inline und padding

[ChrisB]

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">&nbsp; &nbsp;</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 &nbsp;<span class="space">{whitespace}</span>&nbsp; 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

[Teufelchen]

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.

Variante 1:
Textelement in ein anderes stecken und dort mit padding oder hier mit margin arbeiten. Zwei ineinander verschachtelte Elemente sind IMHO immer noch besser als zu versuchen, die Welt per Javascript auf den Kopf zu stellen.

Variante 2:
Textelement nicht inline darstellen (dass der Hintergrund dann zeilenweise dargestellt werden _soll_, ist mir neu, soll das standardmäßig wirklich sein?), sondern tatsächliche Zeilenhöhe per Javascript auslesen und entsprechend hohes Hintergrundbild ausliefern, entweder generiert oder eventuell Zeilenhöhe an vorhandene Bildhöhen anpassen.

[ChrisB]

Hi,

Variante 1:
Textelement in ein anderes stecken und dort mit padding oder hier mit margin arbeiten.

Hilft mir nichts.

<p><span>blah blubb [...] laber suelz.</span></p>

• Wenn ich P den Hintergrund gebe, habe ich wieder einen "Block", wenn der Text ueber mehrere Zeilen umgebrochen wird.
• Wenn ich Span den Hintergrund und margin oder P padding gebe, wird das Span nur weiter vom Rand des P dargestellt - sein Hintergrund aber natuerlich nicht.

Variante 2:
Textelement nicht inline darstellen (dass der Hintergrund dann zeilenweise dargestellt werden _soll_, ist mir neu, soll das standardmäßig wirklich sein?),

http://www.w3.org/TR/CSS21/visuren.html#inline-boxes
"Inline-level elements are those elements of the source document that do not form new blocks of content; the content is distributed in lines (e.g., emphasized pieces of text within a paragraph, inline images, etc.)."

Es handelt sich schlicht und einfach um inline boxes. Denen kann ich einen Hintergrund geben, und ueber line-height kann ich dafuer sorgen, dass zwischen die "Zeilen" ein Abstand kommt - und schon ist der Effekt da.

sondern tatsächliche Zeilenhöhe per Javascript auslesen und entsprechend hohes Hintergrundbild ausliefern, entweder generiert oder eventuell Zeilenhöhe an vorhandene Bildhöhen anpassen.

1. vertraegt sich das schlecht mit Schriftgroessenanpassung durch den Nutzer,
2. habe ich schon mal an anderer Stelle feststellen koennen, dass FireFox Zeilenhoehen nicht unbedingt in ganzen Pixeln zurueckgibt (bei laengeren Fliesstexten verschiebt sich ein Hintergrundbild mit Hoehe in ganzen Pixeln dann also irgendwo), und
3. soll es letztendlich ein "groesseres" Hintergrundbild sein, von dem innerhalb der Zeilen dann jeweils entsprechende "Ausschnitte" zu sehen sein sollen, so dass mir dieser Vorschlag leider auch nichts weiterhilft.

MfG ChrisB

[Teufelchen]

Textelement in ein anderes stecken und dort mit padding oder hier mit margin arbeiten.

• Wenn ich Span den Hintergrund und margin oder P padding gebe, wird das Span nur weiter vom Rand des P dargestellt - sein Hintergrund aber natuerlich nicht.

Achso, du möchtest, dass der Zeilenhintergrund bis zum Rand geht, der Zeileninhalt aber nicht.
Zwei float-Elemente, eins links, eins rechts, in Höhe des Textelements:

  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">  
<html>  
<head>  
<title>Test</title>  
<style type="text/css">  
p.test {  
  display:inline;  
  border:1px solid red;  
  background-color:#ccc;  
  line-height:2em;  
}  
  
span#links {  
  float:left;  
  border:1px solid #0f0;  
}  
span#rechts {  
  float:right;  
  border:1px solid #00f;  
}  
span.innenrand {  
  width:10em;  
  line-height:80em;  
  /* top und bottom wollen nicht so recht */  
}  
  
