Erster Arbeitsentwurf von HTML5 veröffentlicht

[Daniel unreg]

Hallo,

bei all den Diskussionen um die nächste Version des Internet Explorers ist wohl keinem aufgefallen, dass auch die nächste Version von (X)HTML einen neuen Meilenstein erreicht hat (oder es hat keinen interessiert, was ich dann schade fände).

Am 22. Januar wurde nämlich der erste öffentliche Arbeitsentwurf von HTML5 beim W3C veröffentlicht.

Zusätzlich wurde auch ein Dokument zum Vergleich von HTML 4 und HTML 5 veröffentlicht.

Das ist mehr oder weniger der erste Meilenstein, den dieser Entwurf beim W3C gemacht hat, seit er im Mai '07 zur Basis für HTML5 gewählt wurde.

Gruß

[Cheatah]

Hi,

bei all den Diskussionen um die nächste Version des Internet Explorers ist wohl keinem aufgefallen, dass auch die nächste Version von (X)HTML einen neuen Meilenstein erreicht hat (oder es hat keinen interessiert, was ich dann schade fände).

doch, es ist sowohl aufgefallen, als auch auf Interesse gestoßen. Ich vermute eher, dass es vielen wie mir geht: Ich nehme diese Entwicklung mit zerknirschter Besorgnis auf. Anders ausgedrückt:

Ceterum censeo HTMLam esse de..., ähm, deplacendam durch XHTML. Dass der nicht-XML-konforme HTML-Zweig weiterentwickelt wird, halte ich für falsch.

Cheatah

[Daniel unreg]

Hallo,

doch, es ist sowohl aufgefallen, als auch auf Interesse gestoßen.

Dann ist das an mir spurlos vorbeigegangen.

Ich vermute eher, dass es vielen wie mir geht: Ich nehme diese Entwicklung mit zerknirschter Besorgnis auf.

Ich frage mich wirklich, woran das liegen mag. Nicht bei dir im speziellen, sondern allgemein hat HTML5 einen relativ schlechten Ruf, denn ich nicht nachvollziehen kann.

Dass der nicht-XML-konforme HTML-Zweig weiterentwickelt wird, halte ich für falsch.

Wenn ich bedenke, dass das im Web vorhandene XHTML ebenfalls nicht XML-konform ist, sehe ich keinen Vorteil darin, nur auf XHTML zu setzen.

Ehrlichgesagt finde ich HTML als XML auch etwas schwirig. Vielleicht denke ich hier in die falsche Richtung, aber XHTML 6 kann von Browsern die nur XHTML 5 verstehen nicht verarbeitet werden, weil sicherlich neue Elemente und Attribute dazukommen.

HTML 6 wird aber sehr wohl von reinen HTML 5 Browsern verarbeitet werden können, was für mich schon ein Vorteil gegenüber ist. So hat HTML schon immer funktioniert.

Noch besser an HTML 5 gefällt mir, dass Fehlerbehandlung definiert wird. So wird sich HTML 5 besser auf Fehler prüfen lassen können als HTML 4 und ähnliche oder genausogute Interoperabilität zwischen den Browsern ermöglichen.

Gut, das ganze ist wohl auch noch theorethisch. Aber mir gefällt die Vorstellung.

Gruß

[Cheatah]

Hi,

[...] allgemein hat HTML5 einen relativ schlechten Ruf, denn ich nicht nachvollziehen kann.

HTML ist technisch betrachtet eine Katastrophe - schon allein aufgrund der Tatsache, dass es die simplen Regeln, die ein XML ausmacht, nicht besitzt. Das reicht bereits, um eine ablehnende Haltung zu rechtfertigen, zumal die Entwicklung des letzten Jahrzehnts (so in etwa jedenfalls) ganz klar zu XML hin ging. Betrachtet man dann noch die Unterschiede zwischen HTML 5 und XHTML 2 im Elementumfang, dann fragt man sich, was die Leute beim W3C wohl geraucht haben.

Wenn ich bedenke, dass das im Web vorhandene XHTML ebenfalls nicht XML-konform ist, sehe ich keinen Vorteil darin, nur auf XHTML zu setzen.

Weder kann man einem Standard vorwerfen, dass er von schlechten Technikern miserabel verwendet wird, noch ist dies ein Grund, auf etwas zu setzen, was schon im Wesen eine miserable Umsetzung *verlangt*.

Ehrlichgesagt finde ich HTML als XML auch etwas schwirig.

XML respektive darauf aufsetzende Derivate sind *immer* leichter als etwas wie HTML. Man braucht sich nicht mit zig Ausnahmeregeln herumzuschlagen.

Vielleicht denke ich hier in die falsche Richtung, aber XHTML 6 kann von Browsern die nur XHTML 5 verstehen nicht verarbeitet werden, weil sicherlich neue Elemente und Attribute dazukommen.
HTML 6 wird aber sehr wohl von reinen HTML 5 Browsern verarbeitet werden können, was für mich schon ein Vorteil gegenüber ist.

Wie kommst Du darauf? XHTML/(n+1) ist im Vergleich zu zu XHTML/(n) immer exakt so gut zu verarbeiten, wie es bei HTML/(n+1) zu HTML/(n) der Fall ist.

So hat HTML schon immer funktioniert.

XHTML auch.

Noch besser an HTML 5 gefällt mir, dass Fehlerbehandlung definiert wird.

Die gab es ebenfalls schon vorher.

So wird sich HTML 5 besser auf Fehler prüfen lassen können als HTML 4 und ähnliche oder genausogute Interoperabilität zwischen den Browsern ermöglichen.

Ja, aber immer noch um einiges schlechter als jedes XML-Derivat.

Cheatah

[Daniel unreg]

Hallo,

zumal die Entwicklung des letzten Jahrzehnts (so in etwa jedenfalls) ganz klar zu XML hin ging.

Die Entwicklung des letzten Jahrzehnts ging aber leider an den Autoren vorbei. Wobe ich zugeben muss, dass das nicht wirklich deren verschulden war. Dennoch glabe ich nicht wirklich, dass sich das Web XMLisieren lässt. Zumindest nicht in absehbarer Zeit. Dass das Vorteile hätte will ich keinesfalls verschweigen.

Betrachtet man dann noch die Unterschiede zwischen HTML 5 und XHTML 2 im Elementumfang, dann fragt man sich, was die Leute beim W3C wohl geraucht haben.

Nunja, HTML 5 will rückwärtskompatibel sein, XHTML 2.0 etwas völlig neues. Letzteres versagt dabei, z.B. wenn das body-Elemente bestehen bleibt. Das braucht doch kein Mensch.

Was wäre denn deiner Meinung nach hier notwendig bzw. überflüssig?

Weder kann man einem Standard vorwerfen, dass er von schlechten Technikern miserabel verwendet wird, noch ist dies ein Grund, auf etwas zu setzen, was schon im Wesen eine miserable Umsetzung *verlangt*.

Gut, hier hast du natürlich recht ;)

Wie kommst Du darauf? XHTML/(n+1) ist im Vergleich zu zu XHTML/(n) immer exakt so gut zu verarbeiten, wie es bei HTML/(n+1) zu HTML/(n) der Fall ist.

Ah, stimmt. Ich nahm an, wenn der Browser auf XHTML 5 stößt würde er z.B. beim charset-Attribut im Metaelement mit einem Fehler abbrechen. Da dem nicht so ist, kann man das Argument natürlich in die Tonne treten.

Die gab es ebenfalls schon vorher.

Aber nicht in dem Umfang.

Ja, aber immer noch um einiges schlechter als jedes XML-Derivat.

Da bin ich mir nicht so sicher.

Aber egal. HTML 5 bemüht sich glücklicherweise, die Verbleibenen Unterschiede zwischen HTML und XHTML zu verrringern, so dass ein Umstieg relativ problemlos verlaufen kann.

Gruß

[Sven Schodt]

Hi Cheatah,

HTML ist technisch betrachtet eine Katastrophe - schon allein aufgrund der Tatsache, dass es die simplen Regeln, die ein XML ausmacht, nicht besitzt.

Was bitte ist denn 'ein XML' - oder meinst du eine Anwendung von XML, so wie HTML eine Anwendung von SGML ist?

XML wurde insbesondere im Hinblick auf die Schwächen von SGML entwickelt.
Manchmal lernt man ja auch aus den Sünden der Vergangenheit.
Tim Berners-Lee stand XML noch nicht zur Verfügung - und es wird wohl niemand HTML als technisch gelungen bezeichnen.

Ciao Sven

[Cybaer]

Hi,

Betrachtet man dann noch die Unterschiede zwischen HTML 5 und XHTML 2 im Elementumfang, dann fragt man sich, was die Leute beim W3C wohl geraucht haben.

Das bittere Kraut der Erkenntnis, daß es absolut sinnfrei ist, irgendwelche (gut gemeinten) Standards zu verabschieden, die dann die relevanten Leute (=Browserhersteller) bestenfalls ausgedruckt mit aufs Klo nehmen (wofür auch immer).

Ja, aber immer noch um einiges schlechter als jedes XML-Derivat.

Was ist eigentlich der propagierte Grund dafür, nicht zwingend auf XHTML-Syntax zu setzen?

Gruß, Cybaer

[molily]

Hallo,

dann fragt man sich, was die Leute beim W3C wohl geraucht haben.
Das bittere Kraut der Erkenntnis, daß es absolut sinnfrei ist, irgendwelche (gut gemeinten) Standards zu verabschieden, die dann die relevanten Leute (=Browserhersteller) bestenfalls ausgedruckt mit aufs Klo nehmen (wofür auch immer).

Zur Masturbation jedenfalls nicht. ;)

Mathias

[Cybaer]

Hi,

Das bittere Kraut der Erkenntnis, daß es absolut sinnfrei ist, irgendwelche (gut gemeinten) Standards zu verabschieden, die dann die relevanten Leute (=Browserhersteller) bestenfalls ausgedruckt mit aufs Klo nehmen (wofür auch immer).
Zur Masturbation jedenfalls nicht. ;)

Das trifft ja auch nur auf die vom W3C zu! Denn die beschäftigen sich vorwiegend mit sich selbst, und sind offenkundig nicht beziehungsfähig ... >>;->

Gruß, Cybaer

[Daniel unreg]

Hallo,

Was ist eigentlich der propagierte Grund dafür, nicht zwingend auf XHTML-Syntax zu setzen?

Es gibt mehr Browser die HTML verstehen, XHTML aber nicht. HTML hört nicht auf zu existieren.

Gruß

[Cybaer]

Hi,

Es gibt mehr Browser die HTML verstehen, XHTML aber nicht. HTML hört nicht auf zu existieren.

Das ist kein Argument. XHTML 1 ist, jedenfalls so wie es heute eingesetzt wird, ja kompatibel zu HTML. Es sollte den sanften Übergang zum inkompatiblen XHTML 2 gewährleisten, was ja nun, HTML 5 sei Dank, auf die noch längere Bank geschoben wurde. Es wird mit HTML-Content-Type ausgeliefert und ist eigentlich "fehlerhaftes" HTML, was aber den Vorteil hat, die "sauberere" Syntax zu haben (Stichwort: einfachere Maschinenlesbarkeit, weil zwingend ein Elementende gegeben sein muß - "Verschachtelung" ist ja auch bei HTML nicht erlaubt, auch wenn viele Browser das nicht so eng sehen).

Erst wenn es mit XML-Content-Type ausgeliefert wird, gibt es ein Kompatibilitätsproblem.

Aber das muß an ja nicht tun ...
...bzw. kann sich da auf die Clients beschränken, die es als Option anfordern.

Gruß, Cybaer

[Daniel unreg]

Hallo,

Das ist kein Argument. XHTML 1 ist, jedenfalls so wie es heute eingesetzt wird, ja kompatibel zu HTML. Es sollte den sanften Übergang zum inkompatiblen XHTML 2 gewährleisten, was ja nun, HTML 5 sei Dank, auf die noch längere Bank geschoben wurde.

Es ging primär um das Verständnis für den Medientypen. Aber du hast schon recht. XHTML 1.0 ist nicht leichter oder schwerer in HTML5 überzuführen als HTML 4.01.

Es wird mit HTML-Content-Type ausgeliefert und ist eigentlich "fehlerhaftes" HTML, was aber den Vorteil hat, die "sauberere" Syntax zu haben (Stichwort: einfachere Maschinenlesbarkeit, weil zwingend ein Elementende gegeben sein muß - "Verschachtelung" ist ja auch bei HTML nicht erlaubt, auch wenn viele Browser das nicht so eng sehen).

Das Problem ist nur, dass viele Autoren, die XML-Syntax nutzen, diese nicht überprüfen, weil sie zwar wissen, dass XML streng geprüft wird, aber die Sache mit dem Medientyp vergessen und daher meinen, was im Browser angezeigt wird, sei in Ordnung.

Aber das muß an ja nicht tun ...
...bzw. kann sich da auf die Clients beschränken, die es als Option anfordern.

Ja, das ist durchaus möglich. Aus aktueller Sicht aber noch etwas Problematisch, da z.B. Safari createElement in XHTML nicht versteht.

Aber auch das soll sich mit HTML5 ändern. Der Entwurf zielt auch darauf aub, die Unterschiede zwischen HTML und XHTML zu verringern.

Zudem wird im Entwurf keine Sprachvariante bevorzugt.

Gruß

[ChrisB]

Hi,

Noch besser an HTML 5 gefällt mir, dass Fehlerbehandlung definiert wird.

Mir eher weniger.

Ich haette eine strengere Auslegung der Regeln begruesst - und auch einen Abbruch des Parse-Vorgangs im Fehlerfalle, wie das bei "richtigem" XML der Fall ist.

Valide Dokumente zu schreiben ist doch problemlos moeglich - also warum jedem, der die noetige (Lern-)Arbeit nicht investieren will, den Arsch nachtragen?

Aufwendige Fehlerkorrekturroutinen blaehen einen Parser unnoetig auf.
Fehlerfrei = ich stell's dar, fehlerhaft = ich lehn's ab.
Das waere simpel und konsequent.

So wird sich HTML 5 besser auf Fehler prüfen lassen können als HTML 4

XHTML laesst sich mittels Schema-Validierung bereits sehr gut auf Fehler ueberpruefen.

MfG ChrisB

[Daniel unreg]

Hallo,

Ich haette eine strengere Auslegung der Regeln begruesst - und auch einen Abbruch des Parse-Vorgangs im Fehlerfalle, wie das bei "richtigem" XML der Fall ist.

Nur XHTML5 ist richtiges XML. HTML5 ist eine Sprache, die von SGM inspiriert wurde.

Valide Dokumente zu schreiben ist doch problemlos moeglich - also warum jedem, der die noetige (Lern-)Arbeit nicht investieren will, den Arsch nachtragen?

Darum geht es ja gar nicht. Es geht darum, den vorhandenen Inhalt des WWWs auch weiterhin verfügbar zu halten. Der HTML5-Parser ist dazu gedach rückwärts und vorwärtskompatibel zu sein. Da müssen alle Browserhersteller mitmachen.

Und die Lösung die jetzt vorhanden ist, verhindert, dass Mozilla, Opera und Apple einen Extraparser für HTML 5 erstellen.

Aufwendige Fehlerkorrekturroutinen blaehen einen Parser unnoetig auf.

Ja, aber die gibt es ja sowieso schon. HTML 5 will hier nur Interoperabilität zwischen den Browsern schaffen, damit im Zweifelsfall eben ein Fehler so und nicht anders korrigiert wird.

Das hat nichts mit dem Erlauben von Tagsoup zu tun. Die ist in HTML 5 genauso unbeliebt.

Fehlerfrei = ich stell's dar, fehlerhaft = ich lehn's ab.
Das waere simpel und konsequent.

Das ist XML.

XHTML laesst sich mittels Schema-Validierung bereits sehr gut auf Fehler ueberpruefen.

Ja, und HTML zieht nach, daran gibts kein Problem.

Gruß

