Contao goes HTML5 & CSS3

[backbone]

Die letzte Idee von FloB hört sich afaik ganz gut an, da man hier dann auch ohne Probleme (hinsichtlich der Performance) mit XSLT rangehen kann. Womit das ganze dann auch wartbar und viel weniger fehleranfällig wird. Vorraussetzung hierfür ist natürlich die Verwendung von XHTML5 bzw. von wohlgeformter XML Syntax.

Edit: Ok, zu schnell auf den Post-Button gedrückt und zu wenig nachgedacht: problematisch ist das natürlich in der Hinsicht, das PHTML keine gültige XML-Syntax mehr hat, sobald man sowas verwendet:

<div class="<?php echo $class; ?></div>

Trotzdem hört sich die Idee auf jeden Fall besser an, aber leider immer noch kein Ersatz für Multiviews oder multiview-ähnliche Techniken.

[xtra]

Das wird uns aber nix bringen, da die Templates erst nach dem parsen durch den XHTML Reisswolf koennen. Denn den PHP code in Templates mittels pregreplace usw. zu bearbeiten ist (mir persoenlich) dann doch zu riskant.

Somit myssten dann alle partials im Context zum Benutzer im Template cache abgelegt werden was das Prinzip wieder ad absurdum fyhrt und wir eh gleich wieder alles preg_replacen myssten.

