Contao goes HTML5 & CSS3

[leo]

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?

[Flex]

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...

[Tim G]

Guten Morgen,
HTML5 reicht, aus meiner Sicht.

Viele Grüße aus Berlin,
Tim


Sent from my iPhone using Tapatalk

[Nikolas]

HTML5 reicht, aus meiner Sicht.

unterschreib

Seh ich auch so.

Gruß
Nikolas

[leo]

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?

[andreas.schempp]

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

[leo]

Das hat Felix vor ein paar Tagen schon umgesetz

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

[psren]

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

[lindesbs]

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.

[Nina]

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.

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.

[drefsa]

Mir persönlich reicht HTML5.

[leo]

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.

[ofriedrich]

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

[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.
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...

[christian]

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

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

[sans]

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

[Nina]

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.

[leo]

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/

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:

<?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

[xtra]

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.

[lucina]

... 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.

[conta1234]

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
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...

[wiese]

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 ...

[matze]

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

[Nina]

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 ).

[conta1234]

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!

[psren]

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

[Seitengestalter]

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.

[FloB]

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.

[lindesbs]

@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.

[MacKP]

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

[christian]

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 ...

[leo]

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!

[MacKP]

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):

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

Viele Grüße

[leo]

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.

[MacKP]

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

[andreasisaak]

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

[conta1234]

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...

[lucina]

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.

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 ...

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.

[backbone]

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:

<!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

[dave.matter]

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).