[Christoph Schnauß]

hallo,

Am 22. Januar wurde nämlich der erste öffentliche Arbeitsentwurf von HTML5 beim W3C veröffentlicht.
Zusätzlich wurde auch ein Dokument zum Vergleich von HTML 4 und HTML 5 veröffentlicht.

Na doch, so ganz unbemerkt geblieben ist das nicht. Allerdings hat es im Moment noch keine praktische Bedeutung, die Browser müßten die neue Syntax erstmal verstehen können. Interessant für einige Fragesteller (und ein häufiges Thema hier im Forum) ist vielleicht das hier:
"The following elements are not in HTML 5 because their usage affected usability and accessibility for the end user in a negative way:
   frame
   frameset
   noframes"

Grüße aus Berlin

Christoph S.

[Daniel unreg]

Hallo,

Allerdings hat es im Moment noch keine praktische Bedeutung,

Das sehe ich dann doch etwas anders. HTML 5 definiert nicht einfach nur einen neuen Sprachschatz für HTML und XHTML. Es gibt zahlreiche Features, die zuvor unbekannt waren.

Sicherlich werden HTML5-Parser per Spezifikation erst sehr spät auf den Markt kommen, doch bereits heute haben z.B. das canvas-Element oder die getElementsByClassName-Methode ihren Weg in die Browser und auf Webseiten gefunden. Zugegeben, etwas Hilfe von außen war da schon nötig. Aber gerade das sollte uns doch zeigen, dass uns HTML 5 langsam aber sicher erreicht.

Interessant für einige Fragesteller (und ein häufiges Thema hier im Forum) ist vielleicht das hier

Wobei das leider nicht bedeutet, dass diese Funktionalität irgendwann verschwinden wird :(

Gruß

[Jeena Paradies]

Hallo,

[(i)frame]
Wobei das leider nicht bedeutet, dass diese Funktionalität irgendwann verschwinden wird :(

Ähm es währe sehr schade und eine Schande wenn frame und iframe verschwinden würden. Wie sonst will mann mehrere HTML-Dokumente in einem Fenster anzeigen?

Jeena

[Auge]

Hallo

[(i)frame]
Wobei das leider nicht bedeutet, dass diese Funktionalität irgendwann verschwinden wird :(
Ähm es währe sehr schade und eine Schande wenn frame und iframe verschwinden würden. Wie sonst will mann mehrere HTML-Dokumente in einem Fenster anzeigen?

Mit Tabs oder mit ohne HTML5. ;-)

Tschö, Auge

[molily]

Hallo,

Ähm es währe sehr schade und eine Schande wenn frame und iframe verschwinden würden. Wie sonst will mann mehrere HTML-Dokumente in einem Fenster anzeigen?

Dass HTML 5 keine Frames definiert, verstehe ich eher so, dass man nicht eine bekanntermaßen schlechte Technik neudefinieren will. Man wollte wohl weder die problematische Definition aus HTML 4 übernehmen, um diese fortzuschreiben und zu legitimieren, noch sich Gedanken machen über Alternativen, wie es XFrames mal versucht hatten, ohne dass etwas daraus wurde.

Mathias

[ChrisB]

Hi,

Ähm es währe sehr schade und eine Schande wenn frame und iframe verschwinden würden. Wie sonst will mann mehrere HTML-Dokumente in einem Fenster anzeigen?

a) gar nicht :-)
b) object

MfG ChrisB

[Timo "God's Boss" Reitz]

Ähm es währe sehr schade und eine Schande wenn frame und iframe verschwinden würden. Wie sonst will mann mehrere HTML-Dokumente in einem Fenster anzeigen?

Mein Opera kann das. Mein Konqueror auch. Ganz ohne Frames in irgendwelchen HTML-Dokumenten.
Man könnte sich natürlich auch fragen: Warum will man mehrere HTML-Dokumente in einem Fenster anzeigen lassen?

[Daniel unreg]

Hallo,

Man könnte sich natürlich auch fragen: Warum will man mehrere HTML-Dokumente in einem Fenster anzeigen lassen?

Die Frage lautet eher, warum man das kritisiert, wenn man gleichzeitig jahrelang predigt, dass Frames out seien (was sie ja auch sind)!

Das object-Element wird innerhalb der nächsten Jahre an bedeutung gewinnen, vor allem weil IE8 und Fx3 hier Fortschritte gemacht haben.

Gruß

[Timo "God's Boss" Reitz]

Man könnte sich natürlich auch fragen: Warum will man mehrere HTML-Dokumente in einem Fenster anzeigen lassen?

Die Frage lautet eher, warum man das kritisiert, wenn man gleichzeitig jahrelang predigt, dass Frames out seien (was sie ja auch sind)!

Ähm, die Leute, die das kritisieren, dürften nicht die gleichen sein, die darauf hinweisen, dass Frames nicht benutzt werden dürfen. Ich halte die (X)HTML-5-Spezifikation in weiten Teilen für groben Unfug, aber genau an der Stelle ist sie vernünftig.

Das object-Element wird innerhalb der nächsten Jahre an bedeutung gewinnen, vor allem weil IE8 und Fx3 hier Fortschritte gemacht haben.

Ja, warum man hier nicht beim generischen object bleibt und nun wieder tausend (leicht übertrieben) Sachen einführt, verstehe ich nicht. embed, video, audio, was soll das?

[Daniel unreg]

Hallo,

Ja, warum man hier nicht beim generischen object bleibt und nun wieder tausend (leicht übertrieben) Sachen einführt, verstehe ich nicht. embed, video, audio, was soll das?

Manchmal habe ich den Eindruck HTML5 wird nur deshalb kritisert, weil es was anderes ist als HTML 4. Dieses hat aber genauso proprietäre Elemente und neues Zeug hervorgebracht. Einiges davon macht durchaus Sinn.

gruß

[Jeena Paradies]

Hallo,

Man könnte sich natürlich auch fragen: Warum will man mehrere HTML-Dokumente in einem Fenster anzeigen lassen?

Naja ich habe eine Applikation die eigentlich nur eines macht, zwei divs den ganzen tag durch die gegend schubsen. Einen von unten nach oben und einen von rechts nach links.

Ich habe festgestellt dass wenn ich das in einem Fenster mache dann gehen so ziemlich alle browser in die Knie. Aufgeteilt in zwei Frames gibt es dieses Problem nicht.

Jeena

[stareagle]

Moin,

bei all den Diskussionen um die nächste Version des Internet Explorers ist wohl keinem aufgefallen, dass auch die nächste Version von (X)HTML einen neuen Meilenstein erreicht hat (oder es hat keinen interessiert, was ich dann schade fände).

Nein, ich z.B. habe es mit dem notwendigen Interesse zu Kenntnis genommen.

Ich ich bin mir nur noch nicht sicher, ob es so gut es, dass es zwei Entwicklungslinien (HTML5 und XHTML2) gibt. XHTML2 ist zwar um einiges - so weit ich weiss - komplexer als HTML5. Allerdings sind einige Teile von XHTML2, z.B. XForms meiner Meinung nach sehr interessant.

Was ich aber noch viel mehr begrüße würde, wäre eine schnellere Entwicklung UND Implementierung von CSS3, insbesondere der Module Advanced Layout oder Grid Positioning... das würde einem die Arbeit bei komplexen Layouts gegenüber float etc. sicher erleichtern...

Gruß

Stareagle

[Felix Riesterer]

Lieber Daniel,

bei all den Diskussionen um die nächste Version des Internet Explorers ist wohl keinem aufgefallen, dass auch die nächste Version von (X)HTML einen neuen Meilenstein erreicht hat (oder es hat keinen interessiert, was ich dann schade fände).

ich war mir nur bewusst, dass daran gearbeitet wird, nicht aber, dass es einen "Meilenstein" gegeben hat.

Wenn ich mir hier diese Diskussion durchlese, dann finde ich auch den Diskurs über "HTML oder XHTML?" darin wieder. Dabei wird immer mit der "Abwärtskompatibilität" argumentiert, sodass ein HTML-Dokument in seiner (SGML-basierten) Spezifikation immer sehr fehlertolerant geparst werden muss (tag soup parser), wohingegen echtes XML (also im Falle eines XHTML-Dokuments, das als application/xml+xhtml oder so ähnlich ausgeliefert wird) mit einem wesentlich strengeren Parser geparst wird, was in vielen Fällen der aktuell als HTML ausgelieferten XHTML-Dokumenten zu Fehlermeldungen führen würde, anstatt eine Internetseite zu zeigen.

Man darf in JavaScript keine Syntaxfehler machen, da sonst das Script nicht weiter ausgeführt wird (wenn es überhaupt ausgeführt wird), in HTML darf man das aber sehr wohl. Muss das so sein? Ich erinnere mich an einen Artikel aus dem SELFHTML Weblog, in dem genau diese Problematik diskutiert wurde - mit einem aus meiner Sicht höchst unbefriedigendem Votum.

Daher sehe ich HTML5 nicht begeistert entgegen, da diese generelle Problematik wirklich keinen Schritt weiter gekommen ist und nach wie vor der Urwald "Internet" voller halbgarer und pseudostandardisierter Dokumente ist. Im Sinne eines "besseren" Internets kann HTML5 meiner Meinung nach keinen Beitrag leisten!

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Daniel unreg]

Hallo,

Wenn ich mir hier diese Diskussion durchlese, dann finde ich auch den Diskurs über "HTML oder XHTML?" darin wieder.

Wobei HTML 5 beides definiert und keines bevorzugt.

Dabei wird immer mit der "Abwärtskompatibilität" argumentiert, sodass ein HTML-Dokument in seiner (SGML-basierten) Spezifikation immer sehr fehlertolerant geparst werden muss (tag soup parser),

Nein, HTML 5 erlaubt keine Tagsoup. Es spezifiziert aber einen eigenen Parser, der möglichst alle Vorhandenen Webseiten umsetzen kann. Während Browser wie Opera, Safari und Firefox dabei wohl komplett auf diesen Parser umsteigen, wird der IE ggf. einen weiteren Modus hinzufügen.

Aber grundsätzlich Hat HTML5 nichts mit Tagsoup zu tun. Es definiert lediglich, wie bestimmten Fehlersituationen entgegenzuwirken ist.

was in vielen Fällen der aktuell als HTML ausgelieferten XHTML-Dokumenten zu Fehlermeldungen führen würde, anstatt eine Internetseite zu zeigen.

HTML 5 ändert daran ja nichts :)

Man darf in JavaScript keine Syntaxfehler machen, da sonst das Script nicht weiter ausgeführt wird (wenn es überhaupt ausgeführt wird), in HTML darf man das aber sehr wohl. Muss das so sein? Ich erinnere mich an einen Artikel aus dem SELFHTML Weblog, in dem genau diese Problematik diskutiert wurde - mit einem aus meiner Sicht höchst unbefriedigendem Votum.

HTML 5 macht hier eben diesen etwas anderen Ansatz, um Webbrowser nicht dazu zu zwingen Microsoft zu immitieren. Denn deren aktuelle Pläne wären dann eine Vorschau, auf das was käme, wenn HTML 5 nicht Abwärtskompatibel wäre.

Das vorhandene Web wird leider nicht verschwinden. Man muss daran arbeiten. Da hat man eben in den Anfängen einen schweren Fehler gemacht.

Daher sehe ich HTML5 nicht begeistert entgegen, da diese generelle Problematik wirklich keinen Schritt weiter gekommen ist und nach wie vor der Urwald "Internet" voller halbgarer und pseudostandardisierter Dokumente ist.

Davon kann man nun wirklich nicht reden. HTML 5 definiert sehr genau, welche Elemente und Attribute erlaubt sind. Auch wird ein Validator bei Elementen und Attributen die es eben nicht sind Alarm schlagen.

Ungültig bleibt ungültig, aber funktionierendes bleibt weitgehen funktionieren.

Davon abgesehen sollte man nicht nur die Syntax bewerten, sondern auch die Sprache. Wenn man herausgefunden hat, dass bestimmte div/class-Kombinationen fantastrillonenfach vorkommen, ist es sicherlich sinnvoll, Elemente wie header, article usw. einzuführen.

Das ganze wird verbunden mit einem Überarbeitetem Sektionierungsalgorhitmus. Das ergibt letztendlich die selbe Flexibilität wie XHTML 2.0s section/h-Idee.

Gruß

[molily]

Hallo,

Man darf in JavaScript keine Syntaxfehler machen, da sonst das Script nicht weiter ausgeführt wird (wenn es überhaupt ausgeführt wird), in HTML darf man das aber sehr wohl. Muss das so sein? Ich erinnere mich an einen Artikel aus dem SELFHTML Weblog, in dem genau diese Problematik diskutiert wurde - mit einem aus meiner Sicht höchst unbefriedigendem Votum.

Für was habe ich deiner Meinung nach denn votiert? ;) Die Quintessenz war glaube ich nicht mehr als »Ob XHTML (Strenge) oder HTML 5 (Toleranz), ohne genaue Parsing-Regeln geht es nicht«.

Mathias

[Marc Reichelt]

Hallo Daniel,

Das ist mehr oder weniger der erste Meilenstein, den dieser Entwurf beim W3C gemacht hat, seit er im Mai '07 zur Basis für HTML5 gewählt wurde.

Aber der Entwurf hat IMHO noch einiges zu durchgehen, bevor er wirklich als HTML 5 veröffentlicht wird.
Meiner Meinung nach hat das Element embed nichts in HTML 5 zu suchen. Wozu gibt es denn object?

Nach Meinung der WhatWG ist es besser, <embed> zu standardisieren, statt es aussterben zu lassen. <embed> ist nach bisheriger Mache das einzige Element in HTML 5, das auch nicht-standardisierte Attribute (wie pluginspage, bgcolor, quality etc.) annimmt. Toll. Für mich hat HTML 5 heute wirklich an Wert verloren, als ich im #whatwg IRC Chat war und deren Meinung hierzu vernommen habe.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Daniel unreg]

Hallo,

Aber der Entwurf hat IMHO noch einiges zu durchgehen, bevor er wirklich als HTML 5 veröffentlicht wird.
Meiner Meinung nach hat das Element embed nichts in HTML 5 zu suchen. Wozu gibt es denn object?

Was hier genau die Gründe sind ist mir auch unklar. ich denke es liegt daran, dass object aktuell viel zu schlecht unterstützt wird. wirklich verwenden kann man es vermutlich erst in 6-8 Jahren. embed dagegen ist weit verbreitet implementiert und erfüllt seinen Zweck.

<embed> ist nach bisheriger Mache das einzige Element in HTML 5, das auch nicht-standardisierte Attribute (wie pluginspage, bgcolor, quality etc.) annimmt.

Wie kommst du darauf? Weder im WD noch im aktuellen Entwurf werden diese Attribute erwähnt.

Die erlaubten Attribute sind src, type, width und height.

Toll. Für mich hat HTML 5 heute wirklich an Wert verloren, als ich im #whatwg IRC Chat war und deren Meinung hierzu vernommen habe.

Ich war leider nicht dabei. Hast du einen Log o.ä.? Hört sich aktuell noch nach einem Missverständnis an!

Gruß

[frankx]

Hellihello Daniel,

Ich war leider nicht dabei. Hast du einen Log o.ä.? Hört sich aktuell noch nach einem Missverständnis an!

http://krijnhoetmer.nl/irc-logs/whatwg/20080126

Dank und Gruß,

frankx

[Daniel unreg]

Hallo,

Ich war leider nicht dabei. Hast du einen Log o.ä.? Hört sich aktuell noch nach einem Missverständnis an!

http://krijnhoetmer.nl/irc-logs/whatwg/20080126

Danke, frankx.

Aus meiner Sicht handelt es sich hier tatsächlich um ein Missverständnis.

Was ich dem Log entnehme:

embed ist, wie video, img und audio eine Sonderform des object-Elements. Ähnlich wie das img-Element kann man hier nur begrenzt agieren, z.B. keinen alternativen Inhalt anbieten.

