Contao goes HTML5 & CSS3

Zitat:

---

Zitat von FloB

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.

---

Ich vermute du hast ihn felinterpretiert. :)
Es benoetigt in der Summe grob yberschlagen Aenderungen an 4-5 Stellen.
Die von mir gepostete Routine ist aus der Klasse Controller und wird von allen Extensions/core Modulen verwendet um das Template zu lokalisieren.
Wenn eine Extension HTML5 verwenden will, dann nutzt sie den zusaetzlichen Parameter und gibt hierbei dann das gewynschte Outputformat mit ('tpl' = fallback bzw. bisheriges "xhtml", 'tpl5' = HTML5, 'xml' = XML, 'tex' = TeX, ...).
Wer sowieso aktuell kein anderes Format benoetigt/bereitstellen kann als xhtml, der bleibt ohnehin beim momentanen Code.

Das zu verwendende Output Format koennte hierbei nun von einem Setting in TL_CONFIG definiert werden was dann bedeutet: "Benutze bitte HTML5 aber wenn das nicht da ist, dann nimm den Fallback."

In Extensions kann man die Parameter dann ggf. auch noch an die Frontend/BackendTemplates mitgeben, womit dann mehr Konstellationen moeglich sind.

• Benutze bitte XHTML fallback (Parameter $strTemplate).
• Benutze bitte HTML5 aber wenn das nicht da ist, dann nimm den Fallback (Parameter $strTemplate && $strTemplateSuffix).
• Benutze bitte nur HTML5 und schmeisse eine Exception wenn nicht gefunden (Parameter $strTemplate, $strTemplateSuffix && $blnMustBeNative).

Zitat:

---

Zitat von FloB

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

---

Man koennte in obiger Implementierung noch weiter gehen, und den Initialwert von $strTemplateSuffix direkt aus TL_CONFIG lesen (was dann ggf. in der PageRegular auf ein aktuelles Setting fyr den aktuellen page root yberschrieben wird). Dann sind wir noch kompatibler.

Zitat:

---

Zitat von FloB

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.

---

betr. zusaetzlicher Parameter: siehe in meinem Code: $blnMustBeNative welcher dieses Forcieren eines Ausgabeformats realisiert.
Extensionweite Option wird es wohl weniger geben, jedoch kann man das am pageRoot bzw. Seitenlayout/Seite aufhaengen.

Zitat:

---

Zitat von backbone

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

---

Nach außen hin sollte (zumindest für HTML) nur die bisherige Variante gelten. Es geht hier in erster Linie um die interne Dateiendung (sofern das als Identifikationsmerkmal gewählt wird) der Template-Dateien.


@xtra: Ok ;). Eine globale Einstellung sollte aber vorhanden sein, damit ein Admin auch sagen kann: Mir kommt kein HTML5 ins Haus, auch wenn die Extension das vorschreiben will (dann könnte man z. B. einen String Replace von 'tpl5' zu 'tpl' für alle Abweichler einsetzen*).

*Edit: Da muss dann natürlich darauf geachtet werden, dass Extensions z. B. nur mit HTML5-Templates ausgeliefert werden können und ein entsprechendes (natives) Fallback nicht existiert. Entweder nimmt man dann eine Exception in Kauf (und setzt somit ein natives Fallback zwingend voraus), oder es greift der von mir oben im Edit angesprochene Generator an.

Ich bezog mich mit dem SEO Problem eher auf das anfängliche Beispiel von leo-unglaub/lindesbs bzgl. verschiedene Templates.

Zitat:

---

Zitat von FloB

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.

---

1. Wenn Du möchtest, dass die Seite ohne "Gefrickel" läuft, verwende doch einfach HTML5 und nicht XHTML.

2. Für die Umwandlung sind genau 2 Funktionsaufrufe notwendig, einmal preg_replace und einmal str_replace. Kann mir keiner erzählen, dass diese beiden Aufrufe das System lahmlegen!

Der folgende Code reicht schon vollkommen aus:

PHP-Code:

---

// Complex replacements
$arrRegReplace = array
(
    '@<(base|br|hr|img|input|meta)([^>]*)>@' => '<$1$2 />',
    '@<(script|style)([^>]*)>\n@'            => '<$1$2>' . "\n/* <![CDATA[ */\n"
);

// Simple replacements
$arrStrReplace = array
(
    '/ />'            => '/>',
    '<script'         => '<script type="text/javascript"',
    '<style'          => '<style type="text/css"',
    "\n</script>"     => "\n/* ]]> */\n</script>",
    "\n</style>"      => "\n/* ]]> */\n</style>",
    '<html lang="'    => '<html xmlns="http://www.w3.org/1999/xhtml" lang="',
    '<meta charset="' => '<meta http-equiv="Content-Type" content="text/html; charset='
);

// Set the correct doctype
if ($this->doctype == 'xhtml_strict') {
    $arrStrReplace['<!DOCTYPE html>'] = '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">';
} else {
    $arrStrReplace['<!DOCTYPE html>'] = '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">';
}

