caniuse.com’da html öğesinin neden %100 desteklenmediği

 (anderegg.ca)
2 puan yazan GN⁺ 2024-02-03 | 1 yorum | WhatsApp'ta paylaş
  • CanIUse.com, web teknolojilerinin uyumluluğunu izleyen bir site; ancak temel öğe olan html için destek oranının %97,34 olarak gösterilmesi, bu sayının nasıl yorumlanması gerektiği konusunda soru işaretleri doğuruyor
  • Bu destek oranı, CanIUse.com’un kullandığı MDN uyumluluk verileri ile bağlantılı ve html öğesi sayfasındaki bazı alt maddelerin etkili olduğu anlaşılıyor
  • Sorunlu maddeler, isteğe bağlı manifest özniteliği ve secure context required; ikisi de standartlaştırılmamış ya da kullanımdan kaldırılmış maddeler
  • Desteklenmeyen, destek durumu bilinmeyen tarayıcılar ve eski tarayıcıların ele alınış biçimi bir araya gelince, html gibi temel öğelerde bile sezgilere aykırı destek oranları ortaya çıkıyor
  • “% of all tracked” ölçütünde support unknown eklenince oran %99,98 olarak görülebiliyor; bu da yuvarlama hatası olasılığını artırıyor, ancak CanIUse.com’daki sayıların daha dikkatli okunması gerekiyor

html destek oranının %97,34 olmasıyla doğan soru

  • CanIUse.com, web teknolojilerinin tarayıcılardaki benimsenme oranını ve özellik uyumluluğunu izler; bir özelliğin pratikte ne kadar kullanılabilir olduğunu sayısal olarak gösterir
  • html öğesinin destek oranı %97,34 olarak gösteriliyor
    • Bu, audio öğesinden daha düşük bir oran
    • a ve p öğeleri de aynı şekilde %97,34 destek oranıyla gösteriliyor
  • Web’in çok eski zamanlarından beri kullanılan temel öğelerin %100 olmaması, basit bir uyumluluk sayısının ötesinde doğrulama gerektiriyor

MDN uyumluluk tablosunda görünen alt maddeler

  • CanIUse.com’daki verilerin büyük bölümünün MDN’den alındığı anlaşılıyor
  • MDN’deki html öğesi sayfasında bir tarayıcı uyumluluğu bölümü bulunuyor
  • Bu tabloda çok sayıda kırmızı X görülen iki madde var
  • Neredeyse tüm tarayıcıların bu iki maddeyi desteklemediği doğru olsa da, yalnızca bunun html öğesinin genel destek oranını %97,34 seviyesine neden düşürdüğü netleşmiyor

Eski tarayıcılar ve yuvarlama hatası olasılığı

  • Bazı tarayıcılar Support Unknown olarak gösteriliyor ve bu tarayıcıların güncel kullanım toplamı %1,27
  • Android Browser 2.1–4.3, html öğesini desteklemiyor olarak gösteriliyor; ancak kullanım payı %0
    • Bu eski tarayıcıların gerçekten html öğesini desteklemediği yönündeki gösterim şüpheli
    • Yuvarlama hatasının %1,27’yi %2,66’ya kadar çıkarıp çıkaramayacağı da belirsiz
  • CanIUse.com’un sağ üst köşesinde “usage” yanındaki ölçüt “% of all tracked” olarak değiştirilip “support unknown” tarayıcı değerleri eklendiğinde sonuç %99,98 oluyor
    • Bu ölçütte, mevcut sayının yuvarlama hatasından kaynaklanmış olabileceğini görmek daha kolay
    • Ancak html gibi temel bir öğede eski tarayıcıların nasıl ele alındığı hâlâ kafa karıştırıcı
  • CanIUse.com hâlâ yararlı bir kaynak, ancak gösterilen destek oranları bağlamı ve hesaplama ölçütleriyle birlikte kontrol edilmeli

