nicht angemeldet
HTML5 heute?
0 0 
Gunnar Bittersmann
0 Gunnar Bittersmann
0 0
1
HTML5 heute?
Hi,
wie seht ihr jetzt eigentlich konkret die Verwendungsmöglichkeit von HTML5.
Einziges Sorgenkind soweit ich das sehe ist hier eigentlich der IE<=8, da er die ganzen neuen Tags gleich wieder schließt.
Workarounds gibts ja genug:
Mit Javascript die dem IE unbekannten Elemente erst erzeugen damit er etwas mehr damit anfangen kann:
document.createElement("article");
-->
<article>foo</article>
Hier geht man davon aus das JS aktiviert ist, unschön.
Conditional Comments in der Art:
<!--[if lte IE 8]><div class="article"><![endif]-->
<!--[if gt IE 8]><!--><article class="article"><!--<![endif]-->
foo
<!--[if lte IE 8]></div><![endif]-->
<!--[if gt IE 8]><!--></article><!--<![endif]-->
Styling dann eben über .article anstelle von article.
Sehe dabei kein Problem die Funktionalität betreffend, nur ist es sehr unübersichtlich.
Über zusätzlichen xmlns:
Hier hab ich erst ein Verständnisproblem. Warum wird als Namespace http://www.w3.org/1999/xhtml angegeben? Erstens bekomme ich da keine .xsd oder .dtd wie ich erwartet hätte und zweitens hört sich diese Definition nach xhtml und nicht nach html5 an?
So wie ich das sehe funktioniert das sowieso nur weil sich der IE nicht darum schert was da angegeben ist?
Auf jeden Fall gibt es auch bei dieser "Lösung" Probleme, wie mir erst durch Molilys Post bewusst wurde.
Kurze Zusammenfassung:
- das Namespace-Präfix müsste immer mitgezogen werden (
document.getElementsByTagName("präfix:section")) - es ist kein HTML5, sonder XHTML -> eigentlich Semantik der HTML5-Tags geht verloren. (Wenn ich das oben erwähnte richtig verstehe besteht dieses Problem nur weil man als Namespace den XHTML-Namespace angibt?)
- keine Javascript-API bei Elementen die ohne Präfix eine hätten (video, audio...)
Gibt es noch andere Möglichkeiten HTML5 im IE zu ermöglichen?
Würdet ihr mit Hilfe einer der genannten Möglichkeiten in Erwägung ziehen HTML5 bei einem Projekt einzusetzen?
Falls nicht müsste man auf HTML5 wohl verzichten bis der Support für WinXP ausläuft (IE9 erscheint afaik nur für WinVista+)?
~dave
-
Grüße dich, dave,
wie seht ihr jetzt eigentlich konkret die Verwendungsmöglichkeit von HTML5.
Es gibt ein paar wenige Dinge, die in HTML5 definiert werden und schon jetzt benutzt werden können, z.B. audio- und video-Elemente (wobei die dank des Codes-Streits eher einer Todgeburt gleichen), das canvas-Element (scheint sehr beliebt zu sein)...
Mehr fällt mir ehrlichgesagt nicht ein. Klar, es gibt einiges, dass man schon kennt und auch verwenden kann. Aber neue Elemente, Attribute und sontiges besitzen noch keine semantische Bedetung. Die gewinnt HTML5 erst wenn es halbwegs fertig wird.
Hier geht man davon aus das JS aktiviert ist, unschön.
Unschön ja, aber praktisch. Davon abgesehen besitzen diese Elemente aktuell noch keine semantische Bedeutung. Soweit ich weis, werden aber z.B. im Firefox 4 den Elementen bestimmte ARIA-Bedeutungen hinzugefügt. Wenn, dann also so.
Conditional Comments in der Art:
<!--[if lte IE 8]><div class="article"><![endif]-->
<!--[if gt IE 8]><!--><article class="article"><!--<![endif]-->
foo
<!--[if lte IE 8]></div><![endif]-->
<!--[if gt IE 8]><!--></article><!--<![endif]-->> > Styling dann eben über `.article`{:.language-css} anstelle von `article`{:.language-css}. Div-Suppe schmeckt eindeutig besser. > Über [zusätzlichen xmlns](http://forum.de.selfhtml.org/archiv/2010/12/t202408/): > Hier hab ich erst ein Verständnisproblem. Warum wird als Namespace http://www.w3.org/1999/xhtml angegeben? Erstens bekomme ich da keine .xsd oder .dtd wie ich erwartet hätte und zweitens hört sich diese Definition nach xhtml und nicht nach html5 an? > So wie ich das sehe funktioniert das sowieso nur weil sich der IE nicht darum schert was da angegeben ist? Hier wird ausgenutzt, dass der IE eine ganz eigene, völlig vermurkste Vorstellung von Namensräumen besitzt. Der XHTML-Namensraum wird angegeben, weil HTML-Elemente diesem angehören. Allerdings könnte der Namensraum auch kuddeldimuddel heißen. Es wäre das selbe Ergebnis. Der Namensraum hat keine Bedeutung in diesem Trick. Bei dem Code handelt es sich weder um HTML(5) noch um XHTML. Vorwärtskompatibel ist das leider auch nicht, die so erstellten Elemente sind keine HTML(5)-Elemente sondern generische, bedeutungslose Elemente. Was das Schreiben von HTML anbelangt ist HTML4 im Moment einfach noch die beste Wahl. > - es ist kein HTML5, sonder XHTML -> eigentlich Semantik der HTML5-Tags geht verloren. (Wenn ich das oben erwähnte richtig verstehe besteht dieses Problem nur weil man als Namespace den XHTML-Namespace angibt?) Es ist kein XHTML, es ist ein IE-Hack. XHTML definiert sich durch den Medientyp application/xhtml+xml, durch nichts anderes. Alles was nicht XHTML oder XML ist, ist HTML. HTML-Elemente verlieren beim Wechsel zwischen HTML und XHTML nicht ihre Bedeutung. > Gibt es noch andere Möglichkeiten HTML5 im IE zu ermöglichen? Der Parser im IE9 wurde etwas bearbeitet, so dass er die neuen Elemente nicht mehr schließt. Damit musst du vorerst glücklich werden. > Würdet ihr mit Hilfe einer der genannten Möglichkeiten in Erwägung ziehen HTML5 bei einem Projekt einzusetzen? Nein. HTML 4.01 (gefälligst Strict, aber mit stabilen Zusätzen wie etwa dem canvas-Element) ist die erste Wahl. Das empfehlen nebenbei auch HTML5-Enthusiasten wie Henri Sivonen[1]. Bei manchen HTML5-Elementen ist ja noch nichtmal klar, ob sie erhalten bleiben. > Falls nicht müsste man auf HTML5 wohl verzichten bis der Support für WinXP ausläuft (IE9 erscheint afaik nur für WinVista+)? Ja, die nächsten 3 bis 4 Jahre darfst du sicher noch warten. Bis dahin gibts auch die ersten Browser mit einem HTML-Parser wie er von HTML5 definiert wird (Firefox 4 und Safari 6 dürften das sein). Das wird eine Bewährungsprobe für HTML5: Es zeigt sich ob dadurch Schaden oder Nutzen entsteht. Faher bin ich schon darauf gespannt. gruß, Daniel [1] http://hsivonen.iki.fi/doctype/#choosing Inzwischen scheint er etwas von seiner Meinung abgeweicht zu sein.-
@@Daniel.S:
nuqneH
audio- und video-Elemente (wobei die dank des Codes-Streits eher einer Todgeburt gleichen)
Der Codex-Streit ist wohl auf dem Weg, gelöst zu werden.
Aber neue Elemente, Attribute und sontiges besitzen noch keine semantische Bedetung.
Hä? 'article', 'section', 'nav' etc. haben semantische Bedeutung. @autofocus, @autocomplete, @aria-*, @data-* auch.
Die gewinnt HTML5 erst wenn es halbwegs fertig wird.
Wieso sollte sich an der semantische Bedeutung von Elementen und Attributen etwas ändern, wenn HTML5 vom Stadium "in Entwicklung" in das Stadium "fertig" übergeht?
<!--[if lte IE 8]><div class="article"><![endif]-->
<!--[if gt IE 8]><!--><article class="article"><!--<![endif]-->
foo
<!--[if lte IE 8]></div><![endif]-->
<!--[if gt IE 8]><!--></article><!--<![endif]-->> > Div-Suppe schmeckt eindeutig besser. Das ist wohl der so ziemlich einzige Satz in deinem Posting, dem ich zustimmen kann. > Hier wird ausgenutzt, dass der IE eine ganz eigene, völlig vermurkste Vorstellung von Namensräumen besitzt. Falsch. IE kann kein XHTML als 'application/xhtml+xml' verarbeiten, deshalb bekommt er es als 'text/html' serviert. In Tagsoup gibt es ganz einfach keine Namensräume; `<foo:bar/>`{:.language-xml} ist kein Element vom Typ 'bar' aus dem per @xmlns:foo definierten Namensraum wie bei XML-Verarbeitung, sondern eben ein Element vom Typ 'foo:bar'. Deshalb ist es in CSS per Typselektor '`foo\:bar`{:.language-css}' ansprechbar. > Der XHTML-Namensraum wird angegeben, weil HTML-Elemente diesem angehören. Allerdings könnte der Namensraum auch kuddeldimuddel heißen. Falsch. Er muss 'http://www.w3.org/1999/xhtml' heißen. > Es wäre das selbe Ergebnis. Der Namensraum hat keine Bedeutung in diesem Trick. Falsch. Verarbeite mal ~~~xml <html xmlns="kuddeldimuddel"> <head><title>Test</title></head> <body><a href="http://example.net">Link</a></body> </html>als XML und nichts ist mit Link, weil das 'a'-Element nicht dem XHTML-Namensraum angehört. Anders hingegen bei
<html xmlns="kuddeldimuddel"> <head><title>Test</title></head> <body>[code lang=html]<a href="http://example.net" xmlns="http://www.w3.org/1999/xhtml">Link</a> ~~~</body> </html>[/code] > Bei dem Code handelt es sich weder um HTML(5) noch um XHTML. Falsch. Es ist sowohl als auch. Es ist XHTML5. > Vorwärtskompatibel ist das leider auch nicht, die so erstellten Elemente sind keine HTML(5)-Elemente sondern generische, bedeutungslose Elemente. Falsch. ~~~xml <foo:bar xmlns:foo="http://example.net/ns#"> <foo:baz/> </foo:bar>und
<bar xmlns="http://example.net/ns#" xmlns:foo="http://example.net/ns#"> <foo:baz/> </bar>und
<foo:bar xmlns="http://example.net/ns#" xmlns:foo="http://example.net/ns#"> <baz/> </foo:bar>und
<bar xmlns="http://example.net/ns#"> <baz/> </bar>sind völlig äquivalente XML-Dokumente.
<article/>und<foo:article/>sind bei Verarbeitung als 'application/xhtml+xml' völlig äquivalente XHTML5-Elemente, wenn dem Präfix 'foo' der Namensraum 'http://www.w3.org/1999/xhtml' zugeordnet wurde.Was das Schreiben von HTML anbelangt ist HTML4 im Moment einfach noch die beste Wahl.
Nö. Wenn schon, dann XHTML 1.
Wenn ich das oben erwähnte richtig verstehe
Sieht nicht danach aus.
XHTML definiert sich durch den Medientyp application/xhtml+xml, durch nichts anderes.
Falsch. Für XHTML5 ist das so gesagt. XHTML 1 kann durchaus als 'text/html' ausgeliefert werden.
Alles was nicht XHTML oder XML ist, ist HTML.
Also ich für meinen Teil bin nicht XHTML oder XML, aber deshalb noch lange kein HTML.
Im Übrigen lässt sich "XHTML oder XML" zu "XML" zusammenfassen, da XHTML in XML echt enthalten ist.
HTML 4.01 (gefälligst Strict, aber mit stabilen Zusätzen wie etwa dem canvas-Element) ist die erste Wahl.
Es gibt keine Zusätze in HTML 4.01 Strict. Tagsoup mit HTML-fremden Elementen ist kein HTML mehr.
Dass XHTML erste Wahl ist, sagte ich schon.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Grüße dich, Gunnar,
audio- und video-Elemente (wobei die dank des Codes-Streits eher einer Todgeburt gleichen)
Der Codex-Streit ist wohl auf dem Weg, gelöst zu werden.
Der Meinung bin ich nicht. Apple und Microsoft sträuben sich noch etwas.
Die alternative lautet meistens Flash, daher denke ich nicht, dass ein neuer Codec, den man erst herunterladen muss (MS), sich durchsetzen kann.Aber neue Elemente, Attribute und sontiges besitzen noch keine semantische Bedetung.
Hä? 'article', 'section', 'nav' etc. haben semantische Bedeutung. @autofocus, @autocomplete, @aria-*, @data-* auch.
Die gewinnt HTML5 erst wenn es halbwegs fertig wird.
Wieso sollte sich an der semantische Bedeutung von Elementen und Attributen etwas ändern, wenn HTML5 vom Stadium "in Entwicklung" in das Stadium "fertig" übergeht?
Selbstverständlich besitzen die neuen Elemente Semantik per Definition. Dennoch gibts es momentan noch keinen veröffentlichten Browser, in dem z.B. 'article' als Artikel-Element gesehen wird. Es hat die selbe Bedeutung wie ein foo-Element.
Das kann sich erst durch die richtige Implementierung ändern, die zwangsläufig zur Fertigstellung von HTML5 führt.
Hier wird ausgenutzt, dass der IE eine ganz eigene, völlig vermurkste Vorstellung von Namensräumen besitzt.
Falsch. IE kann kein XHTML als 'application/xhtml+xml' verarbeiten, deshalb bekommt er es als 'text/html' serviert. In Tagsoup gibt es ganz einfach keine Namensräume;
<foo:bar/>ist kein Element vom Typ 'bar' aus dem per @xmlns:foo definierten Namensraum wie bei XML-Verarbeitung, sondern eben ein Element vom Typ 'foo:bar'. Deshalb ist es in CSS per Typselektor 'foo\:bar' ansprechbar.Der IE kann auch innerhalb von text/html Namensräume verarbeiten. Das ist ein Feature, dass in IE 5 implementiert wurde (evtl auch schon vorher).
Der XHTML-Namensraum wird angegeben, weil HTML-Elemente diesem angehören. Allerdings könnte der Namensraum auch kuddeldimuddel heißen.
Falsch. Er muss 'http://www.w3.org/1999/xhtml' heißen.
Ich bin mir nicht sicher, ob du mich richtig verstanden hast. Durch das definieren eines belibigen Namensraums (für einen beliebigen Präfix), ist es möglich, Elemente 'normal' verarbeiten zu lassen. Siehe
<html xmlns:baz="kuddeldimuddel"> <body> <baz:section>Test</baz:section> </body> </html>Es wäre das selbe Ergebnis. Der Namensraum hat keine Bedeutung in diesem Trick.
Falsch. Verarbeite mal
<html xmlns="kuddeldimuddel">
<head><title>Test</title></head>
<body><a href="http://example.net">Link</a></body>
</html>> > als XML und nichts ist mit Link, weil das 'a'-Element nicht dem XHTML-Namensraum angehört. Anders hingegen bei > > ~~~xml <html xmlns="kuddeldimuddel"> > <head><title>Test</title></head> > <body>[code lang=html]<a href="http://example.net" xmlns="http://www.w3.org/1999/xhtml">Link</a> ~~~</body> > </html>[/code] Du darfst nicht von XML ausgehen. Der Trick um den es hier geht, ist eine Funktion, die der IE in HTML bereitstellt. Und gerade dort funktioniert der XHTML-Namensraum eben nicht um a-Elemente zu Verweisen zu machen. > > Bei dem Code handelt es sich weder um HTML(5) noch um XHTML. > > Falsch. Es ist sowohl als auch. Es ist XHTML5. In HTML ist es TagSoup, wie du sagen würdest. Dass das Verwenden des XHTML-Namensraums in hinsicht auf eine Verarbeitung als XML sinnvoll sein mag will ich nicht bestreiten. Du selbst sagst jedoch, dass namensräume in HTML keine Bedeutug haben. Selbst der IE, der diesen Mist implementiert hat kann nicht damit Umgehen. Deshalb sage ich, dass diese methode die denkbar schlechteste HTML5-Emulierung ist. Das Ergebnis ist das selbe wie mit dem createElement-Trick, nur wesentlich komplizierter. > > Vorwärtskompatibel ist das leider auch nicht, die so erstellten Elemente sind keine HTML(5)-Elemente sondern generische, bedeutungslose Elemente. > > Falsch. > > [...] > > sind völlig äquivalente XML-Dokumente. > > `<article/>`{:.language-html} und `<foo:article/>`{:.language-html} sind bei Verarbeitung als 'application/xhtml+xml' völlig äquivalente XHTML5-Elemente, wenn dem Präfix 'foo' der Namensraum 'http://www.w3.org/1999/xhtml' zugeordnet wurde. Das streite ich nicht ab. Ich habe in Bezug auf X(HT)ML ohnehin schon etwas zurückgerudert. Aber hier geht es nunmal nicht um XML. Der Versuch mit dem a-Element zeigt, dass es sich um generische HTML-Elemente handelt, nicht um definierte Elemente mit Bedeutung. > > Was das Schreiben von HTML anbelangt ist HTML4 im Moment einfach noch die beste Wahl. > > Nö. Wenn schon, dann XHTML 1. Meinetwegen auch das, macht ja keinen Unterschied. > > XHTML definiert sich durch den Medientyp application/xhtml+xml, durch nichts anderes. > > Falsch. Für XHTML5 ist das so gesagt. XHTML 1 kann durchaus als 'text/html' ausgeliefert werden. Auch XHTML 1.x definiert sich über 'application/xhtml+xml', man kann es nur zufälligerweise auch als 'text/html' ausliefern und verarbeiten lassen. Was das W3C auch erlaubt hat. > > Alles was nicht XHTML oder XML ist, ist HTML. > > Also ich für meinen Teil bin nicht XHTML oder XML, aber deshalb noch lange kein HTML. Entschuldige, von deinen Beiträgen her hätte ich wissen müssen, dass du eher CSS bist :) > Im Übrigen lässt sich "XHTML oder XML" zu "XML" zusammenfassen, da XHTML in XML echt enthalten ist. Das ist klar, mache ich auch oft, aber hin und wieder ist eine Abgrenzung ganz sinnvoll. Sagst du damit aber nicht aus, dass XML auch als 'text/html' ausgeliefert werden kann? > > HTML 4.01 (gefälligst Strict, aber mit stabilen Zusätzen wie etwa dem canvas-Element) ist die erste Wahl. > > Es gibt keine Zusätze in HTML 4.01 Strict. Tagsoup mit HTML-fremden Elementen ist kein HTML mehr. Es geht hier nicht darum, einem bestimmten Standard zu entsprechen. Es geht darum, ein vernünftiges Dokument zu schreiben, dass von allen wichtigen Browsern verarbeitet werden kann. HTML und XML erlauben nunmal TagSoup, dagegen kommen wir nicht mit Diskussion an. Aber mit Aufklärung von Autoren. Gruß, Daniel -
Hier wird ausgenutzt, dass der IE eine ganz eigene, völlig vermurkste Vorstellung von Namensräumen besitzt. Der XHTML-Namensraum wird angegeben, weil HTML-Elemente diesem angehören. Allerdings könnte der Namensraum auch kuddeldimuddel heißen. Es wäre das selbe Ergebnis. Der Namensraum hat keine Bedeutung in diesem Trick.
Falsch. Er muss 'http://www.w3.org/1999/xhtml' heißen.
Daniel hat hier über den IE und diesen Namespace-Hack gesprochen, mit dem man ihm angeblich HTML5 beibringen kann. Und er hat darin Recht. Der IE verarbeitet die Elemente nicht, weil sie im XHTML-Namespace liegen, sondern weil sie in irgendeinem anderen Namespace liegen. Sprich, damit der Hack funktioniert, könnte man auch folgendes schreiben:
<html xmlns:foo="foo"><body> <foo:section>...</foo:section> </body></html>Klar, wenn dieser Code als XHTML5 verarbeitet werden WÜRDE, wäre section kein Element aus dem HTML-Namensraum. Aber bei dem Hack geht es eben NICHT darum, korrektes oder gar sinnvolles XHTML5 zu schreiben. Und es geht auch nicht darum, korrektes HTML5 zu schreiben. Denn ein HTML5-Parser wird obiges section-Element ebenfalls nicht als HTML erkennen, die (hier falsche) Namensraum-Angabe spielt dabei bekanntlich keine Rolle.
Bei dem Code handelt es sich weder um HTML(5) noch um XHTML.
Falsch. Es ist sowohl als auch. Es ist XHTML5.
Es wäre XHTML5, wenn es in Browsern auch als solches verarbeitet werden würde.
Vorwärtskompatibel ist das leider auch nicht, die so erstellten Elemente sind keine HTML(5)-Elemente sondern generische, bedeutungslose Elemente.
Falsch.
Was er damit meinte, habe ich auch in https://forum.selfhtml.org/?t=202812&m=1370510 beschrieben.
(...) sind völlig äquivalente XML-Dokumente.
Das ist schön, aber wir reden hier von HTML5 als text/html. Da nützt es nichts, wenn das Dokument, wenn es als XHTML5 verarbeitet werden WÜRDE, Markup aus dem HTML-Namensraum enthält.
<article/>und<foo:article/>sind bei Verarbeitung als 'application/xhtml+xml' völlig äquivalente XHTML5-Elemente, wenn dem Präfix 'foo' der Namensraum 'http://www.w3.org/1999/xhtml' zugeordnet wurde.Das hat auch niemand bezweifelt. Dieser IE-Hack ist nur in der XML-Theorie stimmig. Wobei, noch nicht einmal das: Man würde niemals ohne Not solchen Code schreiben. Eine XML-Praxis gibt es derweil nicht: Aus naheliegenden Gründen wird niemand diesen Code als application/xhtml+xml an XHTML-fähige Browser ausliefern. Das gab es vor 10 Jahren bei XHTML 1.x nicht und niemand wird es ohne Vorteile für XHTML5 plötzlich einführen. Es wäre auch absurd. Den ganzen Zirkus veranstaltet man gerade wegen einem Browser, der weder HTML5 noch XHTML5 kann. Wieso sollte dieser Hack sämtliche anderen Browser betreffen, die unbekannte Elemente wie durch HTML5 vorgeschrieben parsen.
Ich verstehe nicht, warum dieser Hack eine solche Faszination ausübt. Ich vermute, weil da unglaublich mit Nebelkerzen geworfen wird. Es wird suggeriert, man würde XML-Namensräumen und XHTML5 nutzen. Dabei will man eigentlich nur einen unerklärlichen Bug im IE ausnutzen. Der ist an sich nicht zu rationalisieren. Trotzdem versucht man, das als XHTML5 zu verbrämen. Das zieht aber nur weitere Nachteile und Widersprüche nach sich.
Dass XHTML erste Wahl ist, sagte ich schon.
Okay. Darf ich dich auf das Thema des Threads hinweisen? ;)
Mathias
-
@@molily:
nuqneH
Klar, wenn dieser Code als XHTML5 verarbeitet werden WÜRDE, wäre section kein Element aus dem HTML-Namensraum. Aber bei dem Hack geht es eben NICHT darum, korrektes oder gar sinnvolles XHTML5 zu schreiben.
Ich hatte den Artikel so in Erinnerung, dass er dies (und nur dies) propogiert hätte. Tatsächlich tat er dies erst im letzen Abschnitt Using XHTML5. Ich hatte nur den für mich sinnvollen Teil in mein Langzeitspeicher geschoben. Weißt schon: die Guten ins Köpfchen, die Schlechten …
In vorherigen Abschnitt The solution schickte er Tagsoup an alle Browser. Das ging von meinem Kurzzeitspeicher nach /dev/null.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)
-
-
-
@@Daniel.S:
nuqneH
Warum wird als Namespace http://www.w3.org/1999/xhtml angegeben? Erstens bekomme ich da keine .xsd oder .dtd wie ich erwartet hätte
Zu einen: „Es ist nicht notwendig, dass [der Namensraumname] direkt für den Empfang eines Schemas (sofern eines existiert) verwendet werden kann.“ [XML-NAMES §2]
Zum anderen: (X)HTML5 wird gar nicht durch eine DTD oder ein XML Schema definiert.
und zweitens hört sich diese Definition nach xhtml und nicht nach html5 an?
XHTML5 verwendet denselben Namensraum wie XHTML 1.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain) -
Es gibt ein paar wenige Dinge, die in HTML5 definiert werden und schon jetzt benutzt werden können, z.B. audio- und video-Elemente (wobei die dank des Codes-Streits eher einer Todgeburt gleichen), das canvas-Element (scheint sehr beliebt zu sein)...
Mehr fällt mir ehrlichgesagt nicht ein.Naja, ich würde noch die neuen Werte fürs type-Attribut in die Liste aufnehmen (beim input-Element). Das Fallback ist klar formuliert und serverseitige Prüfung findet eh statt, so dass man in dem Rahmen auch "anders geformte" Eingaben parsen kann.
Problematisch sind wie angesprochen eben die neuen ich nenne sie mal semantischen Elemente wie das genannte <article> oder <nav> oder gibts nicht noch n <footer>?
Allerdings sind die auch nur problematisch wenn man den IE bedienen will, was nicht in jedem Kontext (wohl aber in den meisten kommerziellen) der Fall ist. Ich kenne auch den ein oder anderen Dienst, der auf der Startseite stehen hat, dass er nur mit "modernen Browsern" funktioniert und dann fünf aufzählt.Conditional Comments in der Art:
<!--[if lte IE 8]><div class="article"><![endif]-->
<!--[if gt IE 8]><!--><article class="article"><!--<![endif]-->
foo
<!--[if lte IE 8]></div><![endif]-->
<!--[if gt IE 8]><!--></article><!--<![endif]-->> > > > Styling dann eben über `.article`{:.language-css} anstelle von `article`{:.language-css}. Im Sinne der Übersichtlichkeit würde ich die IE-Elemente einfach in (oder um) die HTML5-Elemente legen, so dass scheinbar eine Baumstruktur erhalten bleibt: ~~~html <!--[if gt IE 8]><!--><article class="article"><!--<![endif]--> <!--[if lte IE 8]><div class="article"><![endif]--> foo <!--[if lte IE 8]></div><![endif]--> <!--[if gt IE 8]><!--></article><!--<![endif]-->und dann kann man imho auch darüber nachdenken ob man die CCs nicht (teilweise) weg lässt...
Appropos, was macht der IE-Parser eigentlich aus den schließenden Tags, die er nicht kennt?
wird
<article>foo</article>
zu
<article></article>foo</article><//article>
oder...?--
sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:(-
Hi,
Appropos, was macht der IE-Parser eigentlich aus den schließenden Tags, die er nicht kennt?
wird
<article>foo</article>
zu
<article></article>foo</article><//article>Habe keinen IE zum Testen zur Hand, aber laut Peter Kröners "HTML5" ist dies der Fall.
Bis die Tage,
Matti-
@@Matti Mäkitalo:
nuqneH
Appropos, was macht der IE-Parser eigentlich aus den schließenden Tags, die er nicht kennt?
wird
<article>foo</article>
zu
<article></article>foo</article><//article>Habe keinen IE zum Testen zur Hand, aber laut Peter Kröners "HTML5" ist dies der Fall.
<!DOCTYPE html> <html> <head> <title>TEST</title> </head> <body> <article>foo</article> <script> [code lang=javascript]for (var child = document.body.firstChild; child; child = child.nextSibling) alert(child.nodeName);</script> </body></html>[/code]
liefert in IE 7 und 8 'ARTICLE', '#text', '/ARTICLE', 'SCRIPT'.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)
-
-
-
Ja, die nächsten 3 bis 4 Jahre darfst du sicher noch warten. Bis dahin gibts auch die ersten Browser mit einem HTML-Parser wie er von HTML5 definiert wird (Firefox 4 und Safari 6 dürften das sein).
Das klingt etwas missverständlich: Firefox 4 soll bereits im Februar/März erscheinen und Chrome hat seit Version 7 (Oktober 2010) einen HTML5-Parser.
Mathias
-
Ja, die nächsten 3 bis 4 Jahre darfst du sicher noch warten. Bis dahin gibts auch die ersten Browser mit einem HTML-Parser wie er von HTML5 definiert wird (Firefox 4 und Safari 6 dürften das sein).
Das klingt etwas missverständlich: Firefox 4 soll bereits im Februar/März erscheinen und Chrome hat seit Version 7 (Oktober 2010) einen HTML5-Parser.
Stimmt, entschuldige.
Mir ging es um eine 'brauchbare Verbreitung', von der die Nutzer leztendlich auch profitieren können. Die werden wir mit dem Firefox-Release wohl erhalten.
Daniel.
-
-
-
Über zusätzlichen xmlns:
Hier hab ich erst ein Verständnisproblem. Warum wird als Namespace http://www.w3.org/1999/xhtml angegeben?Das ist der XHTML-Namensraum.
Man muss ihn wie gesagt nicht angeben, damit der Hack im IE klappt. Man gibt ihn an, damit das Element trotz des Namensraum-Präfixes ebenfalls zum HTML-Namensraum gezählt wird in dem hypothetischen Fall, wenn das Dokument von einem XML-Parser verarbeitet wird. Das ist aber üblicherweise nicht der Fall, dazu müsste man das Dokument als application/xhtml+xml anstatt text/html an den Browser ausliefern.Erstens bekomme ich da keine .xsd oder .dtd wie ich erwartet hätte
Eine Namensraum-Angabe ist eine beliebige URI. Hinter dieser URI muss nichts stecken. Sie muss nur ein eindeutiger Bezeichner sein. Dass es hier eine HTTP-URI ist, ist purer Zufall. Es hätte auch beispielsweise eine Tag-URI sein können. Diese URI hat nicht notwendigerweise etwas mit einer maschinenlesbaren Grammatik zu tun.
So wie ich das sehe funktioniert das sowieso nur weil sich der IE nicht darum schert was da angegeben ist?
Ja, richtig.
- es ist kein HTML5, sonder XHTML -> eigentlich Semantik der HTML5-Tags geht verloren.
XHTML5 definiert sich (wie gesagt) dadurch, dass es als XML deklariert und verarbeitet wird. In dem Fall würde die Semantik erkannt, weil das Element dem XHTML-Namensraum zugehörig ist. Im Falle von normaler HTML5-Verarbeitung wird das Element jedoch nicht als HTML erkannt.
(Wenn ich das oben erwähnte richtig verstehe besteht dieses Problem nur weil man als Namespace den XHTML-Namespace angibt?)
Nein. Was man da angibt, ist für den IE ohne Belang. Und für HTML-Tagsoup- sowie für HTML5-konforme Parser ebenfalls.
Gibt es noch andere Möglichkeiten HTML5 im IE zu ermöglichen?
Keine praktikablen.
Würdet ihr mit Hilfe einer der genannten Möglichkeiten in Erwägung ziehen HTML5 bei einem Projekt einzusetzen?
Kommt darauf an, wie wichtig in dem jeweiligen Fall eine Abwärtskompatibilität zu Internet Explorern ohne JavaScript ist. In manchen Fällen sind alte IEs mit deaktiviertem JavaScript z.B. aus Firmennetzen relevant, in anderen vernachlässigbar. Das heißt: Wieviele IEs ohne JavaScript frequentieren die Site und wie sieht die Site aus, wenn die HTML5-Elemente falsch geparst werden?
HTML5-Textauszeichnung ist erst einmal ein sehr gutes Feature einer Website, das sie zugänglicher machen kann und die maschinelle Verarbeitung verbessert. Man muss abwägen, ob man diesen Feature Benutzern mit neueren Browsern vorenthält, nur weil es alte (sowieso technisch hoffnungslos veraltete) Internet Explorer gibt, bei denen zudem die Möglichkeit verbaut ist, seine Lücken zu stopfen, indem JavaScript deaktiviert ist. Wer mit dieser Kombination im Jahr 2011 die volle Web-Experience fordert, den kann man m.M.n. getrost ignorieren.
Mathias