Die HTML 5 Epidemie

[Sepp]

Angeblich hat die HTML 5 Epidemie auch Contao getroffen.

Die Einhaltung von definitiven W3C Empfehlungen war schon immer eine Bedingung fur barrierefreie Webseiten. Und jetzt spielt man herum mit HTML 5, obwohl es noch gar keine definitive W3C Empfehlung für HTML 5 gibt, und die Browser nur teilweise HTML 5 unterstützen. Also: "back to the future", in die Zeit wo fast keiner definitive W3C Empfehlungen ernst genommen hat.

Zwar bietet Contao im Seitenlayout zum Glück noch immer die Möglichkeit um das Dokument-Type XHTML 1.0 Strict zu verwenden. Aber: dann soll man den tinyMCE Editor nicht verwenden, sonst bekommt man keine fehlerfreie XHTML 1.0 Strict Code mehr. Das liegt daran, dass das "element.format" in /contao/system/tinyMCE.php nicht abhängt vom in Seitenlayout gewählten DTD, sondern den konstanten Wert "html" hat. Somit generiert tinyMCE z.B. <br> statt <br />. Und für Anfänger ist es bestimmt nicht selbstverständlich dass sie, wenn sie "XHTML 1.0 Strict" benutzen möchten, das obengenannte "element.format" ändern müssen. Man will in Contao schon HTML 5 benutzen, ohne aber über solche Folgen nachzudenken.

Es ist entmutigend dass es ungefähr 2.000 CMS gibt, aber schließlich angeblich kein CMS die W3C Empfehlungen ernst nimmt, auch nicht diejenige wie Contao, die behaupten barrierefreie Websites zu generieren. So oft wie möglich auftreten mit Neuigkeiten ist angeblich wichtiger als Qualität. Immer wieder steht man als Informatiker vor der Wahl: ich entwickle mein eigenes CMS (was viel Zeit kostet), oder ich behebe die Fehler in einem bestehenden CMS (was auch viel Zeit kostet).

[magicsepp]

Ist der Fehler hier bereits gemeldet?

[ruedische]

Somit generiert tinyMCE z.B. <br> statt <br />

Mit Verlaub, das ist Quatsch. Du darfst selbstverständlich nicht im TinyMCE in den HTML-Quellcode schauen, sondern im Browser (nach dem Rendern durch Contao). Da siehst du, dass es bei Verwendung von XHTML 1 Strict korrekt als <br /> erscheint.

Ich habe im Firefox ständig den HTML Validator als Addon laufen, Fehler und Warnungen werden mir immer gleich angezeigt. Und ich kann dir versichern: Contaos Code ist (ziemlich) sauber. Bei tables fehlt mal ein summary, das kann man notfalls im template hinzufügen. Aber sonst ist meistens alles okay.

[BugBuster]

Kann ich bestätigen was @ruedische sagt, dazu gibts die Methode toXhtml bzw. toHtml5 die Contao benutzt genau solche Dinge zu korrigieren die von externen Plugins kommen.
https://github.com/contao/core/blob/...tring.php#L382

[RainerG]

Das heißt:
Sepp hat doch recht - Der TinyMCE erzeugt den genannten Code, aber Contao checkt das ab und bereinigt dies. Somit ist seine Grundaussage, dass TinyMCE das so (falsch) erzeugt, kein Quatsch?
* verwirrt nachfrag *

[schman]

So gesehen hat Sepp recht, allerdings wird vor dem speichern in die Datenbank, der generierte Code vom TinyMCE "gesäubert" mit den von BugBusters genannten Methoden.
Das generieren des Codes im Tiny hat aber nichts mit Contao zum tun, der Tiny ist ein Plugin welches extern entwickelt wird, dieses wird dann eben von Contao genutzt.

[magicsepp]

gerade in der online demo getestet:
Ansicht im TinyMCE:

<p>Das ist ein simpler<br> 2 zeiliger Text</p>
<p>und hier geht es weiter</p>

Quellcode:

<p>Das ist ein simpler<br /> 2 zeiliger Text</p>
<p>und hier geht es weiter</p>
</div>

Damit ist es wohl eher ein Feature aber kein Bug....

[Sepp]

Mit Verlaub, das ist Quatsch. Du darfst selbstverständlich nicht im TinyMCE in den HTML-Quellcode schauen

Ach so. Dass habe ich nirgendwo in der Dokumentation gefunden.

