HTML5 oder besser nicht?

[Guy Gaz]

Hallo SelfHTML-Gemeinde!

Seit einigen Tagen befasse ich mich mit der Erstellung eines neuen privaten Webauftrittes und habe bereits die generelle Struktur, einige Inhalte und das rein CSS-gestützte Layout erarbeitet.

Da ich meine überwiegend aus längeren Texten bestehenden Inhalte möglichst sinnvoll semantisch auszeichnen möchte, stellt sich mir nun eine generelle Frage: welche HTML-Version verwende ich?

Zunächst habe ich, XHTML 1.0 strict gewählt und ein wenig mit Mikroformaten 'gespielt', um fehlende Elemente (z.B: für Datum und Zeit)
mittels dieser auszugleichen. Bei meinen Recherchen bin ich dann immer wieder auf HTML5 gestossen und habe mich erstmals auch damit beschäftigt.

Nun frage ich mich, ob der Einsatz von HTML5 bereits sinnvoll ist, oder ich lieber (noch) auf XHTML setzen soll. Was ist Eure Meinung dazu?

Vielen Dank!

Guy

[Cheatah]

Hi,

Nun frage ich mich, ob der Einsatz von HTML5 bereits sinnvoll ist, oder ich lieber (noch) auf XHTML setzen soll. Was ist Eure Meinung dazu?

Du fragst gerade, ob Du Hans-Martin Müller als neue Arbeitskraft einstellen möchtest, während sich seine Eltern noch über die aktuellen Ultraschall-Bilder freuen.

Cheatah

[Guy Gaz]

Hi,

Nun frage ich mich, ob der Einsatz von HTML5 bereits sinnvoll ist, oder ich lieber (noch) auf XHTML setzen soll. Was ist Eure Meinung dazu?

Du fragst gerade, ob Du Hans-Martin Müller als neue Arbeitskraft einstellen möchtest, während sich seine Eltern noch über die aktuellen Ultraschall-Bilder freuen.

Oh ein humorvoller Kommentar - so etwas mag ich. Ok ich habe verstanden, dass Du eher davon abrätst und HTML5 noch im pränatalen Stadium siehst.
Nun: schadet es denn, HTML5 zu benutzen? Das Erreichen der Pubertät wird doch wohl kaum 12 Jahre dauern oder siehst Du nach dessen Niederkunft direkt eine Versammlung trauernder Gäste anstehen?

Vielen Dank für die schnelle Antwort!

[Cheatah]

Hi,

Nun: schadet es denn, HTML5 zu benutzen?

das kommt darauf an, wie viel von HTML 5 Du benutzt. Von den interessanten Features rate ich derzeit noch ganz klar ab - und mir persönlich würde dann jeder Grund fehlen, überhaupt an den Einsatz von HTML 5 zu denken.

Das Erreichen der Pubertät wird doch wohl kaum 12 Jahre dauern oder siehst Du nach dessen Niederkunft direkt eine Versammlung trauernder Gäste anstehen?

Meine Glaskugel zeigt mir im Moment nur einen Haufen Leute, die mal mehr und mal weniger gespannt abwarten.

Cheatah

[Guy Gaz]

Hallo Cheatah!

Nun: schadet es denn, HTML5 zu benutzen?

das kommt darauf an, wie viel von HTML 5 Du benutzt. Von den interessanten Features rate ich derzeit noch ganz klar ab - und mir persönlich würde dann jeder Grund fehlen, überhaupt an den Einsatz von HTML 5 zu denken.

Das sehe ich dann auch so, denn es wären die neuen Features von HTML5, welche mich zu dessen Einsatz bewegen könnten. Würdest Du zum Einsatz von Mikroformaten raten, oder siehst Du dessen Verwendung ähnlich?

Das Erreichen der Pubertät wird doch wohl kaum 12 Jahre dauern oder siehst Du nach dessen Niederkunft direkt eine Versammlung trauernder Gäste anstehen?

Meine Glaskugel zeigt mir im Moment nur einen Haufen Leute, die mal mehr und mal weniger gespannt abwarten.

Ok, verstehe;) Danke für Deine Einschätzung!

[Cheatah]

Hi,

Würdest Du zum Einsatz von Mikroformaten raten, oder siehst Du dessen Verwendung ähnlich?

die wiederum halte ich für ziemlich unkritisch, sofern Du die data-Attribute meinst. In XHTML kriegst Du das selbe valide mit XML-Namespaces hin.

Cheatah

[Guy Gaz]

Hallo Cheatah!

Würdest Du zum Einsatz von Mikroformaten raten, oder siehst Du dessen Verwendung ähnlich?

die wiederum halte ich für ziemlich unkritisch, sofern Du die data-Attribute meinst. In XHTML kriegst Du das selbe valide mit XML-Namespaces hin.

Ok, danke! Dann werde ich weiterhin erstmal XHTML verwenden.

[Auge]

Hallo

Würdest Du zum Einsatz von Mikroformaten raten, oder siehst Du dessen Verwendung ähnlich?

die wiederum halte ich für ziemlich unkritisch, sofern Du die data-Attribute meinst. In XHTML kriegst Du das selbe valide mit XML-Namespaces hin.

Funktionieren die XML-Namespaces auch, wenn man, den IE nicht ausschließen wollend, das XHTML als text/html ausliefert?

