nicht angemeldet
Hi,
ich moechte Fliesstext mit "zeilenweisem" Hintergrund darstellen lassen - in dem ich sein Elternelement also inline darstellen lasse, und dem eine Hintergrundfarbe (bzw. -bild) geben.
Leider wirkt padding dann bei einem solchen Element mit Fliesstext, der ueber mehrere Zeilen geht, per Definition nur in der ersten Zeile vor und in der letzten Zeile dahinter.
Ich moechte aber in jeder Zeile einen seitlichen Abstand haben, damit der Text nicht direkt an den Rand des farbigen Bereiches gequetscht ist.
Simple Grundidee: Na dann geh ich halt per JavaScript ran, und ersetze jeglichen Whitespace, den ich im Fliesstext finde, durch ein non-breaking-space, gefolgt von eben diesem Whitespace, und noch einem non-breaking-space. (Und ganz am Anfang und am Ende des Textes ebenfalls noch ein nbsp.) So weit, so simpel - und das koennte ich sogar einfach per ruecksichtsloser Manipulation von innerHTML machen, denn wenn ich statt einfach das entsprechende Unicode-Zeichen verwende, dann waer's sogar furzegal, ob ich dabei auch Whitespace innerhalb von Kindelement-Tags mit ersetze ...
Das "funzt" soweit auch erst mal - aber dadurch bekomme ich natuerlich unschoen grosse Abstaende auch zwischen den einzelnen Woertern innerhalb der Zeilen.
Beim Versuch, dies ueber negatives word-spacing auszugleichen, machen mir die Browser aber reihenweise Striche durch die Rechnung - siehe diesen Screenshot, bei dem ein word-spacing von -.125em verwendet wurde:
-
Opera (9.24) und IE (7) reagieren halbwegs akzeptabel, auch wenn noch ein groesseres negatives word-spacing notwendig waere, damit der Wortabstand vernuenftig waere.
-
FireFox (2.0.0.14) zeigt zwei Hauptprobleme:
1. "con<em>secte</em>tuer" im Blindtext soll natuerlich *ein* Wort sein (das als EM ausgezeichnete "secte" hat zur besseren Kenntlichmachung rote Schriftfarbe bekommen) - der FF macht vor dieses EM aber einen bloedsinnig grossen Abstand, der natuerlich *ueberhaupt* *nicht* da sein sollte.
2. er macht am Ende der Zeilen lange Abstaende - es sieht irgendwie so aus, als wuerde er die non-braking spaces dorthin "verschieben". -
Safari (3.0.4) baut beim EM innerhalb des Wortes ebenfalls Mist, aber in die "andere Richtung", hier kommt es zu einer Ueberlagerung.
OK, waere ja schoen gewesen, wenn's *so* einfach waere ...
Andere Sachen, die ich ausprobiert habe, waeren bspw. statt dem Whitespace etwas hinzuzufuegen, alle "Woerter" jeweils in ein eigenes Span einzupacken, diesen dann jeweils seitliches Padding zu geben - und dann der Versuch, sie per negativem Margin oder wiederum word-spacing enger zusammenruecken zu lassen. Abgesehen davon, dass das auch teilweise seltsame Resultate brachte, habe ich hierbei an der Stelle "con<em>secte</em>tuer" ein weiteres Problem, wenn ich daraus "<span>con</span><em><span>secte</span></em><span>tuer</span>" mache - dann muesste ich den Span auch noch unterschiedliche Klassen verpassen, um vor, im und nach dem EM keinen zusaeztlichen Freiraum zu erzeugen, der wiederum das Wort auseinanderreissen wuerde - also muesste ich mir auch noch den jeweils vorangehenden und nachfolgenden (Text-)Knoten ansehen, ob der mit einem Whitespace endet/beginnt - was die Ersetzung per JavaScript schon aufwendiger macht, als ich es gerne haette ... insb., wenn die auftretenden Element-Kombinationen noch etwas komplexer werden.
(Nein, an dieser Stelle stattdessen die Struktur "<span>con<em>secte</em>tuer</span>" zu erzeugen, ist auch keine Loesung, da das EM auch mehr als ein Wort enthalten koennte.)
Statt non-breaking-space/whitespace/non-breaking-space habe ich auch schon versucht, zwei nbsp mit einem "zero width non-joiner" bzw. "zero width joiner" zu verbinden - um wenigstens nicht einen Wortabstand von drei, sondern nur zwei Leerzeichenbreiten zu bekommen. Aber da sind die Browser dann wieder unterschiedlicher Meinung, bei welchem dieser beiden Zeichen sie umbrechen oder eben nicht umbrechen moechten - je nachdem, welchen von beiden ich verwende, bekomme ich also immer in irgendeinem der Testbrowser einen lange, nicht umgebrochene Zeichenwurst. (Gut, da koennte man evtl. per JS browser sniffing betreiben, und das jeweils "passende" Zeichen verwenden - "aber schoen ist das nicht™").
Weiterer Versuch: Whitespace durch <span class="space"> </span> ersetzen - fuehrt im IE dazu, dass er den Text nur noch in der ersten Zeile darstellt, und er in den folgenden komplett fehlt (und nicht mal durch Markieren sichtbar zu machen ist) - noch bevor ich ueberhaupt irgendwas mit word-spacing, font-size o.ae. versuche.
Noch 'n Versuch: Whitespace durch <span class="space">{whitespace}</span> ersetzen - und span.space dann mit word-spacing:-.375em; formatieren. Gibt nicht in allen Browsern "gleiche" Wortabstaende, Opera und IE machen sie etwas groesser als FF/Safari - funktioniert aber zunaechst mal uebergreifend ohne wirklich groessere darstellerische Probleme.
Eine Browserweiche, die hier Opera/IE etwas mehr word-spacing gibt, waere u.U. noch akzeptabel.
Frage: Hat jemand noch eine *bessere* Idee auf Lager, um den gewuneschten darstellerischen Effekt zu erzielen? (Von "vergiss' es einfach" mal abgesehen ...)
"Funzigkeit" (oder heisst das Funzionalitaet?) in allen oben genannten Browsern waere wuenschenswert; IE 6 gilt *nicht* als aktueller Browser, in dem waere das ganze also zugunsten der "normalen" Darstellung verzichtbar.
Am wichtigsten ist natuerlich, dass keine absoluten Fehldarstellungen auftreten, in denen der Inhalt ueberhaupt nicht mehr lesbar ist o.ae.
Ja, dass ich bei diesem Vorhaben dem Quelltext ein wenig Gewalt antue, ist mir egal. Deshalb will ich's ja wenigstens erst clientseitig per JS machen, und nicht schon serverseitig solch einen Unsinnscode ausliefern ...
MfG ChrisB
Gernot Back