Deutsche Version
(There is also an English version of this article)
Der Internetexplorer stellt ja bekanntlich nicht alles so dar wie es standardkonform logisch wäre. Ein Fehler, der mich schon seit Jahren aufregt, möchte ich inline-wrap bug nennen. Das Problem tritt auf, wenn man ein inline element (z.B. span oder a) umbricht, d.h. über zwei Zeilen laufen läßt. Weißt man einem solchen Element bestimmte CSS Regeln zu, so werden diese nicht so angezeigt wie der logische Menschenverstand einem dies suggerieren würde bzw. die Standards definieren.
Am auffälligsten ist dieser Fehler bei Hintergrundbildern. Auf dieser Seite nutze ich beispielweise ein WordPress Plugin um Links ein kleines Icon anzufügen und so externe Links, die in einem neuen Fenster geöffnet werden, zu markieren (das ganze setze ich auch oft ohne WordPress ein). Sobald ein solcher Link am Ende einer Zeile umbricht wird das Hintergrundbild nicht richtig angezeigt (linker Pfeil im folgenden Bild). Wie es eigentlich aussehen sollte zeigt der erste Link im Bild (rechter Pfeil).

Abb.1: der inline-bug im IE6
Wenn man genau hinsieht erkennt man beim ersten Wort des zweiten Links (“Brian”) unten am “n” noch ein paar blaue Pixel, die von dem eigentlich in der nächsten Zeile zu erwartenden Hintergrundbild übriggeblieben sind.
Die CSS Regel die dies bedingt sieht wie folgt aus (mehr Details könnt Ihr auch noch in dem Artikel “Besondere Links ohne Aufwand markieren” nachlesen)
a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right;
}
Dieses Problem kommt dadurch zu Stande, dass der Internet Explorer das inline Element (in diesem Fall der a tag) von den Dimensionen her so abgrenzt, dass der rechte Rand des Elements am rechten Rand des Absatzes ist. Richtet man nun ein Hintergrundbild rechts aus, so wird es am rechten Rand des Absatzes angezeigt. Besser ist dieses Phänomen zu sehen wenn man den CSS Code so modifiziert, dass das Icon rechts und oben positioniert wird.
a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right top;
}
Dies führt zu folgendem Ergebnis:

Abb.2: der inline-bug im IE6 mit Background top
Selbst Wikipedia (schaut euch einen Artikel an der externe Links am Ende der Seite hat und verkleinert das Fenster so weit, dass der Link umbricht) hat dieses Problem und scheint machtlos zu sein. Leider habe ich bisher keine Lösungsansätze im Internet gefunden. Es blieb daher nur die Möglichkeit darauf zu achten, dass es keinen Umbruch in den Links gibt.
Die CSS-Lösung
Die erste Idee war, dem ganzen Link die CSS-Regel “white-space: nowrap” hinzuzufügen um einfach den Umbruch zu verhindern. Leider führt selbst dies nicht dazu, dass der IE die Abgrenzungen des Elements korrekt rendert. Umgehen kann man dies, indem man ein “display: inline-block” benutzt. Dieser Wert für “display” ist Teil der CSS 2.1 Specification des W3C, wird aber leider nicht von Gecko basierenden Browsern unterstützt (Ein miracle! Sonst ist das ja tendenziell eher andersrum).
So wird der Link im InternetExplorer immer als ganzer “Block” angezeigt und das Hintergrundbild ist an der richtigen Stelle.
Damit wäre eigentlich schon alles OK, ich finde es aber nicht so nett, dass im Firefox dann der Link umgebrochen wird, auch wenn er dort dann korrekt aussieht.

Abb.3: Anzeige mit “display: inline-block” im IE6

Dies läßt sich angleichen indem man nun noch die Regel “white-space: nowrap” hinzufügt. Dann wird sowohl im IE als auch im Firefox die Anzeige wie in Abb.3 aussehen.
Der entgültige CSS-Code sieht dann so aus:
a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right top;
display: inline-block;
white-space: nowrap;
}
Leider validiert nun das CSS-File nicht mehr, zumindest solange man die Standardeinstellungen des W3C Validators nutzt. Ruft man diesen jedoch über seine Adresse jigsaw.w3.org auf so kann man als Option auch CSS2.1 auswählen, womit auch dieser Code validieren kann. Schließlich ist der Wert ja bereits in den CSS 2.1 Spezifikationen enthalten.
Ein weiteres Problem wird durch Opera generiert. Michael Wöhrer hat in seinem Blog darauf hingwiesen, dass display: inline-block in diesem Browser dazu führt, dass das Element ein paar Pixel nach oben verschoben wird. Deshalb ist es sinnvoll diese CSS Regel in eine extra Datei zu packen die nur vom InternetExplorer aufgerufen wird (hier können dann auch alle anderen IE Hacks rein). Dazu kann man am besten Contitional Comments nutzen. So wird die Regel überhaupt nicht mehr in anderen Browsern ausser dem IE5+ interpretiert.
Das ganze sieht dann zum Beispiel so aus:
<!--[if gte IE 5]> <style type="text/css" media="screen"> @import url( styles/style_ie.css ); </style> < ![endif]-->
Diesen Code in den Head des Dokuments packen und die oben erwähnte CSS-Regel in die Datei styles/style_ie.css.
Anregungen und Codeverbesserungen sind jederzeit willkommen und gerne gesehen!
English Version
(es gibt auch eine deutsche Version des Artikels)
In this article I would like to talk about a very special internet bug, which could be called inline-wrap bug. This problem occurs if an inline element (i.e. span or a) wraps over two lines in the Internet Explorer. If those elements have some “special” CSS rules, they are not redered as anybody would expect or as the W3C Guidelines/Standards define it.
A good example are background-image for link tags. On this and many other sites I use a tiny little Skript to mark external links, which will open in a new window, with an icon behind it (I use a WordPress Plugin here, on other sites I use a Javascript).
If such a link wraps at the end of a line, the background-image is not displayes (corretly). See the left arrow in the next picture for the problem and the right arrow for an example of the correct marking.

