W3C startet Ideensammlung für HTML6 • Peter Kröner • Webtechnologie • Archiv

Kommentare (13)

Chris ¶

21. April 2011, 09:57 Uhr
Schonwieder eine neue Spec...
```
Toll
```
Was ich mir für HTML"6" wünsche:

- Keine alten Browser - äh ich meinte IE<9 - mehr die den Fortschritt aufhalten

- Automatische Browser-Updates ala Chrome

- Einheitlich implementiertes CSS ohne -moz, -mäh und -xyz (Die Browserhersteller sollten nicht mit "woooah wir sind die besten weil wir -mäh implemtiert haben" protzen, sondern eher mit "woooah wir haben alle CSS-Eigenschaften laut Spec implementiert".)

- Eine ECHTE HTML-Spec, keine HTML Nr. X-Spec welche immer mehr persönlich toll empfundene XML-Elemente beinhaltet. Als nächstes kommt
```
<sitemap>, <news> und <products>
```
als TAGS. Weniger ist manchmal mehr.
non ¶

21. April 2011, 10:44 Uhr

Dass solcher Unsinn wie , uvm. endlich ins Nirvana katapultiert werden.
Peter ¶

21. April 2011, 10:50 Uhr

Zitat non:

Dass solcher Unsinn wie , uvm. endlich ins Nirvana katapultiert werden.

Was ist denn an denen Unsinn?
Markus ¶

21. April 2011, 14:43 Uhr

Zitat Peter:

Zitat non:

Was ist denn an denen Unsinn?

Weil sie (laut deinem Buch) für das Auszeichnen von Abschnitten gedacht sind, für die es eigene Elemente geben sollte – <teaser> wurde ja bereits erwähnt.
Peter ¶

21. April 2011, 14:44 Uhr

Kann dir nicht folgen. Die sind ganz sicher nicht für das Auszeichnen ganzer Abschnitte gedacht. Nur für einzelne Textpassagen, die vom Rest-Inhalt abgesetzt werden, ohne besondere Auf- oder Abwertung zu erfahren. Wie spielen Teaser da hinein?
Markus ¶

21. April 2011, 15:09 Uhr

Zitat Peter:

Kann dir nicht folgen. Die sind ganz sicher nicht für das Auszeichnen ganzer Abschnitte gedacht. Nur für einzelne Textpassagen, die vom Rest-Inhalt abgesetzt werden, ohne besondere Auf- oder Abwertung zu erfahren. Wie spielen Teaser da hinein?

Nun, wie würdest du einen Teaser in HTML5 auszeichnen? In deinem HTML5-Buch hast du  oÄ verwendet – korrigiere mich, wenn es in einer aktuellen Auflage nicht so ist.
Peter ¶

21. April 2011, 15:20 Uhr

Stimmt: mit einem  kann man einen Teaser machen. Aber man kann nicht alle Anwendungsfälle von  mit dem vorgeschlagenen <teaser> abdecken.

Außerdem halte ich die <teaser>-Idee ohnehin für Käse, weil Teaser etwas sind, das in der Mehrzahl der Websites nicht vorkommt – anders als Header, Footer und Navigationen. Was kaum einer benutzt, muss nicht in die Spezifikationen.
XHTML-Verfechter ¶

21. April 2011, 17:06 Uhr
Zitat Peter:

Was ist denn an denen Unsinn?

Ganz einfach: Elemente wie , , , <tt>, <strike>, <big> usw. passen nicht in das Konzept der Trennung von Markup und Layout (von Informationsgehalt und äußerer Form). Während (X)HTML den Zweck erfüllt, dem Inhalt semantische Bedeutung zuzuweisen, ist CSS dazu gedacht, dem Dokument eine angemessene Darstellung zu verschaffen. (X)HTML soll also ausschließlich der inhaltlichen Strukturierung von Dokumenten dienen. Da dieser Design-Grundsatz in den Anfangszeiten des WWWs oft missverstanden oder einfach nicht angewendet wurde, entstanden einige HTML-Elemente (u.a. die oben genannten), die ausschließlich der grafischen Darstellung dienen sollten. So formatiert ein Element fett, kursiv, unterstrichen, formatiert ausschließlich Schrift (ganz schlimm!) usw.. Dabei wird den Elementen aber keinerlei strukturelle Bedeutung zugewiesen! Dass font, tt, u usw. keine Semantik bringen, ist wohl offensichtlich. Nicht so einfach ist es hingegen mit b und i: Viele meinen, sie seien synonym zu strong und em – schließlich würden beide den selben Effekt erzielen. Dies ist aber nicht richtig! b und i stellen lediglich eine Formatierungsanweisung an den Browser dar ( ist sozusagen ein kürzeres ); strong jedoch sagt: Dieser Text soll hervorgehoben sein. Dabei lässt sich im Sinne der Trennung von Markup und Layout zusätzlich definieren, wie dieser hervorgehobene Text nun eigentlich aussehen soll. Beispielsweise in Sperrschrift:
```
strong {
 font-weight: normal;
 letter-spacing: 0.3em;
}
```
Altlasten wie diese Elemente sollten deswegen auch meiner Meinung nach entfernt werden. HTML 5 weist dagegen sogar eine gänzlich veränderte neue Definition des -Elements vor, die für noch mehr Verwirrung sorgt und eine browserseitige Abwärtskompatibilität zu HTML 4 unmöglich macht...