Dagegen kann man nun sein, wenn man auch video und audio nicht mag, aber mit der selben Logik müsste man auch img verbieten und wem würde das schon einfallen?

Es wird zwar gesagt, dass der Entwurf embed mit allen Attributen erlauben würde. Ich bin mir aber sehr sicher, dass es anders gemeint ist als du es verstanden hast. Es ist lediglich genauso erlaubt wie <foo bar="baz" />.

Der Entwurf erlaubt in der Hinsicht ja erstmal alles, aber aber nicht alles was gemacht werden kann ist konform. Und da bisher kein Entwurf die allzugiftigen Attribute erwähnt, denke ich hier gibt es kein Problem.

Ich persönlich weis nicht viel über das embed-Element, doch wenn es wie angesprochen nur für Flash genutzt wird, denke ich mir, dass es auch hier kein Problem geben sollte.

Wer auf Zugängliches Markup achtet, wird auch im Flash-Filmchen auf Zugänglichkeit achten. Der Rest kümmert sich weder um das eine, noch um das andere.

Gruß

[Marc Reichelt]

Hallo Daniel,

<embed> ist nach bisheriger Mache das einzige Element in HTML 5, das auch nicht-standardisierte Attribute (wie pluginspage, bgcolor, quality etc.) annimmt.

Wie kommst du darauf? Weder im WD noch im aktuellen Entwurf werden diese Attribute erwähnt.

Die erlaubten Attribute sind src, type, width und height.

Nö. Zitat aus dem HTML 5 Entwurf (siehe embed): "Any other attribute that has no namespace (see prose)."

Toll. Für mich hat HTML 5 heute wirklich an Wert verloren, als ich im #whatwg IRC Chat war und deren Meinung hierzu vernommen habe.

Ich war leider nicht dabei. Hast du einen Log o.ä.? Hört sich aktuell noch nach einem Missverständnis an!

Den log hat frankx ja schon geliefert - dort kann man die ganze Diskussion nachlesen. Ich kann das Argument der WhatWG schon nachvollziehen. Aber ich befürchte, dass solche hässlichen Code-Schnipsel wie die von Macromedia sich mit HTML 5 erst richtig durchsetzen (zur Zeit gibt es ja gott sei Dank noch vernünftige Alternativen, wie beispielsweise die Flash Satay Methode).

Und vernünftiger Alternativ-Inhalt ist mit dem bisherigen <object ...><embed ...></object> einfach nicht machbar, da <embed> keinen Alternativinhalt bietet und selbst als Alternativinhalt für <object> missbraucht wird.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Daniel unreg]

Hallo,

Nö. Zitat aus dem HTML 5 Entwurf (siehe embed): "Any other attribute that has no namespace (see prose)."

Ah, ich verstehe. Der Entwurf sagt aber auch:
„and all attributes defined or mentioned in this specification have no namespace“.

Aber ich befürchte, dass solche hässlichen Code-Schnipsel wie die von Macromedia sich mit HTML 5 erst richtig durchsetzen (zur Zeit gibt es ja gott sei Dank noch vernünftige Alternativen, wie beispielsweise die Flash Satay Methode).

Dann muss man hier beim Hersteller die Situation anprangern. Der Entwurf reagiert darauf nur.

da <embed> keinen Alternativinhalt bietet und selbst als Alternativinhalt für <object> missbraucht wird.

Wie bereits aus unwissenheit gefragt, Alternativinhalt für embed notwendig?

Gruß

[Jeena Paradies]

Hallo,

Wie bereits aus unwissenheit gefragt, Alternativinhalt für embed notwendig?

Öhm natürlich, genau so wie für <img> und <object>, denn nicht alle Browser können <embed> inhalte darstellen.

Jeena

[Klawischnigg]

Hi there,

Am 22. Januar wurde nämlich der erste öffentliche Arbeitsentwurf von HTML5 beim W3C veröffentlicht.

Ein paar interessante Ansätze sind da imho auf jeden Fall dabei; die Möglichkeiten von clientseitigem (Vor-)Validieren von Eingabefeldern ohne Javascript bspw. halte ich für sehr praktisch. Für den Entwickler von webbasierten Applikationen sind da einige interessante Sachen dabei. Den Seitenbastlern wirds ohnehin egal sein, die kennen den Unterschied zwischen 3.2 und 4 nicht.

Die von meinem geschätzten Vorpostern genannten Nachteile kann ich so nicht ganz nachvollziehen. Vor allem der immer wieder genannte Unterschied zu XHTML ist meiner Ansicht nach, wenn HTML als Auszeichnungssprache und lediglich zum Markup verwendet, ja ohnehin verschwindend gering. Daß man in HTML "Schweinereien" machen kann, heisst ja nicht, daß man sie machen muss...

[Jonathan]

Hallo Daniel,

Also, ich finds im großen und ganzen Vernünftig. Ein paar neue Sachen mag ich nicht so sehr und ein paar finde ich überflüssig, aber ich halte den HTML5-Entwurf für sehr viel ordentlicher als den HTML4-Standard.

Jonathan

[Timo "God's Boss" Reitz]

Also, ich finds im großen und ganzen Vernünftig. Ein paar neue Sachen mag ich nicht so sehr und ein paar finde ich überflüssig, aber ich halte den HTML5-Entwurf für sehr viel ordentlicher als den HTML4-Standard.

Inwiefern ordentlicher? Es ist ein gigantischer, nicht-modularer Monsterstandard, der zusätzlich zu den existierenden Sprachen SGML und XML eine weitere definiert, und zig Dinge neben den eigentlich möglichen Elementen und Attributen definiert. Letztlich wird er wohl hauptsächlich dafür sorgen, dass das Gefrickel im Web weitergeht, wenn nicht sogar schlimmer wird.

[Jonathan]

Hallo Timo,

Inwiefern ordentlicher? Es ist ein gigantischer, nicht-modularer Monsterstandard, der zusätzlich zu den existierenden Sprachen SGML und XML eine weitere definiert, und zig Dinge neben den eigentlich möglichen Elementen und Attributen definiert. Letztlich wird er wohl hauptsächlich dafür sorgen, dass das Gefrickel im Web weitergeht, wenn nicht sogar schlimmer wird.

Einfach weil er Rücksicht auf aktuelle Browserimplementierungen nimmt. Auch wenn man die Definition der neuen Sprache vielleicht überflüssig findet (ich wäre auch nur mit einer XHTML-Version einverstanden) nimmt der neue Standard doch viel mehr Rücksicht auf die Programmierer und die aktuellen Browserimplementierungen, indem so blöde SGML-Konstruktionen wie <h1/ Hallo Welt/ (oder so ähnlich) aus dem Standard verschwunden sind. Es ist ja nicht so, als würde eine komplette neue Sprache definiert, sondern es wird einfach die aktuelle Browserverhaltensweise, die eben nicht HTML-Konform ist, in einen neuen Standard gepackt. Für Browser und Programmierer ändert sich da IMHO wenig. Und das weitere Aufrämen mit den darstellerischen Elementen finde ich auch nur positiv, auch wenn, oder gerade weil, da Kompromisse z.B. bei der Umdefinition von <i> und <b> eingeführt wurden. Man hätte i und b auch einfach aus dem Standard streichen können, aber so hat man eben noch abwärtskompatibilität, zugegebenermaßen mit etwas wirren semantischen Begründungen (Elemente, die überlicherweise Fett dargestellt werden, aber nicht als wichtig ausgezeichnet werden sollen).

Ein Standard, der eben noch die volle SGML-Sprache drin hätte, oder nur auf XML setzen würde, oder der b-Elemente verbieten würde, wäre einfach realitätsfremd. Die aktuelle Version finde ich im bezug auf die einfache Brogrammierung und die Browserkompatibilität sehr positiv. Es wurden ja z.B. auch Sachen aufgenommen, die einfach sinnvoll sind und die viele Browser schon implementiert haben, wie innerHTML oder GetElementsByClassName.

Jonathan

[Gunnar Bittersmann]

@@Jonathan:

indem so blöde SGML-Konstruktionen wie <h1/ Hallo Welt/ (oder so ähnlich) aus dem Standard verschwunden sind.

