Teil des Listings mit zu großer Schrift

[Slini11]

Ich habe gerade folgenden Cache entdeckt: http://www.opencaching.de/viewcache.php?cacheid=110975
Ist es auch bei anderen so, das unter der Cachebeschreibung alle Überschriften übergroß sind?
Kann das sein, das da die html-Beschreibung des Listingtextes nicht korrekt abschließt und in den restlichen Code übergreift?

[80s]

Auch bei den meisten anderen Caches von "Malamute" ist das so. Ich tippe mal darauf,
dass es an den Zeitpunkten der Listings liegt (29.05.-01.06.06). Am 01.06. gibt es
welche, bei denen alles stimmt, und andere, bei denen die Darstellung zerschossen ist.
Ich tippe mal ins Blaue und denke, dass es im besagten Zeitraum irgendwelche Probleme
gab die am 01.06. gefixt wurden? 

Gruß
80s

[FriedrichFröbel]

Das altbewährte Problem: Die definierte Schriftart, -größe und -farbe wurde nicht mit den entsprechenden HTML-Tags wieder geschlossen, sodass sich die Formatierung auf den Rest des Listings überträgt.

[80s]

[quote="FriedrichFröbel"]
Das altbewährte Problem: Die definierte Schriftart, -größe und -farbe wurde nicht mit den entsprechenden HTML-Tags wieder geschlossen, sodass sich die Formatierung auf den Rest des Listings überträgt.
[/quote]

Dann dürften jedoch die Überschriften der Logeinträge sowie der Footer nicht auch in übergroß dargestellt werden, oder?

Hab mir es jetzt nicht genauer angesehen - normalerweise regelt man sowas jedoch per externer CSS-Dateien.
Und mit Trennung von variablem Content (geschriebener Text der User) von festen, unveränderbaren Texten, welche
von einem Template kommen.

Gruß
80s

[following]

Der benutzerdefinierte Content wird innerhalb eines <div> in die Templateausgabe eingebettet. Wenn die <div>-Hierarchie durcheinandergerät, können Benutzer-Formatierungen auch auf den nachfolgenden Teil durchschlagen. (Vielleicht gibt es auch noch weitere Ursachen.)

In diesem Fall zeigt mir der Firefox Probleme mit der Div-Hierarchie an, wobei ich auf Anhieb nicht verstehe, woran es liegt - siehe das rote </div> in dem Screenshot. Erkennt jemand, wo es hakt?

Benutzer-HTML-Eingaben durchlaufen einen HTML-Purifier. Die verwendete Version ist 4.2.0 ist von September 2010 - ob er damals upgedat oder erst eingebaut wurde, weiß ich nicht. Jedenfalls sind die allermeisten Problemfälle älter. Beispiele:

* http://www.opencaching.de/viewcache.php?cacheid=114864
* http://www.opencaching.de/viewcache.php?cacheid=139389
* http://www.opencaching.de/viewcache.php?wp=OCA026
* http://www.opencaching.de/viewcache.php?wp=OC2E4A
* http://www.opencaching.de/viewcache.php?wp=OCA066
* http://www.opencaching.de/viewcache.php?wp=OC14F8
* http://www.opencaching.de/viewcache.php?wp=OC0A0A
* http://www.opencaching.de/viewcache.php?wp=OC9AD7
* http://www.opencaching.de/viewcache.php?wp=OC3CDC
* http://www.opencaching.de/viewcache.php?wp=OC28B8
* http://www.opencaching.de/viewcache.php?wp=OC5423
* http://www.opencaching.de/viewcache.php?cacheid=139736
* http://www.opencaching.de/viewcache.php?cacheid=124069
* http://test.opencaching.de/viewcache.php?wp=OC8927

Hier ist aber auch ein neueres Beispiel, das sicher durch den Purifier gelaufen ist:

http://www.opencaching.de/viewcache.php?cacheid=156370

Lösungsmöglichkeiten:

- auf den neuesten HTML-Purifier updaten
- Purifier besser konfigurieren
- zusätzliche Maßnahmen zur Sicherstellung der Div-Hierarchie?
- ältere Cachebeschreibungen vor der Anzeige durch einen zusätzlichen Filter schicken. Das muss man sehr sorgfältig machen, weil die Owner keine Kontrolle über die Ergebnisse haben

Mag sich  jemand die Beispiele oben anschauen und nach einem möglichst universellen Lösungsweg suchen?

[mic@]

[quote="following"]Jedenfalls sind die allermeisten Problemfälle älter. Beispiele:
...
* http://www.opencaching.de/viewcache.php?wp=OC28B8[/quote]

Was ist an obigen Listing denn das Problem?


[quote="following"]...und nach einem möglichst universellen Lösungsweg suchen?[/quote]

Was würde eigentlich passieren, wenn wir vorsorglich das schließende </div> selber
vor unserem Code schreiben. Ist zwar etwas unschön, etwas zu schließen, was bei
99.9% aller Listings schon geschlossen ist. Aber schaden würde das doch nicht, oder?

[following]

Was ist an obigen Listing denn das Problem?

anscheined keines mehr, wurde seit dem Eintrag in unsere Todo-Liste repariert

Was würde eigentlich passieren, wenn wir vorsorglich das schließende </div> selber vor unserem Code schreiben.

Erstens fehlt bei OC1F07 kein </div>, sondern das vorhandene </div> funktioniert nicht (warum?); zweitens zerschießen wir uns das OC-Layout wenn zuviele </div> vorhanden sind.

[flopp]

Was ist an obigen Listing denn das Problem?

anscheined keines mehr, wurde seit dem Eintrag in unsere Todo-Liste repariert

Was würde eigentlich passieren, wenn wir vorsorglich das schließende </div> selber vor unserem Code schreiben.

Erstens fehlt bei OC1F07 kein </div>, sondern das vorhandene </div> funktioniert nicht (warum?); zweitens zerschießen wir uns das OC-Layout wenn zuviele </div> vorhanden sind.

Bei opencaching.de/OC1F07 stehen am Anfang der Cachebeschreibung komische "b"- und "font"-tags ohne schließende Tags:

Code: Alles auswählen

<b />
<font size="+1" />
<font face="Flat Brush" />
<font color="#808080" />

Chrome interpretiert diese Tags so, als ob sie für das gesamte restliche Dokument gelten (jedenfalls zeigt der Developer-Modus von Chrome eine entsprechende Tag-Hierarchie).

[80s]

[quote="flopp"]

Chrome interpretiert diese Tags so, als ob sie für das gesamte restliche Dokument gelten (jedenfalls zeigt der Developer-Modus von Chrome eine entsprechende Tag-Hierarchie).
[/quote]

Das kann auch mit der Vererbbarkeit von Textauszeichnungselementen zusammenhängen:
http://www.css4you.de/wscss/css08.html
http://www.css4you.de/wscss/css08.html#font-size

Aber du hast schon recht,

[quote="flopp"]
Code: [Auswählen]
<b />
<font size="+1" />
<font face="Flat Brush" />
<font color="#808080" />
[/quote]

ist natürlich Schwachfug. Das ist pseudo-XHTML (schließende Tags), welche vorher gar nicht erst geöffnet werden.
Desweiteren sind sie AFAIK nicht W3C konform.