search

contao / core

Contao 3 → see contao/contao for Contao 4
GNU Lesser General Public License v3.0
492 stars 213 forks source link

XHTML-Ausgabe von Member-Feldern #3583

Closed Aybee closed 12 years ago

Aybee commented 12 years ago

Setzt man ein Mitgliederfeld, z.B. firstname auf "textarea" mit "rte", dann wird bei der FE-Ausgabe die XHTML-Ausgabe noch nicht berücksichtigt.
wird nicht zu
.

$GLOBALS['TL_DCA']['tl_member']['fields'][firstname']['inputType'] = 'textarea'; $GLOBALS['TL_DCA']['tl_member']['fields']['firstname']['eval']['rte'] = 'tinyMCE';

Das wird häufig benötigt, wenn die Mitgliederfelder erweitert werden. In der Online-Demo nicht machbar.

--- Originally created on October 27th, 2011, at 02:42pm (ID 3583)

leofeyer commented 12 years ago

Momentan wird die Umwandlung XHTML/HTML5 noch statisch in den Frontend-Modulen gemacht. Eventuell sollte sie aber besser nach isset(eval->rte) vorgenommen werden.

--- Originally created on November 4th, 2011, at 02:24pm

leofeyer commented 12 years ago

In der momentanen Implementierung ist diese Prüfung leider nicht ohne größeren Aufwand möglich. Ich empfehle daher, bei XHTML-Seiten die Datei system/config/tinyMCE.php anzupassen und die Zeile

  doctype : '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">',

zu ergänzen. Damit gibt TinyMCE wieder XHTML-Code aus.

In einer zukünftigen Version wird das wahrscheinlich anders (und besser) implementiert.

Aybee commented 12 years ago

Ich habe mir das nochmal angesehen. Wäre es nicht besser, wir würden auch in HTML5 die standalone-Tags schließen? Es wäre valides HTML5, man kann den Quelltext besser parsen, es gibt keine Fehler mehr diesbezüglich und wir könnten diese ganze Überprüfung mit dem ' />' und '>' rausschmeißen.

siehe hier Punkt 6 http://www.w3.org/TR/html5/syntax.html#start-tags

dominikzogg commented 12 years ago

Sicher wäre es das, aber es gibt da so Performance Junkies ;-) (mehr Traffic)

Aybee commented 12 years ago

Nicht dein Ernst! Wegen der 2 Zeichen in den seltenen 'Void elements'? Da gäbe es bessere Wege um das zu erreichen, schließlich gibt es eine Menge von End-Tags, welche in HTML5 nicht benötigt werden und von Contao trotzdem generiert werden.. Siehe hier http://www.w3.org/TR/html5/syntax.html#optional-tags

tristanlins commented 12 years ago

Besser parsen? HTML postzug valides SGML, das last sich genau so leicht parsen wie XML. Zum parsen ist es total egal ob man valides XML oder HTML schreibt. Und das einzige überflüssige ending-Tag ist das Tag und das existiert nur weil der IE sonst Probleme macht. Optional hast nunmal leider nicht auch “fehlerfrei verzichtbar“. Und ganz ehrlich, wenn es um “besser parsen“ geht, dann sollte man auf diese “optionalen“ Elemente definitiv nicht verzichten, das kann 1. mein Hirn schlechter parsen und 2. werden uns dann einige Browser im sechseck springen. Die Aussage von @dominikzogg war (hoffentlich) eher scherzhaft gemeint ;-) Grundsätzlich gebe ich aber recht, das es eventuell besser währe den tiny auf XHTML zurück zu stellen. Denn im Gegensatz zu HTML, ist ein in XHTML nicht geschlossener standalone Tag ein Syntaxfehler.

dominikzogg commented 12 years ago

Sicher war das ein schlechter Scherz, genau so schlecht wie HTML5 als Markup Language auch. xhtml hat dazu geführt, dass wir grossflächig professionellere Auszeichnung haben bzw. gleich hatten. HTML5 zu validieren ist etwa das selbe wie, hab ich das wirklich so misserabel gemacht, dass es nicht mal HTML5 kompatibel ist. Es gab noch nie eine derart theoretische Fehlertoleranz wie bei HTML5, und das nur, weil ein paar Leute nicht die Disziplin hatten sauber zu arbeiten. Wir hier wissen alle was ein legerer Schreibstil für folgenden in der Darstellung von html bis heute hatte, denkt Ihr wirklich die Zeit sei vorbei? Wäre Sie gewesen, wenn es nur einen richtigen Weg gegeben hätte für ein Problem. xhtml hat sich für diesen einen Weg stark gemacht, wie es scheint vergebens. xhtml war es, dass "html" standardisiert hat, nichts anderes, diese Standards waren und sind noch immer gut für uns, Ich hoffe noch immer, dass ich ein xhtml5 eigenen Doctype bekomme, welche ich auch als solchen validieren kann. Weil W3c beüben für HTML5 ist einfach verlorene Zeit, ich kann ja schreiben was ich will.

