HTML 5

[Harlequin]

Yerf!

Ich gebe ja zu, dass diese Aussagen vom mir persönliche Meinung sind und sicher nicht ganz Vorurteilsfrei.

Mit ein wenig Wille zur Recherche lassen sich in den Mailing-Listen von WHATWG und W3C HTML WG auch die meisten Entscheidungsprozesse finden.

Sollte ich vielleicht wirklich mal machen, könnte interessant werden. Denn aus meinen bisherigen Erfahrungen mit HTML/CSS/JS heraus kann ich eben einiges von HTML 5 nicht nachvollziehen.

Zu diesem speziellen Falle:  Die Entscheidung, <a href> zu einem transparenten Element zu machen, ist nach langem Hin und Her erst vor kurzem von Ian Hickson getroffen worden und eventuell auch noch nicht die finale Lösung.

Ich hoffe mal...

Fakt ist, dass die Praxis zeigt, dass Entwickler eine Möglichkeit brauchen, Textblöcke oder ganze Tabellenzeilen zu verlinken.  JavaScript ist zwar in vielen Fällen eine Möglichkeit – und sogar die von Ian Hickson favorisierte –; die überwiegende Mehrheit in WHATWG und W3C HTML WG hat dennoch den Wunsch geäußert, echte Links setzen zu können.

Javascript vorauszusetzen um dies zu realisieren halt ich auch für einen "ungünstigen" schlechten Weg. Die Problematik, das es Clients ohne JS gibt wird uns erhalten bleiben. (Vor allem Crawler die ja die Links schon finden sollten...)

Da ein globales @href von den Browserherstellern recht einstimmig als schwer implementierbar abgelehnt wurde – und was bringt eine Technik, die man mangels Implementierungen nicht benutzen kann?

Da stellt sich für mich die Frage: warum? Und vor allem: ist die neue Variante besser? Ein onclick="location.href='url'" funktioniert doch heute schon. Einen Parser für das href-Attribut ähnlich dem Eventhandlern sollte doch nicht so schwer sein oder was übersehe ich da?

hat Ian Hickson sich erstmal für das transparente <a href> entschieden.  Aber wie gesagt:  Ob das die finale Lösung ist, wird sich noch zeigen.

Ich sehe in dieser Lösung zwei kritische Probleme:

1. ein uneinheitlicher DOM-Tree, wenn man nicht alle Tabellenzeilen verlinkt. Dann hat man bunt gemischt <tr> und <a> als Kinder von <table>. Nicht nur, dass das einfach nicht "schön" ist, da darf man dann ganz schön aufpassen, wenn man mit JavaScript oder CSS arbeitet. (z.B. wie wird sich die rows-Eigenschaft des Tabellen-Objekts verhalten?)

2. wie sieht das "transparente" <a> im CSS aus? Es darf ja die Darstellung der Tabelle nicht beeinflussen. Gibt's dann ein display:transparent dafür? (Und ist dies wirklich einfacher zu implementieren als die XHTML2-Variante?)

Ja, ein <object>-artiges Element für Bilder wäre wegen der besseren Möglichkeiten für Alternativinhalte durchaus interessant.  Ein Problem:  Es wird vom IE nicht unterstützt und ist damit nicht in der Praxis nutzbar.

Bis der IE mal HTML5 kann wirds auch dauern, von daher ist das kein Argument. (Wobei ich mir nicht mal sicher wär, dass das im IE nicht geht. Meines Wissens hat der nur mit HTML im Object Probleme, Bilder sollten eigentlich gehen)

Ich denke durchaus, dass Video und Audio generisch genug sind; Vergleiche zu PDF oder Word halte ich für völlig überzogen und ordne ich mal in die Kategorie Kintergartenpolemik ein.

Für mich stellt sich halt die Frage, was demnächst noch alles als "generisch genug" gehalten wird und wieso man nicht einfach bei <object> bleibt. Damit hätte man für alle zusätzlichen Inhalte ein einheitliches Verfahren zur Einbindung.

Ich hab grad auch in der HTML5-Spec gesehen, dass das Video-Element keinen Alternativinhalt vorsieht, man solle einen alternativen media stream anbieten. Läuft irgendwie in eine andere Richtung als die üblicherweise für Barrierefreiheit empfohlene Vorgehensweise...

Wie sieht denn die Einbindung von Video- und Audiodateien in Webseiten heute aus?  Proprietäre Techniken mit Windows Media, Real oder bestenfalls noch Flash, die für Nichtexperten kaum zu durchschauen sind.

Die Lösung wäre alles propritäre rauszuschmeißen (gehört ja eigentlich eh nicht zum HTML-Standard) und nur noch <object type="Mimetype"> zu verwenden. Der Browser entscheidet dann anhand des Typs und der vorhandenen Software, wie er das ganze darstellt. Evtl. noch eine Vereinheitlichung der <param>s in der Spec.

Für den IE werden brauchbare Plugins hoffentlich nicht lange auf sich warten lassen.

Ob die wohl jemand installiert? (oder wieviele Leute haben den SVG-Viewer für den IE?) Im Bezug auf den IE bin ich da immer ein wenig pessimistisch.

Auch völliger Quatsch, verzeihe.  HTML 5 ist eine sehr elegante und saubere Sprache, bei der es nicht darum geht, es jedem Recht zu machen.  Ganz im Gegenteil!  Bei jedem einzelnen Feature wird überprüft, ob es in der Praxis relevant und ohne Komplikationen zu implementieren ist.

Hm, aber vielleicht frägt man hier die falschen? Wenn man immer nur danach geht, was im Browser einfach zu implementieren ist bleibt der Webentwickler, der später einmal mit HTML5 arbeiten muss, irgendwo auf der Strecke (siehe auch meinen ersten Punkt oben zum <a><tr></tr></a>).

Hierbei wird die Rückwärtskompatibilität stets im Auge behalten.  Auch wird darauf geachtet, die Regeln nicht so kompliziert zu machen, dass sich 90% der Entwickler oder mehr sowieso nicht darum bemühen, sie einzuhalten.

Einfache und klarer Regeln die gut nachzuprüfen sind wären eigentlich genau die Stärke von XHTML.

Ich würde mich freuen, wenn du meinem Beispiel folgen und dich auch etwas weniger oberflächlich mit dem Thema auseinandersetzen könntest.  Dann kannst du ja immer noch zu dem Schluss kommen, dass du HTML 5 für Mist hälst.

Ein Interesse dafür hast du auf jeden Fall geweckt.

Gruß,

Harlequin