Also: statt in tinyMCE.php "element.format" den Wert XHTML zuzuweisen, lässt man zuerst tinyMCE HTML Code generieren, und konvertiert man diese HTML Code danach in XHTML. Klasse!

Die Quellcode-Ansicht von tinyMCE ermöglicht es, in diese Code einzugreifen wenn es in dem WYSIWYG-Ansicht (besser gesagt: WYSIMOLWYG = what you see is more or less what you get) nicht möglich ist etwas zu erreichen. Aber mann kann sich auf der Quellcode-Ansicht natürlich nicht verlassen, wenn man nicht weiß was später an dieser Code noch geändert wird.

Jetzt ist es mir deutlich was in der ganze Sache eigentlich Quatsch ist. Danke, ruedische!

[xchs]

Das Backend läuft immer unter HTML5. Und da der TinyMCE nun mal im Backend aufgerufen wird, generiert er eben solches Markup.

[BugBuster]

Und wie stellst du dir das vor soll das geschehen? Da muss man schon etwas weiterdenken.

Ich habe Multidomain Installationen mit mehreren Layouts und dadurch auch beide Arten in Verwendung und das gleichzeitig.
Woher soll TinyMCE nun wissen was ich benötige?
Was passiert wenn ich später in der Seitenstruktur das Layout auf ein anderes stelle wodurch sich auch die Ausgabeart ändert?

Nee lass mal, so wie es ist, ist es optimal - alles andere wäre wesentlich aufwändiger und fehleranfälliger.

[FloB]

Ich versteh' nicht, warum viele sagen, HTML5 sei nicht reif, dessen Nutzung sei reiner Aktionismus, etc. Ich glaube, keiner von denen kennt die Spezifikation von HTML5.

HTML5 wurde entwickelt, um HTML voranzubringen, sowie eine Abwärtskompatibilität in der Spezifikation festzuschreiben (ob das gut ist, kann jeder selbst für sich entscheiden). Erst mit HTML5 haben wir ein HTML, was verlässlich ist (was nicht zuletzt an den Parser-Definitionen liegt, die HTML ein für alle mal sauber festgelegt haben) – HTML5 ist kein SGML oder XML mehr, sondern eine eigene Sprache. Das erlaubt Browser- und Entwickler-seitig mehr Flexibilität, Performance und Sauberkeit: Der Code ist aufgeräumter, klarer verständlich, sematischer und einfacher zu verarbeiten (inkl. strikte Regeln, wie mit nicht-standardkonformem Code umgegangen wird – kein Raten mehr!).

