Contao goes HTML5 & CSS3

Hallo liebe Entwickler,

so wie es aussieht, werden HTML5 und CSS3 in Contao 2.10 Einzug halten. Für den IE 6 - 8 greifen wird dabei für HTML5 auf das allseits bekannte HTML5 Enabling Script und für CSS3 auf das selectivizr-Skript zurück.

Bislang kommt in Contao XHTML zum Einsatz, wahlweise in der Transitional- oder in der Strict-Variante. Da jedoch, aufgrund der IE-Inkompatibilität, kein echtes XML-Dokument ausgeliefert wird, handelt es sich de facto immer um HTML-Seiten.

Daher nun die Gretchen-Frage: Wie viele von euch haben Contao so angepasst, dass es echte XHTML-Dokumente ausgibt? Lohnt es sich, neben HTML5 auch XHTML für die Ausgabe anzubieten, was einen erheblichen Mehraufwand bei der Entwicklung bedeutet? Oder reicht es, Contao einfach auf HTML5 umzustellen?

XHTML 2 war aufgrund der fehlenden Rückwärtskompatibilität ein gescheitertes Projekt (imho) und XHTML 1.1 ist aufgrund der fehlenden Features keine wirkliche Weiterentwicklung.

Die XML Variante von HTML5 könnte zwar etwas werden, es bringt einige nette Features mit sich, aber ich denke der Core sollte sich auf die normale Variante beschränken und für die Leute die es brauchen, könnte man die XHTML Variante als Extension realisieren...

Guten Morgen,
HTML5 reicht, aus meiner Sicht.

Viele Grüße aus Berlin,
Tim


Sent from my iPhone using Tapatalk

Zitat:

---

Zitat von Tim G

HTML5 reicht, aus meiner Sicht.

---

unterschreib

Seh ich auch so.

Gruß
Nikolas

Soweit ich gelesen habe, ist das XHTML-Markup auch weitestgehend kompatibel zu HTML5 (bis auf z.B. CDATA-Bereiche), so dass eigener HTML-Code und eigene Module durch den Wechsel nicht inkompatibel würden. Oder sehe ich das falsch?

Ich finde auch HTML5 reicht. Vielleicht könntest du auch gleich sowas mit anbieten: http://css3pie.com/

Das hat Felix vor ein paar Tagen schon umgesetz :)

http://www.contao.org/erweiterungsli....10006.de.html

Multiple Backgrounds wären schön, allerdings nicht so leicht umzusetzen?!

Meine Idee mit den div. Ausgabeformaten ist recht einfach.
Mittels Suffix wird vorgegeben, was der Browser sehen moechte.

Standardmaessig ist dies .html welches nativ in einem .tpl endet

Aber man koennte auch ein .json schreiben.
die TemplateKlasse laedt dann halt nicht die .tpl sondern eine .json.tpl (falls vorhanden)
Somit lassen sich mit einer Webseite div. Ausgabemoeglichkeiten einfach regeln, und die Einbindung von Content waere ncoh ein bisschen weiter.

Bei Bedarf kann ich den Patch in den Bugtracker setzen.

Zitat:

---

Zitat von leo

Wie viele von euch haben Contao so angepasst, dass es echte XHTML-Dokumente ausgibt?

---

Den Mime-Type application/xml habe ich bei keinem einzigen Projekt eingesetzt, da es dadurch nur Stress mit gewissen Browsern gab.

Zitat:

---

Zitat von leo

Lohnt es sich, neben HTML5 auch XHTML für die Ausgabe anzubieten, was einen erheblichen Mehraufwand bei der Entwicklung bedeutet? Oder reicht es, Contao einfach auf HTML5 umzustellen?

---

Ich würde den Leuten schon noch erlauben als Doctype XHTML einzustellen, denn nicht jeder will HTML5 einsetzen bzw. die Masse der Leute ist schlicht und einfach noch gar nicht soweit, dass sie HTML5 beherrschen.

Mir persönlich reicht HTML5.

Mehrere Ausgabeformate anzubieten ist halt ein erheblicher Mehraufwand für alle Entwickler. Es muss jedes Template angefasst und mit einer if-else-Lösung ausgestattet werden, um z.B. schließende Tags oder CDATA-Bereiche korrekt darzustellen oder bestimmte HTML5-Tags im XHTML-Dokment auszublenden. Vermutlich müsste man sogar XHTML-Fallback-Lösungen programmieren, was den Quelltext unnötig aufbläht.

Und ich glaube nicht, dass jeder Third-Party-Entwickler so einen Irrsinn mitmacht, also werden wir am Ende auch noch ein Problem mit inkompatiblen Extensions haben.

Es müssen also schon gewichtige Argumente gegen eine generelle Umstellung sprechen.

Hallo Leo,

mir persönlich würde HTML5 reichen, da ich aber immer mal wieder Kunden habe, bei denen ich IE6 nicht aussperren darf, reicht es eben doch nicht.

Viele Grüße
Oliver

Ich bin der Meinung, dass IE6 kein Argument mehr bei dieser Entscheidung sein darf - wir diskutieren hier ja über die Zukunft von Contao :)

Ich bin auch der Meinung, dass HTML(5) ausreicht.
Ich lasse auch das Argument mit dem "Wissensgrad" nicht gelten, Contao richtet sich ja an Fortgeschrittene.

Ich lasse mir die Sache aber nochmal durch den Kopf gehen... :)

Mehrere Schienen gleichzeitig zu fahren, halte ich auch für zu arbeits- und fehlerintensiv - wobei eine Einstellbarkeit der Ausgabe natürlich auch was hat.

Den IE 6 würde ich auch bewusst nicht mehr unterstützen. Je mehr aus der Webdesigner- und Entwicklergemeinde das konsequent tun, desto eher ist er weg. Es baut auch keiner mehr Zweitakt-Autos, die zwar nicht durch die Abgasprüfung kommen, aber so schön knattern :D

Hätte die Umstellung denn nur auf die CDATA-Bereiche Auswirkungen, oder müssten (gerade in den vielen Extensions) noch mehr Dinge verändert werden?

Was "Ausgleichsscripte" angeht, habe ich allerdings eher schlechte Erfahrungen aus dem Kundenkreis gehört ... "ie8.js", und was es da alles gibt.

Ich würde da auch gerne noch etwas recherchieren, bevor ich mir eine abschließende Meinung bilde.

Grüße,

Christian

Zitat:

---

Zitat von Tim G

HTML5 reicht, aus meiner Sicht.

---

Ebenfalls meine Meinung.

Bez. IE6: HTML5 ist ja nicht "von Haus aus" inkompatibel mit dem IE6. Die neuen Markup-Elemente wie <header>, <footer>, <article> etc. können dem IE6 ja beigebracht werden und wie die Extension-Entwickler mit den Features (Canvas, Video, Storage etc.) umgehen, d.h. ob der IE6 unterstützt wird oder nicht kann diesen überlassen werden.

Zusätzlich XHTML anzubieten fände ich ziemlich ungünstig, vor allem da XHTML keinen einzigen Vorteil gegenüber HTML5 bietet.

FAZIT:
Meiner Meinung nach sollte Contao auf HTML5 setzen aber darauf achten, den IE6 zu unterstützen. Was dann die Extension-Entwickler machen soll deren Entscheidung sein.

Selbes gilt übrigens auch für CSS3. Denn ich denke, dass der Contao-Core mit einem gemeinsamen Nenner den auch IE6 versteht aus kommt... könnte aber auch falsch liegen ;)

Ich bilde mir ein, dass ich gelesen habe, dass HTML5 z. B. die endenden /> bei Einzelelementen wie <br /> oder <img /> akzeptiert. Entsprechend dürfte es doch imho kein Problem sein XHTML weiterhin zu unterstützen?

Ich finde es auf jeden Fall deutlich problematisch, wenn man Contao so abändert, dass es ab der 2.10 plötzlich nur noch auf HTML5 setzt. Das ist ein enormer Eingriff, denn es würde alle Bestands-Websites auf Basis von Contao dazu zwingen, dass sie auf HTML5 umgebaut werden müssen. Dabei ist der derzeitige Einsatz von HTML5 in der Webdesigner-Szene durchaus noch umstritten weil es eben schon noch Probleme damit gibt. Wenn wir mit Contao jetzt anfangen die Leute dazu zu zwingen, dass sie auf HTML5 setzen müssen, finde ich das nicht ideal und das falsche Signal.

Soweit halt meine Meinung.

Zitat:

---

Zitat von Nina

Dabei ist der derzeitige Einsatz von HTML5 in der Webdesigner-Szene durchaus noch umstritten weil es eben schon noch Probleme damit gibt.

---