Zurück zum Ursprung: Argumente wie bei erwähntes habe ich mehrfach gehört, dieser "unnötige" /> beschrere nur Traffic und gebe mehr Schreibarbeit. Diesen haben wir diesen pseudo Standard der HTML5 ist zu verdanken. Ich mag, bzw, ich finde die neuen Dinge in HTML5, wie

Ich würde mich freuen, wenn wie den xhtml weg weiter fahren würden auch mit dem "neuen" Doctype, wenns den schon erlaubt ist. Doch ich akzeptiere, dass ich damit in der Minderheit bin, und solange es keinen eigenen Doctype für xhtml5 gibt, sehe ich auch keinen Grund mich bei Contao dafür stark zu machen, da der Fehler irgendwo da draussen liegt, ausserhalb unserer Community.

PS: Ich spreche von HTML5 als Markup Language, nicht als Buzzword, in dem CSS3, usw. auch dazu gehört.

fbender commented 12 years ago

Der einfache Grund, warum HTML5 so ist, wie es ist (bezüglich Parsing), ist, weil (a) HTML5 zum allerersten Mal eigene Parsing-Anweisungen besitzt (technisch ist es kein SGML mehr) und (b) diese Anweisungen so geschrieben wurden, dass die Browserengine auch alte und kaputte (und nicht aktualisierte) Websites fehlerfrei anzeigen kann, somit Browser nicht zwei Parser mitschleppen müssen (einen für xHTML, einen für xHTML5). Das ist technisch nicht die saubere Lösung, aber es ist eine diplomatische. Leider müssen sich auch (Technik-)Idealisten den "Mehrheitsverhältnissen" im Internet beugen ;).

XHTML5 definiert man nicht mehr über den DOCTYPE, sondern den MIME-Type. Wenn du den HTML-MIME-Type sendest, wird das Dokument als HTML5 geparsed (wobei es durchaus erlaubt ist XHTML und HTML zu mischen!), aber wenn du den XHTML-MIME-Type sendest, wird das Dokument als XHTML5 geparsed.

dominikzogg commented 12 years ago

Zu den Infos: Vielen Dank betreffend den Infos im ersten Abschnitt, wird der zweite Abschnitt beim validieren berücksichtigt?

Zum Idealismus: Nein, ein Idealist beugt sich nie (sollte die Ideale, aber immer immer wieder prüfen), er versucht das Beste aus jenem zu machen was Ihm diese Mehrheit vor den Kopf setzt, jene Mehrheit, welche zum Idealisten jammern geht, wenn was nicht funktioniert.

fbender commented 12 years ago

Ja, sollte berücksichtigt werden. Musst halt den Server entsprechend einstellen, dass die richtigen Header gesendet werden.

dominikzogg commented 12 years ago

Danke

Aybee commented 12 years ago

tristanlins: 'das einzige überflüssige ending-Tag ist das Tag' - Versteh ich nicht, hast du meinen Link verfolgt, z.B. brauchen P, LI, OPTION und noch andere Elemente nicht geschlossen zu werden (bitte nie umsetzen).

Mit dem Parsen lag ich dann ja wohl daneben, ich ging davon aus, dass es besser ist, wenn nicht geschlossene TAGs als solche deklariert sind, z.B. bei Benutzung von Tidy, DOM, simplexml usw.

Ich wollte hier nicht schon wieder die Diskusion 'was ist besser' lostreten, mir geht es nur um das XML-komforme Schließen von standalone-TAGs. Ich denke, dass es in Contao ein paar Punkte vereinfachen könnte und niemandem weh tut. Wie gesagt, es wäre HTML5-valide, falls es sowas überhaupt gibt.

tristanlins commented 12 years ago

@Aybee eben wegen deinem "(bitte nie umsetzen)" hatte ich das geschrieben, ich hatte nur ein "imo" vergessen ;-)

fbender commented 12 years ago

Also ich bin definitv auch für die XHTML-Schreibweise (auch wenn HTML verwendet wird). Sie schadet nirgendwo, die 10 Byte können wir noch erübrigen, und es ermöglicht die größtmögliche Kompatibilität. Wer möchte, kann dann auch den XHTML5-MIME-Type senden und hat gleich wohlgeformtes XHTML. Ansonsten ist der Code valides HTML5.

Zudem fallen die ganzen Konvertierungsmethoden raus. Wer dann von Hand irgendwo (nicht schließend) eingibt, hat auch keine Probleme, solang er nicht den XHTML-MIME-Type sendet.