separation of concerns - darstellungsbezogene Attribute nicht ins HTML reinnehmen!

[Camping_RIDER]

Aloha ;)

Anmerkung: das tl;dr findet sich ganz unten im letzten Satz.

Nunja, in welche Richtung die Standards sich bewegen ist erst mal nicht so klar. Die Tendenz, die Selbständigkeit von Html zu erhalten, ist dokumentiert in solchen Dingen wie pattern und der ganzen Logik, die ohne eine Zeile JS auskommt.

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.

Das geht in die gleiche Richtung, bleibt aber für mein Empfinden viel näher an den aktuellen Entwicklungen dran als die Vorstellung, dass ein Seitenteil durch den Browser aus dem Seitenkontext gelöst und separat dargestellt wird.

Man darf durchaus sagen, dass das Bestreben schwieriges leicht zu machen gerade in Formularen deutlich wird. Durch die Gerätevielfalt ist nun eine neue Schwierigkeit und ein Problem erwachsen. Javascript ist nicht mehr eine Option. Deshalb passt auch hier, das schwierige (eine Navigation für alle Geräte) in die Entwicklung von Html hinein.

Auch da stimme ich dir zu. Bei Geräten mit sehr eingeschränktem Bildschirmplatz wird eine entsprechende Herauslösung aus dem Seitenkontext auch kein als störend wahrgenommener Eingriff sein.

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.

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

Dieser Grundsatz wurde in den vergangenen Jahren auch in den Standards immer mehr in den Fokus gerückt, zum Beispiel durch den Wegfall präsentationsbezogener Attribute und Elemente aus dem HTML-Standard.

Das hat man aber nur gemacht, weil es in CSS einen besseren Ersatz schon lange gab.

Nein, nicht nur. Man hätts ja trotzdem drinlassen können. Nein, die Entfernung, bzw. Umdefinition, wurde aktiv unternommen mit einer klaren Zielsetzung: Präsentationsbezogenheit raus, semantische Bedeutung rein. Das ist eine ganz klare Umsetzung der separation of concerns als Konzept.

Wieder kann ich type=date anführen um zu zeigen, wie eben automation und Browser-definierte Präsentation durchaus in der Entwicklung in html auch vorhanden sind. Der Browser "präsentiert" invalide Feldwerte ohne eine Zeile CSS.

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.

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.

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

Nein, grundsätzlich sagt es aus, dass die Darstellung dem Browser überlassen wird.

Eben, es sagt aus, dass die Darstellung dem Browser überlassen wird. Erstens ist das sowieso immer der Fall. Die Darstellung wird immer dem Browser überlassen. Zweitens ist das, wenn es implizit gesagt wird, im Sinne von "Der Browser soll das hier anders, in einem eigenen Bereich darstellen" eben das: eine Aussage über die Darstellung!

Dafür ist aber eigentlich CSS zuständig. 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;.

Diese präsentationsbezogene Angabe kann der Browser dann zur Darstellung der Navigation, z.B. in einem nativen/eigenen Fensterbereich, nutzen.

2. Du sagst ja schon selbst: „Ich habe einfach eine Fallback-Navigation vorzusehen“. So, nun muss aber meine Fallback-Navigation ja auch bedienbar sein, um keine Nutzer auszuschließen, und du willst natürlich auch nicht, dass das Fallback aussieht wie Grütze.

Es gab immer wieder längere Implementationsfristen in welchen Fallbacks notwendig waren. Schliesslich wird aber eine Implementationsreife erreicht, so dass diese aufgegeben werden können. Einige Komponenten von jQuery-UI erscheinen heute obsolet.

Gut, ACK. - Und die von dir genannten Vorteile sehe ich auch ein.

Aber wie gesagt: Separation of concerns! Keine HTML-Erweiterung, sondern eine CSS-Erweiterung ist hier gefragt! Die könnte dann auch mit den nativen Möglichkeiten von CSS explizit bei bestimmten Bildschirmgrößen genutzt werden.

Grüße,

RIDER