Microsoft-Kritik an HTML 5

13 Aug 2009 19:20

Hin und wieder schaffen es einzelne Beiträge aus den Mailinglisten des W3-Konsortiums ans Licht der breiten Öffentlichkeit. So geschehen jüngst wieder im Fall eines Postings von Adrian Bateman, Microsoft-Mitarbeiter und Entwickler im Internet-Explorer-Team. Dieser hat sich zum aktuellen Stand von HTML 5 geäußert und einige Kritikpunkte eingebracht. Das lässt insofern aufhorchen, als Microsoft gar nicht der WHATWG-Arbeitsgruppe für HTML 5 angehört. Auch gibt es von Microsoft bislang kaum Statements zum Thema HTML 5.

Zunächst kritisiert Bateman die neuen Elemente für sogenannten Sectioning Content, also Elemente wie section (Auszeichnung von Bereichen in Dokumenten oder Benutzeroberflächen), nav (Navigationsbereich), article (Artikel, Blog-Eintrag), aside (Sidebar-Bereiche, Marginalspalten), hgroup (Bereich für direkt folgende, über- und untergeordnete Überschriftenebenen), header (Kopfbereich) und footer (Fußbereich). Bateman hält diese Elemente für unspezifisch und keinen Fortschritt gegenüber bewährten Auszeichnungen wie <div class="header">.

Ich nehme an, Bateman weiß selbst, dass <header> eine in HTML verankerte Konvention mit vordefinierter logischer Bedeutung ist, während <div class="header"> einfach nur einen Bezeichnernamen definiert, der zwar aus Autorensicht semantisch sinnvoll ist, aber aus Sicht der verarbeitenden Software keinerlei spezifische Bedeutung hat. Lediglich im Rahmen von Mikroformaten wird der Versuch unternommen, auf der Ebene von Bezeichnernamen, in HTML also auf der Ebene von Wertzuweisungen an Attribute, so etwas wie semantische Konventionen für verarbeitende Software zu entwickeln. Bateman argumentiert jedoch nicht im Hinblick etwa auf Suchmaschinen-Robots, sondern tatsächlich nur aus rein menschlich-semantischer Sicht. Da ist es natürlich egal, ob <header> oder <div class="header"> da steht. Eine richtige Frage stellt Bateman allerdings auf jeden Fall: Woher wissen wir, dass genau dieses Set an Sectioning-Elementen ausreichend ist? Die Gegenfrage darf natürlich gestellt werden: Sollen wir, solange wir das perfekte Element-Repertoire für eine Sprache wie HTML nicht kennen, nur mit div und span arbeiten?

Auch was das Konstrukt für Dialoge mit direkt wiedergegebener Rede betrifft (<dialog><dt> … </dt><dd> … </dd><dt> … </dt><dd> … </dd> …</dialog>), fragt Bateman nach dem tieferen Sinn. Möglicher, aber nicht aufgeführter Hintergedanke: <dl class="dialog"><dt> … </dt><dd> … </dd><dt> … </dt><dd> … </dd> …</dl> könnte doch das Gleiche leisten. Antwort: Oder auch nicht. Man darf nicht nur an die Verarbeitung in grafischen Browsern denken. Für einen Screenreader könnte ein Dialog interessanten Input zur Artikulation liefern.

Auch bei Text-Level-Elementen (Inline-Elemente, die als Inhalt Text und/oder andere Text-Level-Elemente enthalten) wiederholt Bateman seine Frage danach, warum ausgerechnet mark, time, progress und meter als neue Elemente eingeführt wurden, andere dagegen nicht. Von der Hand zu weisen ist dieses Hinterfragen durchaus nicht. Wenn man davon ausgeht, dass HTML 5 als Standard sehr lange Bestand haben wird, so kann man durchaus die Frage stellen, ob man dann nicht entweder ganz auf neue, semantische Elemente verzichtet, oder, wenn man sie einführt, dann aber massiv. Bei einem Brainstorming würden sicherlich dutzende weitere, nützliche Elemente ausgebrütet werden, von Auszeichnungen für EAN-Nummern bis hin zu Auszeichnungen für Dialektsprache. Warum nicht auch diese in HTML 5 mit aufnehmen? Wenn es nur darum geht, mehr potentielle semantische Anreicherung zu betreiben, dann wäre sicherlich mehr möglich als das, was HTML 5 an Neuerungen enthält.

