Popover API - Tarayıcı yerel tooltip'leri için yeni olanaklar

• Geleneksel tooltip uygulamalarında zorunlu olan JavaScript event listener'ları, durum yönetimi ve ARIA özniteliklerinin elle senkronizasyonu, Popover API tarafından tarayıcının yerel işlevi olarak devralınıyor
• Yalnızca popover ve popovertarget öznitelikleriyle açma/kapama, Esc tuşu işleme ve klavye gezinmesi otomatik çalışıyor
• Ekran okuyucu öngörülebilirliği artıyor, aria-expanded otomatik senkronize ediliyor ve odak geri yükleme gibi erişilebilirlikle ilgili hata kategorileri tamamen ortadan kalkıyor
• Zamanlama kontrolü, hover intent tespiti gibi bazı alanlarda hâlâ JavaScript gerekiyor, ancak temel etkileşim modeli artık tarayıcı tarafından yönetiliyor
• Büyük ölçekli tasarım sistemlerinde veya karmaşık konumlandırma gereken durumlarda kütüphaneler hâlâ geçerliliğini koruyor, ancak varsayılan yaklaşım yerel API'lere kayıyor

---

Geleneksel tooltip'lerin sorunları

• Popover API'den önce tarayıcıda fare, klavye ve yardımcı teknolojiler genelinde çalışan yerel tooltip kavramı yoktu
• Tetikleyici öğe, gizli tooltip öğesi ve ikisini koordine eden JavaScript'ten oluşan aynı desen sürekli tekrar ediyordu
• Yüzeyde basit görünse de, gerçek kullanıcılara sunulduğunda çeşitli sorunlar ortaya çıkıyordu
  • Klavye kullanıcıları Tab ile tetikleyiciye gelse bile tooltip görünmüyordu
  • Ekran okuyucu iki kez okuyabiliyor ya da hiç okumuyordu
  • Fare hızlı hareket ettiğinde titreme (flicker) oluşuyordu
  • Küçük ekranlarda içerikler çakışıyordu
  • Esc tuşuyla kapanmıyor, odak kayboluyordu
• Zamanla event listener'lar birikiyor, hover/focus ayrı ayrı ele alınıyor, dış tıklama özel durumları ve ARIA özniteliklerinin elle senkronizasyonu gibi nedenlerle kod şişiyordu

Neden kütüphane kullanılıyordu

• Kütüphaneler konumlandırma, viewport sınırında çevirme, giriş türüne göre event koordinasyonu ve karmaşık yerleşimlerde scroll algılama gibi gerçek işleri yapıyordu
• Yalnızca konumlandırma bile bağımlılığı haklı çıkaracak kadar karmaşıktı; scroll container'lar, transform'lar ve duyarlı yerleşimler ayrı bir zorluktu
• Asıl sorun ise erişilebilirlik davranışında ortaya çıkıyordu
  • Tooltip geç görünüyor ya da hiç görünmüyordu
  • Hızlı tab geçişlerinde tooltip atlanıyordu
  • Esc ile kapatma güvenilir değildi
• Fare kullanıcıları anındalık, klavye kullanıcıları ise öngörülebilirlik beklediğinden, ikisini birden desteklemek gecikme ve edge case'ler yaratıyordu
• Ekran okuyucularda tooltip'in okunması, okunmaması veya iki kez okunması gibi tutarsız davranışlar görülüyordu
• ARIA özniteliklerinin elle güncellenmesinde tek bir ayrıntı bile atlanırsa erişilebilirlik ağacında karışıklık ya da görünmez durumlar oluşabiliyordu

Sorun kodun kendisi değil, platformun sınırıydı

• Uygulama test edilmişti ve kütüphaneler sağlamdı, ancak temel sorun web platformunda uygun affordance'ların bulunmamasıydı
• Tarayıcının bunun bir tooltip olduğunu anlamasının bir yolu yoktu; her şey genel amaçlı öğeler, event listener'lar, elle ARIA ve özel kapatma mantığı gibi konvansiyonlara (convention) dayanıyordu
• Zamanla küçük bir değişiklik bile risk taşımaya başlıyor, önemsiz bir düzeltme dahi regresyona yol açan kırılgan bir yapıya dönüşüyordu
• Yeni bir tooltip eklendiğinde aynı karmaşıklık aynen devralınıyordu

