Warum das `html`-Element auf caniuse.com nicht zu 100 % unterstützt wird

 (anderegg.ca)
2 Punkte von GN⁺ 2024-02-03 | 1 Kommentare | Auf WhatsApp teilen
  • CanIUse.com ist eine Website, die die Kompatibilität von Webtechnologien verfolgt, doch für das grundlegende Element html wird eine Unterstützungsrate von 97,34 % angezeigt, was Fragen zur Interpretation der Zahl aufwirft
  • Diese Unterstützungsrate scheint mit den von CanIUse.com verwendeten MDN-Kompatibilitätsdaten zusammenzuhängen, wobei einige Unterpunkte auf der Seite des html-Elements Einfluss haben
  • Die fraglichen Punkte sind das optionale Attribut manifest und secure context required; beide sind entweder nie standardisiert worden oder inzwischen obsolet
  • Durch die Vermischung von nicht unterstützten Browsern, Browsern mit unklarem Supportstatus und sehr alten Browsern erscheint selbst bei einem Basiselement wie html eine Unterstützungsrate, die der Intuition widerspricht
  • Nach dem Maßstab „% of all tracked“ lässt sich zusammen mit support unknown auch ein Wert von 99,98 % ansetzen, sodass Rundungsfehler wahrscheinlicher wirken, aber die Zahlen von CanIUse.com trotzdem mit mehr Vorsicht gelesen werden sollten

Die Frage, die die html-Unterstützungsrate von 97,34 % aufwirft

  • CanIUse.com verfolgt die Browser-Akzeptanz und Feature-Kompatibilität von Webtechnologien und zeigt in Zahlen, wie gut sich Features tatsächlich verwenden lassen
  • Für das html-Element wird eine Unterstützungsrate von 97,34 % angezeigt
    • Das ist ein niedrigerer Wert als beim Element audio
    • Auch die Elemente a und p werden mit derselben Unterstützungsrate von 97,34 % angezeigt
  • Dass grundlegende Elemente des Webs, die seit sehr langer Zeit verwendet werden, nicht bei 100 % liegen, macht eine genauere Prüfung über die bloße Kompatibilitätszahl hinaus nötig

Unterpunkte in der MDN-Kompatibilitätstabelle

  • Viele Daten auf CanIUse.com scheinen von MDN zu stammen
  • Auf der html-Elementseite von MDN gibt es einen Abschnitt zur Browser-Kompatibilität
  • In dieser Tabelle fallen vor allem zwei Einträge mit vielen roten X auf
    • Das optionale Attribut manifest
      • Es ist obsolet
      • Es wurde nie standardisiert
    • Der dazugehörige Eintrag secure context required
  • Dass fast alle Browser diese beiden Punkte nicht unterstützen, ist zwar korrekt, erklärt aber für sich genommen noch nicht eindeutig, warum die gesamte Unterstützungsrate des html-Elements auf 97,34 % sinkt

Alte Browser und mögliche Rundungsfehler

  • Einige Browser sind als Support Unknown gekennzeichnet, und die Summe ihres aktuellen Nutzungsanteils beträgt 1,27 %
  • Android Browser 2.1–4.3 wird als ohne Unterstützung für das html-Element angezeigt, sein Nutzungsanteil liegt jedoch bei 0 %
    • Es erscheint fragwürdig, dass diese alten Browser das html-Element tatsächlich nicht unterstützt haben sollen
    • Unklar bleibt auch, ob ein Rundungsfehler 1,27 % überhaupt auf 2,66 % anheben könnte
  • Wenn man oben rechts auf CanIUse.com den Maßstab neben „usage“ auf „% of all tracked“ umstellt und die Browser mit „support unknown“ hinzurechnet, ergibt sich 99,98 %
    • Nach diesem Maßstab lässt sich leichter erkennen, dass der aktuelle Wert durch Rundung zustande gekommen sein könnte
    • Dennoch bleibt die Behandlung alter Browser bei einem Basiselement wie html verwirrend
  • CanIUse.com ist weiterhin eine nützliche Ressource, aber die angezeigten Unterstützungsraten sollten immer zusammen mit Kontext und Berechnungsgrundlage betrachtet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-02-03