So viel dazu. Dies ist aber nur einer der meiner Meinung nach unnötigen Design-Fehler von HTML 5. Statt darüber nachzudenken, was man sonst noch für Zeug in zukünftiges HTML implementieren kann, würde ich eher noch einmal die Schwächen von HTML 5 genau beleuchten und ausmerzen. Generell finde ich die teilweise inkonsequente Umsetzung einiger Features und den überstürzten Entstehungsprozess an sich sehr unschön. Ein Beispiel sind die vielen neuen teils widersprüchlichen strukturierenden Elemente, die ich eher verwirrend finde. Bisher haben mir immer meine <div>s ausgereicht, um größere zusammenhängende Blöcke kenntlich zu machen – es lässt sich also schon über die Notwendigkeit dieser Elemente streiten. Das abgelehnte XHTML 2 hätte z.B. das role-Attribut für mehr Semantik vorgesehen (siehe (X)HTML 5 im Vergleich zu XHTML 2), es konnte sich nur leider nicht durchsetzen. Warum? Weiß man nicht genau, irgendwer wollte einfach viel lieber HTML 5 durchboxen (so viel zum Entstehungsprozess).

Desweiteren finde ich es schade, dass HTML 5 keine wirklichen XML-konformen Erweiterungsmöglichkeiten vorsieht, mit denen sich nahezu beliebige XML-Sprachen einbetten lassen würden. Stattdessen wurden in HTML 5 MathML und SVG aufgenommen, als wären diese ein Bestandteil von HTML 5! Dies ist nicht nur inkonsequent, sondern bringt auch einige Nachteile mit sich: So könnte es zu Problemen kommen, wenn beispielsweise in HTML und SVG gleiche Element- oder Attributnamen sein würden (oder falls zukünftige Spezifikationen solche beinhalten). Außerdem können ohne weiteres keine anderen Sprachen wie SMIL, RDF etc. aufgenommen werden. In einem Satz: Ich finde es schade, dass das X in HTML 5 fehlt.

Das ist wohl nun erstmal genug Kritik. Es gibt schließlich auf genügend anderen Seiten noch viel davon (Wikipedia, Webkompetenz-Blog) Zusammenfassend kann ich nur sagen, dass ich es unangemessen finde, jetzt schon über zukünftige Features von HTML zu reden, während HTML 5 sich noch in Entwicklung befindet und noch mehrere massive Probleme nicht abgearbeitet sind.
alex ¶

21. April 2011, 17:11 Uhr

Webforms:
- bessere Zusammenarbeit mit CSS3 um input typen sowie Fehleranzeige gestalten zu können (ähnliches gilt für die interaktiven elemente)
- checkValidity-methode für fieldset sollte das machen, was man meint was es macht und nicht per definition false returnen
- content-attribut errormessage (setCustomValidity ist so schrecklich)
- setCustomValidityRule an form-element (wie unter 3.)
- forminvalid-event (allgemeins extended invalid-event für das form mit invalidlist-property)
- validitychanged-event
- group-required für type=checkbox (hätten required für checkbox eigentlich identisch zu radio definieren sollen)
- required für select einfach mal so definieren, dass man es versteht (den unterschied merkt eh keiner)

Mediaqueries für mehr HTML-Element insbesondere:
- img
- script

Video/Audio
- deklarative Controls: [button type="play-pause"][/button] (gerne auch für playlisten)
- Standard für Streaming
Markus Schlegel ¶

21. April 2011, 17:26 Uhr
Zitat XHTML-Verfechter:
Zitat Peter:

