tanfa - archived muse
:: View Archives List :: Home :: Skip to Have a Muse
Archive dated February 2, 2006
EasyClearing, the Aslett/PIE way is NOT broken in IE7!
On reading some of the comments on the IE Blog and a couple of other places, that the method of clearing floats without stuctural markup was no longer usable, I decided to run a check.
To my surprise I discovered that the method is still working, which will no doubt be a relief to some. but WHY?
Note: If you're just happy your hack is still working then you don't to need to read any further :), but if your hack isn't working then read more to find the missing ingredient..
Is it that hasLayout thing again?
... I'm glad you asked, and yes it is..
If you ignore the clever bit, the .clearfix:after {..}, for compliant browsers, IE does anyway, and only concentrate on the IE stuff (both Mac and Windows) I will try to explain why.
On Big John's demo page you will see this code:
.clearfix {display: inline-table;}
/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End hide from IE-mac */
However if you look at the source code, you will see it has been updated to include Alex Robinson's later discovery. This change is important to this little story and the demo code being used by PIE (at time of writing) is actually this:
.clearfix {
display: inline-block;
}
/* Holly Hack Targets IE Win only \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End Holly Hack */
note that the inline-table; has been changed to inline-block;
What's so important about that?
As Alex Robinson already noted on his page,
As a benign side-effect IE 6 now makes the entire
<a>element hoverable, something which is also only usually achievable when it has an explicit width set.
That's the clue, normally the only thing that would encourage IE6 make an entire block hoverable would be to set hasLayout to true on that block, which is why it worked when a width was set, width is one of the properties that trigger hasLayout.
In IE6, the * HTML hack was taking care of a setting hasLayout to true, by using the Holly Hack to force feed a small height, it wasn't the height itself that was important (in most cases that height would have nothing to inherit from anyway?) it was mainly just the method of triggering hasLayout.
So now if IE7 is disregarding the * HTML hack, what is it in the above code that is still triggering hasLayout?
There seems to be nothing in the above code that would set hasLayout to true according to Microsoft's list of properties that cause an element to have Layout
| CSS property | Value |
|---|---|
| display | inline-block |
| height | any value |
| float | left or right |
| position | absolute |
| width | any value |
| writing-mode | tb-rl |
| zoom | any value |
Sure there's a display: inline-block; in there but that is being overruled in the Cascade for all browsers except IE/Mac by the display: block; rule inside the Mac hiding hack isn't it?
A while back I discovered (free registration may be required), quite by accident a way to force IE to honour display:inline-block on block level elements, (previously thought to only do so on inline elements).. and it was this that led me to believe that haslayout was still somehow being triggered by inline-block, even if it was subsequently overuled by the correct display property later in the cascade
This is exactly what's happening, and I have a built proof of concept demo for the TripSwitch hasLayout trigger (view with IE to enable test to show the results). Be aware that like everything IE there is a small quirk, IE needs the two rules to be separate, to enable it to reset that actual display status but not the hasLayout status, seemingly.
Conclusion..
So this is why the Aslett method is still working, both of the ingredients for the "trip switch" are present ~ in PIE's demo anyway. And Tony's method of containing floats may still only work for you if you are serendipitously using the later IE/Mac "fix" of display:inline-block; rule and subsequently overriding it with the display:block; rule.
I was asked if that meant the Holly Hack wasn't required any more, and the answer is it's up to you.. IE5.0 does not have support for inline-block, it's only good for IE5.5+. So if it is important that you still support IE5 (Mac and/or Windows) then I would suggest leaving it place, though write yourself some notes in the CSS that the Mac fix is no longer just a Mac fix, it's likely an IE7 fix too. Obviously if you no longer need to/or never had to support IE/Mac, you still need the two rules but you would not need to hide the second one.
Feedback on and experiences with this is welcome. Even though this IE7 is still only beta, we know that the parse error hacks are no longer reliable
added: since writing this I have found this inline-block and hasLayout demonstration by Bruno Fassino which backs up this layout "trip" behaviour.
re: zoom, there is nothing at all wrong with using that, but it is still only supported for >IE5 like this inline-block thing AND in general I've found that people who are this deep into CSS and code do not like to use a microsoft proprietary property in their main CSS 
but yea.. zoom: 1; is the easiest, least "hackiest" way to trigger layout.
Posted By Claire on 05/02/2006 at 0:34am «þ»
Today I was sharing anecdotes on the sometimes unexpected behavior in IE7b2. Bruno pointed me to your musing. Isn't it ironic we now use non-breaking hacks in IE7b2 to understand IE6 better? It's an on-the-fly application of layout to elements via inline-block overwritten by block. But this elegance has it's price: The authors often won't see the silent hack construction that is cluttered over two rulesets. Like authors who don't have access to IEMac often interpret /*\*/ as a typo and 'improve' the stylesheet. I think zoom has the advantage of clearly stating: attention, here comes a hack. It does not validate, so CondComs are required. 'Star html 1% is dead, long live the zoom 1' ? The star html hack is still useful in single conditionals like [if IE] to exclude IE7. For single properties, one can use the underscore hack inside CC's, though. If only they had implemented layout:none, as having this 'internal data structure' is more problematic in all IE versions than not having layout ...
Hi Ingo, thanks for dropping by!
it sure is ironic , & layout:none; would be good.
making a hack stand out is the right idea especially when just learning, and writing notes in the CSS! I recommend using Conditionals for all seperation, though I'm guilty of not using them here (I use zoom - and my stylesheet needs a spring clean!) but when doing outside work I use them for clarity..
ackk this will go on for years I still see CSS files full of the "voice family" hack but without any changes to widths, obviously by authors who don't know what it does/did and are too scared to remove it, I dare say the same will happen with all of this "layout" stuff into the future
Posted By Claire on 13/02/2006 at 11:40am «þ»
Although I can't track it down just at the moment, I remember reading somewhere (either the MSDN library or the IEBlog, probably) that once hasLayout was set to true, it could not be reset. So if for example one used javascript to set contentEditable to true on an element, thus triggering hasLayout to become true, and then used script to reset contentEditable to false, hasLayout would remain true even though the triggering influence no longer applied.
Perhaps what you're seeing is an aspect of this: maybe applying the "display:inline-block;" triggers hasLayout and the subsequent "display:block;", while setting the correct display value, cannot unset the hasLayout flag.
Just a theory, but it seems to fit in with your observations, as well as suggesting a few things about the spaghettiform internals of IE.
Posted By NickFitzsimons on 22/03/2006 at 14:12pm «þ»
Sorry but muses are now closed on this article
previous :: top of page :: next
You know your stuff :)
But what's wrong with just using zoom:1; to set hasLayout?
Posted By JamesAkaXakA on 04/02/2006 at 22:20pm «þ»