// Execute the replacement functions
$strHtml = preg_replace(array_keys($arrRegReplace), array_values($arrRegReplace), $strHtml);
$strHtml = str_replace(array_keys($arrStrReplace), array_values($arrStrReplace), $strHtml); 


---

Ist nur ein Proof of Concept. Eventuell ziehen wir doch ein zweites Template-System hoch. Aber selbst dann wäre HTML5 das Fallback und XHTML die Option und nicht anders herum.

Am besten messen wir mal die Performance: Ein (grosses) HTML5-Dokument mit XHTML replacen. Ich kann mir nicht vorstellen, dass extrem rechenaufwändig ist. UND die meisten Page Requests können ja vom Cache bedient werden.

Nachtrag:
Weblication empfiehlt eine ähnliche Vorgehensweise. Siehe

http://devblog.weblication.de/blog/html5-nutzen.php

Was spricht denn dagegen, ein Konzept zu nutzen, welches bereits im Core vorhanden ist ?
Wir haben doch schon die Widgets fuer die DCA-Fields. Selbiges Verhalten laesst sich auch fuer das FE nutzen. Auch eben fuer div. Ausgabeformate.
Man muss nichts neues erfinden, nur das Vorhandene nutzen.

Zitat:

---

Zitat von leo

1. Wenn Du möchtest, dass die Seite ohne "Gefrickel" läuft, verwende doch einfach HTML5 und nicht XHTML.

2. Für die Umwandlung sind genau 2 Funktionsaufrufe notwendig, einmal preg_replace und einmal str_replace. Kann mir keiner erzählen, dass diese beiden Aufrufe das System lahmlegen!

---

1. Nun, klar, aber wie gesagt, 20% sind nicht zu verachten, und da bleibt ein Gefrickel, wenn es ein Non-JS-Fallback geben soll (und das muss es auch). Kein Gefrickel weil in Browsern voll implementiert ist leider nur XHTML (außer den hier vorgeschlagenen Teils aufwändigen oder wartungsintensiven Lösungsideen).

2. Die Zahl der Funktionsaufrufe ist nicht wirklich ausschlaggebend, sondern die CPU-Zeit und Speicherverbrauch kombininiert mit den Page Impressions (und je komplexer die Seite, desto stärker steigt der Verbauch ebendieser Faktoren). Ich sage nicht, dass dadurch jeder Server in die Knie geht, ich bezweifle stark, dass das bei mir passieren wird (mir ist auch durchaus bekannt, dass ab einem gewissen Load dezidierte Server aufgestellt werden sollten), aber es kann mir keiner erzählen, dass diese Methode keine signifikante Auswirkung auf die Performance hat. Nichtsdestotrotz bin ich sehr für Benchmarks, um mal die Konsequenzen anschaulich und statistisch gesichert betrachten zu können.

Ein Caching ist auch nicht die Lösung, da es Seiten gibt (auch bei mir), bei denen (technisch) keinerlei Caching möglich ist (außer natürlich von Partials, aber das ist in Contao ja leider nicht implementiert), beispielsweise geschützte (Login-)Bereiche.

Zitat:

---

Zitat von dave.matter

Nachtrag:
Weblication empfiehlt eine ähnliche Vorgehensweise. Siehe

http://devblog.weblication.de/blog/html5-nutzen.php

---

Naja, deren Vorschlag ist quasi nur ein Minimalkonsens und ungleich weniger umfangreich (und damit auch weniger rechenintensiv) als der von Leo vorgeschlagene Weg.

Sorry für den dritten Post in Folge, nochmal bezüglich Caching:
Ich könnte mich sehr mit einem "Präprozessor" für Templates anfreunden, der quasi aus den HTML5-Templates bei Requests "unfähiger" Browser zuerst ein (X)HTML-Template generiert. Voraussetzung ist, dass das nicht immer on-the-fly passiert, sondern das generierte "alte" Template gespeichert wird. Ob das dann nach 24h, wie beim übrigen Caching, verfällt, oder (theoretisch) für immer gültig ist, sei mal dahingestellt. Das wäre zwar nicht endgültig sauber, aber meines Erachtens noch deutlich sauberer als (womöglich on-the-fly) das fertig generierte Dokument nochmal durch den Reißwolf zu schicken.

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:

Code:

---

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

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.

Zitat:

---

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

---

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

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.

Zitat:

---

Zitat von xtra

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?

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

Zitat:

---

Zitat von leo

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)

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.

Zitat:

---

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

---

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

Zitat:

---

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

---

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

Finde das auch gut :D

Zitat:

---

Zitat von leo

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.

Klingt spitze! :):)

Zitat:

---

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

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

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.

Zitat:

---

Zitat von lucina

Contao rocks ... ;-)

---

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

<all thumbs up />

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

Zitat:

---

Zitat von leo

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)

HTML-Code:

---

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

Zitat:

---

Zitat von leo

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.

Zitat:

---

Zitat von leo

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.

Zitat:

---

Zitat von leo

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

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)

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

Zitat:

---

Zitat von leo

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

Zitat:

---

Zitat von sans

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

Zitat:

---