Ganz einfach: Elemente wie , , , <tt>, <strike>, <big> usw. passen nicht in das Konzept der Trennung von Markup und Layout (von Informationsgehalt und äußerer Form). Während (X)HTML den Zweck erfüllt, dem Inhalt semantische Bedeutung zuzuweisen, ist CSS dazu gedacht, dem Dokument eine angemessene Darstellung zu verschaffen. (X)HTML soll also ausschließlich der inhaltlichen Strukturierung von Dokumenten dienen. Da dieser Design-Grundsatz in den Anfangszeiten des WWWs oft missverstanden oder einfach nicht angewendet wurde, entstanden einige HTML-Elemente (u.a. die oben genannten), die ausschließlich der grafischen Darstellung dienen sollten. So formatiert ein Element fett, kursiv, unterstrichen, formatiert ausschließlich Schrift (ganz schlimm!) usw.. Dabei wird den Elementen aber keinerlei strukturelle Bedeutung zugewiesen! Dass font, tt, u usw. keine Semantik bringen, ist wohl offensichtlich. Nicht so einfach ist es hingegen mit b und i: Viele meinen, sie seien synonym zu strong und em – schließlich würden beide den selben Effekt erzielen. Dies ist aber nicht richtig! b und i stellen lediglich eine Formatierungsanweisung an den Browser dar ( ist sozusagen ein kürzeres ); strong jedoch sagt: Dieser Text soll hervorgehoben sein. Dabei lässt sich im Sinne der Trennung von Markup und Layout zusätzlich definieren, wie dieser hervorgehobene Text nun eigentlich aussehen soll. Beispielsweise in Sperrschrift:
```
strong {
 font-weight: normal;
 letter-spacing: 0.3em;
}
```
Altlasten wie diese Elemente sollten deswegen auch meiner Meinung nach entfernt werden. HTML 5 weist dagegen sogar eine gänzlich veränderte neue Definition des -Elements vor, die für noch mehr Verwirrung sorgt und eine browserseitige Abwärtskompatibilität zu HTML 4 unmöglich macht...

So viel dazu. Dies ist aber nur einer der meiner Meinung nach unnötigen Design-Fehler von HTML 5. Statt darüber nachzudenken, was man sonst noch für Zeug in zukünftiges HTML implementieren kann, würde ich eher noch einmal die Schwächen von HTML 5 genau beleuchten und ausmerzen. Generell finde ich die teilweise inkonsequente Umsetzung einiger Features und den überstürzten Entstehungsprozess an sich sehr unschön. Ein Beispiel sind die vielen neuen teils widersprüchlichen strukturierenden Elemente, die ich eher verwirrend finde. Bisher haben mir immer meine <div>s ausgereicht, um größere zusammenhängende Blöcke kenntlich zu machen – es lässt sich also schon über die Notwendigkeit dieser Elemente streiten. Das abgelehnte XHTML 2 hätte z.B. das role-Attribut für mehr Semantik vorgesehen (siehe (X)HTML 5 im Vergleich zu XHTML 2), es konnte sich nur leider nicht durchsetzen. Warum? Weiß man nicht genau, irgendwer wollte einfach viel lieber HTML 5 durchboxen (so viel zum Entstehungsprozess).

Desweiteren finde ich es schade, dass HTML 5 keine wirklichen XML-konformen Erweiterungsmöglichkeiten vorsieht, mit denen sich nahezu beliebige XML-Sprachen einbetten lassen würden. Stattdessen wurden in HTML 5 MathML und SVG aufgenommen, als wären diese ein Bestandteil von HTML 5! Dies ist nicht nur inkonsequent, sondern bringt auch einige Nachteile mit sich: So könnte es zu Problemen kommen, wenn beispielsweise in HTML und SVG gleiche Element- oder Attributnamen sein würden (oder falls zukünftige Spezifikationen solche beinhalten). Außerdem können ohne weiteres keine anderen Sprachen wie SMIL, RDF etc. aufgenommen werden. In einem Satz: Ich finde es schade, dass das X in HTML 5 fehlt.

Das ist wohl nun erstmal genug Kritik. Es gibt schließlich auf genügend anderen Seiten noch viel davon (Wikipedia, Webkompetenz-Blog) Zusammenfassend kann ich nur sagen, dass ich es unangemessen finde, jetzt schon über zukünftige Features von HTML zu reden, während HTML 5 sich noch in Entwicklung befindet und noch mehrere massive Probleme nicht abgearbeitet sind.
So, und jetzt?
Peter ¶

21. April 2011, 17:35 Uhr

Zitat XHTML-Verfechter:

Ganz einfach: Elemente wie , , , <tt>, <strike>, <big> usw. passen nicht in das Konzept der Trennung von Markup und Layout (von Informationsgehalt und äußerer Form). Während (X)HTML den Zweck erfüllt, dem Inhalt semantische Bedeutung zuzuweisen, ist CSS dazu gedacht, dem Dokument eine angemessene Darstellung zu verschaffen [...] Dass font, tt, u usw. keine Semantik bringen, ist wohl offensichtlich.

