Nachdenkliches zum Wochenende: The Cult of the Complex (Jeffrey Zeldman)

[beatovich]

hallo

Separation of concerns bedeutet im Webkonzept vereinfacht, dass HTML nur semantische Auszeichnung übernimmt (aber nichts über die weitere konkrete Darstellung/Präsentation der Inhalte aussagt), CSS nur besagte Darstellung übernimmt (Inhalte werden nur generiert soweit sie nur für die Darstellung, aber nicht für den Seiteninhalt relevant sind), während JavaScript die User-Interaktion mit der Seite bestimmt.

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

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.

Es ist auch nicht so, dass die Automation jetzt präsenationsbezogene Details einführt. Im Gegenteil.

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.

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. Featureangaben dienen nur dazu, abzufragen, ob der Browser auch mit multilevel-Angaben umgehen wird (z.B.)

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.

Du kommst also als Entwickler doch wieder nicht darum, dir die ganzen Gedanken zu machen.

Das ist der Preis der Innovation aber kein Argument gegen Innovation.

In dem Fall kannst du dir als Entwickler dann die Verwendung des fiktiven automation-Attributs dann auch wieder sparen, denn wenn du schon den Aufwand hast, dann willst du vermutlich auch, dass deine User die Navigation so zu sehen bekommen wie du sie letztendlich gestaltet hast.

Da könntest du falsch liegen, denn eine Automation kann zum Beispiel eine ganz andere Tastatur-Bequemlichkeit einführen (z.B. Pfeiltasten). Solche Automationen können schneller auch mit anderen Eingabe-Geräten umgehen. Sie können noch ganz andere APIs und Möglichkeiten anbieten (z.B. das Browserseitige Cachen und dynamische Erweitern eines ganzen Navigationsnetzes etc...).