Tschö, Auge

[Gunther]

Hallo!

Nun frage ich mich, ob der Einsatz von HTML5 bereits sinnvoll ist, oder ich lieber (noch) auf XHTML setzen soll. Was ist Eure Meinung dazu?

Ich sehe das ähnlich wie Cheatah. Aktuell sollte man es höchstens auf "experimentellen" Seiten (als Demo o.ä.) verwenden.

Hier noch Link zu Webkrauts.de, die gerade eine Reihe Artikel zum Thema HTML5 rausgebracht haben.

Generell stehe ich dem Entwurf von HTML5 eher "kritisch" gegenüber, aber das kannst bei Interesse auch in den Kommentaren der jeweiligen oben verlinkten Artikel nachlesen. ;-)

Gruß Gunther

[Guy Gaz]

Hallo Gunther!

Nun frage ich mich, ob der Einsatz von HTML5 bereits sinnvoll ist, oder ich lieber (noch) auf XHTML setzen soll. Was ist Eure Meinung dazu?
Ich sehe das ähnlich wie Cheatah. Aktuell sollte man es höchstens auf "experimentellen" Seiten (als Demo o.ä.) verwenden.

Ok, verstehe. Ich hatte die Existenz von HTML5 bislang gänzlich ignoriert und bin doch sehr angetan von dessen neuen Features. Diese nutzen mir natürlich solange nichts, wie die Unterstützung durch die UAs ausbleibt.

Hier noch Link zu Webkrauts.de, die gerade eine Reihe Artikel zum Thema HTML5 rausgebracht haben.

Das schaue ich mir an - auch Dir vielen Dank!

[Cybaer]

Hi,

Diese nutzen mir natürlich solange nichts, wie die Unterstützung durch die UAs ausbleibt.

Die kommt schon noch. Oder nutzt Du auch z.B. keine (bereits von den Browsern vorab unterstützten) CSS-3-Eigenschaften, weil CSS 3 noch nicht fertig, geschweige denn in den Browsern implementiert wäre?

So manche der hiesigen Hardcore-XHTML-Fans ("unbedingt XHTML", "XHTML ist die Zukunft", blabla ...) sind nur arg gefrustet, daß man ihnen ihr schönes Spielzeug auf den Schrotthaufen der Geschichte entsorgt hat. >:->

Gruß, Cybaer

[Guy Gaz]

Hallo!

Hi,

Diese nutzen mir natürlich solange nichts, wie die Unterstützung durch die UAs ausbleibt.

Die kommt schon noch. Oder nutzt Du auch z.B. keine (bereits von den Browsern vorab unterstützten) CSS-3-Eigenschaften, weil CSS 3 noch nicht fertig, geschweige denn in den Browsern implementiert wäre?

Nein dass tue ich tatsächlich nicht - aktuell nutze ich "nur" CSS 2.1;)

So manche der hiesigen Hardcore-XHTML-Fans ("unbedingt XHTML", "XHTML ist die Zukunft", blabla ...) sind nur arg gefrustet, daß man ihnen ihr schönes Spielzeug auf den Schrotthaufen der Geschichte entsorgt hat. >:->

Mhm, jetzt wird die Diskussion heterogener;) Vielen Dank!

[Cybaer]

Hi,

Nein dass tue ich tatsächlich nicht - aktuell nutze ich "nur" CSS 2.1;)

Wie, es gibt noch Webdesigner, die ohne opacity auskommen? Kaum zu glauben ... ;-)

Mhm, jetzt wird die Diskussion heterogener;) Vielen Dank!

Ach, hier im Forum findest Du für fast jede Abartigkeit Pros und Contras ... >;->

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

So manche der hiesigen Hardcore-XHTML-Fans ("unbedingt XHTML", "XHTML ist die Zukunft", blabla ...) sind nur arg gefrustet, daß man ihnen ihr schönes Spielzeug auf den Schrotthaufen der Geschichte entsorgt hat. >:->

Dass man auch HTML 5 in XML schreiben können wird, sollte dir nicht entgangen sein.

Aber vielleicht molilys Artikel XHTML wird zu Grabe getragen? Zur Lektüre empfohlen.

Qapla'

[Cybaer]

Hi,

Dass man auch HTML 5 in XML schreiben können wird, sollte dir nicht entgangen sein.

Natürlich nicht. Aber man nennt es dann immer noch HTML5 - nur eben XML notiert.
Auch für den, der das nicht weiß, sollte sich aus dem Zusammenhang erschließen, was ich hier mit "XHTML" meine ...

... oder hat hier jemand damit Verständnisprobleme?

Aber vielleicht molilys Artikel XHTML wird zu Grabe getragen?

Nein, auch der ist mir nicht entgangen ...

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Aber man nennt es dann immer noch HTML5 - nur eben XML notiert.

?? Man nennt es dann XHTML 5.

Qapla'

[Cybaer]

Hi,

Aber man nennt es dann immer noch HTML5 - nur eben XML notiert.
?? Man nennt es dann XHTML 5.

Nicht daß ich wüßte.

Der Name wurde doch vor kurzem erst offiziell festgelegt: Nicht "HTML 5", nicht "(X)HTML 5" nicht "XHTML 5" sondern eben "HTML5" - ohne X und ohne Leerzeichen.

