A Disturbing IE 7 bug

Here's a web page that looks good in all major browsers except 1. And in this case it's not the browser, it's the O/S.

As you can see, it's fine in IE 7-XP but broken in IE 7-Vista. It's also fine in IE6, FF and Safari on PC and fine in Safari and FF on Mac. The problem is quite obvious, a large positioning error.

In addition to the positioning error, IE7-Vista is the only one that reports a security problem on this page. All other browser-OS combinations report it as fully secure. It passed all security tests with the payment gateway company.

To make matters even worse, some IE7-Vista systems report no problems at all! Positioning is fine, security is fine, too!

The only thing I can think of at this stage is to recode it using tables, get rid of the divs. No idea what to do about the security problem.

In a larger context, is Vista really that horrible of a monster for us coders? Is it going to be impossible to deal with? Is it an "irrational" system whose behavior cannot be predicted?

Any comments are welcome.

Problem Page

 

Well, Vista Ultimate/ IE7 on my computer doesn't give any errors, though there are a few css errors; font-style:'none' should be 'normal' if it needs to be included and webdeveloper for FF says .basket2 is a bad selector that gets ignored, though i haven't actually looked into why 'cause i'm short on time.

 

hi,

bleeding edge or cutting edge releases never work for worth a cr_p. you could spend weeks trying to fix a problem. only to have someone else need the fix more than you and come out with a week after you did. one browser??? is anyone even using vista??? my hardware will not boot this OS until 2009 by reasons of sanity.

kevin

 

Hi Qube,

I'll tell you something I've noticed over the last few months. There's more than one way to code a page, and sometimes for whatever reason, one browser acts unpredictible with a way of coding.

I would have written your page a bit differently (had I been given a PSD or something and someone said, build this page) and I'm also a little surprised that IE6 is cool as that huge gap above the doctype usually gives it the sh*ts.

I don't have Vista but I'll tell ya, I have this Acer laptop running Ubuntu 6, and no matter what browser I check in, my default font size seems to be one good step up from everyone else. I had to reduce my fonts size several times to get the menu in place for this particular page, but I was re-doing another page which looked like it had a broken menu... but it turned out that on all browsers on a Windows or Mac looked fine. I was always one font size bigger. Font size is one area where differences in either available fonts or OS size defaults changes a page in an NON-Browser-Dependent way.

