Text Alignment w/ IE9 in Standards-Mode

Can someone help me vertically center text inside a div, consistently across browsers. In IE9 ONLY, text is one pixel closer to the top of the parent div. All other browsers render the text as expected.

Important: I’m using standards-mode:
<!DOCTYPE>

<!DOCTYPE>
<html>
	<head></head>
	<body>
		<div style="width:100px; height:16px; font-size:13px; font-family:Arial; line-height:1.2; background-color:red; color:White; vertical-align:middle">
			<div style="line-height:16px">XXXXXXXXXX</div>
		</div>		
	</body>
</html>

The above code gives me the same display in Firefox and IE9 with 3px at the top and bottom.

I wouldn’t be surprised though to see it 1px out though as IE7 is usually 1px out when either font size is an even number and line-height is an odd number (or vice versa) due to the way it handles rounding.

I believe that IE9 also use sub pixel positioning algorithms and as your line-height of 1.2 equates to 15.6px then that may also be an issue. Try raising it to 16px and see if it makes a difference for you.

However as I said I see no difference on the code you gave between ie6 - 9 but I don’t doubt that you might see a difference depending on system.

In truth there will be little you can do about it apart from hacking it to death which seems a trifle silly for 1px.

Thanks for the reply Paul!

The problem may seem minor, but it’s affecting a large portion of our site. We have a lot of text overlaying images to represent button, etc.

I’ve made the chages you suggested and it’s still not centered. Here’s the simplified code:

<div style="width:100px; height:16px; font-size:13px; line-height:16px; font-family:Arial; background-color:red; color:White">
	XXXXXXXXXX
</div>

Changing the doctype gives expected results, but nothing else. And we dont want to change the doctype for the site.

Was your test in standards-mode?

Hi,

Sorry my mistake, I ran the page in an open tab and I’d tripped quirks mode while testing something else earlier.

I can confirm that I get the same result as you now with the code above.

Upon further investigation is seems that the issue is that the text you were using was an uppercase X which meant that the element has no descenders. If you add a letter with descenders then it seems that IE9 is actually in a better position than other browsers. It doesn’t really help I know as it would be preferred if they all did the same.

The only solution I could see would be a hack and to give IE9 line-height:17px which puts it in the position that you want.

Obviously you would need to do this via conditional comments and target IE9 only.

I;ll keep looking for something better :slight_smile:

This might be a solution. Try setting the line-height to 16.49px.


        <div style="width:100px; height:16px; font-size:13px; font-family:Arial; line-height:16.49px; background-color:green; color:White; vertical-align:middle"><div>XXXXXXXXXX</div></div>        

That seems to make IE9 and firefox consistent.

However, I notice that both safari and Crome on the mac are showing the same as IE9’s originals display. The above fix does nothing for them. (Safari and Chrome on the PC match Firefox).

Wow, that’s it (on PC at least). Very odd. Any thoughts as to why sub-pixel line heights would cure this? A couple of Microsoft Gurus are looking into this as well and I’ll update this thread if they offer any insights.

With a 16px line-height, how did things look on Mac? No macs here to test on.

Paul - Thanks a ton for working on this with me!!

Can you try this on Mac?

<div style="width:100px; height:16px; font-size:13px; line-height:16.5px; font-family:Arial, sans-serif; background-color:red; color:white">
	XXXXXXXXXX
</div>

The above works consistently on all of the PC browsers I’ve tested, even IE6.

Hi,

That doesn’t work for Chrome or Safari on the mac but I’ve done some more testing and this seems to work.


<div style="width:100px; height:16px; font-size:13px; line-height:16.99px; font-family:Arial, sans-serif; background-color:red; color:white"> XXXXXXXXXX </div>

16.9 doesn’t work but 16.99 does.

As far as I can tell that sets all browsers to be the same unless I made another error :slight_smile:

Stupid question…

You’re declaring everything else in PX, WHY are you even TRYING to use 1.2 for the line-height on the outer wrapper?

Much less if you use %/EM or WORSE the unmetered declaration you WILL have rounding error differences between IE and FF.

Of course I’m seeing six different renderings in six different browsers here…

In IE line-height can often override vertical-align. This is why as a rule of thumb I would never set different line-heights and height at the same time.

Though I think much of the problem as I’m seeing it here is that IE, Opera and FF are all rendering the TEXT as different sizes thanks to that 13px. Odd numbered font sizes do NOT render reliably cross-browser. Change it to 12px or 14px and it’s less problematic – though it will NEVER be perfect.

Really if you need that level of ‘precision’ across different browsers, there’s probably something wrong with what you are trying to do and/or how the site is built in the first place… of course using the HTML5 doctype ALONE tells me that.

Yes I did mention that above also as its seems a contradiction. It didn’t help though changing it to px but it was my first thought also.

Though I think much of the problem as I’m seeing it here is that IE, Opera and FF are all rendering the TEXT as different sizes thanks to that 13px. Odd numbered font sizes do NOT render reliably cross-browser. Change it to 12px or 14px and it’s less problematic – though it will NEVER be perfect.

Really if you need that level of ‘precision’ across different browsers, there’s probably something wrong with what you are trying to do and/or how the site is built in the first place… of course using the HTML5 doctype ALONE tells me that.
I have to agree that 1px perfection where text is concerned is really a fruitless task. It seems that IE9 is always 1px different from other browsers no matter what combination of font size and line-height you use.

It was interesting to note that most browsers apart from IE9 are vertically aligning the uppercase case character perfectly but when a descender is added into the mix then the space on top and bottom is no longer equal.