Davon abgesehen wird es wohl noch sehr lange dauern, bis HTML5 in XML Notifikation praxisrelevant sein wird*) - wohl deutlich länger als HTML5. Jedenfalls bei statischen Dokumenten - bei CMS', die irgendein Content-Source-Format on-the-fly wahlweise in HTML- oder XML-Schreibweise transformieren mag das anders aussehen ...

*) Da HTML5 in XML-Notifikation ja nicht wie bei XHTML möglich wahlweise auch als text/html gesendet werden darf. Und da alle aktuellen IEs kein XHTML können, und die sicherlich noch länger unterstützt werden müssen ...

Gruß, Cybaer

[Tim Tepaße]

Der Name wurde doch vor kurzem erst offiziell festgelegt: Nicht "HTML 5", nicht "(X)HTML 5" nicht "XHTML 5" sondern eben "HTML5" - ohne X und ohne Leerzeichen.

“This specification defines version 5 of the XHTML syntax, known as "XHTML5".”

*) Da HTML5 in XML-Notifikation ja nicht wie bei XHTML möglich wahlweise auch als text/html gesendet werden darf.

Dennoch erlaubt die HTML5-Serialisierung xmlns-Attribute mit bekannten Namensräumen und selbstschließende Start-Tags – d.h sie erlauben eine Syntax, die sehr nahe an Anhang-C-XHTML ist. Tatsächlich besteht in den HTML WG und drumrum ziemliches Interesse ans polyglotten Dokumenten, weitere Änderungen sind wohl zu erwarten bzw. sind teilweise schon in validator.nu enthalten.

[Cybaer]

Hi,

“This specification defines version 5 of the XHTML syntax, known as "XHTML5".”

Heißt das "known as" das, was es übersetzt wirklich heißt: "bekannt als", oder heißt das "known as" eher "named as"?

Ersteres ist informell, letzteres offiziell.

Da sehe ich einen ziemlichen Unterschied.

Dennoch erlaubt die HTML5-Serialisierung xmlns-Attribute mit bekannten Namensräumen und selbstschließende Start-Tags – d.h sie erlauben eine Syntax, die sehr nahe an Anhang-C-XHTML ist.

Das macht aus HTML-Code noch lange kein wohlgeformtes XML-Dokument.

Tatsächlich besteht in den HTML WG und drumrum ziemliches Interesse ans polyglotten Dokumenten, weitere Änderungen sind wohl zu erwarten bzw. sind teilweise schon in validator.nu enthalten.

ACK

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Hi,

“This specification defines version 5 of the XHTML syntax, known as "XHTML5".”

Heißt das "known as" das, was es übersetzt wirklich heißt: "bekannt als", oder heißt das "known as" eher "named as"?

Da HTML 5 noch in der Entwicklung ist, kann es kaum „(schon) bekannt als“ heißen.

Es sollte sich aus dem Zusammenhang erschließen, was hier mit "XHTML" gemeint ist ...

... oder hat hier jemand damit Verständnisprobleme?

Qapla'

[ThomasM]

Hallo Guy Gaz,

Nun frage ich mich, ob der Einsatz von HTML5 bereits sinnvoll ist, oder ich lieber (noch) auf XHTML setzen soll. Was ist Eure Meinung dazu?

Wie schon gesagt, sind die wirklich attraktiven Techniken wie u. a. die neuen Formulartypen praktisch nicht nutzbar (außer in Opera geht sonst wenig, Safari zeigt gerade mal einen Slider bei type="range").

Bei den Strukturelementen ist auch noch viel im Fluss. So soll section nicht mehr als generischer Container zwischen header und footer stehen, sondern zur Strukturierung im Dokumentkontext dienen (also eher unterhalb von article). Insofern bleibt weiterhin <div id="content">...</div> das Mittel der Wahl.

Ansonsten kann man die bisherigen (X)HTML-Dokumenttypdeklarationen ersetzen durch <!DOCTYPE html> bzw. <!DOCTYPE html SYSTEM "about:legacy-compat"> (wenn die Ausgabe mit XSLT erzeugt wird). Wird dann noch auf nicht mehr unterstützte Elemente wie acronym, applet usw. verzichtet, dann gibt sogar der W3C-Validator grünes Licht (siehe etwa ZEIT ONLINE). Ob das etwas bringt, wage ich zu bezweifeln.

Mein Tipp: Beobachten, Experimentieren, Testen und dann irgendwann vielleicht mal produktiv einsetzen. Die ersten "richtigen" Anwendungen werden vermutlich auf mobilen Plattformen laufen, denn vor allem dafür ist HTML 5 konzipiert (neue JS-APIs wie GeoLocation, LocalStorage, Erweiterung von menu-Techniken für UI-Bau: <menu type="toolbar">...</menu>, canvas, progress, ...).

Grüße,
Thomas

[Guy Gaz]

Hallo Thomas!

Mein Tipp: Beobachten, Experimentieren, Testen und dann irgendwann vielleicht mal produktiv einsetzen. Die ersten "richtigen" Anwendungen werden vermutlich auf mobilen Plattformen laufen, denn vor allem dafür ist HTML 5 konzipiert (neue JS-APIs wie GeoLocation, LocalStorage, Erweiterung von menu-Techniken für UI-Bau: <menu type="toolbar">...</menu>, canvas, progress, ...).

