Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 41 bis 80 von 132

Thema: Contao goes HTML5 & CSS3

  1. #41
    AG Core-Entwicklung
    Registriert seit
    16.10.2009.
    Ort
    Bad Lausick
    Beiträge
    437

    Standard

    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.
    Ihr Partner für Contao und Webentwicklung: http://www.hofff.com.

  2. #42
    Alter Contao-Hase Avatar von christian
    Registriert seit
    15.06.2009.
    Ort
    Viersen
    Beiträge
    1.038
    Partner-ID
    387

    Standard

    Zitat Zitat von dave.matter Beitrag anzeigen
    Also wir wären weiterhin schön barrierefrei und clean ;-) Ausser für IE6-User, welche JavaScript nicht aktiviert haben, aber die werden bei 90% der Websites so oder so aussen vor gelassen (Gibt ja z.B praktisch keine rein CSS basierten Navigationen mehr).
    < 9, nicht 6 - 6 ist irrelevant, wie vom Contao-Team schon deutlich gesagt. Und das mit den CSS-Navigationen würde ich auch nicht gerade unterschreiben...

    Eine Seite, die ohne Javascript nicht wackelt, ajaxt, tooltippt oder sonstigen Eye-candy hat, ist ok. Aber sie muss ohne Javascript bedienbar sein, und zwar mit jedem halbwegs modernen Browser.
    Contao-Partner am Niederrhein
    Templating - Komplettservice - Erweiterungen
    Infos: http://delahaye.de

  3. #43
    AG Core-Entwicklung
    Registriert seit
    16.10.2009.
    Ort
    Bad Lausick
    Beiträge
    437

    Standard

    Zitat Zitat von christian Beitrag anzeigen
    Eine Seite, die ohne Javascript nicht wackelt, ajaxt, tooltippt oder sonstigen Eye-candy hat, ist ok. Aber sie muss ohne Javascript bedienbar sein, und zwar mit jedem halbwegs modernen Browser.
    Schon allein da, spalten sich die Geister

    Bei manchen Funktionen (ich rede grad net von Eye-candy, wo man egtl immer nen brauchbares fallback finden kann), brauch man einfach JS oder die Funktion wird einfach scheiße.
    Allgemein kann man viele integrale Kanten und Ecken mit JS rundschleifen, sofern man sich grad dran stößt.
    Ihr Partner für Contao und Webentwicklung: http://www.hofff.com.

  4. #44
    Contao-Urgestein Avatar von FloB
    Registriert seit
    19.06.2009.
    Ort
    Sonnensystem
    Beiträge
    1.618

    Standard

    Zitat Zitat von leo Beitrag anzeigen
    Wieso nicht? Es ändert sich doch erstmal gar nichts außer dem DOCTYPE. Und faktisch ändert sich dadurch überhaupt nichts, denn wie gesagt stand bisher zwar "XHTML" drüber, aber aufgrund des fehlenden XML-Tags und XML-Headers hat es in Contao schon immer nur HTML-Seiten gegeben!
    Der "HTML-5-DOCTYPE" macht aus einem HTML-Dokument nicht einfach ein HTML5-Dokument. Wie gesagt, und wie auch von Anderen erneut erwähnt, besagt dieser DOCTYPE nichts anderes, als dass hier HTML folgt, Version unbekannt. Das kannst du gerne machen, HTML5 wurde ja auch extra so angelegt (sprich der DOCTYPE so gewählt), dass es abwärtskompatibel ist (also sich Browser an dem "neuen" DOCTYPE nicht verschlucken und in den Quirks-Modus wechseln). Aber:

    Zitat Zitat von leo Beitrag anzeigen
    Insofern ist die Umstellung bisher vollständig abwärtskompatibel!
    Die Umstellung ist in dem Moment nicht mehr abwärtskompatibel, ab dem die neuen syntaktischen HTML5-Tags verwendet werden. Und zwar nicht, weil es HTML5 ist, sondern weil IE<9 leider nicht damit zurechtkommt. Es geht nur (ohne JS), wenn man diesen noch als Fallback "alten" Code unterjubelt, z. B. so:
    HTML-Code:
    <div class="section" id="main-wrapper">
    <section id="main">
    […]
    </section>
    </div>
    Aber das gibt wieder nur Code-Salat (auch wenn man das ganze noch in Conditional Comments packt und IDs angleicht). Aber ich denke, dass viele auf ein sauberes non-JS-Fallback (also IE<9-Besucher müssen die Seite problemlos nutzen können) bestehen – und das ist leider mit deinem Vorhaben, Leo, nicht (zumindest nicht ohne massive Mehrarbeit seitens der Administratoren) vereinbar.

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

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

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


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


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

  5. #45
    AG Core-Entwicklung
    Registriert seit
    16.10.2009.
    Ort
    Bad Lausick
    Beiträge
    437

    Standard

    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.
    Ihr Partner für Contao und Webentwicklung: http://www.hofff.com.

  6. #46
    Contao-Urgestein
    Registriert seit
    07.04.2010.
    Ort
    Stuttgart
    Beiträge
    2.733
    User beschenken
    Wunschliste

    Standard

    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.

  7. #47
    Contao-Nutzer
    Registriert seit
    11.11.2010.
    Beiträge
    154

    Standard

    Jap - wenn es um sowas geht werde ich auch frech

    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

  8. #48
    Contao-Hauptentwickler
    AG Core-Entwicklung
    Avatar von leo
    Registriert seit
    05.06.2009.
    Ort
    Wuppertal
    Beiträge
    816

    Standard

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

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

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

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

  9. #49
    Contao-Yoda Avatar von MacKP
    Registriert seit
    15.06.2009.
    Ort
    Duisburg
    Beiträge
    13.292
    User beschenken
    Wunschliste
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Zitat Zitat von leo Beitrag anzeigen
    Das JS-Fallback wird doch nur für den IE 6-8 benötigt. Alle anderen Browser kommen sehr gut mit den neuen Tags klar.
    Hallo leo,
    hier geht es eben nicht nur um den IE6.
    Ich schau immer noch, das es unter dieser Version funktioniert. Die Diskusion können wir uns aber sparen. Das findet ja eh kein Ende (jeder hat da seine Meinung und bleibt anscheinend auch dabei).
    IE7 und erst recht IE8 bekommen dann das passende nur mit JS. Das ist der Punkt über den Diskutiert werden sollte.
    Genau da fängt es dann an ungemütlich zu werden.

    Viele Grüße
    Contao Pool | C-C-A | MetaModels | [Internetseite -> Mediendepot Ruhr]
    [Arbeitet bei -> Paus Design & Medien]
    "I can EXPLAIN it to you, but I can't UNDERSTAND it for you."

  10. #50
    Alter Contao-Hase Avatar von christian
    Registriert seit
    15.06.2009.
    Ort
    Viersen
    Beiträge
    1.038
    Partner-ID
    387

    Standard

    Zitat Zitat von leo Beitrag anzeigen
    nur für den IE 6-8 benötigt.
    Die 8 da drin ist das Problem. 6 ist wurscht, 7 meinetwegen auch (wer das Update gemacht hat, kann auch das auf 8 machen).

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

    <ironie>
    Oder wir bauen ein wenig Flash ein, damit's auf dem iPad wenigstens auch nicht läuft.
    </ironie>
    Contao-Partner am Niederrhein
    Templating - Komplettservice - Erweiterungen
    Infos: http://delahaye.de

  11. #51
    Administratorin Avatar von lucina
    Registriert seit
    19.06.2009.
    Ort
    Kiel (DE)
    Beiträge
    7.335
    Partner-ID
    152
    User beschenken
    Wunschliste
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Zitat Zitat von christian Beitrag anzeigen
    Wenn es nur ein paar Tags sind, mit denen der 8er nicht klarkommt, kann man nicht wenigstens dort eine Fallunterscheidung reinbauen - wieviele/welche sind das überhaupt, gibt's da eine Übersicht?
    Zitat Zitat von lucina Beitrag anzeigen
    Naja, wenn ich mir http://caniuse.com/#cats=HTML5&sort=score mal anschaue,
    Siehe oben.
    Carolina.

  12. #52
    AG Core-Entwicklung
    Registriert seit
    16.10.2009.
    Ort
    Bad Lausick
    Beiträge
    437

    Standard

    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.
    Ihr Partner für Contao und Webentwicklung: http://www.hofff.com.

  13. #53
    Contao-Urgestein
    Registriert seit
    07.04.2010.
    Ort
    Stuttgart
    Beiträge
    2.733
    User beschenken
    Wunschliste

    Standard

    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?

  14. #54
    Administrator Avatar von Nina
    Registriert seit
    04.06.2009.
    Ort
    Hamburg
    Beiträge
    4.755
    Contao-Projekt unterstützen

    Support Contao

    Standard

    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.
    Geändert von Nina (13.04.2011 um 09:47 Uhr)

  15. #55
    Contao-Urgestein
    Registriert seit
    07.04.2010.
    Ort
    Stuttgart
    Beiträge
    2.733
    User beschenken
    Wunschliste

    Standard

    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.

  16. #56
    AG Core-Entwicklung
    Registriert seit
    16.10.2009.
    Ort
    Bad Lausick
    Beiträge
    437

    Standard

    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...
    Ihr Partner für Contao und Webentwicklung: http://www.hofff.com.

  17. #57
    Contao-Hauptentwickler
    AG Core-Entwicklung
    Avatar von leo
    Registriert seit
    05.06.2009.
    Ort
    Wuppertal
    Beiträge
    816

    Standard

    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.

  18. #58
    Administrator Avatar von Nina
    Registriert seit
    04.06.2009.
    Ort
    Hamburg
    Beiträge
    4.755
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Zitat Zitat von leo Beitrag anzeigen
    Intern verwenden wir jedoch HTML5
    Meinst du mit "intern" das Backend?

  19. #59
    Administrator Avatar von Nina
    Registriert seit
    04.06.2009.
    Ort
    Hamburg
    Beiträge
    4.755
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Danke für die Übersetzung

    @leo: Das klingt gut

  20. #60
    Community-Moderator Avatar von alex
    Registriert seit
    05.06.2009.
    Ort
    Wuppertal
    Beiträge
    702

    Standard

    Hallo Leo,

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

    Gruß Alex

  21. #61
    AG Core-Entwicklung
    Registriert seit
    16.10.2009.
    Ort
    Bad Lausick
    Beiträge
    437

    Standard

    Mit str_replace? Abgesehen davon, das dann wie blöd auf dem Output drauf rumgeritten wird, was massig Performance kostet, ist das ganze total "error-phrone", kleines Beispiel:
    HTML-Code:
    <section id="blub" class="bla"></section>
    müsste zu
    HTML-Code:
    <div class="section bla" id="blub"></div>
    werden...
    Dafür brauchst schon mindestens RegEx, was das ganze noch VIEL schlimmer machen wird, sowohl in Sachen performance, als auch Handhabbarkeit.
    Wenn man so eine Ersetzung wirklich "sauber" machen will, dann geht eh nur XSLT... was aber auch nicht wirklich performant ist.
    Ihr Partner für Contao und Webentwicklung: http://www.hofff.com.

  22. #62
    Contao-Fan Avatar von tinoo
    Registriert seit
    19.06.2009.
    Ort
    made in switzerland
    Beiträge
    591

    Standard

    Wie gehen denn die anderen grossen CMS mit der Thematik um?
    Freundliche Grüsse
    Martin

  23. #63
    Community-Moderator Avatar von schman
    Registriert seit
    19.06.2009.
    Ort
    Dornbirn
    Beiträge
    3.739
    User beschenken
    Wunschliste

    Standard

    Beim TYPO3 Backend wird auch HTML5 verwendet, für abwärtskompatibiltät nehmen die modernizer.
    Kein Privat Support via PM.

  24. #64
    Administrator Avatar von Nina
    Registriert seit
    04.06.2009.
    Ort
    Hamburg
    Beiträge
    4.755
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Zitat Zitat von schman Beitrag anzeigen
    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.

  25. #65
    Maintainer Avatar von xtra
    Registriert seit
    02.07.2009.
    Ort
    Tuebingen
    Beiträge
    2.007
    User beschenken
    Wunschliste

    Standard

    Zitat Zitat von leo Beitrag anzeigen
    Ich sehe schon, wohin diese Diskussion läuft. Vorschlag zur Güte: Wir bieten weiterhin im Seitenlayout die Wahl zwischen XHTML und HTML5 an. Intern verwenden wir jedoch HTML5 und passen die Ausgabe bei Bedarf mit Hilfe von Text-Ersetzungen an XHTML an. Dadurch können wir sowohl Tags wie BR und IMG korrekt schließen, als auch die neuen Tags wie SECTION, ARTICLE etc. wieder in DIVs verwandeln.
    Was im Endeffekt mehr Implementierungsaufwand ist als die von lindesbs vorgeschlagene Weiche, da es hoechst komplexe regexe erfordert/ein parsen des DOM tree wenn es error prone sein soll.
    IMO passt da die von lindesbs vorgeschlagene Weiche in der Art von (untested Pseudocode) doch besser:
    PHP-Code:
    protected function getTemplate($strTemplate$strTemplateSuffix='tpl'$blnMustBeNative=false)
    {
            
    $strPath TL_ROOT '/templates';
            
    $strTemplate basename($strTemplate);

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

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

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

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

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

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

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

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

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

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

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

    Gruss
    Chris
    Bedenke stets: Wenn Du ungenaue oder unzureichende Angaben machst, so koennte dies die Bearbeitung deiner Frage endlos verzoegern (oder sogar dazu fyhren, dass ich zu viel nachdenken muss und die Antwort vergesse!). Kein Support per PN.

  26. #66
    Contao-Urgestein Avatar von tril
    Registriert seit
    07.01.2010.
    Ort
    Bad Marienberg
    Beiträge
    2.939
    User beschenken
    Wunschliste

    Standard

    Zitat Zitat von Nina Beitrag anzeigen
    Und Frontend? Wegen dem Backend hat hier imho ja eh keiner Probleme.
    TYPO3 hat dieses Problem einfach nicht, weil du ja alles Typo-Script'en kannst und außerdem hat Typo3 verschiedene Ausgabetypen.

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

  27. #67
    Contao-Hauptentwickler
    AG Core-Entwicklung
    Avatar von leo
    Registriert seit
    05.06.2009.
    Ort
    Wuppertal
    Beiträge
    816

    Standard

    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!

  28. #68
    Contao-Urgestein Avatar von FloB
    Registriert seit
    19.06.2009.
    Ort
    Sonnensystem
    Beiträge
    1.618

    Standard

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


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

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

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

    Wer noch mehr zum falschen Rendering unbekannter Elemente in IE8 (und älter) wissen möchte, dem Empfehle ich die Erklärung im WHATWG Blog: http://blog.whatwg.org/supporting-new-elements-in-ie
    Geändert von FloB (13.04.2011 um 14:12 Uhr)
    So long,
    FloB since Nov. 2007 +706P +115P and counting

  29. #69
    Contao-Urgestein Avatar von FloB
    Registriert seit
    19.06.2009.
    Ort
    Sonnensystem
    Beiträge
    1.618

    Standard

    Bezüglich der neuen Beiträge, die mir mangels Reload entgangen sind:
    Zitat Zitat von backbone Beitrag anzeigen
    Mit str_replace? Abgesehen davon, das dann wie blöd auf dem Output drauf rumgeritten wird, was massig Performance kostet, […]
    Dafür brauchst schon mindestens RegEx, was das ganze noch VIEL schlimmer machen wird, sowohl in Sachen performance, als auch Handhabbarkeit.
    Kann ich nur vollkommen zustimmen. Auch wenn zunächst versucht wird mit Tidy zu kommen (was meines Erachtens auf den wenigsten Servern zur Verfügung gestellt wird, und da kommen wir wieder mit dem 20%-Betroffene-Problem – dieses Fallback kann man bei einem Marktanteil von <10% von betroffenen Browsern einsetzen).

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


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

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


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

  30. #70
    AG Core-Entwicklung
    Registriert seit
    16.10.2009.
    Ort
    Bad Lausick
    Beiträge
    437

    Standard

    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.
    Ihr Partner für Contao und Webentwicklung: http://www.hofff.com.

  31. #71
    Maintainer Avatar von xtra
    Registriert seit
    02.07.2009.
    Ort
    Tuebingen
    Beiträge
    2.007
    User beschenken
    Wunschliste

    Standard

    Zitat Zitat von FloB Beitrag anzeigen
    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 Beitrag anzeigen
    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 Beitrag anzeigen
    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.
    Bedenke stets: Wenn Du ungenaue oder unzureichende Angaben machst, so koennte dies die Bearbeitung deiner Frage endlos verzoegern (oder sogar dazu fyhren, dass ich zu viel nachdenken muss und die Antwort vergesse!). Kein Support per PN.

  32. #72
    Contao-Urgestein Avatar von FloB
    Registriert seit
    19.06.2009.
    Ort
    Sonnensystem
    Beiträge
    1.618

    Standard

    Zitat Zitat von backbone Beitrag anzeigen
    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.
    Geändert von FloB (13.04.2011 um 15:04 Uhr)
    So long,
    FloB since Nov. 2007 +706P +115P and counting

  33. #73
    AG Core-Entwicklung
    Registriert seit
    16.10.2009.
    Ort
    Bad Lausick
    Beiträge
    437

    Standard

    Ich bezog mich mit dem SEO Problem eher auf das anfängliche Beispiel von leo-unglaub/lindesbs bzgl. verschiedene Templates.
    Ihr Partner für Contao und Webentwicklung: http://www.hofff.com.

  34. #74
    Contao-Hauptentwickler
    AG Core-Entwicklung
    Avatar von leo
    Registriert seit
    05.06.2009.
    Ort
    Wuppertal
    Beiträge
    816

    Standard

    Zitat Zitat von FloB Beitrag anzeigen
    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.
    Geändert von leo (13.04.2011 um 16:29 Uhr)

  35. #75
    Contao-Nutzer
    Registriert seit
    28.06.2010.
    Ort
    Zug, Schweiz
    Beiträge
    59

    Standard

    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.

  36. #76
    Contao-Nutzer
    Registriert seit
    28.06.2010.
    Ort
    Zug, Schweiz
    Beiträge
    59

    Standard

    Nachtrag:
    Weblication empfiehlt eine ähnliche Vorgehensweise. Siehe

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

  37. #77
    AG CMS-Garden
    Contao-Urgestein
    Avatar von lindesbs
    Registriert seit
    05.06.2009.
    Ort
    Oer-Erkenschwick
    Beiträge
    4.154
    Partner-ID
    keine
    User beschenken
    Wunschliste

    Standard

    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.
    von Willi Voltz aus PR 500: Henry George sagte einmal: »Kultur ist Zusammenarbeit.«


    Contao-Hosting: begeisterter Uberspace-Nutzer

  38. #78
    Contao-Urgestein Avatar von FloB
    Registriert seit
    19.06.2009.
    Ort
    Sonnensystem
    Beiträge
    1.618

    Standard

    Zitat Zitat von leo Beitrag anzeigen
    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.
    So long,
    FloB since Nov. 2007 +706P +115P and counting

  39. #79
    Contao-Urgestein Avatar von FloB
    Registriert seit
    19.06.2009.
    Ort
    Sonnensystem
    Beiträge
    1.618

    Standard

    Zitat Zitat von dave.matter Beitrag anzeigen
    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.
    So long,
    FloB since Nov. 2007 +706P +115P and counting

  40. #80
    Contao-Urgestein Avatar von FloB
    Registriert seit
    19.06.2009.
    Ort
    Sonnensystem
    Beiträge
    1.618

    Standard

    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.
    So long,
    FloB since Nov. 2007 +706P +115P and counting

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Lesezeichen

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •