6 replies [Last post]
Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 7 years 26 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

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 Smile

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Tags:
Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 9 years 41 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

Wrestling with the Guillotine bug.

You must be tired, you missed the "l" in .html, http://positioniseverything.net/explorer/guillotine.html

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 9 years 41 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

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.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 7 years 26 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

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.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

friday
Offline
Regular
Last seen: 14 years 12 weeks ago
Joined: 2005-02-05
Posts: 34
Points: 0

Wrestling with the Guillotine bug.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 7 years 26 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

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 Smile

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 9 years 41 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

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 Innocent resulted in IE pushing the div down below both sidebar, permanently.

I wonder now if a -ve margin of 3px somewhere would have helped.