Julia: Wie <tr value=... XHTML Strict-konform umsetzen?

Hi,
ich habe eine Tabelle mit HTML erstellt, die ungefähr so aussieht:

Name     | Vorname
Müller     Max
Meier      Kurt
Schneider  Hans

Die Namen sollen verlinkt werden mit einer Detailseite für die jeweiligen Einträge. Ich wollte jedoch nicht nur den Nach-/ Vornamen verlinken, sondern den kompletten Namen. Dazu habe ich dem tr-Element das Attribut value (enthält die aufzurufende Seite) und ein onclick-Ereignis mitgegeben, um per JavaScript die value-Eigenschaft auszuwerten:

  
<table>  
<tr><td>Name</td><td>Vorname</td></tr>  
<tr value="seitemaxmueller.html" onlick=...><td>Müller</td><td>Max</td></tr>  
<tr value="seitekurtmeier.html" onlick=...><td>Meier</td><td>Kurt</td></tr>  
<tr value="seitehanss.html" onlick=...><td>Schneider</td><td>Hans</td></tr>  
</table>  

Die Daten (sowohl Namen als auch Detailseiten) kommen dabei aus einer Datenbank, die Tabelle wird also dynamisch generiert. Das ganze funktioniert soweit wie gewünscht.

Ich versuche nun, die Seite auf XHTML 1.0 Strict umzustellen. Das wiederum kennt kein value-Attribut bei tr. Welches Attribut kann ich stattdessen nehmen oder wie kann ich XHTML 1.0 Strict-konform eine solche Tabelle erstellen?