Indeed Firefox has no space under the bottom of a letter like “y” using the above code but Ie9 positions it much better.

So I suppose the question is who is right and whether ascenders and descenders should both be counted in vertical alignment (even when not present in the prose). It would be nice if browsers makers spent more time fixing the basics such as their rounding algorithms before they implement all the new features.

Thanks Paul. The tabstrip is looking much better now with text more consistently centered. I’ll update here with Microsoft’s contribution, after I get it.

Thanks, it’ll be interesting to see what they say :slight_smile:

I’m not. Even with it set to 16px, the problem persists. Only in IE9.

This is for a tabstrip. I dont see anything wrong with wanting the text to be vertically aligned, as it was prior to IE9. What’s wrong with using the standards-mode doctype?

Uhm, I’m not on my workstation to test this, but wouldn’t vertical-align:top, a shorter line-height and padding then fix that issue? The ‘top’ should never change on most fonts.

say… font:normal 13px/14px arial,helvetica,sans-serif; padding 1px 0; to add up to that 16px? (I’d probably also pull the height declarations unless needed as a haslayout trigger). With vertical-align:top the descenders should have no effect since top is top…

You may also consider just making them tall enough it’s a non-issue, like say… 4px padding for 24px height? Borders that close to text often make them harder to read. You make them taller the 1px difference wouldn’t be as noticeable.

Problem is with all the different font renderers you cannot rely on

I’m seeing it different and not centered in ANY version of IE here – but I’m a large font/120dpi user so IE9 is defaulting to 125% zoom. Not sure what’s messing it up in earlier IE’s though; IE6 it’s acting like vertical-align:top is set and seems to be outright ignoring any values on v-a.

That’s not the “standards mode doctype” – there’s no such thing as that; Using A doctype will trigger standards mode… But really IMHO HTML5 is NOT ready for real world deployment and I’m hoping it never will be. It’s a disaster of a specification undoing ALL the progress STRICT gave us the past decade, and is so loose on rules and whats valid/invalid it’s nothing more than a return to the train wreck that was HTML 3.2

Which is who it seems to have ENTIRELY been crafted for; the people who either never embraced STRICT or failed to grasp it’s purpose.

So when I see the HTML 5 doctype, I generally assume the entire page it’s from is screwy.

HTML 5 isn’t based on SGML and so doesn’t have a doctype at all. It does however require that the first tag in the HTML be <!DOCTYPE HTML> which just happens to be identical to the short version of the doctype that can be used with HTML 2 through HTML 4. As web pages only use the doctype as a switch to determine whether to use the standards or not in displaying the page and do not actually use the doctype itself, it makes no difference to the web browser whether any of the other parts in the longer version of the doctype is there or not. Even the validators only read what is in the doctype tag and don’t use the actual doctype itself. There currently isn’t anything that I know of that actually does use the actual doctype which is perhaps one of the reasons why those developing HTML 5 decided that they didn’t need one.

Any unknown doc type will trigger quirks. That can mean a typo as well so just providing one won’t necessarily trigger standards. Each browser is different. Here’s a great explanation and chart for browsers:

CSS - Quirks mode and strict mode

I was wondering about that myself. I mean how does a UA that predates HTML5 by 10 years know NOT to go all Quirks Mode when it sees HTML5’s doctype?

I was wondering about that myself. I mean how does a UA that predates HTML5 by 10 years know NOT to go all Quirks Mode when it sees HTML5’s doctype?

Somewhere deep inside those older UAs is a note saying
<!doctype html>
is a shortened version of any of the longer, fuller doctypes.

In other words, a shortcut they’ve always recognised and the HTML5 people are taking advantage of simply to avoid browsers using their Quirks Modes.

Apparently nobody figured this out until HTML5 people started playing around with what they could get away with?? Since browsers never actually read those doctypes.

What’s weird to me is that having the long version, but making a small mistake (like having two spaces instead of one between two of the words… yes, I did this once!) or leaving off the referrer url DOES trigger quirks mode.

It’s like it’s gotta be the shortened version, or everything perfect.

I don’t think that’s quite true :slight_smile: (Where’s Tommy when you need him :))

This works:


<!doctype this is junk >

It’s the doctype element that will trigger standards mode. (Or perhaps to be more correct an unrecognised doctype.)


<!doctype>

On its own it is an unrecognised doctype and standards mode is assumed. It’s mentioned in Eric Meyers chart from many many years ago.

It’s only when combinations of label and url are added that you get the various quirks modes, nearly quirks and standards mode being defined.

Making a typo in these will not always default to quirks mode but ony when the typo nullifies one part and then the remaining part matches the requirements for quirks mode.

e.g.

This junk will still render in standards mode in all versions of IE.


<!DOCTYPE HTML PUBLIC [B]what is this for[/B] "-//W3C[B]xxx[/B]/DTD HTML 4.01//EN" "[B]Nonsense here [/B]http://www.w3.org/T[B]xxxR[/B]/html4/strict.dtd">

But this won’t.


<!DOCTYPE HTML PUBLIC what is this for "-//W3Cxxx/DTD [B]rubbish [/B]HTML 4.01//EN" "Nonsense here http://www.w3.org/TxxxR/html4/strict.dtd">

Obviously in the second example I broke the pattern searched for.

So we can assume that browsers first assume standards mode for any page with a doctype element and then try and match wsections of whatever else is in the doctype against all the known options available.

CSS Enhancements in Internet Explorer 6
Eric Meyer on CSS: Picking a Rendering Mode