Alle neu eingeführten Elemente, Attribute, etc. wurden so definiert, dass sie in nicht-HTML5-Browsern so angezeigt werden, dass eine Funktionalität gegeben ist (z. B. input[type=date] oder <article> – einzig wenige Zeilen CSS muss bei allen Browsern ergänzt werden). Dass der IE (<9) mal wieder am entscheidenden Punkt nicht mitmacht, ist einfach lächerlich – aber Gottseidank gibt es einen guten, wenn auch nicht perfekt funktionierenden Workaround (ohne JS geht's nicht). Sonst läuft alles in jedem Browser perfekt, wie es geplant war.

Leider nutzen Einige die in HTML5 extra eingeführten "Fehler" (also Kompatibilitäten) als Argumentation, schlechten Code-Stil zu verwenden (à la "ist doch erlaubt!?"). Das geht von weggelassenen Apostrophen bis hin zu missgebildetem (malformed) XML Code (was im übrigen nicht HTML5-kompatibler Code ist, obwohl ein Handling eines solchen fehlerbehafteten Codes in der Spezifikation festgelegt wurde).

IMO sollte man polyglotten HTML5-Code schreiben, der zu HTML5 und XHTML5 kompatibel ist. Das ist zu 99% möglich. Die paar Byte, die durch extra Slash bei leeren Elementen und Apostrophen (<input type="date"/>) zusätzlich anfallen, werden durch größere Flexibilität, inhärente Fehlervermeidung und bessere Lesbarkeit wett gemacht.

Es wäre also sehr zu begrüßen, wenn Contao (und damit TinyMCE) den Code in XHTML5 auswerfen würde (also <br/>). Ob die Seite dann als XML oder HTML5 geparsed wird, kann dann jeder durch das Setzen des entsprechenden Internet Media Types (text/html od. application/xhtml+xml) selbst entscheiden.

Abgesehen davon halte ich WYSIWG-Editoren für eine Landplage. Lieber eine Markdown-ähnliche Meta-Sprache entwerfen, die jeder Laie versteht, kombiniert mit einem kleinen Helfer-Editor mit Live-Preview – ergibt viel, viel saubereren Code und ein Webadmin/Designer erlebt keine Überraschungen, wenn ein Redakteur/Kunde etwas "besonders hervorheben" möchte …

[Sepp]

Woher soll TinyMCE nun wissen was ich benötige?

In /system/config/tinyMCE.php stehen mehrere Contao-Variablen. Bei element_format steht der Wert 'html'. Da könnte man stattdessen doch die Contao-Variable setzen welche den Dokument-Typ beinhaltet, oder?

[Sepp]

Ich versteh' nicht, warum viele sagen, HTML5 sei nicht reif

Weil es einfach noch immer keine definitive W3C-Empfehlung für HTML5 gibt.

Überlegungen zur HTML5-Umstellung von Webseiten

(inkl. strikte Regeln, wie mit nicht-standardkonformem Code umgegangen wird – kein Raten mehr!).

Leider, leider, leider.

Da war es mit XHTML 1.0 Strict oder XHTML 1.1 und dem Content-Type "application/xhtml+xml" endlich nicht mehr möglich schlampige Code zu verwenden. Und jetzt wird mit HTML5 solche Code sogar auch noch normiert!

Warum doch wollen Leute, welche fehlerfrei programmieren können, keine richtige (X)HTML Code schreiben?

Kleine Ausgabegeräte haben manchmal zu wenig Resources für einen Browser wobei ein großer Teil der Software nur da ist um Fehler zu behelfen.

[BugBuster]

In /system/config/tinyMCE.php stehen mehrere Contao-Variablen. Bei element_format steht der Wert 'html'. Da könnte man stattdessen doch die Contao-Variable setzen welche den Dokument-Typ beinhaltet, oder?

Das ist keine Variable sondern abhängig von der Seite, denn da steht ein Layout dahinter, notfalls vererbt, und dahinter erst das Ausgabeformat.

Das würde bedeuten, bei jedem editieren eines Artikels, müsste Contao erstmal schauen, in welchen Layout sich die passende Seite befindet und entsprechend den Wert dann setzen.

Dann kommt jemand und ändert in der Seitenstruktur das Layout (mit anderem Format). Peng. Wieder falsch wenn jetzt jemand reinschaut in den TinyMCE Quelltext.
Nochmal, da hängt weit mehr dran als du derzeit siehst.
So wie es jetzt läuft werden alle Eventualitäten beachtet, da beim Generieren der Seite das aktuelle Ausgabeformat verwendet wird.

Und, sollte dann deiner Meinung nach die Korrektur der Seite (falls notwendig) zum Schluß entfallen?
Das wäre gar nicht gut.

[lucina]

In /system/config/tinyMCE.php stehen mehrere Contao-Variablen. Bei element_format steht der Wert 'html'. Da könnte man stattdessen doch die Contao-Variable setzen welche den Dokument-Typ beinhaltet, oder?

Was gibt es da zu konfigurieren? TinyMCE ist Backend, und Backend ist HTML5.

Viel Spaß im Übrigen, wenn man mehrere Seiten unterschiedlichen Doctypes in einer Installation hat und dann Artikel, News, Events teilt. Gar nicht so selten.

Die Einstellung hat im Editor nichts, aber auch gar nichts zu suchen.

[FloB]

Weil es einfach noch immer keine definitive W3C-Empfehlung für HTML5 gibt.

So kannst du das nicht sagen; du musst schon die Arbeitsweise des W3C verstehen. Zunächst ist HTML5 in "Last Call", d. h. die Öffentlichkeit ist aufgerufen, Kommentare zum Standard abzugeben – dies soll parallel zur Implementierung dieser Technologie verlaufen. Erst wenn eine ausreichend breite Implementierung (bei Browsern und Websites) vorhanden ist, kann HTML5 in den "Recommendation" Status aufsteigen – ein Henne-Ei-Problem, wenn man deine Argumentation an den Tag legt.

Abgesehn davon bezieht sich der von dir verlinkte Artikel nur auf die Umstellung bestehender Websites und nicht neu zu erstellende. Insbesondere durch die Abwärtskompatibilität, Zukunftsfähigkeit und anbetracht des angestrebten Datums für "W3C Rec" 2014 (in weniger als 2 Jahren!) ist man gut beraten, seine Seiten mit xHTML5 (neu) aufzubauen (wie am Ende des Artikels empfohlen).

Verpflichtet ist man dazu aber nicht (auch nicht in Contao – der XHTML-Mode ist vorhanden und bleibt auch erstmal).

Und nochmal: HTML5 zu verwenden heißt nicht die neusten Elemente zu verwenden, sondern eine solide Basis zu benutzen und insbesondere aus der Spezifikation im Vgl. zu HTML4 entfernte Elemente nicht mehr einzusetzen. Dazu kommt ein sinnvoller und cross-kompatibler Einsatz der anhängenden APIs – nicht-kompatible Browser kann man (zum sehr großen Teil) mit Polyfills auf die Spur helfen.


Edit: Der Artikel erwähnt HTML5 als "Living Standard" – das ist aber die Variante der WHATWG und nicht die des W3C. Wer "bleeding edge"-Elemente aus der HTML5-WHATWG-Spec benutzen möchte, arbeitet auf eigene Gefahr. In diesem Sinne ist der Artikel irreführend (wenngleich ich dem Grundtonus zustimme – wenn man HTML5 nicht braucht, kann man eine Umstellung sein lassen).

Edit 2:

[…] und manche Editoren kommen noch nicht mit HTML5-Features wie ausgelassenen End-Tags klar.

RLY? o.O
Genau das regt mich am HTML5-Standard auf – dass es keine XML-kompatible Syntax (für text/html) voraussetzt. Wie gesagt, schlechter Stil.

Abgesehn davon ist die Argumentation mit mangelnder Unterstützung in Editoren schon lange veraltet (es sei denn, man krebst mit dem selben Editor rum, den man vor 5 Jahren verwendet hat), und auch die meisten Frameworks sind "HTML5-kompatibel" (was auch immer das heißen mag). Dass Enterprise-Frameworks hinterherhinken ist ja nichts Neues, sollte insbesondere den Privatanwender oder Kleinunternehmer nicht interessieren. Und auch genau hier zeigt sich auch das Paradoxon deiner Einstellung – manche Frameworks bieten es nicht an, deswegen soll man darauf verzichten; Contao bietet es an, aber man soll darauf verzichten?

Edit 3 (der letzte): Exemplarisch auch folgender Satz:

[…] der HTML5-Validator weiß zum Beispiel nicht, dass man das &-Zeichen unter einer ganzen Reihe von Bedingungen gar nicht zu escapen braucht.

Du willst dir wirklich merken, unter welchen Bedingungen es erlaubt ist, das Ampersand (und weitere Zeichen) nicht zu escapen, anstatt es einfach immer zu machen? Wie gesagt: Nicht alles, was erlaubt ist, soll man auch machen.

[Sepp]

So kannst du das nicht sagen; du musst schon die Arbeitsweise des W3C verstehen. Zunächst ist HTML5 in "Last Call", d. h. die Öffentlichkeit ist aufgerufen, Kommentare zum Standard abzugeben – dies soll parallel zur Implementierung dieser Technologie verlaufen. Erst wenn eine ausreichend breite Implementierung (bei Browsern und Websites) vorhanden ist, kann HTML5 in den "Recommendation" Status aufsteigen

Genau. Das heißt: es kann sich noch immer was ändern. Wenn Du inzwischen 50 Websites mit HTML 5 erstellt hast, kannst Du die alle ändern um sie standardkonform zu machen.

Und was mit den Browsern? Da würde uns immer gesagt nicht für einen bestimmten Browser zu schreiben. Zwar wird das <link>-Element, was schon aus HTML 2.0 stammt, noch immer nicht völlig von den Browsern unterstüzt. Aber es gibt derzeit noch vieles in HTML 5 was nicht oder nur von wenigen Browsern unterstützt wird. The HTML5 Test

Verpflichtet ist man dazu aber nicht (auch nicht in Contao – der XHTML-Mode ist vorhanden und bleibt auch erstmal).

Vergellt's Gott!

Der Artikel erwähnt HTML5 als "Living Standard" – das ist aber die Variante der WHATWG und nicht die des W3C.

Ja, noch so was. Bevor XHTML 1.1 hat man sich geärgert an den 3 W3C-Varianten "Strict", "Transitional" und "Frameset". Jetzt gibt es mit HTML5, neben die W3C-Version, sogar noch eine WHATWG-Version. Ein "living Standard", das heißt: ein "Standard" der sich durchlaufend ändert. So was wie "thriving on chaos".

Ich muss natürlich die WHATWG-Version nicht anwenden. Aber ich muss sie kennen, um Webseiten zu verstehen, die mit dieser Version entwickelt würden. Unser Tagesablauf fängt jetzt also an mit zu sehen ob sich nicht wiederum was geändert hat an der WHATWG-Version von HTML5.

[andreasisaak]

Was bezweckst du eigentlich mit dieser Diskussion? Ich sehe grade kein Punkt an dem ankommen möchtest. Mittlerweile ist ja schon bewiesen das Contao nichts ändern muss und wahrscheinlich auch nicht wird. Und nun?

[FloB]

Genau. Das heißt: es kann sich noch immer was ändern. Wenn Du inzwischen 50 Websites mit HTML 5 erstellt hast, kannst Du die alle ändern um sie standardkonform zu machen.

Ohja, HTML5 wird nochmal komplett neu geschrieben . Du kannst davon ausgehen, dass die HTMLWG sich nicht für LAST CALL entschieden hätte, wenn sie noch größere Änderungen erwartet. Was jetzt noch kommst sind (formulative) Klarstellungen und Anpassung an Normen (z. B. für die ISO-Zertifizierung – wie es HTML4.01 war zu HTML4).

Und was mit den Browsern? Da würde uns immer gesagt nicht für einen bestimmten Browser zu schreiben. […] Aber es gibt derzeit noch vieles in HTML 5 was nicht oder nur von wenigen Browsern unterstützt wird. The HTML5 Test

Es schreibt auch niemand "für einen bestimmten Browser". Und du musst auch nicht alles einsetzen, was in der Spezifikation festgelegt wurde. Und ein Großteil des dort festgelegten ist – wie gesagt – abwärtskompatibel, es folgt somit kein Fehler, wenn man dieses Element einsetzt, sondern es wird eine "minderwertige", funktionstüchtige Darstellung gewählt (z. B. einfaches input[type="text"] anstatt Datepicker bei input[type="date"]). Die meisten Zusätze zu HTML5 im Vergleich zu HTML4 sind von semantischer Bedeutung, sollen also die Logik des Dokuments verstärken, dass z. B. Browser oder SUMAs besser auf die Inhalte reagieren können. Eine fehlerhafte Anzeige oder ein fehlerhaftes Verständnis folgt durch anwenden von HTML4-Anweisungen nicht.

Ergo kann man (neue) Seiten getrost in HTML5 schreiben und muss sich nicht darüber aufregen.

Ja, noch so was. Bevor XHTML 1.1 hat man sich geärgert an den 3 W3C-Varianten "Strict", "Transitional" und "Frameset". Jetzt gibt es mit HTML5, neben die W3C-Version, sogar noch eine WHATWG-Version. Ein "living Standard", das heißt: ein "Standard" der sich durchlaufend ändert. […] Ich muss natürlich die WHATWG-Version nicht anwenden. Aber ich muss sie kennen, um Webseiten zu verstehen, die mit dieser Version entwickelt würden.

Nö. Du musst nicht jeden Scheiß im Web mitmachen, und schon gar nicht musst du ihn verstehen (abgehesehn davon wirst du fast alles verstehen, ohne auch nur jemals einen Blick zum WHATWG zu werfen) – es gibt so unfassbar viele Spezifikationen und Arbeitsgruppen usw., die kann kein Mensch durchblicken, dafür brauchst du spezialisierte Fachkräfte (für 08/15-Websites natürlich nicht). Was beim WHATWG als "HTML" weiterentwickelt wird, landet im Endeffekt beim W3C in spezialisierten Arbeitsgruppen (z. B. Device-API), die sich im Endeffekt um eine Erweiterung des DOM / BOM (im letzten Falle überhaupt erst Standartisierung) kümmern.


Ich versteh' auch nicht, auf was du hinaus willst. Bist du "frustriert", dass du nicht mehr alles im Web verstehst? Geht es dir zu schnell? Du kannst auch noch in HTML1 arbeiten, wenn du willst; neue Möglichkeiten sind Möglichkeiten und keine Anforderungen! Wenn du allerdings Web-Dienstleistungen verkaufst, solltest du dich in dem Gebiet auskennen (aber auch nicht alles wissen müssen) – so, dass du deine Aufträge ausführen kannst und größere/komplexere an andere Anbieter weitergibst oder dein Unternehmen mit Experten ausbaust.

Das Web entwickelt sich zu einer Plattform, wie sie noch nie dagewesen ist. HTML5 ist da nur die Grundlage. Schau dir mal JavaEE o. ä. an, dann siehst du, wohin das alles führen kann (wie gesagt, für das Web der Zukunft gibt es keinen Vergleich). Wer weiter einfach nur Websites bauen möchte, kann das tun, mit den Tools, die es bereits gibt; dazu muss man keine Fachausbildung hinter sich bringen (wobei es für den professionellen Einsatz anzuraten wäre).

[Bennie]

Vielleicht ist dazu dieser Artikel für einige interessant:


http://www.heise.de/newsticker/meldu...e-1650028.html

[pumukel]

Kann ich bestätigen was @ruedische sagt, dazu gibts die Methode toXhtml bzw. toHtml5 die Contao benutzt genau solche Dinge zu korrigieren die von externen Plugins kommen.
https://github.com/contao/core/blob/...tring.php#L382

Hallo BugBuster

Kann ich aber eben nicht bestätigen. siehe http://gkammermann.ch/contao2115_grure/ so ca. ab Zeile 116.

Der betreffende Code wurde im TinyMCE HTML Editor Mode erzeugt und war und ist nur HTML Code. In erlaubten Tags bringt <br /> eben auch nichts. Wird zwar akzepziert aber eben dann verworfen. Ich bin schon der Meinung wenn Contao 2.11.5 XHTM strikt und XHTM transitional als Ausgabeformat zum Glück immer noch anbietet, dass dieses Problem einmal durchschaubar gelöst wird. Denn ich blick endgültig nicht mehr durch. Mal abgesehen davon, dass das mitgelieferte TinyMCE Gemüse, sorry, ziemlich mühsam ist. Deswegen wird wohl auch das einmal gewünschte (diskutierte) Frontend Editing verworfen. Bei Joomla hat man einen Komfort denn ich bei Contao schwer vermisse. z.B kann man bei Contao seit ich es benutze ab Version 2.9 keine Fonts wählen. Aber Contao ist eben alles in allem um Lichjahre besser als Joomla. Ausserdem verstehe ich auch nicht, dass HTML 5 nun wieder einfach <br> frisst. Ich bin schon gespannt auf HTML 6, dann wahrscheinlich damit es nicht langweilig wird </br/>. Ich könnte natürlich als Ausgabeformat HTML5 benutzen, ich muss ja keine HTML5 Features anwenden. Dann nervt mich wenigsten der W3C HTML Validator nicht mehr mit Unmengen von end tag for "br" omitted, but OMITTAG NO was specified.

Gruss pumukel

[FloB]

Kann ich aber eben nicht bestätigen. siehe http://gkammermann.ch/contao2115_grure/ so ca. ab Zeile 116.

Die genannte Seite ist als XTML Transitional deklariert und ab Zeile 116 finde ich viele <br />. Ich verstehe dein Problem nicht.

Ich möchte nochmal kurz etwas klarstellen: Es ist nicht so, dass "HTML5 auf einmal wieder <br> frisst". HTML hat das schon immer akzeptiert, wohingegen XHTML immer einen Schlusstag erwartet bzw. bei leeren Elementen die entsprechende Schreibweise <br />. HTML5 kann man auch in XHTML schreiben, auch kombiniert, Stichwort polyglottes HTML5. Ich würde so oder so immer die XHTML5-Schreibweise bevorzugen, da sie übersichtlicher, klarer und verständlicher ist und obendrein genauso überall funktioniert. Ob man dann den XML-Internet-Type sendet (sodass das Dokument als XML+XHTML geparsed wird) oder "normal" text/html sei jedem selber überlassen.

[Andreas]

Das sehe ich genauso. Wenn's nach mir ginge würde ich wenigstens auf diesen Unterschied mit den Standalone-Tags in Contao verzichten. <input ... /> ist einfach logischer zu lesen, ob in XHTML oder in HTML5, da man direkt sieht, dass man nicht nach einem schließenden Tag Ausschau halten muss. Paragraphs werden ja in Contao-HTML5 auch geschlossen obwohl nicht nötig - man stelle sich vor es gäbe noch eine Routine, die das dann auch kontrolliert und je nach Ausgabe anders ausgibt.

Fonts kannst du deinen Redakteuren in Contao auch anbieten, würde ich dir aber dringend von abraten.

[lucina]

(...)Kann ich aber eben nicht bestätigen. siehe http://gkammermann.ch/contao2115_grure/ so ca. ab Zeile 116.
Der betreffende Code wurde im TinyMCE HTML Editor Mode erzeugt und war und ist nur HTML Code. In erlaubten Tags bringt <br /> eben auch nichts. Wird zwar akzepziert aber eben dann verworfen.

Kann es sein, dass Du den Quelltext in rekompilierenden Tools wie Firebug oder Chrome Devtools anschaust? Die optimieren nämlich die closing '/>' weg. Im Quelltext ist es drin.

Bei Joomla hat man einen Komfort denn ich bei Contao schwer vermisse. z.B kann man bei Contao seit ich es benutze ab Version 2.9 keine Fonts wählen.

Vielleicht habe ich da was nicht mitbekommen, aber AFAIK braucht es dazu bei Joomla ebenfalls eine Extension (wie Web Font, Phoca Font etc.) - wie unter Contao eben z.B. den WebfontLoader oder einige alternative Lösungen.

Im Übrigen ist es ja auch die Frage, inwieweit Fontwahl aus einer Liste heraus sinnvoll ist. Ich persönlich arbeite relativ sorgfältg an meinen Fonstacks und berücksichtige dabei in aller Regel auch, welche Zielgruppe angesprochen ist, mit welchen Betriebssystemen, Geräten und Browsern sie daherkommt und baue dann passende Stacks jenseits von 'Arial, Helvetica,sans-serif'. Ich glaube nicht wirklich, dass man das mit Auswahllisten abbilden kann.

Aber Contao ist eben alles in allem um Lichjahre besser als Joomla.

Wenn ich mir Deine Beiträge in diversen Joomla-Foren so durchlese, dann kann ich Dir da nur beipflichten.

Ausserdem verstehe ich auch nicht, dass HTML 5 nun wieder einfach <br> frisst. Ich bin schon gespannt auf HTML 6, dann wahrscheinlich damit es nicht langweilig wird </br/>. Ich könnte natürlich als Ausgabeformat HTML5 benutzen, ich muss ja keine HTML5 Features anwenden. Dann nervt mich wenigsten der W3C HTML Validator nicht mehr mit Unmengen von end tag for "br" omitted, but OMITTAG NO was specified.

Ich glaube, so ganz hast Du das Prinzip aber noch nicht verstanden, oder? Eine Schreibweise ist doch kein Selbstzweck, und die wird nicht eingeführt, um Dich zu ärgern ... :-)