Das werde ich tun, danke Dir! Cooles Forum hier - schnelle nette und kompetente Antworten, super!

[Cybaer]

Hi,

Nun frage ich mich, ob der Einsatz von HTML5 bereits sinnvoll ist, oder ich lieber (noch) auf XHTML setzen soll. Was ist Eure Meinung dazu?

HTML ist generell auf- und abwärtskompatibel (das war eines der Probleme des inkompatiblen XHTML 1.1ff., das auch deswegen quasi entsorgt wurde)! Es spricht rein gar nichts dagegen, Features jetzt zu nutzen, die noch von keinem Browser, bzw. die in Teilen von einigen Browsern interpretiert werden.

Das galt bislang noch für jede HTML-Version - HTML5 ist da keine Ausnahme.

Gruß, Cybaer

[Guy Gaz]

Hallo Cybaer!

Nun frage ich mich, ob der Einsatz von HTML5 bereits sinnvoll ist, oder ich lieber (noch) auf XHTML setzen soll. Was ist Eure Meinung dazu?

HTML ist generell auf- und abwärtskompatibel (das war eines der Probleme des inkompatiblen XHTML 1.1ff., das auch deswegen quasi entsorgt wurde)! Es spricht rein gar nichts dagegen, Features jetzt zu nutzen, die noch von keinem Browser, bzw. die in Teilen von einigen Browsern interpretiert werden.

Ok, ich werde wohl etwas tiefer in diese Materie einsteigen müssen, um mir ein eigenes Urteil bilden zu können.

Das galt bislang noch für jede HTML-Version - HTML5 ist da keine Ausnahme.

Nun habe ich etwas mehr Futter zum grübeln - vielen Dank für diesen Input!

[Cybaer]

Hi,

Ok, ich werde wohl etwas tiefer in diese Materie einsteigen müssen, um mir ein eigenes Urteil bilden zu können.

Grundlage einer jeden HTML-Version: Unbekannte Tags und Attribute sind (vom UA) zu ignorieren.

Läßt sich in den HTML-Dokus seit je her nachlesen ...

Gruß, Cybaer

[Guy Gaz]

Hallo!

Ok, ich werde wohl etwas tiefer in diese Materie einsteigen müssen, um mir ein eigenes Urteil bilden zu können.

Grundlage einer jeden HTML-Version: Unbekannte Tags und Attribute sind (vom UA) zu ignorieren.

Ja das ist schon klar - fragt sich nur ob der Einsatz dann sinnvoll ist.

[Cybaer]

Hi,

Grundlage einer jeden HTML-Version: Unbekannte Tags und Attribute sind (vom UA) zu ignorieren.
Ja das ist schon klar - fragt sich nur ob der Einsatz dann sinnvoll ist.

Das kommt wohl auf das Element an.

Ich habe z.B. Fließtext bereits im Blocksatz formatiert, als es noch kein Browser unterstützt hat. Oder opacity verwendet, obwohl es (immer noch) nicht alle unterstützen. Oder auch CANVAS, dem ich eine große Zukunft prognostiziere (das wird ja aktuell sogar schon ziemlich gut unterstützt - per zusätzlichem JS sogar im IE). Und auch die Multimedia-Elemente werden vermutlich sehr früh und reichlich Verbreitung finden. Usw. usf. ...

Gruß, Cybaer

[Gunther]

Hi,

Nun frage ich mich, ob der Einsatz von HTML5 bereits sinnvoll ist, oder ich lieber (noch) auf XHTML setzen soll. Was ist Eure Meinung dazu?

HTML ist generell auf- und abwärtskompatibel (das war eines der Probleme des inkompatiblen XHTML 1.1ff., das auch deswegen quasi entsorgt wurde)!

und ist eines der Probleme von HTML5. ;-)

Es spricht rein gar nichts dagegen, Features jetzt zu nutzen, die noch von keinem Browser, bzw. die in Teilen von einigen Browsern interpretiert werden.

Imho schon! Denn HTML5 erlaubt Dinge[1], die in früheren Versionen nicht erlaubt sind. Das führt zu invalidem Code, und wie wir ja alle wissen, ist das Verhalten von Browsern in solchen Fällen "unbestimmt".
Hinzukommt, dass man ggf. für diverse Dinge einen "Fallback" für inkompatible Browser einbauen muss => Mehraufwand.
Ferner ist HTML5 immer noch im "Entwurf-Stadium". Es können sich also noch täglich Dinge ändern. Keine sehr stabile Grundlage, um eine valide Seite zu bauen.

Das galt bislang noch für jede HTML-Version - HTML5 ist da keine Ausnahme.

Imho nicht ganz richtig (s.o.).

Gruß Gunther

[1] siehe http://www.w3.org/TR/2009/WD-html5-diff-20090825/#changed-elements

[Cybaer]

Hi,

Imho schon! Denn HTML5 erlaubt Dinge[1], die in früheren Versionen nicht erlaubt sind. Das führt zu invalidem Code, und wie wir ja alle wissen, ist das Verhalten von Browsern in solchen Fällen "unbestimmt".

So ein Blödsinn.

Das wissen nicht "alle", sondern nur die, die es offensichtlich nicht besser wissen.

