[TYPO3-german] RTE nervt - Paragraph, Schachtelung, Absatz-Tags

Uschi Renziehausen typo3news at otherone.de
Mon Jul 10 18:56:45 CEST 2006


Hi Carla,

Carla Froitzheim wrote:
> Matthias Süncksen wrote:
> 
>> Hallo Liste,
>>
>> hat hier möglicherweise jemand eine Lösung für einige
>> Standard-Annoyances vom RTE..?
>>  
>>
> Was ist daran annoying, wenn der RTE nicht-valides HTML Gekraute gleich 
> korrigiert? Es macht nicht viel Sinn, wenn sich die Leute in den 
> Entwickler-Teams alle Mühe geben, dass valider Output erzeugt wird, und 
> über einen Wildwuchs-RTE wird alles wieder zunichte gemacht.
> 

Ich gebe dir im  Prinzip Recht, aber: 1) ist Matthias mit einiger 
Wahrscheinlichkeit gar nicht klar, dass er da vermurkstes HTML 
produzieren will.

Solange keiner den Moloch HTMLparser und parseFunc anfasst, um die 
beiden auf einheitliche Füße zu stellen und es wirklich funktionierende 
und aufeinander abgestimmte Defaults für lib.parseFunc und 
lib.parseFuncRTE sowie für die Transformation zwischen RTE und DB, 
beißen auch diejenigen bisweilen frustriert in die Tastatur, die wissen, 
wie Elemente RICHTIG verschachtelt werden und durchaus CSS können.

Ich schreibe das in der Stimmung, die so entstehen kann, wenn frau zwei 
Wochen lang Zeile für Zeile t3lib_htmlparser und t3lib_htmlparser_proc 
debugged, um rauszufinden, an welcher Stelle denn eigentlich mein 
VALIDER Code zunichte gemacht wird!

Es ist nämlich KEINE Korrektur, wenn <p><h3>foo</h3></p> in 
<p></p><h3>foo</h3><p></p> verwandelt wird, weil wir zwei vollkommen 
leere <p>-Elemente erhalten, die übrigens beim nächsten Speichern im RTE 
in <p>&nbsp;</p> verwandelt werden. Das ist dann zwar valide, aber wenig 
hilfreich, weil es endgültig das Layout krachen lässt. 
KORREKTURmöglichkeiten wären z.B.:
1) <div><h3>foo</h3></div>
2) <h3>foo</h3>.

Variante 1 ist mehr oder weniger ausgeschlossen, weil zumindest im 
HTMLparser div und p hartkodiert gleichbehandelt werden und die strikte 
Devise entweder/oder gilt. Stünde die Konfigurationsoptionen von 
parseFunc auch für das BE zur Verfügung, gäbe es Wege aus der Krise und 
als positiven Nebeneffekt gleich auch noch eine Entschlackung des 
Vokabulars.

Ein paar keywords:
encapsLines, externalBlocks, externalBlocks.callRecursive und anderes 
mehr. Haben nicht vielleicht ein paar Leute Lust, das mal genauer und 
richtig systematisch zu analysieren? Damit könnte man sicher vielen 
Leuten, die mit TYPO3 arbeiten, das Leben erleichtern.

Liebe Grüße, Uschi





More information about the TYPO3-german mailing list