Warten auf 2.10 final / RC1 einsetzen / Upgrade von 2.9.5?

Hallo,

ich möchte zeitnahe eine umfangreiche Website mit Contao erstellen und bin nun etwas unsicher, wie ich mit der anstehenden Veröffentlichung von Contao 2.10 umgehen soll.

Welcher der folgenden Thesen würdet ihr zustimmen, falls man das überhaupt so pauschal sagen kann?

• Warte lieber auf die finale Version von Contao 2.10, wenn du dir eine Menge Ärger und Arbeit ersparen möchtest.
• Du kannst ruhig den RC1 verwenden, da sich kaum noch etwas verändern wird und dieser keine groben Fehler mehr enthält. Dann einfach auf die finale Version "updaten".
• Beginne mit der derzeit aktuellen Version 2.9.5 und migriere dann auf Contao 2.10, was problemlos möglich ist.

Lässt sich abschätzen, wann die finale Version von Contao 2.10 veröffentlicht wird? Derzeit sind ja noch 20 Tickets offen. Im Forum las ich etwas von 2 Wochen…

Wie lange dauert es in der Regel, bis die wichtigsten Erweiterungen zur neuen Version kompatibel sind? Gibt es dazu Erfahrungswerte?


So, nun hoffe ich, dass ich das richtige Unterforum gewählt habe und bedanke mich schon einmal für eure Antworten.

Viele Grüße
JaiBee

Kann man schlecht pauschal beantworten. Ich würde RC1 keinesfalls produktiv einsetzen. Ob zur Entwicklung, hängt davon ab, ob man in der 2.9 nicht vorhandene Features nutzen will und wieviel Zeit die Realisierung benötigt. Und falls man Erweiterungen einsetzen will, die mit 2.10 noch nicht kompatibel sind, stellt sich doch die Frage vorläufig noch garnicht.

soweit_ok, danke für dein Antwort!

Zwingend werden die neuen Funktionen von Contao 2.10 nicht benötigt, wobei es natürlich schade wäre, eine neue Website mit einem System zu erstellen, welches ein paar Wochen später schon "veraltet" ist.

Die Website soll Anfang September online gehen – man kann ja vermutlich davon ausgehen, dass die finale Version von Contao 2.10 früher erscheint, oder sehe ich das falsch?


Ist abzusehen, wie komplex ein Umstieg von 2.9.5 auf 2.10 wäre? Könnte man z.B. die neuen HTML5-Templates ohne größere Anpassungen übernehmen oder wäre es dann notwendig bzw. sinnvoller, die alten .tpl-Templates weiterhin zu verwenden?

Fragen über Fragen… ;)
Gruß JaiBee

Ich kann Dir dazu halt nur meine persönlichen Einschätzungen/Ansichten nennen. Aus dem bisherigen Umfrageergebnis kann man ja entnehmen, dass ca. 20 % der User anscheinend auf die 2.10 RC1 aufsetzen würden. Na ja, ich denke, das hängt ganz vom Einsatzszenario ab.

Was mir grundsätzlich sehr zu denken gibt - dass die Abwärtskompatibilität zu IE <9 nur gegeben ist, wenn Javascript in den Browsereinstellungen erlaubt ist. Die Statistiken darüber haben nur begrenzte Aussagekraft, weil man realistisch betrachtet nach Besuchergruppen unterscheiden müsste. So vermute ich, dass der weitaus größte Teil mit abgeschaltetem JS bei Firmen und im öffentlichen Dienst zu finden ist. Auch wenn JS erlaubt ist, können restriktive Firewalls zur Folge haben, dass die html5.js der Contao-Version 2.10 nicht funktioniert. Sicher, die unterschiedlichsten Probleme mit dem IE aller Versionen sind total ätzend, doch es ist nunmal so, dass er bedeutende Marktanteile hat.

Der zweite Punkt sind die Erweiterungen. Auch wenn die nötigen Anpassungen an die 2.10 nicht sehr aufwändig sind, dummerweise müssen aber ALLE Erweiterungen angepasst werden. Und ich frage mich, wie lange es wohl dauern mag, bis das in ausreichendem Umfang erledigt ist. Aktuell ist es jedenfalls so, dass diverse Erweiterungen, die durchaus fehlerfrei unter 2.9.5 laufen, bis heute nichtmal für die 2.9 freigegeben sind. Entwickler die das nicht schafften, passen aber ihre Erweiterungen zeitnah auf die 2.10 an - und wovon träumst Du nachts. ;-)