Hacker-News-Kommentare

  • Bei CanIUse gibt es direkt über dem Global-Anteil die Option "% of all". Wenn man auf der Feature-Seite das Zahnrad öffnet, wird die Berechnung der Nutzungsanteile genauer erklärt. Standardmäßig ist All Users aktiv, wobei die Nutzung aller Browser, die caniuse nicht verfolgt, als nicht unterstützt gezählt wird. Stellt man auf All tracked users um, werden nur die erfassten Browser berechnet, und man kommt auf 98,71 %. Die Summe der Browser, deren Unterstützung im Diagramm als Unknown markiert ist, beträgt 1,27 %. Addiert man 1,27 % zu 98,71 %, erhält man 99,97999…, es scheint also ein Rundungseffekt vorzuliegen. Das eigentliche Problem ist, dass diese Browser als Unknown angezeigt werden, und tatsächlich kann man wohl davon ausgehen, dass sie das ``-Element unterstützen.

    • Wenn man sich die User-Agent-Strings anschaut, die in den Request-Logs unserer API-SaaS auftauchen und „nicht wirklich identifizierbar“ sind, dann scheint ein großer Teil dieser 1,27 % „Browser“ aus allerlei Spezial-Scrapern zu bestehen, die zufällig außerhalb ihres eigentlichen Einsatzbereichs gelandet sind. Daher muss man nicht unbedingt annehmen, dass sie `` parsen können. Es könnten auch JSON-Scraper sein.
    • Ich nutze häufig wget; wenn man das mitzählt, sieht die Sache anders aus. Ich habe in src/html-url.c nachgesehen: Dort wird `` tatsächlich überhaupt nicht unterstützt und als unbekanntes Tag behandelt.

  • Ich habe nachgeschaut, weil ich darüber gestolpert bin, dass MDN früher für Mozilla Developer Network stand und jetzt einfach nur noch MDN ist, aber ich konnte den ausgeschriebenen Namen auch nicht finden.

    • Die Änderung erfolgte ungefähr 2017. Der Name Mozilla Developer Network war etwas mehrdeutig, und auch Umfragen sowie Nutzerinterviews zeigten Verwirrung. Webentwickler hielten es für Material ausschließlich für Mozilla-Entwickler, was anfangs tatsächlich auch weitgehend der Charakter davon war, also nicht völlig falsch. Eine Zeit lang gab es auf MDN neben Webplattform-Dokumentation auch viele Mozilla-bezogene Inhalte, aber 2017 machten die Webplattform-Dokumente 95 % des MDN-Traffics aus, und Material für Mozilla-Entwickler war nicht länger die zentrale Identität. Deshalb wurde der Name zu MDN Web Docs geändert, damit die veränderte Ausrichtung sichtbar wird.
    • Diese Änderung geschah ungefähr am 15. August 2017. Ich weiß das, weil ich zufällig den Moment gesehen habe, als das Branding schon geändert war, aber der Seiteninhalt noch nicht. Hier ist der damals eingereichte Bug-Report: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • Ich nenne so etwas gern ein anachronym, weil es sich wie ein anachronistisches Akronym anfühlt. Genau genommen ist das eher ein Initialismus als ein Akronym, aber ich habe auch einen Text dazu geschrieben. https://simpsonian.ca/blog/anachronyms/
    • Es gibt noch ein paar verbliebene Stellen auf Nebenseiten und in Beispielcode, aber mehr als das habe ich nicht gefunden. “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...
    • Ich erinnere mich, dass Microsoft-Dokumentation vor ein paar Jahren begann, auf Mozilla-Dokumentation zu verweisen. Das könnte Teil des Edge-Rebrandings gewesen sein. Falls die Umbenennung zu MDN in diesem Abstimmungsprozess erfolgte, sollte damit vielleicht Verwirrung wie „Ist das jetzt M(ozilla)DN oder M(icrosoft)DN?“ vermieden werden, aber sicher weiß ich es nicht.

  • Interessanterweise hörte ich, dass auch die Elemente und exakt dieselbe 97,34-%-Unterstützungsquote haben. Auch für diese beiden Elemente werden wie beim ``-Element Daten von MDN verwendet: https://caniuse.com/mdn-html_elements_a und https://caniuse.com/mdn-html_elements_p Ich habe den Artikel entsprechend aktualisiert.

  • Bei CanIUse könnte man html-manifest vielleicht als separates Feature abspalten. Und ich möchte auch noch einmal sagen, dass MDN wirklich eine großartige Ressource ist.

  • Die erste Webseite verwendete das html-Element nicht. http://info.cern.ch/hypertext/WWW/TheProject.html

  • Hat das mit minimal gültigem HTML zu tun? Dort gibt es kein HTML-Tag.

    • Es scheint nicht wirklich damit zusammenzuhängen. `` liegt fast im selben Bereich: https://caniuse.com/mdn-html_elements_title Es wirkt eher wie die Frage, wie man Browser zählt, deren Nutzung bekannt ist, deren Unterstützung aber nicht verifiziert werden konnte. Nebenbei: Das HTML dort ist tatsächlich nicht gültig und wird als leerer Titel behandelt; ein leerer Titel ist nicht gültig. Mit etwas wie . würde es vermutlich ohne Fehler durchgehen.
    • Aber gibt es dort nicht trotzdem ein -Tag? Es ist nur nicht explizit angegeben und wird daher impliziert. In jedem Browser, mit dem man die Seite öffnet, enthält sie ein -Tag.
    • In Protokollen, in denen der Titel auf andere Weise übermittelt werden kann, etwa über den Subject-Header einer E-Mail, ist optional. Daher besteht das kürzeste gültige HTML einfach nur aus, ist allerdings nur in bestimmten Kontexten gültig.

  • Die Aussage „Viele Daten der Seite kommen von MDN“ ist etwas ungenau. Die mit CanIUse verknüpften Support-Matrizen stammen aus dem MDN-Repository browser-compat-data. Die Quelldaten für HTML-Elemente stehen hier: https://github.com/mdn/browser-compat-data/blob/main/html/el... Dort gibt es allerdings weder die Tests noch die Nutzungsinformationen, auf die CanIUse bei der Berechnung der Unterstützung verweist; enthalten ist nur, welche Browserversion welches Feature aufgenommen hat. CanIUse verweist auch auf sein eigenes Repository, und dort gibt es viele Daten: https://github.com/fyrd/caniuse Aber ich konnte keinen einfachen Einstiegspunkt finden, an dem man sieht, woher die Zahlen für bestimmte Elemente stammen. Auch dort scheinen die Daten überwiegend featurebasiert zu sein. Die präzisere Frage ist also, woher CanIUse Tests für HTML-Elemente und Nutzungszahlen bezieht, und genau das scheint der Kern des Problems zu sein.

  • Sollte die Unterstützungsquote des ``-Elements nicht mindestens kleiner oder gleich der jedes anderen Elements sein?

    • Nein. Das -Element bedeutet nicht „HTML insgesamt“, sondern ist einfach nur ein weiteres Element, das das **Wurzelelement des Dokuments** bezeichnet. Wie jemand anderes schrieb, ist es für ein fehlerfreies, gültiges HTML-Dokument tatsächlich nicht zwingend erforderlich; was man dann braucht, sind und ein gültiger Body. Als Analogie: Das Wort „English“ im Titel eines Essays korrekt zu verstehen und zu parsen ist etwas anderes, als die Bedeutung des englischen Wortes „fustigate“ zu kennen.

  • „Also gibt es keine klare Antwort. Wenn jemand sie kennt, sagt bitte Bescheid!“