Naechste Woche werde ich mal versuchen das mit dem Template lookup wie oben skizziert in einen mockup zu verwandeln wenn keiner schneller ist (lindesbs? wie sieht's aus?).

Abschliessend kann ich nur nochmal unterstreichen, dass das preg_replacen bei vielen den Eindruck eines aufgeklebten Flickens erweckt und wir davon tunlichst Abstand nehmen sollten. Wie bereits geschrieben kommt es nicht auf die Anzahl der Funktionsaufrufe sondern deren Laufzeit und Speicherbedarf an (Informatikerlatein: Kosten) und da sind regular expressions leider meist recht teuer.

Ich finde es jedoch hoechst positiv, wie der Thread hier verlaeuft und sachlich Loesungsvorschlaege eingebracht werden. Dickes Thumbs up.

[FloB]

Das wird uns aber nix bringen, da die Templates erst nach dem parsen durch den XHTML Reisswolf koennen. Denn den PHP code in Templates mittels pregreplace usw. zu bearbeiten ist (mir persoenlich) dann doch zu riskant.

Du meinst, dass durch das Ersetzen ggf. PHP-Code geändert wird? Habe ich mir auch schon überlegt, aber meines Erachtens sollte es durch (möglichst) eindeutige RegExs möglich sein solche falschen Ersetzungen vollständig zu vermeiden. Und meines Wissens werden nirgendwo (relevante) Tags on-the-fly generiert (eben außer die verschiedenen Ebenen bei Überschriften, aber die haben sich ja im Standard nicht geändert).

Nach wie vor bleibt natürlich, dass zusätzliche Partials für HTML5 am saubersten und einfachsten zu implementieren wären. Man könnte ja wie gesagt zumindest einen OnDemand-Helper (z. B. in den Developer Tools) zur Verfügung stellen, der HTML5-Templates in XHTML umwandelt (das ist verschieden zur automatischen Übersetzung mit caching!).

[andreas.schempp]

Leo, dein str_replace berücksichtigt nicht, das Erweiterungen ggf. andere Tags ausliefern. Wenn eine Erweiterung <script type="text/javascript"> schon mitliefert, würde durch deine Ersetzung das type-Attribut verdoppelt.

[leo]

Abschliessend kann ich nur nochmal unterstreichen, dass das preg_replacen bei vielen den Eindruck eines aufgeklebten Flickens erweckt und wir davon tunlichst Abstand nehmen sollten.

Das ist doch vollkommener Schmarrn. Es gibt so gut wie kein Skript, das ohne preg_replace auskommt. Denk nur mal an die Verwendung von BBCode, der meistens damit umgewandelt wird. Oder die komplette HTML-/JavaScript-/CSS-Compressor-Extension von Andreas, die ausschließlich auf regulären Ausdrücken basiert.

Und vor ein paar Tagen hast Du selbst noch einen Hook für den Combiner angefragt, um die zusammengefassten Skripte weiter bearbeiten zu können ("minimizing", "alter the content" etc.). Jetzt bin ich ja mal sehr gespannt, mit welchen Mitteln Du das umsetzen wolltest. Doch nicht etwa mit einem "Flickwerk" wie str_replace oder preg_replace?

[FloB]

Niemand hat behauptet, dass die Verwendung von preg_* und *_replace böse wäre oder man es niemals benutzen sollte. Im Gegenteil (du hast ja Parser angesprochen, das kannst du ohne solche Funktionen eigentlich gar nicht umsetzen). Aber für diesen Anwendungsfall ist (zumindest für mich, und es sollte bei vielen anderen auch diesen Eindruck erwecken, wie xtra schon sagte) das auf jeden Fall ein Flicken (es ist hier kein Parsen o. ä., sondern ein "korrigeren" der Abwärtskompatibilität über die Hintertür).

Und wieder sorgt der IE für Zwist

[backbone]

Das ist doch vollkommener Schmarrn. Es gibt so gut wie kein Skript, das ohne preg_replace auskommt. Denk nur mal an die Verwendung von BBCode, der meistens damit umgewandelt wird. Oder die komplette HTML-/JavaScript-/CSS-Compressor-Extension von Andreas, die ausschließlich auf regulären Ausdrücken basiert.

Und vor ein paar Tagen hast Du selbst noch einen Hook für den Combiner angefragt, um die zusammengefassten Skripte weiter bearbeiten zu können ("minimizing", "alter the content" etc.). Jetzt bin ich ja mal sehr gespannt, mit welchen Mitteln Du das umsetzen wolltest. Doch nicht etwa mit einem "Flickwerk" wie str_replace oder preg_replace?

str_replace/preg_replace ist böse, wenn man eine Transformation auf strukurierten Daten (XML) durchführen möchte, wenn für dieses Datenformate spezielle Parser und sogar eigene Transformations-Sprachen existieren.

Ein bisschen Klugscheißen:
Für XML brauchst du mindestens - wenn nicht noch allgemeiner - einen Kellerautomat um es wirklich sauber parsen zu können. str_replace alleine schafft das nicht, mit Perl-"RegEx" kannst du zwar einen Kellerautomat nachbilden, aber das ist bei so einer komplexen Grammatik wie XML total wuschig... (wohl gemerkt das "echte" Reguläre Ausdrücke nur Reguläre Grammatiken und damit nur DFAs nachbilden können, aber das geht dann WIRKLICH GUT mit RegEx).


str_replace und preg_replace sollte meiner Meinung nach nur auf natürliche Sprachen angewendet werden, oder wenn man tatsächlich auf irgendwelchen Zeichen rumoperieren möchte, nicht um irgendwelche syntaxerhaltenden Transformationen durchzuführen.

Dein Beispiel für den BBCode: Dort ist Regex in Ordnung, da die Grammatik SEHR einfach ist und wirklich nur ein DFA (ohne Schachtelung) bzw. sehr einfacher Kellerautomat (mit Schachtelung) benötigt wird.
Ich bring mal noch einige Beispiel für sehr sinnvollen Regex-Einsatz: Syntax-Validierung von Telefonnummern (DFA), E-Mail (DFA), URL (DFA, komplex), Zahlen (DFA), XML-Namensproduktions (DFA)... (und natürlich Transformationen in diesen Wertebereichen)

(Diese Ansicht ist natürlich sehr strikt... In der Praxis geht das natürlich nicht immer. Jedoch sollte man für bestimmte Dinge dann einfach sagen "geht nicht" bzw. "geht unter den Vorraussetzungen - zB zu wenig Ressourcen - nicht". Es sollte kein Freifahrtsschein sein, um bei jeder Gelegenheit zu replacen bzw. zu pregexen. Das sieht am Anfang oft einfach aus, führt aber mittelfristig gesehen, sehr schnell in eine Sackgasse und verursacht mehr Probleme als Nutzen)

[leo]

Habt ihr euch die r667 überhaupt richtig angesehen? Der dort verwendete Parser kommt mit nur zwei kleinen Funktionsaufrufen schon fast bis zum Ziel.

Aber gut, auch wenn ich es den absoluten Overkill finde, werde ich versuchsweise die Idee mit dem zweiten Template-System umsetzen. Dabei verwenden wir aber keine zweite Endung, sondern legen aus Gründen der Übersichtlichkeit verschiedene Ordner an. Anfangs wären das die Ordner html5 und xhtml, theoretisch könnten aber bei dieser Lösung später auch noch xml und pdf folgen.

[MacKP]

Habt ihr euch die r667 überhaupt richtig angesehen? Der dort verwendete Parser kommt mit nur zwei kleinen Funktionsaufrufen schon fast bis zum Ziel.

Aber gut, auch wenn ich es den absoluten Overkill finde, werde ich versuchsweise die Idee mit dem zweiten Template-System umsetzen. Dabei verwenden wir aber keine zweite Endung, sondern legen aus Gründen der Übersichtlichkeit verschiedene Ordner an. Anfangs wären das die Ordner html5 und xhtml, theoretisch könnten aber bei dieser Lösung später auch noch xml und pdf folgen.

Mensch leo, das treibt mir fast freudentränen in die Augen XD
Gerade die Möglichkeit dann auch noch verschiedenste Ausgaben erstellen zu können ist der Hammer und wird sich sehr gut auf der feature Liste von Contao machen ;-)