Dazu hätte man nicht eine neue Sprache jenseits von SGML erfinden müssen, die Änderung auf "SHORTTAG NO" in der SGML-Deklaration hätte genügt. Vgl. [http://forum.de.selfhtml.org/archiv/2007/10/t160280/#m1042992]

Es wurden ja z.B. auch Sachen aufgenommen, die einfach sinnvoll sind und die viele Browser schon implementiert haben, wie innerHTML oder GetElementsByClassName.

Was hat JavaScript-Zeugs in der _HTML_-Spezifikation zu suchen?

Live long and prosper,
Gunnar

[Daniel unreg]

Lieber Gunnar,

Was hat JavaScript-Zeugs in der _HTML_-Spezifikation zu suchen?

Es handelt sich nicht um JavaScript-Zeugs, sondern um DOM-Zeugs. Und das wurde deshalb aufgenommen, weil DOM-2-HTML mit HTML 5 ersetzt werden soll.

Dass HTML5 ein Monsterkonstrukt ist liegt daran, dass ausgegliederte Teile des Entwurfs (mit Ausnahme XMLHttpRequest) inzwischen beim W3C vergammeln, aber innerhalb von HTML5 wenigstens vernünftig vorannkommen.

Gruß

[molily]

Hallo,

Was hat JavaScript-Zeugs in der _HTML_-Spezifikation zu suchen?

Du setzt hier quasi eine Sichtweise voraus, das m.M.n. zurecht abgelöst wurde. Man muss da auch beachten, welchen Zweck diese Spezifikation verfolgt. Es ist ja nicht nur JavaScript (bzw. DOM), es ist viel mehr.

HTML 4 begriff sich als bloßes Auszeichnungsvokabular. Das DOM wurde erst später erfunden, nachdem XML erfunden war. Zwar gab es damit DOM HTML und dann irgendwann DOM HTML 2. Aber die waren eher relativ konservativ der Wirklichkeit hinterhergeschrieben. Und die definierten Möglichkeiten waren extrem eingeschränkt. Im Grunde definiert DOM HTML den Direktzugriff auf Attribute ohne getAttribute, dann gibts noch ein paar andere Shorthands und Überbleibsel aus Netscape JavaScript (wie document.cookie), das wars aber auch.

DOM HTML war so neutral gehalten, dass das reale Scripting von HTML-Dokumenten IM BROWSER völlig unterging. Das entwickelte sich nämlich nicht auf Basis von DOM-Spezifikationen, sondern auf Basis von proprietären Zusätzen. Man denke nur an window, bis heute nicht standardisiert.

Da kannst du natürlich fragen: Was hat das Browser Object Model mit HTML zu tun, in erster Linie nichts, in zweiter Linie alles. Neutralität ist gut, war aber im Fall von DOM HTML ein unrealistischer Schuss in den Ofen. Außerhalb von browserseitigem Scripting ist DOM HTML als Beigabe zu DOM Core nur minder interessant. Das W3C wäre freilich nicht auf die Idee gekommen, das Browser Object Model zu standardisieren

HTML 4 macht sich keine Gedanken darüber, wie das Dokument irgendwo dargestellt wird und wie Hypertext-Browsing tatsächlich funktioniert. Es definiert eine SGML-DTD und fertig. HTML 5 kehrt die Sichtweise natürlich völlig um, da hast du Recht. Es definiert HTML direkt als Document Object Model und geht ganz klar von einem »Default View« und einem »Browsing Context« aus - natürlich können diese auch fehlen, aber ihnen wird zentrale Wichtigkeit eingeräumt. Erstmals wird das Verhalten eines »User Agents« mitdefiniert. Das ist quasi die Erfindung des Browsers als Gegenstand der technischen Standardisierung. HTTP und HTML ließen den außen vor, weil man dachte, die Definition von HTML als universelles und User-Agent-neutrales Format habe damit wenig zu schaffen.

HTML 5 definiert kein bloßes »Format« mehr, sondern das Web (und damit den Browser) als Plattform. »HTML« als Auszeichnungssprache wird damit zu einem Teil in einem Framework, das Webanwendungen ermöglicht. Das ist schon längst Realität, ist aber eher als »Unfall« auf die Welt gekommen, weil man mit dem stillschweigendem Einverständnis verschiedener Browser sehr viel geschaffen hat. Das ist eine Entwicklung, die völlig autonom und ohne Standards ablief, deshalb liegt ein extremer Wildwuchs vor. Den will HTML 5 einholen.

Ich denke, man kann sich weniger am Terminus HTML aufhängen, der sagt wenig über HTML 5. HTML 5 definiert nicht HTML in Version 5, sondern das, was eher im Namen WHATWG drinsteckt: Web Application Hypertext Technology.

Mathias

[Jonathan]

Hallo Gunnar,

Dazu hätte man nicht eine neue Sprache jenseits von SGML erfinden müssen, die Änderung auf "SHORTTAG NO" in der SGML-Deklaration hätte genügt. Vgl. [http://forum.de.selfhtml.org/archiv/2007/10/t160280/#m1042992]

Naja, der neue Standard definiert ja auch das Verhalten von Browsern bei "falschem" Code. Ich denke, dass sowas nötig und sinnvoll ist und weiß nicht, inwieweit das kompatibel mit SGML wäre.

Ich denke jedenfalls, dass die Leute da irgendeinen Grund hatten, einen neuen ML-Standard zu erfinden.

Jonathan

[Daniel unreg]

Hallo,

Naja, der neue Standard definiert ja auch das Verhalten von Browsern bei "falschem" Code. Ich denke, dass sowas nötig und sinnvoll ist und weiß nicht, inwieweit das kompatibel mit SGML wäre.

Das hat den Sinn, dass sich die Browserhersteller nicht mehr ihre eigenen Fehlerkorrekturen ausdenken. Was ja einer der gründe ist, warum es manchmal zwischen Browsern zu Problemen kommt.

SGML spielt eigentlich keine große Rolle, weil HTML selbst auch nie wie SGML verarbeitet wurde.

Gruß

[MudGuard]

Hi,

Einfach weil er Rücksicht auf aktuelle Browserimplementierungen nimmt. Auch wenn man die Definition der neuen Sprache vielleicht überflüssig findet (ich wäre auch nur mit einer XHTML-Version einverstanden) nimmt der neue Standard doch viel mehr Rücksicht auf die Programmierer und die aktuellen Browserimplementierungen, indem so blöde SGML-Konstruktionen wie <h1/ Hallo Welt/ (oder so ähnlich) aus dem Standard verschwunden sind.

Das wäre aber auch einfach zu erreichen gewesen, indem man nur eine XHTML-Variante gemacht hätte.

Und das weitere Aufrämen mit den darstellerischen Elementen finde ich auch nur positiv, auch wenn, oder gerade weil, da Kompromisse z.B. bei der Umdefinition von <i> und <b> eingeführt wurden.

Gerade das finde ich unsinnig. i und b gehören weg, dafür gibt es doch em und strong.

Und weil 4 Elemente zur Hervorhebung noch nicht ausreichen, braucht's auch noch ein m-Element.

Man hätte i und b auch einfach aus dem Standard streichen können, aber so hat man eben noch abwärtskompatibilität,

dann hätte man aber u, s usw. nicht entfernen dürfen, sonst fehlt ja die Abwärtskompatibilität ...

Ein Standard, der eben noch die volle SGML-Sprache drin hätte, oder nur auf XML setzen würde, oder der b-Elemente verbieten würde, wäre einfach realitätsfremd.

Nö. Ist ja keiner gezwungen, statt HTML 4.01 auf (X)HTML 5.0 umzusteigen. Wer b und i usw. benutzen will, kann ja bei HTML 4.01 bleiben.

Es wurden ja z.B. auch Sachen aufgenommen, die einfach sinnvoll sind und die viele Browser schon implementiert haben, wie innerHTML oder GetElementsByClassName.

die aber, wie Cheatah schon sagte, in der HTML-Spezifikation nichts verloren haben.

Soviel nach kurzem Überfliegen des Teils.

cu,
Andreas

[Jonathan]

Hallo MudGuard,

Das wäre aber auch einfach zu erreichen gewesen, indem man nur eine XHTML-Variante gemacht hätte.

Wie ich schon sagte, ich hätte auch nichts dagen, die HTMl_Variante abzuschaffen.

Gerade das finde ich unsinnig. i und b gehören weg, dafür gibt es doch em und strong.

b hat ja laut dem neuen Standard einen sinn, nämlich Dinge auszuzeichnen, die nicht wichtig sind, aber im printbereich üblicherweise fett dargestellt werden (Firmennamen, etc.). Ob das sinnvoll ist kann ich nicht beurteilen, aber so ist eben die neue definition.

dann hätte man aber u, s usw. nicht entfernen dürfen, sonst fehlt ja die Abwärtskompatibilität ...

u und s sind deutlich wenioger verbreitet, außerdem sagt ja auch der HTML5-Entwurf dass solche Elemente immernoch richtig dargestellt werden sollen.

Nö. Ist ja keiner gezwungen, statt HTML 4.01 auf (X)HTML 5.0 umzusteigen. Wer b und i usw. benutzen will, kann ja bei HTML 4.01 bleiben.

Es geht ja nicht nur um den Seitenprogrammierer sondern auch um den Browser. Und für die ist es eben einfacher, wenn die Standard weiesgehend kompatibel sind, sodass man eben nicht zig renderingsmodi implementieren muss.

Es wurden ja z.B. auch Sachen aufgenommen, die einfach sinnvoll sind und die viele Browser schon implementiert haben, wie innerHTML oder GetElementsByClassName.

die aber, wie Cheatah schon sagte, in der HTML-Spezifikation nichts verloren haben.

Siehe Daniels Posting um 18:27.

Jonathan

[Gunnar Bittersmann]

@@Jonathan:

Nö. Ist ja keiner gezwungen, statt HTML 4.01 auf (X)HTML 5.0 umzusteigen.
Es geht ja nicht nur um den Seitenprogrammierer sondern auch um den Browser.

Es gibt Myriaden von Webseiten. Bittersmannsche Vermutung: Auch in 20 Jahren werden Browser noch HTML 4 verstehen.

innerHTML oder GetElementsByClassName.

die aber, wie Cheatah […]

?? ;-)

[…] schon sagte, in der HTML-Spezifikation nichts verloren haben.
Siehe Daniels Posting um 18:27.

Gut, in der Überschrift von [HTML5] steht’s ja schon: „A vocabulary _and associated APIs_ for HTML and XHTML“.

(BTW: Verlinkung von Daniels Posting wäre hier weitaus besser gewesen als Uhrzeitangabe. Besonders in einem Thread mit dem Potential, dass noch etliche Postings hinzukommen.)

Live long and prosper,
Gunnar

[Jonathan]

Hallo Gunnar,

Es gibt Myriaden von Webseiten. Bittersmannsche Vermutung: Auch in 20 Jahren werden Browser noch HTML 4 verstehen.

Eben deshalb ist HTML5 ja abwärtskompatibel. Wir könnten uns jetzt einen neuen Super-Standard ausdenken, wenn die "myriaden" von Webseiten damit nicht darstellbar wären und alles angepasst werden müsste, wäre damit niemandem geholfen.

Man könnte jetzt einwenden, dass man dann eben 2 modi in den Browser implementieren sollte, einen für die alten Webseiten und einen für die neuen, aber das würde wohl kaum ein Browserprogrammierer mitmachen. Denen reicht sicherlich die eine Engine, die sie warten und verbessern müssen.

Und das schöne ist: HTML5 wie im Entwurd ist zudem ziemlich aufwärtskompatibel. Bis auf ein bisschen erweiterte Javascript-Sachen können anständige heutige Browser ziemlich problemlos HTML5-Seiten darstellen.

Jonathan

[Daniel unreg]

Hallo,

Das wäre aber auch einfach zu erreichen gewesen, indem man nur eine XHTML-Variante gemacht hätte.

HTML ist halt nunmal da und man wird es nicht los. Also das beste daraus machen.

Gerade das finde ich unsinnig. i und b gehören weg, dafür gibt es doch em und strong.

Nein, gibt es eben nicht. <em> und <strong> zeichnen Betonung aus und sind Elemente mit hohem semantischen Wert.

Diese Elemete zu verwenden um etwas fett bzw. kursiv darzustellen ist Elementmissbrauch.

b und i dagegen haben keinen Wert. Aber sie werden von Autoren mit einem Sinn eingesetzt. Dieser Sinn, der anders ist als der von em und strong wird in HTML5 mit geringem semantsichen Wert belegt.

Daher ist es besser, wenn b und i für was falsches (im HTML5-Sinn) eingesetzt werden, als wenn em und strng zur formatierung genutzt werden.

Und weil 4 Elemente zur Hervorhebung noch nicht ausreichen, braucht's auch noch ein m-Element.

Zunächst: Das m-Element entfällt vermutlich.

Aber: m ist völlig anders als b, i, strong, em oder u, s usw.
M ist ein Datenelement. Es zeichnet Daten aus. Beispielsweise die Suchergebnisse einer Suchmaschine in einem Dokument (etwa Firefox' Hervorheben-Feature wäre hier vergleichbar).

dann hätte man aber u, s usw. nicht entfernen dürfen, sonst fehlt ja die Abwärtskompatibilität ...

Zunächst: b und i wurden vermutlich deshalb schon nicht aus HTML 4 Strict gestrichen, weil man die beiden Elemente nie loswerden wird.

Zudem: HTML 5 ist Rückwärtskompatibel, denn diese Elemente sind durchaus enthalten. HTML 5 definiert nämlich, wie ein HTML-Parser reagieren muss, wenn er auf diese Elemente trifft. s und u sind aber kein Teil der Kernsprache, also der Teil, den man bei HTML4 noch "nicht deprecated" genannt hätte.

Nö. Ist ja keiner gezwungen, statt HTML 4.01 auf (X)HTML 5.0 umzusteigen. Wer b und i usw. benutzen will, kann ja bei HTML 4.01 bleiben.

HTML5 ist so definert, dass jedes HTML4-Dokument automatisch ein HTML5-Dokument ist. Denn HTML5 definert möglichst alles. Also auch Elemente, die nicht vorkommen bzw. wie diese Verarbeitet werdn müssen um Rückwärtskompatibel zu bleiben. Das ist für die HTML variante notwendig, weil man hier nicht die XML-Features nutzen kann.

die aber, wie Cheatah schon sagte, in der HTML-Spezifikation nichts verloren haben.

HTML5 ist aber keine HTML-Spezifikation.

So viel sollte man schon verstehen, wenn man darüber diskutiert.

Gruß

[molily]

b und i dagegen haben keinen Wert.

Hallo?

Dann lies mal bitte, wie HTML 5 sie definiert.

Aber sie werden von Autoren mit einem Sinn eingesetzt.

Warum definiert sie HTML 5 als sinnvoll?

Dieser Sinn, der anders ist als der von em und strong wird in HTML5 mit geringem semantsichen Wert belegt.

Ganz und gar nicht. Beispiel i:

»The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized.«

Zum Vergleich em:
»The em element represents stress emphasis of its contents.«

Sorry, aber ein i macht offenbar nach dieser Definition eine viel differenziertere Aussage über den Text als em.

Daher ist es besser, wenn b und i für was falsches (im HTML5-Sinn) eingesetzt werden

HTML 5 definiert sie eben nicht als »falsch« (rein presentational) und obsolet.

s und u sind aber kein Teil der Kernsprache, also der Teil, den man bei HTML4 noch "nicht deprecated" genannt hätte. (...) HTML5 ist so definert, dass jedes HTML4-Dokument automatisch ein HTML5-Dokument ist.

Das widerspricht sich.

Mathias

[Daniel unreg]

Hallo,

b und i dagegen haben keinen Wert.

Hallo?
Dann lies mal bitte, wie HTML 5 sie definiert.

Ich sprach davon, wie HTML4 sie definiert, dann wie sie Autoren verwenden und dann, was HTML5 daraus folgert.

Warum definiert sie HTML 5 als sinnvoll?

Weil man die Autoren nicht davon abbringen kann sie einzusetzen.

Sorry, aber ein i macht offenbar nach dieser Definition eine viel differenziertere Aussage über den Text als em.

Das kann man so sehen ja. Aber ich meine, durch die vielseitige Interpretationsmöglichkweit vierliert i an Bedeutung.

HTML 5 definiert sie eben nicht als »falsch« (rein presentational) und obsolet.

HTML 5 gibt b und i eine schwache Bedeutung. Wenn man nun b oder i zur formatieren einsetzt, soll das weniger problematisch sein, als em oderstrong für Formatierung einzusetzen.

s und u sind aber kein Teil der Kernsprache, also der Teil, den man bei HTML4 noch "nicht deprecated" genannt hätte. (...) HTML5 ist so definert, dass jedes HTML4-Dokument automatisch ein HTML5-Dokument ist.

Das widerspricht sich.

Nein, den HTML 5 definiert, wie alte Elemente und unbekannte Elemente verarbeitet werden müssen. Das sieht man vor allem in der Parsersektion des Entwurfs.

Gruß

[Jonathan]

Hallo Daniel,

HTML 5 gibt b und i eine schwache Bedeutung. Wenn man nun b oder i zur formatieren einsetzt, soll das weniger problematisch sein, als em oderstrong für Formatierung einzusetzen.

Also, die neue Semantik von b und i finde ich eigentlich ganz gut. man hat jetzt eigentlich ganz klar zugeordnet, welches Element man wass einsetzt:

i: besonders hervorgehobener Text, z.B. ein Fachbegriff, der Gedankengang einer Person etc.

Beispiele:

• Sie saßen auf der <i>Queen Mary II</i> und aßen.
• <i>Junge, </i>dachte ich, <i>du solltest mal was essen.</i>

b: (semantisch) hervorgehobener text wie z.B. ein Produktname, ein Einleitungssatz etc.

Beispiele:

• Mein neuer Computer besitzt eine <b>Geforce 7600GTX</b>
• <p><b>In folgendem Artikel geht es um Dinosaurier und wie sie aussahen</b></p>

em: Hervorgehobenes/Betontes Wort.

Beispiele:

• Menschen <em>pflegen</em> keine Schnitzel, sie essen sie.
• Menschen pflegen keine <em>Schnitzel</em>, sie pflegen (lebende) Tiere.

strong: Wichtiges Wort oder wichtiger Satz.

Beispiele:

• <strong>Warnung: </strong>Wenn sie fortfahren werden Änderungen möglicherweise nicht gespeichert.
• <strong><strong>Warnung: </strong>Wenn sie fortfahren können wichtige Daten gelöscht werden.</strong>

ich halte die Änderung jedenfalls für sinnvoll, und ich halte die neuen Elemente auch durchaus für besser, als überall spans und divs hinzupacken.

Jonathan

[Daniel unreg]

Hallo,

ich halte die Änderung jedenfalls für sinnvoll, und ich halte die neuen Elemente auch durchaus für besser, als überall spans und divs hinzupacken.

Ja, ich auch. Allerdings meine ich, dass Satzzeichen innerhalb der Elemente nichts zu suchen haben ;)

Also <strong>Warnung<strong>:... und <i>Junge<i>,... wäre imho besser als bei deinen Beispielen.

Wenn ich mich nit irre rät das W3C ohnehin dazu, auch Leerzeichen</element> zu vermeiden, da das Leerzeichen hier verschluckt werden könnte.

Allerdings mag ich das jetzt nicht testen und lasse es einfach im Raum stehen :)

Gruß

[Jonathan]

Hallo Daniel,

Also <strong>Warnung<strong>:... und <i>Junge<i>,... wäre imho besser als bei deinen Beispielen.

Soweit ich weiß, sollten Satzzeichen immer in das Element mit rein. natürlich nur, wenn die Hervorhebung sich nicht einfach auf das letzte Wort in einem Satz bezieht.

Ich zitier hier einfach mal aus dem HTML5-Entwurf:

<strong>Warning.</strong> This dungeon is dangerous.

aber:

<p>Cats are cute <em>animals</em>.</p>

Wenn ich mich nit irre rät das W3C ohnehin dazu, auch Leerzeichen</element> zu vermeiden, da das Leerzeichen hier verschluckt werden könnte.

Wüsste nicht, wieso die das tun sollten. Wie du siehst, steht das so auch in deren Beispiel drin.

Es ist aber auch einfach logisch, dass das Satzzeichen mit rein muss.

Beispiel 1:

<dt>Gras:</dt> <dd>Gründes Zeug</dd>

Wie soll da bitte der Doppelpunkt hinters Tag?

Beispiel 2:

<strong style="font-size:400%">Warning</strong>! This dungeon is dangerous.

Das Ausrufezeichen wirkt da ein bisschen klein, oder? ;-)

Jonathan

[MudGuard]

Hi,

<dt>Gras:</dt> <dd>Gründes Zeug</dd>

Wie soll da bitte der Doppelpunkt hinters Tag?

Mit
<dt>Gras</dt> <dd>Gründes Zeug</dd>
und
dt:after { content:':'; }

cu,
Andreas

[Daniel unreg]

Hallo,

Soweit ich weiß, sollten Satzzeichen immer in das Element mit rein. natürlich nur, wenn die Hervorhebung sich nicht einfach auf das letzte Wort in einem Satz bezieht.

Hier gehe ich nicht vom Entwurf aus, sondern vom Sprachgefühl. Man schreibt ja auch in (Klammern). Und nicht in (Klammern.)

Wüsste nicht, wieso die das tun sollten. Wie du siehst, steht das so auch in deren Beispiel drin.

Andernorts hat das W3C das angeprangert, weil eben das Leerzeichen entfernt werden könnte. Die damals angeführte Argumentation machte sinn, allerdings habe ich sie nicht im Kopf. Und es kann ja auch sein, dass HTML5 hier anders Parst als die Browser.

<dt>Gras:</dt> <dd>Gründes Zeug</dd>

Die Definition definiert aber nur "Gras", nicht aber "Gras:".

<strong style="font-size:400%">Warning</strong>! This dungeon is dangerous.
Das Ausrufezeichen wirkt da ein bisschen klein, oder? ;-)

Du widersprichst dir.

natürlich nur, wenn die Hervorhebung sich nicht einfach auf das letzte Wort in einem Satz bezieht.

"Warning" ist das letzte Wort im Satz.

Gruß

[Jonathan]

Hallo Daniel,

<dt>Gras:</dt> <dd>Gründes Zeug</dd>

Die Definition definiert aber nur "Gras", nicht aber "Gras:".

Schlechtes Beispiel.

Totschlagargument:

<p>Hallo Welt</p>!

natürlich nur, wenn die Hervorhebung sich nicht einfach auf das letzte Wort in einem Satz bezieht.

"Warning" ist das letzte Wort im Satz.

Aber der ganze Satz "Warning!" ist hervorgehoben, nicht nur das eine Wort.

Jonathan

[Daniel unreg]

Hallo,

Schlechtes Beispiel.
Totschlagargument:
<p>Hallo Welt</p>!

Dagegen spricht doch gar nichts. Außer, dass ich es  nicht explizit ausgeschlossen habe.

p hat aber als Blockelement völlig andere Eigenschaften. em und strong sind Inlinelemente. Vielleicht spielt es daher keine Rolle, ob das Satzzeichen nun innerhalb oder außerhalb des Elements zu finden ist, aber mir sagt die Schreibweise außen eher zu.

<em>Junge</em>, ...

Für mich gibt es einfach keinen Sinn, warum das Komma hier betont werden sollte.

Aber der ganze Satz "Warning!" ist hervorgehoben, nicht nur das eine Wort.

Gut, das ist schon wieder eine andere Situation, bei der ich dir sogar zustimmen würde ;)

Gruß

[Jonathan]

Hallo Daniel,