Und BTW: "Validität" war noch nie Selbstzweck, ist es nicht und wird es auch zukünftig nicht sein.

Aber manche tragen das anscheinend immer noch wie eine Monstranz vor sich her.

Gratulation!

Das galt bislang noch für jede HTML-Version - HTML5 ist da keine Ausnahme.
Imho nicht ganz richtig (s.o.).

Ja, IYHO ...

Gruß, Cybaer

[ChrisB]

Hi,

HTML ist generell auf- und abwärtskompatibel (das war eines der Probleme des inkompatiblen XHTML 1.1ff., das auch deswegen quasi entsorgt wurde)! Es spricht rein gar nichts dagegen, Features jetzt zu nutzen, die noch von keinem Browser, bzw. die in Teilen von einigen Browsern interpretiert werden.

Das galt bislang noch für jede HTML-Version - HTML5 ist da keine Ausnahme.

Soweit die Theorie.

In der Praxis musst du dich dann bspw. damit herumschlagen, wie die Browser ihnen unbekannte Elemente ins DOM übernehmen.

MfG ChrisB

[Cybaer]

Hi,

In der Praxis musst du dich dann bspw. damit herumschlagen, wie die Browser ihnen unbekannte Elemente ins DOM übernehmen.

Ich weiß´zwar nicht, was der Einwand mit HTML zu tun hat (ist ja wohl eher eine Sache von JS), aber auch dir sollte eigentlich bekannt sein, daß a) alle Browser, bis auf den IE - der schafft das nur bei unbekannten Attributen, auch unbekannte Elemente ins DOM übernehmen (alternativ freue ich mich auf ein Gegenbeispiel), dies b) mit HTML5 nun auch verpflichtend ist, und c) selbst der IE keine Probleme hat, wenn man die Elemente erst mit JS einhängt.

Ich sehe jetzt also nicht, wo man sich mit irgendwas herumschlagen muß. Ich persönlich hätte sogar damit gut leben können, wenn Elemente oder Attribute, die der Browser nicht kennt, auch nicht im DOM auftauchen.

Ich arbeite seit ich HTML code mit vereinzelt unbekannten Elementen und Attributen, und sehe nicht, wo das, selbst ohne DOM, zu Problemen führt.

Das Verhalten ist dokumentiert, und damit gut ...

Gruß, Cybaer

[ChrisB]

Hi,

Ich weiß´zwar nicht, was der Einwand mit HTML zu tun hat (ist ja wohl eher eine Sache von JS), aber auch dir sollte eigentlich bekannt sein, daß a) alle Browser, bis auf den IE - der schafft das nur bei unbekannten Attributen, auch unbekannte Elemente ins DOM übernehmen (alternativ freue ich mich auf ein Gegenbeispiel),

Der IE macht auch in Version 8 AFAIK aus sowas

<section class="alpha">  
	<h2>Alpha</h2>  
	<p>  
		Sektion Alpha  
	</p>  
</section>

immer noch intern folgendem entsprechendes DOM:

[code=lang=html]<section class="alpha"></section>
<h2>Alpha</h2>
<p>
Sektion Alpha
</p>
</section><//section>[/code]

(Quelle: http://www.peterkroener.de/html5-was-geht-heute-schon-was-geht-nicht-der-grosse-ueberblick/)

Das macht vernünftiges Arbeiten darauf mit CSS komplizierter.

dies b) mit HTML5 nun auch verpflichtend ist,

Was genau nochmal?

und c) selbst der IE keine Probleme hat, wenn man die Elemente erst mit JS einhängt.

Ja, *wenn* die Möglichkeit besteht.

Ich sehe jetzt also nicht, wo man sich mit irgendwas herumschlagen muß. Ich persönlich hätte sogar damit gut leben können, wenn Elemente oder Attribute, die der Browser nicht kennt, auch nicht im DOM auftauchen.

Wenn's wenigstens so wäre - aber die Praxis widerspricht dem, was du gerade noch als Grundlage einer jeden HTML-Version bezeichnet hast, s.o.

Ich arbeite seit ich HTML code mit vereinzelt unbekannten Elementen und Attributen, und sehe nicht, wo das, selbst ohne DOM, zu Problemen führt.

Ich sage nur, dass es zu Extraaufwand führen kann.

MfG ChrisB

[Cybaer]

Hi,

Das macht vernünftiges Arbeiten darauf mit CSS komplizierter.

Hosianna, wenn das das einzige, oder wenigstens das gravierendste CSS-Problem der IEs wäre. =;->

dies b) mit HTML5 nun auch verpflichtend ist,
Was genau nochmal?

HTML5 in XML-Notifikation muß auch zwingend als XML/XHTML ausgeliefert werden. Das kann kein IE verarbeiten. Die bisherige Unart, XHTML als (invalides) HTML auszuliefern, ist bei HTML5 halt nicht erlaubt.

Wenn's wenigstens so wäre - aber die Praxis widerspricht dem, was du gerade noch als Grundlage einer jeden HTML-Version bezeichnet hast, s.o.

Es ist dennoch die Grundlage jeder HTML-Version. Wir wollen uns jetzt aber nicht über Fehler der IEs streiten, oder?

