separation of concerns - darstellungsbezogene Attribute nicht ins HTML reinnehmen!

[beatovich]

hallo

Richtig! Aber bin ich denn der einzige, der die Zukunft von Multi-Ebenen-Navigationen nicht zuletzt auch in details/summary sieht, sobald die zuverlässig von allen Browsern interpretiert werden?

Ich halte es für semantisch durchaus auch korrekt, einen übergeordneten Menüpunkt als <summary> für eine Liste untergeordneter Menüpunkte auszuzeichnen.

Interessanter Punkt. Aber dazu müsste man details wie folgt erweitern

Gruppen von logisch verschalteten details haben den identischen Namen. Ihr open Attribut wird im oder Prinzip gesetzt, d.h. maximal ein details Element der gleichen Gruppe ist offen. Beim Schliessen eines Details müssen alle Kind-details ebenfalls geschlossen werden.

details sind kein Zuckerschleck für Javacript.

Ich habe deshalb für genau dieses Verhalten auf eine andere Methode gesetzt.

https://beat-stoecklin.ch/klapperlogic.html

Allerdings braucht man dann dafür kein zusätzliches Attribut - der Browser sollte dann in dem Fall selbst entscheiden, ob die darstellbare Fläche ein Auslagern der Navigation aus der Seite in ein browsereigenes Interface bedingt.

<nav automation="shrink-to-fit multilevel">

Wenn der Browser die features umsetzt, wird er je nach feature, dass er aktuell auch anwendet, eine Klasse setzen. class=multilevel

Damit hast du über CSS z.B. direkt Einfluss und kannst je nach Situation innerhalb vernünftigen Rahmens spezifisches CSS schreiben.

multilevel oder matrix kann durchaus auch eine logische Komponente beinhalten (Tastaturbedienung)

Es macht schon Sinn in einer Automation über gewisse Grundverhalten eine Rücksprache mit dem Browser pflegen zu können.

Eine Automation soll dem Designer nicht alles wegnehmen, sondern das schwierige erledigen.

Auf großflächigen Bildschirmen kann ich mir kaum vorstellen, dass das wirklich Anklang findet - weder unter Seitenbetreibern noch unter Nutzern.

Wenn du jetzt den Hamburger meinst, ja klar... Es gibt eben Situationen, wo eine Navigation ausgebreitet werden darf und wo sie komprimiert werden muss.

Weit gefehlt!! type="date" hat nichts mit Präsentation zu tun, sondern ausschließlich mit semantischer Auszeichnung. Die Seite sagt damit: Dieses Input-Feld ist für ein Datum gedacht.

Die Browser nutzen diese Erkenntnis, um davon ausgehend eine spezialisierte Eingabemaske bereitzustellen. Aber nicht, weil das HTML dem Browser vorgibt, dass er hier Interaktivität bereitstellen muss, sondern weil das HTML dem Browser sagt, was an der Stelle zu erwarten ist, und der Browser selbst sagt sich dann, okay, das kann ich ja dann auch anders darstellen.

Browser können der Situation entsprechend das geeignete Widget bereitstellen. Genaus das erwarte ich von <nav automation>

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.

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.

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. 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.

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.