Forum Moderators: not2easy
I built a pretty big site with a three column layout using css and xhtml strict (both veriefied). Everybody liked it, I tested in all current browsers and then it happened ... someone looked at it using IE6 and told me it looks like you know what. I thought MS forced everybody to go to at least IE7 via Windows Update and so IE6 was just a dark memory of the past.
So I look at it for myself and sure thing IE6 takes the third (right) column and puts it underneath the footer on the right side.
Below is the basic script I used to get this started. Could someone please, please, please look at it and help me get this right for IE6?
Thank you so much
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<meta http-equiv="pragma" content="no-cache" />
<meta http-equiv="expires" content="-1" />
<title>test</title>
<style type="text/css">
body{margin:0;text-align:left;}
#top{clear:both;width:930px;margin-left:18px;margin-bottom:20px;}
#wrapper{margin:0 auto;padding:0;border:0;width:966px;text-align:left;}
#lco{float:left;margin-left:18px;width:190px;margin-bottom:20px;background:blue}
#cco{float:left;margin-left:10px;width:530px;margin-bottom:20px;}
#rco{float:right;margin-right:18px;width:190px;margin-bottom:20px;background:red}
#bot{clear:both;width:930px;margin-left:18px;margin-bottom:20px;}
</style>
</head>
<body>
<div id="wrapper">
<div id="top">top</div>
<div id="con">
<div id="lco">left</div>
<div id="cco">center</div>
<div id="rco">right</div>
</div>
<div id="bot">bottom</div>
</div>
</body>
</html>
Why are you coding for IE6? This dinosaur is about gone... and will soon go extinct because the web in general has evolved beyond that. Take a look at your log files to see what the IE6 visits might be. There comes a time to fish or cut bait.
Making comments of that nature doesn't help the situation that pstar99 finds themselves in. A lot of site authors still need to support IE6, and coupled with requests from the businness, this becomes mandatory.
pstar99, you're experiencing IE6's double-margin float bug; add 'display:inline' to #lco and #rco and it will work
Actually I'd make a point of always adding Ie specific to a version specific conditional comment only (you don;t want IE8 to see it and throw a fit over it.
I would also add the display: inline; to the #cco div as well
in short any time you have a float with a margin on the same side as the direction the float goes, i.e. float: left; margin-left, or float:right; margin-right, IE6 will double the margin
adding display:inline; to these floats does no harm and for a while I used to add it to every float out of habit in case someone later came along and added a margin
but now, you might just like to put them in a separate IE conditional stylesheet so they can be forgotten about when IE6 finally does expire for all ;)
too slow, Swa, beat me to the conditional comment :),
[edited by: SuzyUK at 9:34 am (utc) on June 18, 2009]
in short any time you have a float with a margin on the same side as the direction the float goes, i.e. float: left; margin-left, or float:right; margin-right, IE6 will double the margin
IE6 will only double the margin if the element in question is floated, has a margin in the same direction and touches the side of its parent (in the same direction).
So there's no really no point for pstar99 to add 'display:inline' to #cco since it's not touching the left (since it's floated left and has a margin-left value) side of it's container. While I understand your thoughts in theory, SuzyUK, it's worth authors learning exactly what the trigger is, otherwise stylesheets can become bloated with unnecessary styles.
it's worth authors learning exactly what the trigger is
I'd rather spend time to learn how to use something new in CSS3 than to waste time on better understanding IE6's bugs.
but I'm with Swa, I no longer think there's any point in worrying about the minor nuances for IE6,
display: inline;Like I said, I used to add it to every float, PRE IE7, as a 'just in case' any other author following me added margins after the fact (it wasn't for me to know where they might add them!).. and now (post IE7) if you do have an IE6 stylesheet,
a: you've already got a small bloat ;)
b: what difference will line 1 really make over line 2?
#rco, #cco, #lco {display: inline;}#rco, #lco {display: inline;}and.. I'm busy with IE7/8 & CSS3 too :)
It's not important to know when the bugs in IE trigger, it's only important to know how to counter them if and where you trigger them
How are you meant to identify a bug and find a fix, if you don't know when, or how a bug is triggered? Knowing when bugs are triggered can also dramatically save development time, as you're able to anticipate what combinations of properties will cause a bug - rather than resorting to asking around on forums for answers.
It's a mentality that I certainly don't agree with. It might not be important for you to know when bugs are triggered, but I myself would certainly encourage people learning CSS to research when bugs are triggered.
I no longer think there's any point in worrying about the minor nuances for IE6, display: inline; does no harm on any float and it's easier to remember: if floating add display: inline; cause there's IE6 bugs, than remember what the whole details of what the actual bug is.
Wow.
Assumption can be a counter-productive thing. If you're adding property combinations with the assumption that you'll trigger a bug, then you're stylesheets will become very bloated- especially with something as broad as the float property
just to try to reassure you that I'm not being assuming in a flippant kind of way. I do already know my bugs :) I have even been been known to discover/find fixes for some of the pesky critters back in the good 'ol days, always with the help of the fine folks here at WebmasterWorld and PIE (both of which is likely to come up if you do a search on IE Bugs), in fact if I may be so bold, if you actually search for "suzyuk ie css bug" (not that anyone would..) you'll see the help & information I give, have given in the past, does get passed around a bit, so I do actually feel a certain responsibility to not be flippant.
If you're adding property combinations with the assumption that you'll trigger a bug
>>my stylesheet bloat
I've seen worse hehe.. besides a separate IE sheet with one broad comment covering a combined selector rule is a lot smaller than comments against each and every time an IE specific rule might be used in a main stylesheet, so I reckon I'm still on a par, even with my existing pre-emptive strikes :)
you said it yourself:
Knowing when bugs are triggered can also dramatically save development time, as you're able to anticipate what combinations of properties will cause a bug - rather than resorting to asking around on forums for answers.
As well as trying to pass on the benefit of some of my past learnings, I am also realistic as to the future. Why should other newer developers waste their time learning about this particular bug especially, hasLayout is different as it's still present in IE7 - it's safe to say that most professional developers don't care about the hows or whys of IE's old logic/inner workings they just need to be able to use CSS especially now that we have IE7/8, and to be perfectly honest I want the young developers to forget about IE6 (we'll be there to help them finish it off muhaha) and fire ahead with CSS2/3 so we can learn newer, more exciting tricks from them :)
A lot of thanks is due to the likes of people here and at PIE persevering with the IE 'bugs', that we are now able to do just that, even though it wasn't always easy back then.
Remember too that IE7 wasn't supposed to happen (though I'm glad it did!), so there was indeed a limbo time when it was useful to know each and every bug individually. But that stopped with the discovery of hasLayout, release of IE7, and the patching of the more common IE6 Bugs.
Most Professional developers (especially newer ones) now just want the safest/quickest fix for IE6 and to be to aware that if they are still having to support IE6 they can be rest assured that all the best forums can help do that for them. If they want educated as to the hows and whys in order to learn, we can always do that or refer to back threads or the library - e.g. This particular bug was hot off the press [webmasterworld.com] over 5 years ago, which was a very different time in IE land ;).. ahhh..and I so remember the days of hacks for each and every early versions of IE, NN(FF), Opera.. but the actual specifics of all those bugs are long since forgotten, and I assume nobody cares anymore but if anyone does we can probably find some threads for them too - But seriously it's time to press on, tackle the new stuff, relegate IE6 to the bottom drawer and enjoy CSS all over again
If you think I'm being flippant or assuming, I'm sorry it came across like that. I'm just trying to be helpful by passing on the info without having to
a: re-write some of the older posts that exist here and other places
b: keep the IE sucks myth going
c: put off the next generation
d: detail bugs that are already writhing on the floor :)
However I do get your point about the educating as that is what we here at WebmasterWorld always like to do and you obviously know your stuff, so I think your expansion of the solution to this problem, as well as questioning my method may have done a power of good, so thank you! :)
a particular project I have been working on this weekend, a form, has a couple of floated inputs but NO same direction margins are involved (never mind the "touching" parent part). Therefore according to @jameshopkins logic I shouldn't need a "bloated" universal fix. BUT, When I get to the end and check out IE6, things aren't where they are supposed to be.. I checked all possible combinations then started tweaking margins (for IE6 only) just for fun, and to get it to work as per my directive.. to my surprise I find that negative 6px margin corrects the issue.. that's a 2 * 3px bug, so I'm looking for 2 floated elements hmmm.. at this point I could just have negative margined the 6px in the ie6 sheet to release me as per Swa's very good logic too, but I'm a little thrawn!
So to me it's a well known bug that is related to hasLayout but according to the 2 x floats I have I cannot, do not want to, remove the widths from them, they are important to how this form will render.
So I then think what the heck and add
display: inline;YEP, it's fixed
not only is there no margined floats in the same direction as the float, but what the heck does this double margining have to do with the 3px thingie..
So long story short, if I'd have put the
display: inline;This is not a point to prove, I really am just sharing, because I'm pretty sure someone could work it out if they wanted to, but more importantly it's amazing how many times I take things for granted, and when I look at those things another way, outside the box if you like, I find no-one really knows and sometimes it really isn't worth the effort.
This problem was only occurring in IE6, the project was already a "do what you can for IE6 thing" and so it's delivered, working in IE6 too.. do you really think if I'd have delivered it without IE6 functionality it would have made any difference if I knew how to explain why it didn't work..because I only knew how the bug should work as opposed to how this particular combination of this 'bug' works?
Logic will take you so far, instinct will take you the rest of the way IMHO.
I have even been been known to discover/find fixes for some of the pesky critters back in the good 'ol days, always with the help of the fine folks here at WebmasterWorld and PIE (both of which is likely to come up if you do a search on IE Bugs), in fact if I may be so bold, if you actually search for "suzyuk ie css bug" (not that anyone would..) you'll see the help & information I give, have given in the past, does get passed around a bit
No, I said I was adding it as pre-emptive measure. Not an assumption, I already knew which "fixes" were needed or not at the time I wrote the templates, I also knew my code didn't trigger the bugs, BUT that it didn't matter in this case if the extra fixes were added, it was never going to harm.
I'd argue that preemptiveness and assumption are the same things, here.
In this instance there is some room for flexibility, due to floats championing the inline display model.
If we can take bug #27 (which I've found a fix for) on my list as an example here; you'll note from looking at the description, that there are a number of conditions for triggering the bug - one of them is a percentage padding value. Now based on your logic (if I understand it correctly), you would add the fix ('overflow' value other than 'visible') to the element to which the percentage padding is applied. Now call it preemptiveness or assumption, I'm sure you'll agree that it's completely unnecessary to add this fix unless *every* condition to trigger the bug is met.
... said someone else/end user, who might not have known their bugs so well, might have picked up my work added some margins or just changed the float order, wondered what the heck was happened, called me names for providing them with an unstable template, never used my services again
Thats not you're responsibility; upon code release, the document was stable - any changes after that are out of your control. Instead of blaming the original author, the subsequent author should learn about what they had changed to trigger the issue.
...besides a separate IE sheet with one broad comment covering a combined selector rule is a lot smaller than comments against each and every time an IE specific rule might be used in a main stylesheet, so I reckon I'm still on a par, even with my existing pre-emptive strikes :)
I am not suggesting for one second that each individual fix should go into the main stylesheet; they should go in a stylesheet specifically targeted for IE6.
Why should other newer developers waste their time learning about this particular bug especially, hasLayout is different as it's still present in IE7 - it's safe to say that most professional developers don't care about the hows or whys of IE's old logic/inner workings they just need to be able to use CSS especially now that we have IE7/8...
Yes, but there are many major bugs in IE8. Coupled with the complications that Compatibility View adds to the equation (forcing Standards Mode can actually be a hindrance in some situations, unfortunately), I'd argue that it's very important for authors to understand when and how one of these bugs are triggered. If we can take bug #27 as an example again; I'm certainly not going to be adding 'overflow:auto' to every element to which I apply a percentage padding value to. To put it bluntly, its simply not a realistic goal to add a 'preemptive' measure to counter every possible bug, when only *one* bug condition is actually used.
If you think I'm being flippant or assuming, I'm sorry it came across like that. I'm just trying to be helpful by passing on the info without having to
b: keep the IE sucks myth going
But IE *does* still suck ;)
I'm not trying to argue with you; it's just an interesting perspective that I've never come across before.