Viele Grüße

[lindesbs]

Habt ihr euch die r667 überhaupt richtig angesehen? Der dort verwendete Parser kommt mit nur zwei kleinen Funktionsaufrufen schon fast bis zum Ziel.

Aber gut, auch wenn ich es den absoluten Overkill finde, werde ich versuchsweise die Idee mit dem zweiten Template-System umsetzen. Dabei verwenden wir aber keine zweite Endung, sondern legen aus Gründen der Übersichtlichkeit verschiedene Ordner an. Anfangs wären das die Ordner html5 und xhtml, theoretisch könnten aber bei dieser Lösung später auch noch xml und pdf folgen.

Auch ich moechte mich bei Dir bedanken, das du diesen Weg in Erwaegung ziehst.
Weil DAS ist ein super Punkt fuer die Besonderheitenliste von Contao !

DANKE

[backbone]

Finde das auch gut

[lucina]

Aber gut, auch wenn ich es den absoluten Overkill finde, werde ich versuchsweise die Idee mit dem zweiten Template-System umsetzen. Dabei verwenden wir aber keine zweite Endung, sondern legen aus Gründen der Übersichtlichkeit verschiedene Ordner an. Anfangs wären das die Ordner html5 und xhtml, theoretisch könnten aber bei dieser Lösung später auch noch xml und pdf folgen.

Danke, Leo. Ich finde das einen superguten Schritt und freu mich auf die weitere Entwicklung.

Contao rocks ... ;-)

Carolina.

[Nina]

Klingt spitze!

[christian.kolb]

Dabei verwenden wir aber keine zweite Endung, sondern legen aus Gründen der Übersichtlichkeit verschiedene Ordner an. Anfangs wären das die Ordner html5 und xhtml, theoretisch könnten aber bei dieser Lösung später auch noch xml und pdf folgen.

Korrigiert mich bitte, falls ich das jetzt falsch verstanden habe, aber:

2 Templates = 2 verschiedene Ausgaben je nach dem ob der genutzte Browser HTML 5 unterstütz oder nicht.

Wenn ich dann ein Template überschreibe in dem ich ein geändertes in den /templates Ordner lege, welches der beiden Templates überschreibe ich damit dann?

Bräuchte man nicht genau dafür verschiedene Dateiendungen?

Gruß
Christian

[teo]

'duales system' finde ich auch super. So kann man dann schon mal HTML5 Seiten bauen wenn es gewünscht wird aber man kann auch noch dem Mainstream (unzaehlige XP Installationen mit IE 7) gerecht werden.

[backbone]

Das Verhalten müsste dann im Templates Ordner natürlich repliziert werden, oder in dem Themes dynamisch festlegbar sein:
Ordner A -> XHTML Templates
Ordner B -> HTML5 Templates

Noch eine Frage am Rande:
Leo: Du benutzt jetzt HTML5 Syntax und keine XHTML5 Syntax, wenn ich das richtig sehe? Gibt es dafür einen bestimmten Grund? Viele würden sich XHTML5 (wohlgeformt im Sinne von XML) wünschen.

[christian]

Contao rocks ... ;-)

... und das bleibt auch so. Danke Leo!

<all thumbs up />

[conta1234]

...wenn das Ding erstmal steht, werden wir sehen, dass es die beste Lösung war und natürlich auch relativ einfach in HTML6,7,8 Zeiten upzugraden ist Schön das ich meinen Kunden weiterhin den Support von IE5+ bis OpenEnd anbieten kann. Demnächst wird erstmal ordentlich in Liveupdates, Bücher und Contaosupport investiert. Besten Dank Leo und natürlich die gesamte Community, die den Umfang dieser Entscheidung zum Glück richtig eingeschätzt hat...

