HTML von a bis z-z I: Back to the root

Moin, ich finde die Idee mit der neuen Serie richtig gut. Ich selbst mach Websites seit dem Ende der 90er und zähle mich eher zu den alten Hasen. Trotzdem entdecke ich immer wieder neu Details, die ich noch nicht kannte oder die mir schon wieder entfallen sind. Macht gerne weiter!

Moin,
mal alle HTML-Elemente von Grundauf durchzugehen ist eine schöne Idee. Da stolpert man immer wieder über irgendwelche Dinge bei denen man sich denkt: „Hätte ich das mal eher gewusst…“

Hier mal ein paar meiner Gedanken zum Podcast:
– Die Sprachangabe per „lang“ ist auch nötig, wenn man die Silbentrennung per CSS (hyphens: auto) nutzen will. Das funktioniert ja mittlerweile browserübergreifend, sofern man an die (korrekte) Angabe gedacht hat.
– Über „base“ und nicht mehr funktionierende Sprunganker bin ich auch mal gestolpert. Hat eine Weile gedauert bis ich den Zusammenhang erkannt hatte.
– zu Meta Description: Google sagt schon lange, dass das keinen Einfluss auf die Position in deren Suchergebnissen hat. Trotzdem sollte man die Chance nutzen dort etwas zu formulieren um den Suchenden zu animieren ausgerechnet diese Seite anzuklicken. Google entscheidet jedoch selbst ob dieser Text zur aktuellen Suchanfrage passt oder ob dort nicht besser ein anderer Text-Schnipsel der Seite stehen sollte.
– Erwähnenswert dürften hier noch die Meta Keywords sein – aber nur als Hinweis, dass man sie NICHT mehr nutzen sollte! Die sind in den Anfängen derart missbraucht worden, dass keine Suchmaschine die mehr ausliest. Sollte ein (kompetenter) SEO trotzdem mal von „Keywords“ sprechen, dürfte er allgemein „Schlüsselwörter“ meinen, die man auf der Seite finden sollte, um darunter gefunden zu werden.
– Wegen den Zwischenschaltseiten: Macht Google zwar mittlerweile anders, aber irgendwie fangen die die Klicks in den Suchergebnissen ab um diese auszuwerten.
– So gesehen hat die „Meta Description“ zumindest einen indirekten Einfluss auf die Platzierung in den Suchergebnissen: Seiten die (aufgrund des passenderen Vorschautextes) häufiger angeklickt werden, bekommen dadurch auch mehr positive Signale, die Google für die zukünftige Bewertung nutzt.

Hey Ihr Zwei,

danke wieder einmal für die Folge! Es ist eine gute Idee, sich an den HTML-Elementen entlang zu hangeln, weil sie ein guter Steigbügel ist, um von Hölzchen auf Stöckchen zu kommen. Aus dem gleichen Grund bin ich ja der Meinung, dass es mal (wieder) eine Konferenz nur über HTML geben sollte!

Zu dem lang-Attribut würde ich ergänzen wollen, dass der Browser bei fehlendem oder in einer falschen Sprache gesetzten Attribut mit seiner eingebauten Silbentrennung (CSS hyphens), dem Setzen von Anführungszeichen (CSS quotes: auto) und der Rechtschreibkorrektur (spellcheck="true") durcheinander kommt. Und man verkackt die WCAG. Daher will man das Attribut eigentlich immer setzen und das auch in der korrekten Sprache. Auch erwähnenswert ist die Tatsache, dass es sich um ein globales Attribut handelt. Das bedeutet, ich kann es auf jedes Element setzen, so dass ich damit Abschnitte im HTML auszeichnen kann, die nicht in der Sprache des Hauptdokuments verfasst sind (z.B. Englische Zitate). Eher in die Kategorie "nutzloses Wissen" fällt, dass es einen :lang-Selektor gibt, der all diejenigen Elemente erfasst, die per lang-Attribut in einer bestimmten Sprache gekennzeichnet sind (Beispiel: :lang(en)).

Das <base>-Tag habe ich früher gerne genutzt, wenn ich local entwickelt habe und ich keine Lust hatte, für jedes Projekt immer einen eigenen virtuellen Host im Betriebsystem und in Apache zu konfigurieren. Ich konnte stattdessen einfach überall mit absoluten Links arbeiten und das Root-Verzeichnis per <base> festlegen, z.B. <base href="http://localhost/projekt">.