body {  
  width:800px;  
}  
  
</style>  
<body>  
  
<p class="test">  
<span id="links" class="innenrand">Links</span>  
<span id="rechts" class="innenrand">Rechts</span>  
Dies ist ein Blindtext. Bitte beachten Sie den weiteren Inhalt dieses Textes nicht. Es handelt sich tatsächlich, so war mir Gott helfe, nur um einen Blindtext. Ja ja, ich merke schon, Sie können es wohl nicht lassen. Na gut, dann erzähle ich jetzt einen Witz: Wie viele Blondinen braucht man, um eine Glühbirne zu wechseln? Fünf, eine, die die Glühbirne hält, und vier, die das Zimmer drehen. Soso, jetzt lachen Sie auch noch, wo ich doch ausdrücklich darauf hingewiesen hatte, den Text überhaupt nicht weiter zu lesen.  
</p>  
</body></html>  

Die Höhe der Randelemente ist noch fest. Entweder probierst du, die Elemente anders zu platzieren, um eventuell mit top und bottom arbeiten zu können, oder du passt ihre Höhe in regelmäßigen Abständen mit Javascript an.

[ChrisB]

Hi,

Achso, du möchtest, dass der Zeilenhintergrund bis zum Rand geht, der Zeileninhalt aber nicht.

Nein, ich moechte eigentlich nur, dass der Fliesstext "zeilenweise" mit einem Hintergrundbild hinterlegt werden kann (problemlos moeglich, wenn ich sein Element inline darstellen lasse) - und dabei gleichzeitig auch noch erreichen, dass der Text an den Stellen, wo er automatisch in eine neue Zeile umbricht eben nicht ganz am Rand "klebt", sondern etwas "padding-artiges" hat.

Falls das aus dem Screenshot nicht klar hervorgegangen sein sollte, hier noch mal ein Beispielbild:

Textabsatz P mit rotem border, darin ein Span mit Text und background:#000.

Ganz oben die ganz normale Darstellung, darunter der Effekt mit horizontalem padding fuer den Span - und ganz unten das, was ich eigentlich erreichen moechte.
(Statt dem schwarzen Hintergrund denke man sich jetzt bitte ein Hintergrundbild - obiges dient nur zur Veranschaulichung des grundsaetzlichen Effektes.)

Wie geschrieben, so was in der Art laesst sich m.e. nur erreichen, wenn ich dafuer sorge, dass vor und hinter jedem Wort noch etwas "Platz" "klebt" - also bspw., in dem ich jedes Wort links und rechts mit einem non-breaking space umgebe. Nur dass mir dadurch dann halt der Wortabstand zu gross wird ...

MfG ChrisB

[Engin]

Ave ChrisB!

Wie geschrieben, so was in der Art laesst sich m.e. nur erreichen, wenn ich dafuer sorge, dass vor und hinter jedem Wort noch etwas "Platz" "klebt" - also bspw., in dem ich jedes Wort links und rechts mit einem non-breaking space umgebe. Nur dass mir dadurch dann halt der Wortabstand zu gross wird ...

Wie sieht eigentlich ein Automatischer Zeilenumbruch im Quelltext  aus?
Gibt es da in den Browsern ein für uns unsichtbares \n oder wie Handhaben das die Browser?

Grüße aus H im R an ChrisB,
  Primus Enginus*

[ChrisB]

Hi,

Wie sieht eigentlich ein Automatischer Zeilenumbruch im Quelltext  aus?

Ein "automatischer"? Den "siehst" du gar nicht - irgendeine Form von Whitespace erlaubt dem Browser in normalem Fliesstext, dort umzubrechen.

Gibt es da in den Browsern ein für uns unsichtbares \n oder wie Handhaben das die Browser?

