IE8 haslayout = true

After numerous promises that layout was never going to be included in IE8, it’s now become clear that the feature which, should have never been exposed [even in earlier IE versions] is alive in the latest version of Internet Explorer, albeit in a far less detrimental form than earlier IE* releases.

Believing what Microsoft had promised about layout not being in IE8, I didn’t feel it necessary to carry out a simple test which checks whether an element has layout, back when Beta 1 was first released. The test happened to have been included in a recent thread on WebmasterWorld, in which a contributor suggested that layout was indeed part of IE8. Upon running this test, I was absolutely astonished by the result I was seeing; the test proves that layout is definitely included in IE8 Standards Mode.  Upon checking the scope of the known layout triggers to test the completeness of IE8’s layout implementation, I observed that all (including IE7-specific) known trigger properties invoke layout.

Now that I’d identfied layout was indeed a feature of IE8, I needed to try and ascertain the scope of layout with regards to its effect on document styling.

After discovering this unwelcome addition, the first port of call was to go back over all the bugs I’ve documented to see if by triggering layout, a workaround could be established for each of the bugs, although it subsequently turned out this wasn’t to be the case. With this in mind, I’ve concluded that layout in IE8 is either:-

1. an implementation whose effects on layout style have been purposefully suppressed. This could have resulted from IE7’s codebase being forked to provide a base for development of IE8
2. an accidental implementation whose suppressed effect on document styling can be attributed to inadvertant links with IE8’s seperate browser/document modes

More confirmation

I then came across a thread at SitePoint relating to an issue where a rounded-corner JS library (Nifty Corners Cube) was wrongly invoking the shrink-to-fit computation for block-level elements in normal flow. One contributor pointed out a confirmed fix which is reminiscent of triggering layout; height:1%. This particular issue, which is discussed in more detail, was essentially down to Javascript triggering layout in elements whose layout value was initially set to false. Adding a triggering property before the Javascript was fired, fixed the issue since these properties are recognised in IE8 as being layout triggers.

In conclusion, I haven’t yet some across any direct issues, such as CSS-only layout anomalies, that have resulted from layout in IE8, and I’d be very surprised if any such issues arose because of it. The real issue here however, is that some existing web pages are now broken as an indirect consequence of Microsoft backtracking on what it had previously promised. A perfectly plausible rationale behind the train of thought from the creator of Nifty Cube Corners, could be that since Microsoft had promised not to include layout in IE8, he saw no need to change the display:inline-block layout trigger, as this property doesn’t exhibit the change in width computation in IE6 & 7 (as the change to the shrink-to-fit computation is ignored for elements that aren’t naturally inline-level). However, since IE8 includes a full implementation of display:inline-block and implements layout, the unwanted behavior (in this context) is exhibited. Another example of Microsoft going back on their word, and another example of the negative effect that their fabrications are having on authors…

Aside: the IE8 fix for Nifty Corners Cube

I’ve seen a fair few posts now where IE8 appears to adopt the shrink-to-fit computation for block-level elements in normal flow, which the Javascript from Nifty Corners Cube is applied to. A snippet from the distributed ‘niftycube.js’ file:-

function FixIE(el){
if(el.currentStyle!=null && el.currentStyle.hasLayout!=null && el.currentStyle.hasLayout==false)
    el.style.display="inline-block";
}

display:inline-block (which uses the shrink-to-fit computation) is being used in the context of a layout trigger if hasLayout is detected as being false. Since we’ve already established that IE8 includes an implementation of layout, this trigger will be applied unless layout is set to true before this script is activated.

A more suitable trigger would be a property that doesn’t affect the initial width computation of an element. To fix this issue, instead use a more suitable trigger such as overflow:hidden