Ich arbeite seit ich HTML code mit vereinzelt unbekannten Elementen und Attributen, und sehe nicht, wo das, selbst ohne DOM, zu Problemen führt.
Ich sage nur, dass es zu Extraaufwand führen kann.

Das wäre bei den IEs allerdings auch nichts neues ... >;->

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Die bisherige Unart, XHTML als (invalides) HTML auszuliefern,

Auch ständige Wiederholung macht dieses Geschwafel von dir nicht sinnvoller.

An HTML-kompatiblem XHTML 1.0 ist nichts Unartiges dran – im Gegenteil: es vereint die autorenseitigen Vorteile von XML mit den browserseitigen Vorteilen der Auslieferung als 'text/html'.

Willst du die einen oder anderen Vorteile nochmals aufgelistet haben oder liest du sie bei Bedarf selbst nach?

Qapla'

[Guy Gaz]

Hallo!

Die bisherige Unart, XHTML als (invalides) HTML auszuliefern,

Auch ständige Wiederholung macht dieses Geschwafel von dir nicht sinnvoller.

Also ich hatte nun wirklich nicht die Absicht, mit meiner Frage hier Grabenkämpfe zu entfachen!

Ich halte mal als Halbzeitergebnis für mich fest, dass die Frage ob HTML5 bereits heute zu verwenden sei bzw. eine Verwendung empfohlen werden könne auch bei den Experten nicht abschließend geklärt ist.
Die Diskussion erinnert ein wenig an "Amiga vs. Atari ST" oder später "PC vs. Mac" - es gibt Argumente Pro und Contra HTML5 zum jetzigen Zeitpunkt und aktuell scheint es mir so auszugehen, dass ich vorerst bei XHTML bleibe und
weiterhin ein Auge auf HTML5 werfe - späteres Verlieben und Heirat nicht ausgeschlossen.

G'peace please!'G

[Cybaer]

Hi,

Also ich hatte nun wirklich nicht die Absicht, mit meiner Frage hier Grabenkämpfe zu entfachen!

keine Sorge, das geht hier gantz automatisch. :->

vorerst bei XHTML bleibe

Dann achte aber bitte darauf, daß die Seite auch dann noch funktioniert, wenn sie wirklich als XHTML ausgeliefert wird (üblicherweise werden die Seiten ja trotzdem nur als HTML ausgeliefert). Nur mit "ist valide, dann wird es auch funktionieren", ist es nämlich nicht getan ...

weiterhin ein Auge auf HTML5 werfe - späteres Verlieben und Heirat nicht ausgeschlossen.

Die Zeit ist, logischerweise, auf der Seite von HTML5. Deswegen kann auch der leidenschaftlichste HTML5-Fan ganz gelassen bleiben ... ;-)

Gruß, Cybaer

[Guy Gaz]

Hallo Cybaer!

Also ich hatte nun wirklich nicht die Absicht, mit meiner Frage hier Grabenkämpfe zu entfachen!

keine Sorge, das geht hier gantz automatisch. :->

Naja, der Umgangston ist wohl manchmal rau - ist ja auch kein Kindergebzrtstag hier;)

vorerst bei XHTML bleibe

Dann achte aber bitte darauf, daß die Seite auch dann noch funktioniert, wenn sie wirklich als XHTML ausgeliefert wird (üblicherweise werden die Seiten ja trotzdem nur als HTML ausgeliefert). Nur mit "ist valide, dann wird es auch funktionieren", ist es nämlich nicht getan ...

Kannst Du mir dazu bitte noch ein Stichwort geben was genau Du meinst? Validität (warum sagt eigentlich im Deutschen niemand "gültig", sondern alle immer "valide" - klingt schrecklich) setze ich voraus, aber was kann ich sonst noch tun, wann/wo/wie sollen meine Dokumente als XHTML "funktionieren"?

weiterhin ein Auge auf HTML5 werfe - späteres Verlieben und Heirat nicht ausgeschlossen.

Die Zeit ist, logischerweise, auf der Seite von HTML5. Deswegen kann auch der leidenschaftlichste HTML5-Fan ganz gelassen bleiben ... ;-)

Mhm, gelassen bin ich schon, es geht nur um ein privates Webprojekt.

Danke an alle soweit - die Anregungen und Tipps haben mir sehr geholfen!

[Cybaer]

Hi,

Naja, der Umgangston ist wohl manchmal rau - ist ja auch kein Kindergebzrtstag hier;)

Eher Kleinkindergeburtstag! ;)

Kannst Du mir dazu bitte noch ein Stichwort geben was genau Du meinst?

Google mal nach: Unterschiede HTML XHTML

(gerne auch in Englisch. ;-)

Validität (warum sagt eigentlich im Deutschen niemand "gültig", sondern alle immer "valide" - klingt schrecklich)

Na ja, ist halt ein Fachbegriff. "Valide" ist eindeutig: Gültigkeit zu bestimmten Regeln (also vor HTML5: zur DTD). "Gültig" ist IMHO mißverständlicher. "Gültig" im Sinne von "fehlerlos verarbeitbar" ist auch bereits ein nur wohlgeformtes XHTML-Dokument.

aber was kann ich sonst noch tun, wann/wo/wie sollen meine Dokumente als XHTML "funktionieren"?

Ändere einfach mal die Dateiendung auf .xhtml. Der Apache ist per Default darauf eingestellt, das Dokument dann wirklich als XHTML auszuliefern.

