IE9CV it’s pretty much IE7:
IE
It does seem so, in CV there’s no round borders for instance but for some reason Microsoft decided to keep the old IE7 rendering engine too so pages with jquery/lots of DOM objects automatically load a lot slower.
Okay, so until someone discovers an IE9 only CSS hack out there that gets read by IE9 and IE9 only I don’t think I’m going to win the h1/h2 etc. line-height/padding bug in IE9 (which also exists in IE8 but not IE7).
You would expect/hope that the below gets read by the correct IE version but as it stands (with the /9 hack) it’s a case of a) do I fix IE9 and break IE8 despite it has a hack in place of its own and also kick IE7 enough to marginally see it’s been affected (i.e. 2px up or down) or b) do I leave the IE8 hack in there, keep IE7 happy but IE9 showing its weaknesses that are quite severe in this instance.
The /9 appears to mean all versions up to IE9. That would be fine if true but it seems to take authority, the IE8 hack is ignored if there’s a /9 next to it. The very least Microsoft could do is keep the bug behaving 100% identically across IE8 and IE9.
I tried changing the order too, no go either.
h1.title-index span {line-height: 37px\\0/; padding: 1px 0px 10px 35px\\0/;} /* IE8*/
h1.title-index span {line-height: 45px\\9; padding: 1px 0px 5px 35px\\9;} /* IE9*/
I see no difference in my example in IE9 in native or compatibility mode.
Are you sure that you are no mistaking what’s happening here? The html,body margins,padding and borders are all different across browsers and if you simply mean the menu is moving down then that’s because you haven’t reset html,body to zero defaults.
I’m guessing you are doing the same with the margins on the heading elements also.
Can you give me a working example of that bug to play with please 
Yeah, I also asked a proof. Until then I can only assume it’s an invalid markup or CSS playing tricks on the OP.
Maybe I should have referred to it as a bug but rather an instance of specific browser behaviour. Your example does it too if you click on the CV icon in the address bar. What you say above is likely the cause, but since you don’t have any divs with images below it you can’t see the result as I see it (although you can see how the top margin grows in IE9 CV and IE7). With an image below the menu div and without the hack the menu creeps in under the image below it, gives the impression of a z-order issue.
I’ve attached a screenshot showing how this looks if there’s an image right below the menu, this is without the hack above.
You bring up an interesting point, maybe doing a margin: 0; on the affected headers will fix the issue. I will need to dwell on it and it this doesn’t fix it I’ll package up the components to do a quick run on your end. I’ll also check if reset.css is being read in before default.css. From what I could tell so far it’s more a padding/line-height issue but we’ll see.
Perhaps I should also add that I already have the below code in my reset.css, maybe minify isn’t reading it before default.css (will check - UPDATE - yes reset.css is the first to be read and compressed in by minify, then default.css etc.):
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
vertical-align: baseline;
}
:focus {
outline: 0;
}
body {
line-height: 1;
color: black;
background: white;
}
ol, ul {
list-style: none;
}
caption, th, td {
text-align: left;
font-weight: normal;
}
No, resetting doesn’t seem to do anything useful.
The below code should be enough for you to just copy and paste and see the differences across browsers (note how the vertical alignment falters, all IE7+ seems to be most sensitive - Opera and Firefox is minor - Chrome and Safari are touch wood). Background can be colour or image, same effect.
<h1 class=“header-border”>Some sample text goes here</h1>
.header-border {
padding: 8px 5px 10px 12px;
background: #1947A3;
text-align: center;
-webkit-border-radius: 9px;
-moz-border-radius: 9px;
border-radius: 9px;
}
-
- html .header-border {padding: 5px 5px 5px 10px;} /* IE7*/
.header-border {padding: 6px 5px 11px 10px\0/;} /* IE8*/
- html .header-border {padding: 5px 5px 5px 10px;} /* IE7*/
Sorry but the only difference I see in that code is on the properties you have hacked.
I’ve tested across ie6 - ie9, Firefox and safari and all I get is the usual 1px difference for rounding errors because of font discrepancies as mentioned before. If I set a height they would have all been exact.
If you remove your hacks then they are all pretty much the same. The vertical alignment of text varies in IE browsers by 1px depending of the font size and line height combinations due to the way it rounds things up and down but at most you will only get a 1px difference which you don’t need to hack for.
I’ve attached a screenshot showing how this looks if there’s an image right below the menu, this is without the hack above.
I’d need to see the whole rules for that page as my demo does not do this unless it’s a specific platform issue that you are seeing. Do you have a link to the page or demo so we can check and get to the bottom of this otherwise we seem to be going around in circles a bit.
I still think that the issues are with your code set up and not the browsers (apart from the odd 1px I mentioned). You don’t seem to be controlling margins or line-height properly and are just throwing alternative rules around like little exploding bombs waiting to go off
Text is never going to be pixel perfect cross browser but there is no need to hack the padding like that.
-
there is no reason to be using two separate files for this.
-
nesting the span usually is harder and more problem prone than simply sandbagging it with an APO.
-
when you set all those font properties, condense and set the line-height at the same time.
-
this looks like a menu, get those anchors into UL/LI.
-
If ALL you are doing is applying these backgrounds, why do you need classes targeting each and every one of them.
-
usually if you have to resort to a title attribute, there’s something wrong with the content of the tag – this is particularly true of anchors – I don’t see accesskeys, so there’s no reason to waste time putting title on them.
-
floats are inherently display:block, you don’t need to say that again.
-
I’d have to see the html for #container-header, and probably the entire page layout – though I suspect that’s an unnecessary wrapping element just like all the unnecessary classes.
Though you are trying to make a perfect width menu, something I advise against even trying to do in the first place.
That’s what I’ve been saying all along
Just allow some extra breathing space and then a few pixels difference here and there won’t make a difference and no one will notice.
Okay. I’ve played around with it and this is what I’ve found (the facts as I see them to the best of my knowledge):
a) It seems I can get away with not deploying any hacks whatsoever in as far as h1.title-index span, .header-border, h2.accordion_trigger_index, h2.accordion_trigger_faqs, h2.accordion_trigger_articles (all relate to the vertical text alignment bug mentioned earlier in this thread) if it wasn’t for IE8. IE7, IE9, IE9CV, FF, Chrome, Opera, Safari & Flock do a top/very good (very small differences where apparent) job of vertical alignment. IE8 unless hacked refuses to play ball correctly (even though IE7 just does as its told).
b) The problem with IE8 hacks now that IE9 has surfaced is that IE9 seems to think it’s meant to read them too. If a IE8 hack is in place this will corrupt how IE9 renders the image (IE7 only reads the css it’s supposed to). Maybe this was intentional by Microsoft, who knows.
c) Below is the current live CSS code for the affected div’s (all exemplify the vertical alignment issue in IE8).
h1.title-index {
/* Sliding right image */
background: transparent url("../images/index_title_right.png") no-repeat scroll top right;
display: block;
float: left;
height: 48px; /* CHANGE THIS VALUE ACCORDING TO IMAGE HEIGHT */
padding-right: 35px; /* CHANGE THIS VALUE ACCORDING TO RIGHT IMAGE WIDTH */
margin: 0px 0px 20px 40px;
/* FONT PROPERTIES */
font-size: 30px;
text-transform: uppercase;
color: #FFFFFF;
font-weight: bold;
}
h1.title-index span {
/* Background left image */
background: transparent url("../images/index_title_left.png") no-repeat;
display: block;
line-height: 48px; /* CHANGE THIS VALUE ACCORDING TO IMAGE HEIGHT */
padding: 0px 0px 0px 35px;
}
.header-border {
padding: 8px 5px 10px 12px;
background: #1947A3;
text-align: center;
-webkit-border-radius: 9px;
-moz-border-radius: 9px;
border-radius: 9px;
}
h2.accordion_trigger_index, h2.accordion_trigger_faqs, h2.accordion_trigger_articles {
margin: 0 0 5px 0px;
background: url(../images/h2_trigger_index.png) no-repeat;
height: 46px;
line-height: 46px;
width: 600px;
font-weight: normal;
float: left;
}
h2.accordion_trigger_faqs, h2.accordion_trigger_articles {width: 580px; height: 49px; background: url(../images/h2_trigger_faqs_articles.png) no-repeat; line-height: 48px;}
h2.accordion_trigger_index a, h2.accordion_trigger_faqs a, h2.accordion_trigger_articles a {
color: #FFFFFF;
text-decoration: none;
display: block;
margin-bottom: 10px;
font-size: 24px;
margin: 0px 0px 0px 20px;
}
h2.accordion_trigger_faqs a, h2.accordion_trigger_articles a {margin: 0px 0px 0px 60px; color: #000000;}
h2.accordion_trigger_index a:hover, h2.accordion_trigger_faqs a:hover, h2.accordion_trigger_articles a:hover { color: #CCC; font-size: 24px; }
h2.accordion_trigger_faqs a:hover, h2.accordion_trigger_articles a:hover {color: #C00000;}
h2.active {background-position: left bottom;}
d) The below hacks have been removed from the live CSS and as such result in all browsers but IE8 doing a good job at rendering the corresponding div’s. IE8 on the other hand does a great job of showing its vertical text alignment bug.
h1.title-index span {line-height: 37px\\0/; padding: 1px 0px 10px 35px\\0/;} /* IE8*/
h1.title-index span {line-height: 45px\\9; padding: 1px 0px 5px 35px\\9;} /* IE9*/
* + html .header-border {padding: 5px 5px 5px 10px;} /* IE7*/
.header-border {padding: 6px 5px 11px 10px\\0/;} /* IE8*/
h2.accordion_trigger_index {line-height: 35px\\0/;} /* IE8*/
h2.accordion_trigger_faqs, h2.accordion_trigger_articles {line-height: 40px\\0/;} /* IE8*/
e) If I try and add a height CSS rule to either div then this along with different padding does improve IE8 but IE7 heavily dislikes (it seems) to be given a height. If IE7 is provided a height it will ignore the top margin of that div and move it up therefore colide it with whatever’s on the page right above it.
f) I don’t think I can easily form a demo with just these div’s and prove something’s up somewhere, there also exists the chance that other CSS is interfering. For this reason I’ve uploaded the modified code to a working live website with a lot more going on code wise. This site also uses this exact same codebase so maybe something’s clashing. It’s currently located at: Laptop Memory Upgrades UK
g) To see how IE8 behaves differently but all other browsers do a good job you need to look at the various areas throughout the site:
- On the index page look right at the top where the white title text with navy background is located, this is h1.title-index span.
- Also on the index page scroll down about midway through the page and you will come across h2.accordion_trigger_index, this is the white text on a gray image background (bar shaped).
- On any page other than the index page of the site the first title at the top if white text on a blue background. This is .header-border.
- On any faqs or articles sub-page scroll down (if need be) and you will come across a gray button (bar shaped) with black text on it. This is h2.accordion_trigger_faqs or h2.accordion_trigger_articles (depending on the page you’re on).
All the above will act abnormal in IE8 yet function properly (small discrepancies if at all - most shouldn’t notice this) in the other browsers. All these areas concern the same vertical text alignment issue.
h) That’s all I can think of so far. As I say it’s now become an IE8 only issue. I’m using IETester to test in IE8 but I don’t think this should matter.
i) The IE7 menu issue is a seperate issue. The current live CSS has the IE7 hack in place for now:
* + html .container-menu {margin: 0px 0px 0px 0px; height: 49px;} /* IE7 & IE9 compatability mode*/
Thanks again.
I haven’t looked in detail but I see you that you are using Cufon and the issue is with Cufon as the problem does not exist when cufon is disabled. Line-height doesn’t seem to be working properly when cufon is enabled and as mentioned in the documentation that alternative methods should be used to centralise the text.
BTW that page is a real pig to view and the delay on cufon kicking in is unbearable. I can’t scroll up or down the page for what seems like ages. It must surely be hurting your visitors!
No, the problem is that you have fallen into the trap of using hacks on live browsers which is the number one rule that you should avoid. You can’t just find a hack for IE8 and not know if it will affect IE9 until IE8 has been superseded.
Now that IE9 has been released you can look for hacks that only apply to IE8 and not IE9 but you cannot do this until IE9 has been released. Hence the mantra “only use hacks for dead browsers”.
The backslash hack (\9) at the end of the property value is a hack that should never have been used for IE8 because it is unstable and its effect on future browsers unknown.
You only have yourself to blame for using it in the first place I’m afraid.
Here is the hack I came up with for ie8 a while back.
- html p {color:red;} /* Valid/Safe Hack For IE6 */
+html p {color:green;} / Valid/Safe Hack For IE7 /
p {color:blue\ !important;} / InValid/Not-So-Safe Hack For IE8 */
From this page. http://www.visibilityinherit.com/code/target-ie.php
Hi Eric
That hack also hits IE9 which means that IE9 is getting hacks for bugs it doesn’t have
It’s just not safe to use new hacks because they may affect future versions which understand the hack but don’t have the same bug.
Oh does it. I havn’t checked that hack since ie8 first came out. I agree of course. There are many other valid and safe ways to feed IE.
Yes, now that IE9 is out using IE8 hacks is dangerous, for some reason IE9 wants to still read them.
I did some more tests and it wasn’t all to do with Cufon (but Cufon seems to have made it worse - i.e. more visible padding top/bottom discrepancies) but since cufon is used, I had to implement the following CSS. This way the vertical text alignment seems identical in all browsers:
h1.title-index span cufon {
padding: 3px 0px 2px 0px;
} /* IE8 cufon fix*/
.header-border cufon {
padding-top: 2px;
} /* IE8 cufon fix*/
p.date-time span cufon {
padding-top: 2px;
} /* IE8 cufon fix*/
h2.title cufon {
padding-top: 2px;
} /* IE8 cufon fix*/
h6.page_sub_header span cufon {
padding-bottom: 2px;
} /* IE8 cufon fix*/
h2.accordion_trigger_index cufon {
padding-bottom: 5px;
} /* IE8 cufon fix*/
h2.accordion_trigger_faqs cufon, h2.accordion_trigger_articles cufon {
padding: 2px 0px 2px 0px;
} /* IE8 cufon fix*/
All IE8 hacks have been removed, IE7 hacks are still necessary on the odd occasion here or there.
Thankfully IE9 is not only considerably faster than IE8 (though JQuery performance is still left wanting) but providing IE8 CSS hacks aren’t forced onto it, it acts more like the class leaders: Chrome/Firefox. Only the menu width issue had to be redone as stated earlier in this thread.
As for the delay in loading that site. Some optimisation is needed, fewer DOM objects (possible), image expiration headers (caching in place in htaccess but YSlow still thinks other’s), etags (from what I know these are best left disabled due to browser problems but again, YSlow wants them on).
I’ve found cufon to always delay the rendering of a page, at most 2-3 seconds. It’s the older browsers (IE7/IE8) that increase this delay. Chrome is top dog but FireFox, Opera, Safari, as far as I can tell they’re swift at it.
Glad you are making progress
The problems with hacks is that they start compounding and fighting each other and you have to really remove them all and start from scratch and see what the real issues are. That’s what I did and how I saw that the biggest problem was cufon and a quick visit to their site confirmed this was a problem.
There are 1px alignment diffrences in browsers which for the most part you can live with but there are never discrepancies with padding once you have zeroes the defaults.
The issues will more likely be concerned with line-height, general rounding errors, haslayout or collapsing margins. Most of which can be cured without specific hacks or by using hacks that need no maintenance.
Once you start altering position and padding for each then that’s a very slippery slope.
I code a different number of templates each week and have no problem in getting relative consistency between most elements (apart from form controls which are a whole different kettle of fish)
Thanks for the input, and sticking throughout in this thread, multiple minds are always better than one
I guess my habit of opting to implement CSS hacks stems from the fact that as far as my mind can stretch it’s always been predominantly IE failing to follow the pack and basically wanting to be different. No other browser that I’ve ventured across has been so abrupt in its ways. From this I’ve just assumed the logic that if IE wants to fight, we should fight it back.
I guess Microsoft is finally starting to see that most complaints refer to its ill implementation of CSS standards and thus losing market share (including how much faster the competition was/is too at rendering the same code). It’s taken years and years but there’s finally light at the end of the tunnel