İlgili okumalar

1 yorum

 
GN⁺ 2024-02-03
Hacker News görüşleri

  • CanIUse'ta Global oranının hemen üstünde "% of all" seçeneği var. Özellik sayfasındaki dişli simgesini açarsanız kullanım hesaplama yöntemi daha ayrıntılı gösteriliyor Varsayılan ayar, caniuse'un takip etmediği tarayıcıların kullanımını tamamen desteklenmiyor sayan All Users ve bunu All tracked users olarak değiştirince yalnızca takip edilen tarayıcılar hesaplanıyor ve oran 98.71% oluyor Grafikte destek durumu Unknown olan tarayıcıların toplamı 1.27%; 98.71%'e 1.27% eklenince 99.97999… çıktığı için bunun yuvarlamadan kaynaklanıyor gibi göründüğü söylenebilir Asıl sorun, bu tarayıcıların Unknown olarak görünmesi; gerçekte ise `` öğesini destekliyor kabul etmek makul olabilir

    • API SaaS'ımızın istek günlüklerinde görülen, “tam olarak ne olduğu belirlenemeyen” User-Agent dizelerine bakınca, o 1.27%'lik “tarayıcıların” önemli bir kısmının kendi asıl alanları dışında yanlışlıkla gelen çeşitli özel amaçlı scraper'lar olma ihtimali yüksek görünüyor Bu yüzden mutlaka `` ayrıştırabildiklerini varsayamayız. JSON scraper'ı da olabilirler
    • wget'i çok kullanıyorum; eğer onu dahil ediyorsanız durum farklı. src/html-url.c dosyasına baktım, gerçekten de `` desteği yok ve bunu bilinmeyen etiket olarak işliyor

  • MDN eskiden Mozilla Developer Network'ün kısaltmasıydı ama artık sadece MDN olması dikkatimi çektiği için araştırdım; ben de tam açılımını bulamadım

    • Bu değişiklik 2017 civarında yapıldı. Mozilla Developer Network adı biraz belirsizdi ve anketlerle kullanıcı görüşmelerinde de kafa karışıklığı yarattığı görülmüştü Web geliştiricileri bunun yalnızca Mozilla geliştiricilerine yönelik materyaller olduğunu düşünüyordu; başlangıçta gerçekten de ağırlık biraz öyleydi, yani tamamen yanlış da sayılmazdı Bir süre MDN'de web platformu belgelerinin yanında Mozilla ile ilgili çok sayıda belge de vardı, ancak 2017'de web platformu belgeleri MDN trafiğinin %95'ini oluşturmaya başlamıştı ve artık ana kimliği Mozilla geliştiricilerine yönelik kaynak olmak değildi Bu yüzden odak değişimini yansıtmak için adını MDN Web Docs yaptılar
    • Bu değişiklik yaklaşık 15 Ağustos 2017'de oldu. Markalama değişmişken sayfa içeriği henüz güncellenmemiş anı tesadüfen gördüğüm için biliyorum O zaman gönderdiğim hata raporu burada: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • Buna anachronym demeyi seviyorum. Zamansız kalmış bir kısaltma hissi veriyor. Teknik olarak bu bir acronym'den çok bir initialism ama bununla ilgili bir yazı da yazmıştım https://simpsonian.ca/blog/anachronyms/
    • Yan sayfalarda ve örnek kodlarda birkaç yerde hâlâ kalmış ama bulabildiklerim bunlar “will soon be a proud part of the Mozilla Developer Network (MDN)” — https://developer.mozilla.org/en-US/blog/mdn-observatory/ “Their brilliant but offbeat idea grew into today's Mozilla Developer Network” — https://developer.mozilla.org/en-US/docs/MDN/At_ten const heading = Mozilla Developer Network; — https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...
    • Birkaç yıl önce Microsoft belgelerinin Mozilla belgelerine yönlendirmeye başladığını hatırlıyorum. Bu, Edge yeniden markalamasının bir parçası da olmuş olabilir Eğer adı MDN yapma kararı o uzlaşma sürecinde alındıysa, “bu M(ozilla)DN mi, M(icrosoft)DN mi?” türü bir karışıklığı önlemek istemiş olabilirler ama emin değilim

  • İlginç şekilde, ve öğelerinin de birebir aynı 97.34% destek oranına sahip olduğu söylenmişti Bu iki öğe de `` öğesinde olduğu gibi MDN'den gelen veriyi kullanıyor: https://caniuse.com/mdn-html_elements_a ve https://caniuse.com/mdn-html_elements_p Bunu yazıya yansıtacak şekilde güncelledim

  • CanIUse'ta html-manifest için ayrı bir özellik tanımlansa iyi olabilir Ayrıca MDN'in gerçekten harika bir kaynak olduğunu da tekrar söylemek isterim

  • İlk web sayfası html öğesini kullanmıyor http://info.cern.ch/hypertext/WWW/TheProject.html

  • Bu, minimum geçerli HTML ile mi ilgili? Orada HTML etiketi yok

    • Pek ilgili görünmüyor. `` de neredeyse aynı orana sahip: https://caniuse.com/mdn-html_elements_title Daha çok, kullanımı bilinen ama destek durumu doğrulanamayan tarayıcıların nasıl hesaba katıldığı meselesi gibi görünüyor Ek olarak, o HTML aslında geçerli değil ve boş bir başlık olarak değerlendiriliyor; boş başlık geçerli sayılmaz. . gibi bir şeye çevirirseniz hata vermeden geçer
    • Ama orada etiketi yok mu? Sadece açıkça yazılmamış, dolayısıyla çıkarımla var olduğu kabul ediliyor. Hangi tarayıcıyla açarsanız açın o sayfada etiketi bulunur
    • E-postadaki Subject başlığı gibi başlığın başka şekilde iletilebildiği protokollerde isteğe bağlıdır Bu yüzden en kısa geçerli HTML aslında sadece olur; ama yalnızca belirli bağlamlarda geçerlidir

  • “Sitedeki verilerin çoğu MDN'den geliyor” demek biraz muğlak CanIUse'a bağlı özellik destek matrisleri, MDN'in browser-compat-data deposundan geliyor. HTML öğelerine ait kaynak veri burada: https://github.com/mdn/browser-compat-data/blob/main/html/el... Ancak burada, CanIUse'ın destek oranı hesaplamak için kullandığı testler ve kullanım bilgileri yok; yalnızca hangi tarayıcı sürümünde hangi özelliğin bulunduğu bilgisi var CanIUse da kendi deposunu işaret ediyor ve orada epey veri bulunuyor: https://github.com/fyrd/caniuse Ama belirli bir öğenin sayısının nereden geldiğini kolayca bulmayı sağlayan bir giriş noktası göremedim. Oradaki veriler de daha çok özellik bazlı görünüyor Daha doğru soru, CanIUse'ın HTML öğesi testlerini ve kullanım sayılarını nereden aldığı; asıl mesele de bu gibi duruyor

  • `` öğesinin destek oranı, diğer tüm öğelerden en azından daha düşük ya da onlara eşit olmak zorunda değil mi?

    • Hayır. öğesi “HTML'in tamamı” anlamına gelmiyor; sadece **belgenin kök öğesi** olan başka bir öğe Başkasının da yazdığı gibi, hatasız geçerli bir HTML belgesi üretmek için gerçekten zorunlu da değil; o durumda gereken şey ve geçerli bir gövde içeriği Benzetme yaparsak, bir makale başlığındaki “English” kelimesini doğru anlayıp ayrıştırabilmek, İngilizce bir kelime olan “fustigate”in anlamını bilmekten ayrı bir şeydir

  • “Yani net bir yanıt yok. Bilen varsa söylesin!”