Google setzt bereits seit geraumer Zeit HTML5 ein und scheint damit gut zu fahren. Für den Anfang bestünde die Umstellung ja auch erstmal nur aus dem geänderten DOCTYPE und der Nutzung der neuen Tags (article, section etc.). Diese wenigen grundlegenden Dinge sind auf jeden Fall jetzt schon uneingeschränkt nutzbar - sogar im IE6, den wir aber mit Sicherheit nicht mehr weiter supporten werden. Selbst Microsoft unterstützt den IE6 nicht mehr: http://ie6countdown.com/

Zitat:

---

Zitat von Nina

Ich bilde mir ein, dass ich gelesen habe, dass HTML5 z. B. die endenden /> bei Einzelelementen wie <br /> oder <img /> akzeptiert.

---

Das schon, aber die neuen Tags werden in XHTML nicht unterstützt. Wir müssten also alle Contao-Templates mit if-else-Schleifen ausstatten:

HTML-Code:

---

<?php if($this->isHtml5): ?>
<nav id="mainmenu">
<?php else: ?>
<div id="mainmenu">
<?php endif; ?>

---

Und das muss ja eigentlich nicht sein. Vor allem wenn man bedenkt, dass Contao auch jetzt keine echten XHTML-Dokumente ausgibt, sondern ganz normale HTML-Seiten! Im Prinzip würde sich also nicht viel ändern - sofern nicht doch noch ein "echtes" Gegenargument auftaucht :)

HTML5 ist nicht standardisiert und wird dieses auch nie sein.
HTML5 ist mittlerweile HTML und ein "moving standard". d.h. es wird nur snapshots geben. Wie genau dies aussehen wird, steht noch in den Sternen.

W3C ist jedoch aus der Standardisierung komplett draussen, da deren HTML5 bzw. XHTML basiertes HTML5 von den Herstellern nicht angenommen wurde und sich eine paralelle Arbeitsgruppe gebildet hat. Das nur am Rande.

Den IE6 sollten wir auch in den Unterstytzungsgedanken aussen vor lassen.
Die neuen Tags wie nav usw. sollten i.d.R. auch keine Probleme bereiten, da sie Browser die selbige nicht verstehen doch als block Elemente rendern sollten, was sich mit den bisherigen "div" Tags doch gut vertraegt.

Also HTML5 von meiner Seite aus.

Zitat:

---

Zitat von leo

... Für den Anfang bestünde die Umstellung ja auch erstmal nur aus dem geänderten DOCTYPE und der Nutzung der neuen Tags (article, section etc.) ...

... Das schon, aber die neuen Tags werden in XHTML nicht unterstützt. Wir müssten also alle Contao-Templates mit if-else-Schleifen ausstatten ...

...Und das muss ja eigentlich nicht sein. Vor allem wenn man bedenkt, dass Contao auch jetzt keine echten XHTML-Dokumente ausgibt, sondern ganz normale HTML-Seiten! Im Prinzip würde sich also nicht viel ändern - sofern nicht doch noch ein "echtes" Gegenargument auftaucht :)

---

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.

Jens Meiert hat dankenswerterweise den entsprechenden Vergleichsartikel des WHATWG übersetzt (siehe http://meiert.com/de/publications/tr...html-vs-xhtml/). Streng genommen (siehe auch eine inzwischen existierende Empfehlung des W3C unter http://dev.w3.org/html5/spec/the-xht...html-documents und einige Nebenartikel) müsste man sicvh wohl entscheiden, ob man HTML5 (ohne die entsprechenden XHTML-Syntax-Fragmente) ausgibt oder eben XHTML5 (und sich dann am besten vollständig an XML als Basis halten).

Leo, Du sprichst die Template-Ausgaben an, und triffst damit den Kern des Problems, das Contao hat, indem es leider keine globale Möglichkeit bietet, eine zugeordnerte Bezeichnung eines Elementes wahlfrei innerhalb der vorhandenen Ausgabebereiche als DIV ID oder als HTML5-Strukturelement (im Beispiel 'nav') auszugeben.

Begründet in der Art und Weise, wie das bisher gehandhabt wurde (die groben Richtlinien, als was das Dokument ausgegeben werden soll bestimmt die fe_page mit den Doctype-Modellen HTML, XHTML, den Rest schreiben wir quasi verabredungsgemäß im XHTML-Codestyle in die Templates rein ...) sehe ich persönlich eher Probleme am Horizont, wenn die Seiten zukünftig als <!DOCTYPE html> ausliefern, uns andererseits darauf verlassen, dass die Browser sich schon nicht dran verschlucken werden, wenn hintendran ein Rattenschwanz an Ausgaben als XHTML-1 erfolgen.

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.

Entwickler, die ihre Extensions im Bereich der Ausgabe von HTML5 berücksichtigt wissen wollen, müssten ein oder mehrere zusätzliche Templates zur Verfügung stellen, die dann statt den hardgecodeten echo->this styles die Mapping-Funktion von weiter oben aufrufen müssten. Scheint mir schaffbar.

Obendrein - und jetzt sehe ich einen wirklichen Vorteil des themes / templates-Konzepts - wäre es jedem relativ einfach möglich, diese Anpassung auf Template-Ebene durch Ablage eines eigenen Templates selbst durchzuführen, sollte eine Extension beispielsweise verwaist sein und nicht um die neuen Möglichkeiten vom Entwickler ergänzt werden.

Mein persönliches Fazit, mein Plädoyer dafür, es etwas grundsätzlicher anzugehen. Ich kenne die Roadmap für Contao 3 nicht, vielleicht mache ich mir um Dinge einen Kopf die schon längst skizziert sind - aber ich bin dagegen, jetzt HTML5 mal eben auf die schnelle nachzurüsten, ohne ein grundständiges Designproblem zu lösen.

Carolina.

1. HTML5 ist einfach gesagt nicht fertig und um das Beispiel mit dem Auto wieder hervorzurufen, ich fahre lieber mit einem alten klapprigen Auto, als mit einem das nicht fertig ist!
2. In jeder Firma in der ich bis jetzt gearbeitet habe, war der IE6 Standart. Auch aktuell. Ohne Adminrechte können die MA auch nie updaten und XP reicht für die meisten Firmen noch einige Jahre...
3. Ich möchte die Anwender sehen, die gerade mit HTML und CSS anfangen und jetzt noch JS lernen dürfen...bzgl. die JS-Frameworks die in diesem Thread genannt wurden.
4. Meiner Meinung nach wird "HTML5" wieder einmal von den großen überrannt werden und bleibt dann ein schönes "Framework" für IPhone und andere kommerzielle Entwickler, damit sie ihre runden Ecken kriegen :p
5. Wenn man schon mal vor so einem Schritt steht, sollte man den Entwicklungsaufwand nicht scheuen - schließlich wird es nicht das letze mal sein, dass wir vor so einer Entscheidung stehen und dann lohnt es sich spätestens! Wirklich eine sehr seltsame Frage ob es sich lohnt noch XHTML anzubieten. Ich für meinen Teil würde von einem Projekt wie Contao sofort abspringen wenn hier in Zukunft auf Spielereien gesetzt wird - die können sich die Coder nämlich wirklich selbst einbauen, wenn sie unbedingt runde Ecken brauchen und nicht einmal die nötigen Divs dafür hin coden können um sie auch mit normalem HTML zu bekommen.
6. Der IE6 ist nicht ansatzweise Tod - er war ein ganz großer Fehler aber dieser befindet sich nun in 75% aller Unternehmen und MS wird auch mit getürkten Statistiken nicht erreichen, dass prof. Webdesigner ihren Kunden gegenüber behaupten, man müsse eine Website nicht mehr für den IE6 optimieren. Ich jedenfalls werde frühstens wenn der WC3 das HTML5-Ding abgesegnet hat darüber nachdenken, aber ganz bestimmt nicht solange hier Workgroups von Apple,Google und MS den die Fäden in der Hand halten...

Ich nehme auf den IE6 keine Rücksicht. Er ist vielleicht weit verbreitet, aber das muss irgendwann mal aufhören. Eine Status Nachricht sagt dem Nutzer, der Browser sei 10 Jahre alt, er sollte bitte Updaten - sonst kann er die Seiten nicht richtig sehen.

Wenn das alle machen würden ... :D

Aber IE6 ist ja auch gar nicht das Thema... HTML5 ist das Thema.

Bitte lasst hier die IE6-Diskussionen sein oder lagert sie in eine der schon bestehenden Threads zum Thema aus. Die Frage der IE6-Unterstützung stellt sich schon lange nicht mehr für das Contao-Team ... und jeder der meint, er müsse ihn unterstützen, kann das so oder so tun (Contao-Anpassbarkeit sei Dank).

Hier geht es ausschließlich um HTML5 (CSS3 ist imho nichts was man diskutieren müsste ;)).