<em>Junge</em>, ...

Für mich gibt es einfach keinen Sinn, warum das Komma hier betont werden sollte.

Ich habe gehört, dass man das so machen soll, auch hier im Forum, und ich finde es eigentlich völlig logisch.

Betrachten wir mal den Originalsatz:

<i>Junge, </i>dachte ich, <i>du solltest mal was essen.</i>

Den Satz kann man natürlich reduzieren auf:
<i>Junge, du solltest mal was essen.</i>

• Hier ist das Komma selbstversändlich mitformatiert.

Anders sieht es aus wenn ich nicht den kompletten Satz (bis auf den Nebensatz) formatiere, sondern nur ein Wort. Hier halte ich dann folgendes für besser:

<em>Jungen</em>, aber keine Mädchen, wollen gerne Traktor fahren.

Ansonsten ist mir das aber egal, ich will dir nichts aufzwingen, ich hab das aber so gelernt und ich werde das auch so weitermachen.

Jonathan

[Cybaer]

Hi,

<strong style="font-size:400%">Warning</strong>! This dungeon is dangerous.

Das Ausrufezeichen wirkt da ein bisschen klein, oder? ;-)

Das ist allerdings auch kein HTML 5, da HTML 5 kein STYLE-Attribut mehr kennt (außer beim FONT-Element)! :)

Gruß, Cybaer

[Jonathan]

Hallo Cybaer,

Das ist allerdings auch kein HTML 5, da HTML 5 kein STYLE-Attribut mehr kennt (außer beim FONT-Element)! :)

Bitte entschuldige, dass ich das Beispiel nicht unnötig verkompliziert habe, indem ich ein externes Stylesheet definiert habe. Was ich sagte müsste im übrigen auch für HTML4 gelten.

Jonathan

[Daniel unreg]

Hallo,

Das ist allerdings auch kein HTML 5, da HTML 5 kein STYLE-Attribut mehr kennt (außer beim FONT-Element)! :)

Es wundert mich, dass immernoch so wenige verstehen, dass es immer HTML5 ist. Egal wie viele unerlaubte Elemente und Attribute vorkommen.

Gruß

[Cybaer]

Hi,

Es wundert mich, dass immernoch so wenige verstehen, dass es immer HTML5 ist. Egal wie viele unerlaubte Elemente und Attribute vorkommen.

Aha, "Duke Nuk^W^W HTML 5 Forever"! ;)

Also zu behaupten, ich hätte den Workung Draft verstanden, wäre glatt gelogen. Ich habe noch nicht mal die Zeit gefunden, ihn komplett zu lesen. :-> Aber führe mich ins Licht, bzw. zu der Stelle, die deine sehr absonderlich klingende Behauptung a) belegt und b) bitte auch begründet.

Gruß, Cybaer

[Tim Tepaße]

Hallo Cybaer,

Es wundert mich, dass immernoch so wenige verstehen, dass es immer HTML5 ist. Egal wie viele unerlaubte Elemente und Attribute vorkommen.

Also zu behaupten, ich hätte den Workung Draft verstanden, wäre glatt gelogen. Ich habe noch nicht mal die Zeit gefunden, ihn komplett zu lesen. :-> Aber führe mich ins Licht, bzw. zu der Stelle, die deine sehr absonderlich klingende Behauptung a) belegt und b) bitte auch begründet.

Die passende Stelle dafür ist Abschnitt 8: The HTML syntax, insbesondere 8.2 Parsing HTML documents - da es für die HTML 5 Serialisierung keine Metasyntax wie SGML oder XML gibt.

In der Tokenisierung werden Attribute generell nur als A-Z beschrieben (vorher auf Großschreibung normalisiert). In der Tree construction phase gilt:

When the steps below require the UA to create an element for a token, the UA
  must create a node implementing the interface appropriate for the element type
  corresponding to the tag name of the token (as given in the section of this
  specification that defines that element, e.g. for an a element it would be the
  HTMLAnchorElement interface), with the tag name being the name of that element,
  with the node being in the HTML namespace, and with the attributes on the node
  being those given in the given token.

Beachte: Es wird keine Aussage über Bedingungen an die Attribute gestellt. Wenn etwas da ist, dass der abstraken Attribut-Syntax entspricht, wird es als Attribut behandelt. DOM 5 sagt nur aus, dass der bestimmte DOM Attribute (aus den jeweiligen Interfaces) bestimmte Content Attribute (in der HTML 5 Syntax bzw. der XML Syntax von XHTML 5) reflektieren müssen. Mehr nicht. Wird Dich vielleicht interessieren, diese Agnostik gilt auch gegenüber unbekannten Elementen, es wird nur explizit ein Knoten im DOM dafür angelegt:

The interface appropriate for an element that is not defined in this
  specification is HTMLElement.

Das überlebt dann auch Roundtrips, aus Serialising HTML Documents:

If the child node is an Element:
  ...
  For each attribute that the element has, append a U+0020 SPACE character, the
  attribute's name (which, for attributes set by the HTML parser or by
  Element.setAttributeNode() or Element.setAttribute(), will be lowercase), a
  U+003D EQUALS SIGN (=) character, a U+0022 QUOTATION MARK (") character, the
  attribute's value, escaped as described below, and a second U+0022 QUOTATION
  MARK (") character.

Nur wird da die eigentlich flexible Syntax verhübschert. ;)

...

Das Verhalten zur DOM-Konstruktion ist übrigens ähnlich zu demjenigen, mit dem XML-Dokumente in DOM-Dokumente umgewandelt werden – und damit gilt das für die XHTML 5 Serialisierung. Auch bei XML/XML NS können beliebige Attribute im Dokument vorkommen, wenn dieses nicht mit einer DTD ausgestattet sind. Dort entscheidet dann allein die Syntax über den Attributstatus. Und XHTML 5 hat ja weder formelle DTD noch ein formelles XML Schema.

Bei XML kommen dann natürlich noch eventuelle Namensräume vor, ein ganz eigenes Thema. Es gibt sogar Bestrebungen einen Hauch von Namensraumerkennung in die HTML 5 Syntax reinzubringen. Einerseits um schöne Dinge wie z.B. SVG auch für die HTML 5 Syntax freizuschalten zum anderen aus Abwärtskompabilität. Es gibt ja noch haufenweise XHTML 1.0 oder gar XHTML 1.1 Dokumente da draussen, die per text/html versendet werden, nach der HTML 5 Spec werden die dann nach der HTML 5 Syntax verarbeitet.

Tim

[Cybaer]

Hi,

Die passende Stelle dafür ist Abschnitt 8: The HTML syntax, insbesondere 8.2 Parsing HTML documents - da es für die HTML 5 Serialisierung keine Metasyntax wie SGML oder XML gibt.

Das muß ich erstmal alles lesen und dann sacken lassen. ;-)

Wobei ich bislang eher davon ausgegangen bin, daß die frühere Toleranz (die ja auch *nicht* auf Eigenschaften von SGML gründet, sondern *explizit* eine Definition von HTML als solchem war!) mit HTML 5 einfach auf eine neue Definitionsstufe gehoben wurde.

Wie man sich erinnern kann, war z.B. der Doctype in HTML <2 auch noch kein Thema (trotz SGML-Basis!). Daß er mit HTML 5 nur deswegen nicht komplett wieder rausgeflogen ist, weil mittlerweile das unsägliche Doctype-Sniffing eingeführt wurde, habe ich weniger als ein "wir erfinden HTML neu" betrachtet, sondern eher als ein "Back to the Roots".

Insofern sehe ich mom. HTML 5 als das HTML an, das explizit *den* Elemente-Umfang besitzt, wie es in der HTML-5-Spec verzeichnet sein wird, wenn die Spec offiziell wird. Nur das man mit HTML 5 gleichzeitig zu einer neuen modernen wie rückwärtsbesonnenen Definition gelangt ist, was überhaupt HTML als solches ist.

Ich würde also konkreten Umfang und allg. Definition durchaus trennen - oder eben auch nicht, was dann aber IMHO (zumindest für mich) nie anders war. :-) Oder anders formuliert: Jedes denkbare HTML ist für mich genauso "HTML 5" wie es "HTML 1" wäre. Nur eben mittlerweile modernisiert, bzw. erweitert um Definitionen, die damals nicht nötig waren, es heute aber sind (Stichwort: DOM). Und genauso ist für mich ein HTML mit Elementen, die man nicht in der HTML-5-Spec findet eben dennoch nicht "HTML 5".

Gruß, Cybaer

PS: Klar erkannt, daß *mir* die neue Entwicklung, zumindest im Wesentlichen, sehr gut gefällt! Ich konnte es auch nicht verhehlen ... >:->

[Robert Bienert]

Moin!

Das ist allerdings auch kein HTML 5, da HTML 5 kein STYLE-Attribut mehr kennt (außer beim FONT-Element)! :)

Was hat font in einer seriösen HTML-Version überhaupt noch suchen?

Viele Grüße,
Robert

[Cybaer]

Hi,

Was hat font in einer seriösen HTML-Version überhaupt noch suchen?

Für "WYSIWYG"-Editoren (Stichwort: contenteditable), die naturgemäß ein wenig mehr Probleme mit semantischer Codierung haben, als wir Menschen.

Gruß, Cybaer

[Robert Bienert]

Moin!

Was hat font in einer seriösen HTML-Version überhaupt noch suchen?

Für "WYSIWYG"-Editoren (Stichwort: contenteditable), die naturgemäß ein wenig mehr Probleme mit semantischer Codierung haben, als wir Menschen.

Tja, aber darauf kommt es in HTML nun einmal an. Ein WYSIWYG-Editor für eine WYSIWYM-Sprache ist halt problematisch und deshalb halte ich es für inkonsequent dem noch eine Alternative zur Seite zu stellen, die die Sprache verwässert.

Viele Grüße,
Robert

[Cybaer]

Hi,

Tja, aber darauf kommt es in HTML nun einmal an. Ein WYSIWYG-Editor für eine WYSIWYM-Sprache ist halt problematisch und deshalb halte ich es für inkonsequent dem noch eine Alternative zur Seite zu stellen, die die Sprache verwässert.

Willkommen in der Realität, wo die Sekretärin/PR-Abteilung der Firma die Texte der Website selbst pflegt - mittels Online-WYSIWYG-Editor.

Bei uns ist *der* Renner ein gut SEO nutzendes CMS, mit eben eingebautem WYSIWYG-Editor (für den Content-Bereich, nicht das Template als solchem), damit die Firma nicht bei jedem Alltagskleinkram den HTML-Profi kontakten muß.

Das ist aus "Sicht" von HTML zwar nicht optimal (jeder, der diesbezügl. arbeite, sollte IMHO eigentlich ein HTML-"Profi" sein), aber eben realistisch.

Gruß, Cybaer

[Robert Bienert]

Moin!

Tja, aber darauf kommt es in HTML nun einmal an. Ein WYSIWYG-Editor für eine WYSIWYM-Sprache ist halt problematisch und deshalb halte ich es für inkonsequent dem noch eine Alternative zur Seite zu stellen, die die Sprache verwässert.

Willkommen in der Realität, wo die Sekretärin/PR-Abteilung der Firma die Texte der Website selbst pflegt - mittels Online-WYSIWYG-Editor.

Und die Sekretärin hat noch nie etwas von Formatvorlagen gehört? Das kann ich mir beim besten Willen nicht vorstellen. OK, PR-Abteilung ist eine andere Baustelle. Es gibt übrigens auch fähige Online-Editoren, z.B. der von WordPress. Allerdings könnte ich mir vorstellen, dass dabei das Missbrauchspotenzial recht hoch ist (fett=strong und so).

Bei uns ist *der* Renner ein gut SEO nutzendes CMS, mit eben eingebautem WYSIWYG-Editor (für den Content-Bereich, nicht das Template als solchem), damit die Firma nicht bei jedem Alltagskleinkram den HTML-Profi kontakten muß.

SEO und physische Textauszeichnung? Das musst du mir mal näher erklären.

Schönes Wochenende,
Robert

[Cybaer]

Hi,

Und die Sekretärin hat noch nie etwas von Formatvorlagen gehört?

Doch, natürlich. Aber wenn im Fließtext nunmal ein Textteil größer sein soll, dann kommt halt z.B. ein <font size="2"> oder ein <span style="font-size: 14px;"> bei raus .

Das kann ich mir beim besten Willen nicht vorstellen.

Ich kann mir noch ganz andere Dinge nicht vorstellen - die ich aber dennoch nachträglich zu fixen habe.

Es gibt übrigens auch fähige Online-Editoren, z.B. der von WordPress.

Ich kenne den Moloch WP nicht so gut. Ist der per Default dabei?

Den Quelltext-Editor den ich kenne, ist IMHO jedenfalls gnadenlos schlecht ...

SEO und physische Textauszeichnung? Das musst du mir mal näher erklären.

Nein. SEO was den ganzen Rest angeht. Wenn jemand im WYSIWYG partout nicht H2 nehmen möchte, sondern lieber unsematische Formtierung, dann ist das nicht zu ändern. Allerdings gibt es ein Site-spezifisches Postprocessing-Script, mithilfe dessen die "gängigen Fehler" einfach im Nachhinein gnadenlos wieder zurechtgebügelt werden, egal was der Autor wysiwygte - man kennt mit der Zeit ja seine Pappenheimer! :-)

Ansonsten ist aber das Content-Template korrekt (was aber weder mit dem WYSIWYG, noch mit dem CMS als solchem was zu tun hat).

Gruß, Cybaer

[Jonathan]

Hallo Cybaer,

Doch, natürlich. Aber wenn im Fließtext nunmal ein Textteil größer sein soll, dann kommt halt z.B. ein <font size="2"> oder ein <span style="font-size: 14px;"> bei raus .

1. Wüsste ich nicht, wieso man auf gängien Webseiten plötzlich mitten im Fließtext den Text größer machen sollte. Wenn die Sekretärin auf so komische ideen kommt, ich das vielleicht eher deren Problem.

2. Muss man eben nen ordentlichen WYSIWYG-Editor einsetzen. Beispiel wäre die Wikipedia-Syntax wo »'''Hallo''', du ''schöne'' Welt« zu <b>Hallo</b>, du <i>schöne</i> Welt wird. Das ist zwar jetzt nicht wirklich semantisch, aber man könnte ja auch genausogut em und strong draus machen. Das ganze wäre natürlich auch genausogut als über buttons formatierbar, also richtig WYSIWYG, denkbar. Wichtig wäre dann eben auch noch, dass der WYSIWYG-Editor solche schwachsinnigen font oder span-Elemente einfach nicht anbietet, bzw. dessen verwendung nicht dokumentiert. Ich glaube kaum, dass die Sekretärin von sich aus auf die Idee kommen wird, die einzubauen.

Man sollte also einfach nen guten Editor nehmen, der nur die formatierungen erlaubt, die auf der Site üblich sind, und man hat schöne einheitliche Seiten, wo die Sekretärin, auch wenn die noch so doof ist, nicht viel falsch machen kann. Und Tidy kann man dann immernochmal drüber jagen.

Jonathan

[Cybaer]

Hi,

1. Wüsste ich nicht, wieso man auf gängien Webseiten plötzlich mitten im Fließtext den Text größer machen sollte.

Du darfst dir auch gerne andere Textauszeichnungen (Farbe z.B.) vorstellen. Streng deine Phantasie einfach mal ein wenig an ... >;->

2. Muss man eben nen ordentlichen WYSIWYG-Editor einsetzen.

Ja, was meinst Du denn, warum ich ein Beispiel genommen habe, wo das eben nicht so einfach geht? Herr im Himmel, wirf Hirn herab ... =;->

Gruß, Cybaer

[Jonathan]

Hallo Cybaer,

Du darfst dir auch gerne andere Textauszeichnungen (Farbe z.B.) vorstellen. Streng deine Phantasie einfach mal ein wenig an ... >;->

