IE9 launched yesterday but it’s too much to trust Microsoft these days it seems. IE6 and IE7 was a pain CSS wise, IE8 much better but IE9 is at best the same as IE8.
IE9 causes three different CSS quirks when rendering my site, oddly enough one of them never occured in IE7/IE8.
For IE7 we had this CSS hack:
html
For IE8 we had this:
\0/ - i.e. padding: 0px 5px 10px 70px\0/;
Is there one for iE9?..I can’t find anything yet…or must I resort to using the messy if statements or seperate css files? It’s a padding bug, IE9 just loves to throw in a few pixels padding here or there, just to be awkward. Perhaps I’ll never understand how you can employ so much talent, pay them well, oversee their coding and yet do this each time.
Thanks guys. The PHP method seems interesting. I have found that \9 seems to work inline with the css, something like this:
margin: 8px 4px 0px 0px\9;
Now that IE9 is final I assume they’ll keep this active, even though it’s far different to the previous hacks for IE7/IE8 (why can’t Microsoft be consistent?).
It does seem an only IE9 issue. The 1st problem concerns menu buttons, IE9 expands them more than the CSS thus causing them to enter a 2nd row. The other two issues involve H2 heading positioning. Only IE8 had this problem but now IE9 also.
I’m using a strict DTD so from what I know IE should just follow the rules…
Looks like I spoke too soon, the \9 hack affects not only IE9 but all versions prior to it (IE8, IE7 etc.). Since the earlier versions don’t reveal this bug fixing one breaks the others Ah the joy…
IE9 also seems to splitting pixels A right maring of 4px is 1px too low but a right margin of 5px causes IE9 to render the last menu button on a new row.
I’d love to see a working example of this bug so that we can document it properly. Can you knock up a working demo?
Are you sure its not just the default margins and padding that you haven’t accounted for?
If we don’t define the reasons and triggers for the bug then it’s a bug that will bite often.
Hacking isnt really the way to go as you never know who else the hack will affect and live browsers shouldn’t really be hacked anyway. What happens when they get updated and your hack breaks the whole page.
I very rarely see a need to hack IE8 and have never run into padding issue on normal elements.
However, I am very interested in IE9 bugs that are found.
I’ve attached the css and menu code necessary to get this working. The menu code needs to go inside the parent div container (#container-header).
It will probably be difficult to see this bug without having something 1144px wide just under the menu, say a line or graphic. Either way it IE9 will move the last menu button to a new line as soon as the gap between the home button and the next menu button (see below) is made consistent with the other browsers (in other words the home button margin-right is set to 8px in IE9 instead of 5px).
I got it to overcome the 1px bug in IE9 but I had to change the parent div container width from 1144px to 1145px even though the realworld width is 1144px. IE9 is eating up 1px somewhere in the parent div width. Unfortunately IE9 isn’t pixel perfect. Difficult to see what I mean from text but in the example there are several menu buttons. The first menu button is a home button. It’s right margin is slightly more than all the other buttons, this just to make it stand out from the others. In IE9 this gap has to be smaller than in all other browsers, including IE7 and IE8. If you attempt to make this gap the same as in the other browsers (all but IE9) then you run into the double row menu issue (back to square one).
So in summary, while not pixel perfect the only solution I have found thus to fix the double row menu issue in IE9 far is:
a) Increase parent div width by 1px
b) Decrease margin-right of home button (1st button in menu) from 8px to 5px
Result:
In IE9 the menu now stays on one line, but the gap between the home button and the neighbouring menu button is visibly smaller, i.e. rendering is now longer pixel perfect across browsers (including the IE family).
Other:
\9 works as a css hack for IE9 but automatically breaks IE7/IE8.
I’ve taken screenshots of how IE9 and Chrome renders it and then cut and pasted each row of menu buttons in MS Paint and aligned them one below the other.
It’s now clear where the extra pixels are creeping in when rendered in IE9 and consequently why the gap between the home button and the next menu button has to be narrowed to compensate, and the parent div container widened by 1px.
It looks like in IE9 each menu button (thus the code below) is 1px wider than in IE7/IE8/Chrome/Firefox/Opera/Safari/Flock.
a.menu-button-home, a.menu-button-guide, a.menu-button-buy, a.menu-button-faqs, a.menu-button-articles, a.menu-button-vouchers, a.menu-button-about, a.menu-button-contact {
/* Sliding right image */
background: transparent url("../images/top_menu_button_right.png") no-repeat scroll top right;
display: block;
float: left;
height: 39px; /* CHANGE THIS VALUE ACCORDING TO IMAGE HEIGHT */
padding-right: 16px; /* CHANGE THIS VALUE ACCORDING TO RIGHT IMAGE WIDTH */
margin: 8px 2px 0px 0px;
/* FONT PROPERTIES */
text-decoration: none;
color: #000000;
font-family: Arial, Helvetica, sans-serif;
font-size: 16px;
font-weight: bold;
}
a.menu-button-home span, a.menu-button-guide span, a.menu-button-buy span, a.menu-button-faqs span, a.menu-button-articles span, a.menu-button-vouchers span, a.menu-button-about span, a.menu-button-contact span {
/* Background left image */
background: transparent url("../images/top_menu_button_left.png") no-repeat;
display: block;
line-height: 22px; /* CHANGE THIS VALUE ACCORDING TO IMAGE HEIGHT */
padding: 10px 0px 8px 16px;
}
The issue is really the way you have coded that page.
You are using the width of the text to make those items fit on one line which is never going to fly especially for users with large fonts selected or 120 dpi settings.
There is also the issue of how different fonts are rendered and how their sizes vary as well as the space between letters and words etc etc…
You should never rely on something fitting an exact pixel container purely by means of the content it holds. Browsers are always going to round things up or down and will always disagree.
If you want 8 items to fit exactly across the width of the menu then you have to give them all an exact pixel width or use the display:table properties to equally distribute them (ie8 and upwards). You can never rely on text being the same in any browser and indeed on the mac systems the width of text will also vary.
You should have given widths (without padding) to the eight items and then just centered the text within those items with text-align:center so that text could be resized a little without upsetting the width.
Top and bottom padding isn’t really needed either (unless you want two lines of text in a tab). Just use line height equal to the height which would have ensured that the text was vertically centred and also cater for text resize without breaking
Much of web design is doing things the right way as you have to allow for variances across systems.
If you wanted fluid with menu items then you should just allow more room for them and not try to make them fit. Give elements breathing space.
Also your structure for the anchors is bad for accessibility and bare anchors should never be next to other. They should be within a list element to provide semantics and structure.
Secondly, a few things spring to mind that potentially clash (I think):
a) I have tried DPI at 120% and the menu renders fine in IE7, IE8, FireFox (all), Opera (all), Safari (all), Chrome (all) and Flock (all I thin). Only IE9 renders it with extra padding here or there causing the last menu button to get kicked onto a second row.
b) The menu will break in all browsers as far as I can tell (i.e. it will break into two rows) if I use the browser’s zoom function. As far as I can tell this is expected in many websites on the web and glitches will occur unless one uses pure CCS3 etc. True?
c) You speak of fonts. The menu uses Arial. As such, do you think Arial is not available on all platforms (including smartphones if you prefer) and thus an alternative font will be used to render the link text thus potentially widen the menu button width? Windows based PC’s/Laptops and/or Mac’s out there should have Arial right?
d) The part that confuses me most is how you say that ideally the menu buttons should be of fixed width instead of dynamic where there width is determined at runtime by the browser. Assuming I read you correctly, would you be referring I scrap the sliding window menu button technique? I’m not sure I follow this 100% because in such case this would imply I increase the number of button images I need of various lengths (i.e. 6-7 buttons = 6-7 button images). Doing so would mean more DOM objects and more page weight.
Could you just elaborate whether I understand you correctly? What ultimately strikes me is that various browsers do as they’re told (including IE7 and IE8 - at least in this respect) and then comes along IE9 and the only way to attack it is to do a complete rewrite of the menu code, and also make it more bulky?
I’m going to dwell on what you said some more…maybe I’m seeing the woods but not the trees.
I think I’m starting to see what you mean…it goes like this:
a) keep your sliding window technique in place but remove left & right margins so all menu buttons appear right next to each other (no gaps).
b) next, write a div container for each button and set each to the desired width of its corresponding menu button. Package each menu button inside its respective div container so that the latter adds the illusion of a gap between the menu buttons (i.e. the menu button container has to be a little wider than the given menu button).
That just leaves the comment about text-align: center; - not sure how that fits in unless the sliding window method is scrapped.
As I said above you are seeing something different to me already. I am seeing the opposite as shown in my demo and in my browserscam screenshots showing that it’s not just my system. I’m not seeing extra padding but smaller text instead.
b) The menu will break in all browsers as far as I can tell (i.e. it will break into two rows) if I use the browser’s zoom function. As far as I can tell this is expected in many websites on the web and glitches will occur unless one uses pure CCS3 etc. True?
No, not if you use ems instead of pixels but of course that will give you more rounding errors than you had before and less pixel precision.
It will also not break (with text only zoom) in the method I suggested by using widths. It will eventually break but not for while as there is no padding inside the menu items and as the width is wider than the text then the text can resize and will not break out of the element for a while.
c) You speak of fonts. The menu uses Arial. As such, do you still think Arial is not available on all platforms (including smartphones if you prefer) and thus an alternative font will be used to render the link text thus potentially widen the menu button width? Windows based PC’s/Laptops and/or Mac’s out there should have Arial right?
I find that that fonts vary between browsers especially on a mac. I often see menus like your breaking to a new line in safari for example because the text is rendered slightly fatter.
It may be that some fonts are better than others but you should never expect them all to be exactly the same. The fact that you see consistent results in this example except for IE9 is probably more luck than judgement. I see differences daily.
d) The part that confuses me most is how you say that ideally the menu buttons should be of fixed width instead of dynamic where there width is determined at runtime by the browser. Assuming I read you correctly, would you be referring I scrap the sliding window menu button technique? I’m not sure I follow this 100% because in such case this would imply I increase the number of button images I need of various lengths (i.e. 6-7 buttons = 6-7 button images). Doing so would mean more DOM objects and more page weight.
I’m not sure what you are saying here exactly:)
I was working on the menu you had given us where you had entered text to make the menu an exact total width. If you don’t need them all to total an exact with then just allow some breathing space. This is one of the most important concepts on a web page and one that is little understood.
Things just render differently on different browsers and you have no absolute control over this so don’t try. Just make sure that you have a few pixels of breathing space and you can accommodate these discrepancies without batting an eyelid.
For example just reduce the padding slightly on your menu and then it fits in all browsers. I only suggested a width on each menu item because I assumed that you wanted it to fill the 100% width exactly edge to edge etc.
What ultimately strikes me is that various browsers do as they’re told (including IE7 and IE8 - at least in this respect) and then comes along IE9 and the only way to attack it is to do a complete rewrite of the menu code, and also make it more bulky?
I may be misunderstanding your finished article but it looked to me as though you were trying to make the menu fit an exact width by using its contents only.
If this is nt the case then just reduce the padding slightly and it will fit in all. No one will notice the difference but you.
If that’s not what you meant or you had something in different in mind then you may need to clarify a bit more.
Yes keep the sliding window technique in place and keep the margins but just set a class on each menu item and apply a width for each one so that when combined with the margins will equal the total width available. This means that each menu item will be a certain width and the text inside will be centered with text-align:center.
Each menu item should be about as wide as you have them now (but sized to fit the available space exactly) with no padding and simply held open by the width applied.
No need to do anything else different.
Assuming that I have understood what you wanted of course
I see, thanks. So basically write a wrapper div that will wrap around each menu button with a specified width matching the given menu button. Something like this:
…and in such case the only caveat is to measure pixel for pixel the exact width of each menu button. Hmmm, if I follow you correctly then I’ll hopefully try this tonight, will be good to see what happens considering IE9 is rendering 3 of the 7 buttons slightly wider than the other browsers.
Check in any browser and it should fit the same - including IE9.
Preferably I would not size each menu item but just make them smaller so that they can expand and contract without breaking the menu.
However if you must have it fit exactly like my demo then you have no choice but to size each item to fit.
As you can see form that ccs tricks link I posted above the text length varies quite considerably from browser to browser so you cannot rely on text length being the same.
wait…
isnt the easiest way to target IE a conditional link to the relevant stylesheet, this way you can target any version (or range of versions) as necessary?
<!–[if IE 9]>
<link to ie9.css >
<![endif]–>
unless you were saying hacks which made ONLY IE see the code… ( *+ html would be a misleading example tho)
Hacks were bad to begin with, the real risk , IMHO… would be the odd chance that new versions Chrome or FF decide to see * html{} or * + html{} . Would we be screwed then? LOL.
I suspect “the bugs” in IE9, for which I still like to see the page outlining them, are about… tables layout? I just came from the HTML and XHTML forum, where somebody faces a “bug”. It appears that, the old problem reappeared: if no width is declared for the cells in the first row, the colspan partitions are looking different in IE9.
Yes, I agree that would be the easiest and safest way to target all IE versions but the OP did say in the first post:
or must I resort to using the messy if statements
Which is why I tried a different tack and tried to avoid using any hacks at all.
Hacks were bad to begin with, the real risk , IMHO…
Yes I agree that hacks were a bad invention - but necessity is the mother of invention and IE was a mother to fix.
would be the odd chance that new versions Chrome or FF decide to see * html{} or * + html{} . Would we be screwed then? LOL.
[/quote]
By the same token they could break normal rules also (just like the way that border-radius changed and the way that Firefox changed how overflow worked from FF2 (and like opera breaks something else in every new version in some way or another)) so there’s no guarantee either way.
It’s less likely that a new browser would accidentally replicate an old browser bug though but who knows you may be right.
I think the main issue is to avoid having to use hacks in the first place and ensure that the code can work within reasonable limits without the need for them.
Okay, so first off thanks again for uploading that example, very transparent/easy to follow what you did etc.
Secondly, once implemented and tweaked somewhat it works fine in all browsers as far as I can see (tested with DPI at 120%). Only IE7 and IE9 in compatibility mode caused issues. This has been fixed with the hack below. Basically IE7/IE9C was now moving the menu buttons south for some reason. I made the menu container a class so I can style its ul if need be from within the css file rather than inline via style=“”. Also applying the width’s to the menu button class and not its span. IE9 remains the only browser from the pack that needs the width’s applied for it to skip adding its own padding here or there when it feels like it.
IE9 does seem to carry over the line-height/padding h1/h2 etc. bug from IE8 though (separate issue but since this thread is about IE9 bugs…). Not visible unless the h1/h2 etc. has a background image/colour and/or image (i.e. especially an accordion header that often use images for section markers). Will have to look into that next. Also present in Firefox/Opera but not Chrome/Safari/Flock/IE7 but less visible.
Ah the joy…