Ein weiterer Punkt betrifft Benutzer, die einen Shop mit vielen Kategorien und Unterkategorien sowie vielen Produkten einsetzen. Bereits bei einigen hundert Produkten kann sich das massiv auswirken. Mit Sicherheit kann ich das allerdings nur bei Isotope sagen, beim Webshop ist mir die Struktur nicht bekannt. Unter diesen Voraussetzungen schlägt ein dramatisches Performance-Lack im BE zu, welches auf den Contao Core zurückzuführen ist und leider erst in der 2.10 gefixt wurde, indem die Zahl der Datenbankabfragen um etwa den Faktor 10 reduziert werden konnte. Im zugehörigen Ticket wurde ein Workaround veröffentlicht, der auch für 2.9 angewendet werden kann. Es bedeutet aber, wenn oben genannte Voraussetzungen gegeben sind, muss man das Problem anhand dieses Workarounds selbst fixen, denn den Livegang einer großen Webseite mit vielen Erweiterungen für September mit der Version 2.10 zu planen, fände ich sehr mutig. Bei einer relativ kleinen Webseite hätte ich hingegen keine besonderen Bedenken. Mit "klein" meine ich nicht die Menge an Content, sondern den Einsatz nur weniger Erweiterungen bzw. eine insgesamt überschaubare Interaktivität.

Ja, Du vermutest richtig, bis September ist die Final-Version sicher längst verfügbar und es sind dann dementsprechend auch schon praktische Erfahrungen im Produktiveinsatz damit zu erwarten. Ich persönlich warte mit der Umstellung mit Sicherheit mindestens bis Anfang 2012 bzw. nicht bevor ich die Zeit hatte, es komplett in der lokalen Entwicklungsumgebung umgesetzt und gründlich getestet zu haben. Bis auf Weiteres benötige ich noch kein HTML5 und ich kann es mir mit meinem akt. Projekt einfach nicht leisten, nicht auf der sicheren Seite zu sein. Was andere darüber denken, ist mir relativ egal, denn was an die Substanz geht, kann und sollte schließlich jeder für sich selbst entscheiden.

Momentan habe ich keine Cross-Browser-Probleme, doch ich hatte während der Entwicklung hin und wieder welche mit manchen Erweiterungen, die mir mitunter fast den letzten Nerv raubten, sie zu lösen. Deshalb verspüre ich keinerlei Dringlichkeit für mich, da ohne Not noch eins draufzusetzen. Dass ich auf 2.10 umstellen werde, ist keine Frage, nur eben wann. Mehr kann ich dazu nicht sagen. In diesem Sinne vermute ich auch, die Handlungsweise der meisten Contao Designer/-entwickler bzgl. der Umstellung orientiert sich wohl vorwiegend an den jeweiligen Projektanforderungen. Deine Umfrage ist ja nicht uninteressant, das Ergebnis kann Dir Deine Entscheidung aber nicht abnehmen.

Wow, vielen Dank für diese ausführliche Antwort.

Zitat:

---

Zitat von soweit_ok

Was mir grundsätzlich sehr zu denken gibt - dass die Abwärtskompatibilität zu IE <9 nur gegeben ist, wenn Javascript in den Browsereinstellungen erlaubt ist.

---

Daran habe ich noch gar nicht gedacht, aber es ist gut, dass du mich darauf hingewiesen hast. Da zur Zielgruppe der Website auch Mitarbeiter und Führungskräfte von Unternehmen gehören, ist das in der Tat eine nicht vernachlässigbare Einschränkung.

Zitat:

---

Zitat von soweit_ok

Unter diesen Voraussetzungen schlägt ein dramatisches Performance-Lack im BE zu, welches auf den Contao Core zurückzuführen ist und leider erst in der 2.10 gefixt wurde

---

Diese Problem wird bei der Website wohl nicht auftreten. Und selbst wenn, wäre die Integration des Patches bestimmt kein Hexenwerk.

Zitat:

---

Zitat von soweit_ok

den Livegang einer großen Webseite mit vielen Erweiterungen für September mit der Version 2.10 zu planen, fände ich sehr mutig. Bei einer relativ kleinen Webseite hätte ich hingegen keine besonderen Bedenken. Mit "klein" meine ich nicht die Menge an Content, sondern den Einsatz nur weniger Erweiterungen bzw. eine insgesamt überschaubare Interaktivität.