[xtra]

Das ist doch vollkommener Schmarrn. Es gibt so gut wie kein Skript, das ohne preg_replace auskommt. Denk nur mal an die Verwendung von BBCode, der meistens damit umgewandelt wird. Oder die komplette HTML-/JavaScript-/CSS-Compressor-Extension von Andreas, die ausschließlich auf regulären Ausdrücken basiert.

Es ist schoen dass du meine Ansichten als Schmarrn abtust, aber lies bitte nicht nur was ich schreibe sondern versuche mich auch zu verstehen und vergleiche hier nicht Aepfel (XML, XHTML) mit Birnen (BBcode was eine Grammatik mit sehr wenigen Vokabeln ist, Javascript, was maschinell nur mit einem vollwertigen Lexer wirklich parsbar ist).
Aepfel (von HTML bzw. SGML allgemein, dazu unten mehr) abgesehen sind mit minimalem Aufwand maschinell verarbeitbar im Vergleich zu Birnen.

Es ist weiterhin ein grosser Unterschied, ob man versucht innerhalb einer Sprache nur Whitespaces etc. zu entfernen (dein Beispiel Minimizer) oder versucht mit einem Regulaeren Ausdruck eine Sprache in eine andere zu ybersetzen.

In deinem regex Code Beispiel frage ich mich z.B. wo ist XHTML wenn nun einer die Listen optional schliesst? (das ist valides HTML5 bzw. SGML, wobei mir bei dem, was in SGML alles "valide" ist, sowieso schwindelig wird)

<p class="welt">Hallo Welt!
<ul>
    <li>Lorem
    <li>Ipsum
    <li>Dolor
</ul>

Wie regext du das nun weg damit sauberes XHTML raus kommt? Klar, kann man eintragen, dann spinn ich weiter, dann mach ich das nun noch mit anderen Elementen...

Dieses Spiel kann man, gemessen an der Tatsache dass HTML5 ein moving Standard ist(bzw. wird) und somit laufen neue Tags hinzukommen beliebig weiter treiben, so dass deine regex beliebig komplex werden kann(!).

Ein "alternatives Templatesystem", welches ja im Grunde nur aus dem umschreiben des Templatesuchalgortihmus besteht, ist von vornherein fyr sowas gewappnet.

Und vor ein paar Tagen hast Du selbst noch einen Hook für den Combiner angefragt, um die zusammengefassten Skripte weiter bearbeiten zu können ("minimizing", "alter the content" etc.). Jetzt bin ich ja mal sehr gespannt, mit welchen Mitteln Du das umsetzen wolltest. Doch nicht etwa mit einem "Flickwerk" wie str_replace oder preg_replace?

Als kleinen sidekick koennte ich mir hier einen Javascript packer vorstellen, der in der Tat die Scripte parst und dann wirklich packt anstelle Variablennamen auszutauschen und funktionsnamen zu verkryppeln etc. Mit Regex? schwer.
Aber das wirklich nur als Sidekick.
Wie oben bereits geschrieben ist dies etwas total anderes, denn ich wollte in solchen Scripten nicht die Formalen Sprachen tauschen. Ich hatte nicht vor in diesem Hook aus Javascript VBScript oder etwas andersartiges zu machen (um mal einen Vergleich anzustellen, der zugegebenermassen aufgrund der unterschiedlichen Vokabeln der Sprache schon ein wenig hinkt, aber mal als Beispiel allein die Grammatiken zu wandeln entspricht dem Umwandeln einer komplexen Sprache in eine andere).
Ich kann hierbei backbone nur beipflichten, wenn man versucht alles per regex und str_replace zu beheben, dann faehrt man mit fortschreitender Zeit gegen die Wand und dann ist das Geheule gross (habe ich mehrfach erlebt in den vergangenen Jahren).
Also lass uns diesen Fehler bitte vermeiden.

Habt ihr euch die r667 überhaupt richtig angesehen? Der dort verwendete Parser kommt mit nur zwei kleinen Funktionsaufrufen schon fast bis zum Ziel.

