separation of concerns - darstellungsbezogene Attribute nicht ins HTML reinnehmen!

[Camping_RIDER]

Aloha ;)

Der Unterschied mag klein sein, aber es ist ein prinzipieller! Attribute und Elemente treffen semantische Aussagen. Der Browser interpretiert sie. Attribute und Element reichen keine „Befehle“ an den Browser durch, sondern legen nur Rahmenbedingungen fest.

Also das ist jetzt Pfennigfuchserei. Attribute steuern verhalten. Ob das nun ein type Attribut oder ein automation Attribut ist.

Nein, das ist keine Pfennigfuchserei. Das ist eine Aussage darüber, was HTML tut und was HTML nicht tut.

Und nein, Attribute steuern kein Verhalten. Attribute machen inhaltlich/semantische Aussagen! Der Browser leitet sein Verhalten aus Attributen ab, indem er die inhaltlich/semantischen Aussagen auswertet.

Ein <input type="date"> macht eine inhaltlich/semantische Aussage, die spezifischer ist als die eines <input type="text">.

Im ersten Fall heißt das: Hier ist ein Input-Feld, in das ein Datum eingetragen werden kann, im zweiten Fall heißt das: Hier ist ein Input-Feld, in das irgendein Text eingetragen werden kann.

Das Attribut macht also eine inhaltlich/semantische Aussage.

Jetzt schauen wir mal den Vergleich von <nav> zu <nav automation="shrink-to-fit multilevel"> an:

<nav> sagt semantisch: Das was hier drin steht ist eine Navigation. <nav automation="shrink-to-fit multilevel"> sagt semantisch: Das was hier drin steht ist eine Navigation, außerdem sagt es noch: Der Browser soll das automatisiert darstellen mit den Anzeigeeinstellungen shrink-to-fit und multilevel.

Letzteres ist keine inhaltlich/semantische Aussage. Das Attribut type="date" hat eine Bedeutungsdimension auf inhaltlich/semantischer Ebene. Das Attribut automation="shrink-to-fit multilevel" hat keinerlei Bedeutungsdimension auf inhaltlich/semantischer Ebene, sondern sagt nur etwas darüber aus, wie der Browser etwas darstellen soll.

Mit dem gleichen Argument könntest du die zum Glück abgeschafften HTML-Attribute width="", height="" und so weiter verteidigen.

Nein! Zum Glück sind die weg. Wir sind doch die darstellungbezogenen Attribute erst losgeworden, da werden sicher keine neuen nachgelegt. Das wäre völliger Quatsch.

Wenn so etwas kommt wie du da vorschlägst, dann höchstens als CSS-Attribut! Denn das ist der Platz, wo darstellungsbezogene Informationen hingehören.

Wir verdanken das date input der Tatsache, dass ein Widget so ein pain in the ass ist und anderseits der Wunsch nach betriebssicheren Datum-Angaben bestand.

Nein. Wir verdanken das date input der Tatsache, dass HTML eine standardisierte Möglichkeit zur Auszeichnung von Input-Feldern bietet, die ein Datum beinhalten sollen, für die der Browser dann deshalb auch eine eingeschränktere und spezialisierte Eingabemöglichkeit zur Verfügung stellen kann.

1. Separation of concerns - das automation-Attribut sagt nichts über den Inhalt oder die Semantik aus, sondern nur über eine gewünschte Darstellung.

Es geht um Verhaltenssteuerung, auch wenn du jetzt primär nur an darstellung denkst.

Weder Verhaltenssteuerung noch Darstellung haben was im HTML zu suchen. Das HTML nimmt rein und ausschließlich semantische Auszeichnung vor.

Das Verhalten wird durch Javascript und den Browser festgelegt. Die Darstellung wird durch CSS festgelegt.

Mit dem Verhalten ist ziemlich viel konsistente Information für den User verbunden, die du anderseits erst mit aria Attributen definieren, und dann mit Javascript auch noch manipulieren müsstest.

Auch aria-Attribute sind eine rein semantisch-inhaltliche Auszeichnung. Sie sagen nicht „stell dieses Element als button dar“, sondern sie sagen „dieses Element übernimmt die Funktion eines Button“. aria-Attribute sagen nichts über das Verhalten des Useragent aus, sondern nur über die Art und Weise, wie ein Useragent das Element wahrnimmt.

Konsequenterweise müsste man hier also nicht ein neues HTML-Attribut fordern, an dem die Browser angreifen können, sondern einen neuen Wert für die CSS-Eigenschaft display! Zum Beispiel: display:navigation;.

Wir brauchen kein display:form,
wir brauchen auch kein display:details.

Du hast ganz offensichtlich nicht verstanden, was ich damit sagen will, wie deine Beispiele zeigen. Weder ein display:form noch ein display:details ergibt einen großartigen Sinn, weil weder mit form noch mit details eine bestimmte Darstellung verbunden ist. Mit einer Auslagerung der Navigation in ein eigenes Browser-UI-Element ist aber sehr wohl eine bestimmte Darstellung, nämlich in besagtem Navigations-UI-Element, verbunden.

Rein präsentationsgsbezogene Festlegungen gehören ins CSS, nicht ins HTML.

Grüße,

RIDER