---

In Anbetracht deiner Einschätzung und der Tatsache, dass ich kein unnötiges Risiko eingehen möchte, zumal der Mehrwert von 2.10 dann doch eher gering ist, tendiere ich momentan stark zu Contao 2.9.5. Damit macht man wohl nichts verkehrt und ob die Seite nun auf HTML5 setzt oder nicht, dürfte dem Kunden wohl auch ziemlich egal sein. Wichtig ist nur, dass es mit allen gängigen Browsern – mit und ohne JavaScript – funktioniert. Und das spricht dann wohl für Contao 2.9.5.

Zitat:

---

Deine Umfrage ist ja nicht uninteressant, das Ergebnis kann Dir Deine Entscheidung aber nicht abnehmen.

---

Klar, aber wenn das Forum diese Funktion bietet, muss man sie schließlich nutzen :D.

Also, soweit_ok, vielen Dank nochmals für deine Hilfe. Du hast mir die Entscheidung um einiges leichter gemacht.

Gruß JaiBee

Zitat:

---

Zitat von soweit_ok

Was mir grundsätzlich sehr zu denken gibt - dass die Abwärtskompatibilität zu IE <9 nur gegeben ist, wenn Javascript in den Browsereinstellungen erlaubt ist.

---

Man kann aber auch weiter xHTML einsetzen. Da sollten keine Probleme Auftreten (außer mit dem ie6)

Zitat:

---

Da zur Zielgruppe der Website auch Mitarbeiter und Führungskräfte von Unternehmen gehören, ist das in der Tat eine nicht vernachlässigbare Einschränkung.

---

Zur werblichen Aussage, Contao sei auch für große Webseiten geeignet, zählt zwingend auch die betriebswirtschaftliche Betrachtung durch die Brille der zu dieser Kategorie zählenden Benutzer des Systems. Ich finde es sehr schade, obgleich im Forum zu der Zeit umfangreich und kontrovers diskutiert, dass dieser Aspekt bei der letzlichen Entscheidung für die einfacher umzusetzende Art der HTML5-Unterstützung dem plakativen Anspruch geopfert wurde, mit möglichst geringem Aufwand bzw. schnell mit noch mehr "Modernität" punkten zu können. Ich würde mich nicht wundern, sollte die Realität das Wunschdenken einholen, die Verwendung von IE-Versionen <9 ohne JS würde nicht mehr lange eine Rolle spielen. Anderenfalls werden vielleicht mittelfristig einige Nutzer Contao für neue Projekte weniger häufig einsetzen. Auf längere Sicht bei 2.9.5 stehenzubleiben oder dieses neue Feature der 2.10 nicht bedenkenlos nutzen zu können, wäre immerhin keine Lösung.

Zitat:

---

... der Mehrwert von 2.10 dann doch eher gering ist

---

Dass der Mehrwert der kontinuierlichen Weiterentwicklung von Contao gering sei, würde ich so nicht sagen. Ich betrachte bloß die Implementierungsform der HTML5-Unterstützung unterm Strich eher als unterhalb des techn. Niveaus angesiedeln, das Contao ansonsten durchgängig bietet.

Zitat:

---

... wäre die Integration des Patches bestimmt kein Hexenwerk.

---

Nein, keineswegs Hexenwerk, diesen Patch in den PHP-Code einzufügen. Es gibt allerdings auch eine Reihe von Einsteigern, die sich in die akt. Version einarbeiten. Deshalb hätte das m. E. noch in den Core der 2.9.5 wandern sollen.

Zitat:

---

Zitat von psren

Man kann aber auch weiter xHTML einsetzen. Da sollten keine Probleme Auftreten (außer mit dem ie6)

---

Ja, zum Glück ist das so. Weshalb ich das Ganze derzeit auch noch gelassen betrachte und ich damit leben kann. Von wenigen Dingen, die ich vermisse mal abgesehen, arbeite ich außerordentlich gerne mit Contao und möchte das möglichst auch weiterhin. Abhängig von der weiteren Entwicklung hinsichtlich Standardisierung etc. will man aber vielleicht doch irgendwann HTML5 verwenden. Bleibt es jedoch dabei, dass die Unterstützung JS voraussetzt, kann dies je nach Zielgruppe noch nicht begonnener zukünftiger Projekte ein wichtiger Minuspunkt für den Einsatz von Contao sein.