Viele Grüße,
Julia

  1. <tr value="seitekurtmeier.html" onlick=...><td>Meier</td><td>Kurt</td></tr>

    soll natürlich jeweils ONCLICK heissen...

    1. Mahlzeit Julia,

      <tr value="seitekurtmeier.html" onlick=...><td>Meier</td><td>Kurt</td></tr>

      soll natürlich jeweils ONCLICK heissen...

      Schade ... ;-)

      Aber zurück zu Deiner eigentlichen Frage:

      Schau Dir mal die <http://de.selfhtml.org/html/referenz/attribute.htm#tr@title=erlaubten Attribute für <tr>> an - das sieht schlecht aus ... außer Du "missbrauchst" ein gültiges Attribut für Deine Informationen.

      MfG,
      EKKi

      --
      sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
      1. Hi EKKi,

        soll natürlich jeweils ONCLICK heissen...

        Schade ... ;-)

        ... war wohl eine Freud'sche Fehlleistung. Aber da heute Freitag ist und sich mein Arbeitstag dem Ende zuneigt, möget ihr mir verzeihen :)

        Schau Dir mal die <http://de.selfhtml.org/html/referenz/attribute.htm#tr@title=erlaubten Attribute für <tr>> an - das sieht schlecht aus ... außer Du "missbrauchst" ein gültiges Attribut für Deine Informationen.

        Ja, hab ich auch gemerkt. Das mit dem Mißbrauch zwar versucht, aber kam nicht so gut. Werde dann wohl am Ende oder Anfang jeder Zeile einen Link setzen.

        Danke fürs Denken und viele Grüße,
        Julia

        1. Ja, hab ich auch gemerkt. Das mit dem Mißbrauch zwar versucht, aber kam nicht so gut. Werde dann wohl am Ende oder Anfang jeder Zeile einen Link setzen.

          wenn du meinen post gelesen hast: da wird eine methode (theoretisch) beschrieben, wie du diesen zusätzlichen link trotzdem dazu bringst, sich so zu verhalten wie du es gerne hättest - du musst auf diese funktionalität also nicht verzichten

          1. wenn du meinen post gelesen hast: da wird eine methode (theoretisch) beschrieben, wie du diesen zusätzlichen link trotzdem dazu bringst, sich so zu verhalten wie du es gerne hättest - du musst auf diese funktionalität also nicht verzichten

            Gelesen schon, aber gerade erst richtig verstanden *an den Kopf hau*
            Klappt super! Hab aus dem href ein hidden-Field gemacht, dann brauch ich auch keine Tabellenzellen ausblenden.

            Vielen Dank nochmal!

            1. Klappt super! Hab aus dem href ein hidden-Field gemacht, dann brauch ich auch keine Tabellenzellen ausblenden.

              die bessere lösung wäre aber die mit dem <a>-element, die variante die du jetzt hast, funktioniert ohne javascript nicht - daran solltest du immer denken

              javacript ist immer ein extra goodie welches zusätzliche features einbauen soll, aber ohne javascript darf kein nachteil entstehen

              aktuell entsteht bei dir ein nachteil, weil der link eben ohne js nicht bedienbar ist

    2. <tr value="seitekurtmeier.html" onlick=...><td>Meier</td><td>Kurt</td></tr>

      soll natürlich jeweils ONCLICK heissen...

      nein, in xhtml 1.0 strict MUSS es "onclick" heissen ;)

      da value-attribut gibts auch nicht in den transitional varianten nicht in einem tr-element, woher du das hast ist mir in rätsel ;)

      aber wenn du etwas verlinken willst, würd ich es mit einem link versuchen ;) - so in etwa:
      <table><tr onclick="location.href = this.childNodes(0).childNodes(0).href";><td id="blah"><a href="seitekurtmeier.html">Detailinformation</a></td><td>Meier</td><td>Kurt</td></tr></table>
      <script type="text/javascript">
        window.onload = function() {
          document.getElementById('blah').style.display = 'none';
        }
      </script>

      Die erste Tabellenzelle sollte natürlich keine id erhalten, diese blendest du am besten mit rows/cols in einer schleife per javascript aus

      wenn jemand kein javascript hat, bekommt er die tabelle mit einem hyperlink davor ;)

      1. Hi suit!

        soll natürlich jeweils ONCLICK heissen...
        nein, in xhtml 1.0 strict MUSS es "onclick" heissen ;)

        Besserwisser! ;-)

        da value-attribut gibts auch nicht in den transitional varianten nicht in einem tr-element, woher du das hast ist mir in rätsel ;)

        irgendwo mal gesehen und probiert. Hatte auch funktioniert ;-)

        aber wenn du etwas verlinken willst, würd ich es mit einem link versuchen ;) - so in etwa:
        <table><tr onclick="location.href = this.childNodes(0).childNodes(0).href";><td id="blah"><a href="seitekurtmeier.html">Detailinformation</a></td><td>Meier</td><td>Kurt</td></tr></table>
        <script type="text/javascript">
          window.onload = function() {
            document.getElementById('blah').style.display = 'none';
          }
        </script>

        Danke für deine Antwort! So werde ich es wohl machen.

        Viele Grüße,
        Julia

        1. Hi,

          irgendwo mal gesehen und probiert. Hatte auch funktioniert ;-)

          [# 900]

          Cheatah

          --
          X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
          X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
          X-Will-Answer-Email: No
          X-Please-Search-Archive-First: Absolutely Yes
  2. Hallo Julia,

    Welches Attribut kann ich stattdessen nehmen oder wie kann ich XHTML 1.0 Strict-konform eine solche Tabelle erstellen?

    Erstelle doch einfach eine weitere td-Datenzelle pro Reihe mit dem Link, der dann auch ohne JS problemlos erreichbar ist. Setze alternativ den Wert als Variable beim onclick-Handler: <tr onclick="var value='seite.html';machwas(value)">...</tr>

    Grüße,
    Thomas

    1. Hi Thomas!

      Erstelle doch einfach eine weitere td-Datenzelle pro Reihe mit dem Link, der dann auch ohne JS problemlos erreichbar ist. Setze alternativ den Wert als Variable beim onclick-Handler: <tr onclick="var value='seite.html';machwas(value)">...</tr>

      Danke für deine Antwort! So ähnlich werde ich es wohl machen.

      Viele Grüße,
      Julia

  3. Hi,

    Die Namen sollen verlinkt werden mit einer Detailseite für die jeweiligen Einträge. Ich wollte jedoch nicht nur den Nach-/ Vornamen verlinken, sondern den kompletten Namen.

    da dieser in zwei getrennte Elemente aufgeteilt ist, ergibt das eben zwei Links. Wo ist das Problem?

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. da dieser in zwei getrennte Elemente aufgeteilt ist, ergibt das eben zwei Links. Wo ist das Problem?

      zwei links auf das selbe ziel nebeneinander ist uncool ;) - ein zusätzlicher link und dann ein onlick auf die tabellenzeile ist sicher praktischer

      1. Hi,

        zwei links auf das selbe ziel nebeneinander ist uncool ;)

        dieses Argument trifft bei mir auf eine kalte Schulter ;-)

        ein zusätzlicher link und dann ein onlick auf die tabellenzeile ist sicher praktischer

        Das finde ich eigentlich nicht. Wie ist eigentlich das Look&Feel der beiden verlinkten Flächen, und zwar bei aktiviertem und bei deaktiviertem JavaScript?

        Cheatah

        --
        X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
        X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. Hi Cheatah!

          zwei links auf das selbe ziel nebeneinander ist uncool ;)

          dieses Argument trifft bei mir auf eine kalte Schulter ;-)

          Nein, cool oder nicht ist natürlich nicht die Frage. Vom Empfinden her fand ich es aber auch nicht so schön und hab einfach ein bißchen rumgespielt, ob es auch anders geht. Nur dadurch lernt man schließlich!

          ein zusätzlicher link und dann ein onlick auf die tabellenzeile ist sicher praktischer

          Das finde ich eigentlich nicht. Wie ist eigentlich das Look&Feel der beiden verlinkten Flächen, und zwar bei aktiviertem und bei deaktiviertem JavaScript?

          Diese Frage stellt sich glücklicherweise nicht, da es sich um eine Intranetanwendung handelt und alle Mitarbeiter meiner Firma die selben IE-Einstellungen haben.

          Danke und viele Grüße,
          Julia

          1. zwei links auf das selbe ziel nebeneinander ist uncool ;)
            dieses Argument trifft bei mir auf eine kalte Schulter ;-)
            Nein, cool oder nicht ist natürlich nicht die Frage. Vom Empfinden her fand ich es aber auch nicht so schön und hab einfach ein bißchen rumgespielt, ob es auch anders geht. Nur dadurch lernt man schließlich!

            es geht hier nicht um schön oder nicht sondern um ein usability problem - wenn ich in einer tabellenzeile oder in einem satz oder sonstwo 5 links nebeneinander habe, die alle auf das selbe ziel verweise, verwirrt das den benutzer

            <a href="http://example.com/uber_mich">ich</a> <a href="http://example.com/uber_mich">mag</a> <a href="http://example.com/uber_mich">gerne</a> <a href="http://example.com/uber_mich">speiseeis</a>

            das ist mindestens genauso schlimm wie zusammenklebende links, die auf verschiedene ziele verweisen

            <a href="http://example.com/haus">haus</a><a href="http://example.com/boot">boot</a>

            natürlich ist das bei tabellenzellen ein dilemma - da hilft halt nur 1 link in einer zelle und dann mit onclick das verweisziel einer anderen zelle nutzen

  4. @@Julia:

    <tr><td>Name</td><td>Vorname</td></tr>

    "Name" und "Vorname" sind keine Tabellendaten, sondern Spaltenköpfe. Sollten also nicht 'td'-, sondern 'th'-Elemente sein.

    Es mag sich auch anbieten, sie nicht im 'tbody' (bzw. bei 'application/xhtml+xml direkt in 'table') zu notieren, sondern im 'thead':

    <table>  
      <thead>  
        <tr><th>Name</th><th>Vorname</th></tr>  
      </thead>  
      <tbody>  
        <tr><td>Müller</td><td>Max</td>  
        <!-- ... -->  
      </tbody>  
    </table>
    

    <tr value="seitemaxmueller.html" onlick=...><td>Müller</td><td>Max</td></tr>

    Warum willst du Daten, die du schon hast (Vorname, Name), noch einmal notieren? Wenn die Webseiten zu den einzelnen Personen streng der Namenskonvention folgen, ist das unnötig. Dein JavaScript kann doch die Werte aus den 'td'-Elementen auslesen ("Müller", "Max") und daraus den string "seitemaxmueller.html" zusammensetzen.

    Live long and prosper,
    Gunnar

    --
    Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.
    1. Warum willst du Daten, die du schon hast (Vorname, Name), noch einmal notieren? Wenn die Webseiten zu den einzelnen Personen streng der Namenskonvention folgen, ist das unnötig. Dein JavaScript kann doch die Werte aus den 'td'-Elementen auslesen ("Müller", "Max") und daraus den string "seitemaxmueller.html" zusammensetzen.

      ggf zeigt der verweis dann aber auf personen.php?id=1337 ;)

      1. Hi,

        Warum willst du Daten, die du schon hast (Vorname, Name), noch einmal notieren? Wenn die Webseiten zu den einzelnen Personen streng der Namenskonvention folgen, ist das unnötig. Dein JavaScript kann doch die Werte aus den 'td'-Elementen auslesen ("Müller", "Max") und daraus den string "seitemaxmueller.html" zusammensetzen.

        ggf zeigt der verweis dann aber auf personen.php?id=1337 ;)

        Genauso ist es. Was ich geschrieben habe, sollte nur ein kleines und verständliches Beispiel sein. Natürlich gibt es keine Seite Max Müller, sondern im Hintergrund steht eine ID, die auf einen Eintrag verweist. Und diese ID wird üblicherweise nicht angezeigt.

        Trotzdem danke und viele Grüße,
        Julia

        PS: bitte um Applaus, weil endlich mal jemand nicht seine 1000 Zeilen Code hier reinkopiert, von denen nur 10 relevant sind!

        1. Hallo Julia,

          PS: bitte um Applaus, weil endlich mal jemand nicht seine 1000 Zeilen Code hier reinkopiert, von denen nur 10 relevant sind!

          <applaus intensity="strong" />

          Und noch ein Applaus, weil hier jemand nicht nur Fragen stellt, sondern die Antworten auch liest und zu verstehen versucht, und weil hier jemand (im großen und ganzen) weiß, was er bzw. sie tut. :-)

          <applaus intensity="default" />

          Schönes Wochenende,
           Martin

          --
          F: Was ist schlimmer: Alzheimer oder Parkinson?
          A: Parkinson. Lieber mal ein Bier vergessen zu zahlen, als eins verschütten.
          1. Hi Martin!

            <applaus intensity="strong" />

            Und noch ein Applaus, weil hier jemand nicht nur Fragen stellt, sondern die Antworten auch liest und zu verstehen versucht, und weil hier jemand (im großen und ganzen) weiß, was er bzw. sie tut. :-)

            <applaus intensity="default" />

            *lach*
            danke fürs Kompliment. Gibt leider auch genug Foren (bzw. sicher hier auch genug User), wo die Antworten so abgehoben oder unfreundlich sind, daß man das lieber gar nicht weiter kommentieren möchte.

            Dir einen schönen Start in die Woche und viele Grüße,
            Julia

        2. PS: bitte um Applaus, weil endlich mal jemand nicht seine 1000 Zeilen Code hier reinkopiert, von denen nur 10 relevant sind!

          das ist unmöglich - man kanns niemandem recht machen ;)

          aber du hast dein problem in der tat verständlich beschreiben - das kommt zwar immer häufiger vor, aber ist noch lange keine selbstverständlichkeit

          verbreite dein wissen, sinnvolle fragen zu stellen und verständliche problembeschreibungen zu liefern und dir wird ein platz auf dem rechten fleischklops des fliegenden spaghettimonsters sicher sein

  5. @@Julia:

    wie kann ich XHTML 1.0 Strict-konform eine solche Tabelle erstellen?

    Die einfachste Lösung wäre mit XHTML 2 möglich:

    <tr href="seitemaxmueller.html"><td>Müller</td><td>Max</td></tr>

    In (X)HTML 5:

    <a href="seitemaxmueller.html"><tr><td>Müller</td><td>Max</td></tr></a>

    Völlig ohne JavaScript, und die ganze Tabellenzeile ist _ein_ Link.

    Live long and prosper,
    Gunnar

    --
    Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.
    1. Yerf!

      Die einfachste Lösung wäre mit XHTML 2 möglich:

      <tr href="seitemaxmueller.html"><td>Müller</td><td>Max</td></tr>

      Jo, wird wohl nur leider nie kommen...

      In (X)HTML 5:

      <a href="seitemaxmueller.html"><tr><td>Müller</td><td>Max</td></tr></a>

      <br>, dieses HTML 3.2 reloaded wird mir immer unsympatischer...

      Gruß,

      Harlequin

      --
      <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
      1. <br>, dieses HTML 3.2 reloaded wird mir immer unsympatischer...

        Hmm, darf man die näheren Hintergründe deiner Antipathie erfahren?

        -david

        1. <br>, dieses HTML 3.2 reloaded wird mir immer unsympatischer...

          Hmm, darf man die näheren Hintergründe deiner Antipathie erfahren?

          Offenbar keine vorhanden – nur sinnloses Bashing gegen alles, was einem unbekannt ist.  Schade, ich hatte mich auf fruchtbare Sachdiskussionen gefreut…

          -david

          1. Yerf!

            Offenbar keine vorhanden – nur sinnloses Bashing gegen alles, was einem unbekannt ist.  Schade, ich hatte mich auf fruchtbare Sachdiskussionen gefreut…

            Tschuldigung, dass das hier kein LiveChat ist...

            Gruß,

            Harlequin

            --
            <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
            1. Offenbar keine vorhanden – nur sinnloses Bashing gegen alles, was einem unbekannt ist.  Schade, ich hatte mich auf fruchtbare Sachdiskussionen gefreut…

              Tschuldigung, dass das hier kein LiveChat ist...

              Tschuldigung meinerseits – ich bin aus den heise-Foren schnellere Antwortzeiten gewöhnt…

        2. Yerf!

          <br>, dieses HTML 3.2 reloaded wird mir immer unsympatischer...

          Hmm, darf man die näheren Hintergründe deiner Antipathie erfahren?

          Naja, ich versuch mal trotzdem ein paar Gründe zu liefern...

          Schon alleine das hier gebene Beispiel mit der kaputten Tabellen-Struktur. Was soll das? Klingt für mich wie: schreib was du willst, der Browser wird dann deine Gedanken lesen und es schon "richtig" darstellen...

          oder das eigene Element für Videos, ähm, Object reicht wohl nicht? was kommt demnächst - eigenes Element für PDF, Flash, Java[1] und Word? Ich würd da eher drüber dikutieren ob man wirklich ein eigenes Elemnt für Bilder braucht (Object hätte da einige Vorteile für Browser die keine Bilder können)

          HTML5 erweckt bei mir den Eindruck das mans allen um jeden Preis recht machen will und dabei alle Vorteile einer sauber strukturierten Sprache opfert.

          Und ja... das ist persönlicher Eindruck... nur für den Fall, dass Nachfragen kommen.

          Gruß,

          Harlequin

          [1] ähm, an dem Punkt waren wir doch schon mal...

          --
          <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
          1. <br>, dieses HTML 3.2 reloaded wird mir immer unsympatischer...

            Hmm, darf man die näheren Hintergründe deiner Antipathie erfahren?

            Naja, ich versuch mal trotzdem ein paar Gründe zu liefern...

            Schon alleine das hier gebene Beispiel mit der kaputten Tabellen-Struktur. Was soll das? Klingt für mich wie: schreib was du willst, der Browser wird dann deine Gedanken lesen und es schon "richtig" darstellen...

            Das wage ich mal als Unsinn zu bezeichnen.  HTML 5 befindet sich in einem vollständig offenen Entwicklungsprozess.  Die aktuellste Entwurfsfassung lässt sich an verschiedenen Orten abrufen – hättest du von dieser Möglichkeit Gebrauch gemacht, würdest du definitiv nicht behaupten, HTML 5 erlaube einem, jeden Mist zu schreiben, den der Browser nacher telepathisch interpretieren muss.  Mit ein wenig Wille zur Recherche lassen sich in den Mailing-Listen von WHATWG und W3C HTML WG auch die meisten Entscheidungsprozesse finden.

            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.  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.  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? –, 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.

            oder das eigene Element für Videos, ähm, Object reicht wohl nicht? was kommt demnächst - eigenes Element für PDF, Flash, Java[1] und Word? Ich würd da eher drüber dikutieren ob man wirklich ein eigenes Elemnt für Bilder braucht (Object hätte da einige Vorteile für Browser die keine Bilder können)

            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.  Ob es noch andere Komplikationen gibt, weiß ich gerade nicht zu sagen.  Andererseits sollten Bilder sowieso nicht so extrem viele Informationen beinhalten, dass sie sich nicht in @alt zusammenfassen lassen.  Notfalls tut man eben ein <a> ums <img>, das die Informationen als Text aufbereitet.  Das kann auch sinnvoll sein, wenn der User Agent das Bild anzeigt.

            <video> und <audio> halte ich für die sinnvollsten Entwicklungen in HTML 5 überhaupt, da sie dank OGG wohl erstmals eine simple und transparente Möglichkeit bieten werden, Video- und Audiodateien in Webseiten einzubinden.  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.  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 Initiative der WHATWG zeigt schon Wirkung:  Firefox 3.1 wird wohl bereits mit eingebautem Support für <video> und <audio> kommen; Safari und Opera dürften schnell nachziehen, da die Hersteller auch in der WHATWG vertreten sind.  Für den IE werden brauchbare Plugins hoffentlich nicht lange auf sich warten lassen.

            HTML5 erweckt bei mir den Eindruck das mans allen um jeden Preis recht machen will und dabei alle Vorteile einer sauber strukturierten Sprache opfert.

            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.  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.  Mit Anarchie hat das aber ganz und gar nichts zu tun.

            Und ja... das ist persönlicher Eindruck... nur für den Fall, dass Nachfragen kommen.

            Klar, kein Problem.  Bevor ich mir HTML 5 genauer ansah und mich später zur aktiven Mitarbeit entschloss, entsprach mein Eindruck weitgehend dem deinem heute.  Daher lade ich dich herzlich ein, mal ein paar Abschnitte der Spezifikation probezulesen.  Ich bin mir sicher, dass du von dem pragmatischen, praxisnahen und mit vielen Beispielen ausgestatteten Dokumentationsstil, den wir wohl in erster Linie Ian Hickson zu verdanken haben, begeistert sein wirst.  Schau dir zum Vergleich gern auch mal die HTML 4.01-Spezifikation an – da findest du nur minimale Praxisbeispiele, die praxisrelevante Fragen in aller Regel nicht beantworten.

            Nochmal:  Glaub mir, als ich das erste mal von HTML 5 hörte, fragte ich mich als damaliger XHTML-Fanboy auch, was da für eine gequilte Kacke auf uns zukommt.  Nachdem ich mich ein wenig mit dem Thema auseinandergesetzt hatte, musste ich irgendwann verschämt zugeben, dass HTML 5 einfach nur überzeugt.  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.

            Lieben Gruß

            -david

            1. 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

              --
              <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
              1. 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:

                1. ein uneinheitlicher DOM-Tree, wenn man nicht alle Tabellenzeilen verlinkt. Dann hat man bunt gemischt <tr> und <a> als Kinder von <table>. […]

                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?)

                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>&lt;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:

                1. Videodienste á la YouTube, wo das Video im Mittelpunkt steht.  Kein Videoautor würde ernsthaft eine alternative Textversion seines Videos einstellen wollen, oder?

                2. 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

                1. 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>&lt;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]-->