Das sollte dann auch, sofern der Browser das unterstützt (der IE kann es ja immer noch nicht) fehlerfrei funktionieren.

Fallstricke gibt es einige, aber das läßt sich alles im Netz nachlesen, da auch hier im Forum bereits hinreichend thematisiert ...

Gruß, Cybaer

[Cybaer]

Hi,

Auch ständige Wiederholung macht dieses Geschwafel von dir nicht sinnvoller.

Sinnvoller als dein Geschwafel ist es gottseidank noch allmal ...

... OK, ist auch nicht schwer. :->

An HTML-kompatiblem XHTML 1.0 ist nichts Unartiges dran – im Gegenteil: es vereint die autorenseitigen Vorteile von XML mit den browserseitigen Vorteilen der Auslieferung als 'text/html'.

Ja, abertausende in XHTML codierte Seiten (darunter auch von sog. XHTML-Gurus), die nicht funktionieren würden, wenn man sie wirklich als XHTML ausliefern würde, sprechen in der Tat eine deutliche Sprache.

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Sinnvoller als dein Geschwafel ist es gottseidank noch allmal ...

Kommen zur Abwechslung mal Argumente von dir? Nein? Warum überrascht mich das jetzt nicht?

Ja, abertausende in XHTML codierte Seiten (darunter auch von sog. XHTML-Gurus), die nicht funktionieren würden, wenn man sie wirklich als XHTML ausliefern würde, sprechen in der Tat eine deutliche Sprache.

Warum sollte man denn auch XHTML-Dokumente, die gar nicht dafür gedacht sind, als XML ausgeliefert zu werden, als XML ausliefern?

Ja, die Dokumente sprechen eine deutliche Sprache. Du verstehst sie nur nicht.

Qapla'

[Cybaer]

Hi,

Kommen zur Abwechslung mal Argumente von dir?

Nein. Wir haben dies Thema (und andere auch) hier schon so oft durchdiskutiert, und ich kann mich nicht erinnern, daß Du jemals Argumenten offen gegenüber gewesen wärst. Das wäre reine Zeitverschwendung, genauso wie generell das Nachtrauern um XHTML 1.x/2 ...

... einzig die Lust, dir verbal eine mitzugeben, erhebt Threads mit dir auf ein sinnvolles Niveau: das des Amüsements. :-)

Warum sollte man denn auch XHTML-Dokumente, die gar nicht dafür gedacht sind, als XML ausgeliefert zu werden, als XML ausliefern?

Hast Recht. Die Möglichkeit, XHTML-Dokumente als HTML auszuliefern, war ja stets das Ziel des W3Cs. Daß das nur den Übergang zu wirklichem XHTML darstellen sollte, kann man getrost vergessen ...

... wie man ja mittlerweile XHTML 1.1 ff. auch vergessen kann. :->

R.I.P.

Ja, die Dokumente sprechen eine deutliche Sprache. Du verstehst sie nur nicht.

Oh, *viele*, inkl. dem Google-Verantwortlichen Ian Hickson, sprechen eine deutliche Sprache. Aber was wissen die schon, das sind ja Newbies und die lesen ja nicht die erlauchten Ergüssen unseres Starexperten Gunnar ... =:->

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Oh, *viele*, inkl. dem Google-Verantwortlichen Ian Hickson, sprechen eine deutliche Sprache.

ROTFL. Wieder einmal diesen „sehr bekannte Artikel“.

Dass dieser „jedoch hauptsächlich dadurch besticht, dass er vor allem einseitig und irreführend ist“ [Jendryschik], haben wir hier ja wohl oft genug durchgekaut.

Aber vermutlich tust du [Jendryschik] und [Schneegans] auch als „erlauchten Ergüsse“ von „Starexperten“ ab.

Qapla'

[Edgar Ehritt]

Hallo,

Oh, *viele*, inkl. dem Google-Verantwortlichen Ian Hickson, sprechen eine deutliche Sprache.

ROTFL. Wieder einmal diesen „sehr bekannte Artikel“.

Dass dieser „jedoch hauptsächlich dadurch besticht, dass er vor allem einseitig und irreführend ist“ [Jendryschik], haben wir hier ja wohl oft genug durchgekaut.

Wer ist Jendryschik? Programmiert der Browser oder Crawler? Ist der vom W3C?

Aber vermutlich tust du [Jendryschik] und [Schneegans] auch als „erlauchten Ergüsse“ von „Starexperten“ ab.

Gunnar, das sind ebenso keine Argumente. Nur weil irgendwer in sein Weblog sich auskotzt oder die Menschheit mit seinen buchgewordenen Ergüssen gegen Geld belehrt, ist das genauso triftig, als würde ich mir untern Arm fassen.