Wobei ich die Gründe für die "kleine" Lösung der HTML5-Unterstützung durchaus nachvollziehen und verstehen kann. Die verflucht langen Übergangszeiten eben, bis etwas "vielleicht" mal Standard wird. Na ja, mir persönlich wäre es eben lieber gewesen, damit noch zu warten, um es ggf. später ohne einen solchen Kompromiss zu implementieren. Nicht nur Core-Entwickler müssen strategische Entscheidungen treffen - die an der Endkundenfront genauso.

Ungeachtet dessen, dass nicht immer alles meine innere Zustimmung erhält und ich mich mal dementsprechend kritisch dazu äußere, finde ich Contao aber große Klasse und das Forum im Vergleich mit so manchen anderen OS-Foren ebenfalls.

Zitat:

---

Zitat von soweit_ok

... Ich finde es sehr schade, obgleich im Forum zu der Zeit umfangreich und kontrovers diskutiert, dass dieser Aspekt bei der letzlichen Entscheidung für die einfacher umzusetzende Art der HTML5-Unterstützung dem plakativen Anspruch geopfert wurde, mit möglichst geringem Aufwand bzw. schnell mit noch mehr "Modernität" werben zu können ...

---

Bei der Diskussion um die Umsetzung ging es gerade nicht um plakative Ansprüche sondern um die Frage der Kompatibilität, die Du ja bereits im Zusammenhang mit betriebswirtschaftlichen Gründen postuliert hast.

Insofern ist Deine Darstellung zumindest unklar - und ich finde nicht, dass die Diskussion hier Unklarheiten verdient hat ... ;-)

Carolina.

Zitat:

---

Zitat von lucina

Bei der Diskussion um die Umsetzung ging es gerade nicht um plakative Ansprüche sondern um die Frage der Kompatibilität, die Du ja bereits im Zusammenhang mit betriebswirtschaftlichen Gründen postuliert hast.

Insofern ist Deine Darstellung zumindest unklar - und ich finde nicht, dass die Diskussion hier Unklarheiten verdient hat ... ;-)

Carolina.

---

Hallo Carolina,

na ja, dieses Statement war nicht als Darstellung gedacht. Jedenfalls nicht im Sinne einer Unterstellung dieses Motivs, sondern lediglich Ausdruck meiner Verunsicherung und einer gewissen Skepsis ggü. dieser Lösung. html5.js als Fallback bei Verwendung von HTML5 ist nunmal mit dem genannten nicht unerheblichen Nachteil verbunden.

Es hängt mit dem hohen Entwicklungsaufwand und der Reichweite meines akt. Projekts zusammen, dass der Werkzeugwahl besondere strategische Bedeutung zukam. Momentan ist HTML5 bei meinen Kunden noch nicht gefragt, aber das könnte sich irgendwann ändern. Meine Befürchtungen beziehen sich auf mögliche Umsatzeinbußen, wenn nur 5 % dann kein Javascript-Fallback akzeptieren. Eine solche Befürchtung ist schließlich nicht aus der Luft gegriffen, weil bekanntermaßen ansonsten häufig auf ein Fallback FÜR Javascript Wert gelegt wird.

Wenn ich mich übrigens recht erinnere, hattest Du in der zurückliegenden Diskussion darüber ebenfalls nicht für die Lösung eines Javascript-Fallbacks votiert. Korrigier mich bitte, falls ich mich täusche.

HG Andreas

Zitat:

---

Zitat von soweit_ok

Momentan ist HTML5 bei meinen Kunden noch nicht gefragt, aber das könnte sich irgendwann ändern. Meine Befürchtungen beziehen sich auf mögliche Umsatzeinbußen, wenn nur 5 % dann kein Javascript-Fallback akzeptieren. Eine solche Befürchtung ist schließlich nicht aus der Luft gegriffen, weil bekanntermaßen ansonsten häufig auf ein Fallback FÜR Javascript Wert gelegt wird.

---

Drum ja der Doppelmoppel mit xhtml / html5-Templates. Das ist ja gerade das elegante daran: durch paralleles Templating eine HTML5-Ausgabe genau dann zu ermöglichen, wenn die Welt Deiner Meinung nach soweit ist.

