nicht angemeldet
Yerf!
Ich hoffe mal...
Offen gestanden: Ich auch… ;-)
Das durchlesen der von dir verlinkten Artikle bestärkt diese Hoffnung, da sie sich der Problematik bei Tabellen zumindest bewusst sind.
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.
Es wäre halt trotzdem schade die volle Funktionalität nur mit JS zu bekommen. Man hofft als Webentwickler halt auf eine Verbesserung und Weiterentwicklung anstelle von Stillstand und Hinweisen auf Workarounds.
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.
Bei deinen Links hat man aber schon ein paar Sachen rauslesen können, z.B. CSS (:visited usw.). Da hängt schon einiges dran.
Was ich mich aber wirklich frage, ist, ob ein transparentes <a href> tatsächlich weniger schwer umzusetzen ist als @href.
Das kommt drauf an, wieviel Rücksicht man auf die Webentwickler nimmt... Wenn man sie einfach vor die Problematik stellt, dass eine Tabelle eben im DOM auch in <a>-verpackte Zeilen haben kann macht das für den Browserentwickler weniger Arbeit, aber der Webentwickler ist dann am fluchen, wenn er das im JS berücksichtigen muss. Ein Standard der nur auf die einfache Realisierbarkeit im Browser abziehlt kann irgendwie auch nicht das Ziel sein. Was nützt es, wenn es jeder Browser integriert hat aber keiner Nutzt, weil es an den Bedürfnissen der Webentwickler vorbeigeht?
Gute Fragen. Was transparente Elemente angeht, hilft dir der entsprechende Absatz in der Spezifikation vielleicht zum Teil weiter.
Hm, der klärt zwar die Stellung inerhalb des Dokuments, aber was noch offen bleibt ist, wie diese bei zugriffen auf die Hirarchie betrachtet werden. Für den Fall mit der verlinkten Tabellenzeile bräuchte man eigentlich einen Zugriff auf das DOM, der die transparenten Elemente nicht berücksichtigt. Allerdings bräuchte mann trotzdem auch einen Weg um Zugriff auf die transparenten Elemente selbst zu bekommen.
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.
Das mit der Abwärtskompatiblität ist so eine Sache. Ich glaube nicht, dass sich so einfach per PlugIn eine Unterstützung für <video> einbauen lässt.
<object> geht schon jetzt ganz gut.
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.
Ja, die Radikalkur <img> entfallen zu lassen wäre sicherlich nicht so leicht durchzusetzen. Allerdings wird <video> sicherlich ähnliche Startschwierigkeiten haben.
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](http://meineipadresse.de/netrenderer/)-IE7 dort immerhin das „asdf“ anzeigt. Offenbar gibt es also doch noch Schwierigkeiten. Leider und peinlicherweise.
Ich hab das hier bei mir mit dem IE6 auch mal durchgespielt. Die Anzeige von "asdf" liegt am fehlenden type-Attribut (keine Ahnung, wieso das in dem einen Fall anders ist, aber evtl. versucht sich der IE da an einer Autoerkennung). Das man mit type="image/jpeg" trotzdem nichts sieht liegt daran, dass der IE zwingend height und width benötigt. Dann aber wird das Bild dargestellt, aber leider innerhalb eines Rahmens ähnlich eines IFrames, also als Ersatz für <img> nicht so gut geeignet... (allerdings sollte der IE8 das hinbekommen, ist ja auch Bestandteil vom ACID2-Test)
> Es besteht bestimmt keine Gefahr, dass wir in ein, zwei Jahren ein <pdf> oder <ms-word-doc> sehen werden.
Aber vielleicht ein <ebook> (für nicht HTML-Dokumente z.B. pdf) oder eine Wiedergeburt von <applet> (für eingebundene Programme in z.B. Java/.NET/was-auch-immer). Es gibt sicher noch mehr generische Medien die sich da finden lassen. Wer mit Ausnahmen anfängt muss sich immer wieder der Diskussion stellen, wo und warum er die Grenze zieht.
> > 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...
> Oder nenne du mir einen Anwendungsfall, in dem du mit den von HTML 5 zur Verfügung gestellten Mitteln nicht zurecht kommst.
Man könnte im Alternativinhalt für Leute, die das Video gerade nicht abspielen können (kein Player vorhanden oder Rechner zu schwach) ein paar Bilder + Beschreibung geben, anhand dessen sie entscheiden können, ob es sich lohnt das Video herunterzuladen (Link dafür ebenso im Alternativinhalt) um es sich dann aucf einem anderen Rechner anschauen zu können.
> Die genauen Beweggründe zu den Worten in der [<video>-Spezifikation](http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video) kenne ich zwar übrigens nicht, bin mir aber ziemlich sicher, dass sie weitestgehend meiner Argumentation oben entsprechen.
Ich denke mal, dass auch die Leute hinter dem [BITV](http://www.einfach-fuer-alle.de/artikel/bitv/begruendung/) ihre Gründe für Punkt IV.8. hatten. Da sehe ich halt schon eine gewisse Diskrepanz.
> Aber dann dürfte es viele Technologien geben – Flash? Java? Windows Media? Real? –, die auf diesem Wege nicht mehr laufen würden.
Flash und Java funktionieren schon jetzt problemlos mit <object>, Videos (egal ob WindowsMedia oder was anderes) sollten auch gehen, vor allem auch unabhängig vom tatsächlichen PlugIn, dass das Video ausgibt. Der Browser entscheidet anhand des Type-Attributs, an welches PlugIn oder Programm er weiterleitet.
Probleme gibts eigentlich nur bei zu alten Browsern oder wenn man die teilweise empfohlene "defekte" Flash-Einbindung per <object> benutzt. Da ist eine Variante im Umlauf, bei der ein Attribut fehlt, weshalb ein <embed> als Fallback innerhalb des <object> notwendig wird.
> 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…
Ja, den Sinn eines SVG-PlugIns kann man dem User etwas schwerer klar machen. Aber dafür wären die Vorteile für den Webentwickler gewaltig: frei ohne Qualitätsverlust skalierbare Designelemente.
> 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.
Hm, das könnte man auch auf vieles andere noch ausdehnen (Politik, OpenSource-Software usw.) und irgendwann stellt man fest, dass einem die Zeit nicht reicht... Klar ist es blöd nur zu meckern und sich nicht weiter einzubringen, aber komplett meine Klappe halten kann ich dann halt doch nicht.
> 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.
Das ist schon klar, aber irgendwie auch schade... Anstatt, dass die Browserhersteller einmal etwas Aufwand reinstecken und man dann eine vernünftige Lösung hätte gibts nur Workarounds.
> Zumal die Spezifikation beim W3C eh nicht über das CR-Stadium herauskommen wird, wenn nicht zwei funktionierende Implementierungen existieren.
Vielleicht hätte ich meine Zeit in eine Referenzimplementierung für XHTML stecken sollen, um zu zeigen: es geht doch! Aber der Zug dürfte inzwischen abgefahren sein...
> > 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?
Mir geht es dabei vor allem um den Syntaxunterschied zwischen XML und SGML. In HTML sind ja einige "Wildwüchse" erlaubt, die so kein Browser unterstützt (womit eigentlich kein Browser HTML \*wirklich\* kann). Vor allem auch das implizite öffnen und schließen von Tags kann für einige Verwirrung und unerwartete Ergebnisse sorgen. Bei X(HT)ML ist das klarer geregelt und ein Validator kann einem sauber sagen, was falsch ist. Wenn man den gleich in den Editor integriert bedeutet das auch keinen Mehraufwand für den Author.
> 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.
Wie gut die Specs ausgearbeitet sind kann ich jetzt nicht vergleichen, aber es sollte eigentlich kein Problem sein, diese zu Erweitern.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. [Get one today!](http://www.opera.com)<![endif]-->
suit
Gunnar Bittersmann
Der Martin