Angenommen jemand möchte einen schönen neuen Privatjet kaufen und sich online darüber informieren. Nun kommt er auf eine Website mit einem schönen Balken und einer Warnmeldung und darunter ist alles zerstückelt...auch ein Klick auf den Link in der Warnmeldung bringt den potenziellen Kunden nicht weiter, da sein Admin, wie 90% aller Admins den Benutzer nichts installieren lässt - also auch keine Updates. Geprägt von dem schlechten Eindruck der Website und der einzigen, nicht funktionierenden Lösung(!) wechselt der Kunde zur Konkurenz - die sich weniger Sorgen um die neuste (unfertige) HTML5 technologie gemacht hat - dafür aber professionelle Entwickler einsetzt, die selbstverständlich auch die Bugs des IE6 beherschen. Wer einfach sagt, der IE6 ist so alt, den unterstütze ich einfach nicht, der braucht sich auch keine Gedanken über SEO machen, den der Kunde wird keine 3 Sek auf der Seite bleiben...
Mein Fazit: HTML5 gerne aber Abwärtskompatiblität ist ein MUSS!!! UND XHTML ist immer noch Standart! Außerdem, wie gesagt, sollte das ganze langfristig Modular aufgebaut werden, auch wenn es jetzt mehr Arbeit bedeutet, den die Entwicklung wird ganz bestimmt nicht langsamer!

Zitat:

---

Zitat von Toflar

Ich bin der Meinung, dass IE6 kein Argument mehr bei dieser Entscheidung sein darf - wir diskutieren hier ja über die Zukunft von Contao :)

Ich bin auch der Meinung, dass HTML(5) ausreicht.

---

HTML(5) versteht auch bisherige HTML-Dokumente. Einige Elemente sind für den ie6 z.B. nicht benutzbar, aber diese kann dann der Entwickler, der auf den ie6 achten muss in den Templates getauscht werden. Das sollte also kein großes Problem sein. Und das HTML(5) nicht fertig sei... wie schon erwähnt wird es mit dem ersten Snapshot zum moving standart und der sollte im Sommer kommen. Da würde das mit dem Releasetermin von Contao 2.10 vielleicht ganz gut zusammenlaufen.

Oder irre ich gänzlich?

Und @contao1234 du solltest dir mal anschauen was HTML5 überhaupt ist, weil das hat rein garnichts mit runden Ecken zu tun (was du ja mehrfach erwähnst). Wie gesagt soweit ich das verstehe ist HTML5 an sich zu 100% abwärtskompatibel wenn man trotzdem auf <div> elemente statt <header> etc. verwendet.

Grüße
psren

Den Ausführungen von Lucina kann ich nur voll und ganz zustimmen. Desweiteren finde ich es sehr - äh -mutig, sich zukünftig wie im ersten Post erwähnt auf Javascipt - sprich das HTML5-Enabling- und das selectivizr-Skript - zu verlassen. Da ist der Ärger ja gleich vorprogrammiert.

Ich werde diesen Thread erstmal beobachten und dann entscheiden, ob es überhaupt noch sinnvoll ist, mit Contao weiterzuarbeiten.

Da wurden hier im Thread ja wieder ein paar sehr alte Kisten ausgepackt ;) … um mal sachlich zu bleiben:

• HTML5 hat nichts, aber auch gar nichts mit runden Ecken, fancy Effekten oder all-things-js-framework zu tun.
• <!DOCTYPE html> ist allgemeingültig und abwärtskompatibel zu allen (X)HTML-Versionen – dieser riesige Rattenschwanz an Zusatzinformationen wird von Browsern eh prinzipiell ignoriert und hilft auch nicht wirklich bei der Entscheidung zwischen XML- oder (ehemals) SGML-Parser (das geht eher über den MIME-Type, der korrekte für die XML-Variante ist übrigens application/xhtml+xml). Das heißt auch, dass man technisch "HTML5" schreien kann, hinterher aber "nur" (X)HTML4 kommt, und es kommt das "richtige" Ergebnis raus – HTML5 ist viel viel mehr als nur ein paar neue Tags und natives Video/Audio.
• Theoretisch kann man (natürlich auf Kosten der Validität) beliebig Tags erfinden und im HTML-Dokument einbauen – der IE verschluckt sich halt leider mit einem Rendering-Fehler, was die Nutzung in IE<9 (ohne JS-Helper) so ziemlich unmöglich macht (mehr siehe unten).
• HTML5 wird nicht "standartisiert" sein, bevor eine breite und vollständige Implementierung vorhanden ist – was bei HTML4 bis heute nicht geschehen ist. Also braucht man eigentlich auch nicht darauf warten. HTML5 ist heute – mit gewissen Einschränkungen – einsetzbar und auch einzusetzen!
• HTML5 ist nicht fertig. Aber die Bereiche, in denen noch gewerkelt wird, sind für die meisten Websites nicht relevant. Da geht es meist um DOM-Interpretationen oder (noch) exotische Elemente wie <device> usw., und alle aktuellen Browser kommen mit HTML5, wie es zu 99% eingesetzt wird, problemlos zurecht.
• Das nur am Rande: Das W3C hat mit XHTML2 zu technisch (jedoch nicht grundlegend falsch) gedacht, worauf "keine Lust" hatten und somit das WHATWG gründeten, das HTML5 ersann. Schon vor Jahren aber hat das W3C die Vorschläge des WHATWG übernommen und nun entwickeln beide Konsortien gemeinsam am neuen Standard (die Arbeitsdokumente sind auch inhaltlich nahezu identisch, das WHATWG hat einen etwas anderen Schreibstil, und macht oft auch weitergehende Vorschläge, deren Umsetzung aber in den Sternen steht). Das W3C hat somit immernoch (oder wieder?) die "Autorität", die es vorher hatte.
• Der wunderbare Chrome Frame kann jetzt auch ohne Administrator-Privilegien installiert werden ;).

Meine Meinung zur Änderung der Contao-Ausgabe als HTML5:
Generell begrüße ich diese Roadmap sehr. Aber: IMO ist es in 2.x nicht mehr möglich, komplett die Ausgabe zu ändern.

Sonst würden viel zu viele bei 2.9 bleiben, was sicherlich als letztes gewünscht ist (ich weiß, "Update" auf HTML5 sollte generell kein Problem sein, aber davor würden ohne refactoring zu Viele zurückschrecken, ich wahrscheinlich eingeschlossen, und ein refactoring verbraucht kostbare Zeit und will obendrein bezahlt sein). Neue Projekte würde ich sofort mit HTML5 umsetzen, egal, mit welchem Schrott Leute meine Seite besuchen wollen, aber bestehende Projekte würde ich nur widerwillig anfassen (warum auch, sie funktionieren prima) – das muss aber jeder für sich selbst entscheiden.

Ja, man kann alten Browsern (aka IE <9) HTML5 beibringen. Das Problem ist, dass die Seite ohne JS mehr als zerschossen sein wird (zumindest IE 6, meines Wissens alle <9, bastelt aus unbekannten Elementen z. B. sowas wie <article/>…</article/>, somit würde ein Container wegfallen und ein neu angesetztes Block-Styling verpuffen), wenn der Browser nicht aktuell ist. Ich kenn zwar keine aktuelle Statistik, die den IE 6 über 5% zeigt (außer in manchen Entwicklungsländern, aber das ist nicht meine Zielgruppe), aber leider gibt es noch andere "unfähige" Versionen, und der IE 9 ist leider nicht für XP verfügbar, und XP bleibt ein Problem.


Die Lösung, die ich mir für Contao 2.10 (bzw. 2.x) vorstelle (Begründung siehe oben):

• XHTML1 bleibt vollständig erhalten!
• (X)HTML5 kann optional gewählt werden, möglicherweise auch als Standard bei neuen Installationen (ich würde sogar auf Grund der Abwärtskompatibilität XHTML5 wählen und auch automatisch den korrekten MIME-Type außer für IE<9 senden).
• (X)HTML5 wird über optionale Templates z. B. mit der Endung 'tpl5' zur Verfügung gestellt, Fallback ist die bisherige 'tpl' (insbesondere deswegen XHTML5 wählen! – so ist die Lösung auch vollständig abwärtskompatibel!).

Contao 3 soll dann XHTML1 komplett streichen.

@FloB : du hast meine vollste Zustimmung !!!