Die schauen einfach, wie viele Worte in eine Zeile passen - und machen dann mit dem verbleibenden Text in der naechsten Zeile weiter.

MfG ChrisB

[Gernot Back]

Hallo ChrisB,

dass du soviel Javascript einzusetzen bereit bist, ist mir von dir neu.
So kenne ich dich ja noch gar nicht!
;-)

Kannst du den Text nicht Wort für Wort in ein Blockelement schreiben, jedesmal die offsetHeight überprüfen, falls sich diese erhöht hat, das Blockelement durch diese Aktion also zweizeilig geworden ist, das letzte Wort wieder entfernen, ein neues Blockelement aufmachen, das aus dem letzten Blockelement wieder rausgenommene Wort da reinschreiben und die folgenden Wörter, Wort für Wort usw., usf.?
(Huch, das reimt sich ja sogar!)

Gruß Gernot

[ChrisB]

Hi Gernot,

dass du soviel Javascript einzusetzen bereit bist, ist mir von dir neu.

"Unter der Haube" bin ich bereit, 'ne ganze Menge mit JS zu machen.

Kannst du den Text nicht Wort für Wort in ein Blockelement schreiben, jedesmal die offsetHeight überprüfen, falls sich diese erhöht hat, das Blockelement durch diese Aktion also zweizeilig geworden ist, das letzte Wort wieder entfernen, ein neues Blockelement aufmachen, das aus dem letzten Blockelement wieder rausgenommene Wort da reinschreiben und die folgenden Wörter, Wort für Wort usw., usf.?

Damn, ich hatte beim Verfassen des OP noch dran gedacht, dass ich das noch dazu schreiben (w|s)ollte, dass ich sowas fuer zu wenig praktikabel halte.
Mit font-size *und* Elementbreiten in em vertraegt sich das vielleicht noch halbwegs - aber wenn dann noch min-/max-width und eventuelle Aenderung der Viewportgroesse durch den Nutzer hinzukommen, wird das glaube ich viel zu unflexibel bzw. eklig.

Ausserdem wuerde dieses "Ausmessen" bei laengerem Seiteninhalt vermutlich auch zu lange dauern. Ein kurzes "Flackern" nach onload (oder evtl. auch oncontentready fuer modernere Browser), wenn sich die Wortverteilung auf Grund nicht ganz identisch hinzubekommendem word-spacing aendert, waere ich bereit in Kauf zu nehmen. Aber das man dem Browser dabei zusehen kann, wie er Zeile fuer Zeile umstellt - das waere doch etwas zu viel des guten ...

MfG ChrisB

[Gernot Back]

Hallo ChrisB,

dass du soviel Javascript einzusetzen bereit bist, ist mir von dir neu.

"Unter der Haube" bin ich bereit, 'ne ganze Menge mit JS zu machen.

Echt, hast du geheiratet? Gratulation!

Damn, ich hatte beim Verfassen des OP noch dran gedacht, dass ich das noch dazu schreiben (w|s)ollte, dass ich sowas fuer zu wenig praktikabel halte.

Ein kurzes "Flackern" nach onload (oder evtl. auch oncontentready fuer modernere Browser), wenn sich die Wortverteilung auf Grund nicht ganz identisch hinzubekommendem word-spacing aendert, waere ich bereit in Kauf zu nehmen. Aber das man dem Browser dabei zusehen kann, wie er Zeile fuer Zeile umstellt - das waere doch etwas zu viel des guten ...

Man kann auf diese Weise sogar Bilder unten links floaten lassen! Schau mal, wie der Browser hier Wort für Wort umstellt, geht doch recht flott!

Gruß Gernot

[ChrisB]

Hi,

Man kann auf diese Weise sogar Bilder unten links floaten lassen! Schau mal, wie der Browser hier Wort für Wort umstellt, geht doch recht flott!

Koennte man vielleicht fuer meinen Anwendungsfall mal ausprobieren, OK.

