sprungmarker testet

HTML 5: eine Verneigung vor allen Unwägbarkeiten und Problemstellen

456 Berea Street startet einen Hilferuf zur Aufrechterhaltung von Barrierefreiheit und Semantik in HTML.

[lang_de]In seinem Aufruf „Help keep accessibility and semantics in HTML“ fordert er die Standard-Gemeinde auf, sich an der Entwicklung von HTML 5 aktiv zu beteiligen.[/lang_de]
[lang_en]Roger Johansson strongly remarks that the current draft for HTML 5 is on its the way against standards, semantic HTML and accessibility. The continued use of old HTML-attributes and elements as I-, B– and FONT-element (for WYSIWYG-editors) is quite unbelievable and is indeed regressive. Accessibility features for data tables (ID-, HEADERS-attributes) are not yet implemented and maybe never. Accessibility tends to be a more or less fluent issue. If they get enough evidence that an accessible feature could be of interest anyhow … . But which interests get evidence? Browser vendors, microsoft with its back-to-the-roots approach in Outlook 2007?[/lang_en]

Ich fürchte, wir normalen Standard-End-User-Entwickler würden da ohnehin nicht aufgenommen werden bzw. würde man wohl an der Sprache letztlich scheitern. Das nur am Rande. Spannend ist vor allem der lange Kommentar-Thread, der auch wichtige Informationen zu Standarisierung und Barrierefreiheit im Hinblick auf HTML 5 mitliefert.

Alte HTML-Elemente wieder modern?!

Interessant etwa ist, dass alte physikalische Auszeichnungen wie das B-Element oder I-Element für die Kennzeichnung von fett und kursiv wieder in die Spezifikation aufgenommen werden sollen, wohl aus pragmatischen Gründen (Quelle: Kommentar 32) – diese Pragmatik wird sowohl von Johansson als auch anderen mit der Vorherrschaft von Browser-Hersteller erklärt, die auf Validität, Barrierefreiheit und semantische Strukturen keinen Wert mehr legen wollen bzw. ohnehin nie wirklich gelegt hatten).

Tatsächlich findet sich das I-Element für kursiv wieder im aktuellen Draft von HTML 5 mit dem Hinweis, dass der nur dann angewendet werden soll, wenn man sonst nichts mehr anwenden kann, also kein CITE-Element, kein EM-Element etc.. Das ist schon arg merkwürdig, wie ich finde.

Datentabellen ohne ID und HEADERS Verbindung?!

Wie von Johansson bereits angemerkt, ist in der aktuellen Draftversion von HTLML 5 nur noch das SCOPE-Attribut angeführt, um eine eindeutige Verbindung zwischen Überschrift und Zeilen einer Datentabelle zu setzen. In den Kommentaren zu Johansson wird darauf verwiesen, dass das das ID/HEADERS-Konzept noch später integriert werden würde, wenn die Sinnhaftigkeit sich einstellen würde (sprich: wenn sich ausreichend Fürsprecher für diese Methode finden lassen).

Dabei weiss man doch, dass das SCOPE-Attribut nur für sehr einfache Datentabellen überhaupt anwendbar ist (also durchaus auf sehr technischer Ebene gesprochen), und das ID/HEADERS-Konzept für komplexe Verschränkungen in Datentabellen nötig wird.

Meiner Ansicht nach steht dahinter klar der Nutzer/Nutzenaspekt, die Leute denken wahrscheinlich immer noch in Layouttabellen. Datentabellen zu formatieren, ist wohl was für Spezialisten im Standardisierungs-Kämmerchen! 😉 Wenn schon eine Datentabelle sein muss, dann reicht denen wohl irgendwie SCOPE schon hin.

Sehr bedenklich das alles – kann man nur hoffen, dass das ID/HEADERS-Konzept doch noch Fürsprecher findet.

Wenn man den Draft mal genau hinsichtlich der Tabellen-Struktur ansieht, könnte man auch erkennen, dass es nicht mehr zwingend sein wird, THEAD, TBODY und TFOOT – die ja die wesentlichen Elemente einer gut strukturierten Datentabelle ausmachen – gemeinsam zu verwenden. Es scheinen wohl auch Mischformen erlaubt, wenn nicht alle Elemente vorhanden sind.

Hier schliesst sich dann wieder die Fragen an, was bringt das an Vorteil, ausser das der Wildwuchs im Datentabellenbau noch weiter zunehmen wird. Wahrscheinlich gibt man hier auch wieder dem Problem nach, dass keiner das volle Programm wirklich verwendet. 😉

Das FONT-Element wird erlaubt für WYSIWYG-Editoren

Autsch, jetzt tut es gleich richtig weh. Das FONT-Element, den uns Microsoft mit seinem Outlook 2007 wiederbeschert hat, ist weiter im Kommen. (Quelle: HTML 5 Draft). Freilich soll es nur in WYSIWYG-Editoren erlaubt sein und es wird auch gleichzeitig aufgefordert, Editoren möchten doch lieber darauf verzichten. 😉 Man kann in der noch immer aktuellen HTML 4.01. Spezifikation ruhig nochmal den Satz lesen: FONT and BASEFONT are deprecated“. Für das B– oder I-Element trifft das nicht zu. Also immer nur wieder her damit! Besser alles doppelt und dreifach einsetzen, als einmal zu wenig. 😉

Fazit: eine Verneigung vor dem Kapital

Naja, ob diese Verneigung vor Microsoft und invaliden Editoren-Hersteller wirklich notwendig ist? Die haben sich doch ohnehin nie an Spezifikationen gehalten, werden mit dieser W3C-Weichenstellung jedoch unnötig ermutigt.

Also es lohnt sich, sich den Draft mal genauer anzusehen, um, und da ist Roger Johansson nur zuzustimmen, die bereits im Vorfeld ab- und eingeschliffenen Kanten erkennen zu können. Freilich findet man dort auch viele interssante, neue Konzepte. Aber was suchen die alten dort?

2 Antworten auf “HTML 5: eine Verneigung vor allen Unwägbarkeiten und Problemstellen”

  1. […] weiteren Unsinn kann man sich hier kundig machen: HTML 5: eine Verneigung vor allen Unwägbarkeiten und Problemstellen […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert