Archive for the 'bugs' Tag

  1. HasLayout in IE7

    The majority of freaky rendering behaviour in IE6 came down to whether the haslayout attribute was applied to an element. This was a speed optimisation in the rendering engine - certain behaviour was skipped when deciding how to render an element if haslayout was false to increase the efficiency of rendering a page. The result was that a valid set of CSS instructions would produce unexpected rendering behaviour in IE6 unless haslayout was true on certain elements.

    One of the hacks used to get around this was to apply height: 1px to an element (in a hacks file, served only to IE6 via conditional comments). As IE6 treated height like min-height, this would have no adverse behaviour, but would result in haslayout resolving to true for the element.

    This morning I came across my first strange rendering issue in IE7 due to haslayout being false on a container element. I think a lot of the quirks have been fixed, but just be aware that the engine can still render differently according to haslayout. The previous height:1px fix is no longer applicable, as IE7 quite correctly respects any absolute height that you specify.

    The fix in this case was to set min-height: 1px, which is another attribute that will now result in haslayout being set. In our case this had no adverse effect on the desired rendering, and therefore was a suitable fix. The actual problem was minor - 1px of extra padding on an element for no good reason.

    I think in a lot of cases setting a min-height value would be a good approach (obviously this can be abstracted to a seperate file and served with conditional comments). However this is a fairly unobtrusive fix, so could stay with the core set of instructions without polluting the water too much.

    Posted at 11:55 am on 4/10/06

    Tags: , , , ,

    Comments: None

  2. Think Before You Hack

    I’ve just been looking at a ‘broken’ site in IE7 and helping a friend diagnose what the problems are. I think people tend to assume that if a site renders happily in a bunch of different browsers, but has problems in IE7, then the browser is bad. The default response is then to add some hacks to make IE7 work correctly.

    This is a bad way to go. Each problem that I’ve looked at so far, IE7 is actually rendering correctly based on the instructions it understands. We just fixed a big layout problem where the root cause was a container div not stretching to contain it’s floated children. However this was the correct behaviour. Based on the instructions that IE7 had parsed and understood, it was rendering correctly.

    The fact that those instructions didn’t arrive at the desired layout was the problem, not the browser rendering. By taking the time to diagnose the problem and understand why it was rendering in a certain way, you can solve the root issue rather than adding a new layer of hacks on top of broken instructions.

    Generally IE7 will behave in a very logical way - it’s really worth taking the time to figure out why something looks wrong, rather than jumping straight in and hacking.

    UPDATE: the particular issue we were looking at was how to get an element to contain it’s floated children. This has been discussed already on 456 Berea Street and Malarky.

    Posted at 10:02 am on 3/10/06

    Tags: , , ,

    Comments: 2