Aber den Vorschlag mit unterschiedliche tpl zu arbeiten, wurde quasi schon abgelehnt (#10)
es ist aber nach wie vor die meiner Meinung effizienteste Loesung. Und nicht das fixe in Code zementieren, wie es in der 2.10 passiert ist.

Ich stehe total hinter dem was lucina und FloB geschrieben haben.
Ich halte es für falsch alle Brücken abzubrechen und den Leuten vorzuschreiben, das man nun mit Contao HTML(5) nutzen sollte. Ich bin zwar jemand der eh viele Templates anpasst, aber das wird dann durchaus überhand nehmen.

Viele Grüße

Nach einiger Recherche und den vielen guten Beiträgen hier kann ich auch FloB, Lucina und ein paar anderen nur zustimmen:

HTML5 ja, aber nicht sofort und nicht über's Knie gebrochen.

Bestehende Projekte will ich auch nicht anfassen müssen - bzw. die Kunden überzeugen müssen, Geld auszugeben. Und wie gesagt: Javascript-Fallbacks halte ich für sehr gewagt bis hochspekulativ.

Es rennt uns ja nicht weg. Was spricht dagegen, erst ein schlüssiges Umsteigekonzept zu machen und das danach anzugehen?

Eigentlich ein prima Thema für eine Devcon 2011 ...

Zitat:

---

Zitat von FloB

Aber: IMO ist es in 2.x nicht mehr möglich, komplett die Ausgabe zu ändern.

---

Wieso nicht? Es ändert sich doch erstmal gar nichts außer dem DOCTYPE. Und faktisch ändert sich dadurch überhaupt nichts, denn wie gesagt stand bisher zwar "XHTML" drüber, aber aufgrund des fehlenden XML-Tags und XML-Headers hat es in Contao schon immer nur HTML-Seiten gegeben!

Wirf doch mal einen Blick auf den aktuellen 2.10-Trunk. Dort werden bereits valide HTML5-Seiten generiert, obwohl sich bisher nur der DOCTYPE geändert hat. Die XHTML-Syntax der Templates ist 100% kompatibel und ganz ehrlich gesagt schadet es meiner Meinung nach nicht, wenn man auch in HTML5 alleinstehende Tags weiterhin nach XHTML-Schema schließt (z.B. <img /> statt <img>).

Insofern ist die Umstellung bisher vollständig abwärtskompatibel!

Hallo leo,
na, da sieht die Sache ja schon wieder etwas anders aus. HTML(5) ist ja durch ein paar Dinge mehr gekennzeichnet, als nur den DOCTYPE. Nur mit einem anderen DOCTYPE kann man/ich leben.
Sorgen bereiten da ja eher die speziellen Tags, die neu hinzugekommen sind.

Nützlich wäre es eventuell eine Notation zu empfehlen, wie Tags auch schließen etc. und Listen nicht einfach so auszuwerfen (auch wenn es stimmt):

Code:

---

<ul>
<li>listenelement
<li>listenelement
</ul>

---

Viele Grüße

Zitat:

---

Zitat von MacKP

Sorgen bereiten da ja eher die speziellen Tags, die neu hinzugekommen sind.

---

Für den Anfang würden wir nur die semantischen Tags (section, article, nav, side etc.) verwenden, die Dank html5.js auch im IE 6-8 funktionieren. Audio und Video, Canvas oder Drag&Drop sind sicherlich noch nicht so weit, dass man sie produktiv verwenden könnte.

Statt <div id="main"> steht dann z.B. <section id="main">, was ebenfalls zu 100% abwärtskompatibel ist, da die Referenzen in den Stylesheets nach wie vor richtig zugewiesen werden (es sei denn, jemand hat explizit div#main als Selektor verwendet, was im Core jedoch nicht der Fall ist).

Bezüglich der Notation bin ich vollkommen Deiner Meinung. XHTML hat in diesem Bereich den richtigen Weg gewiesen: alle Tags gehören sauber geschlossen, wodurch sich die Lesbarkeit und Kompatibilität, sowohl mit Browsern aber auch mit IDEs, erhöhen. Von diesem "Standard" würde ich so oder so nicht abweichen wollen.

Zitat:

---

Zitat von leo

Für den Anfang würden wir nur die semantischen Tags (section, article, nav, side etc.) verwenden, die Dank html5.js auch im IE 6-8 funktionieren.

---

Und genau der Teil bereitet mir (und manch anderen wie ich das lese) Bauchschmerzen.
Nur mit JS Probleme Lösen ist nicht der Weg den ich für Sinnvoll empfinde.

Viele Grüße

Zitat:

---

Zitat von MacKP

Und genau der Teil bereitet mir (und manch anderen wie ich das lese) Bauchschmerzen.
Nur mit JS Probleme Lösen ist nicht der Weg den ich für Sinnvoll empfinde.

Viele Grüße

---

Auch mir bereitet das Bauchschmerzen. Einerseits werben wir das wir dank Contao noch schneller und effizienter barrierefreie Websites erstellen können und dann bauen wir Tags ein die nur via JS unterstützt werden?

Ich bin ja ein großer Verfechter des HTML5 und würde gerne nur noch diese Spezifikation verwenden aber mich auf ein zusätzliches JS Script zu verlassen - bitte nicht. Ein Tag nach dem Update höre ich schon das Telefon läuten - warum sieht unsere Seite ohne JS so doof aus ;)

Mit runden Ecken meinte ich auch einfach die Tatsache, dass in meinen Augen 90% in HTML5 Spielereien sind, die in einem Produktivsystem noch nichts zu suchen haben.

Native Videos bzw. Medien wird es nie geben, dafür werden die großen schon sorgen...also wozu überhaupt HTML5 wenn es wieder kein Standart wird sondern ein "moving" in alle Richtungen...das sollte erstmal geklärt werden, bevor man auf einen Zug ins Nirvana aufspringt und dabei noch 75% der Besucher ausschließt.

Meine Websites sind bis IE5 nur durch HTML und CSS 99% Crossbrowserkompatibel und das ist es auch was einen Webdesigner aus macht, sonst könnte ich mir ja auch alles von Photoshop generieren lassen...und jetzt soll ich auf diverse Javascripts umrüsten, weil da ein paar sections im Code stehen, die ich niemals brauchen werde !?!

Also HTML5 gerne für wen und was auch immer aber auf keinen Fall als Standart in Contao - wenn dann extra aktivieren oder durch Extensions bzw. tpls usw. Glaubt mir, es ist viel zu früh !

Ich finde die Abwärtskompatiblität durch JS oder ein im Ansatz vielleicht garnicht so doofes Google Chrome Frame ist eine Belastung, die man vielleicht ein paar Bauern verkaufen kann aber nicht zahlenden Kunden. Dann lernt lieber Webdesign!

PS: Ich bin Sys-Admin in einer relativ großen Firma und wurde soeben angerufen, weil da jemand ein Update nicht installieren kann...mal sehn was es diesmal ist, aber ich könnte wetten - es fängt mit Java... an. Und ich glaube diesen 5% Statistiken einfach nicht - in jeder Firma, die nicht gerade mit Medien arbeitet, läuft XP und zwar ohne Adminrechte für Benutzer und 75% mit IE6, da wett ich meine Oma drauf leuts...Kann mir übrigens mal jemand erklären worauf diese Statistiken beruhen? Etwa auf 10000 laufende Server die ständig ausgewertet werden - Supi - dat wären dann 0,0000111%...Ach egal - HTML5 als Standart in Contao und ich bin weg, entschuldigt meine etwas aufgeregte Schreibweise aber ich hatte mich gerade in Contao eingearbeitet und wär echt nicht daran interessiert wegen sonem...wieder wechseln zu müssen...

Naja, wenn ich mir http://caniuse.com/#cats=HTML5&sort=score mal anschaue, dann finde ich die wenigsten Dinge dort Spielerei.

Die 'runden Ecken' haben mit HTML5 nichts zu tun, dass wäre dann CSS3.

Zu Browserstatistiken schau doch bitte mal auf http://www.w3schools.com/browsers/browsers_stats.asp oder http://gs.statcounter.com/#browser_v...-201003-201103.

Zitat:

---

Zitat von conta1234

Meine Websites sind bis IE5 nur durch HTML und CSS 99% Crossbrowserkompatibel und das ist es auch was einen Webdesigner aus macht, sonst könnte ich mir ja auch alles von Photoshop generieren lassen..

---

Ich glaube, das die wenigsten hier den Einsatz von HTML5 ablehnen - es geht doch eher um die Art und Weise der Implementierung. Ich bin mir jedenfalls sicher, dass jede und jeder hier in dieser Diskussion durchaus in der Lage ist, jenseits von Photoshop-Slices sauberen Code zu erstellen. Von daher ...

Zitat:

---

Zitat von conta1234

Ich finde die Abwärtskompatiblität durch JS oder ein im Ansatz vielleicht garnicht so doofes Google Chrome Frame ist eine Belastung, die man vielleicht ein paar Bauern verkaufen kann aber nicht zahlenden Kunden. Dann lernt lieber Webdesign!

---

Siehe oben. Sei Dir sicher, dass es unser aller Bestreben ist, auf solche Krücken zu verzichten. Auch im Sinne unserer Kunden. Das ich dafür erstmal Webdesign lernen sollte halte ich für ein Gerücht.

Die Kompatibilitätsscripte machenmir allerdings ebenfalls Bauchschmerzen.

Also: mal die Kirche im Dorf lassen und sachlich diskutieren, das wünsche ich mir an dieser Stelle.

Carolina.

Geb ich auch mal meine Senf dazu:

Ich finde die Idee mit HTML5 ziemlich gut, wenn Sie in die richtige Richtung geht, und zwar wie lindesbs sagte: Mit unterschiedlichen Ausgabeformaten.
Standardmäßig würde ich zumindest bei XHTML1.1 bleiben... noch eine Weile.

Generell ist HTML5 schon an manchen Stellen ziemlich verbockt wurden...
Schon alleine:

Code:

---

<!DOCTYPE html>
<html>
...

---

... ist totaler Quark - semantisch betrachtet. Ein "Doctype" gibt es in XML/SGML nur in Verbindung mit einer DTD, die durch eine System ID gekennzeichnet wird (und die gegebenfalls mit der Public ID einen Hinweis zur Auffindung der Definition bekommt). (Kann sein das ich die IDs grad vertausche)
Also sagt "<!DOCTYPE html>" soviel wie "Ich hab hier ein html-Dokument, zu dem ich jedoch keine Definitions-ID liefern kann, weil es vermutlich nicht mal eine gibt". Genau das gleiche sagt aber auch ein alleiniges root-html-Element aus. Abgesehen davon, würd ich sofort in der Zeit zurückreisen und alle Spuren von DTDs in der XML Spec löschen. XMLSchema integriert sich viel mehr in den XML-Stil und Schematron setzt noch einen drauf und ist im Prinzip nur eine Anwendung der verschiedenen XML-Standards und kann alles das, was alle anderen Schemasprachen zusammen können.
Validität nach DTDs oder schlechten Schemata sollte kein Kriterium für das Ausliefern von Dokumenten sein... Es sei denn man liefert es an uralt Software aus.
Wohlgeformtheit ist ein viel wichtigeres Kriterium und hier bietet HTML5 mit XHTML5 eine XML-Sprache an, die ich auf jeden Fall der "ich hab kein bock das tag zu schließen" syntax vorziehen würde.
Also, wenn keine unterschiedlichen Ausgabeformate zugelassen sind, dann bin ich entweder XHTML5 oder XHTML1.1


Generell muss ich sagen das mir die derzeigtigen Funktionen der "Themes" in Contao nicht so wirklich gefallen. Das einzige Problem was ich damit löse - das jedoch eher umständlich - ist, wenn ich zB 2 unterschiedliche Paginations brauche.

Hier könnte man sich so eine Art "Template-Set" überlegen (was man auch vererben kann, etc. blabliblub), welches vollkommen orthogonal zu den Layouts läuft und auch separat in den Seiten (ähnlich wie Layouts) vergeben werden können.

Damit wäre es dann auch kein Problem ein HTML5, XHTML5, HTML4, XHTML1.1 or whatever Template-Set zu haben, welches ein Entsprechendes Format ausliefert. Was die Extension-Entwickler dann mitliefern, liegt in eigenem Interesse (aehnlich wie bei den Uebersetzungen).
Man könnte sich dann auch überlegen, eine Art "Output-Ruleset" zu haben, welches abhängig vom Request (zum bsp. UA-Header) ein entsprechendes Template-Set auswählt.

So TLDR: XHTML5: ja, HTML5: nein, XHTML5 als alleiniges Ausgabeformat: nein, mehrere Ausgabeformate: ja

Kommt schon, Leute! Es geht ja wirklich nur um den Doctype und ein paar Tags, welche man im Notfall durch normale DIVs ersetzen kann. Ich sehe nicht wo das Problem liegt.

Dass IE6-User benachteiligt werden ist meiner Meinung nach in der heutigen Zeit kaum unumgehbar. Benachteiligt heisst ja nicht, dass die entsprechenden User Contao-Websites nicht mehr benutzen können, es wird einfach ein zusätzliches JavaScript-File eingebunden.

Also wir wären weiterhin schön barrierefrei und clean ;-) Ausser für IE6-User, welche JavaScript nicht aktiviert haben, aber die werden bei 90% der Websites so oder so aussen vor gelassen (Gibt ja z.B praktisch keine rein CSS basierten Navigationen mehr).

