Has anybody else come across IE9 on Vista rendering oddly?
I have a page which I tested in IE9 on Windows 7 and it was fine, but I saw it yesterday on the client’s computer running Vista and the background colour on the <body> is missing, as is the last line of text. It’s a very simple page with valid HTML and CSS, so there’s nothing for any browser to choke on, and it’s fine in every other browser I’ve tested. It’s also fine in Chrome on the client’s machine, so at least I could prove I hadn’t missed off their contact details.
In this instance, it doesn’t really matter as it’s only a “holding page” until they get their act together and get their “real” web site up and running, but I wondered if there were any known issues I should be aware of, since I can’t test in Vista (and BrowserCam only has IE7 and IE8 on Vista).
It was really just a theoretical question about IE9/Vista in general. However, I would be interested to know if anybody else using that combo is seeing the same thing. I didn’t get a chance to investigate the problem on the client’s computer.
http://www.theislayhotel.com - There should be a pale lilac background on the body, and two lines of text in the footer.
I changed the background-color to rgb(0,128,0) and I now get a dark green background colour in the <body> in both IE9 and FF7 under Vista. I don’t nornally use hex colours so I don’t know what the problem with #EEF is.
Thanks for testing that. It seems really weird. I’ve tested IE7 and IE8 on Vista in BrowserCam (the only way I can do it) and the background is showing OK. Heck - it’s even OK in IE6. I’m even more surprised to find the problem occurs on Firefox7, too. I tested that (live) in Linux and Windows7 and it’s fine in both.
I don’t normally use 3-digit hex values, so I wonder if that’s the problem. Would you mind testing again using #EEEEFF, and, for good measure, rgb(238 238 255) to see if the objection is to my notation or my choice of colour? Thanks.
I’m seeing a character encoding mismatch here, that could be part of the issue – NOT that valid CSS or should contain anything more than ascii7 meaning there is no legitimate reason to EVER declare the character encoding in the file.
The font family stack could also be causing issues, IE hates massive families… the use of condensed properties there may also help, and easing up on the inconsistent mix of spaces, tabs, ntabs and enspaces used for indenting wouldn’t hurt either. (the latter two possibly also being causes of your issues – just what are you using for an editor?)
The stack doesn’t even make sense – I’ve never seen a machine that had verdana or arial that didn’t have trenchbucket ms – so there’s no reason to even say those… likewise nimbus is on NOTHING I’ve ever seen, and if that’s a non-windows option helvetica is aliased in *nix and mac…
You also do not redeclare your line-height when you changed the size on your h1/h2 – that alone could be wreaking all sorts of layout havoc since the line-height will remain at the same size and not rescale. You change the font size significantly (like say… 250%) re-declare your line-height. I suspect this is why you have the pointless min-height in there and why the layout is busted here on my 120dpi setup.
Of course putting media types on the CSS embed wouldn’t hurt either… I wouldn’t have that presentational logo image in the markup… and it feels a bit DIV heavy for a single column layout… and I’d not be declaring %/EM fonts next to an image interaction like that logo; given the massive size it’s one of the few times I’d say go ahead and use px since NOBODY is going to kvetch about 40px being ‘too small’ – and it breaks horribly when it does get that 25% larger on LF/120 systems. You’re also declaring padding on the wrapper while declaring a width, which is just asking for layout headaches… and looks too massive when it does auto-size along with the content.
… and your comment placements could be tripping IE and FF rendering bugs (YES I SAID COMMENTS), though the lack of floats means that’s unlikely, it’s still never good to put comments between div like that… which is why I put them BEFORE the closing tag.
is wide open for easy access, tested just fine all the way back to IE 5.5… I also left out the .htaccess that forces UTF-8 to test that encoding mismatches are a non-issue. (NOT that either file uses anything more than ASCII7)
It’s often the little details and choices that bite you on these types of things; things that made IE 5.5 behave still are a good idea even if you don’t give a flying purple fish about a browser that old – never declare padding and border the same time as width for example… on the font front, you change the font-size RESTATE the line-height, at which point it’s usually clearer and more efficient to just use the entire full condensed font declaration – which works flawlessly and often saves you a few bytes. Massive font-family sets are often problematic and nonsensical – especially if you declare fonts from the same set (like say… the microsoft core fonts).
also, I only use background-color when I have an inherited background-image and don’t want to change the image – the condensed ‘background’ property is a lot easier.
Oh, another possibility is that they were on a garbage monitor that had the contrast set improperly – #EEF is so close to #FFF that could very well have been it too.
Thanks for going to that trouble, deathshadow60, and I do appreciate it, but as I said originally, this is only a “holding page”. The client has a designer working on their “real” site, but because that’s taking so long, they asked me to put up a temporary page. They wanted it up immediately, if not sooner, so I didn’t stop to sort out the finer points.
No, that’s because of the massive logo, which the client wanted in there.
As I mentioned in my original post, the background colour is fine in Chrome on the same system. Also, webdev1958 is reporting the same problem.
So I really just wanted to sort out what it is about that declaration that’s causing it to fail in IE9 and FF7 on Vista, so I can avoid the same pitfall on other sites. As both browsers are OK on Windows 7 and I don’t have access to Vista, I can’t do any testing of the issue myself.
Which you had as a floated IMG tag, so wrap floats instead of using min-height – or as I did, put it where it belongs in the CSS, and set the font fixed with enough height to make room for it. EM font size + EM padding + px image == /FAIL/ cross browser; it will break somewhere and min-height is NOT the answer. It is still likely why the layout was busted here (the not declaring line-height on font-size change) since… well… lemme pull up an old example from my font size comparison page.
<div id="linkHeights">
<div class="test1">
This renders 40px tall with line-height inheriting from 200%
</div>
<div class="test2">
This renders 28px tall with line-height set manually as 200%
</div>
</div>
Think on that… your 250% font-size was still getting the line-height of the parent element… so on a 96pdi machine your code was returning a 40px tall font with a 22px line-height on the h1… and a 32px font-size on h2 with a 22px line-height… Large fonts that’s 50px/28px and 40/28px respectively… so broken layout here - though most browsers wont let an inherited line-height be smaller than the font-size… some do. It’s why I always say “change the font-size, redeclare the line-height!”
As to the background issue, Vista in a VM yours lacks background, mine works fine – so it could be the massive and redundant font stack, it could be a character encoding issue (which is why I NEVER declare @charset in my CSS and stick to the specification restriction of ASCII7) and why I never type ‘fancy space’ characters, which yours was chock full of… tabs or spaces, choose ONE (preferably tabs :D) , and don’t use non-standard/utf space characters (like nspace, emspace, etc) – again, valid CSS shouldn’t have anything more than the bottom 7 bits (128 characters) of ASCII in it in the first place! If you can’t type it on a US 101 keyboard without reaching for the alt key, it shouldn’t be in the CSS.
Making me wonder if your editor is actually at fault for the problem. Oddball characters and character encodings can have really weird issues in pretty much every browser – though IE and Safari are the worst in that regard. (A common cause of pages that work in Chrome but break in Saffy)
It’s why when I viewed the CSS here the indenting seemed willy-nilly all over the place, and when I cut/paste the CSS into notepad2 from Opera, I got a bunch of unrecognized character symbols – Well there’s your problem…
Hm, I can’t see anything weird (other than stuff ds mentioned) on the page either. Here on Linux everything shows just dandy. Though I thought lilac was kind of a pinkish purplish colour? #eef is kinda grey.
I don’t normally use 3-digit hex values, so I wonder if that’s the problem. Would you mind testing again using #EEEEFF, and, for good measure, rgb(238 238 255) to see if the objection is to my notation or my choice of colour? Thanks.
Hex colours are totally fine with all modern browsers. Nutscrape or IE4 or someone had issues with the shortcut versions (#eef) but, whatever.
Usually when the body colour isn’t showing up, the body itself is stopping (and in this case, also the html element). It makes no sense that IE on one OS would do that and on another OS not, esp when all other browsers are fine.
Makes me suspect some setting the client has that IE happens to show when Chrome doesn’t. Chrome for example still doesn’t let users set their basis default font-size. Most other browsers let you.
Unfortunately what I think you need to do is get ahold of the client’s machine and start looking at the page with a debugger like IE dev toolbar. And check the browser’s settings, and/or the OS settings. Likely in the debugger, even if you can’t see the footer, you can probably find it. You can then also check if the body or html elements are ending sooner than the rest of the content.
That webdev only sees issue with the background looking white, I could possibly attribute to #eef looking an awful lot like #fff on many monitors anyway. Webdev sees the footer fine and if the background is changed to some more obvious colour, that’s fine too.
To make sure, you could temporarily set the background to something much more obviously not-white on the current page and have webdev take a look again. If the background colour shows everywhere it’s supposed to, that’s a good thing and points more towards some strange thing going on specifically with the client’s machine.
I can’t find that on my site - how are you detecting that?
I never did, until about 18 months ago when I took a W3C course and learned it was considered best practice to include it. I have therefore done so ever since.
I agree and I apologise. I think I must have been interrupted in the middle of that and forgotten where I was when I returned. I promise I’ve never used that font-family anywhere else. (:
Thank you. I was entirely unaware that could cause problems. I’ll adopt your method for future use.
That was also part of the W3C best practice…
In this case, I have to disagree with you. Your example uses line-height: 200%, which does indeed behave as you’ve described. However, I used line-height: 1.4, not line-height 140%. To quote from the [book I’ve just been re-reading:
Although any unit can be used, the line-height property is unique in that it can be specified without a unit. When this is done, the value is taken as a scaling factor based on the font size of the element (whether inherited or stated explicitly).
The same point is made in the [URL=“http://reference.sitepoint.com/css/line-height#compatibilitysection”]SitePoint reference](http://www.apress.com/9781590597323). It doesn’t seem logical to me to scale a number but not a percentage; nevertheless, that’s the way it works and my 2em <h1> therefore has 1.4 x 2 line-height, not 1.4 x 1.
Now that bit does concern me. Yes, I put extra whitespace in sometimes (quite often) when I’m working, because it helps me read it. But I only use tabs/spaces (OK, I’ll stick to tabs in future) and wouldn’t know an nspace or emspace if I fell over one. And if they’re non-standard, why isn’t the validator picking them up?
May very well be. I’ll try that and see what I get. Somehow, I don’t think it will be the editor (Bluefish) - unless I’ve somehow done something really daft with it…
Edit: OK, I’ve visited the site using Opera on Windows7, viewed the CSS file and copied/pasted it into Notepad 2. No unrecognised character symbols. When I try “View whitespace”, all it shows me are arrows, which I take to be tabs, and dots for spaces. I can’t see any strange characters anywhere. Am I looking in the wrong place?
Here too, and thank you for checking.
True, but a more pinky grey than SitePoint grey. (Off-Topic: When I asked the client if they had any colour-scheme in mind, they replied that the colours are in the logo. To me, that just looks grey-scale, so I was trying to find a warm but subtle colour that would blend with - grey. )
My thoughts entirely, and it upsets the Vulcan side of my nature.
Good suggestion - I think I may end up having to do that. Should be fun; I seldom use Windows, and never owned/used a Vista box, so checking OS settings may be …interesting. Just as well I enjoy a challenge.
I never did, until about 18 months ago when I took a W3C course and learned it was considered best practice to include it.
Considering no user agent bothers to read it, I’d dump it. As Crusty says, CSS doesn’t allow characters outside US-ASCII anyway (the basic US chars) so whether you had utf-8 set on that or not, means nothing: the other possible charsets would still correctly interpret those characters (nothing wrong with having your server send a utf-8 header though… especially since that would always override any @charset anything just as the server overrides the <meta> tags).
I dunno if they’re still using ASCII-7 anymore…
The W3C Doctypes page was until quite recently still suggesting the <?xml?> crap before an XHTML doctype. XML only requires that if you’re using UTF-16 or 32 anyway, but since nobody is using utf-16 (except some particular versions of hindi, and still not on the web) and nobody’s writing real XHTML, all the <?xml?> prologue thing does is throw IE6 unnecessarily into Quirks Mode.
Looks like they finally removed it. Good riddance.
Thank you. I was entirely unaware that [comments] could cause problems.
Specifically, it was an IE6/7 duplicate content bug, caused by IE’s strange interpretation of comments (similar to how IE7 finally understands :first-child, but if a comment is the first child it’ll try to apply to the comment!). If a comment was sammiched between two floats you could get some interesting results. So, if you need to place a comment and are worried about that, you could just make sure teh comment is inside one of the floats instead of in between them. There’s a similar bug regarding IE6 and two absolutely positioned boxes where one box would vanish entirely.
That was also part of the W3C best practice…
It’s good to have the server send out the charset headers. Anything you type as @charset or <meta> tags are suggestions to the browsers at best. If the documents aren’t saved the way the server claims tho everyone dies in a fire. Except, usually, the basic ASCII stuff.
Although any unit can be used, the line-height property is unique in that it can be specified without a unit. When this is done, the value is taken as a scaling factor based on the font size of the element (whether inherited or stated explicitly).
However, if someone is 2em tall, that’s that element’s 100%. So 1.4 line-height should be 140%… of the 2em. I didn’t test in an example so I could be wrong but I believe if you had 1.4 and then changed to 140% you’d see no difference.
Yes, I put extra whitespace in sometimes (quite often) when I’m working, because it helps me read it.
Whitespace is good.
But I only use tabs/spaces (OK, I’ll stick to tabs in future) and wouldn’t know an nspace or emspace if I fell over one. And if they’re non-standard, why isn’t the validator picking them up?
Validator doesn’t care about whitespace. Only devs do.
So far as I know, to get en and em spaces you have to expressly type them in as HTML character entities. I can’t see how you could accidentally have any.
Re tabs: you could set your tabs to “x spaces” if you want. People argue too much about tabs versus spaces. I set my tab to 2 spaces. So when I’m indenting, I just hit tab. So for indenting 8 spaces I hit tab 4 times… someone with tab set to 8 spaces will probably see ruinously indented text. Oh well.
Edit: OK, I’ve visited the site using Opera on Windows7, viewed the CSS file and copied/pasted it into Notepad 2. No unrecognised character symbols. When I try “View whitespace”, all it shows me are arrows, which I take to be tabs, and dots for spaces. I can’t see any strange characters anywhere. Am I looking in the wrong place?
I dunno, I’d never copy something some browser spit out and paste to see what’s there… too much stuff’s been interpreted along the way. If I am looking for strange characters I prefer to view the actual file. Especially on some retarded-with-characters system like Windows (recently I opened a template file someone had made… apparently they intended to have multiple new lines, but what I got was one line only, with lots of ^M characters everywhere. Yeah, ^M is how Unix sees Windows newlines (usually there are two characters,
and \r I think, one of which Unix will interpret as a newline and the other as ^M, but here it seems only one character was ever added, so no newlines for me… bleh).
No, neither do I - and I can’t find any anywhere to even take a guess at how they might have got there.
I wouldn’t normally do that, either, but I’d already tried everything I could think of to find these invalid characters I apparently have in that file. I thought using the same method ds60 used would finally track them down, but no - same results I get by every other method. But if those characters aren’t there - why is ds60 seeing them?
Seems the problem was not with my site after all. IE9 on the client’s computer will not render background colours or images on any element on any site. Weird.
The developer tools showed the CSS background declarations, but they were not displayed by the browser. I couldn’t find any setting that could be causing this, although that might well be because I was looking in the wrong place; Windows is not my usual OS.
The missing last line seems to have been a one-off glitch, as it was displaying OK today.
My thanks and apologies to those who have spent time trying to help me solve the wrong problem , but your efforts have not been wasted as I’ve learned a good deal from this thread. Thanks again all.
specifically in the comments people mention how you can get the browser to reflect your OS settings. People can also set a “high contrast” setting and I know that for instance icons and background images vanish in that mode.
If the client doesn’t know how that happened, then it’s no setting they’ve deliberately set, but it sounds plausible that indeed it’s one of those types of accessibility settings that are involved.
Re the line-height: ah, you’re setting on the body and seeing a difference. I was assuming everything set on the header:
h1 {
font-size: 2em;
line-height: 1.4;
}
versus
h1 {
font-size: 2em;
line-height: 140%;
}
You probably noticed that while the headers looked different as you changed line-height units in the body, your p’s didn’t seem to change at all (assuming you’ve set no font-sizes on those p’s but that they’re just inheriting from the body).
If you’ve got font-size and line-height set on the body element, and then you want to set a specific font-size on another element (or if the browser has a default one, as they do for heading tags), then it’s recommended that you set an explicit line-height on that element too.
Cause I’ve run into that exact same issue; I started setting line-height on the body (good) but in % (because I set font in % and liked them to be the same unit I guess) and then saw I needed a really high line-height to get headers working. If I set headers to be 1em (like everything else on the page was, so overriding the browser defaults) there was no problem with just keeping the body’s line-height, but indeed I usually need my headers larger, so always gave them their own line-height.
So the general rule of thumb: if you’re setting a specific font-size (or if a default stylesheet is doing this), set an explicit line-height for that element.
yeah, I’m guilty of still not doing this all the time, but it means some browser’s going to puke on those elements some day.
I’m even more surprised to find the problem occurs on Firefox7, too. I tested that (live) in Linux and Windows7 and it’s fine in both.
– 
(Off-Topic: When I asked the client if they had any colour-scheme in mind, they replied that the colours are in the logo. To me, that just looks grey-scale, so I was trying to find a warm but subtle colour that would blend with - grey. 
)
, but your efforts have not been wasted as I’ve learned a good deal from this thread.