Habe ich und sie kommt mit dem preg_replace fast bis an das Ziel das du wolltest, naemlich von HTML5 auf XHTML zuryckzureiten.
Wei du aber schon selbst schreibst: "fast". Und der Alternative Template Ansatz zaeumt das Pferd nicht von Hinten auf, sondern entscheidet sich einfach fyr ein Pony wenn die der Reiter fyr ein echtes Pferd zu klein ist und amputiert nicht dem Pferd die Fysse.

Aber gut, auch wenn ich es den absoluten Overkill finde, werde ich versuchsweise die Idee mit dem zweiten Template-System umsetzen. Dabei verwenden wir aber keine zweite Endung, sondern legen aus Gründen der Übersichtlichkeit verschiedene Ordner an. Anfangs wären das die Ordner html5 und xhtml, theoretisch könnten aber bei dieser Lösung später auch noch xml und pdf folgen.

Wie meine Vorredner kann ich diese Entscheidung nur begryssen und freue mich dass du, zumindest experimentell diese Implementierung vornimmst.
Als Overkill empfinde ich diese in keinster Weise denn:
Wenn diese Implementierung von vornherein flexibel genug ist, dass "ohne Probleme" andere Ausgabeformate hinzugefygt werden koennen (XML, TeX, das PDF bezweifle ich aufgrund der mittlerweile komplexen und binaer gepackten Natur des Formats) ist dies ein Meilenstein in der Entwicklung des CMS Contao, welche bei grossen Schritten in den Minors (2.7: col2 layout im BE, 2.8: Schnelles publishing, 2.9: Theme Manager) meiner Meinung nach derjenige, welcher alle vorherigen bei weitem in den Schatten stellen wird.

In diesem Sinne: Rock on und back to code (was auch ich nun wieder tun werde)

Grysse
Chris

[backbone]

Weil du grad TeX und PDF ansprichst: Wenn man sich ein schönes TeX Templateset zusammenbaut, sollte man doch serverseitig daraus PDFs machen können? Meine technischen TeX und PS/PDF Kenntnisse sind eher beschränkt, aber ich kann mich daran erinnern, das mit LaTeX es ziemlich gut ging PDFs zu bauen, die nicht wie grütze aussehen (Hallo isotope nicht so ernst nehmen andreas, die letzte PDF die ich von isotope gesehen habe, war von 0.2.0 beta)

[xtra]

Abschliessend ist das kein Problem das nach der Generierung durch das CMS durch pdfmaker zu jagen (oder was auch immer du hinterher haben willst). Das mach ich hier lokal haeufig. Bin doch gerne TeXer.
Ich meinte damit das interne, native erstellen von PDF als template, was wohl nicht wirklich ohne ein Ursprungsformat wie Tex funktionieren wird.

Gruss
Chris

[pinball]

Hallo liebe Entwickler,
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?

Auch eine Gretchen-Frage.
Und wie sieht es mit den heutigen Browsern in Sachen HTML5 aus?? In zwei bis drei Jahren vielleicht werden es diese fressen, man siehe z.B. CSS 3. Es hat also meiner Meinung nach keine Eile mit der Anpassung. XHTML wird noch lange leben. Aus leidiger Erfahrung ist nicht immer alles besser nur weil es neu ist.
Gruss poppap

[pinball]

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.

Auch meine Meinung zu IE6.
Für IE6 ist die Zeit abgelaufen, endgültig und es interessiert mich überhaupt nicht mehr
ob er meine Werke frisst. IE6 gehört endlich verboten, IE7, IE8 und IE9 eigentlich auch. MS kann einfach keine Browser stricken.
gruss poppap

[andreasisaak]

Auch meine Meinung zu IE6.
Für IE6 ist die Zeit abgelaufen, endgültig und es interessiert mich überhaupt nicht mehr
ob er meine Werke frisst. IE6 gehört endlich verboten, IE7, IE8 und IE9 eigentlich auch. MS kann einfach keine Browser stricken.
gruss poppap

Könnten wir endlich aufhören immer wieder über den IE6 zu sprechen? Der IE6 Support kostet Geld und kann von jedem Dienstleister und Contao Partner individuell berechnet werden. Da muss sich leo gar keinen Kopf drum machen.

[leo]

Es ist schoen dass du meine Ansichten als Schmarrn abtust

Das darfst Du nicht persönlich nehmen. In Bayern ist das eine ganz normale Aussage ohne böse Hintergedanken, die nur bedeutet "ich stimme Dir nicht so ganz zu"

[andreas.schempp]

