CSS

I'm having problems in IE6 where the left column decides to go for a wander when the screen is narrowed in width.

Any ideas? It's just IE6 that has the problem.

*link removed* Forgot about the link rules here.


.floatLeft {
float: left;
}


seriously though.. I can't even spot why yet as there is a lot of new code, but I'll keep looking as of course I'm interested to know what would break it

I have to think it's something in the content you've been adding, where is the .floatLeft class applied.. it's not part of my template code

[edited by: SuzyUK at 10:23 am (utc) on Mar. 7, 2008]

The ie6 rule you mailed me seems to have sorted it though.

Just going through and checking for ie6 wonderbugs on the rest of the site. :)

as we know cos we've been chatting.. he really did break it you know! It's taken around 3 years but it had to happen ;) and I would like to say thanks for letting me know as it allowed me to see a very specific set of circumstances to prove to me what I'd always felt.

The code in question is my Flexi-Floats template, it contains this code

#centerpad { margin: 0 185px; background: url(image.jpg) no-repeat 100% 0; }

up until now the template has been hasLayout hack free, but that particular rule was always a red flag to me anyway that perhaps it shouldn't be. I've said a few times over the years that if you get a display error, look for a div that has left/right padding or margins on it but doesn't have a width.. this rule fits that description but up until now (to my knowledge) the template had never errored once content was added.

However Ryan's code triggered a relatively unknown IE bug, hasLayout related of course!, in the content (center) area..

His content code tripped the inherited margin on form elements bug which in turn started a chain of events that led to the 'centerpad' divs margins being inherited and the overall width being added to (stretching box behaviour).. sheesh

anyway long story short, although that explanation at PIE details various fixes they are all unrealistic (why add to the HTML for an IE haslayout fix!) - there is an unmentioned fix for that bug and that is the one of triggering hasLayout=true on the ancestor which has the margins.

The ancestor with the margins in Ryans case is my templates centerpad div margins, So it comes full circle and I'll take it on the chin and give in hehe, I have now added a hasLayout hack to the template and have advised Ryan to do the same rather than fix the smaller haslayout issue with HTML.. yes he could workaround it from the inside but why should he have to I always felt that div needed a hack just didn't want to add one until there was proof - there is now. eeek I knew IE would get me in the end :)

so code is now:

#centerpad { margin: 0 185px; display: inline-block; /* TRIP haslayout for safety */ } #centerpad { display: block; /* SWITCH back the display */ }

I'm using the 'tripswitch' to trigger layout, but you can use whichever is your favourite method

-Suzy

I'll add some wood to the fire i'm building under IE6 in your honour. :)

Thanks again for spotting that, it took some finding on your part and it's appreciated.

I'd recommend your layout to anyone and believe me i tried a few, after having trouble trying to get one of my own working with IE.

I've learnt a lot in the process as well.