Was ich noch vergessen habe:
Ich bin gegen JS-Frameworks, welche erstmal die komplette Seite "durch den Wolf drehen" und irgendwie solange auf dem DOM drauf rumreiten, bis Sie in inkompatiblen Browsern passt.
Hier sollte wirklich eine Serverseitige Lösung (sprich unterschiedliche Ausgabeformate) her.

Zitat:

---

Zitat von dave.matter

Also wir wären weiterhin schön barrierefrei und clean ;-) Ausser für IE6-User, welche JavaScript nicht aktiviert haben, aber die werden bei 90% der Websites so oder so aussen vor gelassen (Gibt ja z.B praktisch keine rein CSS basierten Navigationen mehr).

---

< 9, nicht 6 - 6 ist irrelevant, wie vom Contao-Team schon deutlich gesagt. Und das mit den CSS-Navigationen würde ich auch nicht gerade unterschreiben...

Eine Seite, die ohne Javascript nicht wackelt, ajaxt, tooltippt oder sonstigen Eye-candy hat, ist ok. Aber sie muss ohne Javascript bedienbar sein, und zwar mit jedem halbwegs modernen Browser.

Zitat:

---

Zitat von christian

Eine Seite, die ohne Javascript nicht wackelt, ajaxt, tooltippt oder sonstigen Eye-candy hat, ist ok. Aber sie muss ohne Javascript bedienbar sein, und zwar mit jedem halbwegs modernen Browser.

---

