Popover API'sine Başlarken
Twitter'da paylaş, LinkedIn
Bir kitaplığın yardımı olmadan tarayıcının yerel modelini kullanarak tek bir araç ipucunu yeniden oluşturursanız ne olur? Popover API, araç ipuçlarını simüle ettiğiniz bir şeyden tarayıcının gerçekten anladığı bir şeye dönüştürür. Açma ve kapatma, klavye etkileşimi, Kaçış yönetimi ve erişilebilirliğin büyük bir kısmı artık geçici JavaScript'ten değil, platformun kendisinden geliyor. Bir kitaplığın yardımı olmadan tarayıcının yerel modelini kullanarak tek bir araç ipucunu yeniden oluşturursanız ne olur? Popover API, araç ipuçlarını simüle ettiğiniz bir şeyden tarayıcının gerçekten anladığı bir şeye dönüştürür. Açma ve kapatma, klavye etkileşimi, Kaçış yönetimi ve erişilebilirliğin büyük bir kısmı artık geçici JavaScript'ten değil, platformun kendisinden geliyor.
Sonuç ve Değerlendirme
Araç ipuçları, karşılaşabileceğiniz en küçük kullanıcı arayüzü sorunu gibi geliyor. Küçükler ve genellikle gizlidirler. Birisi nasıl oluşturulacağını sorduğunda, geleneksel yanıt neredeyse her zaman bir JavaScript kitaplığı kullanılarak gelir. Ve uzun bir süre bu mantıklı bir tavsiyeydi.
Nasıl Önlem Alınmalı?
Ben de onu takip ettim.
Görünüşte bir araç ipucu basittir. Bir öğenin üzerine gelin veya odaklanın, metin içeren küçük bir kutu gösterin, ardından kullanıcı uzaklaştığında onu gizleyin. Ancak bir tanesini gerçek kullanıcılara gönderdiğinizde avantajlar ortaya çıkmaya başlar. Klavye kullanıcıları Tetikleyiciye dokunur ancak araç ipucunu asla görmez. Ekran okuyucular bunu iki kez duyurur veya hiç duyurmaz. Fareyi çok hızlı hareket ettirdiğinizde araç ipucu titriyor. Daha küçük ekranlardaki içerikle örtüşür. Esc tuşuna basınca kapatmıyor. Odaklanma kaybolur.
Zamanla araç ipucu kodum artık gerçekten sahip olmak istemediğim bir şeye dönüştü. Etkinlik dinleyicileri birikti. Fareyle üzerine gelme ve odaklanmanın ayrı ayrı ele alınması gerekiyordu. Dış tıklamalar özel durumlara ihtiyaç duyuyordu. ARIA niteliklerinin elle senkronize tutulması gerekiyordu. Her küçük düzeltme başka bir mantık katmanı ekledi.
Önemli Gelişmeler
Kütüphaneler yardımcı oldu ama aynı zamanda perde arkasında neler olup bittiğini tam olarak anlamak yerine, üzerinde çalıştığım kara kutular gibiydiler.
Beni daha yeni Popover API'sine bakmaya iten şey buydu. Bir kitaplığın yardımı olmadan tarayıcının yerel modelini kullanarak tek bir araç ipucunu yeniden oluşturursam ne olacağını görmek istedim.
Başlarken, her yeni özellikte olduğu gibi bu özellikte de hala düzeltilmekte olan bazı şeylerin olduğunu belirtmekte fayda var. Bununla birlikte, genel API'nin değişen birkaç parçası olmasına rağmen şu anda harika bir tarayıcı desteğine sahiptir. Bu arada Caniuse'a göz kulak olmakta fayda var.
Popover API'sinden önce araç ipucu kitaplığı kullanmak bir kısayol değildi. Bu varsayılandı. Tarayıcıların fare, klavye ve yardımcı teknolojide çalışan yerel bir araç ipucu konsepti yoktu. Doğruluğu önemsiyorsanız tek seçeneğiniz kütüphane kullanmaktı ve ben de tam olarak öyle yaptım.
Yüksek düzeyde model her zaman aynıydı: bir tetikleyici öğe, gizli bir araç ipucu öğesi ve ikisini koordine edecek JavaScript.
Detaylar ve Etkileri
Eski yaklaşım, beş olay dinleyicisi ve manuel durum yönetimi ile ~60 satır JavaScript gerektiriyordu. Yeni yaklaşım, sıfır olay dinleyicisi olan yaklaşık 10 satırlık bildirimsel HTML'dir. (Büyük önizleme)
Kütüphane, öğenin fareyle üzerine gelindiğinde veya odaklanıldığında gösterilmesine, bulanıklaştırıldığında veya fare bırakıldığında gizlenmesine ve kaydırıldığında yeniden konumlandırılmasına/yeniden boyutlandırılmasına olanak tanıyan kablolamayı yönetiyordu.
Teknik Analiz
Hiçbiri tesadüf değildi. Yalnızca web platformu özelliklerindeki boşlukları telafi ediyordu.
Uzmanların Görüşleri
Neden Kütüphane Kullandım
Gelecekte Ne Bekleniyor?
Kütüphane benim için gerçek bir iş yapıyordu: konumlandırma, görünüm kenarlarını çevirme, giriş türleri arasında olay koordinasyonu ve karmaşık düzenlerde kaydırma farkındalığı. Konumlandırma tek başına bağımlılığı haklı çıkardı. Kaydırma kapsayıcılarını, dönüşümleri ve duyarlı düzenleri doğru bir şekilde yönetmek basit değildir.
Asıl sorunlar görsellerde değil erişilebilirlik davranışında ortaya çıktı. Araç ipucu işe yaradı, ancak her zaman değil. İşte dikişlerde işlerin yıpranmaya başladığı yer:
Sistem Güvenliği
Araç ipuçları bazen geç ortaya çıkıyor veya hiç ortaya çıkmıyor.
Hızlı bir şekilde sekme yapmak onları tamamen atlayabilir.
Kaçış işten çıkarma güvenilir değildi.
Eski uygulamayla klavyede gezinme: Hızlı bir şekilde sekme yapmak, araç ipuçlarının tamamen atlanmasına neden olur ve işten çıkarmadan kaçış güvenilmezdir.
Fareyle üzerine gelme ve odaklanma davranışını senkronize etmeye çalışırken de sorunlarla karşılaştım:
Fare kullanıcıları aciliyet bekler.
Klavye kullanıcıları öngörülebilirlik bekler.
Hem gecikmelerin hem de uç durumların desteklenmesi anlamına geliyordu.
Bu zamanlama uyumsuzluğu, giriş yöntemleri arasında tutarsız bir deneyim yaratır.
Bahsetmiyorum bile, orada Yardımcı teknolojilerle, özellikle de ekran okuyucularla ilgili sorunlar vardı: Araç ipucu bazen duyuruluyor, bazen duyurulmuyor, bazen de iki kez duyuruluyor.
Özel araç ipuçlarıyla ekran okuyucu davranışı.
ARIA niteliklerini senkronize tutmak için manuel güncellemeler gerekiyordu. Bir durum değişikliğini kaçırırsanız araç ipucu kafa karıştırıcı hale gelir veya erişilebilirlik ağacında görünmez hale gelir.
Uygulama test edildi, kütüphane sağlamdı ve o sırada mevcut olan araçlar göz önüne alındığında davranış makuldü.
Temel sorun kod değildi. Web platformunun uygun olanaklardan yoksun olmasıydı.
Örneğin tarayıcının, öğenin bir araç ipucu olduğunu bilmesinin gerçek bir yolu yoktur. Her şey geleneklerden oluşturuldu: genel öğeler, olay dinleyicileri, manuel olarak yönetilen ARIA ve özel işten çıkarma mantığı.
Önce: Olay dinleyicilerinden, durum yönetiminden ve manuel ARIA güncellemelerinden oluşan karmaşık bir ağ. Sonra: Tarayıcı ilişkiyi bildirimsel olarak anlar. (Büyük önizleme)
Zamanla araç ipucu kırılgan hale gelebilir. Küçük değişiklikler risk taşıyordu. Küçük düzeltmeler gerilemelere neden oldu. Daha da kötüsü, yeni araç ipuçlarının eklenmesi aynı karmaşıklığı miras aldı. İşler teknik olarak işe yaradı, ancak hiçbir zaman çözülmüş veya tamamlanmış hissetmedim.
Araç ipucunu tarayıcının yerel Popover API'sini kullanarak yeniden oluşturmaya karar verdiğimde durum böyleydi.
Popover API'sini Denediğim An
Yeni bir şey denemek istediğim için Popover API'sini kullanmaya geçmedim. Tarayıcının zaten anlamış olması gerektiğine inandığım araç ipucu davranışını sürdürmekten yorulduğum için geçiş yaptım.
İlk başta şüpheciydim. Yeni web API'lerinin çoğu basitlik vaat eder, ancak yine de yapıştırıcı, uç durum yönetimi veya kaçmaya çalıştığınız karmaşıklığın aynısını sessizce yeniden yaratan geri dönüş mantığı gerektirir.
Bu yüzden Popover API'sini mümkün olan en küçük şekilde denedim. İşte neye benziyordu:
Popover API'sini kullanan eksiksiz araç ipucu uygulaması
Etkinlik dinleyicisi yok. Durum takibi yok. JavaScript'te hiçbir ARIA güncellemesi işlenmedi. Düğmeye odaklandım ve araç ipucu belirdi. Esc tuşuna bastım ve kayboldu.
Hemen Öne Çıkan Neydi?
Birkaç dakika içinde birkaç şey açıkça ortaya çıktı:
Açmak veya Kapatmak İçin Herhangi Bir JavaScript Yazmadım
Tarayıcı, çağrıyı tamamen HTML aracılığıyla gerçekleştirdi. Tetikleyici ve araç ipucu arasındaki ilişki açıktı.
Esc Tuşu Az Önce İşe Yaradı
Önemli bir dinleyici eklemedim. Esc tuşuna basıldığında araç ipucu düzgün bir şekilde kapatıldı çünkü tarayıcı açılır pencerelerin kapatılabilir olması gerektiğini anlıyor.
ARIA Durumu Otomatik Olarak Senkronize Edildi
Aria-expanded özelliği, açılır pencere açılıp kapandığında kendi kendine güncellendi. Manuel defter tutmaya gerek yoktu ve eski durum riski yoktu.
Tarayıcının DevTools'u, açılır pencere açıldığında otomatik olarak yanlıştan doğruya güncellenen aria-genişletilmiş özelliği gösteriyor.
Bu, Popover API'sinin kolaylık sağlamayı bıraktığı ve daha çok gerçek iyi niyetli platform davranışına benzediği andı.
Beni en çok şaşırtan kodun azaltılması değil, sorumluluğun değişmesiydi. Daha önce araç ipucu, JavaScript'im öyle söylediği için mevcuttu. Artık tarayıcı ne olması gerektiğini ve işaretlemedeki rolünü anladığı için var. Araç ipucu artık yalnızca bir düğmenin yanına yerleştirilmiş bir kutu değil; tarayıcının odak modeline, erişilebilirlik ağacına ve yerel kapatma kurallarına katılan bir araç.
İşte o zaman Popover API'sine geçişim başladı.
Çağırıcı Komutlarını Anlamak
Popovertarget ve popovertargetaction nitelikleri, HTML'nin invoker komutlarının bir parçasıdır; JavaScript olmadan etkileşimli öğeleri kontrol etmenin bildirimsel bir yoludur.
popovertarget="id" : Düğmeyi bir popover öğesine bağlar.
: Düğmeyi bir açılır öğeye bağlar. popovertargetaction : Ne olacağını belirtir: show : Yalnızca popover'ı açar. hide : Yalnızca açılır pencereyi kapatır. geçiş (varsayılan): Kapalıysa açılır pencereyi açar, açıksa kapatır.
: Ne olması gerektiğini belirtir:
Bu, aynı araç ipucu için birden fazla tetikleyiciye sahip olabileceğiniz anlamına gelir:
Tarayıcı, temel etkileşim için JavaScript gerekmeden her şeyi koordine eder.
Ücretsiz Erişilebilirlik Kazanır
Bu beni tamamen değiştirmeye iten kısımdı. Popover API'sinin kodu azaltmasını bekliyordum. Yıllardır peşinde koştuğum erişilebilirlik hatası kategorilerinin tamamını ortadan kaldırmasını beklemiyordum. Geçişten önce araç ipucu sistemim en azından iyi görünüyordu. Klavye desteği mevcuttu, ARIA özellikleri mevcuttu ve ekran okuyucular genellikle buna göre davranıyordu. Ama “genellikle” çok fazla ağır kaldırma işi yapıyordu.
Yerel popover'ları değiştirdiğimde üç şey hemen değişti.
Özel uygulamalar, tetikleyicileri ve araç ipuçlarını bağlamak için hassas JavaScript kullanır. Popover API, yardımcı teknolojinin güvenebileceği yerel bir tarayıcı bağlantısı oluşturur. (Büyük önizleme)
1. Klavye “Sadece Çalışıyor”
Klavye desteği birden fazla katmanın doğru şekilde sıralanmasına bağlıydı: Odaklanmanın araç ipucunu tetiklemesi, bulanıklaştırmanın onu gizlemesi, Esc'nin manuel olarak kablolanması gerekiyordu ve zamanlama önemliydi. Bir uç durumu kaçırırsanız, araç ipucu ya çok uzun süre açık kalır ya da okunamadan kaybolur.
Popover özelliği auto veya manual olarak ayarlandığında, tarayıcı temel işlemleri devralır: Tab ve Shift + Tab normal şekilde davranır, Esc her seferinde araç ipucunu kapatır ve fazladan dinleyiciye gerek kalmaz.
Kod tabanımdan kaybolanlar, genel tuş indirme işleyicileri, Esc'ye özgü temizleme mantığı ve klavyede gezinme sırasındaki durum kontrolleriydi. Klavye deneyimi artık sürdürmem gereken bir şey olmaktan çıktı ve bir tarayıcı garantisi haline geldi.
2. Ekran Okuyucunun Tahmin Edilebilirliği
Bu en büyük gelişmeydi. Dikkatli bir ARIA çalışmasına rağmen, daha önce de belirttiğim gibi davranışlar değişiklik gösteriyordu. Her küçük değişiklik riskli geliyordu. Popover'ı uygun bir rolle kullanmak, ne olacağı konusunda çok daha istikrarlı ve öngörülebilir görünüyor ve hissettiriyor:
Ve işte başka bir kazanç: Geçişten sonra Lighthouse, etkileşim için hatalı ARIA durumu uyarılarını işaretlemeyi bıraktı; bunun büyük ölçüde nedeni, kazara hata yapabileceğim özel ARIA durumlarının artık olmamasıydı.
Geçişten önce Lighthouse, yanlış ARIA durumu yönetimiyle ilgili erişilebilirlik uyarılarını işaretledi. Popover API'sine geçtikten sonra denetim puanı arttı. (Büyük önizleme)
Odaklanma eskiden kırılgandı. Daha önce şu gibi kurallarım vardı: odak tetikleyicisinin araç ipucunu göstermesine izin ver, odağı araç ipucuna taşıyın ve kapatmayın, çok yakın olduğunda tetikleyiciyi bulanıklaştırın ve araç ipucunu kapatıp odağı manuel olarak geri yükleyin. Bu, işe yaramayana kadar işe yaradı.
Popover API'si ile tarayıcı, odağın popover'a daha doğal bir şekilde taşınabileceği daha basit bir modeli uygular. Açılır pencerenin kapatılması, odağın tetiğe dönmesini sağlar ve görünmez odak tuzakları veya kaybolan odak anları olmaz. Odak restorasyon kodunu da eklemedim; Kaldırdım.
Tetiğe odaklanmak için dokunun, araç ipucu görünür, kapatmak için Escape tuşuna basın ve odak otomatik olarak tetiğe geri döner.
Popover API'sinin Belki Hala Yeterli Olmadığı Yer
Popover API kodumu basitleştirip anlambilimi geliştirmiş olsa da hâlâ JavaScript'i tamamen ortadan kaldırmadı. Bu tamamen kötü bir şey değil çünkü değişen şey, JavaScript'in artık önemli bir bağımlılık olmamasıdır. Artık eksik platform davranışını telafi etmiyorum. Ben daha çok niyete odaklanıyorum.
API'nin gelişmeye devam ettiğini görebileceğim birkaç yer var.
İpucu Zamanlaması Hala Önemli
Yerel popover'lar hemen açılıp kapanıyor. Bu genellikle beklenen davranıştır ancak araç ipuçları olarak değerlendirdiğimiz şeyler için her zaman ideal değildir. Bu gibi durumlarda, farenizi birkaç piksel fazla hızlı hareket ettirdiğinizde veya kazara tetikleyicinin yanından geçtiğinizde anında kapatma işlemi kararsız hale gelebilir; araç ipucu yanıp söner, sonra kaybolur ve bu da rahatsız edici olabilir.
Bu zamanlamayı kontrol edebilmek ve fareyle üzerine gelme veya odaklanma ile araç ipucunu açma arasında gecikmeler uygulayabilmek istiyorum. Bu yüzden hala küçük gecikmeler ekliyorum. Değişen şey aslında etkileşim mantığının ne kadarına sahip olmam gerektiğiydi. Daha önce temel açma ve kapama davranışı bile JavaScript gerektiriyordu. Popover API ve özellikle HTML çağırma komutlarıyla bu sorumluluk tekrar tarayıcıya geçer.
Bu noktada tarayıcı, başlatma, reddetme ve ARIA durumunu kendi başına yönetir. Orada' Sadece araç ipucunun görünmesini veya kaybolmasını sağlamak için herhangi bir JavaScript kullanılmaz.
JavaScript yalnızca kasıtlı davranış istediğimde geri geliyor. Bu durumda, araç ipucunu gizlemeden önce kısa bir gecikme olur ve imleç ipucunun içine doğru hareket ederse iptal edilir. Bu erişilebilirlik düzeltmeleriyle ilgili değil. İnsan davranışlarıyla ilgili.
CSS'nin de bu alanı keşfetmeye başladığını belirtmekte fayda var. Ortaya çıkan ilgi/çağrı çalışması, giriş ve çıkış gecikmelerini doğrudan CSS'de ifade etmenin yollarını sunar; bu, bu küçük JavaScript parçasını tamamen kaldırabilir. Şimdilik bu işi hala zorunlu olarak hallediyorum ama platformun yönü belli.
let hideTimeout; const show = () => { clearTimeout(hideTimeout); tooltip.showPopover(); }; const hide = () => { hideTimeout = setTimeout(() => { tooltip.hidePopover(); }, 200); };
Aradaki fark bu mantığın küçük ve yerel kalmasıdır. Artık araç ipucunun nasıl çalıştığını tanımlamamaktadır. Sadece nasıl hissettiğini iyileştirir.
Çağırıcı Komutlarıyla Amacın Üzerine Gelme
Tarayıcı, birisinin neden bir öğenin üzerine geldiğini veya ona odaklandığını bilmiyor. Kasıtlı mıydı, yoksa işaretçi sadece içinden mi geçiyordu? Bu kısım her zaman biraz muhakeme gerektirmiştir.
Değişen şey bu mantığın nerede yaşadığıdır. Temel açma ve kapama davranışını yöneten invoker komutları ile JavaScript artık etkileşim modeline sahip değildir. Sadece üstüne niyet ekler.
Platform, çağrıyı, işten çıkarmayı ve ARIA durumunu yönetir. JavaScript yalnızca tarayıcının çıkaramayacağı bir davranış istediğimizde gereklidir; örneğin, gizlenmeden önce kısa bir gecikme veya işaretçi araç ipucuna hareket ederse kapatmayı iptal etme.
let hideTimeout; const show = () => { clearTimeout(hideTimeout); tooltip.showPopover(); }; const hide = () => { hideTimeout = setTimeout(() => { tooltip.hidePopover(); }, 200); };
Ve yine CSS bu alanı yeni etkileşim temelleriyle keşfetmeye başlıyor, bu da özel fareyle üzerine gelme amacı koduna olan ihtiyacı daha da azaltabilir.
Manuel Popover'lar ve Odaklanma
popover=manual" için tarayıcı, otomatik popover'larda olduğu gibi odağı otomatik olarak geri yüklemez. Bu sorumluluk açıkça ortadadır. Bir araç ipucu odak noktasında açılıp bulanıklık durumunda kapandığında, odağı bilinçli olarak tetikleyiciye geri döndürürüm:
tooltip.hidePopover(); tetikleyici.focus();
Bu bir sınırlama değil, platform davranışı ile kişinin amacı arasında net bir sınırdır.
Popover API, araç ipuçlarını sihirli bir şekilde çözmez. Beni kırılgan altyapıyı yeniden inşa etmeye zorlamayı bıraktı. Hala JavaScript yazıyorum ve uç durumları düşünüyorum, ancak artık tarayıcının zaten anlaması gereken kullanıcı arayüzü ilkellerini yeniden oluşturmak yerine ürün sorunlarını çözüyorum.
Hala Bir Araç İpucu Kitaplığına Ulaştığımda
Araç ipuçlarımı Popover API'sine taşıdıktan sonra bile kitaplıkların eski ve modası geçmiş olduğunu düşünerek oradan ayrılmadım. Sadece daha spesifik durumlarda yerlerini hak ettiler.
1. Büyük Veya Olgun Tasarım Sistemleri
Birden fazla ekip tarafından kullanılan geniş bir tasarım sistemini sürdürüyorsanız, merkezi davranış, belgelenmiş modeller ve ürünler genelinde tutarlı varsayılanlar nedeniyle bir araç ipucu kitaplığı yine de anlamlı olabilir. Bu ortamlarda temel etkileşim modelini değiştirmek yalnızca teknik bir karar değildir; bu bir organizasyondur. Bakımlı bir kitaplık, özellikle herkesin erişilebilirlik nüanslarına derinlemesine aşina olmadığı durumlarda ekiplere korkuluk sağlar.
2. Karmaşık Konumlandırma Gereksinimleri
Çoğu araç ipucu için yerel konumlandırma yeterlidir, ancak iç içe kaydırma kapları arasında çarpışma algılamaya, özel çevirme mantığına veya uzaklıklar ve sınırlar üzerinde ayrıntılı kontrole ihtiyacınız varsa, Kayan Kullanıcı Arayüzü gibi kitaplıklar hala parlıyor. Platformun henüz yeni çözmeye başladığı geometri sorunları için optimize edilmişlerdir.
Ayrıca, araç ipucu kitaplıklarının tarihsel olarak çözdüğü sorunların çoğunu kapsamaya başlayan CSS bağlantı konumlandırmasından da bahsetmeye değer. Çapalar, görüntü alanına duyarlı yerleştirme ve kenar çevirme de dahil olmak üzere, saf CSS kullanılarak açılır pencerenin bir tetikleyiciye göre konumlandırılmasına olanak tanır. Bu, JavaScript yerine platforma daha fazla sorumluluk taşır.
Bununla birlikte, çapa konumlandırma hala yeni ve bilinen sorunlar var, ancak iyi haber bunların Interop'un bir parçası olması, yani tam ve tutarlı tarayıcı desteğini sabırsızlıkla bekleyebileceğimiz anlamına geliyor. Günümüzde tutarlı tarayıcılar arası davranışa ihtiyaç duyan ekipler için kütüphaneler pratik seçim olmaya devam ediyor. Platformun bir zamanlar gerekli olan işleri sürekli olarak absorbe ettiği yönündeki yön açıktır. özel konumlandırma motorları kullanılmıştır.
3. Erişilebilirlik Deneyimi Olmayan Ekipler
Bu önemli. Eğer bir ekip güçlü bir erişilebilirlik bilgisine sahip değilse, iyi bir kütüphane bir güvenlik ağı görevi görebilir, ancak mükemmel erişilebilirliği garanti etmez. Ancak birçok yaygın hatayı önleyebilir. Popover API size daha iyi varsayılanlar sunar ancak yine de rolleri, etiketleri, odak yönetimini ve testi ne zaman ekleyeceğinizi bildiğinizi varsayar. Bu anlayış olmadan yerel araçlar bile kötüye kullanılabilir.
Benim için seçim artık şöyle görünüyor:
Ve bazen doğru araç hâlâ bir kitaplıktır; yalnızca artık varsayılan olarak değil.
Popover API, araç ipuçlarının artık simüle edebileceğiniz bir şey olmadığı anlamına gelir. Bunlar tarayıcının anladığı şeylerdir. Açma, kapatma, klavye davranışı, Kaçış yönetimi ve erişilebilirliğin büyük bir kısmı artık geçici JavaScript'ten değil, platformun kendisinden geliyor.
Bu, araç ipucu kitaplıklarının geçerliliğini yitirdiği anlamına gelmez çünkü karmaşık tasarım sistemleri, ağır özelleştirme veya eski kısıtlamalar için hala anlamlıdırlar ancak varsayılan değer değişmiştir. İlk defa, en basit araç ipucu aynı zamanda en doğru ipucu da olabiliyor. Merak ediyorsanız şu deneyi deneyin: Ürününüzdeki yalnızca bir ipucunu Popover API ile değiştirin, her şeyi yeniden yazmayın, tüm sistemi taşımayın ve yalnızca birini seçin ve kodunuzdan neyin kaybolduğunu görün.
Platform size daha iyi bir ilkel sunduğunda, kazanç yalnızca daha az JavaScript satırı değil, aynı zamanda endişelenmeniz gereken şeylerin daha az olması anlamına gelir.
GitHub depomdaki kaynak kodunun tamamına göz atın.
Popover'lara ve ilgili API'lere daha ayrıntılı bir bakış için:
MDN ayrıca Popover API'si için kapsamlı teknik belgeler sunar.