Du kannst in die HTML oder die XHTML-Variante in HTML5 nutzen. Und weitere Slashes wird es nicht geben, weil nach dem ersten ja bereits syntaktisch alles gesagt ist.

[Andreas]

Ich konnte da aber im Quelltext auch keine <br>s entdecken und die Quelltextanzeige von Firefox kombiniert mit dem Addon HTML-Validator lässt den Code soviel ich weiß so wie er ist, BR-Fehler bekomme ich da nämlich angezeigt.

[pumukel]

Die genannte Seite ist als XTML Transitional deklariert und ab Zeile 116 finde ich viele <br />. Ich verstehe dein Problem nicht.

Ich möchte nochmal kurz etwas klarstellen: Es ist nicht so, dass "HTML5 auf einmal wieder <br> frisst". HTML hat das schon immer akzeptiert, wohingegen XHTML immer einen Schlusstag erwartet bzw. bei leeren Elementen die entsprechende Schreibweise <br />. HTML5 kann man auch in XHTML schreiben, auch kombiniert, Stichwort polyglottes HTML5. Ich würde so oder so immer die XHTML5-Schreibweise bevorzugen, da sie übersichtlicher, klarer und verständlicher ist und obendrein genauso überall funktioniert. Ob man dann den XML-Internet-Type sendet (sodass das Dokument als XML+XHTML geparsed wird) oder "normal" text/html sei jedem selber überlassen.