Aber das hat schon rein von der technischen Umsetzung her so wenig Flexibilitaet, dass es mich davor graust.

MfG ChrisB

[ChrisB]

Hi,

Man kann auf diese Weise sogar Bilder unten links floaten lassen! Schau mal, wie der Browser hier Wort für Wort umstellt, geht doch recht flott!

Koennte man vielleicht fuer meinen Anwendungsfall mal ausprobieren, OK.

Ach ja, jetzt faellt mir noch der andere Grund ein, warum ich das als Option bereits verworfen hatte - es muss ja nicht reiner Fliesstext sein, sondern kann noch andere inline-Elemente wie em, strong, etc. enthalten. Selbst wenn das "umbrechen" dieser ueber Zeilenenden hinaus noch ginge, dann muesste man sie halt schliessen und wieder oeffnen - spaetestens bei Links, die ueber Zeilengrenzen hinausgehen und damit durch Aufteilung nur noch einen "halben" Hover-Effekt haetten, wird mir das zu bloed. Klar, auch da koennte man wieder mit JavaScript nachhelfen, und dem separaten, aber doch dazugehoerenden Linkelement in der naechsten bzw. vorherigen Zeile dynamisch eine Klasse verpassen, damit's auch da "hovert" - aber vom KISS-Prinzip entfernt sich das m.E. dann doch zu weit ...

Ich moechte mir wenn moeglich das "normale" Umbrechen erhalten - und nur ein bisschen simuliertes seitliches padding in jeder Zeile haben.

MfG ChrisB

[at]

Hallo.

Ach ja, jetzt faellt mir noch der andere Grund ein, warum ich das als Option bereits verworfen hatte - es muss ja nicht reiner Fliesstext sein, sondern kann noch andere inline-Elemente wie em, strong, etc. enthalten. Selbst wenn das "umbrechen" dieser ueber Zeilenenden hinaus noch ginge, dann muesste man sie halt schliessen und wieder oeffnen - spaetestens bei Links, die ueber Zeilengrenzen hinausgehen und damit durch Aufteilung nur noch einen "halben" Hover-Effekt haetten, wird mir das zu bloed. Klar, auch da koennte man wieder mit JavaScript nachhelfen, und dem separaten, aber doch dazugehoerenden Linkelement in der naechsten bzw. vorherigen Zeile dynamisch eine Klasse verpassen, damit's auch da "hovert" - aber vom KISS-Prinzip entfernt sich das m.E. dann doch zu weit ...

Wenn du einfach mittels Javascript jedes Wort in ein <span>-Element verpackst, betrifft das die übrigen Inline-Elemente doch gar nicht, wenn die <span>-Elemente innerhalb der anderen Inline-Elemente stehen. Dann funktionieren sogar :hover-Effekte.
Und mehr Code oder eine längere Rechendauer als bei den Whitespace-Tricksereien sind doch auch kaum zu befürchten.
Hast du schon einmal ausprobiert, wie sich ein beidseitiger Innenabstand in Kombination mit einem negativen Außenabstnad bei jedem einzelnen <span>-Element auswirkt? Du wirst ein wenig mit den Werten spielen müssen, und eventuell dem letzten <span>-Element eine Sonderbehandlung zukommen lassen müssen, aber prinzipiell funktioniert es so.
MfG, at

[ChrisB]

Hi,

Wenn du einfach mittels Javascript jedes Wort in ein <span>-Element verpackst, betrifft das die übrigen Inline-Elemente doch gar nicht, wenn die <span>-Elemente innerhalb der anderen Inline-Elemente stehen. Dann funktionieren sogar :hover-Effekte.

Das bezog sich auf Gernots Vorschlag, die Zeilenlaenge durch ausprobieren zu ermitteln, und dann die einzelnen *Zeilen* in Spans aufzusplitten.

Da kann es mir durchaus passieren, dass sowas vorkommt:

