Mich erreichen regelmäßig E-Mails, in denen gefragt wird, wie man denn am besten eine vorhandene Webseite auf HTML5 umstellt. Besonders oft geht um Fragen der Validierung und um die neuen semantischen Elemente (<section>
, <article>
und Konsorten). Schließlich sind diese doch nur so schlecht vom Internet Explorer unterstützt und stellen komische Sachen mit den Überschriften an, die es nicht einfach machen, die Struktur der alten Seite 1:1 zu übertragen. Kurz gesagt lautet die Frage immer wieder: was tun beim Webseiten-Umbau? Ich hole an dieser Stelle immer gen die Hype-Bremse aus dem Schrank und behaupte: man kann es auch einfach sein lassen! Es gibt schließlich keine Verpflichtung zum Mithypen und oft existieren noch nicht mal gute Gründe, eine normale, bisher wunderbar funktionierende HTML 4/XHTML 1-Webseite auf HTML5 umzumodeln.
If it ain't broke, don't fix it
Wenn man eine wunderbar funktionierende Webseite hat, die in XHTML 1 oder HTML 4 geschrieben ist, sollte man sich gut überlegen, ob man diese tatsächlich „auf HTML5 umzustellen“ muss. Handelt es sich bei der fraglichen Seite wirklich um eine Webseite, also um ein paar HTML-Dokumente ohne übermäßigen interaktiven Charakter, gewinnt man durch einen Umbau nicht viel. Zwar mögen XHTML 1 und HTML 4 im Moment hypebedingt ein wenig uncool wirken, aber es ist nicht damit zu rechnen, dass es in den nächsten 20 Jahren keine Unterstützung mehr dafür geben wird.
Moderne Webbrowser haben viele Fehler, aber einen Standard halten alle Surfprogramme gleichermaßen ein: unbedingte Abwärtskompatibilität. Die Frage, ob ein Browser irgendwelche neuen Features unterstützt, ist eigentlich ein Luxusproblem. Der mit Abstand schlimmste Bug in einem Browser wäre, wenn er schon bestehende Inhalte des WWW nicht mehr verarbeiten könnte. Niemand würde einen Browser verwenden wollen, der sich der Verarbeitung älterer HTML-Dokumente verweigert, selbst wenn seine Unterstützung für HTML5 und CSS3 noch so großartig wäre. Und so kommt es, dass moderne Browser selbst älteste HTML-Fossilien (in diesem Falle von 1992) noch einwandfrei darstellen. Mit XHTML 1 und HTML 4 oder älter wird es sich die nächsten Jahre und Jahrzehnte genau so verhalten.
Eine Seite umzubauen, nur damit sie HTML5 verwendet, ist also eine ziemlich komische Idee, denn was bisher gut lief, wird auch weiterhin keinen Ärger machen. Stattdessen kann man sich mit einer HTML5-Umstellung sogar zusätzliche Probleme einhandeln.
Hürden und Fallen
Eine Webseite „auf HTML5 umzustellen“ ist allein schon dehalb keine einfache Aufgabe, weil man sich entscheiden muss, wie weit man gehen möchte. Nimmt man einfach sein altes Dokument und tauscht den Doctype aus, so wird man damit sicher keine großen Probleme haben. Wer aber weiter geht, halst sich relativ schnell eine Ansammlung kleinerer und mittlerer Ärgernisse auf.
So hat man zum Beispiel dem Fakt ins Auge zu sehen, dass HTML5 ein „Living Standard“ und damit unfertig ist. In Folge ergeben sich durchaus auch schon mal größere Änderungen. Bestes Beispiel sind die Änderungen am <time>
-Element, als das Element innerhalb weniger Tage erst aus dem Standard entfernt und dann wieder eingebaut wurde. In aller Regel sind Änderungen nicht gar so dramatisch wie bei <time>
, so dass man dem „Living Standard“ eigentlich recht gelassen gegenübertreten könnte (vor allem wenn man bedenkt, dass kein Ende dieses Zustandes in Sicht ist). Nur wirklich hilfreich ist der ganze Zirkus beim Seitenbau auch nicht, also warum die Eile damit?
Desweiteren gibt es noch das kleine Problem, dass viele Tools noch im XHTML-Zeitalter leben. Enterprisige Frameworks sprechen in aller Regel nur XHTML und manche Editoren kommen noch nicht mit HTML5-Features wie ausgelassenen End-Tags klar. Selbst eigens entwickelte HTML5-Tools haben noch Kinderkrankheiten – der HTML5-Validator weiß zum Beispiel nicht, dass man das &-Zeichen unter einer ganzen Reihe von Bedingungen gar nicht zu escapen braucht. Auch hier gilt: das ist alles nicht dramatisch und selbst im schlimmsten Fall nur mäßig lästig, aber es hilft eben auch nicht wirklich dabei, eine Webseite zu verbessern.
Etwas kräftiger kann man sich schon mit den neuen semantischen Elementen ins Knie schießen. Diese funktionieren bekanntermaßen in den IE6 bis 8 nur, wenn man sie mit JavaScript bearbeitet, aber ob man wirklich die Struktur der Webseite von JavaScript abhängig machen möchte, sollte man sich gut überlegen. In den meisten Fällen dürfte das kein dramatisches Problem darstellen, nur macht der Hack die bisher bestehende Webseite besser? Eher nicht. Hinzu kommt, dass die neuen Elemente die Überschriftenstruktur beeinflussen. Das ist kein Problem, wenn man eine neue Webseite konzipiert, aber eine bestehende Struktur auf HTML5 zu trimmen ist weder einfach, noch besonders sinnvoll – neben den in die neuen Elemente eingebauten WAI-ARIA-Features unterscheidet eine HTML5-Struktur so gut wie nichts von einer herkömmlichen Div-Suppe.
HTML5 bietet natürlich syntaktisch und semantisch so manches Features, das man gern verwenden würde. Wenn man allerdings den endgültigen Nutzen und den zu betreibenden Aufwand vergleicht, ist es vielleicht eine Überlegung wert, die HTML5-Umstellung auf einen Zeitpunkt zu verschieben, an dem man ohnehin alle Templates umbaut.
Wann soll man denn HTML5 verwenden?
Das liest sich jetzt vielleicht so, als wäre pauschal vom HTML5-Einsatz auf Webseiten abzuraten. Ganz so schlimm ist es sicher nicht, es ist nur recht sinnlos, eine gut funktionierende in HTML 4 oder XHTML 1 geschriebene Webseite des Hypes wegen auf HTML5 umzustellen. Anders sieht es aus, wenn man eine neue Seite baut oder aus anderen Gründen größere Umbaumaßnahmen an etwas Bestehendem durchführt. Wenn ohnehin alle Templates überarbeitet oder gar komplett neu geschrieben werden, ist es natürlich anzuraten, den neuesten Standard zu verwenden (wobei man auch hier nicht verpflichtet ist, jedes mögliche Feature einzusetzen).
HTML5 ist primär ein Spielzeug für Webapp-Programmierer. Die paar neuen Bonbons für herkömmliche Webseiten sind nett, aber nicht nicht so großartig, dass man sich darüber umgehend in Arbeit stürzen müsste. Man kann eine Umstellung auf HTML5 also ruhig auf den Zeitpunkt verschieben, an dem sowieso das nächste Redesign ansteht.
Meine Tipps bis dahin:
- Locker bleiben! Nur weil das halbe Internet und der Chef meinen, man müsste jetzt unbedingt aktionistisch werden, ist das noch lange nicht richtig. Entspannt Aufwand und Nutzen abzuwägen ist nicht nur in Sachen HTML5 eine empfehlenswerte Grundhaltung.
- Planen! Hat man es geschafft den Hype für den Moment abzuwehren, kann man natürlich für die Zukunft planen. Irgendwann steht der Wechsel auf HTML5 mit Sicherheit an, also sollte man sich der Sache nicht ganz verschließen. Ausprobieren, Lesen, Planen und Gedanken machen sind nie verkehrt.
- WAI-ARIA lernen! Die fest in die neuen Elemente eingebauten ARIA-Eigenschaften sind mit das größte Plus von semantischem HTML5. Allerdings kann man diese erstens auch manuell in ältere (X)HTML-Dokumente einbauen und zweitens muss man sich als HTML5-Autor ohnehin damit auskennen. Also: lesen!
Kommentare (24)
Janek ¶
17. Januar 2012, 14:38 Uhr
Fein. Bin gerade dabei HTML5-Relaunch zu machen und auch schon fast fertig. Glücklicherweise ist mir der IE herzlich egal. :-)
Wie schon beim alten Design bekommt der IE lte 8 einfach eine lineare Ansicht der Seite und da ist es dann auch egal, ob unbekannte Elemente direkt wieder geschlossen werden oder nicht. Wenn's nicht zu abgefahren wird, ist der IE9 übrigens gut mit dabei. In meinem Falle sind für diesen Browser keinerlei Fixes vonnöten. Allein ein paar nicht allzu wichtige Dinge wie CSS-Gradients ohne SVG etc. funktionieren da nicht (Data-URIs mit dynamischen SASS-Inhalten sind eher schlecht zu handhaben). Von daher denke ich, dass das IE-Problem auch in absehbarer Zeit weitest gehend gelöst sein könnte (angenommen, die Horde XP-Nutzer da draußen upgraded endlich mal ihr OS oder steigt auf einen anderen Browser um).
"If it ain't broke, don't fix it"
Full ACK. Wenn der Anlass aber eine Aufbohrung des Designs ist, kann ein HTML5-Rewrite ein angenehmer Nebeneffekt sein.
Tom ¶
17. Januar 2012, 14:45 Uhr
Danke für den Artikel.
Kurzer Hinweis: Unter dem 1. Kommentar steht: "Noch keine Kommentare zu diesem Artikel."
Das ist mal eine glatte Lüge :o)
Thomas ¶
17. Januar 2012, 20:08 Uhr
Einspruch! ;) Ausgelassene End-Tags gibts (wie ja in einem älteren Beitrag beschrieben) schon seit der ersten Stunde von HTML. In der DTD (hier HTML 4.01) erkennt man sie am "O" für "Optional". Die HTML5-Spezifikation übernimmt bzw. erweitert diese, und behandelt Grenzfälle.
Leider ist das in der Vergangenheit sehr häufig falsch gelehrt worden, und genau dieser Umstand hat dazu geführt, dass es massenweise HTML-Editoren gibt, die eigentlich gar kein HTML können, sondern nur sowas wie XML.
(Ach ja, und der IE
Peter Kröner ¶
17. Januar 2012, 20:18 Uhr
Einspruch abgelehnt. HTML-Features sind auch HTML5-Features.
Patrick ¶
17. Januar 2012, 23:03 Uhr
Es wird eh ein schleichender Prozess. Viele seiten nutzen schon CSS3 Elemente, was man im weitesten Sinne als HTML5 verstehen kann. Insofern abwarten und wenn es passt in die Seite implementieren was sinnvoll ist.
Mike Alter ¶
17. Januar 2012, 23:21 Uhr
Habe auch überlegt von XHTML1.0 umzustellen, bins aber wegen des enormen Aufandes der Endtags usw. noch nicht angegangen ( Viele über 100 kleinere Smarty-Templates die anzupassen wären). Mein erster Beweggrund war allerdings nocht der Hype, sondern die schlichte Möglichkeit in HTML5 Auszeichnungen für das Parsen von Facebook & Google+ semantisch fehlerfrei einzubauen. Damit die sozialen Riesen endlich die richtigen Snippets ( Bild und redaktionellen Text ) finden. Bzw. die Möglichkeiten den Googlespider Rich Snippets wie Produkte, Reviews etc.
In sofern hardere ich seit einigen Monaten.
Janek ¶
17. Januar 2012, 23:36 Uhr
Naja, was viele Editoren nicht können, ist die richtige Tag-Vervollständigung. In Sachen Syntax-Check habe ich jetzt noch keinen Editor gesehen, der aus fehlenden End-Tags bei Elementen, bei denen es erlaubt ist, ein Problem macht, aber ich bekomme ständig automatisch die Endtags für P- und LI-Elemente um die Ohren gehauen, obwohl ich mir die gern spare. Ansonsten werden unbekannte HTML5-Elemente ggf. schon mal unterkringelt, aber das ist dann auch alles.
Bei so richtig enterprisigen Geräten kann es natürlich schon sein, dass man da mal richtige Probleme bekommt (was weiß ich, unbekannte HTML5-Attribute-Werte sprengen durch die Verdrahtung des Editors mit der per RemoteDesktop eingebundenen und über Java-Sockets getunnelten IE6-Engine und der darin als Active-X-Element laufenden DOS-Emulationssoftware für die hochaktuelle Rechnungsverwaltungs-Software in 3km Entfernung den Zentralrechner des Unternehmens in die Luft oder so), das weiß ich jetzt nicht.
Schlimmer finde ich eigentlich den W3C-Validator. Der hat nicht, wie Peter im Blog-Post erwähnte, „Kinderkrankheiten“, sondern der versteht schlicht kein HTML5. Der kennt zwar den Doctype und ein paar der neuen Elemente, aber das war's auch schon. Früher war das mal ein Tool, mit dem man arbeiten konnte, mittlerweile nutze ich den nur noch, um schnell Verschachtelungsfehler bei automatisch generiertem HTML ausfindig zu machen. Zu viel mehr taugt der nicht mehr.
Peter Kröner ¶
17. Januar 2012, 23:53 Uhr
Du schreibst, als wäre das total undenkbar :)
Also bei mir gehen Doctype und Elemente (plus Attribute) als die Hauptsachen durch. Was fehlt denn noch so großes?
Janek ¶
18. Januar 2012, 00:07 Uhr
Ist mir gestern passiert. Deshalb ist Wikipedia morgen down (Netzwerklatenz und so). ;-)
Was den Validator angeht: das blöde Ding validiert Attribut-Werte, kennt aber nicht einmal die Hälfte der erlaubten Werte. Mal versucht, die neuen HTML5-Input-Types zu validieren? Gerade letztens erst wieder köstlich amüsiert über
Ähnlich dämlich geguckt habe ich, als ich mal versucht habe, eine Seite zu validieren, die time-Elemente mit datetime-Attributen enthält. Der Validator lässt nur eine einzige Schreibweise zu, nämlich nur genau YYYY-MM-DDTHH:mm:ssZ. Alle die tausend anderen laut Spezifikation möglichen Schreibweisen werden nicht berücksichtig. Es muss nur ein Teil fehlen, schon wirft der Validator einen Fehler. Die Anmerkung
mutet da auch schon ironisch an. Man beachte some.
Genauso seltsam ist die rel-Attribut-Validierung mit dem Hinweis:
Soll heißen: im Grunde ist jeder Wert denkbar, ich werfe aber trotzdem mal einen Fehler wenn der Attribut-Wert nicht auf der DIN-A7-Microsoformats-Karteikarte des W3C verzeichnet ist.
Peter Kröner ¶
18. Januar 2012, 00:17 Uhr
Also
<input type="search">
scheint er mittlerweile zu kennen. Das mit den Zeitangaben ist ein bisschen fies, weil da sind der Großteil der erlaubten Formate ja wirklich erst kürzlich eingeführt worden. Das würde ich dem Validator nicht zum Vorwurf machen, ebenso wenig wie das mit den Microformats. Das sind eben Sachen, die in 99% aller Fälle falsch sind, aber unter bestimmten Umständen eben nicht – genau wie ein ausgelassenesalt
-Attribut bei<img>
. Wir, die wir diese Spezialfälle bauen, wissen in aller Regel was wir tun, d.h. ich denke wir können (für uns) falsche Validatormeldungen eher souverän interpretieren als Anfänger, die dasalt
-Attribut versehentlich auslassen.Es ist halt nicht leicht HTML5-Validator zu sein. Genau genommen halte ich es für kaum leistbar, einen fehlerfreien bzw. einen alle Spezialfälle abdeckenden Validator überhaupt zu bauen. Geht nur näherungsweise. Und vermutlich nicht so viel besser als jetzt.
Janek ¶
18. Januar 2012, 00:36 Uhr
Also
<input type="search">
habe ich gerade erst ausprobiert, funktioniert immer noch nicht.Was die Microformats und die Zeit-Angaben angeht, so finde ich, dass der Validator das wenigstens als Warnungen kennzeichnen sollte, wenn nicht bloß nur als Hinweise. Microformats müssen meinetwegen gar nicht validiert werden. Ob die falsch oder richtig sind, lässt sich eh nur anhand der Semantik feststellen und die kann kein Validator prüfen. Wenn ich eine Blog-Seite validiere und für jeden Eintrag ein article-Element mit einem enthaltenen time-element habe, dann habe ich schon einmal gut und gern 10-20 mal die Meldung, dass mein datetime-Attribut einen ungültigen Wert besitzt, der aber theoretisch auch gültig sein könnte und ich suche dann nach den richtigen Fehlern, für die ich trotz 1440px Bildschirmhöhe erst einmal eine Ecke scrollen muss.
Ich habe da mittlerweile schon so eine Art Tunnel-Blick entwickelt. Wann immer ich „Bad value“ sehe, lese ich schon gar nicht mehr weiter. Auch nicht schön.
Wenn wir schon einmal dabei sind: der Input-Type "search" scheint zumindest im Firefox noch etwas mehr als nur eine optische Bedeutung zu haben. Ich konnte noch nicht ganz rausfinden, was genau da abläuft, aber unter gewissen Umständen behält der Firefox den Wert nach dem Absenden und packt den da als eine Art Placeholder rein. Einmal habe ich auch zu einem falschen Zeitpunkt Enter gedrückt und der Suchbegriff wurde an Google weitergeleitet. Konnte das noch nicht verlässlich reproduzieren, aber irgendwie verhält sich das Feld anders als normale Input-Felder.
Der Chromium zeigt beim :focus-Event übrigens auch immer ein kleines X an, um den aktuellen Suchbegriff zu löschen. Aber das ist ja schon fast wieder nur Präsentation.
BTW du solltest mal per Cookies die Werte der Meta-Felder deiner Kommentar-Funktion speichern. Erleichtert das Kommentieren, wenn ich nicht immer die Autovervollständigen-Funktion des Browsers bemühen muss. ;-)
Peter Kröner ¶
18. Januar 2012, 01:41 Uhr
Was mache ich falsch?
Nur da oder bei allem, was schwer zu validieren ist? Soll das Fehlen von
alt
-Attributen auf<img>
auch nur noch ein Hinweis sein? Wenn nicht, würde ich fragen, welchen Maßstab man denn anlegen sollte um zu entscheiden, was ein richtiger Vielleicht-Fehler ist und was nicht.Ist doch super, dann stört es dich offenbar kaum noch. Man sollte sowieso seinen Tools nicht blind vertrauen, man kann man auch eine horrende Kack-Webseite auf valide Art und Weise bauen. Und je mehr drastische Meldungen Anfänger um die Ohren gehauen bekommen, umso besser.
Steht auf der Todo-Liste.
Janek ¶
18. Januar 2012, 02:47 Uhr
Okay, in diesem Falle scheint der Fehler bei mir gelegen zu haben und mal nicht beim Validator, jedenfalls nicht vollständig.
Fehler war: die search-Aria-Rolle war (aus welchen Gründen auch immer) direkt auf dem Input gesetzt anstatt auf dem umgebenden Div. Laut Spezifikation nicht erlaubt. Nur warum der Validator mir dann nicht eine Meldung wie "Cannot override strong native semantic" auswirft, sondern das Pferd von hinten aufzäumt und mir sagt, ich solle doch mal bitte den Wert des type-Attributs ändern ohne dabei auch nur im Ansatz zu erwähnen, was der Grund ist, entzieht sich meinem Vorstellungsvermögen. Da das Input-Feld noch 6 weitere Attribute enthält, tauchte das role-Attribute noch nicht einmal im angezeigten Snippet auf.
Da frage ich mich doch: wozu nutze ich dieses Tool eigentlich…
Einerseits ja, andererseits wäre es genau für solche Fälle schön, wenn man vom Validator wenigstens in den meisten Fällen halbwegs verlässliche Resultate bekäme. Hätten wir diese Diskussion nicht gehabt, hätte ich den Fehler wahrscheinlich erst irgendwann beim erneuten Durchgehen des Quellcodes gefunden oder er wäre für immer unentdeckt geblieben. Der Validator hilft da eher kaum, der Tunnelblick gar nicht.
In Sachen Microformat-Validierung: meinetwegen kann man die auf syntaktische Korrektheit prüfen (keine ungültigen Zeichen), aber der Rest ist Müll. Ich finde überall da, wo Validierungsfehler wahrscheinlich sind, sollte eher eine Warnung ausgegeben werden, überall da, wo korrekte Validierung absolut unwahrscheinlich ist, eher eine Notice (wenn überhaupt).
HTML-Input-Types kann man validieren, da gibt es eine begrenzte Anzahl an Werten. datetime-Werte kann man auch validieren, wenn man denn mal seine Sources aktuell hielte. Microformats kann man hingegen nicht validieren, solange nicht gegen eine für alle Welt verbindliche und stets aktuelle Datenbank gültiger Werte geprüft wird. Alles andere ist so schwachsinnig wie zu prüfen, ob mein gesetzter Meta-Charset gültig ist oder das type-Attribut eines Link-Elements einen bekannten Wert besitzt.
Janek ¶
18. Januar 2012, 02:53 Uhr
Nachtrag: die seltsame Meldung des Validators resultiert wohl aus diesem Teil der Spezifikation:
Aber wenn's denn wenigstens das gewesen wäre. Hätte der Validator gesagt: "Use a more appropriate element to represent a search facility" , dann wäre auch klar gewesen, was gemeint ist. Was der Validator hier macht ist etwa dasselbe wie zu sagen "Mach das Schild da weg" anstatt klar zum Ausdruck zu bringen, dass der Wagen einfach im Halteverbot steht. :-\
Matti ¶
18. Januar 2012, 08:18 Uhr
... genau der richtige Beitrag zum richtigen Zeitpunkt - danke Peter. Ich hatte mir deine DVD gekauft, um einen guten Einstieg in HTML5 zu bekommen. Das ist gelungen.
Gegen die von dir gern erwähnten div-Suppen in XHTML-1 und HTML 4 hilft im Übrigen immer noch Andy Clarks "Transcending CSS": benutze die Dinge wofür sie geschaffen wurden.
Jan ¶
19. Januar 2012, 02:18 Uhr
Macht es eigentlich einen relevanten Unterschied, ob der HTML5 Doctype oder XHTML Strict genutzt wird? Der HTML5 Doctype sollte ja den HTML5 Parser aktivieren. Hat dieser irgendwelche nennenswerten Vorteile?
Peter Kröner ¶
19. Januar 2012, 02:35 Uhr
Browsern sind Doctypes fast völlig egal. Wenn du dein XHTML-Dokument wie üblich mit dem Content-Type
text/html
auslieferst (und ich nichts verpasst habe) wird für es der gleich Parser wie für ein HTML5-Dokument verwendet. Um den XML-Parser für XHTML zu verwenden, müsstest du den Content-Typeapplication/xhtml+xml
benutzen, was keiner tut, da dieser Content-Type von den IE6, 7 und 8 nicht unterstützt wird. Richtig große Unterschiede zwischen einen HTML5-Parser und einen Prä-HTML5-Parser gibt es auch nicht.Also nein, es macht keinen Unterschied, solange überhaupt ein Doctype vorhanden ist. Zu Vermeidung von Verwirrung sollte man halt einen nehmen, der dem verwendeten HTML-Featureset entspricht-
Klaus ¶
22. Januar 2012, 11:52 Uhr
von jemand der sich selbst schon mal als HTML5-Erklärbär bezeichnet ein schöner, unaufgeregter Artikel, der den imho schon manchmal etwas hysterisch klingenden HTML5-Hype in geeigneter Weise wieder erdet. :)
HTML5 kommt...sicher...mit all seinen Vor- und Nachteilen. Wir werden damit arbeiten und zurechtkommen!
Es ist aber noch in der Entwicklungsphase, warum sollte ich meine ordentlich funktionierenden Websites schon jetzt darauf umstellen.
Warum sollte ich sie überhaupt je darauf umstellen? Wenn die jetzigen und auch zukünftigen Funktionalitäten der entsprechenden sites mit der bestehenden Dokumentenstruktur problemlos funktionieren muss ich da doch garnix machen, oder? ;)
Manuel Kaufmann ¶
22. Januar 2012, 20:03 Uhr
Mein neustes Projekt ist ein Online Shop. Und den mach ich komplett mit HTML5. Aber den IE8 - 6 werd ich trozdem berücksichtigen. Wenn jemand mit einen dieser Browser kommt, lass ich per PHP die HTML5-Elemente durch andere Elemente ersetzen. (
<footer>
wird dann z.B. zu<div class="footer">
). Ist natürlich mehraufwand (denn man muss ja auch noch das CSS anpassen) aber ich will nicht noch 20 Jahre warten um neue HTML5 Elemente zu verwenden!! Und den IE8 wirds definitiv noch eine Weile geben, da man auf XP keinen höheren IE installieren kann.Aber diese Lösung werde ich in Zukunft für alle meine Projekte einsetzen.
Gruß, MK
Marko ¶
23. Januar 2012, 23:40 Uhr
@Manuel http://code.google.com/p/html5shiv/ wäre auch eine Option
Manuel Kaufmann ¶
24. Januar 2012, 10:52 Uhr
@Marko Ich weiß, aber ich wollte eine Möglichkeit ohne JavaScript. Weil es ja auch durchaus vorkommen kann, dass JS abgeschaltet ist.
frederik ¶
24. Januar 2012, 16:35 Uhr
Sehr informativer Artikel, ich denke auch über das das Umstellen auf HTML 5 all meiner Webseiten nach. Warscheinlich erfolgt dies nach udn nach.
Lese gerne wieder rein.
Don ¶
25. Januar 2012, 01:05 Uhr
..ja, man kann durchaus nochmal ein
div
verwenden. Und stimmt schon, warum nicht die alten Seiten so lassen wie sie sind!Sepp Baum ¶
18. Juni 2012, 20:28 Uhr
Um den XML-Parser für XHTML zu verwenden, müsstest du den Content-Type application/xhtml+xml benutzen, was keiner tut, da dieser Content-Type von den IE6, 7 und 8 nicht unterstützt wird.
Es stimmt nicht dass keiner das tut, Peter. Ich bestimme den Content-Type mit PHP:
$content_type = stristr($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml") ? "application/xhtml+xml" : "text/html";