Schon allein da, spalten sich die Geister :(

Bei manchen Funktionen (ich rede grad net von Eye-candy, wo man egtl immer nen brauchbares fallback finden kann), brauch man einfach JS oder die Funktion wird einfach scheiße.
Allgemein kann man viele integrale Kanten und Ecken mit JS rundschleifen, sofern man sich grad dran stößt.

Zitat:

---

Zitat von leo

Wieso nicht? Es ändert sich doch erstmal gar nichts außer dem DOCTYPE. Und faktisch ändert sich dadurch überhaupt nichts, denn wie gesagt stand bisher zwar "XHTML" drüber, aber aufgrund des fehlenden XML-Tags und XML-Headers hat es in Contao schon immer nur HTML-Seiten gegeben!

---

Der "HTML-5-DOCTYPE" macht aus einem HTML-Dokument nicht einfach ein HTML5-Dokument. Wie gesagt, und wie auch von Anderen erneut erwähnt, besagt dieser DOCTYPE nichts anderes, als dass hier HTML folgt, Version unbekannt. Das kannst du gerne machen, HTML5 wurde ja auch extra so angelegt (sprich der DOCTYPE so gewählt), dass es abwärtskompatibel ist (also sich Browser an dem "neuen" DOCTYPE nicht verschlucken und in den Quirks-Modus wechseln). Aber:

Zitat:

---

Zitat von leo

Insofern ist die Umstellung bisher vollständig abwärtskompatibel!

---

Die Umstellung ist in dem Moment nicht mehr abwärtskompatibel, ab dem die neuen syntaktischen HTML5-Tags verwendet werden. Und zwar nicht, weil es HTML5 ist, sondern weil IE<9 leider nicht damit zurechtkommt. Es geht nur (ohne JS), wenn man diesen noch als Fallback "alten" Code unterjubelt, z. B. so:

HTML-Code:

---

<div class="section" id="main-wrapper">
<section id="main">
[…]
</section>
</div>

---

Aber das gibt wieder nur Code-Salat (auch wenn man das ganze noch in Conditional Comments packt und IDs angleicht). Aber ich denke, dass viele auf ein sauberes non-JS-Fallback (also IE<9-Besucher müssen die Seite problemlos nutzen können) bestehen – und das ist leider mit deinem Vorhaben, Leo, nicht (zumindest nicht ohne massive Mehrarbeit seitens der Administratoren) vereinbar.

Ich bleibe dabei: Eine komplette Umstellung (d. h. Einführung der HTML5-Tags ohne die aktuelle XHTML1-Variante beizubehalten) halte ich für bestehende Projekte nicht durchsetzbar, und für neue muss zunächst die Zielgruppe untersucht werden (denn, wie conta1234 zumindest einmal richtig anmerkt: Zu viele große Firmen sind noch mit XP und somit IE<9 unterwegs). Gegen den "HTML-5-DOCTYPE" habe ich aber absolut nichts einzuwenden. Und bitte XHTML5 mit (automatisch) richtigem MIME-Type (außer wieder für IE<9).

IE 6 ist und bleibt irrelevant, IMO auch IE 7, aber Version 8 leider nicht.

Edit: Das Backend kann meines Erachtens gerne die neuen HTML5-Tags verwenden, ich würde mal behaupten, dass man bei diesen Nutzern einen stets aktuellen Browser und auch aktiviertes JS voraussetzen kann.


@conta1234: Versteh das bitte nicht böse oder als herablassend: Deine Argumente sind großteils nicht grundlegend falsch, aber fast alle hier nicht angebracht. Ich bitte darum, dass du dich mit der Materie (syntaktische ”Programmierung", HTML5, DOM, Browser-Rendering, XML, CSS3, [maschinelle] Code-Interpretation, …) mehr beschäftigst (und das ist leider nicht in wenigen Stunden oder Tagen getan), bevor du hier dazu deine Meinung preisgibst. Und hier den Diskutierenden vorzuwerfen, sie könnten nicht "webdesign", ist (abgesehn von der falschen Wortwahl) nicht nur unangebracht, sondern auch frech.


Bez. "eye-candy" und "pur CSS Menüs": Zauberwort "progressive enhancement". Alles funktioniert prima auch in älteren Browsern (und sieht auch weder falsch noch unpassend aus), je aktueller der Browser, desto "hübscher" die Ansicht. Und dafür braucht man keinen Schnipsel JS. Selbst einen Fade würde ich heutzutage nur mit CSS-Transitions umsetzen wollen (gut, das will der Kunde öfters leider nicht …). Und welche essentiellen Funktionen sind ohne JS nicht "sauber" umsetzbar?
Aber vllt. sollten wir das lassen, gehört nicht zum Thema.

Kann man den doctype nicht ganz wegkicken bei HTML5 und mit application/xhtml+xml schicken. Oder wechseln die browser dann trotzdem in den quirks? Hat zwar jetzt nicht direkt was mit dem für oder wieder zu tun, aber "<!DOCTYPE html>" ist kein wohlgeformtes XML (da system id fehlt; korrigiert mich wenn ich falsch liege; wahrscheinlich verwechsel ich die IDs grad wieder), also auch kein XHTML5.

Die ganze Sache würde sich mit den von lindesbs vorgeschlagenen ausgeben von verschiedenen "views" komplett erledigen. (über die umsetzung dieser multi views kann man sich sicher streiten). BTW: was übrigens gleich noch mit in den multi view bereich fällt: das server caching von Contao noch etwas aufzubohren, sodass eine gecachte seite gar nicht mehr über php ausgegeben werden muss, sondern direkt mit mod_rewrite auf den cachefile gemappt wird.

Also eine Lösung bei der man das Ausgabeformat selbst wählen kann und abhängig von der Auswahl dann eine andere Templateendung gewählt wird fände ich perfekt.
Die verschiedenen Endungen wie .html5.tpl oder nur .tpl müssen ja nicht im Core mitgeliefert werden nur eine Möglichkeit wäre schön.

Jap - wenn es um sowas geht werde ich auch frech :D

Die Statistiken eurer wunderbaren Browserstatistikseiten berufen sich auf ca. 3 Mio Websites die durchgehend gescannt werden. Sehr schön... Wenn ich bei Google www eingeben bekomme ich 25.270.000.000 Ergebnisse...und das sind nur die mit www xD soll ich noch weiter machen? Ich halte es für höchst unprofessionell sich auf solche Statistiken zu berufen und was OS angeht, Windows XP erreicht trotz des allgemeinen Verkaufsstopps im Dezember 2008 einen Marktanteil von 48 % und ist damit weiter verbreitet als Windows Vista mit 14 % und Windows 7 mit 30 % (Stand: März 2011). Viele davon auf IE6 setzen möchte ich garnicht wissen, aber ich weiß zumindest wie viel möglich wären und das sagt mir genug. Zum Thema <9 kann ich nur sagen dass es den IE9 auf XP garnicht gibt/geben wird ;)
Und der Quirksmode ist ein NoGo für mich, die Gründe dafür kann euch FloB erklären - ich hab ja keine Ahnung auch auch keine Lust mehr...JS als Basis für "normales" rendering geht ebenfalls garnicht und vor allem auch anders. Und für alle die sich irgendwie angegriffen gefühlt haben: Ich habe doch garnichts gegen HTML5 - Ich sage lediglich das ich es unmöglich finde, ohne Abwärtskompatiblität bzw. modularen Aufbau -> Templates usw. in dieser Sache vorzugehen! Für einen 100%igen Umstieg ist es meiner Meinung nach viel zu früh! Tut mir leid wenn sich jemand angegriffen gefühlt hat. Ich finde Leos Idee an sich sehr gut und die Entwicklung wird dadurch natürlich im Interesse aller nach vorn gebracht aber wie gesagt - nicht ohne .tpl5 :p

Zitat:

---

Zitat von jared

und dann bauen wir Tags ein die nur via JS unterstützt werden?

---

Das JS-Fallback wird doch nur für den IE 6-8 benötigt. Alle anderen Browser kommen sehr gut mit den neuen Tags klar. Und ganz ehrlich: Der IE, speziell die Version 6, kommt heutzutage doch sowieso nicht ohne CSS-Hacks und JavaScript-Krücken aus. Was macht da ein Skript mehr für einen Unterschied?

Ich hatte früher mal einen alten VW Käfer, bei dem man beim Tanken immer Bleizusatz hinzugeben musste. Die ganzen neuen Autos kamen mit bleifreiem Benzin prima zurecht, deswegen gab es an der Tankstelle auch nur noch solches. Weil ich aber ein veraltetes Modell fahren wollte, musste ich mir den Zusatz besorgen.

Warum erzähle ich das? Der VW Käfer ist der IE6, das bleifreie Benzin der HTML5-Standard und der Bleizusatz das html5.js-Skript. Wer unbedingt mit einem veralteten Browser-Modell unterwegs sein möchte, muss damit rechnen, dass Software irgendwann inkompatibel wird. Dies lässt sich dann eben nur über bestimmte Hilfsmittel wie den Bleizusatz bzw. das html5.js-Skript abfangen. Man kann nicht erwarten, dass die Tankstellen (Software-Hersteller) für immer und ewig bleihaltiges Benzin vorhalten, während der Rest der Welt schon im Elektroauto fährt!

Und der Vollständigkeit halber noch mal der Hinweis: Selbst Microsoft möchte, dass der IE6 vom Markt verschwindet! http://ie6countdown.com/

Zitat:

---

Zitat von leo

Das JS-Fallback wird doch nur für den IE 6-8 benötigt. Alle anderen Browser kommen sehr gut mit den neuen Tags klar.

---

Hallo leo,
hier geht es eben nicht nur um den IE6.
Ich schau immer noch, das es unter dieser Version funktioniert. Die Diskusion können wir uns aber sparen. Das findet ja eh kein Ende (jeder hat da seine Meinung und bleibt anscheinend auch dabei).
IE7 und erst recht IE8 bekommen dann das passende nur mit JS. Das ist der Punkt über den Diskutiert werden sollte.
Genau da fängt es dann an ungemütlich zu werden.

Viele Grüße

Zitat:

---

Zitat von leo

nur für den IE 6-8 benötigt.

---

Die 8 da drin ist das Problem. 6 ist wurscht, 7 meinetwegen auch (wer das Update gemacht hat, kann auch das auf 8 machen).

Wenn es nur ein paar Tags sind, mit denen der 8er nicht klarkommt, kann man nicht wenigstens dort eine Fallunterscheidung reinbauen - wieviele/welche sind das überhaupt, gibt's da eine Übersicht?

<ironie>
Oder wir bauen ein wenig Flash ein, damit's auf dem iPad wenigstens auch nicht läuft.
</ironie>

Zitat:

---

Zitat von christian

Wenn es nur ein paar Tags sind, mit denen der 8er nicht klarkommt, kann man nicht wenigstens dort eine Fallunterscheidung reinbauen - wieviele/welche sind das überhaupt, gibt's da eine Übersicht?

---

Zitat:

---

Zitat von lucina

Naja, wenn ich mir http://caniuse.com/#cats=HTML5&sort=score mal anschaue,

---

Siehe oben.
Carolina.

Also abgesehen davon, dass hier alle einer anderen Meinung sind, würde ich generell Leo darum bitten hier keine HTML5 Experimente in 2.10 einzubauen die nicht mehr rückgängig zu machen sind. (Geht hier nicht um ein HTML5 fe_page.tpl, sondern das irgendwelche Core-Klassen mit Scheuklappen Richtung HTML5 gedreht werden).

Davon mal abgesehen sind sich sicher alle einig das man im Backend ruhig auf HTML5 + CSS3 + JS setzen kann, sprich als "Systemvorraussetzung" nehmen kann. Zumindest JS halte ich für VIEL zu wenig benutzt im Backend.

Ich betone hier gerne nochmal: Für IE 8 & 7 auf irgendwelche JS-Libs zu setzen, ist für mich persönlich ein absolutes No-Go. Wenns hier um irgendwelches nichtintegrales Canvas zeug gehen würde, wo man ein schickes Fallback designen kann, ok... aber was gar nicht geht sind Navigationen die man nicht findet, nicht da sind oder nicht benutzbar sind.

Also scheint die eigendliche Frage zu sein:
Wie hoch ist der Antel von IE8,7 und meinetwegen 6 Usern, die ohne Javascript unterwegs sind. Kennt irgendwer von euch hierzu eine Statistik?

Wie auch die von lucina schon zweimal verlinkte Seite gut zeigt, ist es eben nicht so, dass wir hier von einem Uralt-Browser wie IE6 reden, sondern von relativ aktuellen Browsern wie einem IE8. Bedenkt bitte, dass die Nutzer gar nicht auf IE9 updaten können, wenn sie noch Windows XP nutzen (und das tun sehr viele)!

Wenn man Statistiken wie denen von W3Schools folgt, sieht man deutlich, dass von dem knappen Viertel der Browser-Nutzer die auf den IE setzen, der absolut größte Teil noch auf IE8-Basis läuft. Oder anders ausgedrückt, wir würden laut der Statistik bei mindestens 18% aller Webseiten-Benutzer (die IE8-Nutzer) einen JS-Zwang voraussetzen, nur damit sie überhaupt die Grundelemente der Webseite brauchbar sehen (ohne die das ganze Gerüst einfach zusammenbricht, wenn sie falsch interpretiert werden!).

Ich denke, dass sich hier schon eine sehr deutliche Mehrheit für den Punkt "HTML5 gerne, aber nicht radikal ab der 2.10 nur noch die neuen Elemente wie <header> <section> <nav> etc." abzeichnet. Eine zwingende "Lösung" via JS für einen so aktiven Browser wie IE8 nur, damit die Grundelemente der Website überhaupt funktionieren, ist schon äußerst radikal.

Wenn es aber eh nur um diese Grundelemente geht, dann ist imho der Aufwand überschaubar, dass man hier eine Weiche einbaut und der Admin selbst z. B. in den Settings festlegen kann, ob er (Standardeinstellung) die Ausgabe als <div id="header"> haben will, oder ob er (müsste bewusst vom Admin gewählt werden) schon auf das riskante Pferd <header> setzt.

Diese Herangehensweise hätte den deutlichen Vorteil, dass eben niemand gezwungen wird seine bisherige Website anzupassen, weil die Default-Einstellung die Elemente wie bisher belässt. Die Extension-Entwickler trifft es auch nicht, denn wie Leo schon sagte, spricht er eh nur von den paar Grundelementen wie <header> <section> <nav> etc., so dass sie ihre Templates wie bisher lassen könnten.

Also nochmal klar meine Meinung:
JA zu HTML5-Unterstützung, aber nur wenn auch das gilt:
JA zu Wahlmöglichkeit, wie die Grundelemente in der Website ausgegeben werden, wobei der Default die bisherige (XHTML)-Herangehensweise sein sollte.


@psren: So kannst du auch nicht ran gehen, denn ich habe schon öfter gesehen, dass in Firmen zwar JS theoretisch im Browser aktiv wäre, aber die restriktiven Antivirenprogramme das JS dann blockten. Sowas lässt sich imho in keiner Statistik erfassen, da der Browser ja vielleicht noch für ne Hundertselsekunde die Info "ich kann JS" schickt, bevor das Antivirusprogramm dann blockt.

Wir sollten den x-tausenden Contao-Webseitenbetreibern so oder so aber nicht aufzwingen, dass sie einer Philosophie von "geht nur mit JS" folgen müssen. Das wäre schlechter Stil.
Für "hübsche" Effekte oder Teilbereiche einer Website kann man diese Doktrin als Webdesigner bewusst in Kauf nehmen, aber doch nicht für eine gesamte Website. Zumindest aber sollte die Wahlmöglichkeit immer für den Admin bestehen - und unter Wahlmöglichkeit verstehe ich nicht, dass abertausende Contao-Websites zwingend in den Templates deswegen von den Betreibern modifiziert werden müssen. Das würden die Leute Contao nicht danken, sondern wären wahrscheinlich extrem sauer, dass man sie derart bevormundet.

Deshalb wäre doch die '.tpl5' bzw. '.html5.tpl' Lösung so Elegant, weil man könnte im Core die XHTML .tpl beibehalten und die '.tpl5' dann entweder als Erweiterung oder im Core oder garnicht zur Verfügung Stellen und das kann dann ja jeder machen wie er will.

Hätte auch den Vorteil dass ich in einer Installation eine HTML(5) Seite und eine XHTML Seite verwalten könnte (Firmenseite XHTML und Spielwiese HTML5 oder so).

imo die beste Lösung. Das man die ie6/ie7 Unterstützung fallen lassen kann denke ich auch, weil wer unbedingt ie6 unterstützen will, der weiß im normalfall auch wie das geht.

Templates fix über die Dateiendung einem View zuschustern ist überhaupt nicht elegant und erst recht nicht flexibel. Es soll durchaus Seiten geben, die 2 verschiedene XHTML Views definieren wollen. Das ist zur Zeit nur mit den Themes umsetzbar, was allerdings ein Mirror der ganzen Module erfordert...

Ich sehe schon, wohin diese Diskussion läuft. Vorschlag zur Güte: Wir bieten weiterhin im Seitenlayout die Wahl zwischen XHTML und HTML5 an. Intern verwenden wir jedoch HTML5 und passen die Ausgabe bei Bedarf mit Hilfe von Text-Ersetzungen an XHTML an. Dadurch können wir sowohl Tags wie BR und IMG korrekt schließen, als auch die neuen Tags wie SECTION, ARTICLE etc. wieder in DIVs verwandeln.

Zitat:

---

Zitat von leo

Intern verwenden wir jedoch HTML5

---

Meinst du mit "intern" das Backend?

Danke für die Übersetzung :D

@leo: Das klingt gut :)

