iOS PWA'da klavye üstünde sabit composer: dvh ve interactive-widget çözüm değil

Bir geliştirici, iOS'ta ana ekrana eklenmiş (standalone) bir PWA'daki sohbet ekranında klavye açıldığında mesaj yazma kutusunun klavyenin arkasında kaldığını tespit etti. Sorunun kaynağı net: interactive-widget=resizes-content meta etiketi yalnızca Chromium tarayıcılarda çalışıyor, WebKit bu değeri tamamen yok sayıyor; 100dvh birimi de klavye açıldığında tepki vermiyor.

Ölçümler ilginç detaylar ortaya koyuyor: window.innerHeight klavye açıkken görsel viewport'u takip ediyor, dolayısıyla innerHeight ile visualViewport.height farkına dayalı klavye tespiti asla çalışmıyor. documentElement.clientHeight ise sabit kalıyor ve position:fixed elemanların containing block'u değil. visualViewport'un resize olayı, ekran animasyonundan yaklaşık 200ms önce, animasyonun bitmiş halini erken bildiriyor — bu da senkronize bir geçiş animasyonu yapmayı imkansız kılıyor.

Denenen yaklaşımlar arasında hesaplanan klavye yüksekliğiyle bottom değerini kaydırmak, her iki kenarı eşit miktarda taşımak, karşı-animasyon uygulamak ve scrollIntoView kullanmak var; sonuncusu position:fixed elemanı hareket ettiremediği için zararlı çıkıyor. Şu anki çözüm, visualViewport.height değerini bir CSS özel değişkenine (--vvh) yazıp kök elemanı görünür alana göre küçültmek — Chrome'un interactive-widget=resizes-content ile otomatik yaptığını elle uygulamak. Bu, iOS Safari'de klavye etkileşimli arayüzler geliştiren mühendisler için hem pratik bir workaround hem de platformlar arası tutarlılığın hâlâ ne kadar kırılgan olduğunu gösteren somut bir örnek.