Hallo Floss

Was Du mir hier erzählst war nicht mein Problem. Ich habe gefragt, wie ich den HTML Editor (vielleicht hätte ich dabei präziser erwähnen müssen, wenn ich ein Modul vom Typ Eigener HTML Code erzeuge, wie ich den Editor dazu bringe eben das <br /> nicht zu verwerfen. Inzwischen habe ich dieses Problem genau mit element_format : 'xhtml' - vorher element_format : 'html', in der tinyMCE.php (Zeile 58) nach Stunden langer Suche hier im Forum, gelöst. Da ich vorläufig das Ausgabeformat XTML Transitional beibehalten will. Das Problem ist also gelöst und keine Beanstandung mehr vom W3C (X)HTML Validator mehr und auch keine neuen Probleme. Deshalb hast Du dann die <br /> nach diesem meinem Vorgehen im Code gesehen. Und was (X)HTML und die Browser alles akzeptieren ist mir im Grossen und Ganzen auch klar. Aber der W3C (X)HTML Validator akzeptiert es nicht. Ob dies relevant ist darüber streiten sich nicht wenige.

Schönes Wochende
pumukel

[pumukel]

Kann es sein, dass Du den Quelltext in rekompilierenden Tools wie Firebug oder Chrome Devtools anschaust? Die optimieren nämlich die closing '/>' weg. Im Quelltext ist es drin.

Vielleicht habe ich da was nicht mitbekommen, aber AFAIK braucht es dazu bei Joomla ebenfalls eine Extension (wie Web Font, Phoca Font etc.) - wie unter Contao eben z.B. den WebfontLoader oder einige alternative Lösungen.

Im Übrigen ist es ja auch die Frage, inwieweit Fontwahl aus einer Liste heraus sinnvoll ist. Ich persönlich arbeite relativ sorgfältg an meinen Fonstacks und berücksichtige dabei in aller Regel auch, welche Zielgruppe angesprochen ist, mit welchen Betriebssystemen, Geräten und Browsern sie daherkommt und baue dann passende Stacks jenseits von 'Arial, Helvetica,sans-serif'. Ich glaube nicht wirklich, dass man das mit Auswahllisten abbilden kann.

Ich glaube, so ganz hast Du das Prinzip aber noch nicht verstanden, oder? Eine Schreibweise ist doch kein Selbstzweck, und die wird nicht eingeführt, um Dich zu ärgern ... :-)

