Text Alignment w/ IE9 in Standards-Mode

**Peralta** · Mar 24, 2011 12:36

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>

Code:

<!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>

**Paul O'B** · Mar 24, 2011 13:55

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.

**Peralta** · Mar 24, 2011 14:07

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:

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?

**Paul O'B** · Mar 24, 2011 15:47

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

**Paul O'B** · Mar 24, 2011 16:17

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

Code:

        <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).

**Peralta** · Mar 24, 2011 16:49

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.

**Peralta** · Mar 24, 2011 16:55

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

Can you try this on Mac?

Code:

<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.

**Paul O'B** · Mar 24, 2011 17:06

Hi,

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

Code:

<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

**deathshadow60** · Mar 24, 2011 21:53

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.

**Paul O'B** · Mar 25, 2011 05:20

Originally Posted by deathshadow60

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?

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.

**Peralta** · Mar 25, 2011 05:48

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.

**Paul O'B** · Mar 25, 2011 05:51

Originally Posted by Peralta

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

**Peralta** · Mar 25, 2011 05:56

Originally Posted by deathshadow60

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

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

Originally Posted by deathshadow60

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.

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?

**deathshadow60** · Mar 25, 2011 15:06

Originally Posted by Paul O'B

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.

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.

**deathshadow60** · Mar 25, 2011 15:17

Originally Posted by Peralta

This is for a tabstrip. I dont see anything wrong with wanting the text to be vertically aligned, as it was prior to IE9.

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.

Originally Posted by Peralta

What's wrong with using the standards-mode doctype?

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.

**felgall** · Mar 25, 2011 19:50

Originally Posted by deathshadow60

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.

**thumbslinger** · Mar 25, 2011 22:10

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

**dresden_phoenix** · Mar 25, 2011 23:15

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?

**Stomme poes** · Apr 4, 2011 01:21

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.

**Paul O'B** · Apr 4, 2011 02:26

Originally Posted by Stomme poes

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

I don't think that's quite true

(Where's Tommy when you need him

)

This works:

Code:

<!doctype this is junk >

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

Code:

<!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.

Code:

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

But this won't.

Code:

<!DOCTYPE HTML PUBLIC what is this for "-//W3Cxxx/DTD rubbish 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

**Stomme poes** · Apr 4, 2011 02:37

This works:
<!doctype this is junk >

OMIGOD my next page will absolutely have
<!doctype w00t>
if that really does work down to IE5 and FF2!

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

...this won't [work]:

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

Hm, that makes sense: my double space was somewhere around the "EN" part, which would break the "4.01//EN" section.

**noonnope** · Apr 4, 2011 05:52

Originally Posted by Paul O'B

This works:

Code:

<!doctype this is junk>

I get quirks mode in FF4 and Op11. It's standard for IE8.

Code:

<!doctype this is junk>
<html lang="en"><head>

  <title>Testing page</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

</head><body>

  <h1>Testing 123...</h1>

</body></html>

**Stomme poes** · Apr 4, 2011 06:30

Aw, darn.

And I was gonna have such a cool doctype : (

**Paul O'B** · Apr 4, 2011 06:42

Originally Posted by noonnope

I get quirks mode in FF4 and Op11. It's standard for IE8.

Yes, I'm not sure what each is looking for exactly.

This will trigger standards mode in Firefox.

Code:

<!doctype html public "this is junk">

User Tag List

Thread: Text Alignment w/ IE9 in Standards-Mode

Thread Tools

Display

Text Alignment w/ IE9 in Standards-Mode

Tags for this Thread

Bookmarks

Bookmarks

Posting Permissions