Auch farbig oder sonst anders ist nicht sehr sinnvoll. Wenn es auf der Website trotzdem üblich ist, bestimmten Text irgendwie (farbe, größe) zu markieren, dann kann man da immernoch ein passendes Element mit ner speziellen Klasse nehmen und dem Editor das beibringen. man mus aber nicht der Sekretärin (bzw. dem Sekretär ;-) ) das freie formatieren mit span- oder font-Elementen erlauben

Jonathan

[Cybaer]

Hi,

Auch farbig oder sonst anders ist nicht sehr sinnvoll.

Ich habe mich nicht danach zu richten, was Du (oder auch ich) für sinnvoll erachtest.  Ich stelle fest, daß es genutzt wird, und ich stelle ferner fest, daß, in Kenntnis des Inhalts, das Anliegen mal berechtigt, mal unberechtigt war.

Wenn es kontraproduktiv war, kegelt das CMS das anschließend wieder raus - grausam ist die Welt ... >;->

Wenn es auf der Website trotzdem üblich ist, bestimmten Text irgendwie (farbe, größe) zu markieren, dann kann man da immernoch ein passendes Element mit ner speziellen Klasse nehmen und dem Editor das beibringen.

Dein Vertrauen in die Änderbarkeit bestehender Arbeitsabläufe durch "komische Anwandlungen seitens der Webleute" ehrt dich, ist aber AFAIK nicht unbedingt realistisch.

BTW: Dort wo mit Dreamweaver-WYSIWYG gearbeitet wird (ist bei unserem System ebenfalls möglich), wird durchaus auch mit Klassen gearbeitet. Ich sehe aber nicht, daß der Quelltext dadurch besser würde. Letztlich wird dann für jeden Scheiß eine CSS-Regel angelegt, DW-typisch durchnummeriert (Stil1-Stiln) und die Übersicht ist noch geringer, als bei den Direktstilen. =:->

Gruß, Cybaer

[Gunnar Bittersmann]

@@Jonathan:

2. Muss man eben nen ordentlichen WYSIWYG-Editor einsetzen. Beispiel wäre die Wikipedia-Syntax wo »'''Hallo''', du ''schöne'' Welt« zu <b>Hallo</b>, du <i>schöne</i> Welt wird.

Nein; das ist kein WYSIWYG.

WYSIWYG heißt direkte Manipulation am Text. Also Text markieren, Formatierung ändern, Ergebnis sofort sichtbar.

Die Frage ist, warum Entwickler von HTML-WYSIWYG-Editoren solch Unsinn wie physische Formatierung überhaupt in den Editor einbauen. Die Schuld daran, dass HTML-WYSIWYG-Editoren so grottenschlechten Quelltext generieren, liegt bei den Entwicklern der Editoren; nicht bei deren Anwendern, die die unsinnigen Funktionalitäten dann auch tatsächlich nutzen.

Live long and prosper,
Gunnar

[Jonathan]

Hallo Gunnar,

Beispiel wäre die Wikipedia-Syntax wo »'''Hallo''', du ''schöne'' Welt« zu <b>Hallo</b>, du <i>schöne</i> Welt wird.

Nein; das ist kein WYSIWYG.

Ich weiß. Kann man auch an meinem nächsten Satz erkennen. So eine Syntax finde ich insgesammt aber deutlich besser, als (echtes) WYSIWYG, weil man eben richtige Kontrolle über die Ausgabe hat. Bei einem WYSIWYG-Editor kann man auch ein Leerzeichen fett machen und es fällt überhaupt nicht auf, dass das vielleicht Schwachsinn ist.

Jonathan

[Cybaer]

Hi,

So eine Syntax finde ich insgesammt aber deutlich besser, als (echtes) WYSIWYG, weil man eben richtige Kontrolle über die Ausgabe hat.

Es ist *null* Problem für einen WYSIWYG-Editor bei einem fett zu machenden Text die Stelle in ein B-Element zu packen!

Es ist und bleibt aber ein Problem, zu unterscheiden (nach z.B. HTML-5-Kriterien), ob es ein B- oder ein STRONG-Element sein soll.

Es ist ferner nicht möglich, z.B. einen Farbwechsel semantisch zu erfassen. Hier gibt es IMHO folgende Alternativen:
1. SPAN + STYLE-Attribut (zukünftig nicht mehr erwünscht).
2. FONT + STYLE-Attribut (beides WYSIWYG-Editoren vorbehalten und im normalen Webdesign nicht zulässig)
3. Definition von Stilen seitens des Editierenden
4. Zwangsweise Nutzung vorgegebener Stile

IMHO sind nur 2 & 3 praktisch nutzbar (weil 1 nicht mehr erwünscht ist und 4 ggf. eine Beschneidung der Möglichkeiten bedingt).

Für den Anwender soll sich der WYSIWYG-Editor im Wesentlichen darstellen ...

Bei einem WYSIWYG-Editor kann man auch ein Leerzeichen fett machen und es fällt überhaupt nicht auf, dass das vielleicht Schwachsinn ist.

... wie z.B. eine Textverarbeitung (die er gewohnt ist). Das schmeißt Punkt 3 aus dem Rennen, und schließt dann auch unsinniges wie ausgezeichnete Leerstellen mit ein (wobei das ein WYSIWYG-Editor natürlich auch vermeiden kann).

Aber ob <span class="stil2"> </span> besser ist als <b> </b> glaube ich eigentlich auch nicht. =;-)

Gruß, Cybaer

[Jonathan]

Hallo Cybaer,

es hängt immer davon ab, was erreicht werden soll. Natürlich ist ein WYSIWYG-Editor, der nur wenige eingebaute klassen beherrscht, nicht sehr sinnvoll. wenn ich aber ne große Webseite habe und will, dass meine "Redakteure" ihre Artikel nur in einem bestimmten Stil mit bestimmten Formatierungen benutzen, kann ich sehr wohl einen WYSIWYG-Editor einbauen, dem ich dann nur wenige passende Stile beibringe.

Das mit dem fetten Leerzeichen ist ja auch nicht das einzige Problem, aber es verdeutlicht, dass man bei einem WYSIWYG-Editor eben nur irgendwas sieht, aber keine Kontrolle über das Resultat hat.

Es mag gute WYSIWYG-Editoren geben, aber im Zweifelsfall kann man sich nicht sicher sein, dass der ordentlichen Code ausspuckt, und dann müsste man den resultierenden Quelltext überprüfen, und gucken wieso der Editor da so einen Mist draus macht. Nur kann man ja schlecht irgendwelche überflüssigen Tags aus der WYSIWYG-Ansicht entfernen. Man fummelt dann da irgendwie rum und hat hinterher vielleicht sowas: <b><span style="font-weight:normal">Hallo</span> Welt</b>

Deshalb würde ich eigentlich eher Wikisyntax/BB-Code-Ähnliche Textauszeichnungen empfehlen, auch gerne in Verbindung mit einer Echtzeitvorschau.

Jonathan

[Cybaer]

Hi,

es hängt immer davon ab, was erreicht werden soll.

Klar, wie immer. :-)

Natürlich ist ein WYSIWYG-Editor, der nur wenige eingebaute klassen beherrscht, nicht sehr sinnvoll. wenn ich aber ne große Webseite habe und will, dass meine "Redakteure" ihre Artikel nur in einem bestimmten Stil mit bestimmten Formatierungen benutzen, kann ich sehr wohl einen WYSIWYG-Editor einbauen, dem ich dann nur wenige passende Stile beibringe.

Ich glaube hingegen, daß "Redakteure" eher überhaupt keine Auszeichnungen benötigen. Wenn es sich um eh "standardisierte" Texte handelt, kommt im Zweifel nur eine Klartext-Eingabe in Frage.

Es mag gute WYSIWYG-Editoren geben, aber im Zweifelsfall kann man sich nicht sicher sein, dass der ordentlichen Code ausspuckt, und dann müsste man den resultierenden Quelltext überprüfen, und gucken wieso der Editor da so einen Mist draus macht. Nur kann man ja schlecht irgendwelche überflüssigen Tags aus der WYSIWYG-Ansicht entfernen. Man fummelt dann da irgendwie rum und hat hinterher vielleicht sowas: <b><span style="font-weight:normal">Hallo</span> Welt</b>

Ich weiß nicht, was die Online-WYSIWYG-Editoren so bieten, aber ich vermute mal, daß zu so ziemlich jedem WYSIWYG-Editor auch eine Quelltext-Ansicht gehört, in der man den HTML-Code auch direkt bearbeiten kann.

Wenn ich aber wetten darauf abschließen müßte, wie häufig bei unserem System der Quelltext-Editor-Teil des WYSIWYG-Editors tatsächlich benutzt wird, dann würde ich wetten: zu 0% (selbst ich verwende ihn nicht, weil ich einen separaten Nur-Quelltext-Online-Editor habe).

Genausowenig wird bei unseren Dreamweaver-Nutzern dort der Quelltext-Teil benutzt.

Nochmal: Die User wollen nunmal etwas wie ihre Textverarbeitung haben, und sich nicht mit HTML-, ...

Deshalb würde ich eigentlich eher Wikisyntax/BB-Code-Ähnliche Textauszeichnungen empfehlen, auch gerne in Verbindung mit einer Echtzeitvorschau.

BB-, oder sonstigem Code auseinandersetzen. Das mag man bedauern, aber alles andere halte ich aus diesem Grund leider für unrealistisch.

Gruß, Cybaer

[Jonathan]

Hallo Cybaer,

Ich glaube hingegen, daß "Redakteure" eher überhaupt keine Auszeichnungen benötigen. Wenn es sich um eh "standardisierte" Texte handelt, kommt im Zweifel nur eine Klartext-Eingabe in Frage.

Naja, man will vielleicht schon mal nen Link setzen oder nen textabschnitt fett färben.

Ich weiß nicht, was die Online-WYSIWYG-Editoren so bieten, aber ich vermute mal, daß zu so ziemlich jedem WYSIWYG-Editor auch eine Quelltext-Ansicht gehört, in der man den HTML-Code auch direkt bearbeiten kann.

Das stimmt so nicht. Ich vermute sogar, dass es kaum einen Online-WYSIWYG-Editor gibt, indem man den HTML-Code bearbeiten (oder wenigstens direkt anzeigen) kann.

Wenn ich aber wetten darauf abschließen müßte, wie häufig bei unserem System der Quelltext-Editor-Teil des WYSIWYG-Editors tatsächlich benutzt wird, dann würde ich wetten: zu 0% (selbst ich verwende ihn nicht, weil ich einen separaten Nur-Quelltext-Online-Editor habe).

Genausowenig wird bei unseren Dreamweaver-Nutzern dort der Quelltext-Teil benutzt.

Ja, weil das eben die Standard-Ansicht ist. Ich wette aber, dass die wenigsten Leute kaum ein Problem damit haben ne simple Auszeichnungssprache einzusetzen.

Nochmal: Die User wollen nunmal etwas wie ihre Textverarbeitung haben, und sich nicht mit HTML-, ...

BB-, oder sonstigem Code auseinandersetzen. Das mag man bedauern, aber alles andere halte ich aus diesem Grund leider für unrealistisch.

Was denn für User? Ich gehe davon aus, dass die meisten Leute, die Internetseiten "administrieren" auch schon Internetforen kennen und somit mit dem Umgang mit BB-Codes und ähnlichem vertraut sind.

Jonathan

[Cybaer]

Hi,

Das stimmt so nicht. Ich vermute sogar, dass es kaum einen Online-WYSIWYG-Editor gibt, indem man den HTML-Code bearbeiten (oder wenigstens direkt anzeigen) kann.

Also mit FCK, tinyMCE und openWYSIWYG fallen mir spontan 3 WYSIWYG-Editoren mit Quellcode-Modus ein.

Was denn für User? Ich gehe davon aus, dass die meisten Leute, die Internetseiten "administrieren" auch schon Internetforen kennen und somit mit dem Umgang mit BB-Codes und ähnlichem vertraut sind.

Davon kann man nach meiner Erfahrung *nicht* ausgehen.

Es mag sicher sehr web-affine Menschen geben, die in/für ihre Firma auch Texte online stellen, aber soo stark wie uns Power-Usern es vielleicht mitunter scheinen mag, ist die alltägliche Web-Durchdringung IMHO bei weitem noch nicht.

Gruß, Cybaer

[Robert Bienert]

Moin!

Die Frage ist, warum Entwickler von HTML-WYSIWYG-Editoren solch Unsinn wie physische Formatierung überhaupt in den Editor einbauen. Die Schuld daran, dass HTML-WYSIWYG-Editoren so grottenschlechten Quelltext generieren, liegt bei den Entwicklern der Editoren; nicht bei deren Anwendern, die die unsinnigen Funktionalitäten dann auch tatsächlich nutzen.

Genau so sehe ich das auch! Dass es gar nicht so schwierig ist, vernünftige WYSIWYG-Editoren für HTML herzustellen hat (ausgerechnet) Microsoft mit seiner »Entwicklungsumgebung« (zumindest die für Office 2000) gezeigt und auch Nvu könnte mit ein bisschen Anstrengung gut mitarbeiten.

Mein Traum ist allerdings immer noch ein Web-Editor „wie OpenOffice“, d.h. z.B. CSS-Klassen als Formatvorlagen und ein bequemes Bearbeiten von Tabellen oder Bildern.

Viele Grüße,
Robert

[MudGuard]

Hi,

Das ist allerdings auch kein HTML 5, da HTML 5 kein STYLE-Attribut mehr kennt (außer beim FONT-Element)! :)
Was hat font in einer seriösen HTML-Version überhaupt noch suchen?

Du unterstellst, daß HTML 5 seriös ist ...

cu,
Andreas

[Daniel unreg]

Hallo,

Was hat font in einer seriösen HTML-Version überhaupt noch suchen?

Du unterstellst, daß HTML 5 seriös ist ...

Wieso sollte es das nicht sein?

Zudem schafft es das Element sehr wahrscheinlich nicht, weiterhin enthalten zu bleiben.

Gruß

[Cybaer]

Hi,

Du unterstellst, daß HTML 5 seriös ist ...
Wieso sollte es das nicht sein?

Es wurde dem guten W3C, Hüter der Reinheit des Geistes und der Seele, (wie die allermeisten Entwicklungen/realen Standards) von bösen Schurken übel aufgezwungen. :-)

Gruß, Cybaer

[Daniel unreg]

Hallo,

Es wurde dem guten W3C, Hüter der Reinheit des Geistes und der Seele, (wie die allermeisten Entwicklungen/realen Standards) von bösen Schurken übel aufgezwungen. :-)

Klar, wie konnte ich nur so blind sein? ;)

Gruß

[Jonathan]

Hallo Cybaer,

Das ist allerdings auch kein HTML 5, da HTML 5 kein STYLE-Attribut mehr kennt (außer beim FONT-Element)! :)

Das Font-Element wirds wahrscheinlich nicht in HTML5 schaffen.

http://www.w3.org/TR/2008/WD-html5-20080122/#the-font

This entire section will probably be dropped.

Jonathan

[Cybaer]

Hi,

Das Font-Element wirds wahrscheinlich nicht in HTML5 schaffen.

Wir werden sehen (ist ja eh alles nur vorläufig). Ich finde die Idee allerdings durchaus gut: Es ist Abwärtskompatibel, und ich finde FONT in einem "WYSIWYG"-Editor absolut angenehmer, als die ebenso uninspirierte Massenverwendung von SPANs zum gleichen Zweck. Da kann man wenigstens gut unterscheiden, was der Editor verbrochen hat, und was wirklich gewollt ist.

Gruß, Cybaer

[Robert Bienert]

Moin!

bei all den Diskussionen um die nächste Version des Internet Explorers ist wohl keinem aufgefallen, dass auch die nächste Version von (X)HTML einen neuen Meilenstein erreicht hat (oder es hat keinen interessiert, was ich dann schade fände).

Also den Arbeitsentwurf einen Meilenstein zu nennen, ich weiß nicht (bzw. HTML 5 generell so zu bezeichnen):

