Observations on the IE Guillotine bug:
Having just spent some time wrestling with a prime example of this bug I have arrived at certain somewhat confusing aspects about it, when read in conjunction with the P.I.E explanation, and which caused me to overlook the eventual fix arrived at for dealing with this instance of the bug - I acknowledge that it is a far from completely documented bug and that the P.I.E article probably is not intended to cover every possible trigger that there may be, but just the more common ones.
In the P.I.E article the conditions for producing the bug are noted as:
1. A container element.
2. A float element inside the container that is not "cleared".
3. Links inside the container in non-floated content after the float.
4. a:hover style rules for those links that change certain properties.
and obviously the offending browser that nightmares are made of.
The triggers we know are any properties on the 'hover' of links that change the background color or images, the borders, padding, text styles.
All well and good, so given a container that has a specified height to trigger the auto enclosing behavior of IE and that holds a floated element which also contains links following after the floated element which are themselves not contained in any further div or p style element of their own is going to trigger the effect.
So the problem lies with giving the container the auto clearing behavior of IE by using the height:1%; trick, as given no height IE will correctly let a float break through the container and no problems will occur.
The fixes discussed are therefor to:
Give no height to the container.
Ensure that the non floated elements following after the float are
wrapped in a div or p and the Holly hack( height:1%) is applied to this new wrapper element.
Use the old method of a clearing div inserted after all elements before the container is closed, although this is takes us back to adding non semantic markup and is not the preferred solution.
This is one instance where the use of the ':after' clearing method has to be helped along and clearly the extra wrapper with the height fix is the preferred way.
Now to my mind the operative words here are "content, non floated, that Followsafter the float".
I was finding that a given a container holding in descending order a header, a navbar, and a further strapline div followed by a floated content div that the bug managed to rear it's ugly head.
The container was given the standard :after clearing fix along with the IE 1% height fix within this was a header div given height and position relative this contained an h1
element with a link attribute and a background hover this div was followed by a navbar also given height and position and a strapline div containing a floated element but cleared with the clearing rule, then followed by the floated contents div.
My confusion is that the above should technically not trigger the bug all the elements come before the floated contents, all elements are given height and position, all elements are contained within their own divs and the only div that holds another float i.e the strapline div is cleared.
So why does hovering a link in the header div or navbar cause the effect to happen ?
have I missed some salient point here or is this just a different way of the bug manifesting itself ?
The fix was to enclose all three of those divs in a further wrapper div given a height 1% for IE, but still leaves me puzzled.
Lastly I refer to this as a guillotine bug yet in my case it did not present itself as cutting of the floated element but rather it just switched off the clearing rules allowing the float to break through and down the page out of all the containing elements, which seems to be the opposite from that described and demonstrated in the P.I.E article where the float is actually chopped off, truncated if you will.
So is this perhaps not actually the Guillotine bug but a similar and closely related cousin, or am I just very tired
Hugo.
Wrestling with the Guillotine bug.
You must be tired, you missed the "l" in .html, http://positioniseverything.net/explorer/guillotine.html
Wrestling with the Guillotine bug.
I have come across a different effect which occurs under similar circumstances.
There is floated content on the page, basic three column layout, left and right columns floated. In the central (unfloated) column there is also floated, but not cleared content.
IE renders the page as expected. When you hover over a link in the center column, beyond the floated content, IE decides to apply a clear to the center column and locate it below the lower of the two floated sidebars.
Hovering over a link (with :hover changes) in one of the sidebars brings the center column back to its original position.
Wrestling with the Guillotine bug.
Interesting, need to ponder that one a little, sounds slightly more like the classic guillotine as hovering the link resets things, yet it's not exactly as classically described, where with the effect I was getting hovering the links again didn't reset things.
I'm wondering whether these are somewhat undocumented variants on guillotine bugs.
If I had the energy I would try and test case them for interests sake.
Hugo.
Wrestling with the Guillotine bug.
Wrestling with the Guillotine bug.
Thanks for the link friday, I was aware that, certainly MS will address certain deficiencies in the new release and the general bugs to do with floats are a pretty major problem, lets just hope that their solution fixes the general nature of the problem rather than a specific test case as demonstrated by P.I.E which they allude to.
However despite the upbeat nature of that blog, lets not forget that regardless of how wonderful IE7 turns out to be, people will be continuing to use IE6 for a very long time so we will still have to support it's deficiencies. It sort of negates the joy of a new and improved version really, if only MS, given there love for detailing how people use their products, would invest some time or find a way of forcing every IE6 user to upgrade or else
Hugo.
Wrestling with the Guillotine bug.
I solved my problem, by placing an internal wrapper div, floating it and setting the width to 99%. The 99% seemed to be important. Although prior to the change the center column had no specified width, at exremely wide browser window widths the problem went away. Just floating the internal wrapper with width:100% (margin/border/padding all resulted in IE pushing the div down below both sidebar, permanently.
I wonder now if a -ve margin of 3px somewhere would have helped.