Nachdenkliches zum Wochenende: The Cult of the Complex (Jeffrey Zeldman)
Gunnar Bittersmann
- lesetipp
0 pl0 Henry
Jeffrey Zeldman hat einen lesenswerten Artikel auf A List Apart veröffentlicht: The Cult of the Complex
Einige Gedanken daraus:
“It’s the people who use the stuff we design who suffer from our uninformed or lazy over-reliance on these div-ridden gassy tools. And that suffering is what we protest.”
“HR folks who write job descriptions listing the ten thousand tool sets you’re supposed to know backwards and forwards to qualify for a junior front-end position don’t help the situation.”
“CSS is not broken, and it’s not too hard.”
“I am baffled and numbed by the growing preference for complexity over simplicity. Complexity is good for convincing people they could not possibly do your job. Simplicity is good for everything else.”
LLAP 🖖
- “HR folks who write job descriptions listing the ten thousand tool sets you’re supposed to know backwards and forwards to qualify for a junior front-end position don’t help the situation.”
Das liegt daran daß HR folks zum Produkt überhaupt keine Beziehung mehr haben. Wie schrieb doch Heinrich Böll mal so schön: <cite>Es ist etwas geschehen. Ich habe gekündigt! Zeit darüber nachzudenken was in dieser Firma eigentlich produziert wurde. Wahrscheinlich Seife.</cite>
Danke Heinrich. Hab Dich alles gelesen. Damals vor 30..40 Jahren.
MfG
Ahja, hier ist sie ja, eine handlungsstarke Geschichte 😉
Danke Heinrich!
PS: Der Name des Fabrikbesitzers ist hoffentlich nur zufällig ähnlich mit dem Namen einer Stadt im Fichtelgebirge/Ofr. Also ch hätten den wahrscheinlich einen anderen Namen gegeben, Ochsenkopf z.B.
Hej pl,
Ahja, hier ist sie ja, eine handlungsstarke Geschichte 😉
Danke Heinrich!
Danke dir für den schönen Böll-Text!
Marc
he danke für Dein Feedback!
Noch eine kleine Anektode: Irgendwann in den 80ern, Böll wollte mal nach Erfurt kommen. Angesichts des Stasi-Aufgebots auf dem Bahnsteig machte er auf der Stelle kehrt und fuhr mit dem nächsten Zug zurück.
Denn die Mächtigen fürchteten sich vor dem Volk denn es hielt ihn für einen Propheten...
Schönen Sonntag 😉
MfG
Hallo Gunnar,
Jeffrey Zeldman hat einen lesenswerten Artikel auf A List Apart veröffentlicht: The Cult of the Complex
in der Tat, danke. Sofern ich das richtig verstehe, bin ich da komplett der gleichen Ansicht.
Einige Gedanken daraus:
- “I am baffled and numbed by the growing preference for complexity over simplicity. Complexity is good for convincing people they could not possibly do your job. Simplicity is good for everything else.”
Aber offen gestanden, wundert mich ein wenig, dass gerade du das postest. Denn die Einfachheit vor den komplexen Lösungen zu stellen und Semantik nicht als essentiell zu proklamieren (wie gesagt, sofern ich das alles richtig dort verstehe), ist ja nicht unbedingt in diesem Forum so beliebt. Insbesondere…
A backlash in defense of divs followed this meaningless running-down of them—as if the W3C had created the div as a forbidden fruit. So, let’s be clear. No HTML element is bad. No HTML element is good. A screwdriver is neither good nor bad, unless you try to use it as a hammer. Good usage is all about appropriateness.
Divs are not bad. If no HTML5 element is better suited to an element’s purpose, divs are the best and most appropriate choice. Common sense, right?
*Mal Anregung @admins, falls es das noch nicht gibt, könnte man nicht Fremdzitate ähnlich der normalen Zitate, nur in anderer Farbe hinzufügen, immer etwas verwirrend, nehme deshalb nur kursiv.
… die immer wiederkehrende Belehrung kein Div zu nehmen, sondern spezielle Elemente, ist ja allzu oft hier zu finden.
Gruss
Henry
Hallo Henry,
*Mal Anregung @admins, falls es das noch nicht gibt, könnte man nicht Fremdzitate ähnlich der normalen Zitate, nur in anderer Farbe hinzufügen,
Die Idee finde ich gut.
Bis demnächst
Matthias
Aloha ;)
- “I am baffled and numbed by the growing preference for complexity over simplicity. Complexity is good for convincing people they could not possibly do your job. Simplicity is good for everything else.”
Aber offen gestanden, wundert mich ein wenig, dass gerade du das postest. Denn die Einfachheit vor den komplexen Lösungen zu stellen und Semantik nicht als essentiell zu proklamieren (wie gesagt, sofern ich das alles richtig dort verstehe), ist ja nicht unbedingt in diesem Forum so beliebt.
Ich habe den verlinkten Artikel nicht gelesen, aber zumindest im hier dargestellten Zitat ist nichts von "Semantik nicht als essentiell zu proklamieren" zu lesen.
Ich bin mir auch nicht sicher, ob du da ganz richtig verstanden hast, was Zeldman möchte.
Einfache Lösungen müssen schon auch Lösungen sein.
Ich wüsste nicht, wo hier im Forum komplexe Lösungen einfachen Lösungen vorgezogen werden.
Mir fallen aber tausend Beispiele ein, in denen ein Fragesteller meint, es gäbe eine einfache Lösung auf ein Problem, weil er die Komplexität des Problems noch nicht verstanden hat. So zum Beispiel neulich im Thread zur Multi-Ebenen-Navigation.
Das ist aber genau nicht wovon Zeldman spricht.
Zeldman spricht, wenn ich ihn richtig verstehe, davon, dass manchenorts propagiert wird, dass man erst drölf Javascript-Frameworks erlernen muss, bevor man dann Dinge realisieren kann, die auch mit drei Zeilen Vanilla-Javascript erledigt wären. Das ist die Form von „Komplexität zur reinen Joberhaltung“ wie sie mir zumindest aus obigem Zitat entgegenkommt.
Divs are not bad. If no HTML5 element is better suited to an element’s purpose, divs are the best and most appropriate choice. Common sense, right?
… die immer wiederkehrende Belehrung kein Div zu nehmen, sondern spezielle Elemente, ist ja allzu oft hier zu finden.
Eben. Genauso wie bei Zeldman. Du zitierst doch selbst schon die richtige Stelle:
If no HTML5 element is better suited to an element’s purpose, divs are the best and most appropriate choice.
Wir empfehlen, wie du schon selbst sagst, immer, spezielle Elemente zu nehmen. Das setzt voraus, dass es sie gibt. Wenn es keine gibt, ist div völlig okay.
So what?
Grüße,
RIDER
hallo
Wir empfehlen, wie du schon selbst sagst, immer, spezielle Elemente zu nehmen. Das setzt voraus, dass es sie gibt. Wenn es keine gibt, ist div völlig okay.
Entweder Elemente haben eine echte Funktion oder sie sind so gut wie neutrale Elemente. html5 Hat das repertoire an Elementen mit eher esoterischen Rollen eingebracht.
Echte Browserunterstüzte Funktionalität wäre angebracht. Dass man nach 20 jahren <nav> schreiben darf, aber keine <nav> bekommt, halte ich für ziemlich lächerlich. Aber man soll ja die Hoffnung nie aufgeben.
Aloha ;)
Wir empfehlen, wie du schon selbst sagst, immer, spezielle Elemente zu nehmen. Das setzt voraus, dass es sie gibt. Wenn es keine gibt, ist div völlig okay.
Entweder Elemente haben eine echte Funktion oder sie sind so gut wie neutrale Elemente. html5 Hat das repertoire an Elementen mit eher esoterischen Rollen eingebracht.
Du nennst das esoterisch, andere nennen es semantisch.
Echte Browserunterstüzte Funktionalität wäre angebracht. Dass man nach 20 jahren <nav> schreiben darf, aber keine <nav> bekommt, halte ich für ziemlich lächerlich. Aber man soll ja die Hoffnung nie aufgeben.
Da sowieso jeder seine Navigation so darstellt wie er das grad möchte und sie überdies fest in seiner Seite integriert hat, ist eine browserunterstützte Funktionalität für viele sicher gar nicht erstrebenswert.
Semantische Auszeichnung bedeutet viel mehr als nur ein Mittel dazu zu sein, den Browser zu einer bestimmten Darstellung zu bringen.
Grüße,
RIDER
hallo
Da sowieso jeder seine Navigation so darstellt wie er das grad möchte und sie überdies fest in seiner Seite integriert hat, ist eine browserunterstützte Funktionalität für viele sicher gar nicht erstrebenswert.
Aha, du findest das also toll, wenn ich auf Seite A mit Maus, auf Seite B mit Tab und auf Seite C ach Überraschung mit Pfeiltasten navigieren kann/muss.
Semantische Auszeichnung bedeutet viel mehr als nur ein Mittel dazu zu sein, den Browser zu einer bestimmten Darstellung zu bringen.
Ja, höchstwahrscheinlich fällt da in China sogar ein Sack Reis um.
Weist du, was für input type=date gilt, düfte wohl auch für nav gelten. Ich hätte auf jeden Fall nichts dagegen, echte Browserunterstützung für etwas zu bekommen, das allen Webautoren immer wieder Kopfzerbrechen macht. Eventuell könnte ich am Ende ja sogar dadurch auf einer Site Javascript ganz deaktivieren.
Aloha ;)
Da sowieso jeder seine Navigation so darstellt wie er das grad möchte und sie überdies fest in seiner Seite integriert hat, ist eine browserunterstützte Funktionalität für viele sicher gar nicht erstrebenswert.
Aha, du findest das also toll, wenn ich auf Seite A mit Maus, auf Seite B mit Tab und auf Seite C ach Überraschung mit Pfeiltasten navigieren kann/muss.
Was ich toll finde spielt hier gar keine Rolle. Im Übrigen auch nicht was du toll findest. Tatsache ist, dass sich Webseitenbetreiber die individuelle Gestaltung ihrer Navigation nicht nehmen lassen werden. Und deshalb werden die Browser sie auch nicht anbieten.
Wie soll ein Browser das auch machen? Die Navigation aus dem Seitenkontext nehmen und selbst darstellen? Das ist ein großer Eingriff in das Design der Seite.
Sowas kann ein Browser-Plugin, das man sich bewusst installieren muss, vielleicht tun.
Wäre das in einem Browser der Normalfall, würden zwei Dinge passieren:
a) Abwanderung von Usern, die den Sinn nicht verstehen und sich fragen warum die Seiten auf einmal nicht mehr aussehen wie sie sollten
b) Webseitenbetreiber verwenden dann in Zukunft wieder <div>
statt <nav>
, um weiterhin ihre Navigation selbst gestalten zu können.
Und wer gewinnt daran deiner Meinung nach?
Du auch nicht, denn dein Browser kann das <nav>
nicht mehr benutzen, wenn überall wieder flächendeckend <div>
genutzt wird.
Semantische Auszeichnung bedeutet viel mehr als nur ein Mittel dazu zu sein, den Browser zu einer bestimmten Darstellung zu bringen.
Ja, höchstwahrscheinlich fällt da in China sogar ein Sack Reis um.
Ja, und vielleicht stellt sich danach heraus, dass es ein Sack voll Ming-Vasen war, der halt blöderweise falsch ausgezeichnet war.
Eventuell könnte ich am Ende ja sogar dadurch auf einer Site Javascript ganz deaktivieren.
Scheint dir das ein allgemeingültig als sinnvoll gesehenes Argument zu sein in Zeiten, in denen die Browser das Abschalten von Javascript aus ihrem Standardumfang entfernt haben?
Ich will dich nicht davon abhalten, deine persönlichen Interessen zu verfolgen. Wenn du findest das alles sei erstrebenswert, dann darfst du das gerne persönlich so finden. Aber wenn du eigentlich schon weißt, dass das nicht mehrheitsfähig oder ein allgemeines Interesse ist, dann stells doch bitte nicht so dar als wär es so...
Grüße,
RIDER
hallo
Aloha ;)
Da sowieso jeder seine Navigation so darstellt wie er das grad möchte und sie überdies fest in seiner Seite integriert hat, ist eine browserunterstützte Funktionalität für viele sicher gar nicht erstrebenswert.
Aha, du findest das also toll, wenn ich auf Seite A mit Maus, auf Seite B mit Tab und auf Seite C ach Überraschung mit Pfeiltasten navigieren kann/muss.
Was ich toll finde spielt hier gar keine Rolle. Im Übrigen auch nicht was du toll findest. Tatsache ist, dass sich Webseitenbetreiber die individuelle Gestaltung ihrer Navigation nicht nehmen lassen werden. Und deshalb werden die Browser sie auch nicht anbieten.
Ach nun sei doch nicht so phantasielos
<nav automation="shrink-to-fit; multilevel">
Du kannst auch immer noch deinen eigenen Datums-picker gestalten.
Wie soll ein Browser das auch machen? Die Navigation aus dem Seitenkontext nehmen und selbst darstellen? Das ist ein großer Eingriff in das Design der Seite.
Nicht, wenn ich es wünsche. Wir haben uns in anderen Bereichen daran gewöhnt, dass Browser Funktionen einsetzen, und die Styling-Freiheiten einschränken. Konsistentes Verhalten über Webseiten hinweg wird in der Regel als vorteilhaft betrachtet.
Sowas kann ein Browser-Plugin, das man sich bewusst installieren muss, vielleicht tun.
Einige gute Dinge haben als Plugin angefangen (Firebug)
Und wer gewinnt daran deiner Meinung nach?
Die Navigationsanwender!
Aloha ;)
Ach nun sei doch nicht so phantasielos
<nav automation="shrink-to-fit; multilevel">
Du kannst auch immer noch deinen eigenen Datums-picker gestalten.
Datums-picker, d.h. einzelnes atomares Eingabeelement vs. Navigation, d.h. elementarer Teil einer jeden Seite, oft im Vergleich zum Rest der Seite sehr aufwändig gestaltet und wichtiges Element im Seitendesign.
Kein sehr passender Vergleich.
Und wie passt eigentlich deine automation
-Angabe zur separation of concerns?
Da bleiben für mich viele Fragezeichen (die wir hier und jetzt weder aufdröseln müssen noch aufdröseln können).
Einige gute Dinge haben als Plugin angefangen (Firebug)
Richtig. Ich habe auch nichts gegen Plugins.
Und wer gewinnt daran deiner Meinung nach?
Die Navigationsanwender!
Das bleibt ja dann noch zu sehen, ob das wirklich so ist. Spätestens nach der in dem Fall zu erwartenden <nav>
-Flucht derer, die sich ihr unbedienbares Design nicht nehmen lassen wollen, sicherlich nicht mehr.
Grüße,
RIDER
Hallo Camping_RIDER,
Och, ich finde die Idee mindestens charmant, dass eine verschachtelte Liste innerhalb eines nav-Elementes ohne weiteres Zutun für jedermann bedienbar wäre.
Bis demnächst
Matthias
@@Matthias Apsel
Och, ich finde die Idee mindestens charmant, dass eine verschachtelte Liste innerhalb eines nav-Elementes ohne weiteres Zutun für jedermann bedienbar wäre.
Das sind sie doch – solange man nicht mit CSS oder JavaScript was dagegen tut. 😜
SCNR. Mir ist schon klar, dass du sowas Klappbares in der Art meintest, wie es für menu
/menuitem
mal vorgesehen war.
LLAP 🖖
hallo
Datums-picker, d.h. einzelnes atomares Eingabeelement vs. Navigation, d.h. elementarer Teil einer jeden Seite, oft im Vergleich zum Rest der Seite sehr aufwändig gestaltet und wichtiges Element im Seitendesign.
Tatsächlich, so wichtig, dass man dessen Funktionalität nicht dem Zufall überlassen sollte.
Kein sehr passender Vergleich.
Und wie passt eigentlich deine
automation
-Angabe zur separation of concerns?
Ich versuche mich mal an einer Übersetzung: Trennung von Zuständigkeit
Hier ist sie:
<nav> = deine Sache
<nav automation="featurelist"> = Browser-Sache
Ein Browser der das nicht versteht, wird <nav> verstehen. Ich habe in dem Fall einfach eine Fallback-Navigation vorzusehen.
Da bleiben für mich viele Fragezeichen (die wir hier und jetzt weder aufdröseln müssen noch aufdröseln können).
Ich will gar nicht wissen, wieviele Detailprobleme bei so etwas einfachem wie type=date gelöst wurden.
Und wer gewinnt daran deiner Meinung nach?
Die Navigationsanwender!
Das bleibt ja dann noch zu sehen, ob das wirklich so ist. Spätestens nach der in dem Fall zu erwartenden
<nav>
-Flucht derer, die sich ihr unbedienbares Design nicht nehmen lassen wollen, sicherlich nicht mehr.
Ich will dir sicher nichts wegnehmen. Aber wir dürfen ja mal progressive Enhancement erwähnen, ohne dabei gleich (vielen Dank WAI-ARIA) die Javascript-Kanone zu bemühen.
Aloha ;)
Und wie passt eigentlich deine
automation
-Angabe zur separation of concerns?Ich versuche mich mal an einer Übersetzung: Trennung von Zuständigkeit
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.
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.
Hier ist sie:
<nav> = deine Sache
<nav automation="featurelist"> = Browser-Sache
Ein Browser der das nicht versteht, wird <nav> verstehen. Ich habe in dem Fall einfach eine Fallback-Navigation vorzusehen.
Soweit so verständlich. Deine Idee hat ja auch einen gewissen Charme. Ich seh aber immer noch zwei Probleme, die sich nicht einfach wegdiskutieren lassen:
Separation of concerns - das automation-Attribut sagt nichts über den Inhalt oder die Semantik aus, sondern nur über eine gewünschte Darstellung. Das ist aber nicht in welche Richtung sich die Standards im Moment entwickeln, würde mich also eher verwundern. Aber nun gut, bei <select size="1">
gilt natürlich das selbe und auch das ist nach wie vor valides HTML.
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. Du kommst also als Entwickler doch wieder nicht darum, dir die ganzen Gedanken zu machen. 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.
Grüße,
RIDER
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.
- 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.)
- 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...).
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.
- 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.
- 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
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.
- 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.
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.
- 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
hallo
Ich sehe, du bist nicht aufgeschlossen.
Ich habe dir gesagt: Wir haben kein display:details.
Und denoch dient das essentielle von Details genau der Präsentation, nicht dem wie sondern dass es präsentiert wird. Genau darum kann es bei automatisierter Navigation auch gehen.
Aloha ;)
Ich sehe, du bist nicht aufgeschlossen.
Sicher, dass ich dir nicht zuhöre?
Ich habe dir gesagt: Wir haben kein display:details.
Und denoch dient das essentielle von Details genau der Präsentation, nicht dem wie sondern dass es präsentiert wird. Genau darum kann es bei automatisierter Navigation auch gehen.
Nein. Nochmal: HTML ist eine Auszeichnungssprache. Sie ist für semantische Auszeichnung, also den Transport inhaltlich/semantischer Spezifizierungen da.
Details und Summary haben eine inhaltlich/semantische Aussage in der Form: „Hier stehen ausführliche Informationen und es handelt sich um ein Element, das User-Interaktion ermöglicht“, „Da gibt es etwas, was die Inhalte zusammenfasst“. Das „open“-Attribut gibt an, dass dem User die ausführlichen Informationen zur Verfügung gestellt werden sollen; fehlt es, soll der User nur die Zusammenfassung zur Verfügung gestellt bekommen.
Die Browser verstehen dank der inhaltlich/semantischen Aussage wie die Inhalte zueinander in Bezug stehen und wählen anhand dessen eine Darstellung.
Wäre „das essentielle“ von Details tatsächlich die Präsentation, dann müsste die ja irgendwo festgelegt sein. Die HTML-Spezifikation legt aber gar nicht fest, wie genau der Browser das darzustellen oder in welcher Form er die Interaktivität herzustellen hat. Ein Screenreader kann genauso eine ganz andere Präsentation anbieten.
Aber selbst wenn du nicht einsiehst, warum das von dir vorgeschlagene Attribut nichts im HTML-Standard zu suchen hat - eben genauso wenig wie width und height:
Nenn mir doch mal bitte einen Grund, warum ein HTML-Attribut einer CSS-Eigenschaft für diesen Zweck vorzuziehen sei.
Grüße,
RIDER
hallo
Nein. Nochmal: HTML ist eine Auszeichnungssprache. Sie ist für semantische Auszeichnung, also den Transport inhaltlich/semantischer Spezifizierungen da.
Details und Summary haben eine inhaltlich/semantische Aussage in der Form: „Hier stehen ausführliche Informationen und es handelt sich um ein Element, das User-Interaktion ermöglicht“,
und inwiefern widerspricht das
<nav autommation>
Der Inhalt sind Navigationsitems und die Useraktion ist standardisiert?
Aber selbst wenn du nicht einsiehst, warum das von dir vorgeschlagene Attribut nichts im HTML-Standard zu suchen hat - eben genauso wenig wie width und height:
Nenn mir doch mal bitte einen Grund, warum ein HTML-Attribut einer CSS-Eigenschaft für diesen Zweck vorzuziehen sei.
Nenne mir einen Grund, warum du automation NUR als CSS-eigenschaft verstehen kannst...
Ich laste dir sicher nicht Uneinsichtigkeit an, sondern ganz einfach Phantasielosigkeit.
Dir muss man erst mal usecases zeigen, um dich zu überzeugen.
Aloha ;)
Details und Summary haben eine inhaltlich/semantische Aussage in der Form: „Hier stehen ausführliche Informationen und es handelt sich um ein Element, das User-Interaktion ermöglicht“,
und inwiefern widerspricht das
<nav autommation>
Insofern, dass das von dir vorgeschlagene automation-Attribut keine inhaltlich/semantische Aussage macht, sondern nur eine präsentationsbezogene.
Wie ich übrigens auch schon etwa drölf mal gesagt habe.
Aber selbst wenn du nicht einsiehst, warum das von dir vorgeschlagene Attribut nichts im HTML-Standard zu suchen hat - eben genauso wenig wie width und height:
Nenn mir doch mal bitte einen Grund, warum ein HTML-Attribut einer CSS-Eigenschaft für diesen Zweck vorzuziehen sei.
Nenne mir einen Grund, warum du automation NUR als CSS-eigenschaft verstehen kannst...
Spielen wir hier Ping-Pong?
Ich verstehe deine "automation" als CSS-Eigenschaft, weil die automation nur eine präsentationsbezogene Aussage macht, und es ist nunmal die Aufgabe von CSS-Eigenschaften, präsentationsbezogene Aussagen zu machen.
So, jetzt du.
Ich laste dir sicher nicht Uneinsichtigkeit an, sondern ganz einfach Phantasielosigkeit.
Dir muss man erst mal usecases zeigen, um dich zu überzeugen.
Nein. Den usecase der dir vorschwebt sehe ich sehr genau. Ich glaube nur, dass du die Frage, ob das was dir da vorschwebt, CSS oder HTML sein sollte, konzeptionell nicht genau genug durchdacht hast.
Grüße,
RIDER
hallo
Insofern, dass das von dir vorgeschlagene automation-Attribut keine inhaltlich/semantische Aussage macht, sondern nur eine präsentationsbezogene.
Ich habe nichts mehr zu sagen...
Ich verstehe deine "automation" als CSS-Eigenschaft, weil die automation nur eine präsentationsbezogene Aussage macht, und es ist nunmal die Aufgabe von CSS-Eigenschaften, präsentationsbezogene Aussagen zu machen.
Nein, mit automation ist sehr viel Interaktionsfähigkeit und Robustheit verbunden.
Nein. Den usecase der dir vorschwebt sehe ich sehr genau.
Eben, deine Phantasie reicht nicht soweit. Sag ich doch.
Hallo Camping_RIDER,
Das bleibt ja dann noch zu sehen, ob das wirklich so ist. Spätestens nach der in dem Fall zu erwartenden
<nav>
-Flucht derer, die sich ihr unbedienbares Design nicht nehmen lassen wollen, sicherlich nicht mehr.
Das meinte ich hier mit "solche Ansichten nicht sehr beliebt" 😉
Unbedienbares Design? och komm, da muss man schon wirklich viel verkehrt machen und erst recht nicht nur Empfehlungen missachten.
Ich weiß auch immer noch nicht genau, wie ich den Artikel deuten soll. Zeldman schreibt, dass sie früher immer Semantik, Elementenvorgaben usw. gepredigt haben rudert dann aber zumindest mit den Elementen wieder etwas zurück, so dass ich nicht sicher bin ob das dann auch insgesamt für die früheren Predigten in allerlei Richtung(einschließlich Semantik) gilt.
Aber für wen ist die Semantik denn gut? Ja ich weiß schon was jetzt kommt, aber hatte da ja schon mal eine Bitte an Gunnar in Bezug auf Marko Zehe geäußert. Wenn ich Semantik haben möchte, baue ich eine XML-Datei. Hier scheint Semantik aber zu bedeuten, jede aktuelle Neuerung in der Auszeichnung muss genutzt werden, weil sonst ist es nicht semantisch/unbedienbar. Seltsam daran aber, dass vor der jeweiligen Neuerung die alte Vorgehensweise dann doch semantisch war. Aber das ist ja doch immer eine Diskussion hier ohne Resultat, daher nochmal die Bitte an dich @Gunnar Bittersmann (sozusagen sowieso als Barrierefreibotschafter hier) zum Statement/Artikel eines z.b. Marco Zehe.
Im Moment, solange Betroffene mich nicht eines Besseren belehren, sehe ich das ähnlich @beatovich, warum ein paar Links, die sich wunderbar über CSS formen lassen, so umständlich verpacken? (Ja, ich machs zwar auch so aber nur weil's erwartet wird)
<nav class="topnav">>
<ul>
<li><a href="">link</a></li>
<li><a href="">link</a></li>
<li><a href="">link</a></li>
<li><a href="">link</a></li>
</ul>
<nav>
Wir nehmen eine Liste, verändern meist komplett die Vorgabewerte, wie sie eigentlich gedacht ist…
Dabei geht's eigentlich ja auch so:
<div class="topnav">
<a class="active" href="#home">Home</a>
<a href="#news">News</a>
<a href="#contact">Contact</a>
<a href="#about">About</a>
</div>
Quelle: https://www.w3schools.com/howto/howto_js_topnav.asp
Gruss
Henry
Aloha ;)
Die Antwort ist etwas länger geraten. Ich gliedere sie mal auf - für alle Mitleser.
#Wie schnell ein Design unbedienbar wird#
Unbedienbares Design? och komm, da muss man schon wirklich viel verkehrt machen und erst recht nicht nur Empfehlungen missachten.
Ist das so? Ich sehe mich ausnahmsweise @Gunnar Bittersmann wirklich beipflichten: Ein „Design“, das nicht tastaturbedienbar und klick-/touchbedienbar ist, ist unbedienbar - zumindest für denjenigen, der nur die fehlende der drei Bedienoptionen zur Verfügung hat.
Und wie wir gesehen haben ist es gar nicht so einfach, ein Menü so zu bauen, dass es diesem Anspruch genügt - zumindest dann, wenn man untergeordnete Ebenen im Menü ausblenden will.
Dabei ist es dann verlockend, es sich einfach zu machen und entweder Tastaturbedienbarkeit oder Klick-/Touchbedienbarkeit über Bord zu werfen. Passiert auf tausend Webseiten da draußen. Und ist unglaublich ärgerlich, wenn man mal wieder mit dem Mobil-Browser unterwegs ist.
Man muss nicht wirklich viel verkehrt machen, um ein (für einige User) unbedienbares Design zu erhalten.
#Was hat Semantik mit HTML zu tun#
Aber für wen ist die Semantik denn gut?
Ähm. Wir sprechen hier über die Hypertext Markup Language. Markup, so wie in Auszeichnung, so wie in semantische Auszeichnung. Semantische Auszeichnung ist der (im ursprünglichen Sinn einzige!) Sinn und Zweck von HTML.
Wenn ich Semantik haben möchte, baue ich eine XML-Datei.
HTML und XML sind verwandt. Und weißt du was? Auch in XML steckt das Wort Markup. Fällt dir was auf?
#Was Semantik bedeutet und was unsemantisch bedeutet#
Hier scheint Semantik aber zu bedeuten, jede aktuelle Neuerung in der Auszeichnung muss genutzt werden, weil sonst ist es nicht semantisch/unbedienbar.
Nein. Semantik bedeutet, dass man versucht, für jeden Inhalt anhand der vorhandenen Auszeichnungsmöglichkeiten eine möglichst sinnstiftende Auszeichnung zu finden.
Divs für tabellarische Daten zu verwenden ist unsemantisch, denn es gibt mit den Tabellenelementen eine sinnstiftendere Auszeichnung. Eine DIV für den Hauptinhalt der Seite zu verwenden ist unsemantisch, denn es gibt mit main ein sinnstiftenderes Element.
Ja, das bedeutet, dass man in dem Moment, in dem man HTML schreibt, sich aller verfügbarer Elemente bedient, um möglichst sinnstiftende Elemente zu finden. Alles andere ist unsemantisch.
Nein, das bedeutet nicht, dass eine Seite unbedienbar ist. Nicht jede perfekt semantische Seite ist unbedienbar und es gibt auch semantisch perfekte, aber unbedienbare Seiten.
Seltsam daran aber, dass vor der jeweiligen Neuerung die alte Vorgehensweise dann doch semantisch war.
Wie gesagt, semantische Auszeichnung hat immer damit zu tun, die möglichst akkurate Auszeichnung unter den aktuell verfügbaren Auszeichnungsmöglichkeiten zu finden.
Semantik ist doch schon an sich ein Begriff, der im Kontext „Sprache“ definiert ist. Das, was in einer Sprach(-version|-e) semantisch ist, mag in einer anderen Sprach(-version|-e) unsemantisch sein.
Frühere HTML-Versionen waren statisch versioniert. Da konnten keine Elemente dazu kommen und daher hat sich der Grad der Semantik bei einmal semantisch ausgezeichneten Texten auch nie wieder verändert - bezogen auf die Sprachversion, in der ausgezeichnet wurde.
HTML5 ist ein „living standard“. Das Hinzukommen neuer Elemente und damit die graduelle Abnahme des Grads der Semantik bei einem einmal semantisch ausgezeichneten Text in Bezug auf die Sprachversion, in der ausgezeichnet wurde, ist damit selbstverständlich und wohnt dem HTML-Standard inne.
#Wozu eigentlich Semantik#
Aber für wen ist die Semantik denn gut?
Semantik gibt einem Text eine Struktur und einen Sinn, der erfassbar ist, auch wenn man den Text nicht versteht. Das hilft ganz konkret allen automatischen Verarbeitern: Suchmaschinen, Browser, Screenreader …
Semantisch ausgezeichneter Text macht das gesamte WWW aus und trägt in höchstem Maße dazu bei, dass Webseiteninhalte für alle verständlich sind - nicht nur für die, an die bei der Erstellung im Speziellen gedacht wurde. HTML und seine Semantik stellen sicher, dass ohne jedes CSS oder Javascript immer so klar wie möglich ist, um was für Inhalte es sich handelt. Davon profitieren letztlich alle Internet-Benutzer.
Du hast im verlinkten Beitrag die Frage gestellt, warum es semantisch besser sein soll, <main>
zu verwenden statt <div id="main">
. Das ist eine berechtigte Frage. Ich möchte dir die Antwort mit einem Vergleich näher bringen.
Sagen wir, die zugrundeliegende Sprache ist Deutsch. Du möchtest über ein Quadrat sprechen. Nun hast du mehrere Möglichkeiten, das zu tun:
Du sprichst von:
Die ersten beiden verwenden generische Begriffe und präzisieren durch nähere Beschreibungen, in unterschiedlichen Graden. Letzterer fasst alles in einem eigenen, fest definierten Fachbegriff zusammen. Alle drei Möglichkeiten sind inhaltlich völlig gleichwertig. Trotzdem gehört es zum natürlichen Sprachgebrauch dazu, einen präzisen Fachbegriff, sofern es einen gibt, zu verwenden, statt generische Begriffe mit näheren Beschreibungen zu versehen.
Du kannst ja mal selbst versuchen, wie viele Menschen, da es den Fachbegriff Quadrat ja gibt, noch genau verstehen, was du mit geometrische Form mit vier Ecken und jeweils einem rechten Winkel sowie geraden Kanten meinst. Wenn du so kommunizierst hast du zwar das selbe gesagt - aber trotzdem nicht das gleiche Verständnis bei deinem Gegenüber erzeugt.
Deshalb ist die Bezeichnung eines Quadrats als geometrische Form mit vier Ecken und jeweils einem rechten Winkel sowie geraden Kanten zwar nicht inhaltlich falsch, aber trotzdem unsemantisch - denn du nutzt nicht die semantischen Auszeichnungsmöglichkeiten der Sprache, um das präziser und weniger missverständnisanfällig zu fassen.
Wenn du noch nicht verstehst, was ich mit missverständnisanfällig meine: Stell dir vor, du hast auf deiner Seite eine Beschreibung aller deutschen Flüsse und ihrer Eigenschaften und verwendest auch da das generische div - und erhältst:
<div id="rhein">
<p>Beschreibung des Flusses Rhein...</p>
</div>
<div id="donau">
<p>Beschreibung des Flusses Donau...</p>
</div>
<div id="main">
<p>Beschreibung des Flusses Main...</p>
</div>
Ups. Woher genau weiß jetzt der Browser oder die Suchmaschine oder ..., dass das <div id="main">
hier nicht das Hauptelement der Seite meint, sondern Inhalte zum Fluss Main beinhaltet?
Richtig. Der Browser kann das nicht zweifelsfrei sagen. Deshalb missverständnisanfällig, denn die Attributwerte sind potenziell immer mehrdeutig.
Ein eigenes Element ist immer eindeutig definiert und kann nicht falsch verstanden werden. Deshalb ist die Verwendung des extra dafür definierten Elements semantischer als die Verwendung des generischen Elements mit beschreibendem Attribut[1].
Aber das ist ja doch immer eine Diskussion hier ohne Resultat, daher nochmal die Bitte an dich @Gunnar Bittersmann (sozusagen sowieso als Barrierefreibotschafter hier) zum Statement/Artikel eines z.b. Marco Zehe.
Ich habe das jetzt ausführlich gemacht, und ich glaube die Beispiele sind recht verständlich geworden. Ich hoffe du nimmst dir das zu Herzen und es klärt einige deiner offenen Fragen endlich.
Dabei geht's eigentlich ja auch so:
<div class="topnav"> <a class="active" href="#home">Home</a> <a href="#news">News</a> <a href="#contact">Contact</a> <a href="#about">About</a> </div>
Deine Aussage ist genau dieselbe wie:
Warum sagen wir eigentlich
„Die Diagonalen eines Parallelogramms halbieren einander“,
denn eigentlich gehts ja auch so:
„Die Verbindungsstrecken, die in gerader Linie die Ecken einer geometrischen Figur mit vier Ecken und zwei Kanten, die sich als Gerade verlängert nie schneiden würden, verbinden, haben den Punkt, der von den genannten Ecken genau gleich weit entfernt ist und jeweils auf den genannten Linien liegt, gemeinsam.“
Ich denke die Frage beantwortet sich damit von selbst.
Wer verstanden werden will, sollte so präzise wie möglich auszeichnen.
Grüße,
RIDER
außer, wenn die Bedeutung der Attribute auch fest und eindeutig definiert sind, zum Beispiel wie in aria-... oder den Möglichkeiten von schema.org. Aber auch da gilt, dass neu definierte, spezialisierte Attributwerte semantischere Auszeichnung ermöglichen als generische und daher auch verwendet werden sollten. ↩︎
@@Camping_RIDER
- geometrische Form mit vier Ecken und jeweils einem rechten Winkel sowie geraden Kanten
- Viereck mit rechten Winkeln
- Quadrat
[…] Alle drei Möglichkeiten sind inhaltlich völlig gleichwertig.
Wirklich?
Mathematik zum Wochenende wäre für dich eine Pflichtveranstaltung. 😉
LLAP 🖖
Aloha ;)
- geometrische Form mit vier Ecken und jeweils einem rechten Winkel sowie geraden Kanten
- Viereck mit rechten Winkeln
- Quadrat
[…] Alle drei Möglichkeiten sind inhaltlich völlig gleichwertig.
Wirklich?
Danke für die Korrektur! Beide erstere Beschreibungen benötigen natürlich noch ein „gleich langen“ - oder es muss Rechteck heißen, nicht Quadrat.
Ich laste es mal einfach der Uhrzeit meines Postings an 😉
Grüße,
RIDER
@@Henry
<div class="topnav"> <a class="active" href="#home">Home</a> <a href="#news">News</a> <a href="#contact">Contact</a> <a href="#about">About</a> </div>
Sich auf w3schools zu berufen war noch nie die beste Idee. Die mögen sich gebessert haben und es ist nicht mehr alles falsch, was da steht; als Referenz würde ich das aber noch lange nicht ansehen.
Das nav
-Element anstelle von <div class="topnav">
zu verwenden wurde in diesem Thread ja schon besprochen.
Zur Kennzeichnung der aktuellen Seite bietet sich aria-current="page"
an. Das hilft Nutzern von assitiven Technologien (zumindest von aktuellen, die das Attribut unterstützen), und außerdem ist es besser lesbarer Code. class="active"
braucht man dann nicht; [aria-current]
lässt sich genauso gut zum Stylen verwenden.
(Dass die aktuelle Seite im Menü nicht verlinkt sein sollte, ist nochmal eine andere Diskussion.)
Dann wären wir bei
<nav>
<a aria-current="page" href="#home">Home</a>
<a href="#news">News</a>
<a href="#contact">Contact</a>
<a href="#about">About</a>
</nav>
Kann man machen, aber: Die Auszeichnung der Menüpunkte als Liste bringt Nutzern von assitiven Technologien zusätzlichen Mehrwert. Screenreader können jeweils ansagen, der wievielte Menüpunkt von wievielten insgesamt das jeweils ist. Außerdem bieten die ul
-/ol
- und li
-Elemente zusätzliche Ansatzpunkte für CSS, kommen also auch durchaus dem Entwickler entgegen. (Eine Diskussion, die ich desöfteren schon mit MrMurphy1 geführt habe.)
LLAP 🖖
@@beatovich
html5 Hat das repertoire an Elementen mit eher esoterischen Rollen eingebracht.
Welche meinst du damit? Die vormals präsentationsbezogenen b
, i
, s
, small
?
Dass man nach 20 jahren <nav> schreiben darf, aber keine <nav> bekommt
Doch, bekommt man. Frag mal einen Screenreader-Nutzer.
LLAP 🖖
Hej beatovich,
Echte Browserunterstüzte Funktionalität wäre angebracht. Dass man nach 20 jahren <nav> schreiben darf, aber keine <nav> bekommt, halte ich für ziemlich lächerlich.
Die gibt es längst, wenn auch nicht sichtbar in grafischen Browsern.
Um das ausssehen musst du dich schon noch selber kümmern. Ist auch gut so, meiner Meinung nach.
Was ansonsten passiert kannst du sehen, wenn du beobachtest, was alles für Gewächse wuchern, wenn der Browser select-Boxen bereit stellt. Unfassbar was für Wege da gegangen werden, um Dropdowns zu erhalten, die aussehen wie gewünscht.
Sehr zum Nachteil aller Beteiligter wie Auftraggeber, Besucher und Entwickler…
Marc
hallo
Echte Browserunterstüzte Funktionalität wäre angebracht. Dass man nach 20 jahren <nav> schreiben darf, aber keine <nav> bekommt, halte ich für ziemlich lächerlich.
Die gibt es längst, wenn auch nicht sichtbar in grafischen Browsern.
Deine Aussage ist vergleichbar mit: Es gibt sie nur mit einem Plugin.
Hej beatovich,
Echte Browserunterstüzte Funktionalität wäre angebracht. Dass man nach 20 jahren <nav> schreiben darf, aber keine <nav> bekommt, halte ich für ziemlich lächerlich.
Die gibt es längst, wenn auch nicht sichtbar in grafischen Browsern.
Deine Aussage ist vergleichbar mit: Es gibt sie nur mit einem Plugin.
Nö. Sie ist in allen Browsern vorhanden, in nicht grafischen Browsern auch erlebbar. In grafischen Browsern verhält sie sich nicht so, wie du es dir wünschst und ist auch nicht sichtbar, das heißt aber nicht, dass sie nicht da ist.
Übrigens: deine Erwartungen an das Verhalten einer Navigation wird sich nicht mit meinen Wünschen decken (ich hätte die standardmäßig an der aktuellen Seite aufgeklappt). Aber weder deine noch meine Präferenzen eignen sich zur Standardisierung.
Marc
hallo
Nö. Sie ist in allen Browsern vorhanden, in nicht grafischen Browsern auch erlebbar. In grafischen Browsern verhält sie sich nicht so, wie du es dir wünschst und ist auch nicht sichtbar, das heißt aber nicht, dass sie nicht da ist.
Übrigens: deine Erwartungen an das Verhalten einer Navigation wird sich nicht mit meinen Wünschen decken (ich hätte die standardmäßig an der aktuellen Seite aufgeklappt). Aber weder deine noch meine Präferenzen eignen sich zur Standardisierung.
Ich kann ein nav durch ein div ersetzen, vorausgesetzt CSS braucht jetzt nicht nav für Regeln. Nichts an meiner Experience im Browser ändert sich.
@@beatovich
Ich kann ein nav durch ein div ersetzen, vorausgesetzt CSS braucht jetzt nicht nav für Regeln. Nichts an meiner Experience im Browser ändert sich.
An deiner nicht, an der anderer schon.
Ein Screenreader ist kein Browser-Plugin.
LLAP 🖖
Hej beatovich,
Ich kann ein nav durch ein div ersetzen, vorausgesetzt CSS braucht jetzt nicht nav für Regeln. Nichts an meiner Experience im Browser ändert sich.
Richtig. Aber das sagte ich bereits.
Ich sagte aber auch, das gilt nicht für jeden. Screenreader Nutzer beispielsweise.
Wenn du semantisch falsch auszeichnest ändert sich die die user experience dennoch für die meisten, wenn auch nicht unbedingt im Browser. Z. B. auf den SRPs der meisten Suchmaschinen.
Du kannst dann auch keine nav
mehr parsen uswusf
Sei doch nicht so phantasielos 😉
Marc
hallo
Sei doch nicht so phantasielos 😉
Ich kann schon Phantasie aufwerfen und sehe die Verwendung von <nav> unbedingt ein.
Meine Phantasie reicht auch für ein Plugin, mit aller Gefahr die Plugins beinhalten, dass sie nämlich unter Umständen zu Browsereigenschaften werden.
😉
@@marctrix
Nö. Sie ist in allen Browsern vorhanden, in nicht grafischen Browsern auch erlebbar.
Welche Art Browser meinst du? Textbrowser wie Lynx?
LLAP 🖖
Hej Gunnar,
@@marctrix
Nö. Sie ist in allen Browsern vorhanden, in nicht grafischen Browsern auch erlebbar.
Welche Art Browser meinst du? Textbrowser wie Lynx?
Nein, ich dachte an Screenreader. Ich weiß, dass die nicht Browser im eigentlichen Sinn sind, weil sie nicht ausschließlich Webseiten interpretieren. Ich denke aber dass sie sich wie ein Browser verhalten, wenn der Fokus auf einer Webseite ist. Sie stellen also neben vielem anderen die Funktionalität eines Browsers bereit.
Marc
@@marctrix
Nö. Sie ist in allen Browsern vorhanden, in nicht grafischen Browsern auch erlebbar.
Welche Art Browser meinst du? Textbrowser wie Lynx?
Nein, ich dachte an Screenreader. Ich weiß, dass die nicht Browser im eigentlichen Sinn sind
Eben. Screenreader lesen vor, was in Anwendungen zu sehen ist, z.B. im Browser – üblicherweise in einem grafischen Browser.
LLAP 🖖
Hej Gunnar,
@@marctrix
Nö. Sie ist in allen Browsern vorhanden, in nicht grafischen Browsern auch erlebbar.
Welche Art Browser meinst du? Textbrowser wie Lynx?
Nein, ich dachte an Screenreader. Ich weiß, dass die nicht Browser im eigentlichen Sinn sind
Eben. Screenreader lesen vor, was in Anwendungen zu sehen ist, z.B. im Browser – üblicherweise in einem grafischen Browser.
Na und? Das heißt noch lange nicht, dass sie sich um Grafik kümmern.
Sie kümmern sich um Semantik, nicht um Optik und das gibt der grafische Browser an den Screenreader weiter; aber der Screenreader stellt die Benutzeroberfläche und Eingabemöglichkeiten bereit stellt. Er rendert die Seiten sogar (nur eben akustisch mit diversen Stimmen und gesprochenen Hinweise). Er tut also genau das, was einen Browser ausmacht.
Manchmal leider (wenn Elemente per order
umsortiert würden, wäre das manchmal praktisch für die Screenreader-Unterstützung), manchmal zum Glück (weil dadurch üble Hacks für Screenreader möglich werden, um Elemente vorlesen zu lassen, die vor sehenden verborgen werden - dafür sollte es eine native, semantische Möglichkeit geben).
Marc