Zitat von pinball

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.

Zitat:

---

Zitat von xtra

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

Zitat:

---

Zitat von pinball

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.

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.

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?

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

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.

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

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

I love contao <3 <3 <3

Zitat:

---

Zitat von leo

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!

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

Zitat:

---

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

---

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

Zitat:

---

Zitat von tril

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.

Zitat:

---

Zitat von psren

z.B. <adress> etc.

---

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

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

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

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

Zitat:

---

Zitat von 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

---

sehr interessanter Use case und die Idee mit dem separaten xmlns gefaellt mir sehr gut.
Wobei ich da dann auch zu XHTML5 tendieren wyrde.
@leo: du willst wirklich nicht doch lieber die XML kompatible XHTML5 Variante verwenden?
Die hat zwar leider den Nachteil (bzw. IMO Vorteil) dass man keine Seite zu Gesicht bekommt, wenn die XML Notation fehlerhaft ist, aber ist dafyr noch besser Maschinenlesbar. :)

Gruss
Chris

PS: Den namespace koennte man dennoch als "IE Hack" einbauen und somit das JS loswerden.

was meinst du mit XML-Notation? Die (optionale) XML-Deklaration am Anfang (<?xml version="1.0" ... ?>) oder generell XML-Syntax (aka Wohlgeformtheit)?

Die Wohlgeformtheit (valides XML) => XHTML5.

Um das mal etwas individueller entscheiden zu können, hab ich einen kleinen Testcase zusammengebaut: http://learning.rostoff.de/xhtml5/
Bitte mal jeder der Zugang zu einem Browser hat, der noch nicht in den Results steht, alle Links durchklicken und schauen ob a) die section grün ist und b) der p bei hover blau wird.
Der optimale Standard wäre für mich:
http://learning.rostoff.de/xhtml5/in...&docType=false

Edit: Wenn jemand Lust hat, kann er gern mal ein bissl Reset-CSS oder so schreiben, um zu schauen, ob Quirksmode oder Standardmode aktiv ist.

Edit2: Ein Einstiegslink für IE: http://learning.rostoff.de/xhtml5/in...&docType=false

FF 3.6.16

Funktional:

• text/html <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE html>
• text/html <?xml version="1.0" encoding="UTF-8" ?>
• text/html <!DOCTYPE html>
• text/html

Alle anderen nicht.

Ok, das verwundert mich jetzt etwas, egtl sollte im FF3.6 auch alles gehen -.-
Kannst du das Problem lokalisieren, warum application/xhtml+xml nicht funktioniert?
Hab auch nochma im FF4 getestet, da gehen auch alle text/html Docs, jedoch triggern die ohne doctype den quirksmode, wenn ich das richtig sehe

Ok, ich hab das Ganze nochmal geupdated, da meine 0815 Browserdetection mist war und auch beim FF/Safari auf Win eine IE klasse mit reingehauen hat. (Verwende jetzt Browser.php aus der Erweiterung browserdetection.)

Auch wird jetzt das CSS manuell gesteuert (ob nur "section" oder "h5\:section" als Selektor genommen wird).

Wär nett wenn es einige (nochmals) durchtesten würden.

Zitat:

---

Zitat von backbone

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

---

Ja. Ist aber ein schlechter Vergleich. Einem IE-User der ohne JS surft kann man einen netten Hinweis zeigen der darauf hinweist dass die Seite am besten mit JS funktioniert und er kann es dann einschalten wenn er möchte.

Barrierefreiheit hingegen kann nicht einfach eingeschaltet werden.

Zitat:

---

Zitat von kahlil

... er kann es dann einschalten wenn er möchte.

---

Es ist halt so, dass jeder "einfach" JS einschalten kann, weil zum Beispiel irgendwelche Admins der Meinung sind, das es "gefährlich" ist... und grad diese Menge an Usern wird den Großteil derer ausmachen, die kein JS haben.

Also ich bin voll dafür das HTML 5 und CCS 3 eizug hält in contato.

Es würde mir vieles erleichtern beim Coden einer website. Ich denke da bei einfacheren sachen wie Radien, Schattierung usw. dass kann ich auch sofort anpassen und dem kunden zB einen grösseren Radius sofort zeigen, Ohne die Grafik (bild) erst editieren zu müssen.

Natürlich gibt es leute die noch ie6 oder weiss ich nicht was nutzt.
Aber ich denke in der heutigen Zeit ist man schnell up to date. Sowiso als Privater Nutzer. schwiriger wird es bei grossen Firmen, die nicht immer sofort up to date sind.

Ich finde HTML 5 & CSS3 coole sache.
man könnte ja den doctype html 5 auswählen können und dass css so händig anpassen mit radien und so weiter ..

LG
Marco

Zitat:

---

Zitat von MacPix

man könnte ja den doctype html 5 auswählen können und dass css so händig anpassen mit radien und so weiter

---

Radien etc. sind in 2.10 im Stylesheet-Editor mit eingebaut. Es manuell reinbauen kannst du auch schon bei der 2.9.5.

oder Erweiterung CSS3Styles verwenden...