Auch meine Meinung zu IE6.
Für IE6 ist die Zeit abgelaufen, endgültig und es interessiert mich überhaupt nicht mehr
ob er meine Werke frisst. IE6 gehört endlich verboten, IE7, IE8 und IE9 eigentlich auch. MS kann einfach keine Browser stricken.

Ich wundere mich immer wieder über solche Aussagen. Auch ich "hasse" den IE, aber was macht ihr wenn der Kunde IE6 unterstützt haben will, und bereit ist (egal was) dafür zu bezahlen? Sagt ihr dann "das können wir nicht"? Der sucht sich schnell einen anderen Partner und ein anderes CMS.

Man sieht an den Aussagen ein wenig, in welchem Segment jemand tätig ist. Für private Seiten und junge Unternehmen ist eine (vollständige) nicht-Unterstützung von IE6 vielleicht akzeptabel, aber für die meisten Auftritte grosser Unternehmen nicht. Insbesondere auch in diesem Bereich wird der IE6 noch oft benutzt (wegen interner IT-Richtlinien, nicht weil der Benutzer das will, da nützt auch eine Warnmeldung nichts...).

Ich versuche meist die Seite so zu optimieren, dass der IE6 diese benutzen kann, aber wenn dann PNG-Transparenzen fehlen, ist mir das egal. Aber es gibt auch Kunden die eine vollständige Unterstützung wollen, siehe z.B. www.nab.ch.

[weke]

Leider kann ich Andreas nur zustimmen.
Für eine Firma ist es mit unter relevant auch die "alten" Nutzer mit einem IE6 oder IE7 zumindest so weit etwas Anzeigen zu können, dass diese potentiellen Kunden nicht gleich woanders ihr Glück suchen.
Beim IE6 liegen wir noch so bei etwa 7%, beim IE7 etwa bei 11% der Besucher.
Dann nur einen Hinweis zu bringen, "Sorry dein Browser ist zu alt, besorgt dir gefälligtst einen neuen" hilft da leider nicht.
Die Besucher, die mit den Dinosaurien Browsen, die wissen oft nicht, wie sie das ändern können. Und welche Firma möchte schon auf 7-18% der Kunden Verzichten?

Contao sollte hier nicht die Probleme der Benutzer beim Updaten der Browser lösen, zumindest nicht solange der Anteil des IE6 nicht noch drastisch nach unten geht.

[leo]

So, der erste Commit steht kurz bevor. Wir haben aber auf jeden Fall zwei Probleme: Der Rich Text Editor kann nur entweder HTML5 oder XHTML generieren, wobei man da noch die Konfiguration je nach verwendetem Seitenlayout anpassen könnte. Dasselbe Problem gilt aber auch für Inserttags, nur dass diese definitiv keine Ahnung haben, auf welcher Seite sie ausgegeben werden.

Fällt irgendjemandem eine Lösung dazu ein?

[andreas.schempp]

Könnte der InsertTag das nicht über die globale $objPage auslesen?

[backbone]

Gibt es eine globale $objPage, wenn man die InsertTags in einem Cache-Eintrag ersetzt?
Das mit dem TinyMCE find ich nicht so trivial, da der ja egtl. Content generieren soll den man in verschiedenen Templates benutzen können soll. (Also ich möchte jetzt mein typografisches Markup als TeX haben zum Beispiel.) Wenn man garantieren kann, das der RTE wellformed produziert, dann sollte das mit XSLT ganz gut machbar sein, da er ja nur ein Subset von HTML produziert.

[andreas.schempp]

Nein, beim Cache wohl nicht, aber die meisten InsertTags werden gecacht.

[leo]

So, in der r671 sollte das neue Feature relativ stabil laufen.

[conta1234]

I love contao <3 <3 <3

[FloB]

Der Rich Text Editor kann nur entweder HTML5 oder XHTML generieren, …

Halte ich für vernachlässigbar. Gibt ja Inline für Fließtext nur weniger interessante HTML5-Elemente, meines Wissens. article und section sind ja eher in der Template-Ebene zu finden (Aufgrund der Struktur von Artikeln und CEs). Und wenn man inhaltliche Abschnitte innerhalb eines CEs (z. B. wg. SEO) markieren möchte, kann man das mit section ja machen, ob der IE das dann korrekt interpretiert oder nicht, ist da eher unerheblich. Selbiges gilt für InsertTags, wobei dort ja wie gesagt auf das Page-Objekt zugegriffen werden kann.