Popover API ile ilk uygulama

• Geçişin nedeni yeni bir deneye girmek değil, tarayıcının zaten anlaması gereken tooltip davranışını sürdürmekten yorulmuş olmaktı
• En küçük biçimde denendi: <button popovertarget="tip-1"> + <div id="tip-1" popover="manual" role="tooltip">
• Event listener yok, durum takibi yok, JavaScript içinde ARIA güncellemesi yok
• Buton odak alınca tooltip görünüyor, Esc basılınca kayboluyor

Hemen fark edilen farklar

• JavaScript olmadan açma/kapama: Tarayıcı çağrıyı yalnızca HTML ile yönetiyor; tetikleyiciyle tooltip arasındaki ilişki açıkça tanımlanıyor
• Esc tuşunun otomatik çalışması: Ek bir tuş dinleyicisi olmadan tarayıcı popover'ı kapatılabilir bir öğe olarak anlıyor
• ARIA durumunun otomatik senkronizasyonu: aria-expanded özniteliği popover açılıp kapandıkça otomatik güncelleniyor; elle yönetim gerekmiyor ve eski durum riski ortadan kalkıyor
• Kodun azalmasından daha önemlisi sorumluluğun el değiştirmesi: Önceden JavaScript'in “var ettiği” tooltip artık tarayıcının işaretlemedeki rolünü anlayıp odak modeli, erişilebilirlik ağacı ve yerel kapatma kurallarına katıldığı bir yapıya dönüşüyor

Invoker Commands'ı anlamak

• popovertarget="id", butonu popover öğesine bağlar
• popovertargetaction ile davranış belirlenir
  • show: yalnızca aç
  • hide: yalnızca kapat
  • toggle (varsayılan): açıksa kapat, kapalıysa aç
• Aynı tooltip için birden fazla tetikleyici kullanılabilir ve temel etkileşim için JavaScript gerekmez

Erişilebilirlikte ücretsiz kazanımlar

• Klavye "kendiliğinden çalışır"

  • Önceden odak tooltip'i tetiklemeli, blur gizlemeli, Esc elle bağlanmalı ve zamanlama da doğru ayarlanmalıydı; yani çok katmanlı bir yapı vardı
  • popover özniteliği (auto veya manual) ayarlandığında tarayıcı temel davranışı kendisi sağlar: Tab/Shift+Tab normal çalışır, Esc her seferinde güvenilir biçimde kapatır
  • Kod tabanından global keydown handler'lar, Esc için özel temizleme mantığı ve klavye gezinmesi sırasında durum kontrolleri çıkarılır

• Ekran okuyucuda öngörülebilirlik

  • En büyük iyileşme alanı buydu; daha önce dikkatli ARIA kullanımına rağmen davranış değişebiliyor, küçük bir değişiklik bile risk yaratıyordu
  • popover="manual" role="tooltip" kullanıldığında davranış çok daha istikrarlı ve öngörülebilir hâle geliyor
  • Geçişten sonra Lighthouse artık yanlış ARIA durumu uyarısı göstermiyor — çünkü hata yapılabilecek özel ARIA durumları artık yok

• Odak yönetimi

  • Önceden odak tetikleyince gösterme, odak tooltip içine geçtiğinde kapatmama, blur işleme ve odağı elle geri getirme gibi karmaşık kurallar vardı
  • Popover API ile odak popover'a doğal şekilde geçer ve kapandığında otomatik olarak tetikleyiciye geri döner
  • Odak geri yükleme kodu eklenmedi; tam tersine kaldırıldı

Popover API'nin hâlâ eksik kaldığı alanlar

• Tooltip zamanlaması

  • Yerel popover anında açılıp kapanır; fare biraz hızlı hareket ettiğinde ya da tetikleyiciye sadece hafifçe değdiğinde tooltip titreyebilir ve istikrarsız hissettirebilir
  • Hover/focus ile açılma arasında gecikme kontrolüne hâlâ ihtiyaç vardır
  • Temel açma/kapama davranışı tarayıcı ve HTML invoker commands tarafından yönetilir; JavaScript ise yalnızca işaretçi tooltip'e geçince gizlemeyi iptal etmek gibi kasıtlı davranış iyileştirmeleri için kullanılır
  • CSS tarafında da bu alan araştırılıyor; interest/invoker ile ilgili çalışmalar, giriş/çıkış gecikmelerini doğrudan CSS ile ifade etmeyi mümkün kılacak yönde ilerliyor