Wenn Du das zeitnah einsetzen möchtest, dann steht Dir das ja auch frei - unter der Prämisse, dass Du weißt was Du tust, für entsprechende Fallbacks sorgst (oder auch nicht und den eingebauten nutzt). Whatever, Contao ist m.E. flexibel genug für sowas.

Carolina.

Woher Dein plötzlicher Sinneswandel? ;-)

Da ich schon viele Deiner Beiträge las, ist mir Deine hohe Fachkompetenz durchaus bewusst und ich nehme Deine Statements entsprechend ernst. Erklär´s mir, wenn Du magst.

Nachfolgend mal ein paar Auszüge aus Deinen Postings im Thread http://www.contao-community.de/showt...t=lucina+html5

Zitat:

---

Naja, da bin ich ja schon bei den Gegenargumenten: In Konsequenz würde es bedeuten, dass Contao beim Buzzword-Bingo mitmacht, indem es den Output mit ein wenig HTML5 aufhübscht, im Hintergrund aber XHTML im HTML5-Style ausliefert. .....

..... Klar, man kann das, und in vielen Fällen wird das auch gut gehen, aber ich persönlich empfinde das als schlicht als unsauber. es gibt diverse Artikel, die sich dagegen aussprechen, und die haben meine volle Zustimmung.

Vermutlich sauberer wäre folgendes Vorgehen, dass allerdings - mir ist das bewusst - sehr viel mehr Arbeit macht:

• Modularisierung der fe_page mit dem Ziel, je nach gewähltem Doctype die weitere Ausgabe im HTML- oder im XHTML-Codestyle erfolgen zu lassen
• Zur Verfügung stellen von Methoden, die es erlauben, die bisherigen IDs abhängig vom ersten Schritt in eine ID- oder eine Section-basierte Struktur zu mappen (es sollten ja weiterhin banale #IDs möglich sein ...)
• Für den HTML5-Teil der Abschied vom Container-Konzept mit #left, #right und Konsorten
• eine Möglichkeit an die ExtensionentwicklerInnen, weitere HTML5-fähige Templates in einem Ornder /modules/foo/templates5 unterzubringen
• eine verlässliche Möglichkeit, abzufragen, ob mit einem Modul ein HTML5-Output möglich ist und die betreffende Extension dann - analog zum 'kompatible Erweiterungen anzeigen' - bei Vorliegen der Voraussetzungen dem System zur Verfügung zu stellen. Das ist ganz übel, ich weiß.

Für bestehende Extensions würde das erstmal gar nichts ändern, die könnten innerhalb der XHTML-Struktur weitermachen wie bisher, würden aber ohne weiteres Zutun im HTML5-Zweig keine Berücksichtigung finden. .....

...... Mein persönliches Fazit, mein Plädoyer dafür, es etwas grundsätzlicher anzugehen.

---

Zitat:

---

Ich glaube, das die wenigsten hier den Einsatz von HTML5 ablehnen - es geht doch eher um die Art und Weise der Implementierung.

Zitat von conta1234 Ich finde die Abwärtskompatiblität durch JS .... ist eine Belastung, die man vielleicht ein paar Bauern verkaufen kann aber nicht zahlenden Kunden.

Siehe oben. Sei Dir sicher, dass es unser aller Bestreben ist, auf solche Krücken zu verzichten. Auch im Sinne unserer Kunden. Die Kompatibilitätsscripte machenmir allerdings ebenfalls Bauchschmerzen.

---

Dass dieses Thema so ausführlich und kontrovers diskutiert wurde, hatte schließlich Gründe. Obwohl ich mich zu der Zeit selbst nicht dazu äußerte, las ich aufmerksam mit und dachte mir natürlich auch was zu den verschiedenen Positionen. Kannst Du angesichts dessen nicht nachvollziehen, warum ich in der letztlich gewählten Art der Implementierung eine auf Dauer nicht überzeugende Interimslösung vermute? Wie gesagt, mit guten Argumenten denke ich gerne um. Ja, ich schätze Flexibilität genauso wie Du, doch denke dabei auch, ein Plus an Flexibilität sollte möglichst nicht mit einem Minus an Kontinuität erkauft werden.

Wenn Euch die Fallback Lösung per JS für IE<9 nicht gefällt, mal die Frage, was es für Alternativen gäbe?
Es wäre natürlich cool, würde Contao selbst auf xhtml umschalten, wenn erkannt wird, der anfragende Browser kann kein HTML5.
Bzw. per default xhtml und wenn Browser gut genug, dann auf html5 umschalten.
Und wie würde man das erkennen? Per Agent String? Hmm, schwierig denke ich mal eindeutig zu erkennen, aber einfach in der Umsetzung. (ähnlich wie mein replacelanguage)
Per Javascript beim ersten Aufruf und dann per cookie merken? Hmm, JS wollte man ja nicht.

Bin für weitere Alternativen offen. Was Contao nicht können soll, können meist dann Erweiterungen. ;)

