I was putting together some demo pages a while back and I noticed that the line-height (or “leading” as it’s called in the print world) was expanding slightly between certain pairs of lines. This caught my eye because the line-height was set explicitly to a px value in the CSS. The spacing between any two adjacent lines should have been totally uniform but yet some were wider apart than others by one pixel.
Here’s a snippet using underlined text to illustrate:
This was in IE8 on Windows XP. I checked FireFox, Safari, Chrome, Opera, all looked fine. Even IE8 on Vista was fine.
I narrowed it down, finally, to the presence of HTML spacer entities like   or  . For some reason, spacer entities like these, for which there are no corresponding characters in the font, cause an extra pixel of line-height to appear in IE8 on Windows XP.
After confirming the bug on three separate XP machines, I filed a formal bug report on the Microsoft Connect site:
1 Pixel Jog Caused By Insertion Of HTML Character Entities
And then, as an extra kick in the pants, I duplicated the same bug report on the IE newsgroup microsoft.public.internetexplorer.general. This newsgroup isn’t restricted to bug reports, but it is monitored by lookouts from Microsoft who will pass along anything that looks to them like a significant problem.
If you feel strongly that you’ve spotted a browser bug that’s reproducible on computers other than your own and will therefore adversely effect a lot of users, don’t feel bashful about making some noise. No one will blame you, and many might have you to thank.
I also supplied a test page that reproduces the problem. But remember, you won’t actually see the 1px jog in line-height unless you’re one of the lucky tens of millions of people using IE8 on XP!
The bug has since been confirmed. Web developers might have to learn to live with it because it’s going to be difficult to patch. Developers have a very limited choice of typographic tools to begin with and it’s a shame to have a problem like this crop up. Especially disappointing in IE because that means the installed base of users susceptible to the bug will be around for years and years. And this was a version that was in development for nearly a year.
I was a Beta tester for IE8. It’s upsetting to see this, really.
Using entities like   or   or   can be much more convenient than crafting an equivalent using CSS. But now it seems we have to either shy away from them or simply accept the side-effect. I still use XP on my main development machine and I do use spacer entities. It’s funny how, once you know something is there, you can’t help but notice it. Right now, since I know where the entities are, every time I check one of my posts in IE8, the extra line-height is the first thing that draws my attention.
{ 9 comments… read them below or add one }
You mean you’re using “spacer entities” (fun neologism, BTW) just like spacer GIFs? Because they’re easier than CSS?
You’re so 2009 you’re 1997!
@Joe Clark: Sometimes, yes I do.
For certain kinds of word-spacing and kerning problems where the CSS alternative is using a span element with a class attribute, I find inserting a spacer entity much less unwieldy.
Plus, there are instances where the user has no access to the CSS in a page and wishes to format their text. For example, with indentation as I have done here in this reply to you.
I’ll be doing a post about all of the spacer entities — some of them really “spacer characters” — and authors can choose for themselves what makes sense.
Glad you found my neologism fun!
First of all, I think this is a ridiculous post. 1px line height difference? No offence, but web design isn’t print design; if you want to control user experience to the pixel then you picked a wrong profession.
Second of all, I could not reproduce the bug when using
text-decoration: underline overline;and line-height set in pixels (and it shouldn’t be set in them) to make those two lines touch each other. Perfect in IE8 on Windows.Lastly, if you set line-height in `em` units, the line height vary by a pixel in Firefox and I’m sure in many other browsers.
Cheers!
Zoffix Znet
@Zoffix Znet:
“web design isn’t print design; if you want to control user experience to the pixel then you picked a wrong profession.”
The human eye is capable of distinguishing approximately 600 points per inch.
Now, speaking not as a web designer, but as a “user” who is as self-interested in controlling my experience as you are, I would prefer it if web authors had control over all 600 of those points. If they did, I think my experience would improve substantially.
You may disagree – perhaps slovenliness and/or imprecision is a part of the web’s charm and we will all miss it greatly should authors be given, heaven forbid, such control.
Frankly, I’d be more worried about who has control over content, but hey, that’s just me being paranoid, probably. I’m crazy enough to think that Amazon has the power to delete the books it doesn’t want you to read right off your Kindle! Crazy, huh?
Thanks for your input.
Congrats on finding such a subtle bug!
Just one thing: line height and leading are not the same thing.
When you subtract the content box height from the line height you get the leading.
Chetan,
I was reading your observations about font rendering, as well. I’ll be going back to take a closer look. Good stuff. Bookmarked!
Yes, you’re correct. The CSS term ‘line height’ doesn’t map exactly to ‘leading’ in the print world. thanks for bringing up the distinction because I was planning, at some point, to write a glossary of print-to-web terms.
Regards, Rich
I’m also very frustrated by this bug, running windows server 2003 IE8 tried & tested everything. I’m sorry to say it looks better in IE6… just hope this bug gets sorted.
And sorry Zoffix
“if you want to control user experience to the pixel then you picked a wrong profession.” lol…. funniest thing I’ve heard all week, you probably still use tables Zoffix with 4px borders.
Yes ,I have also experienced this problem, I see this site IE8′s CSS HACK.
position:relative; top/*\**/:1px\9; *top:0;
Hello Richard,
You say
I think you over-excessively exaggerate the damage (severity, gravity, criticality) caused by this bug. It’s 1px. And I am convinced that a very wide majority (over 99.99%) of ordinary people will never notice such a bug. Your demo page is also very revealing of this. You need XP and a good, careful, thorough look to see the visual effect of the bug: a 1px offset.
On the other hand, websites with tiny font size and frozen font-size tyrannizing users, impacting readability, especially for seniors, is still very frequent.
I also checked the code of your webpages, including the code of the test page that reproduces the problem. You should first fix the validation (markup and CSS) errors. e.g.
line-height:22px; !important;Your CSS code is unjustifiably over-declaring, also over-constraining.
When trying to “corner” a bug in CSS or in HTML, you need to reduce code declarations. Your testpage does the reverse: it over-declares. E.g.:
font-family:'cambria';font-size:17px;
line-height:22px; !important;
Why setting font, font-size, line-height? If the bug is really caused by the entities spacers, then you should avoid including lots of CSS declarations; you should reduce CSS declarations to eliminate possible side effects.
Why did you want to set !important to line-height anyway?
You expect to get 2.5px (22px minus 17px divided by 2) for half-leading above and below content area. It does not work like that. Fraction of a pixel is not rendered the same in mainstream browsers (IE8, Firefox 3.6, Opera 10.5x, Safari 4.0.5, Chrome 4.x, Konqueror 4.4.2); some truncate, some round up.
Your testpage does not demonstate that.
position:absolute; left:40px; etc.Wasn’t it possible to create a reduced testpage without having to absolutely position text content? Not sure…
text-align:justify;text-align:right;
text-align:justify;text-align:left;
Why the double text-align declarations?
Well, then I think it would have been a good idea to set font-size: 2em; (or font-size: 200%;) and then write one, only one, 2-lines sentence and then put both of them side by side. Also I would have tried to reduce column width… instead of fixing them to 444px.
Maybe there is a bug with the line-height… but your testpage does not demonstrate this well and correctly. There is just too many issues with your testpage. One good point is that you provided 2 screenshots…
Regarding Zoffix Znet’s comment, overall, I agree entirely with Zoffix Znet. Web design isn’t print design. Web authors should focus on content and less on style and presentation; users should have control over presentation. Users have a veto power over submitted style and presentation in webpages.
regards, Gérard