Konkreter ist die Kritik Batemans an den neuen Formularelementen, da die Kritik sich bei diesen Elementen vor allem mit der Implementierungs-Ebene auseinandersetzt. So stellt Bateman beispielsweise fest, dass die HTML5-Implementierung des keygen-Elements einer alten Netscape-Technik folgt, während Microsoft dazu viel modernere, ausgereiftere Lösungen anbietet. Das keygen-Element dient zum Generieren eines Schlüsselpaars, besehend aus einem öffentlichen und einem zugehörigen privaten Schlüssel, wobei der öffentliche Schlüssel mit den Formulardaten übertragen wird, der private Schlüssel dagegen vom Browser lokal gespeichert wird. Diese Technik wird üblicherweise zur Verifizierung eines Kommunikationspartners verwendet, was auch für die Kommunikation zwischen Browsern und Webanwendungen nützlich sein kann. Batemans Kritik betrifft wohl die Tatsache, dass als Default-Methode zum Generieren der Schlüssel der RSA-Signatur-Algorithmus zum Einsatz kommen soll.

Bei den neuen Eingabefeld-Typen für Datum und Uhrzeit (<input type="date|time|datetime|local-datetime">) sieht Bateman eine Ungereimtheit darin, dass sich bei Datumsangaben explizit angeben lassen soll, ob diese als Standardweltzeit (UTC) oder als lokale Zeitangabe interpretiert werden sollen, während das bei Zeitangaben nicht der Fall ist. Klingt für mich eher wie etwas, das schlichtweg noch ergänzt werden muss.

Viel Aufmerksamkeit widmet Bateman schließlich auch den neuen HTML-Elementen für Benutzer-Interaktion und Script-/Datenanbindung. Das ist nicht weiter verwunderlich, da der MS Internet Explorer schon seit Produktversion 4 proprietäre Konzepte für all diese Dinge mit sich herum schleppt und Microsoft dieses Gebiet gerne federführend beackern würde, geht es doch um die Schnittstelle zwischen Web und der klassischen MS-Domaine Desktop.

Das neue datagrid-Element für komplexe, auch explorer-artige Datenstrukturen mit Datenanbindung kritisiert Bateman auf diesem Hintergrund ebenso wie das bb-Element, das einem Webautor ermöglichen soll, innerhalb einer Webseite das gezielte Anstoßen von Browser-Funktionen (denkbar sind z.B. Drucken, Download, Zoom …) zu ermöglichen. Bei der Datenanbindung glaubt er bessere Ansätze zu kennen, und die Elementschnittstelle für Browser-Funktionen hält er für manipulierbar und eine potentielle Gefahrenstelle, um Anwender mit böswilligen Absichten auszutricksen. Bateman kritisiert im Zusammenhang mit Formularelementen auch den in HTML häufig spezifizierten Vorschlag, Elemente mit den Ressourcen der verwendeten grafischen Benutzeroberfläche (Windows, Mac, Gnome …) zu rendern und auch Verhaltensweisen von Elementen mit den Bordmitteln der Benutzeroberfläche abzubilden. Er kritisiert, dass viele Webentwickler lieber die vollständige Kontrolle über das Aussehen und Verhalten von Dialog-Elementen wünschen. Bezüglich des contenteditable-Attributs schließlich, das endlich die offizielle Richttext-Editier-Schnittstelle von HTML werden soll, meckert Bateman zu unpräzise Implementierungsdetails an, was iin der Praxis wieder für Ärger und Probleme wegen unterschiedlicher Browser-Reaktionen führen könnte.

Insgesamt ein netter Rundumschlag, der durchaus dazu beitragen kann, HTML 5 weiter zu konkretisieren und zu verbessern. Ein kraftvolles „Jetzt kommen wir (Microsoft)“ kann ich dem Mailinglisten-Posting von Bateman allerdings nicht entnehmen. Dazu ist die Liste wohl auch der falsche Ort. Offizielle Einmischungen von Microsoft gibt es ja auch weiterhin nicht. Es scheint sich eher um die Einzelaktion eines MS-Mitarbeiters zu handeln.

Kommentare

Neuen Kommentar hinzufügen
oder Anmelden als Wikidot User
(wird nicht veröffentlicht)
- +
Sofern nicht anders angegeben, steht der Inhalt dieser Seite unter Lizenz Creative Commons Attribution-ShareAlike 3.0 License