Nutzungshäufigkeit von HTML-Elementen

Die auch heute noch bedeutende Studie namens Web Authoring Stats aus dem Jahr 2005 beschäftigt sich mit der Nutzung von HTML-Elementen (Tags) in Webseiten. Die Studie beruht auf der Auswertung von über einer Milliarde Webseiten und ist daher hochsignifikant. Sie dürfte auch heute ähnliche Ergebnisse aufzeigen, wenngleich mit geringen Verschiebungen zugunsten modernerer Standards.

Interessante und teils erschreckende Ergebnisse dieser Studie:

  • Die veralteten Tags font und b werden weitaus häufiger genutzt als die semantischen Elemente h1 oder strong.
  • Beim img-Element wird häufiger das schon lange überflüssige Attribut border genutzt, als das vorgeschriebene alt-Attribut.
  • Bei fast 50% aller Seiten mit a-Elementen wird das target-Attribut genutzt.

    Bis heute kann ich nicht überzeugend nachvollziehen, warum dieses Attribut in XHTML strict nicht mehr enthalten ist - meines Erachtens nach extrem praxisfremd und auch von der reinen Theorie her nicht richtig oder gar notwendig:
    Es ist auch inhaltlich eine Aussage und ein Unterschied, ob ich intern verlinke oder auf ein anderes Fenster oder Element verlinke. Es geht dabei nicht um Kosmetik, sondern um Funktion.

  • Die manchen "Webdesignern" offensichtlich unbekannten Elemente wie label, fieldset, abbr, blockquote werden leider extrem selten genutzt - schade, gerade das label-Element ist für die Usability in modernen Browser von Vorteil, erlaubt es doch das Anklicken des Label-Textes, um das daneben liegende Eingabefeld auszuwählen.
  • Für das interessante HTML5-Projekt sind folgende, auch in der realen Praxis schon häufig genutzte, standardisierte Klassen-Namen zur Identifikation bestimmter Bereiche einer Seite nach deren Funktion im Gespräch:
    • header
    • menu
    • nav
    • search
    • warning
    • breadcrumb
    • footer

    Klassen, die nicht Seitenbereiche, sondern einzelne Daten klassifizieren:

    • date
    • price

    Es wäre ein eleganter und vor allem abwärtskompatible Art und Weise, um alte Seiten leicht auf den propagierten Stand zu bringen. Wichtige Seitenbereiche wären damit endlich semantisch ausgezeichnet. Somit könnten zum Beispiel reine Navigationsmenüs und immergleiche Seitenheader von Suchmaschinen bei der Ermittlung der Relevanz einer Seite für ein Thema anders gewichtet werden.

    Aktuell stellen schon manche Autoren die Menüs ganz nach hinten in die Webseiten, um die Positionierung der Seite zu verbessern – diese fraglichen Mühen könnten dann besten Gewissens eingespart werden.

  • Das nutzlose Meta-Element mit dem name="revisit-after" wird nach wie vor häufig benutzt, obwohl KEINE Suchmaschine oder sonstwer es beachtet.

    Schon die Idee des Tags ist absurd, als könnte eine Suchmaschine sich auf diese Angabe verlassen. Die Suchmaschinen legen ihren Wieder-Besuchs-Intervall nach anderen, sinnvolleren Kriterien fest.

(X)HTML5 - der Ausweg?

Die Studie dient auch der Untermauerung der Arbeiten an (X)HTML5. Generell begrüße ich evolutionäre Erweiterungen der Web-Seitenbeschreibungssprache, aber diese müssen weitgehendst abwärtskompatibel sein, wenn sie eine Chance auf große Verbreitung erreichen wollen. Daher gefällt mir die Idee mit der Kennzeichnung von Seitenbereichen durch vordefinierte Klassen-Namen sehr gut.

Leider geht die WhatWG in ihren aktuellen Entwürfen zu (X)HTML5 den Weg nicht-abwärtskompatibler Änderungen.

Das input-Element zum Beispiel erhält dort einen neuen Attributwert namens email für das Attribut type – damit aber können Milliarden älterer Browser rein gar nichts anfangen.

Several new values are introduced for the type attribute. As with the older types, UAs are recommended to show specialized widgets for these types, instead of requiring that the user enter the data into a text field.

Abwärts-Kompatibilität ist der Weg!

Da nur wenige Web-Autoren sich die Mühe machen werden, Webseiten zu erstellen, die nur von einer kleinen Minderheit korrekt angezeigt werden können, ist der Weg, der mit XHTML5 gegangen werden soll, meines Erachtens zum Scheitern verurteilt. Den Aufwand, zwei verschiedene Templates zu pflegen, und diese browser-abhängig per Content Negotiation unterschiedlich auszuliefern, wird kein Auftraggeber bezahlen wollen – zu Recht.

Wenn Erweiterungen eine Chance auf Durchsetzung genießen möchten, dann nur, wenn sie auch auf älteren oder weniger leistungsfähigen Browsern wie auf einem PDA oder in einem Handy-Browser korrekt dargestellt werden können.

Neue, zusätzliche Attribute als eine abwärtskompatible Erweiterung für bestehende Tags wären dagegen ein gangbarer Weg. Neue Elemente oder breaking-changes in Attributwerten dagegen sind der Tod jeglicher Neuerung. Die Attribute class und id haben sich z.B. sehr gut durchgesetzt – weil sie eben von älteren Browsern ignoriert wurden und Webautoren diese gefahrlos einsetzen konnten, ohne sämtliche Besucher mit älteren Browsern auszusperren.