blah blubb laber suelz, <a>dies ist ein // Zeilenbreite hier erreicht, Umburch erforderlich
laengerer Linktext</a>, jodel quasel...

Wenn ich daraus jetzt

<span>blah blubb laber suelz, <a>dies ist ein</a></span>
<span><a>laengerer Linktext</a>, jodel quasel ...</span>

machen moechte, *muss* ich den Link in zwei Elemente aufteilen - und das wird mir zu laestig.

Ja, wenn ich jedes Wort in einen Span packe, dann hab ich dieses Problem natuerlich nicht.

Aber bei

<span>Wort1</span> <em><span>Halbbetontes</span></em><span>wort2</span>

muss ich jetzt aufpassen, dass ich dem Span im Em kein padding-right mitgebe - weil Halbbetonteswort2 eben ein "Wort" bleiben soll.

Klar, sagst du jetzt, dann pack' doch das Em in den Span, und nicht umgekehrt ... dann bekomme ich aber mit

<em>blah Halbbetontes</em>wort

wieder ein Problem ...
(Ja, da ich das ganze auch auf "user generated content" anwenden moechte, kann ich auch solche obskuren Kombinationen nicht ausschliessen.)

Hast du schon einmal ausprobiert, wie sich ein beidseitiger Innenabstand in Kombination mit einem negativen Außenabstnad bei jedem einzelnen <span>-Element auswirkt? Du wirst ein wenig mit den Werten spielen müssen, und eventuell dem letzten <span>-Element eine Sonderbehandlung zukommen lassen müssen, aber prinzipiell funktioniert es so.