In HTML5 sind die genannten Elemente semantische Elemente. Früher waren das in der Tat Designanweisungen, jetzt sind sie umdeklariert worden. Grob gesagt besagen beide, dass der ausgezeichnete Inhalt vom Rest-Inhalt abgesetzt werden, ohne besondere Auf- oder Abwertung zu erfahren. Der Designfaktor ist rein historisch. Siehe die Kommentare hier.

Zitat XHTML-Verfechter:

Da dieser Design-Grundsatz in den Anfangszeiten des WWWs oft missverstanden oder einfach nicht angewendet wurde, entstanden einige HTML-Elemente (u.a. die oben genannten), die ausschließlich der grafischen Darstellung dienen sollten.

Das hat nichts mit Missverständnissen zu tun, Konzepte wie Trennung von Inhalt und Design sind so alt wie Auszeichnungssprachen selbst. Das waren Wettbewerbsmerkmale von Browsern, die die Browserkrieger eingeführt haben, um der Konkurrenz zu zeigen wo der Hammer hängt.

Zitat XHTML-Verfechter:

HTML 5 weist dagegen sogar eine gänzlich veränderte neue Definition des -Elements vor, die für noch mehr Verwirrung sorgt und eine browserseitige Abwärtskompatibilität zu HTML 4 unmöglich macht...

Was ist denn daran verwirrend? Wo liegt das Kompatibilitätsproblem? Im Übrigen schreibt sich das „HTML5“, also ohne Leerzeichen.

Zitat XHTML-Verfechter:

Statt darüber nachzudenken, was man sonst noch für Zeug in zukünftiges HTML implementieren kann, würde ich eher noch einmal die Schwächen von HTML 5 genau beleuchten und ausmerzen.

Ich habe mal vor einiger Zeit beschrieben, warum solche HTML5-stoppen-und-überarbeiten-Ideen nichts werden.

Zitat XHTML-Verfechter:

Das abgelehnte XHTML 2 hätte z.B. das role-Attribut für mehr Semantik vorgesehen (siehe (X)HTML 5 im Vergleich zu XHTML 2), es konnte sich nur leider nicht durchsetzen. Warum? Weiß man nicht genau, irgendwer wollte einfach viel lieber HTML 5 durchboxen (so viel zum Entstehungsprozess).

Ich weiß warum: XHTML 2 wäre nicht abwärtskompatibel gewesen und das wollten die Browserhersteller nicht – ganz abgesehen davon, dass (echtes, mit dem richtigen Content Type ausgeliefertes) XHTML prinzipbedingt nicht in den IE6-8 funktioniert. Deshalb stattdessen HTML5.

Zitat XHTML-Verfechter:

Desweiteren finde ich es schade, dass HTML 5 keine wirklichen XML-konformen Erweiterungsmöglichkeiten vorsieht, mit denen sich nahezu beliebige XML-Sprachen einbetten lassen würden.

Natürlich gibt es diese Erwiertungsmöglichkeiten in XHTML5.

Zitat XHTML-Verfechter:

Zusammenfassend kann ich nur sagen, dass ich es unangemessen finde, jetzt schon über zukünftige Features von HTML zu reden, während HTML 5 sich noch in Entwicklung befindet und noch mehrere massive Probleme nicht abgearbeitet sind.

Es ist gar nicht klar, ob es überhaupt jemals ein „Ende“ von HTML5 geben wird. Das W3C geht zwar davon aus, die WHATWG-Arbeitsgruppe nicht. Von daher ist dieser Zeitpunkt genau so gut wie jeder andere.
Thomas Scholz ¶

22. April 2011, 17:10 Uhr

Ich will ein Element für Eigennamen und ein Attribut, das automatische Übersetzungen verbietet. Das aktuelle Durcheinander in dieser Hinsicht empfinde ich als unzumutbar.

Bevor man sich weitere Elemente ausdenkt, möchte ich immer eine konkrete Beschreibung dessen sehen, was ein UA damit anfangen soll. In diesem Punkt sind b und i selbst dem section noch weit voraus.
Perun ¶

22. April 2011, 21:11 Uhr

Ich würde mir wünschen, dass Code-Beispiele die z. B. mit <code type="sample">...</code> ausgezeichnet werden (oder ähnliches), nicht ausgeführt sondern im Browser eben als Code-Beispiele angezeigt werden, also als plain text behandelt werden.

Interessant wäre dann in diesem Zusammenhang ob es die Browserhersteller schaffen könnten eine Syntaxhervorhebung anzubieten. Schließlich ist sie ja in der Quelltextansicht in so ziemlich allen Browser bereits drin.

Kommentare (13)

non ¶

XHTML-Verfechter ¶

alex ¶