Hallo Leo,

ich denke, dass das ein guter Kompromiss ist. Somit ist zumindest der "1. Schritt" im Core Richtung HTML5 gegangen.

Gruß Alex

Mit str_replace? Abgesehen davon, das dann wie blöd auf dem Output drauf rumgeritten wird, was massig Performance kostet, ist das ganze total "error-phrone", kleines Beispiel:

HTML-Code:

---

<section id="blub" class="bla"></section>

---

müsste zu

HTML-Code:

---

<div class="section bla" id="blub"></div>

---

werden...
Dafür brauchst schon mindestens RegEx, was das ganze noch VIEL schlimmer machen wird, sowohl in Sachen performance, als auch Handhabbarkeit.
Wenn man so eine Ersetzung wirklich "sauber" machen will, dann geht eh nur XSLT... was aber auch nicht wirklich performant ist.

Wie gehen denn die anderen grossen CMS mit der Thematik um?

Beim TYPO3 Backend wird auch HTML5 verwendet, für abwärtskompatibiltät nehmen die modernizer.

Zitat:

---

Zitat von schman

Beim TYPO3 Backend wird auch HTML5 verwendet, für abwärtskompatibiltät nehmen die modernizer.

---

Und Frontend? Wegen dem Backend hat hier imho ja eh keiner Probleme.

Zitat:

---

Zitat von leo

Ich sehe schon, wohin diese Diskussion läuft. Vorschlag zur Güte: Wir bieten weiterhin im Seitenlayout die Wahl zwischen XHTML und HTML5 an. Intern verwenden wir jedoch HTML5 und passen die Ausgabe bei Bedarf mit Hilfe von Text-Ersetzungen an XHTML an. Dadurch können wir sowohl Tags wie BR und IMG korrekt schließen, als auch die neuen Tags wie SECTION, ARTICLE etc. wieder in DIVs verwandeln.

---

Was im Endeffekt mehr Implementierungsaufwand ist als die von lindesbs vorgeschlagene Weiche, da es hoechst komplexe regexe erfordert/ein parsen des DOM tree wenn es error prone sein soll.
IMO passt da die von lindesbs vorgeschlagene Weiche in der Art von (untested Pseudocode) doch besser:

PHP-Code:

---

protected function getTemplate($strTemplate, $strTemplateSuffix='tpl', $blnMustBeNative=false)
{
        $strPath = TL_ROOT . '/templates';
        $strTemplate = basename($strTemplate);

        // Check the templates subfolder
        if (TL_MODE == 'FE')
        {
            global $objPage;

            $strTemplateGroup = str_replace('../', '', $objPage->templateGroup);
            $strTemplateGroup = preg_replace('@^templates/@', '', $strTemplateGroup);

            if ($strTemplateGroup != '')
            {
                $strFile = $strPath . '/' . $strTemplateGroup . '/' . $strTemplate . '.' . $strTemplateSuffix;

                if (file_exists($strFile))
                {
                    return $strFile;
                }
            }
        }

        // Check the templates directory
        $strFile = $strPath . '/' . $strTemplate . '.' . $strTemplateSuffix;

        if (file_exists($strFile))
        {
            return $strFile;
        }

        // Browse all module folders
        foreach ($this->Config->getActiveModules() as $strModule)
        {
            $strFile = TL_ROOT . '/system/modules/' . $strModule . '/templates/' . $strTemplate . '.' . $strTemplateSuffix;

            if (file_exists($strFile))
            {
                return $strFile;
            }
        }
        // still not found, check if it was an non standard extension and try to find a XHTML Template if graceful degration is allowed.
        if($strTemplateSuffix != 'tpl' && !$blnMustBeNative)
            return $this->getTemplate($strTemplate);
        throw new Exception(sprintf('Could not find template file "%s"', $strTemplate));
    }
} 