Du kannst in die HTML oder die XHTML-Variante in HTML5 nutzen. Und weitere Slashes wird es nicht geben, weil nach dem ersten ja bereits syntaktisch alles gesagt ist.

Hallo
Mein Problem ist gelöst siehe zwei Postings unterhalb und ich habe mich ungenau ausgedrückt mit HTML Editor, hätte im Zusammenhang Modultyp Eigener HTML Code lauten müssen, sorry. Ich habe den Quelltext mit Notepad++ und PSPad gesichtet. Und wegen der Fontwahl, dies bezieht sich natürlich hauptsächlich auf Redakteure. Contao ist doch ein CMS? Also muss man eventuell damit rechnen, dass dann einige dieser "Schreiberlinge" jammern. Ich brauche natürlich die Fontwahl nicht. Dies erledige ich per CSS.

Gruss pumukel

[lucina]

Und wegen der Fontwahl, dies bezieht sich natürlich hauptsächlich auf Redakteure. Contao ist doch ein CMS? Also muss man eventuell damit rechnen, dass dann einige dieser "Schreiberlinge" jammern. Ich brauche natürlich die Fontwahl nicht. Dies erledige ich per CSS.

Naja, wenn die jammern, dann kann das auch daran liegen, dass man ihnen nicht die richtigen Werkzeuge an die Hand gibt ... ;-)