• ein leerer DOCTYPE (wozu überhaupt? HTML ist SGML, also eine DTD, und für die XHTML-Variante hätte man sich was Schönes (DTD, Schema, Relax NG) für den Parser aussuchen können)

• XML-Namensraum von XHTML 1 zum Verwirren von Parsern oder Transformatoren

• audio, video und embed: Erinnert sich noch jemand daran, warum object eingeführt worden ist? Aber gleichzeitig: „applet has been obsoleted in favor of object.“

• „The contextmenu attribute can be used to point to a context menu provided by the author.“ – Rechte Maustaste sperren?

• absent attributes: „longdesc attribute on img and iframe“

Da finde ich XHTML 2 schon den konsequenteren Entwurf, auch wenn XForms ganz schön starker Tobak ist.

Schönes Wochenende,
Robert

[ChrisB]

Hi,

bei all den Diskussionen um die nächste Version des Internet Explorers ist wohl keinem aufgefallen, dass auch die nächste Version von (X)HTML einen neuen Meilenstein erreicht hat (oder es hat keinen interessiert, was ich dann schade fände).

Also den Arbeitsentwurf einen Meilenstein zu nennen, ich weiß nicht (bzw. HTML 5 generell so zu bezeichnen)

Es ist in der IT bei groesseren Projekten gaengige Praxis, sog. Milestones oder eben Meilensteine vorab zu definieren, an denen man eine bestimmte Phase abgeschlossen und ein nachpruefbares (Zwischen-)Ergebnis erreicht hat. Wie der historische Meilenstein an der Strasse steht er auch hier fuer einen bestimmten Wegabschnitt, den man hinter sich gebracht hat.

MfG ChrisB

[Daniel unreg]

Hallo,

• ein leerer DOCTYPE (wozu überhaupt? HTML ist SGML, also eine DTD, und für die XHTML-Variante hätte man sich was Schönes (DTD, Schema, Relax NG) für den Parser aussuchen können)

Die HTML-variante von HTML5 ist eben *kein* SGML mehr sondern eine eigene Sprache (die sich zugegebenermaßen an SGML inspiriert).

Der Doctype ist ein notwendiges Übel: Mit ihm sorgt man dafür, dass jeder Browser den Full standards mode verwendet! Ansonnsten hat er keine bedeutung und ist daher in XHTML5 überflüssig. Er ist deshalb leer, weil die Restlichen informationen sinnlos wären und die aktuelle Form schnell und einfach und vor allem problemlos (case-insesitive) von der Hand geht.

• XML-Namensraum von XHTML 1 zum Verwirren von Parsern oder Transformatoren

Das selbe gilt auch für XHTML 1.1 und 2.0, beide wollen zum jetzigen zeitpunkt diesen Namensraum verwenden, sind aber zueinander inkompatibel!

• audio, video und embed: Erinnert sich noch jemand daran, warum object eingeführt worden ist? Aber gleichzeitig: „applet has been obsoleted in favor of object.“

Hier kann man natürlich streiten, und embed hat leider wirklich eher Nachteile. Aber: Mit der selben Logik musst du auch das img-Element verbannen. Tust du das? ich denke es ist nicht verkehrt für bestimmte Zwecke ein Element zu besitzen. Solange es kein Element für *jeden* möglichen Zweck gibt.

• „The contextmenu attribute can be used to point to a context menu provided by the author.“ – Rechte Maustaste sperren?

Das hört sich gefährlich an, ja. Die Möglichkeit, damit Schund zu treiben wird aber von aktuellen Browsern bereits sehr gut unterbunden.
Das Attribut selbst soll, so nehme ich an, die Gestaltung von Webanwendungen leichter machen. Was ja durchaus ein Ziel von HTML 5 ist.

• absent attributes: „longdesc attribute on img and iframe“

Ja, aber reiß das nicht aus dem Zusammenhang. Hier wurde geforscht und man hat herausgefunden, dass das longdesc-Attribut sehr sehr selten seinem Zweck entsprechend verwendet wird. Darüberhinaus sind sich die benutzer von Screanredern usw. dieser Möglichkeit nicht bewusst (auf Youtube gibts dazu auch ein Video von einem Jaws-Benutzer).

Da finde ich XHTML 2 schon den konsequenteren Entwurf, auch wenn XForms ganz schön starker Tobak ist.

Ich finde XHTML 2.0 nicht konsequent. Es ist eine Sprache, die mit HTML nichts mehr zu tun haben will, sondern etwas ganz neues darstellt. Dennoch will man nicht auf obsolote Elemente, wie z.B. das body-Element verzichten.

Gut, hierüber kann man ebenfalls streiten. Aber der Web Forms 2.0 der WHATWG (der sich ebenfalls beim W3C befindet), will ähnliche Fortschritte machen, wie XForms, dabei aber kompatibel bleiben und für Benutzer verständlich. Auch hier wird eine Live-Überprüfung der Eingaben möglich sein.

Schönes Wochenende,

Ebenfalls :)

[Robert Bienert]

Moin!

• ein leerer DOCTYPE (wozu überhaupt? HTML ist SGML, also eine DTD, und für die XHTML-Variante hätte man sich was Schönes (DTD, Schema, Relax NG) für den Parser aussuchen können)

Der Doctype ist ein notwendiges Übel: Mit ihm sorgt man dafür, dass jeder Browser den Full standards mode verwendet! Ansonnsten hat er keine bedeutung und ist daher in XHTML5 überflüssig. Er ist deshalb leer, weil die Restlichen informationen sinnlos wären und die aktuelle Form schnell und einfach und vor allem problemlos (case-insesitive) von der Hand geht.

Erst einmal vorweg: Ich finde case-insensitive nicht problemlos, sondern problembeladen: Es erzeugt Verwirrung beim Anwender, vor allem bei mehreren Anwendern, und erzeugt Mehraufwand beim Programmierer.

Der Doctype enthält nicht nur das „notwendige SGML-Übel“, sondern für den Parser potenziell wichtige Informationen: Eine DTD zum Prüfen sowie eine Versionsangabe. Wenn sich HTML5 mit <!DOCTYPE html> zufrieden gibt, wie will ich dann den Unterschied zu HTML6 kennzeichnen? Das ist einfach nicht zu Ende gedacht. Oder soll es in Zukunft HTML5 + Zusätze geben?

• XML-Namensraum von XHTML 1 zum Verwirren von Parsern oder Transformatoren

Das selbe gilt auch für XHTML 1.1 und 2.0, beide wollen zum jetzigen zeitpunkt diesen Namensraum verwenden, sind aber zueinander inkompatibel!

Arbeiten da irgendwo auch Informatiker oder Mathematiker  ;-)

• audio, video und embed: Erinnert sich noch jemand daran, warum object eingeführt worden ist? Aber gleichzeitig: „applet has been obsoleted in favor of object.“

Hier kann man natürlich streiten, und embed hat leider wirklich eher Nachteile. Aber: Mit der selben Logik musst du auch das img-Element verbannen. Tust du das?

Ich hätte keine Probleme damit, img aus der Sprach zu entfernen. object ist doch viel flexibler: Der alternative Inhalt kann HTML sein, Microsofts CSS-Vergewaltigung, damit der MSIE transparente PNGs kann, hätte man als param definieren können. OK, für longdesc gäbe es dann keinen Ersatz …

• absent attributes: „longdesc attribute on img and iframe“

Ja, aber reiß das nicht aus dem Zusammenhang. Hier wurde geforscht und man hat herausgefunden, dass das longdesc-Attribut sehr sehr selten seinem Zweck entsprechend verwendet wird. Darüberhinaus sind sich die benutzer von Screanredern usw. dieser Möglichkeit nicht bewusst (auf Youtube gibts dazu auch ein Video von einem Jaws-Benutzer).

Sofern das Attribut denn überhaupt verwendet wird, wie wird es denn „falsch“ verwendet. Und dass User-Agents darauf keinen gescheiten Zugriff bieten würde ich nicht der Sprache anlasten, sondern den Entwicklern.

Da finde ich XHTML 2 schon den konsequenteren Entwurf, auch wenn XForms ganz schön starker Tobak ist.

Ich finde XHTML 2.0 nicht konsequent. Es ist eine Sprache, die mit HTML nichts mehr zu tun haben will, sondern etwas ganz neues darstellt. Dennoch will man nicht auf obsolote Elemente, wie z.B. das body-Element verzichten.

Die Schnittmenge von XHTML2 und XHTML1 ist allerdings nicht leer, sondern schon ganz gut gefüllt. Was ich wirklich gut finde, ist, dass man Navigationslisten auch als solche auszeichnen kann oder die Strukturierung mittels section und h. Warum soll denn body eigentlich obsolet sein?

Gut, hierüber kann man ebenfalls streiten. Aber der Web Forms 2.0 der WHATWG (der sich ebenfalls beim W3C befindet), will ähnliche Fortschritte machen, wie XForms, dabei aber kompatibel bleiben und für Benutzer verständlich. Auch hier wird eine Live-Überprüfung der Eingaben möglich sein.

Bei XForms geht es mir nicht nur um die Live-Überprüfung der Eingabe, sondern auch das klare MVC, was dahinter steckt oder die Serialisierung in XML. Wer sich mit GUI-Programmierung auskennt, findet da viele Gemeinsamkeiten. Das ist aber auch gleichzeitig eine Hürde für HTML-Autoren, das gebe ich zu. Web Forms 2.0 ist da ein recht guter Ansatz, zumal die Elemente, die es einführt, wahrscheinlich auf der Wunschliste fast jeden HTML-Autors stehen.

Wenn man jetzt „in XML machen würde“, könnte man beides als Module anbieten …

Schönen Sonntag,
Robert

[Daniel unreg]

Hallo,

Erst einmal vorweg: Ich finde case-insensitive nicht problemlos, sondern problembeladen: Es erzeugt Verwirrung beim Anwender, vor allem bei mehreren Anwendern, und erzeugt Mehraufwand beim Programmierer.

Den sehe ich nicht. Für Autoren ist es doch einfacher, weil man sich nicht merken muss: DOCTYPE groß, html klein usw.

Der Doctype enthält nicht nur das „notwendige SGML-Übel“, sondern für den Parser potenziell wichtige Informationen: Eine DTD zum Prüfen sowie eine Versionsangabe. Wenn sich HTML5 mit <!DOCTYPE html> zufrieden gibt, wie will ich dann den Unterschied zu HTML6 kennzeichnen? Das ist einfach nicht zu Ende gedacht. Oder soll es in Zukunft HTML5 + Zusätze geben?

Zunächst: HTML5 basiert nicht mehr auf SGML, sondern definiert HTML5 als eigene SGML-inspirierte Sprache. Daher ist eine DTD nutzlos. Das ist sie nebenbei auch bei XHTML.

HTML5 ist hier einfach ganz anders aufgebaut als frühere versionen. HTML 5 ist als Teilmenge von HTML 6 definiert. Das selbe Prinzip lässt sich heute schon bei XHTML betrachten. Es ist ein guter Ansatz, aber man nmuss zugegebernamaßer erstmal durchblicken, wie er funktioneirt :)

Sofern das Attribut denn überhaupt verwendet wird, wie wird es denn „falsch“ verwendet. Und dass User-Agents darauf keinen gescheiten Zugriff bieten würde ich nicht der Sprache anlasten, sondern den Entwicklern.

Zunächst mal wird es sehr selten verwendet. Dann verwendet es der großteil falsch. Beispielsweise zeigt der Attributwert nicht auf eine langbeschreibung, sondern auf sich selbst oder anderen nutzlosen Kram, der Rest ist ein winzig kleiner Bruchteil.

Nebenbei: Longdesc *wird* von Benutzeragenten erkannt und an entsprechende Programme weitergegeben. Aber die Informationen sind so selten, dass der tatsächliche Benutzer so wenig davon hat, dass er das longdesc-Attribut gar nicht kennt (bzw. seine Repräsentation im Programm).

Die Schnittmenge von XHTML2 und XHTML1 ist allerdings nicht leer, sondern schon ganz gut gefüllt. Was ich wirklich gut finde, ist, dass man Navigationslisten auch als solche auszeichnen kann oder die Strukturierung mittels section und h. Warum soll denn body eigentlich obsolet sein?

Die Schnittmenge muss ja nicht leer sein. Aber man hätte sich hier wirklich der Altlasten entlegigen können. img, a, und andere Elemente sind nutzlos bei dem Hintergrund den XHTML 2.0 bietet.

Navigationlisten schön und gut. Ein großteil der Autoren verwendet aktuell div@id=nav, deshalb entstand in HTML5 das rückwärtskompatible nav-Element.

section/h ist eine gute Idee. HTML5 macht es nur ein bisschen anders, um Kompatibel zu bleiben.

Aber gut, ich will hier keinen Streit XHTML2 vs. HTML 5 auslösen. Beide haben ja verschiedene Ziele.

Wenn man jetzt „in XML machen würde“, könnte man beides als Module anbieten …

Ich könnte dich missverstehen, aber sowohl HTML5 als auch WF2 sind XML-kompatibel und modularisierbar.

Gruß

[Robert Bienert]

Moin!

Erst einmal vorweg: Ich finde case-insensitive nicht problemlos, sondern problembeladen: Es erzeugt Verwirrung beim Anwender, vor allem bei mehreren Anwendern, und erzeugt Mehraufwand beim Programmierer.

Den sehe ich nicht. Für Autoren ist es doch einfacher, weil man sich nicht merken muss: DOCTYPE groß, html klein usw.

Dann vergleich doch mal die Eierei, die man bei größeren Projekten in Sprachen wie SQL, Pascal oder Fortran hat: Da braucht man allein schon wegen der Schreibung Konventionen. Der case-sensitive-Ansatz ist da viel klarer, man sagt z.B. CamelCase und schon weiß jeder Bescheid.

Der Doctype enthält nicht nur das „notwendige SGML-Übel“, sondern für den Parser potenziell wichtige Informationen: Eine DTD zum Prüfen sowie eine Versionsangabe. Wenn sich HTML5 mit <!DOCTYPE html> zufrieden gibt, wie will ich dann den Unterschied zu HTML6 kennzeichnen? Das ist einfach nicht zu Ende gedacht. Oder soll es in Zukunft HTML5 + Zusätze geben?

HTML5 ist hier einfach ganz anders aufgebaut als frühere versionen. HTML 5 ist als Teilmenge von HTML 6 definiert. Das selbe Prinzip lässt sich heute schon bei XHTML betrachten. Es ist ein guter Ansatz, aber man nmuss zugegebernamaßer erstmal durchblicken, wie er funktioneirt :)

Was ich meinte (deine Antwort geht vollkommen daran vorbei): HTML 4.01 erkenne ich an <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">, dann könnte ich doch HTML 5 mit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5//EN"> deklarieren, HTML 6 … Diese Information ist für einen Parser doch vielleicht gar nicht so unwichtig. Aus dem gleichen Grund sollten XHTML 5, XHTML 2 und XHTML 1 auch unterschiedliche Namensräume benutzen.

Navigationlisten schön und gut. Ein großteil der Autoren verwendet aktuell div@id=nav, deshalb entstand in HTML5 das rückwärtskompatible nav-Element.

… und in XHTML 2 nl.

Wenn man jetzt „in XML machen würde“, könnte man beides als Module anbieten …

Ich könnte dich missverstehen, aber sowohl HTML5 als auch WF2 sind XML-kompatibel und modularisierbar.

Was ich meinte: Man könnte Web Forms 2 und XForms als Module (mit jeweils eigenem Namensraum) gestalten, die man in XHTML einbetten kann, der Anwender hätte also die Wahl zwischen beiden Modellen. An der Stelle könnte man den alten HTML-Zopf abschneiden und nur noch in XML weiterentwickeln – aber ohne DTD: XHTML+MathML oder XHTML+SVG sind sehr krude Möglichkeiten, andere XML-Inhalte einzubinden.

Schönen Sonntag,
Robert

[Robert Bienert]

Moin!

Einen kleinen Nachtrag hierzu habe ich:

HTML 4.01 erkenne ich an <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">, dann könnte ich doch HTML 5 mit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5//EN"> deklarieren, HTML 6 … Diese Information ist für einen Parser doch vielleicht gar nicht so unwichtig. Aus dem gleichen Grund sollten XHTML 5, XHTML 2 und XHTML 1 auch unterschiedliche Namensräume benutzen.

XHTML 2 soll übrigens einen eigenen Namensraum benutzen: „The namespace URI for XHTML 2.0 is defined to be http://www.w3.org/2002/06/xhtml2/.“ – XHTML 2.0 Conformance Definition.

Schönen Sonntag,
Robert

[Daniel unreg]

Hallo,

XHTML 2 soll übrigens einen eigenen Namensraum benutzen: „The namespace URI for XHTML 2.0 is defined to be http://www.w3.org/2002/06/xhtml2/.“ – XHTML 2.0 Conformance Definition.

Wie gesagt, deren Entwuf ist schon betagt. Inzwischen wollens ie den XHTML1.x-Namensraum verwenden.

Gruß

[Gunnar Bittersmann]

@@Robert Bienert:

Diese Information [HTML-Version] ist für einen Parser doch vielleicht gar nicht so unwichtig. Aus dem gleichen Grund sollten XHTML 5, XHTML 2 und XHTML 1 auch unterschiedliche Namensräume benutzen.

?? Parser sollen anhand des Namensraums auf die XHTML-Version (und deren Regeln) schließen?

Nein! Namensräume haben mit den Regeln (Grammatik der Sprache) nichts zu tun. [http://forum.de.selfhtml.org/archiv/2007/12/t163502/#m1064996 unten]

Es spricht wohl nichts gegen einen gemeinsamen Namensraum.

Was ich meinte: Man könnte Web Forms 2 und XForms als Module (mit jeweils eigenem Namensraum) gestalten, die man in XHTML einbetten kann, der Anwender hätte also die Wahl zwischen beiden Modellen.

Das hört sich gut an. XHTML 2 mit der für Autoren evtl. einfacher zu handhabenden Option der Web Forms 2 (anstelle der unständlicheren XForms) – da wär’s doch. Dann käme HTML 5 an den ihm zustehenden Platz: in die Tonne!!1elf

?? aber ohne DTD: XHTML+MathML oder XHTML+SVG sind sehr krude Möglichkeiten, andere XML-Inhalte einzubinden.

„Krude“? Es geht doch mit DTD.

(BTW, gibt es XHTML+SVG, oder meinstest du XHTML+MathML+SVG?)

Live long and prosper,
Gunnar

[Daniel unreg]

Hallo,

Was ich meinte (deine Antwort geht vollkommen daran vorbei): HTML 4.01 erkenne ich an <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">, dann könnte ich doch HTML 5 mit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5//EN"> deklarieren, HTML 6 … Diese Information ist für einen Parser doch vielleicht gar nicht so unwichtig. Aus dem gleichen Grund sollten XHTML 5, XHTML 2 und XHTML 1 auch unterschiedliche Namensräume benutzen.

Was ich meite (deine Antwort geht vollkommen daran vorbei): HTML 5 macht das Überflüssig, weil ein HTML-Dokument keine Versionsnummer mehr trägt. Es ist so definiert, das jedes HTML-Dokument ein HTML-Dokument der aktuellen Version ist. Es ist dadurch nur wenig anders als XHTML, das auch völlig ohne Versionierung auskommt.

… und in XHTML 2 nl.

Ein Ansatz der zu XHTML 2 passt. Dagegen spreche ich ja nicht ;)

Gruß

[Robert Bienert]

Moin!

Was ich meinte (deine Antwort geht vollkommen daran vorbei): HTML 4.01 erkenne ich an <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">, dann könnte ich doch HTML 5 mit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5//EN"> deklarieren, HTML 6 … Diese Information ist für einen Parser doch vielleicht gar nicht so unwichtig. Aus dem gleichen Grund sollten XHTML 5, XHTML 2 und XHTML 1 auch unterschiedliche Namensräume benutzen.

Was ich meite (deine Antwort geht vollkommen daran vorbei): HTML 5 macht das Überflüssig, weil ein HTML-Dokument keine Versionsnummer mehr trägt. Es ist so definiert, das jedes HTML-Dokument ein HTML-Dokument der aktuellen Version ist. Es ist dadurch nur wenig anders als XHTML, das auch völlig ohne Versionierung auskommt.

Dann würde ich gerne mal das Wort an Browserprogrammierer weitergeben: Wie geht man denn dann mit unterschiedlichen Sprachversionen um? Tag-Suppe heißt wohl, dass ein HTML4-Dokument auch noch HTML2-Elemente enthalten darf?

Viele Grüße,
Robert

[Jonathan]

Hallo Robert,

Dann würde ich gerne mal das Wort an Browserprogrammierer weitergeben: Wie geht man denn dann mit unterschiedlichen Sprachversionen um? Tag-Suppe heißt wohl, dass ein HTML4-Dokument auch noch HTML2-Elemente enthalten darf?

HTML soll eben abwärtskompatibel sein. Auch wenn jetzt z.B. das <s>-Element mit HTML5 aus dem Standard entfällt definiert der Standard immernoch was der Browser damit machen soll. Der Browser implementiert im idealfall einfach HTML5 und kann damit alle vorhergehenenden Versionen darstellen, auch HTML4 oder HTML2.

Jonathan

[Daniel unreg]

Hallo,

Dann würde ich gerne mal das Wort an Browserprogrammierer weitergeben: Wie geht man denn dann mit unterschiedlichen Sprachversionen um? Tag-Suppe heißt wohl, dass ein HTML4-Dokument auch noch HTML2-Elemente enthalten darf?

Ja, es ist in der Tat bereits aktuell so, dass ein Browser, der HTML verarbeitet keine HTML Versionen kennt. Das sieht du z.B. Wenn du in ein HTML-4.01-Strict-Dokument Transitional-Elemente und -Attribute einfügst.

Nur der IE ist hier eine Ausnahme, da der ja seinen Kenntnisstand über den Doctype einfriert. Aber selbst der ist im Prinzip das selbe.

Ohne Doctype ist das sogar in XHTML-Dokumenten möglich. Daraus zieht HTML5 seinen Nutzen.

Gruß

[molily]

Hallo,

embed hat leider wirklich eher Nachteile. Aber: Mit der selben Logik musst du auch das img-Element verbannen. Tust du das?

Schon seit Jahren plädieren Leute dafür, img und alle anderen zugunsten von object aufzugeben. In XHTML 2 ist es bloß drin »to ease the transition to XHTML2«. Die Einbindung mit src braucht solche Container sowieso nicht.

In HTML 5 wollte man in dem Punkt offenbar einfach die verbreitete Praxis redefinieren. Wie in so vielen Fällen.

Allerdings kann ich in manch anderen Fällen verstehen, dass im Detail unterschiedliches Browserverhalten nun standardisiert wird, indem man den Mittelweg der vorhandenen Implementationen sucht. Bei embed wird aber gar nicht soviel neu definiert.

ich denke es ist nicht verkehrt für bestimmte Zwecke ein Element zu besitzen.

embed bringt aber überhaupt keine Vorteile, also abgesehen davon, dass Browserimplementationen existieren.

Bei video und audio könnte man einwenden, dass diese existieren, um ein neues spezielles Interface zu bieten, das so auf object allgemein nicht zutrifft.

Ich finde XHTML 2.0 nicht konsequent. Es ist eine Sprache, die mit HTML nichts mehr zu tun haben will, sondern etwas ganz neues darstellt. Dennoch will man nicht auf obsolote Elemente, wie z.B. das body-Element verzichten.

Hab ich was verpasst oder wieso ist body obsolet?

Mathias

[Daniel unreg]

Hallo,

Schon seit Jahren plädieren Leute dafür, img und alle anderen zugunsten von object aufzugeben. In XHTML 2 ist es bloß drin »to ease the transition to XHTML2«. Die Einbindung mit src braucht solche Container sowieso nicht.

Hier sieht man eben die Unterschiede. HTML5 will halt rückwärtskompatibel bleiben. XHTML 2.0 will eigentlich was neues machen.

Die Sache ist nur, in XHTML 2.0 befindet sich eine Menge »to ease the transition to XHTML2«.

Allerdings kann ich in manch anderen Fällen verstehen, dass im Detail unterschiedliches Browserverhalten nun standardisiert wird, indem man den Mittelweg der vorhandenen Implementationen sucht. Bei embed wird aber gar nicht soviel neu definiert.

Ich weis davon leider nicht viel, aber so viel ich weis, will man embed wegen Flash behalten bzw. embed als Flash-Container nutzen.

Hab ich was verpasst oder wieso ist body obsolet?

Welchen sinn hat es denn? Es ist nur ein weiteres »to ease the transition to XHTML2«.

Und gerade hier sehe ich das Problem. Denn die »the transition to XHTML2« ist eben gar nicht einfach, weil Elemente wie p völlig anders definiert sind. Ich sehe keinen Grund, große Änderungen zu machen, wenn man dann an diesen altlasten hängen bleibt. Und ja, Zu den Altlasten gehören auch das img- und das a-Element und vermutlich noch einige weitere.

Gruß

[Robert Bienert]

Moin!

so viel ich weis, will man embed wegen Flash behalten bzw. embed als Flash-Container nutzen.

Wozu? Wenn man object _richtig_ anwendet (und diese Web 0.0 Videoplattformen tun es durch die Bank weg nicht), braucht man kein Netscape-4-legacy (!) embed.

Hab ich was verpasst oder wieso ist body obsolet?

Welchen sinn hat es denn?

Es kennzeichnet den Textkörper aus, oder?

Und gerade hier sehe ich das Problem. Denn die »the transition to XHTML2« ist eben gar nicht einfach, weil Elemente wie p völlig anders definiert sind.

Welche Bedeutung soll denn p auf einmal bekommen? Laut aktuellem Working Draft wird p ein bisschen aufgebohrt.

Schönen Sonntag,
Robert

[Daniel unreg]

Hallo,

Wozu? Wenn man object _richtig_ anwendet (und diese Web 0.0 Videoplattformen tun es durch die Bank weg nicht), braucht man kein Netscape-4-legacy (!) embed.

Es wurde doch dieser mozilla-bug angesprochen. ich hab ihn nur überflogen, aber macht der nicht Probleme beim Flash-über-Object-Einbinden?

Tut mir leid, ich hab nichts mit Flash zu tun.

Mir ist schon klar, dass embed diskussionbedürftig ist. Ich habe mich auch gefragt, was das soll. Es ist sicherlich nicht der schönste teil des Entwurfs.

Es kennzeichnet den Textkörper aus, oder?

Eigentlich ist body nicht sehr viel mehr Wert als div. Bei XHTML 2.0 hat man ja auch überlegt, es zu entfernen, aber »to ease the transition to XHTML2« wurde es halt behalten.

Welche Bedeutung soll denn p auf einmal bekommen? Laut aktuellem Working Draft wird p ein bisschen aufgebohrt.

Zunächst mal ist der WD schon recht alt :) Aber naja, das aufbohren ist eben etwas ganz anderes als das was man bisher mit p anstellen konnte.

Schöne Woche.

[Gunnar Bittersmann]

@@Daniel unreg:

Aber naja, das aufbohren ist eben etwas ganz anderes als das was man bisher mit p anstellen konnte.

In XHTML wurde ein Makel berichtigt, den HTML 4/XHTML 1 noch mit sich rum schleppte: Warum sollte man

„Lorem ipsum dolor sit amet, consetetur sadipscing elitr:

• foo,
• bar,
• baz,
  sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.“

nicht als das auszeichnen, was es ist: ein Absatz, der eine Liste enthält? Also:

<p>  
  Lorem ipsum dolor sit amet, consetetur sadipscing elitr:  
  <ul>  
    <li>foo,</li>  
    <li>bar,</li>  
    <li>baz,</li>  
  </ul>  
  sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.  
</p>

In HTML 4/XHTML 1 nicht möglich, in XHTML 2 schon – völlig zurecht. HTML 5 versäumt es, den Makel in HTML 4/XHTML 1 auszumerzen.

Auch an anderer Stelle versagt HTML 5 völlig: bei Definitionslisten. Es fehlt wie schon in HTML 4/XHTML 1 ein Element, um zusammengehörige 'dt' und 'dd' zu gruppieren. [</archiv/2007/10/t160872/#m1046502>] In XHTML 2 wurde dieser Mangel behoben: es gibt 'di'.

In XHTML 2 gibt es noch viele andere wirklich sinnvolle Neuerungen. Es ist zu befürchten, dass HTML 5 der Verbreitung von XHTML 2 im Wege steht, also eine Bremse des Fortschritts darstellt.

Live long and prosper,
Gunnar

[Daniel unreg]

Hallo,

In XHTML wurde ein Makel berichtigt, den HTML 4/XHTML 1 noch mit sich rum schleppte: Warum sollte man [...] nicht als das auszeichnen, was es ist: ein Absatz, der eine Liste enthält?

Bis vor kurzem war das in HTML5 möglich. Allerdings wurde das Elementmodell stark überarbeitet ud ich weis nicht, wie es aktuell aussieht.

Auch an anderer Stelle versagt HTML 5 völlig: bei Definitionslisten. Es fehlt wie schon in HTML 4/XHTML 1 ein Element, um zusammengehörige 'dt' und 'dd' zu gruppieren. [</archiv/2007/10/t160872/#m1046502>] In XHTML 2 wurde dieser Mangel behoben: es gibt 'di'.

Da gebe ich dir schon recht, aber man darf ja nicht vergessen, dass beide Sprachen ein Entwurf sind. XHTML 2.0 wird weder src noch href für alle Elemente behalten, verliert also auch seine Reize.

In XHTML 2 gibt es noch viele andere wirklich sinnvolle Neuerungen. Es ist zu befürchten, dass HTML 5 der Verbreitung von XHTML 2 im Wege steht, also eine Bremse des Fortschritts darstellt.

Ich denk ob HTML5 oder nicht hat mit der Verbreitung von XHTML 2.0 nichts zu tun.

Außerdem bremst XHTML 2.0 doch selbst. Die WG arbeitet doch an allem außer XHTML 2.0 selbst.

Gruß

[Robert Bienert]

Moin!

Wozu? Wenn man object _richtig_ anwendet (und diese Web 0.0 Videoplattformen tun es durch die Bank weg nicht), braucht man kein Netscape-4-legacy (!) embed.

Es wurde doch dieser mozilla-bug angesprochen. ich hab ihn nur überflogen, aber macht der nicht Probleme beim Flash-über-Object-Einbinden?

Welcher Mozilla-Bug? In diesem Zusammenhang ist mir nur ein Bug bekannt, den Webautoren machen, weil er von Macromedia irgendwann mal vorgeschlagen wurde: object ohne data-Attribut.

Viele Grüße,
Robert

[Daniel unreg]

Hallo,

Welcher Mozilla-Bug? In diesem Zusammenhang ist mir nur ein Bug bekannt, den Webautoren machen, weil er von Macromedia irgendwann mal vorgeschlagen wurde: object ohne data-Attribut.

Nummer 46569, allerdings weis ich nicht mehr, ich hatte noch nicht die Zeit ihn genauer anzusehen.

gruß

[Robert Bienert]

Moin!

Welcher Mozilla-Bug? In diesem Zusammenhang ist mir nur ein Bug bekannt, den Webautoren machen, weil er von Macromedia irgendwann mal vorgeschlagen wurde: object ohne data-Attribut.

Nummer 46569, allerdings weis ich nicht mehr, ich hatte noch nicht die Zeit ihn genauer anzusehen.

Nach dem Durchlesen: Wessen Bug istn das? Ich glaube, dass Macromedia, Microsoft und andere Plugin-Hersteller einen gewissen Anteil daran haben.

Viele Grüße,
Robert