Zitat:

---

Zitat von BugBuster

Wenn Euch die Fallback Lösung per JS für IE<9 nicht gefällt, mal die Frage, was es für Alternativen gäbe?

---

Na ja, ich kann dazu nur sagen, mir gefällt das JS-Fallback halt nicht besonders. :) Wie andere inzwischen darüber denken, weiß ich nicht.

Zitat:

---

Es wäre natürlich cool, würde Contao selbst auf xhtml umschalten, wenn erkannt wird, der anfragende Browser kann kein HTML5.
Bzw. per default xhtml und wenn Browser gut genug, dann auf html5 umschalten.
Und wie würde man das erkennen? Per Agent String?

---

Ja, das wäre cool. Per Useragent String ist halt unzuverlässig.

Doch überlegen wir vielleicht mal, ob das tatsächlich eine reale Einschränkung ist. Ich glaube, wer den ändert, meistens aus experimentellen Gründen und nicht zum gewöhnlichen Surfen. Der "Normalsurfer" tut sowas Ungehöriges eher nicht, warum auch. Zumindest vermute ich, es geschieht um einiges seltener als JS in den Browsereinstellungen zu verbieten. Es wäre ja auch nur in Aufwärtsrichtung kritisch, also wenn bspw. jemand seinen IE6 neuerdings als FF4 ausgibt, statt den einfach zu installieren. Welcher Sinn läge denn darin? Und man muss auch das Umfeld derartiger Manipulationen berücksichtigen ... Entwickler und Webdesigner machen es vielleicht manchmal, selten, und ansonsten vielleicht noch ein paar Kiddies, die ihren Spieltrieb ausleben. In Firmen, Institutionen und bei nahezu 100% der Normalsurfer aber sicher nicht Standard. Daneben auch von niemandem empfohlen, im Unterschied zu den relativ populären Empfehlungen diverser Sicherheitsapostel, Scripting und Cookies zu verbieten.

Den Agentstring ändern, ist auch nicht in allen Browsern ganz einfach. Bei neueren Chrome-Versionen gehts glaub ich in den Einstellungen. Beim Firefox nur per about:config. Ob es im IE9 auch per Browsereinstellung geht, weiß ich nicht. Für ältere Versionen müsste man meines Wissens auf jeden Fall die Registry patchen, und zwar mehrere Werte unter [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Internet Settings\8.0\User Agent\] ändern. Na ja, wer das macht, warum auch immer, der wundert sich bestimmt auch nicht, wenn Webseiten danach noch eigenartiger aussehen als vorher. Und ein paar Experimentierfreudige, die auf Weise mit ihren Mobilgeräten Zugang zu Portalen erhalten wollen, die sie sonst nicht damit erreichen, könnte man wohl ebenfalls vernachlässigen.

So gesehen finde ich Deine Idee unterm Strich sehr interessant. Und ich wäre neugierig, wie andere im Forum darüber denken. Hättest Du auch eine Idee, wie am besten realisieren? Im Core ist das Ding ja nun erstmal gelaufen.

Ohne JS fallback geht's halt nicht. IE 6 - 8 Fendern ohne JS eine Article Element einfach nicht, das JScript macht daraus ein Block Element.

Auf der anderen Seite ist JS für HTML5 essentiell, es geht ja nicht nur um ein paar neue Sematische tags und einem neuen Doctype, eben auch um Local Storage, Canvas und vieles mehr.

Gut man könnte den fallback auch umkehren, mit JS wird HTML5 zugeschaltet, ohne bleibt es halt bei HTML4. Nur will man wegen einen Bruchteil (es sind eben mehr HTML5 fähige Browser unterwegs) so einen aufwand betreiben zu Lasten des serverloads?