Und danke für das mehrgliedrige Templatesystem!

[tril]

Ich will auch nochmal bisl Senf dazu geben, um die Suppe zu würzen *g*

Ich bin froh zu lesen, dass der Ansatz Generieren den Vorzug vor Transformieren gefunden hat.
Wir sind dadurch deutlich flexibler und vor allem, keiner ist jetzt in irgendeiner Form gezwungen beim Update auf 2.10 alle Websites auf HTML5 zu schiffen.
Im anderen Fall sehe ich die Gefahr, dass für einen Großteil von bestehenden Contao Installationen der Update Aufwand extrem groß werden würde, aber das hat sich ja dann jetzt erledigt

So, der erste Commit steht kurz bevor. Wir haben aber auf jeden Fall zwei Probleme: Der Rich Text Editor kann nur entweder HTML5 oder XHTML generieren, wobei man da noch die Konfiguration je nach verwendetem Seitenlayout anpassen könnte. Dasselbe Problem gilt aber auch für Inserttags, nur dass diese definitiv keine Ahnung haben, auf welcher Seite sie ausgegeben werden.

Fällt irgendjemandem eine Lösung dazu ein?

In diesem Fall bleibt wohl nur Transformieren. Wenn nicht HTML5-Funktionalität verloren geht, wenn man XHTML nutzt, würde ich zu XHTML gehen, da XHTML-Syntax zu HTML5 kompatibel ist. imo umgekehrt aber nicht. So bräuchten wir überhaupt keine Transformation sondern betten einfach den XHTML-konformen Code, der gleichzeitig HTML5-konform ist in HTML5 ein.

MfG Tristan

[psren]

In diesem Fall bleibt wohl nur Transformieren. Wenn nicht HTML5-Funktionalität verloren geht, wenn man XHTML nutzt, würde ich zu XHTML gehen, da XHTML-Syntax zu HTML5 kompatibel ist. imo umgekehrt aber nicht. So bräuchten wir überhaupt keine Transformation sondern betten einfach den XHTML-konformen Code, der gleichzeitig HTML5-konform ist in HTML5 ein.

Wie @FloB schon meinte kann man da ohne größere Bedenken einfach den tinyMCE auf xHTML laufen lassen, da das eben auch HTML(5) valide ist. Es gibt einige inline-Tags in HTML(5) die man noch benutzen könnte z.B. <adress> etc.

Aber die kommen eher seltener vor und können dann ja immernoch direkt im HTML ergänzt werden.

[FloB]

z.B. <adress> etc.

Schlechtes Beispiel, der ist nämlich schon seit HTML 4 dabei (korrekt ist aber <address>) .

[kahlil]

Hi,
2 Sachen:

dieser Artikel beschreibt ausführlich wie man HTML5 im IE einsetzen kann ohne JS zu verwenden. http://debeterevormgever.nl/en/artic...out-javascript

Des weiteren zeigt dieser Artikel von 2007 wieviele Internetuser damals ohne JS surften: http://visualrevenue.com/blog/2007/0...led-index.html
1.4% in EU und 3.05% in US davon sind dann wiederum nur ein bestimmter Prozentsatz IE Benutzer. Nehmen wir an das sind 20% von 1,4% in EU dann surfen 0.28% der EU Internetuser mit IE ohne JS.

Diese Zahlen sind zwar nur Tendenzen, die reichen mir persönlich aber aus um XHTML zu knicken!

HTML5 FTW!

My 2 cents.

Gruss,
Kahlil

[backbone]

Gegenbeispiel:
Wieviele der Internetuser sind blind? Sicher < 1% und trotzdem ist Contao für blinde Nutzer optimiert.

[MacKP]

Ja, Statistiken sind was tolles ^^
Ihr geht komischerweise immer von 100% der Internetnutzer aus. So viele Leute hat aber kaum einer auf seiner Seite (ich leider auch nicht *g*).
Je nach Seite sind diese Werte also unterschiedlich. Manche werden durchaus mehr Benutzer haben, die kein JS an haben oder mehr die zu den Seheingeschränkten gehören.
Deswegen nutzen allgemeine Statistiken bei sowas eigentlich nie etwas.

So oder so ist der Plan ja jetzt ein anderer, der dann für alle flexiebel genug sein sollte um das zu machen was er/sie/es will.

Viele Grüße