nicht angemeldet
Ich gebe ja zu, dass diese Aussagen vom mir persönliche Meinung sind und sicher nicht ganz Vorurteilsfrei.
Das habe ich schon verstanden, und ich will dir persönliche Meinungen, die mit meinen nicht kongruent sind, auf keinen Fall verbieten. Mir liegt aber daran, dir zu zeigen, dass es sich bei HTML 5 um das Gegeneteil von „HTML 3.2 reloaded“ handelt, zumal du mit solchen Äußerungen möglicherweise auch andere Forumsteilnehmer voreingenommen machst.
Die Entscheidung, <a href> zu einem transparenten Element zu machen, ist […] eventuell auch noch nicht die finale Lösung.
Ich hoffe mal...
Offen gestanden: Ich auch… ;-)
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...)
Sorry, ich habe mich auch missverständlich ausgedrückt. Reine JavaScript-„Links“ will natürlich gar keiner. Neben der von dir angesprochenen Barrierefreiheit wäre da auch noch die Usability als Problem zu nennen, denn onclick fängt ja nur einfache Mausklicks der primären Taste ab; stellt ein tab-fähiger Browser nun beispielsweise den Mittelklick bereit, um das Verweisziel in einem neuen Tab zu öffnen, funktioniert das mit JavaScript ohne weiteres auch nicht.
Was Ian Hickson für zureichend hielt, war die auch irgendwo in diesem Thread vorgeschlagene Lösung, unterhalb von <tr> ein <a href> in einem <td> unterzubringen und dessen @href fürs @onclick des <tr> zu nutzen. Das dumme ist eben, dass unerfreulich viele Entwickler Barrierefreiheit und Usability dann schnell aus den Augen verlieren und direkt zu <tr onclick="location.href='http://example.org/'"> greifen, „weils ja funktioniert“.
Die zwei Mails, die zu dieser Thematik relevant sein dürften, sind übrigens diese und diese.
Da ein globales @href von den Browserherstellern recht einstimmig als schwer implementierbar abgelehnt wurde […]
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?
Sollte man meinen – offenbar ist das alles doch komplizierter. Ich finde die entsprechende Mail gerade nicht; Ian Hickson hat aber mal eine ganze Reihe an Punkten aufgelistet, die zusätzlich bewerkstelligt werden müssten, um ein globales @href zum Laufen zu bringen. Da ist einiges bei, worauf man so spontan nicht kommt. Was ich mich aber wirklich frage, ist, ob ein transparentes <a href> tatsächlich weniger schwer umzusetzen ist als @href. Naja, mal sehen, was die Zeit bringt. Der Zeitplan ist ja doch recht großzügig ausgelegt… ;-)
hat Ian Hickson sich erstmal für das transparente <a href> entschieden. […]
Ich sehe in dieser Lösung zwei kritische Probleme:
ein uneinheitlicher DOM-Tree, wenn man nicht alle Tabellenzeilen verlinkt. Dann hat man bunt gemischt <tr> und <a> als Kinder von <table>. […]
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?)
Gute Fragen. Was transparente Elemente angeht, hilft dir der entsprechende Absatz in der Spezifikation vielleicht zum Teil weiter. Aber überhaupt funktioniert ein <a href><tr></tr></a> zumindest in Gecko derzeit ja noch gar nicht. Sei also versichert, dass der derzeitige Zustand noch nicht den finalen Zustand darstellt. Wenn du willst, beteilige dich doch einfach an den Diskussionen und äußere deine Bedenken! Genau zu diesem Zwecke ist die WHATWG ja offen.
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.
Was heißt „Bis der IE mal HTML5 kann“? HTML5 (ja, hier ist „HTML5“ tatsächlich die richtige Schreibweise :-) legt großen Wert auf Abwärtskompatibilität. Sollte mal irgendwo ein <section> in einem älteren Browser nicht für CSS zugänglich sein, ist das kein ernsthaftes Problem. Empfiehlt HTML 5 aber für Bilder <object>, obwohl der Browser (ja, leider, natürlich) es nicht versteht, wird HTML 5 beim Durchschnittsentwickler in die Kategorie „Yet another praxisferner Standard, an den ich mich zu halten keine Lust habe“ fallen. Sogesehen ist das durchaus ein 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)
Ein kleiner Schnelltest:
<!doctype html>
<meta charset=UTF-8>
<title><object> Test</title>
<p><object data="http://src.selfhtml.org/logo.gif">asdf</object>
<hr>
<p><img src="http://src.selfhtml.org/logo.gif" alt="asdf">
schlug bei mir im IE7 fehl; in meinem lokalen IE7 wird überhalb der <hr> gar nichts angezeigt, während der NetRenderer-IE7 dort immerhin das „asdf“ anzeigt. Offenbar gibt es also doch noch Schwierigkeiten. Leider und peinlicherweise.
Ich denke durchaus, dass Video und Audio generisch genug sind; […]
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.
Ehrlich gesagt kann ich deine Bedenken nicht wirklich nachvollziehen. Grafik, Video und Audio halte ich für extrem generisch; all das sind Medienformen, die im Web sehr wichtig sind und für die im einzelnen viel spezifiziert werden muss, siehe Spezifikation. Für alles andere, inklusive proprietären Quatsch, gibt es <object>. Es besteht bestimmt keine Gefahr, dass wir in ein, zwei Jahren ein <pdf> oder <ms-word-doc> sehen werden.
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...
Für <video> kann ich mir zwei Haupteinsatzgebiete vorstellen:
-
Videodienste á la YouTube, wo das Video im Mittelpunkt steht. Kein Videoautor würde ernsthaft eine alternative Textversion seines Videos einstellen wollen, oder?
-
Vielleicht Präsentationen oder dergleichen, die durchaus viel Text beinhalten. Dann sollte man die Reintextalternative nicht als Fallback-Inhalt verstecken, sondern jedem Benutzer zugänglich machen. Auch, wenn ich nicht blind bin, will ich ja vielleicht Teile der Texte herauskopieren.
Oder nenne du mir einen Anwendungsfall, in dem du mit den von HTML 5 zur Verfügung gestellten Mitteln nicht zurecht kommst. Die genauen Beweggründe zu den Worten in der <video>-Spezifikation kenne ich zwar übrigens nicht, bin mir aber ziemlich sicher, dass sie weitestgehend meiner Argumentation oben entsprechen. Und im Zweifelsfall hilft halt eine Google-Suche mit site:lists.whatwg.org oder site:lists.w3.org.
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.
Ich habe von der Einbindung proprietärer Formate per <object> nicht wirklich Ahnung, sodass ich nicht zu viel zu diesem Thema sagen kann und will. Ich glaube aber nicht, dass in HTML 5 noch mehr Proprietäres steht als zwingend nötig, sofern denn überhaupt etwas. Falls doch: Soweit ich weiß, ist die von dir vorgeschlagene, strikte Lösung die, die allen in WHATWG und W3C HTML WG, auf jeden Fall auch mir persönlich am liebsten wäre. Aber dann dürfte es viele Technologien geben – Flash? Java? Windows Media? Real? –, die auf diesem Wege nicht mehr laufen würden. Dann gilt wieder das, was ich weiter oben zum Thema „Yet another praxisferner Standard, an den ich mich zu halten keine Lust habe“ gesagt habe: Ein validierendes Dokument wird zu einer unüberwindbaren Hürde und ist für viele keine realistische Option mehr. Aber wie gesagt, mit dem Thema kenne ich mich nicht wirklich aus, von daher ist das, was ich hier gerade sage, womöglich auch Unsinn.
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.
Ob du dem 08/15-Benutzer sagst „Bitte installieren Sie den längst eingestellten Adobe SVG Viewer, um sich meine tolle Schaugrafik als genial skalierbare Vektorgrafik ansehen zu können“ oder „Bitte installiere das IE-OGG-Plugin, um dir mein heißes Partyvideo anzusehen“, ist schon ein Unterschied. Du verstehst, was ich meine? :-) Den Flash Player installieren ja auch (fast) alle…
[…] 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?
Wie gesagt, dafür ist die WHATWG ja offen. Natürlich kommen sie nicht zu dir nach Hause und fragen, was du dir so für HTML 5 wünschst. Aber es gibt Mailing Lists, Foren und IRC, damit du deine Wünsche äußern kannst.
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>).
Danach geht es nicht immer nur, aber auch danach geht es, selbstverständlich. Wenn es von oben heißt „Nein, das implementieren wir nicht, weil es zu umständlich wäre“, macht es wohl keinen Sinn, entsprechendes dennoch in die Spezifikation zu schreiben, um den Entwickler zu besänftigen. Zumal die Spezifikation beim W3C eh nicht über das CR-Stadium herauskommen wird, wenn nicht zwei funktionierende Implementierungen existieren.
Einfache und klarer Regeln die gut nachzuprüfen sind wären eigentlich genau die Stärke von XHTML.
Augenblick! Inwiefern sind denn die HTML5-Regeln weniger einfach und klar und weniger gut nachzuprüfen als beispielsweise die von XHTML 1.0? In der XHTML 1.0-Spezifikation gibt es, sofern ich mich recht erinnere, gar keine Erläuterungen zu Elementen und Attributen; die HTML 4.01-Spezifikation hat mir bei Problemen noch nie weitergeholfen, außer wenn es nur darum ging, ob ein Element oder ein Attribut existiert oder nicht.
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.
Das war mein Ziel. Freut mich sehr, das zu hören :-)
-david
Gunnar Bittersmann
Der Martin