Druckbare Version
Was ich noch vergessen habe:
Ich bin gegen JS-Frameworks, welche erstmal die komplette Seite "durch den Wolf drehen" und irgendwie solange auf dem DOM drauf rumreiten, bis Sie in inkompatiblen Browsern passt.
Hier sollte wirklich eine Serverseitige Lösung (sprich unterschiedliche Ausgabeformate) her.
< 9, nicht 6 - 6 ist irrelevant, wie vom Contao-Team schon deutlich gesagt. Und das mit den CSS-Navigationen würde ich auch nicht gerade unterschreiben...Zitat:
Zitat von dave.matter
Eine Seite, die ohne Javascript nicht wackelt, ajaxt, tooltippt oder sonstigen Eye-candy hat, ist ok. Aber sie muss ohne Javascript bedienbar sein, und zwar mit jedem halbwegs modernen Browser.
Schon allein da, spalten sich die Geister :(Zitat:
Zitat von christian
Bei manchen Funktionen (ich rede grad net von Eye-candy, wo man egtl immer nen brauchbares fallback finden kann), brauch man einfach JS oder die Funktion wird einfach scheiße.
Allgemein kann man viele integrale Kanten und Ecken mit JS rundschleifen, sofern man sich grad dran stößt.
Der "HTML-5-DOCTYPE" macht aus einem HTML-Dokument nicht einfach ein HTML5-Dokument. Wie gesagt, und wie auch von Anderen erneut erwähnt, besagt dieser DOCTYPE nichts anderes, als dass hier HTML folgt, Version unbekannt. Das kannst du gerne machen, HTML5 wurde ja auch extra so angelegt (sprich der DOCTYPE so gewählt), dass es abwärtskompatibel ist (also sich Browser an dem "neuen" DOCTYPE nicht verschlucken und in den Quirks-Modus wechseln). Aber:Zitat:
Zitat von leo
Die Umstellung ist in dem Moment nicht mehr abwärtskompatibel, ab dem die neuen syntaktischen HTML5-Tags verwendet werden. Und zwar nicht, weil es HTML5 ist, sondern weil IE<9 leider nicht damit zurechtkommt. Es geht nur (ohne JS), wenn man diesen noch als Fallback "alten" Code unterjubelt, z. B. so:Zitat:
Zitat von leo
Aber das gibt wieder nur Code-Salat (auch wenn man das ganze noch in Conditional Comments packt und IDs angleicht). Aber ich denke, dass viele auf ein sauberes non-JS-Fallback (also IE<9-Besucher müssen die Seite problemlos nutzen können) bestehen – und das ist leider mit deinem Vorhaben, Leo, nicht (zumindest nicht ohne massive Mehrarbeit seitens der Administratoren) vereinbar.HTML-Code:<div class="section" id="main-wrapper">
<section id="main">
[…]
</section>
</div>
Ich bleibe dabei: Eine komplette Umstellung (d. h. Einführung der HTML5-Tags ohne die aktuelle XHTML1-Variante beizubehalten) halte ich für bestehende Projekte nicht durchsetzbar, und für neue muss zunächst die Zielgruppe untersucht werden (denn, wie conta1234 zumindest einmal richtig anmerkt: Zu viele große Firmen sind noch mit XP und somit IE<9 unterwegs). Gegen den "HTML-5-DOCTYPE" habe ich aber absolut nichts einzuwenden. Und bitte XHTML5 mit (automatisch) richtigem MIME-Type (außer wieder für IE<9).
IE 6 ist und bleibt irrelevant, IMO auch IE 7, aber Version 8 leider nicht.
Edit: Das Backend kann meines Erachtens gerne die neuen HTML5-Tags verwenden, ich würde mal behaupten, dass man bei diesen Nutzern einen stets aktuellen Browser und auch aktiviertes JS voraussetzen kann.
@conta1234: Versteh das bitte nicht böse oder als herablassend: Deine Argumente sind großteils nicht grundlegend falsch, aber fast alle hier nicht angebracht. Ich bitte darum, dass du dich mit der Materie (syntaktische ”Programmierung", HTML5, DOM, Browser-Rendering, XML, CSS3, [maschinelle] Code-Interpretation, …) mehr beschäftigst (und das ist leider nicht in wenigen Stunden oder Tagen getan), bevor du hier dazu deine Meinung preisgibst. Und hier den Diskutierenden vorzuwerfen, sie könnten nicht "webdesign", ist (abgesehn von der falschen Wortwahl) nicht nur unangebracht, sondern auch frech.
Bez. "eye-candy" und "pur CSS Menüs": Zauberwort "progressive enhancement". Alles funktioniert prima auch in älteren Browsern (und sieht auch weder falsch noch unpassend aus), je aktueller der Browser, desto "hübscher" die Ansicht. Und dafür braucht man keinen Schnipsel JS. Selbst einen Fade würde ich heutzutage nur mit CSS-Transitions umsetzen wollen (gut, das will der Kunde öfters leider nicht …). Und welche essentiellen Funktionen sind ohne JS nicht "sauber" umsetzbar?
Aber vllt. sollten wir das lassen, gehört nicht zum Thema.
Kann man den doctype nicht ganz wegkicken bei HTML5 und mit application/xhtml+xml schicken. Oder wechseln die browser dann trotzdem in den quirks? Hat zwar jetzt nicht direkt was mit dem für oder wieder zu tun, aber "<!DOCTYPE html>" ist kein wohlgeformtes XML (da system id fehlt; korrigiert mich wenn ich falsch liege; wahrscheinlich verwechsel ich die IDs grad wieder), also auch kein XHTML5.
Die ganze Sache würde sich mit den von lindesbs vorgeschlagenen ausgeben von verschiedenen "views" komplett erledigen. (über die umsetzung dieser multi views kann man sich sicher streiten). BTW: was übrigens gleich noch mit in den multi view bereich fällt: das server caching von Contao noch etwas aufzubohren, sodass eine gecachte seite gar nicht mehr über php ausgegeben werden muss, sondern direkt mit mod_rewrite auf den cachefile gemappt wird.
Also eine Lösung bei der man das Ausgabeformat selbst wählen kann und abhängig von der Auswahl dann eine andere Templateendung gewählt wird fände ich perfekt.
Die verschiedenen Endungen wie .html5.tpl oder nur .tpl müssen ja nicht im Core mitgeliefert werden nur eine Möglichkeit wäre schön.
Jap - wenn es um sowas geht werde ich auch frech :D
Die Statistiken eurer wunderbaren Browserstatistikseiten berufen sich auf ca. 3 Mio Websites die durchgehend gescannt werden. Sehr schön... Wenn ich bei Google www eingeben bekomme ich 25.270.000.000 Ergebnisse...und das sind nur die mit www xD soll ich noch weiter machen? Ich halte es für höchst unprofessionell sich auf solche Statistiken zu berufen und was OS angeht, Windows XP erreicht trotz des allgemeinen Verkaufsstopps im Dezember 2008 einen Marktanteil von 48 % und ist damit weiter verbreitet als Windows Vista mit 14 % und Windows 7 mit 30 % (Stand: März 2011). Viele davon auf IE6 setzen möchte ich garnicht wissen, aber ich weiß zumindest wie viel möglich wären und das sagt mir genug. Zum Thema <9 kann ich nur sagen dass es den IE9 auf XP garnicht gibt/geben wird ;)
Und der Quirksmode ist ein NoGo für mich, die Gründe dafür kann euch FloB erklären - ich hab ja keine Ahnung auch auch keine Lust mehr...JS als Basis für "normales" rendering geht ebenfalls garnicht und vor allem auch anders. Und für alle die sich irgendwie angegriffen gefühlt haben: Ich habe doch garnichts gegen HTML5 - Ich sage lediglich das ich es unmöglich finde, ohne Abwärtskompatiblität bzw. modularen Aufbau -> Templates usw. in dieser Sache vorzugehen! Für einen 100%igen Umstieg ist es meiner Meinung nach viel zu früh! Tut mir leid wenn sich jemand angegriffen gefühlt hat. Ich finde Leos Idee an sich sehr gut und die Entwicklung wird dadurch natürlich im Interesse aller nach vorn gebracht aber wie gesagt - nicht ohne .tpl5 :p
Das JS-Fallback wird doch nur für den IE 6-8 benötigt. Alle anderen Browser kommen sehr gut mit den neuen Tags klar. Und ganz ehrlich: Der IE, speziell die Version 6, kommt heutzutage doch sowieso nicht ohne CSS-Hacks und JavaScript-Krücken aus. Was macht da ein Skript mehr für einen Unterschied?Zitat:
Zitat von jared
Ich hatte früher mal einen alten VW Käfer, bei dem man beim Tanken immer Bleizusatz hinzugeben musste. Die ganzen neuen Autos kamen mit bleifreiem Benzin prima zurecht, deswegen gab es an der Tankstelle auch nur noch solches. Weil ich aber ein veraltetes Modell fahren wollte, musste ich mir den Zusatz besorgen.
Warum erzähle ich das? Der VW Käfer ist der IE6, das bleifreie Benzin der HTML5-Standard und der Bleizusatz das html5.js-Skript. Wer unbedingt mit einem veralteten Browser-Modell unterwegs sein möchte, muss damit rechnen, dass Software irgendwann inkompatibel wird. Dies lässt sich dann eben nur über bestimmte Hilfsmittel wie den Bleizusatz bzw. das html5.js-Skript abfangen. Man kann nicht erwarten, dass die Tankstellen (Software-Hersteller) für immer und ewig bleihaltiges Benzin vorhalten, während der Rest der Welt schon im Elektroauto fährt!
Und der Vollständigkeit halber noch mal der Hinweis: Selbst Microsoft möchte, dass der IE6 vom Markt verschwindet! http://ie6countdown.com/
Hallo leo,Zitat:
Zitat von leo
hier geht es eben nicht nur um den IE6.
Ich schau immer noch, das es unter dieser Version funktioniert. Die Diskusion können wir uns aber sparen. Das findet ja eh kein Ende (jeder hat da seine Meinung und bleibt anscheinend auch dabei).
IE7 und erst recht IE8 bekommen dann das passende nur mit JS. Das ist der Punkt über den Diskutiert werden sollte.
Genau da fängt es dann an ungemütlich zu werden.
Viele Grüße
Die 8 da drin ist das Problem. 6 ist wurscht, 7 meinetwegen auch (wer das Update gemacht hat, kann auch das auf 8 machen).Zitat:
Zitat von leo
Wenn es nur ein paar Tags sind, mit denen der 8er nicht klarkommt, kann man nicht wenigstens dort eine Fallunterscheidung reinbauen - wieviele/welche sind das überhaupt, gibt's da eine Übersicht?
<ironie>
Oder wir bauen ein wenig Flash ein, damit's auf dem iPad wenigstens auch nicht läuft.
</ironie>
Zitat:
Zitat von christian
Siehe oben.Zitat:
Zitat von lucina
Carolina.
Also abgesehen davon, dass hier alle einer anderen Meinung sind, würde ich generell Leo darum bitten hier keine HTML5 Experimente in 2.10 einzubauen die nicht mehr rückgängig zu machen sind. (Geht hier nicht um ein HTML5 fe_page.tpl, sondern das irgendwelche Core-Klassen mit Scheuklappen Richtung HTML5 gedreht werden).
Davon mal abgesehen sind sich sicher alle einig das man im Backend ruhig auf HTML5 + CSS3 + JS setzen kann, sprich als "Systemvorraussetzung" nehmen kann. Zumindest JS halte ich für VIEL zu wenig benutzt im Backend.
Ich betone hier gerne nochmal: Für IE 8 & 7 auf irgendwelche JS-Libs zu setzen, ist für mich persönlich ein absolutes No-Go. Wenns hier um irgendwelches nichtintegrales Canvas zeug gehen würde, wo man ein schickes Fallback designen kann, ok... aber was gar nicht geht sind Navigationen die man nicht findet, nicht da sind oder nicht benutzbar sind.
Also scheint die eigendliche Frage zu sein:
Wie hoch ist der Antel von IE8,7 und meinetwegen 6 Usern, die ohne Javascript unterwegs sind. Kennt irgendwer von euch hierzu eine Statistik?
Wie auch die von lucina schon zweimal verlinkte Seite gut zeigt, ist es eben nicht so, dass wir hier von einem Uralt-Browser wie IE6 reden, sondern von relativ aktuellen Browsern wie einem IE8. Bedenkt bitte, dass die Nutzer gar nicht auf IE9 updaten können, wenn sie noch Windows XP nutzen (und das tun sehr viele)!
Wenn man Statistiken wie denen von W3Schools folgt, sieht man deutlich, dass von dem knappen Viertel der Browser-Nutzer die auf den IE setzen, der absolut größte Teil noch auf IE8-Basis läuft. Oder anders ausgedrückt, wir würden laut der Statistik bei mindestens 18% aller Webseiten-Benutzer (die IE8-Nutzer) einen JS-Zwang voraussetzen, nur damit sie überhaupt die Grundelemente der Webseite brauchbar sehen (ohne die das ganze Gerüst einfach zusammenbricht, wenn sie falsch interpretiert werden!).
Ich denke, dass sich hier schon eine sehr deutliche Mehrheit für den Punkt "HTML5 gerne, aber nicht radikal ab der 2.10 nur noch die neuen Elemente wie <header> <section> <nav> etc." abzeichnet. Eine zwingende "Lösung" via JS für einen so aktiven Browser wie IE8 nur, damit die Grundelemente der Website überhaupt funktionieren, ist schon äußerst radikal.
Wenn es aber eh nur um diese Grundelemente geht, dann ist imho der Aufwand überschaubar, dass man hier eine Weiche einbaut und der Admin selbst z. B. in den Settings festlegen kann, ob er (Standardeinstellung) die Ausgabe als <div id="header"> haben will, oder ob er (müsste bewusst vom Admin gewählt werden) schon auf das riskante Pferd <header> setzt.
Diese Herangehensweise hätte den deutlichen Vorteil, dass eben niemand gezwungen wird seine bisherige Website anzupassen, weil die Default-Einstellung die Elemente wie bisher belässt. Die Extension-Entwickler trifft es auch nicht, denn wie Leo schon sagte, spricht er eh nur von den paar Grundelementen wie <header> <section> <nav> etc., so dass sie ihre Templates wie bisher lassen könnten.
Also nochmal klar meine Meinung:
JA zu HTML5-Unterstützung, aber nur wenn auch das gilt:
JA zu Wahlmöglichkeit, wie die Grundelemente in der Website ausgegeben werden, wobei der Default die bisherige (XHTML)-Herangehensweise sein sollte.
@psren: So kannst du auch nicht ran gehen, denn ich habe schon öfter gesehen, dass in Firmen zwar JS theoretisch im Browser aktiv wäre, aber die restriktiven Antivirenprogramme das JS dann blockten. Sowas lässt sich imho in keiner Statistik erfassen, da der Browser ja vielleicht noch für ne Hundertselsekunde die Info "ich kann JS" schickt, bevor das Antivirusprogramm dann blockt.
Wir sollten den x-tausenden Contao-Webseitenbetreibern so oder so aber nicht aufzwingen, dass sie einer Philosophie von "geht nur mit JS" folgen müssen. Das wäre schlechter Stil.
Für "hübsche" Effekte oder Teilbereiche einer Website kann man diese Doktrin als Webdesigner bewusst in Kauf nehmen, aber doch nicht für eine gesamte Website. Zumindest aber sollte die Wahlmöglichkeit immer für den Admin bestehen - und unter Wahlmöglichkeit verstehe ich nicht, dass abertausende Contao-Websites zwingend in den Templates deswegen von den Betreibern modifiziert werden müssen. Das würden die Leute Contao nicht danken, sondern wären wahrscheinlich extrem sauer, dass man sie derart bevormundet.
Deshalb wäre doch die '.tpl5' bzw. '.html5.tpl' Lösung so Elegant, weil man könnte im Core die XHTML .tpl beibehalten und die '.tpl5' dann entweder als Erweiterung oder im Core oder garnicht zur Verfügung Stellen und das kann dann ja jeder machen wie er will.
Hätte auch den Vorteil dass ich in einer Installation eine HTML(5) Seite und eine XHTML Seite verwalten könnte (Firmenseite XHTML und Spielwiese HTML5 oder so).
imo die beste Lösung. Das man die ie6/ie7 Unterstützung fallen lassen kann denke ich auch, weil wer unbedingt ie6 unterstützen will, der weiß im normalfall auch wie das geht.
Templates fix über die Dateiendung einem View zuschustern ist überhaupt nicht elegant und erst recht nicht flexibel. Es soll durchaus Seiten geben, die 2 verschiedene XHTML Views definieren wollen. Das ist zur Zeit nur mit den Themes umsetzbar, was allerdings ein Mirror der ganzen Module erfordert...
Ich sehe schon, wohin diese Diskussion läuft. Vorschlag zur Güte: Wir bieten weiterhin im Seitenlayout die Wahl zwischen XHTML und HTML5 an. Intern verwenden wir jedoch HTML5 und passen die Ausgabe bei Bedarf mit Hilfe von Text-Ersetzungen an XHTML an. Dadurch können wir sowohl Tags wie BR und IMG korrekt schließen, als auch die neuen Tags wie SECTION, ARTICLE etc. wieder in DIVs verwandeln.
Meinst du mit "intern" das Backend?Zitat:
Zitat von leo
Danke für die Übersetzung :D
@leo: Das klingt gut :)
Hallo Leo,
ich denke, dass das ein guter Kompromiss ist. Somit ist zumindest der "1. Schritt" im Core Richtung HTML5 gegangen.
Gruß Alex
Mit str_replace? Abgesehen davon, das dann wie blöd auf dem Output drauf rumgeritten wird, was massig Performance kostet, ist das ganze total "error-phrone", kleines Beispiel:
müsste zuHTML-Code:<section id="blub" class="bla"></section>
werden...HTML-Code:<div class="section bla" id="blub"></div>
Dafür brauchst schon mindestens RegEx, was das ganze noch VIEL schlimmer machen wird, sowohl in Sachen performance, als auch Handhabbarkeit.
Wenn man so eine Ersetzung wirklich "sauber" machen will, dann geht eh nur XSLT... was aber auch nicht wirklich performant ist.
Wie gehen denn die anderen grossen CMS mit der Thematik um?
Beim TYPO3 Backend wird auch HTML5 verwendet, für abwärtskompatibiltät nehmen die modernizer.
Und Frontend? Wegen dem Backend hat hier imho ja eh keiner Probleme.Zitat:
Zitat von schman
Was im Endeffekt mehr Implementierungsaufwand ist als die von lindesbs vorgeschlagene Weiche, da es hoechst komplexe regexe erfordert/ein parsen des DOM tree wenn es error prone sein soll.Zitat:
Zitat von leo
IMO passt da die von lindesbs vorgeschlagene Weiche in der Art von (untested Pseudocode) doch besser:
Damit kann dann jede Extension ein Template in beliebigem Format anfordern und bekommt (sofern optionaler Parameter $blnMustBeNative==false) automatisch das fallback Template als XHTML.PHP-Code:protected function getTemplate($strTemplate, $strTemplateSuffix='tpl', $blnMustBeNative=false)
{
$strPath = TL_ROOT . '/templates';
$strTemplate = basename($strTemplate);
// Check the templates subfolder
if (TL_MODE == 'FE')
{
global $objPage;
$strTemplateGroup = str_replace('../', '', $objPage->templateGroup);
$strTemplateGroup = preg_replace('@^templates/@', '', $strTemplateGroup);
if ($strTemplateGroup != '')
{
$strFile = $strPath . '/' . $strTemplateGroup . '/' . $strTemplate . '.' . $strTemplateSuffix;
if (file_exists($strFile))
{
return $strFile;
}
}
}
// Check the templates directory
$strFile = $strPath . '/' . $strTemplate . '.' . $strTemplateSuffix;
if (file_exists($strFile))
{
return $strFile;
}
// Browse all module folders
foreach ($this->Config->getActiveModules() as $strModule)
{
$strFile = TL_ROOT . '/system/modules/' . $strModule . '/templates/' . $strTemplate . '.' . $strTemplateSuffix;
if (file_exists($strFile))
{
return $strFile;
}
}
// still not found, check if it was an non standard extension and try to find a XHTML Template if graceful degration is allowed.
if($strTemplateSuffix != 'tpl' && !$blnMustBeNative)
return $this->getTemplate($strTemplate);
throw new Exception(sprintf('Could not find template file "%s"', $strTemplate));
}
}
Das dann in die TemplateKlassen einzubauen sollte auch moeglich sein (switch in TL_CONFIG auswerten).
Entsprechende Adaption an Controller::getTemplateGroup() etc. steht hierbei noch aus.
Im allgemeinen bin ich massiv gegen str_replace und preg_replace Orgien.
Man sollte nicht einen riesen String bauen, der dann hin und her geschubst und umgeschrieben wird. Besonders nicht, wenn es mind. 18% aller meiner User betrifft (siehe Nina oben). Den IE7 und andere "alternative" Browser noch nicht mal mitgezaehlt.
Der Rechenaufwand ist hiebei einfach zu hoch und man kann auch nicht ohne Ende vom Servercache profitieren.
Meiner Meinung nach begeben wir uns auf sehr dynnes Eis hinsichtlich Skalierbarkeit, wenn wir nun versuchen an allen Ecken und Enden string replace Operationen vorzunehmen.
Gruss
Chris
TYPO3 hat dieses Problem einfach nicht, weil du ja alles Typo-Script'en kannst und außerdem hat Typo3 verschiedene Ausgabetypen.Zitat:
Zitat von Nina
Aber der Vorschlag von lindesbs&Xtra gefällt mir :)
Wenig Aufwand für volle Flexibilität ohne die Geschwindigkeit zu gefährden.
String-Replace-Funktionen wären auch nur das Fallback wenn die tidy-Erweiterung nicht vorhanden ist. Und im Cache landet natürlich die bereits angepasste Version, so dass die Umwandlung nur einmal gemacht werden muss. Das ist immer noch weit weniger Arbeit als ein komplettes zweites Template-System!
http://de.wikipedia.org/wiki/Stichprobe und http://de.wikipedia.org/wiki/Projektion_%28Statistik%29. Und viel relevanter: Unter den drei Million sind so manche Schwergewichte mit tlw. Hunderttausenden bis Millionen von Impressions pro Tag. Die sind wahre Indikatoren für die Marktanteile der Nutzer, nicht die Hundertausende und Millionen von "Mini-" oder Privatseiten von Benno dem Hund und ihrer stolzen Besitzerin mit höchstens 100 Impressions pro Monat.Zitat:
Zitat von conta1234
Und zu guter Letzt kann ich die statistischen Werte einigermaßen mit den Werten der Websites, die ich betreue, verifizieren, da zeichnet sich sogar ein viel deutlicherer Trend zu (wirklich) modernen Browsern ab, aber das ist zum Teil auch Zielgruppeneffekten geschuldet (Kreativbranche usw.) – das bestätigt erneut: Wenn die Zielgruppe einer Website z. B. eher mittelständische, "träge" Unternehmen sind, ist davon auszugehen, dass man einen deutlich erhöhten Anteil von IE<9 hat, und entsprechend darauf eingestellt sein muss, inkl. (z. B. aus Sicherheitsgründen) fehlender JS-Unterstützung!
Edit: Ab hier nicht mehr aktuell, ich Penner hab vor dem Antworten keinen Reload gemacht … sorry.
… und dann geht die ganze Website den Bach hinunter, wenn JS die Fehler von Microsoft in IE8 (und früher, wenn es denn beachtet werden soll) ausbügeln soll. Und wie Nina dankenswerterweise anmerkte: Ein Marktanteil von fast 20% ist nicht zu missachten! Und es ist nicht immer nur "Corporate Policy", wenn JavaScript deaktiviert ist, denn bei vergangenen Sicherheitslücken wurde oft empfohlen, JavaScript zu deaktivieren, oder der Virenschutz erledigt das.
Ich kann es nur nochmal wiederholen: Die neuen semantischen HTML5-Tags zwingend in Contao 2.x im Frontend einzuführen, halte ich zumindest für die nächsten zwei Jahre (wenn der Security Support für XP endet) nicht für tragbar und sinnvoll, schon gar nicht mit einem pur-JS-Fallback.
Wer noch mehr zum falschen Rendering unbekannter Elemente in IE8 (und älter) wissen möchte, dem Empfehle ich die Erklärung im WHATWG Blog: http://blog.whatwg.org/supporting-new-elements-in-ie
Bezüglich der neuen Beiträge, die mir mangels Reload entgangen sind:
Kann ich nur vollkommen zustimmen. Auch wenn zunächst versucht wird mit Tidy zu kommen (was meines Erachtens auf den wenigsten Servern zur Verfügung gestellt wird, und da kommen wir wieder mit dem 20%-Betroffene-Problem – dieses Fallback kann man bei einem Marktanteil von <10% von betroffenen Browsern einsetzen).Zitat:
Zitat von backbone
Ein Gefrickel mit str_replace / preg_* oder gar Tidy kann ich leider weder dem Kunden ("Wieso ist die Seite so langsam??", "Warum stürzt mein Server ab??") noch dem Server und zugehörigem Admin verkaufen. Es würde auch vor allem den memory-Footprint weiter erhöhen, was gar nicht zu dem schlanken Image (bezogen auf Ressourcen) von Contao passt.
Ich bin stark für die zusätzliche .tpl5-Variante, auch wenn es nicht (wie angemerkt) ganz sauber ist: Es ist die Variante mit dem wenigsten Aufwand, bietet ein wunderbar 100%ig kompatibles und schnelles Fallback, benötigt keine Extraarbeit (wenn man nicht will), funktioniert auch bei verschiedenen Partials. Es ist ein progressive enhancement, quasi auch als "Testbed" für Contao 3 (in dieser Version kann man sich dann von XHTML1 verabschieden, da eine bewusste Entscheidung seitens der Entwickler getroffen werden kann – ich bezweifle, dass jemand seine Seite ohne viel Aufwand direkt auf Contao 3 portieren wird, bei Updates von 2.x auf 2.y ist das ja, v. a. dank LiveUpdate, etwas ganz anderes).
Ich würde allerdings nicht ganz die von xtra vorgeschlagene Änderung befürworten (vorausgesetzt, ich interpretier den Code richtig), da es im gesamten Contao Code doch relativ viel Änderung bedeutet. Stattdessen würde ich eine globale Einstellung anbieten, die, wenn die Einstellung entsprechend gesetzt ist, automatisch das HTML5-Template wählt (als Fallback natürlich das "normale" Template sucht). Damit sich niemand bevormundet fühlt, empfehle ich einen zusätzlichen Parameter, der diese Einstellung für ein Template überschreiben kann (à la $forceExtension='tpl5'|'tpl'), ggf. sogar eine Extension-weite Option (wenn das technisch in Contao möglich ist), die für alle Templates einer Extension die "Dateiendung" (oder wie auch immer die Varianten identifiziert werden) vorschreibt.
Edit: Das Argument, quasi ein zweites Template-System mit entsprechendem Aufwand einzuführen, kann ich nicht ganz anerkennen. Erstens betreffen neue syntaktische HTML5-Tags nur vergleichsweise wenige Templates (insbesondere fe_page, Navigation, Artikel), zweitens kannst du, Leo, ja durchaus lokal einen Regex basteln, der aus HTML5-Templates durch Ersetzungen die "alten" Templates generiert (und abspeichert), somit hast du eigentlich keinen Mehraufwand (außer einmalig den Regex und Build-Skript schreiben). Vielleicht kann man das sogar in den Core verfrachten und immer "alte" Templates generieren lassen, wannimmer "nur" neue Templates auftauchen, vorausgesetzt, diese werden dann z. B. im /templates/-Ordner fix abgespeichert und nicht ständig oder regelmäßig, sondern nur "auf Zuruf" neu generiert.
Ein problem was noch aufkommt bzgl. der Templatewahl via URL: SEO.
http://domain.tld/start.html
ist für Suchmaschinen eine komplett andere Seite wie
http://domain.tld/start.html5
Also muss man dieses Template-Switching sowie so über ein Mapping "Browser->Templatetyp" machen und wie gesagt um das ganze dann noch sinnvoll für "Multiviews" zu machen müsste man diese Mappingregeln editieren können in einem Gewissen Scope.
Ich vermute du hast ihn felinterpretiert. :)Zitat:
Zitat von FloB
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).
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
betr. zusaetzlicher Parameter: siehe in meinem Code: $blnMustBeNative welcher dieses Forcieren eines Ausgabeformats realisiert.Zitat:
Zitat von FloB
Extensionweite Option wird es wohl weniger geben, jedoch kann man das am pageRoot bzw. Seitenlayout/Seite aufhaengen.
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.Zitat:
Zitat von backbone
@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.
1. Wenn Du möchtest, dass die Seite ohne "Gefrickel" läuft, verwende doch einfach HTML5 und nicht XHTML.Zitat:
Zitat von FloB
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:
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.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);
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.
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).Zitat:
Zitat von leo
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.
Naja, deren Vorschlag ist quasi nur ein Minimalkonsens und ungleich weniger umfangreich (und damit auch weniger rechenintensiv) als der von Leo vorgeschlagene Weg.Zitat:
Zitat von dave.matter
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.