Dass die <link>-Elemente ein disabled-Attribut unterstützen wusste ich nicht und finde ich sehr interessant! Im Sinne von: Mal sehen, wann man damit einen akrobatischen Winkelzug hinlegen kann ^^

Ansonsten würde ich ergänzen wollen, dass bei <link rel="preload"> das as-Attribut auch weggelassen werden kann. Tatsächlich aber dient es dem Browser dazu, den Request im Fluss anderer Requests anhand des Ressourcentyps korrekt einzupriorisieren. Siehe dazu diese Übersicht.

Das crossorigin-Attribut ist ein kompliziertes Ding. Man soll es in der Regel nur für Ressourcen setzen, für die der Browser auch beim Request gesetzte CORS-Header erwarten würde. Also z.B. für XHR-Requests oder für das Preloaden von Bildern, die man von anderen Origins lädt und die man dann per JavaScript und HTML Canvas auslesen möchte (wofür man das Bild dann auch mit einem crossorigin-Attribut ausstaffieren und der Origin entsprechende CORS-Header senden muss). Man sollte es aber z.B. nicht für Bilder setzen, die man von einem anderen Origin (z.B. einem CDN) einbindet und die man nur ganz passiv anzeigen möchte. Bringt man das durcheinander, lädt der Browser die Ressource doppelt, einmal mit Cross Origin aufgrund des <link rel="preload" crossorigin> und dann nochmal ohne Cross Origin aufgrund des <img>. Hier habe ich Euch eine Demo gebaut, wo Ihr im Network-Panel seht, dass bei zwei Bildern insgesamt drei Requests rausgehen.

Kuriosum: "Moderne" Typen von Ressourcen, die nach der Erfindung von CORS spezifiziert wurden, nutzen implizit alle den crossorigin-Modus, egal von wo die Ressource kommt. Das wären Schriften, aber auch Fetch()-Requests und auch <script type="module">. Das hat den Grund, dass das sicherer ist, aber für alte Legacy-Ressourcen-Typen konnte man das nachträglich nicht mehr ändern. Das bedeutet dementsprechend, dass man beim Preloaden der as-Typen font oder fetch immer auch ein gesetztes crossorigin-Attribut benötigen, damit es nicht zu doppelten Requests (und damit einem Verpuffen des Preload-Effekts) kommt. Um es entgültig kompliziert zu machen, gibt es für ES Module einen eigenen <link>–type, nämlich preloadmodule. Warum könnt Ihr hier nachlesen.

Anders als <link rel="preload"> gilt <link rel="prefetch">, wie Ihr richtig sagt, nicht für die aktuelle, sondern eine zukünftig benötigte Ressource/Seite. Was <link rel="prefetch"> allerdings nicht tut, ist diese zukünftige Ressource, wenn sie ein HTML-Dokument ist schon komplett zu rendern. Das macht <link rel="prerender">. <link rel="prerender"> gab es schon ganz lange, wurde in seiner Urversion aber wieder eingestellt und nun in Version 2 neu aus der Taufe gehoben. Was es früher gemacht hat, war die angegebene Seite in einem versteckten Tab komplett vor zu rendern. In dem Zuage wurde dann auch die Page Visibility API eingeführt, damit Analytics-Tools dann nicht schon einen Hit gemeldet haben und die Zahl der aufgerufenen Seiten verfälscht werden. Das stellte sich aber als zu ressourcenintensiv und zu nebeneffektreich heraus. Die neue Version arbeitet nun so, dass sie wie <link rel="prefetch"> arbeitet, nur dass eine HTML-Seite dann geparsed und all die darin verlinkten Ressourcen im Anschluss ebenfalls heruntergeladen werden. Gerendert wird sie aber erst, wenn sie dann auch tatsächlich aufgerufen wird, was aber dank vorliegender Ressourcen sehr schnell geht.

Die Frage nach der Notwendigkeit einer Charset-Angabe hat mich auch interessiert und ich habe folgendes herausgefunden: Ist keiner angegeben und handelt es sich um ein HTML5-Dokument, schaltet der Browser auf UTF-8. Bei älteren HTML-Doctypes ist hingegen ISO-8859-1 der Default. Außer ins HTML schaut der Browser aber auch auf den Content-Type-HTTP-Header. Wenn im HTML kein Charset angegeben wird und im Header schon, dann schaltet der Browser in den Zeichensatz, der im Header steht (beispielsweise Content-Type: text/html; charset=UTF-8).

Uffz. Ihr seht, auch mich hat dieses HTML-Alphabet stark angeregt – vong Nachdenken her 🙂

Liebe Grüße!

vom Schepp