---

Damit kann dann jede Extension ein Template in beliebigem Format anfordern und bekommt (sofern optionaler Parameter $blnMustBeNative==false) automatisch das fallback Template als XHTML.
Das dann in die TemplateKlassen einzubauen sollte auch moeglich sein (switch in TL_CONFIG auswerten).
Entsprechende Adaption an Controller::getTemplateGroup() etc. steht hierbei noch aus.

Im allgemeinen bin ich massiv gegen str_replace und preg_replace Orgien.
Man sollte nicht einen riesen String bauen, der dann hin und her geschubst und umgeschrieben wird. Besonders nicht, wenn es mind. 18% aller meiner User betrifft (siehe Nina oben). Den IE7 und andere "alternative" Browser noch nicht mal mitgezaehlt.

Der Rechenaufwand ist hiebei einfach zu hoch und man kann auch nicht ohne Ende vom Servercache profitieren.
Meiner Meinung nach begeben wir uns auf sehr dynnes Eis hinsichtlich Skalierbarkeit, wenn wir nun versuchen an allen Ecken und Enden string replace Operationen vorzunehmen.

Gruss
Chris

Zitat:

---

Zitat von Nina

Und Frontend? Wegen dem Backend hat hier imho ja eh keiner Probleme.

---

TYPO3 hat dieses Problem einfach nicht, weil du ja alles Typo-Script'en kannst und außerdem hat Typo3 verschiedene Ausgabetypen.

Aber der Vorschlag von lindesbs&Xtra gefällt mir :)
Wenig Aufwand für volle Flexibilität ohne die Geschwindigkeit zu gefährden.

String-Replace-Funktionen wären auch nur das Fallback wenn die tidy-Erweiterung nicht vorhanden ist. Und im Cache landet natürlich die bereits angepasste Version, so dass die Umwandlung nur einmal gemacht werden muss. Das ist immer noch weit weniger Arbeit als ein komplettes zweites Template-System!

Zitat:

---

Zitat von conta1234

Die Statistiken eurer wunderbaren Browserstatistikseiten berufen sich auf ca. 3 Mio Websites die durchgehend gescannt werden. Sehr schön... Wenn ich bei Google www eingeben bekomme ich 25.270.000.000 Ergebnisse

---

http://de.wikipedia.org/wiki/Stichprobe und http://de.wikipedia.org/wiki/Projektion_%28Statistik%29. Und viel relevanter: Unter den drei Million sind so manche Schwergewichte mit tlw. Hunderttausenden bis Millionen von Impressions pro Tag. Die sind wahre Indikatoren für die Marktanteile der Nutzer, nicht die Hundertausende und Millionen von "Mini-" oder Privatseiten von Benno dem Hund und ihrer stolzen Besitzerin mit höchstens 100 Impressions pro Monat.
Und zu guter Letzt kann ich die statistischen Werte einigermaßen mit den Werten der Websites, die ich betreue, verifizieren, da zeichnet sich sogar ein viel deutlicherer Trend zu (wirklich) modernen Browsern ab, aber das ist zum Teil auch Zielgruppeneffekten geschuldet (Kreativbranche usw.) – das bestätigt erneut: Wenn die Zielgruppe einer Website z. B. eher mittelständische, "träge" Unternehmen sind, ist davon auszugehen, dass man einen deutlich erhöhten Anteil von IE<9 hat, und entsprechend darauf eingestellt sein muss, inkl. (z. B. aus Sicherheitsgründen) fehlender JS-Unterstützung!


Edit: Ab hier nicht mehr aktuell, ich Penner hab vor dem Antworten keinen Reload gemacht … sorry.

… und dann geht die ganze Website den Bach hinunter, wenn JS die Fehler von Microsoft in IE8 (und früher, wenn es denn beachtet werden soll) ausbügeln soll. Und wie Nina dankenswerterweise anmerkte: Ein Marktanteil von fast 20% ist nicht zu missachten! Und es ist nicht immer nur "Corporate Policy", wenn JavaScript deaktiviert ist, denn bei vergangenen Sicherheitslücken wurde oft empfohlen, JavaScript zu deaktivieren, oder der Virenschutz erledigt das.

Ich kann es nur nochmal wiederholen: Die neuen semantischen HTML5-Tags zwingend in Contao 2.x im Frontend einzuführen, halte ich zumindest für die nächsten zwei Jahre (wenn der Security Support für XP endet) nicht für tragbar und sinnvoll, schon gar nicht mit einem pur-JS-Fallback.

Wer noch mehr zum falschen Rendering unbekannter Elemente in IE8 (und älter) wissen möchte, dem Empfehle ich die Erklärung im WHATWG Blog: http://blog.whatwg.org/supporting-new-elements-in-ie

Bezüglich der neuen Beiträge, die mir mangels Reload entgangen sind:

Zitat:

---

Zitat von backbone

Mit str_replace? Abgesehen davon, das dann wie blöd auf dem Output drauf rumgeritten wird, was massig Performance kostet, […]
Dafür brauchst schon mindestens RegEx, was das ganze noch VIEL schlimmer machen wird, sowohl in Sachen performance, als auch Handhabbarkeit.

---

Kann ich nur vollkommen zustimmen. Auch wenn zunächst versucht wird mit Tidy zu kommen (was meines Erachtens auf den wenigsten Servern zur Verfügung gestellt wird, und da kommen wir wieder mit dem 20%-Betroffene-Problem – dieses Fallback kann man bei einem Marktanteil von <10% von betroffenen Browsern einsetzen).

Ein Gefrickel mit str_replace / preg_* oder gar Tidy kann ich leider weder dem Kunden ("Wieso ist die Seite so langsam??", "Warum stürzt mein Server ab??") noch dem Server und zugehörigem Admin verkaufen. Es würde auch vor allem den memory-Footprint weiter erhöhen, was gar nicht zu dem schlanken Image (bezogen auf Ressourcen) von Contao passt.


Ich bin stark für die zusätzliche .tpl5-Variante, auch wenn es nicht (wie angemerkt) ganz sauber ist: Es ist die Variante mit dem wenigsten Aufwand, bietet ein wunderbar 100%ig kompatibles und schnelles Fallback, benötigt keine Extraarbeit (wenn man nicht will), funktioniert auch bei verschiedenen Partials. Es ist ein progressive enhancement, quasi auch als "Testbed" für Contao 3 (in dieser Version kann man sich dann von XHTML1 verabschieden, da eine bewusste Entscheidung seitens der Entwickler getroffen werden kann – ich bezweifle, dass jemand seine Seite ohne viel Aufwand direkt auf Contao 3 portieren wird, bei Updates von 2.x auf 2.y ist das ja, v. a. dank LiveUpdate, etwas ganz anderes).

Ich würde allerdings nicht ganz die von xtra vorgeschlagene Änderung befürworten (vorausgesetzt, ich interpretier den Code richtig), da es im gesamten Contao Code doch relativ viel Änderung bedeutet. Stattdessen würde ich eine globale Einstellung anbieten, die, wenn die Einstellung entsprechend gesetzt ist, automatisch das HTML5-Template wählt (als Fallback natürlich das "normale" Template sucht). Damit sich niemand bevormundet fühlt, empfehle ich einen zusätzlichen Parameter, der diese Einstellung für ein Template überschreiben kann (à la $forceExtension='tpl5'|'tpl'), ggf. sogar eine Extension-weite Option (wenn das technisch in Contao möglich ist), die für alle Templates einer Extension die "Dateiendung" (oder wie auch immer die Varianten identifiziert werden) vorschreibt.


Edit: Das Argument, quasi ein zweites Template-System mit entsprechendem Aufwand einzuführen, kann ich nicht ganz anerkennen. Erstens betreffen neue syntaktische HTML5-Tags nur vergleichsweise wenige Templates (insbesondere fe_page, Navigation, Artikel), zweitens kannst du, Leo, ja durchaus lokal einen Regex basteln, der aus HTML5-Templates durch Ersetzungen die "alten" Templates generiert (und abspeichert), somit hast du eigentlich keinen Mehraufwand (außer einmalig den Regex und Build-Skript schreiben). Vielleicht kann man das sogar in den Core verfrachten und immer "alte" Templates generieren lassen, wannimmer "nur" neue Templates auftauchen, vorausgesetzt, diese werden dann z. B. im /templates/-Ordner fix abgespeichert und nicht ständig oder regelmäßig, sondern nur "auf Zuruf" neu generiert.

Ein problem was noch aufkommt bzgl. der Templatewahl via URL: SEO.
http://domain.tld/start.html
ist für Suchmaschinen eine komplett andere Seite wie
http://domain.tld/start.html5

Also muss man dieses Template-Switching sowie so über ein Mapping "Browser->Templatetyp" machen und wie gesagt um das ganze dann noch sinnvoll für "Multiviews" zu machen müsste man diese Mappingregeln editieren können in einem Gewissen Scope.