• Hover intent ve Invoker Commands

  • Tarayıcı, birinin neden bir öğenin üzerine hover yaptığını bilemez — bunun kasıtlı mı olduğu, yoksa işaretçinin sadece üzerinden mi geçtiği ayırt edilemez
  • Invoker commands temel açma/kapamayı yönettiği için JavaScript artık etkileşim modelinin sahibi değildir; sadece bunun üzerine niyet katmanı ekler
  • JavaScript yalnızca kapatmadan önce kısa gecikme eklemek veya işaretçi tooltip'e giderse kapatmayı iptal etmek gibi tarayıcının çıkaramayacağı davranışlar için kullanılır

• Manual popover ve odak

  • popover="manual" kullanıldığında, auto popover'dan farklı olarak tarayıcı odağı otomatik geri yüklemez
  • Tooltip odakla açılıp blur ile kapanıyorsa, odağın tetikleyiciye açıkça geri verilmesi gerekir
  • Bu, platform davranışı ile kullanıcı niyeti arasındaki net sınırı gösterir

• Dürüst değerlendirme

  • Popover API tooltip'leri sihirli biçimde çözmez, ancak kırılgan altyapıyı yeniden kurma işini durdurur
  • Hâlâ JavaScript kullanılır ve edge case'ler düşünülür, ancak artık UI primitive'lerini yeniden üretmek yerine ürün sorunlarını çözmeye odaklanılabilir

Hâlâ tooltip kütüphanesine ihtiyaç duyulan durumlar

• Büyük ölçekli veya olgun tasarım sistemleri

  • Birden çok ekibin kullandığı büyük tasarım sistemlerinde merkezi davranış, belgelenmiş desenler ve tutarlı varsayılanlar için kütüphane mantıklı olabilir
  • Temel etkileşim modelini değiştirmek yalnızca teknik değil, aynı zamanda organizasyonel bir karardır
  • Erişilebilirlik nüanslarına aşina olmayan ekip üyeleri için bir güvenlik korkuluğu sağlar

• Karmaşık konumlandırma gereksinimleri

  • İç içe scroll container'lar arasında çarpışma tespiti, özel flipping mantığı ve offset/sınırların ince ayarı gerekiyorsa Floating UI gibi kütüphaneler hâlâ avantajlıdır
  • CSS anchor positioning bu sorunun büyük kısmını kapsamayabaşlıyor — tetikleyiciye göre göreli yerleşim, viewport farkındalığıyla yerleşim ve kenarda çevirme saf CSS ile mümkün hâle geliyor
  • Bu hâlâ yeni bir özellik ve bilinen sorunları var, ancak Interop kapsamına alınmış durumda; bu da tam ve tutarlı tarayıcı desteği için umut veriyor
  • Bugün tutarlı cross-browser davranış gerekiyorsa kütüphane hâlâ pratik seçimdir

• Erişilebilirlik deneyimi az olan ekipler

  • Erişilebilirlik bilgisi sınırlı ekiplerde iyi bir kütüphane güvenlik ağı işlevi görür — kusursuz erişilebilirliği garanti etmese de yaygın hataları önler
  • Popover API daha iyi varsayılanlar sunsa da role, label, odak yönetimi ve testi ne zaman eklemek gerektiğini bilmek hâlâ önemlidir
  • Anlayış olmadan yerel araçlar da yanlış kullanılabilir

Sonuç

• Popover API sayesinde tooltip artık simüle edilen bir şey değil, tarayıcının anladığı bir öğe hâline geliyor
• Açma, kapama, klavye davranışı, Esc işleme ve erişilebilirliğin büyük bölümü doğrudan platform tarafından sağlanıyor
• Karmaşık tasarım sistemlerinde, ileri düzey özelleştirmede ve legacy kısıtlarında kütüphaneler hâlâ geçerlidir; ancak varsayılan yaklaşım değişiyor
• En basit tooltip'in aynı zamanda en doğru tooltip olabildiği ilk döneme giriliyor
• Üründeki tek bir tooltip'i bile Popover API ile değiştirerek koddan nelerin kaybolduğunu görebilirsiniz