Ja, hab ich schon ausprobiert, und auch obiges Problem schon halbwegs geloest, in dem ich mir jeweils den vor- und nachfolgenden Text anschaue, ob der Whitespace ist oder nicht, und dem Span noch entsprechend Klassen verpasse. (Vom Coding her noch nicht "schoen" oder effizient umgesetzt, deshalb zeig' ich das noch nicht her ...)
Bis auf Safari spielen da auch alle mit - der weigert sich da, wo eine Zeile umgebrochen wird, immer noch, das padding-right des letzten Spans in einer Zeile auch anzuzeigen. Da Safari aber eh eine Erkennung per JavaScript erfordern wird, werde ich dem vielleicht dann noch ein &nbsp; am Ende eines jeden Wortes mitgeben ... mal schauen.

MfG ChrisB

[at]

Hallo.

Aber bei

<span>Wort1</span> <em><span>Halbbetontes</span></em><span>wort2</span>
muss ich jetzt aufpassen, dass ich dem Span im Em kein padding-right mitgebe - weil Halbbetonteswort2 eben ein "Wort" bleiben soll.

Für mich wäre hier das Kriterium "Wort"  mangels Whitespace gar nicht erfüllt.

Klar, sagst du jetzt, dann pack' doch das Em in den Span, und nicht umgekehrt ...

Würde ich nie tun, schon weil du dann auch wieder die aus mehreren Wörtern bestehenden Verweise mittels Javascript zum Reagieren auf Mausberührung bringen müsstest. Das wäre zwar an sich auch kein Problem, aber doch ein unnötiger Aufwand.

(Ja, da ich das ganze auch auf "user generated content" anwenden moechte, kann ich auch solche obskuren Kombinationen nicht ausschliessen.)

So ungewöhnlich fände ich solche Kombinationen gar nicht, sondern würde eher noch mit nur teilweise betonten Verweisen etc. rechnen. Und ausschließen sollte man hier wohl ohnehin nur invalides HTML beziehungsweise ein defektes DOM.

Ja, hab ich schon ausprobiert, und auch obiges Problem schon halbwegs geloest, in dem ich mir jeweils den vor- und nachfolgenden Text anschaue, ob der Whitespace ist oder nicht, und dem Span noch entsprechend Klassen verpasse.

Eine gemeinsame Klasse benötigst du aber lediglich für den Fall, dass sich vorher bereits <span>-Elemente im Inhalt befinden.

(Vom Coding her noch nicht "schoen" oder effizient umgesetzt, deshalb zeig' ich das noch nicht her ...)

Wäre aber schön, es irgendwann hier finden zu können. Ich hatte nämlich mal das gleiche Problem, aber den Aufwand gescheut.

Bis auf Safari spielen da auch alle mit

Ich hatte nur einen kurzen Test in Opera gemacht und war daher der Meinung, dass es zumindest grundsätzlich funktionieren sollte.

der weigert sich da, wo eine Zeile umgebrochen wird, immer noch, das padding-right des letzten Spans in einer Zeile auch anzuzeigen. Da Safari aber eh eine Erkennung per JavaScript erfordern wird, werde ich dem vielleicht dann noch ein &nbsp; am Ende eines jeden Wortes mitgeben

Dass es Safari sein würde, wusste ich nicht, aber dass irgendein Browser irgendwelche Sonderbehandlungen benötigt, war mir schon fast klar. Das war einer der Gründe, weshalb ich es letztlich gelassen habe.

... mal schauen.

Viel Erfolg.
MfG, at

[ChrisB]

Hi,

Aber bei

<span>Wort1</span> <em><span>Halbbetontes</span></em><span>wort2</span>
muss ich jetzt aufpassen, dass ich dem Span im Em kein padding-right mitgebe - weil Halbbetonteswort2 eben ein "Wort" bleiben soll.

Für mich wäre hier das Kriterium "Wort"  mangels Whitespace gar nicht erfüllt.

Vor dem Wort steht Whitespace, hinter dem Wort steht Whitespace - ziemlich sicher ein "Wort", auch wenn es teilweise kursiv geschrieben ist :-)

(Ja, da ich das ganze auch auf "user generated content" anwenden moechte, kann ich auch solche obskuren Kombinationen nicht ausschliessen.)

So ungewöhnlich fände ich solche Kombinationen gar nicht, sondern würde eher noch mit nur teilweise betonten Verweisen etc. rechnen.

Ob da noch ueber mehrere Ebenen Elemente verschachtelt werden, ist dann letztendlich auch wieder uninteressant - ich muss lediglich irgendwie dem Fall beruecksichtigen, dass innerhalb eines "Wortes" diverse Elemente bzw. Tags auftauchen koennen, die ignoriert werden wollen.

Und ausschließen sollte man hier wohl ohnehin nur invalides HTML beziehungsweise ein defektes DOM.

Das wird schon serverseitig sichergestellt - Christians BBCode-Parserklasse.

Ja, hab ich schon ausprobiert, und auch obiges Problem schon halbwegs geloest, in dem ich mir jeweils den vor- und nachfolgenden Text anschaue, ob der Whitespace ist oder nicht, und dem Span noch entsprechend Klassen verpasse.

Eine gemeinsame Klasse benötigst du aber lediglich für den Fall, dass sich vorher bereits <span>-Elemente im Inhalt befinden.

Nee, Klassen benoetige ich auch, um innerhalb eines - ueber mehrere Elemente "verteilten" - Wortes keine Abstaende zu bekommen, wenn ich <span>Wort</span> generell mit seitlichem Padding versehe.

Wäre aber schön, es irgendwann hier finden zu können. Ich hatte nämlich mal das gleiche Problem, aber den Aufwand gescheut.

Bin mir momentan noch nicht sicher, ob ich nicht lieber doch drauf verzichte - weil's einfach eine zu wackelige Angelegenheit ist.

Bis auf Safari spielen da auch alle mit

Ich hatte nur einen kurzen Test in Opera gemacht und war daher der Meinung, dass es zumindest grundsätzlich funktionieren sollte.

Irgendwie scheinen, was das angeht, *alle* ihre Eigenarten zu haben ...

Dass es Safari sein würde, wusste ich nicht, aber dass irgendein Browser irgendwelche Sonderbehandlungen benötigt, war mir schon fast klar. Das war einer der Gründe, weshalb ich es letztlich gelassen habe.

/me too ... maybe :-)