While building a menu, I used Verdana (which I don't have) and followed with Arial. My menu looked completely different from one OS to the next because Verdana's default size is larger than its Arial counterpart... similarly someone with only Times/Times New Roman will see a smaller font on a page which offers Georgia as the first font of choice.


By the way, can you show a screenshot of the f*k'd up Vista version? I'm curious what/where the big positioning error is. It likely has a nice explanation (though I never could figure out why that church page posted here had a nice dropshadow in all browsers but IE7.... that was a weird one).

 

I solved the positioning error by brute force. I moved the element 4 pixels for all agents.

This page has gone through repeated revisions so it's not efficiently coded. The designer continues making tweaks. I don't optimize the code unless the client pays for it. They're always given the option. When I do optimize I go all the way and even strip out all extra spaces and endlines. I doubt they'll want to optimize this one because it's not a problem for them. Pretty small stylesheet (825 lines), so not much gain to be had.

The fonts in the menu are specified in the containers and then inherited for the individual link elements. font-size is specified in pixels, not in ems. There are 4 menus on that page, One uses arial, helvetica, sans-serif and the other 3 use times, serif.

The security problem is another matter. I've had a number of folks look at it with IE7 Vista and so far I'll estimate the problem shows up in about 1 in 15 Vista users. No other agent has a problem.

Here's a screener, what are you seeing on the Acer?

 

I'm assuming that most people with XP haven't bothered upgrading to IE7, and that vista users may or may not have updated their version of IE7, hence the problem. not sure how many times i've had to say this, but since installing vista ultimate on my computer, i've had *zero* problems with it. none. no crashes, nothing. in other words, a billion times better than the initial release of 98 and xp.

sadly, i'm not as well versed in tuning for IE as for FF, so i can't really help you resolve the problem. best of luck anyway.

 

Even setting your font in px apparently doesn't stop one font family from taking liberties with it. Actually, that's what font originally meant-- it was Verdana 8pt, another was Verdana 12pt, another was Verdana 16pt...
*Edit I see what you mean... you mean you're not getting the em-inheritance thing where everyone assumes their parent is 100%... ok

Anyway, here's a link in case the upload thing doesn't work:
http://stommepoes.nl/Tests/bettyjaneonubuntu.gif

Which shows how the site first looks when I visit, how it looks hovering on the same thing you did, and then after 3 text-size reductions (most sites I visit only need one). I erased the red comments in Gimp if you're wondering where that went. Also, my resolution is 1400 by 975

I know it isn't easy to do with every design, but when I'm building a site, I keep doing text increases. I know that somebody, somewhere is gonna do it anyway-- I might as well see how badly (or well) my site ends up when they do-- and I try to build the site so that the menu has room to breathe. The body text usually has no problem with enlargements, but menus show it the quickest.

I'll also say the biggest browser problem here is FF. IE only lets text-enlargement in certain stages and not with px, IE7 and Opera use zoom, and apparently Safari enlarges text more carefully than FF. FF just lets everything go wild.

Oh, I'm getting the https but I have NoScript running so I dunno if I was supposed to get the login or not; I get the red text "We're under construction blah blah..." instead.

Damn, the uploader here changes my gif to a jpg (prolly because the filesize was ginormous) so you might want to look at the one on my server for more clarity instead.

 

Which Stomme's screencap is almost identical to Opera's rendering of this as well.

20 validation errors, a host of unnecessary/unneeded wrapping div's, presentational markup, lists not marked up as lists, spans for no fathomable reason, an IE6 conditional on a layout that has NO reason to need such a thing... and some formatting wouldn't hurt. 3.5k of markup and you don't even have 400k of actual content yet. (I'd say you've got about 1k of fat to trim)

I have time later (after I go to bed - this staying up 20 hours stuff is catching up with me) I'll toss together a quick rewrite to show you 'a more proper' approach.

 

I'm a little surprised that font-size doesn't work in some circumstances on this page. That's the first time I've encountered that. Font-family doesn't seem to be inheriting correctly, either. I guess I'll have to code a full font statement for each and every container. More code bloat.

The validator errors are about variables in the dynamic internal URLs. These are not parsed by the web browsers and can be safely ignored.

The divitis was explained earlier and is impossible to avoid on jobs like this. Unfortunately the client hasn't approved the budget to re-write the code efficiently. Most clients never do. When working with graphic designers it seems like you need to put each and every letter and element in a separate contaner to accomodate all the revisions you'll be making.

The IE6 conditionals are critical to this centered floated layout. It is used in global elements on about 40 pages of dynamic content with variable numbers of columns. I don't think IE6 gets any of the layout variations right without the hack. Of course the dropdown menu would not work in IE6 without all the conditionals, either. Some of the extra divs aren't really extras when viewed site-wide, they are used to facilitate all the page variations while keeping the global content in global data fields for single-point editing.

You need to realize that you're not seeing the original code. There are some weird issues related to the Empressa engine. Adding a class inside a link won't work in the category tree (it works fine everywhere else) so the links in this container must either be spanned or divved due to an obscure bug in the script parser. Another problem is some dynamic content must be invoked in a certain sequence to get the CSS to apply properly and this requires an occasional coding oddity or absurdity, too.

Here's an example of placing the CSS class in a surrounding container in the category tree and defining the class names with a dynamic variable. You can easily change the li containers to either a span or a div and this is done quite commonly.

<mvt:if expr="l.settings:cattree:stack EQ 0">
  <mvt:item name="category_tree" param="cattree_header" />
</mvt:if>
<mvt:if expr="l.settings:nextcount GT 0">
  <ul class="cattree catlevel&mvt:cattree:stack;">
    <mvt:item name="category_tree" param="nextlevel">
      <mvt:foreach iterator="cattree_category" array="categories">
        <mvt:if expr="l.settings:cattree_category:code EQ g.Category_code">
          <mvt:if expr="NOT l.settings:cattree_category:image">
            <li class="cattree thiscat">&mvt:cattree_category:name;</li>
          <mvt:else>
            <li class="cattree thiscat"><img src="&mvte:cattree_category:image;" alt="&mvte:cattree_category:name;"></li>
          </mvt:if>
        <mvt:else>
          <mvt:if expr="l.settings:cattree_category:image">
            <li class="cattree"><a href="&mvt:global:sessionurl;Screen=CTGY&Store_Code=&mvta:store:code;&Category_Code=&mvta:cattree_category:code;"><img src="&mvte:cattree_category:image;" alt="&mvte:cattree_category:name;"></a></li>
          <mvt:else>
            <li class="cattree"><a href="&mvt:global:sessionurl;Screen=CTGY&Store_Code=&mvta:store:code;&Category_Code=&mvta:cattree_category:code;">&mvt:cattree_category:name;</a></li>
          </mvt:if>
        </mvt:if>
        <mvt:if expr="l.settings:cattree_category:id EQ l.settings:cattreenext">
          <mvt:item name="category_tree"/>
        </mvt:if>
      </mvt:foreach>
    </mvt:item>
  </ul>
</mvt:if>
<mvt:if expr="l.settings:cattree:stack EQ 0">
  <mvt:item name="category_tree" param="cattree_footer" />
</mvt:if>

Code (markup):

 

and here it is - a quick rewrite of that one page:

http://battletech.hopto.org/for_others/qube99/template.html

as with all my examples the directory:

http://battletech.hopto.org/for_others/qube99

is unlocked so you can get at the gooey bits. I remastered the page images, chopping it down to five files totalling under 15k.

In the HTML, the breakdown is as follows.

Fixed width layout - so the whole thing goes into a #container DIV

Site logo I make the H1, I styled it so images off a colored box with similar appearance is in there, while images on a 'image replacement' places the logo over it. Unlike yours which made the top of the page a single huge file, I just made a palettized transparancy of your logo (saving 55k) - the brown top 88px is instead done as the background of the H1...

next you have a menus at the top. Menus are lists, so we toss in a styled list. Since all of the lists are going to have dividers, we'll toss in a 'last' class to say 'don't put a border after this one'. - #topMenu will get a current class to indicate the 'current' page, implement that as appropriate in your back-end. #mainMenu has the nested submenu, that's just a flat UL inside an LI.

SINCE your links are pointing at the same server the page should be hosted from, there is NO reason to include the full URL - the only reason to do so would be the https links (as I did)

The content area I double wrapped so that in the future if desired the page could be switched to a semi-fluid or fully fluid layout. Because that paragraph of construction text does not match what a 'normal' para would be, slap a class on it.

I put in a sidebar div and implemented it as functional - I'm assuming that's what the faux-column appearance you had in the background was for.

The footer - I did away with the images here outright except for one small 'bullet' next to the 'Savor the Moments' text. Took me a bit to recognize 'georgia' - and I tried to match as close as possible. YES, it will not appear 100% identical to people who don't have M$ fonts installed - Honestly, it's not worth the hassle to make that an image. The empty span is there to be turned into the bullet (since that's presentational, not content) - normally I'd slap it on the div as a background, but due to positioning problems and the load of CSS that would be involved since it's flush right - it's just simpler this way.

Which covers the HTML - the CSS goes as follows:

Universal reset - just to keep margins and padding out of our hair.

paragraph - I format mine with padding-bottom instead of margin. Margin collapse can bite you in the ass on some layouts, so just pad the top of your containers and you're fine just padding bottom of your para's.

strip the image borders - rarely do I want them, so this is part of my reset.

body - top/bottom padding to space out #container, text-align to center #container in IE 5.x, background and default font size. I set a %/em font size for the content so resizing is not an issue - later on we'll be setting some stuff in px inside px width containers - the reason for this is simple - we don't want those handful of elements to be broken at default zoom on large font/120dpi machines. Those elements will still break on content resize in FF, but frankly anyone who actually CARES about content resizing probably isn't using FF in the first damned place since it still handles that like the sweetly retarded crack addict cousin of Netscape 3 that it is. (but I'm in the minority - I believe IE6's behavior on resizing px is the CORRECT one unless you are going to resize ALL px elements - like Opera and IE7 do)

* html body - the * html uses a bug in IE6/earlier to isolate just those browsers... I'm loading a behavior file there which implements :hover and :focus on all elements letting our menu code be MUCH simpler and not have to have all those stupid 'lt IE7' conditionals in the html.

#container - set the width, reset text-align to normal, set the margin to center it in standards compliant browsers, colors, faux column. The Faux column image I stripped to only be the 172px wide area that's a different color - shrinking the filesize since the reset of that was only white. Set the background flush left and only to repeat-y, and you don't have to waste bytes on the rest of the image.

h1 - height and color make the brown top bar area. position:relative lets us absolute position our other elements inside it.

h1 span - this is our 'normal' header content which shows when images are disabled. A little absolute positioning and careful measuring lets it be smaller than the image. The font set here is for the bigger text.

h1 em - the smaller subtext in the logo gets replicated here, even with the top and bottom borders on it.

h1 b - our actual image replacement.

#topmenu - turn off the list, set the height... fairly straightforward. Float right lets us float:left the anchors inside it while keeping the menu flush right. The only thing really needing explanation is the position:relative and negative top margin. This slides the menu up over our h1... likewise I pad the bottom so that our #mainMenu ends up in the right spot since it too might slide up.

#topmenu li - setting this to display:inline and manipulating the anchor instead dodges some IE7 layout issues.

#topmenu a - floating these sets them to display:block, some simple padding, fonts and colors, and the border as a divider. Nothing to write home about.

#topmenu asuedos - simple hover state.

#topmenu .current a - indicates the current page.

#topmenu .last - as mentioned under html, turn off that border.

#mainMenu, #subMenu - these share a number of properties so I declare them together. Turn off bullets, height, font size, etc. Because the logo (and it's text span) are absolute positioned, these non-positioned elements will render UNDER our logo letting those stripes across the screen be done as code instead of blowing bandwidth on an image.

#mainMenu - by itself it has a different background color, and that 1px bottom border (which only really shows over on the left side of the logo)

#subMenu - gets margin-left to push the background under the border so that little bit on the left side not rendered in your copy is preserved. To account for this and make it line up with #mainMenu's indent, it gets less right padding. I also noticed this column is 2px taller, so we just pad it a bit more.

#subMenu li, #mainMenu li - float:left, display:inline to prevent IE from going wierd on us, padding and border.

#mainMenu li - gets it's own unique properties too, the biggest of which being the position:relative to let us position the dropdowns.

#subMenu .last, #mainMenu .last - nothing new here.

#subMenu a, #mainMenu a - again, enough shared properties to make putting this together worth it. Display:block makes them expand to fit their container. The white-space setting prevents the buttons from 'breaking up', rest is just color and style.

#submenu a - gets a different color.

#mainMenu asuedo - hover state color.

#subMenu asuedo - different hover state color

#mainMenu ul - here's our dropdown menu code. Position:absolute with -1000em moves it off screen where we can't see it. CSS off it will appear on the page normal. width and top position don't really need explanation... the z-index is for 'good measure'... The one thing that does need explaining is the display:inline - IE will often miss-render or not render changes in position if you don't change the display state. Setting it to inline, then setting it to block on hover makes the hover work reliably in IE.

#mainMenu ul li - inherits properties from #mainMenu li we have to reset like padding and border, and I set the width and height for 'good measure'. (since again, IE can be a pain in the tuchas on that)

#mainmenu ul a - simple spacing and padding, the height trips haslayout which combined with the display:block makes the anchor fill the entire LI and be clickable in all browsers.

#mainMenu lisuedo ul - and here's the actual code that makes the dropdown menu appear.

#contentWrapper, #content, #sideBar - a fairly standard two column layout where #content is still 'dynamic width' - so in the future if you wanted to make it fluid you could.

Based on the 'layoutGala' method:
http://blog.html.it/layoutgala/

Which I explain in some detail here:
http://battletech.hopto.org/html_tutorials/3coldiv/template.html

.standOut - color and padding. Simple dimple.

#footer - since this is after the two columns we need to clear the floats... this causes a render bug in IE which we fix using haslayout. Text-align to put our content flush right, some padding makes it pretty, the rest is just fonts, colors and borders.

#savorTheMoments - padding, some font tweaks to replicate the image you were using.

#savorTheMoments span - an inline-block on which I hang the little bullet image. Technically you could just inline the image in the HTML, but that makes positioning a bitch. This way the positioning is dead on in all browsers. (even if the code is a bit heftier than I'd like - thanks FF)

and that's the whole thing. Tested IE 5.5, 6 & 7, Opera 9.25 and 9.5, FF 2 and Safari 3.0.4 beta - in both large font/120dpi and small font/96dpi modes. Validates XHTML strict, CSS would validate if not for the one behavior file and two -moz specific codes.

At least, that's how I'd approach the problem. Hope this helps.

 

Oop, you posted while I was typing the above.

Yeah, I should have smelled the Empressa from here. Still, you SHOULD be able to cut-down the output as appropriate unless their skinning engine is still in the dark ages.

Oh, and your validation errors are not JUST the url's. You've got unclosed spans, unclosed DIV, HTML 4 style standalones under a XHTML doctype...

Which would be clear to see if the back-end sanitized the outputs so you wouldn't have to wade through the URL rubbish to actually find the real errors.

 

That's impressive. Thanks! Some of it won't work on this site because you're information was incomplete but I get the drift.

For instance, the header is a graphic because it changes to background photos depending on the page you're on. The photos are selected by a dynamic token and are not hard coded. That makes this particular page look like it's not done correctly when it's actually done in the simplest way I can think of. When the client adds a category or a product they also add a header image associated with it. The customer doesn't write any code. I will look at your header work in more detail, see if there's something new for me here.

I really wanted to use TGA for the main logo to simplify that part of the header. IE6, you know.

The page links actually use a token system that switches the pages from secure to non-secure by inserting the base href dynamically. You're just seeing the output of a single page. All links to images and scripts are relative for security purposes. Absolute pathnames can break security so they are never used. There are also no session IDs in the real deal. In the final version there won't even be any variables in the URLs. This is done with an htaccess script that rewrites the variables and replaces them with keywords.

I really like what you did for the menus. Thanks! Some valuable things for me to learn here. I've been looking for a way to rid myself of the menu hacks. They're actually quite difficult to deal with in an iterative script. This is the reason I can't asign classes to the menu items manually. It has to be done dynamically, so some of your class selectors can't be used. Too bad, too. It'd sure make life simpler! However, I have worked out some functional methods that can been seen in the script I posted above that allow me to take full advantage of the CSS for unordered lists.

In the footer you use moz-inline-block which is new to me. Is that a Mozilla extension? I might offer the possibility of eliminating the triangle image by using the Webdings font instead.

Now for the validator errors. I think you'll find this amusing. The designer on this job likes to make code changes and he never, ever gets it right. He can't change a font color without throwing a validator error. He then calls me to fix the page that mysteriously stopped working for no reason. I then chastise him (and bill him) because I use version histories that record his changes and logins. I usually revert and redo. If it doesn't break in his browser (Firefox Mac), then he doesn't call me. It's obvious he's been "tinkering" with this page so I now get some more billable hours fixing it. I never release a job until it has totally passed validation and been checked in all popular browsers. No matter how much extra I bill this designer over this issue, he still won't get a PC, still won't use a valdator, and still won't learn HTML/CSS. C'est la vie.

 

One more observation...

We still haven't solved the IE7-Vista security error issue. This seems to occur only in certain versions of Vista and not in other versions. Basically I dumped the whole stinking mess onto the web host. I have no intention of spending time debugging Vista.

 

FireFox is a little behind the times on this one.

It's the stopgap for display: inline-block until FF3 is out (which as far as I know supports the normal CSS version). Even IE gets this one right I think... no wait, first it has to either already be inline or set to inline (or a parent set to inline) or something... but whatever. : )

 

I really like your use of the PNG image format in this circumstance. I had not thought of that and in fact have never used PNG on a web page. Its use on this design most certainly simplifies the header a lot, and would simplify the dyamic image-swapping version even more. I was aware that TGA would solve this problem but for some reason PNG never entered my mind. I rejected TGA because of IE6 non-support and went with slicing rather than layering.

I visited the PNG home page and got the technical details. One thing they don't mention - is it a fully cross-browser format? Are there any issues in this area to deal with?

 

First off, I'd not suggest EVER using TGA for anything - one simple reason. There's no ENCODING in TGA meaning you end up with absurdly oversized images. .jpg exists for a reason. You'd be better off using lossless .jpg (yes, .jpg CAN be done without loss) though with the resulting filesizes you end up with a website that is painful to load at best.

.png is the weapon of choice for the majority of what I do, though I do also use .jpg at 5-25% 'loss' where appropriate, and .gif for things like borders that can be stated under 16 colors.

There are two types of .png:

palletized: 256 colors or less total, works in all browsers, does offer 'single color' transparancy - but does not do differing opacity. A pixel can be either completely transparent, or fully opaque. This is the easiest to work with because you can use a completely crazy color you'd normally never use (like magenta) and say 'all pixels this color are transparent'.

24 bit color - this type of .png can be made alpha transparant and delivers the full visual spectrum, but there are 'problems' with it. IE6/earlier has no support for alpha transparancy - though you can in SOME cases fake it with a filter (for what I usually use .png for ... it doesn't work) - and the files end up huge. I generally try to avoid alpha transparancy .png, and only use 24 bit .png in the handful of situations where the file actually ends up smaller. (which CAN happen since 24 bit images don't need to include a pallette). Working with alpha .png is a pain in the ass because you have to deal with layers, can't merge, often making edits difficult... and generally there's nothing it brings to the table you cannot do without some simple planning ahead by pre-compositing the images.

.png does have one other 'issue' - IE for some reason applies it's own gamma correction to .png images, but not to .gif or .jpg - this means if you need to color match something declared in your HTML like a background-color or border, it's just not going to match in any version of IE... Which is when I use a .gif.

.gif is the 'old standby' for web graphics, for good reason. If an image can be stripped down to 16 colors or less, and totals under 64k in pixels .gif usually delivers the smallest filesize. .gif can only support 256 colors or less, but does offer palette transparancy AND animations that works in all browsers.

All of the above concerns are part of why I use Paint Shop Pro for 99% of my image work - it's "save as" dialog has a options button under which you can pull up an 'image optimizer' for the selected file format. At save you can choose to reduce the color depth (using two different schemes for determining proper colors), dithering amount and style, palette transparancy, and a whole host of other options.

 

In this case I'd need full alpha transparency. The logo is layered on top of various background images. The anti-aliasing of the logo prevents the use of GIf. In addition we'd like to use soft shadows.

If the background image didn't change, simple photo-compositing would work nicely and this is what we ended up doing. But now the composite images must be sliced because a second element, the faux column, changes in width as you go from page to page and part of it must be included in the composite.

The logo lies over both the masthead and the left column. Both of these elements change dynamically from page to page while the logo stays the same in the same position.

If IE alters the PNG color it would be ruinous. We absolutely must match image colors to HTML background colors. This is a featute that is required on virtually every project I do.

You might find it interesting that IE does NOT allow a foreground color and a background color to be the same in a drop-down menu made with an unordered list. The 2 colors must be different so we make the difference the smallest possible which is not visible to the human eye.

I use Photoshop which also has a very nice menu when "saving for web". The latest versions of Photoshop are not good at JPG compressions and for this I use my ancient Photoshop 5 which yields JPGs of 1/2 the size at the same quality.

So, the search for true alpha transparency continues...