Das W3C hat eine Information zu den verwendeten Mediatypen herausgegeben. Im Standard zu XHML 1.0 wird darauf verwiesen. Im Standard zu XHTML 1.1 wird nicht darauf verwiesen, jedoch wird auf den Mediatypen gar nicht eingegangen (GOOGLE site:http://www.w3.org/TR/xhtml11/ 3236, wobei RFC 3236 die Spezifikation des Mediatyps application/xhtml+xml ist), zu meinem Erstaunen trifft auch XHTML 2.0 zum Mediatypen keine Definitionen. Da letztere eh nicht offizielle Empfehlung des W3C ist, ist das aber eh egal.

Aus der o. g. Information geht für Programmierer klar der Prior text/html hervor.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Wer ist Jendryschik? Programmiert der Browser oder Crawler? Ist der vom W3C?

Was hat das damit zu tun, dass dieser „sehr bekannte Artikel“ von Ian Hickson kaum mehr als eine Ansammlung von Unsinn ist?

Hickson hat sicher seine Kompetenzen. Nur ist ebendieser Artikel gerade nicht geeignet, diese zu zeigen. Da hat Cybaer ins Klo gegriffen.

Gunnar, das sind ebenso keine Argumente.

Es war gar nicht meine Absicht, Hicksons Artikel speziell für Cybaer nochmals zu zerpflücken. Das hat Christoph Schneegans unter „Unsinnige Argumente gegen XHTML“ schon getan. [Schneegans] Auch von molily dürfte dazu einiges im Archiv zu finden sein.

Das W3C hat eine Information zu den verwendeten Mediatypen herausgegeben. Im Standard zu XHML 1.0 wird darauf verwiesen. Im Standard zu XHTML 1.1 wird nicht darauf verwiesen, jedoch wird auf den Mediatypen gar nicht eingegangen

Hm, im WD vom 2007-02-16 [XHTML11:20070216 §2.1.1] wird. S.a. http://forum.de.selfhtml.org/archiv/2008/6/t172648/#m1131743 ff.

Allerdings verweist http://www.w3.org/TR/xhtml11/ inzwischen wieder auf die REC vom 2001-05-31. Der WD vom 2007-02-16 ist damit kaum noch auffindbar, also bedeutungslos?

Aus der o. g. Information geht für Programmierer klar der Prior text/html hervor.

Ich war es nicht, der Probleme mit XHTML als 'text/html' hat.

„Für Programmierer“??

Qapla'

[Edgar Ehritt]

Re:

Wer ist Jendryschik? Programmiert der Browser oder Crawler? Ist der vom W3C?
Was hat das damit zu tun, dass dieser „sehr bekannte Artikel“ von Ian Hickson kaum mehr als eine Ansammlung von Unsinn ist?

Nichts; muss es auch nicht. Mich störte Deine Argumentlosigkeit.

Hickson hat sicher seine Kompetenzen. Nur ist ebendieser Artikel gerade nicht geeignet, diese zu zeigen. Da hat Cybaer ins Klo gegriffen.

Dann winkt man eben mit einem Argument und nicht mit jemand unbekannten, dessen Kompetenz fraglich ist.

Gunnar, das sind ebenso keine Argumente.

Es war gar nicht meine Absicht, Hicksons Artikel speziell für Cybaer nochmals zu zerpflücken.

Ja, das ist das Traurige daran. Deswegen schrieb ich auch Dir und nicht ihm.

Ich war es nicht, der Probleme mit XHTML als 'text/html' hat.
„Für Programmierer“??

Programmiert der Browser oder Crawler?

Gruß aus Berlin!
eddi

[Korrektur]

HTML5 in XML-Notifikation muß auch zwingend als XML/XHTML ausgeliefert werden. Die bisherige Unart, XHTML als (invalides) HTML auszuliefern, ist bei HTML5 halt nicht erlaubt.

Richtig ist: XHTML 5 definiert sich über den MIME-Typen und damit über die Verarbeitung als XML. Alles andere ist per definitionem kein XHTML 5.

Allerdings: Die HTML-5-Serialisierung ist durch liberale Parsing-Regeln offen für eine XML-konforme Syntax. HTML 5 in XML-Schreibweise ist möglich und muss nicht als XML ausgeliefert werden. Es bedarf ferner keiner großen Änderungen, um bisheriges XHTML 1.0 als valides HTML 5 auszuliefern, ohne dass die Fähigkeit zur XML-Verarbeitung verloren geht.

HTML-5-Dokumente, die als HTML 5 und gleichzeitig als XML verarbeitet werden können, werden "polyglotte" Dokumente genannt.

[Tim Tepaße]

HTML-5-Dokumente, die als HTML 5 und gleichzeitig als XML verarbeitet werden können, werden "polyglotte" Dokumente genannt.

Hm. Mathias?

[Cybaer]

Hi,

Richtig ist: XHTML 5 definiert sich über den MIME-Typen

Ach, gibt es Resourcen im Web, die sich nicht über den MIME-Typ definieren?

und damit über die Verarbeitung als XML. Alles andere ist per definitionem kein XHTML 5.

Genau. Anders als bei XHTML.

Allerdings: Die HTML-5-Serialisierung ist durch liberale Parsing-Regeln offen für eine XML-konforme Syntax.

Jo, und das bisherige liberale HTML-Parsing ermöglicht es überhaupt, in XHTML 1.0 notierte Dokumente als HTML zu nutzen.

HTML-5-Dokumente, die als HTML 5 und gleichzeitig als XML verarbeitet werden können, werden "polyglotte" Dokumente genannt.

Eher "polymorph pervers"! ;-)

Gruß, Cybaer

[jobo]

Hallo,

http://forum.de.selfhtml.org/archiv/2009/9/t191067/#m1273918

Gruß

jobo