Img.1: the inline-bug in IE6
If you have a closer look at the first word of the second link (“Brian”), you might see a some blue Pixel at the botom right of the “n”, which are left from the expected background-image.
The CSS rule which does that can look like that:
a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right;
}
This problem is occuring because the Internet Explorer is giving the inline elements (in this case an a-tag) wrong dimensions, if the element is wraps. IE calculates the right border of the element at the right border of the paragraph. If now a background-image is positioned at the right border of the tag, it is automaticaly positioned at the right border of the paragraph.
You can get a better understanding of the problem if you position the image right and top of the link.
a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right top;
}
This displays like that:

Img.2: the inline-bug in IE6 with background top
The problem even occurs on Wikipedia (check an article with external links at the end and resize the browserwindow so that they wrap) and I have not found a solution on the web yet.
The CSS solution
My first idea was to simply give the link a “white-space: nowrap”, which would prevent any line wrapping. As you can imagine IE will not display the background-image in the right spot although the link is in the second line and in one piece.
The solution is to use “display: inline-block”. This value is part of the CSS 2.1 Specification of the W3C but is not supported in Gecko based browsers yet (a miracle!).
Styling the link this way the InternetExplorer renders it as a block and the background-image is at its correct position.
This is OK (even with the disadvantage that now no link can wrap), but i.e. Firefox is still wrapping the link. If you are not angry about sites which look different in two browsers you are fine.

Img.3: output with “display: inline-block” in IE6

We can prevent this issue bei just adding “white-space: nowrap” to your CSS rule. This does the trick! Now IE and Firefox should output the text like you can see in Image 3.
Final CSS code:
a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right top;
display: inline-block;
white-space: nowrap;
}
Unfortunately now the CSS file is not validating anymore… as long as you use the standard options of the Validator. But if you use the jigsaws direkt adress, you can choose the specifications you want to use (i.e. CSS2.1). So even this code can be validated.
Another problem is coming up in Opera. In this Browser the Element which has display: inline-block in his rules, is moved some pixels up. Michael Wöhrer mentioned this in his Blog. That’s why it is urgent to use Contitional Comments to let this rule only appear for the IE5+. Just put our CSS Code into a file called i.e. styles/style_ie.css and include it in the following way into the head of your documents:
<!--[if gte IE 5]> <style type="text/css" media="screen"> @import url( styles/style_ie.css ); </style> < ![endif]-->
Corrections and hints for better code and/or other solutions are appritiated.













[...] The blue moped bloghas evaluated this issue and recommends the following solution: Using display: inline-block in the CSS: a.liexternal { background: url(images/icon.gif) no-repeat right; padding-right: 10px; display: inline-block; } [...]
Thanks again for this article.
In the meantime I have found out that the Opera browser moves the links a few pixels to the top when you use “display: inline-block”. Therefore I recommend to use conditional statements to apply inline-block. See Inline Wrap Bug of Internet Explorer for details.
@Michael: Nice! I did not have the time to test this yet.
I should modifiy my article soon.
I’m not sure is a good idea. At least in blogs I was designed, were I’m not author, I can’t use this solution because I can’t limit link extension. I prefer the inicial error and not lines like this:
text,
large link large link large link large link large link large link
text text text text text text text text text text text text text
anyway, thanks for sharing!
Hello Irene,
thank you for your comment. I totally understand your issue. And I agree.
. Anyway one could be limit the css class to the Contentarea which you as an editor use. in example
Of course it is still a stupid thing, that not all Browsers act the same and one can feel free to dislike this “solution”
#content .maintext a.liexternal {wired-css-stuff-here}
A not so easy idea could also be to break such extra large links in the middle with an additional little skript (I did such thing ones for a small sidebar – like this one here).
Or you just import the brilliant IE7-lib of Dean Edwards, which makes the IE standard compliant (by the way, I have never checked if the behaviour of IE or Firefox is standard compliant – we just get so sloppy in trusting Mozilla
)
So there are solutions everywhere…
[...] Problem Keine Kommentare – jetzt Kommentar schreiben » Noch keine Kommentare. RSS-Feed für Kommentare zu diesem Beitrag. Einen Kommentarhinterlassen [...]
[...] Nur, ihr mal seht, dass wir alle unser Web-Päckchen zu tragen haben. Ein paar andere Dinge, wie die Sache mit 404 und WordPress sind ToDos, das ist was anderes. Und manche Dinge, wie dieses blöde Darstellungsproblem im Zusammenspiel mit dem Link-Indication-Plugin (auf das ist nicht mehr verzichten will!), sind eben so – kann man nichts machen, Kröte muss man schlucken. [...]
So viel Aufwand nur für den dummen IE
Danke, nun endlich habe ich den Sachverhalt ganz kapiert