Probiere doch mal, denen mittels vordefinierter Stile das Layout zu erleichtern. Entweder via Formate im TinyMCE oder vielleicht auch mit dem Stylepicker_4ward. Klug eingesetzt und konfiguriert ist das ganz einfach (inklusive Schriftwahl durch das entsprechende, von Dir angelegte CSS).

War jetzt aber ein wenig Off-Topic (auch wenn ich damit einige Deiner Gedanken aufgenommen habe, die streng genommen auch nicht in dieses Thema hineingehörten).

[xchs]

Der betreffende Code wurde im TinyMCE HTML Editor Mode erzeugt und war und ist nur HTML Code. In erlaubten Tags bringt <br /> eben auch nichts. Wird zwar akzepziert aber eben dann verworfen.

Mein Problem ist gelöst siehe zwei Postings unterhalb und ich habe mich ungenau ausgedrückt mit HTML Editor, hätte im Zusammenhang Modultyp Eigener HTML Code lauten müssen

Irgendwie verstehe ich das noch nicht ganz: Wenn Du - wie Du sagst - ein Frontendmodul vom Typ "Eigener HTML-Code" verwendet hast, dann gibt es dort aber keinen TinyMCE, sondern den Code-Editor. Und der frisst imho so ziemlich alles, was man dort reinschreibt. Gibst Du beispielsweise "Foo<br>Bar<br />Baz<br>Qux<br />" ein, wird das auch so gespeichert und im Frontend ausgegeben.