MfG ChrisB

[at]

Hallo.

Aber bei

<span>Wort1</span> <em><span>Halbbetontes</span></em><span>wort2</span>
muss ich jetzt aufpassen, dass ich dem Span im Em kein padding-right mitgebe - weil Halbbetonteswort2 eben ein "Wort" bleiben soll.

Für mich wäre hier das Kriterium "Wort"  mangels Whitespace gar nicht erfüllt.

Vor dem Wort steht Whitespace, hinter dem Wort steht Whitespace - ziemlich sicher ein "Wort", auch wenn es teilweise kursiv geschrieben ist :-)

Ich nehme an, dass wir das gleiche meinen, ich mich aber nur auf einen Wortteil bezog, von dem ich annahm, für dich sei dies kein Wortteil, sondern ein Wort. Oder so.

Ob da noch ueber mehrere Ebenen Elemente verschachtelt werden, ist dann letztendlich auch wieder uninteressant - ich muss lediglich irgendwie dem Fall beruecksichtigen, dass innerhalb eines "Wortes" diverse Elemente bzw. Tags auftauchen koennen, die ignoriert werden wollen.

Dass Ignorieren aber auch immer so viel Arbeit machen muss.

Und ausschließen sollte man hier wohl ohnehin nur invalides HTML beziehungsweise ein defektes DOM.

Das wird schon serverseitig sichergestellt - Christians BBCode-Parserklasse.

Gut, mindestens ein Problem weniger.

Nee, Klassen benoetige ich auch, um innerhalb eines - ueber mehrere Elemente "verteilten" - Wortes keine Abstaende zu bekommen, wenn ich <span>Wort</span> generell mit seitlichem Padding versehe.

Wer tut denn sowas? Na gut, sicher ist sicher. Ist ja auch kein Aufwand. Nur wer sich den Quelltext ansieht, könnte einen noch größeren Schrecken bekommen. Aber das ist ja kein Kriterium.

Dass es Safari sein würde, wusste ich nicht, aber dass irgendein Browser irgendwelche Sonderbehandlungen benötigt, war mir schon fast klar. Das war einer der Gründe, weshalb ich es letztlich gelassen habe.

/me too ... maybe :-)

Sollte sich da noch etwas tun und dich dich der Ehrgeiz packen, lass es mich mich bitte wissen.
MfG, at

[ChrisB]

Hi,

ich hab jetzt erst mal folgenden halbgaren Workaround entwickelt.
(Auf '"padding" hinzufuegen' klicken, um den Effekt zu sehen;
ja, die lange Zeile im zweiten Absatz ist beabsichtigt, um das overflow-Verhalten zu testen, dass da nichts abgeschnitten wird.)

Zwar nicht ganz das, was ich eigentlich will (*stampf*), weil damit alle Zeilen bis auf die letzte in einem Absatz eben nicht der Textbreite entsprechen, sondern ueber die gesamte Breite gehen - aber immerhin ...

Allerdings auch noch eine wackelige Angelegenheit - FireFox und IE 7 machen Elemente im Fliesstext mit kursiver Schrift (bspw. em) etwas hoeher als den Rest (zumindest bei der derart verwendeten Schriftart, fuer andere hab ich's noch nicht untersucht) - sieht man in der rechten Spalte, insb. beim laengeren Absatz faellt im FF stark auf, wie sich die Zeilenhoehen verschieben, und damit der simulierte Hintergrund nicht mehr "sitzt" ...

Hm, ich ueberleg' mir noch mal, ob ich das mit jedes-Wort-in-Span-verpacken nicht doch besser hinkriege - oder, wenn's zu wackelig bleibt, vielleicht doch ganz bleiben lasse.

MfG ChrisB