Forum Moderators: not2easy
Two things have always bugged me about the various IE bugs and their solutions [positioniseverything.net].
Thesis
So, I've been pondering something... Is it true that IE has all these bugs (more seem to pop up every day), or are they all simply variations on the same theme? Maybe there's simply just one or two bugs, not tens or hundreds?
I will now present evidence showing that my reasoning seems to be correct. IE does not have an endless array of display bugs. Instead, there's just one!
The bugs
Let's take a look at some of the more famous IE bugs...
Peek-a-boo
We've all seen it -- content that magically appears/disappears/reappears, seemingly for no reason. The most common trigger involves floated elements.
Solution? Well, it's been proposed that
position:relativeline-heightheightUnscrollable content
An absolutely positioned element inside a relatively positioned element may cause the scrollbar not to appear.
Solution? The Holly Hack seems to work very well, simply because it assigns a height to the relatively positioned "wrapper"...
Duplicate characters
One of the more annoying bugs! It is triggered by two or more "non-content-generating" elements immediately following a floated element. These "non-content-generating" elements can be pretty much anything that doesn't generate content:
<!-- regular comments -->
element with
display:none3px jog
Eww! Another of those nasty ones. Text adjacent to a float gets indented by 3px, but only for the length of the float. Once the float ends, so does the bug.
Solution? Add dimensions to the element next to the float. This is, however, not always extremely practical, or even possible. And, adding the dimensions magically triggers other bugs. Go figure!
Escaping floats
This bug is a mess! Floated elements "run over the edge" of its container, the container only holds the last row of floats... and... and... (who builds a layout like that anyway?)
Solution? The Holly Hack again comes to the rescue, and performs quite well.
Creeping text
Hmm... Weird! This bug is triggered by nested elements, each with certain identical styles applied. This one you have to see for yourself!
Solution? Apply a bottom border (which may not always be desirable) or "avoid the trigger combo altogether" (well, duh!).
Doubled margin
A float with a margin in the same direction as the float (left margin on left-floated element, right margin on right-floated element) triggers the bug which, as the name indicates, doubles the assigned margin. Very frustrating!
Solution? Up until recently it was thought to be impossible to solve, but now it's been found that simply adding
display:inlineDuplicate indent
Essentially identical to the above bug... but for some reason listed as a separate bug(?). The bug identifies itself the same way, the solution is the same... (Maybe they're brothers?)
Summary
As you can see, the solutions are way different for each bug, and may trigger additional bugs. Other times, the solution is simply not an option because of layout etc. Furthermore, certain hacks/fixes (Holly Hack for example) depend on rendering bugs currently present in IE, hacks that work today, but may well no longer work in the next generation of IE.
Thought process
So, all this got me thinking -- there must be an easier approach? After all, these are all various display bugs that... Wait a second! "Display" bugs? So, perhaps the display property may hold the fix? The fix for the doubled margin bug may not have been a coincidence!
And, in fact, it appears that the
displayMagic
The solution for the duplicate characters and doubled margin problems is, as stated above, to simply specify
display:inlineWhat about the other bugs? Does
display:inlinedisplaydisplay:inline-blockdisplay:inline-blockVoila!
Why are these solutions superior? Simply because if IE finally gets its act together, they will do no harm! No need to worry about whether the fix will break in compliant browsers.
Plus, you don't have to memorize an array of fixes! Simply use the
display<added>
inline-block is not a valid value in current recommendations, even though it has made its way into the candidate release for CSS2.1
The fact that IE already supports a brand new feature (knowing their past history of not supporting recommendations until much later, if at all) obviously only means one thing -- they were already using these types of elements, which in of itself explains why the property works as a fix.
Maybe MS themselves pushed for this addition to CSS2.1? Who knows? :)
</added>
[edited by: DrDoc at 3:54 pm (utc) on July 21, 2004]
Big John: The inline-block value seems to trigger the hasLayout behavior, which is why it fixes all the bugs the Holly hack does. I also found that this method did affect Op7, so it's not really harmless without a hiding hack. That stands to reason, since that value is meant to make a box behave like an inline element on the outside and a block box on the inside.
Well Opera 7 is one of the few browsers that acts on display:inline-block as an implemented feature. If I recall, IE fails to work with it. The fact that it does something when it encounters the code though is interesting! Clearly they were working on it, or put the programming hooks in place for the future, before, as we know, development got halted.[1]
What frustrates me is that IE's developers must have known all these things for years. (Along with how to run older versions on the same computer.) Yet they never seem to let anyone know. All this could have come out years ago. Instead we poor users have to figure things out, try hacks, eventually learning how IE6 works. I wouldn't be surprised if Microsoft have a direct reason for each bug and a way to avoid them.
[1](It's not like supporting the method is crucial to web pages. While Opera try to implement as much CSS support as possible (even some CSS3!) Microsoft have a policy of only implementing what they feel their users require.)
I'm not sure they are "display" bugs (as in related to the display property) they are all in someway related to either MS's "hasLayout" property or they are have that 3px thing going on (float-model problem, not sorted yet..)
so it's their own "hasLayout" property and their own Float Model which are broken?
IE does "support" inline-block, but only on elements that are already inline by default, e.g. <span>, <em> etc..
Though it is an interesting point is that IE seem to pay attention to any display property when it's attached to a floated element (in direct violation of the specs).. as witnessed by the fact that display: inline (on the floated container) fixes the double margin bug.. which seems to be the exception to above relations.. but perhaps not?
As Hester says it seems MS have indeed implemented display-block, though not so sure about it just being "hooks".. I'm tending to think that again they have implemented something that nobody else did (well until Opera that is) for their own use.. but it's figuring out how they used it that is the problem as usual :o
Yes unfortunately
display: inline-block;re: hasLayout
Well that's not funny either :( but it does seem that not giving an element "layout" is the cause of a lot of the bugs so far..
btw.. BJ the Creeping Text bugs and Duplicating Characters (not visible in IE5) can be fixed by forcing "hasLayout" to "true" too.. either by the (Holly Hacked) width/height or a conditional and using the display: inline-block;... so will using zoom on its own for that matter..
What's "zoom"?
[msdn.microsoft.com] is another MS proprietary CSS property which also happens to force "haslayout" and it would be wonderful to use this instead of a "hiding hack" as no other browser (afaik) recognises it.. zoom
simply putting
* {zoom: 1.0;}
at the start of your stylesheet would cover a lot of these bugs..
but.. IE5 doesn't recognise it, although I think I may be willing to live with that one? anyone still using IE5 can expect some display errors ;)
Anyhow still testing but that's some thoughts, nothing like a bit of fresh thinking to force the cobwebs out ;)
Suzy
<ooops sorry BJ, I missed your post where you too mention zoom, but I'll leave this as it explains to readers who may not have heard of it yet ;)>
LisaB
* {zoom: 1.0;}
Excellent idea SuzyUK! What happens if you use a higher zoom value? Does it only affect images, or the entire page, like Opera?
[edited by: Hester at 10:08 am (utc) on July 23, 2004]
that's why it would need to be 1.0 (100%) at the top (if using it to force layout on all elements) but that can be overridden later on in the cascade or by specificity.. for use on a single graphic or <p>....
inheritance would probably be the key, but do test it, I haven't really "played" with it yet.. just did some quick checks
Suzy
are you gonna provide an IE zoom feature ;)
----added--
IE hidden Zoom feature! [webmasterworld.com]
[edited by: SuzyUK at 9:41 pm (utc) on July 23, 2004]
[edit reason] added cross-link [/edit]
I've been spurred on by this thread and what with finding out about "haslayout" and I've been using this zoom catchall for troubleshooting...
simply putting
* {zoom: 1.0;}
at the start of your stylesheet would cover a lot of these bugs..
but.. IE5 doesn't recognise it,
>>troubleshooting:
i.e. not in use on any pages yet because of the IE5 factor. I've found, so far anyway, that in a troubleshooting capacity this has been working very well it even corrects some stuff that isn't mentioned above, like whitespace in lists..
The theory being that putting that bit of CSS at the start of a stylesheet forces all elements to have this IE proprietary "haslayout" which, thanks to Doc starting this thread and forcing me to do a bit of reading and testing, seems to be the actual cause of many (nearly all?) of IE's known "bugs".
It has now occurred to me that this "catchall" would be a useful tool to use on page, no need to spend valuable time working out which bit of the CSS IE doesn't like.. just provide for it at the beginning, if only it worked in IE5...
I figured it would be OK to use zoom if IE5 support wasn't crucial, until hester started his great research into that subject [webmasterworld.com].. so now I think it would possibly have repercussions on sites which decide to use zoom for IE accessibility reasons, making it an overall neater catchall, but unusable on page.
so I came up with this instead..
/* IE/Win catchall hack - but hide from mac \*/
* {height: 1px;}
/* end hide */
It uses IE's height (min-height) "feature" to provide a "haslayout" trigger instead of zoom thus covering IE5 as well. Then because height affects other browsers too it needs to be inside a hiding hack so it doesn't affect them.
So I'm asking for some fresh eyes..
Can anyone forsee a situation where this solution would be a problem?
and/or would anyone like to run/test it in some of their pages for a while and report back if it there are any problems?
Thx
Suzy
I would link to demos I wrote on my site, but I'm not allowed to, so either find them or take my word. I don't have time to reprise all that work here.
Please understand that M$ specifically designed the IE behaviors to prevent sites written for it from being x-browser friendly. You won't find any magic bullet to make IE a nice compliant browser. Any static or relative box that follows a float must not be in "layout" mode if the design is to look the same in all browsers.
vary wildly between IE/win and all other browsers
Not very scientific, I know. Ideally we should build up some test cases... Or just trust big_john of course...
...which I do! @big_john: A shame that you can't link from here (kidding mods, haha), but then again, it does keep a lid on your traffic ;-] haha
Any static or relative box that follows a float must not be in "layout" mode if the design is to look the same in all browsers.
I'm not sure I would totally agree with this, .. "must not" is a bit strong. e.g. when creating columns, then it might actually help, doesn't it depend which way you decide to debug which float model? .. I'll do some revision on that one though..
but..
Using this "all layed out" method will cause any float+static design to vary wildly between IE/win and all other browsers.
Thanks that was the bit I needed to see
[added]Hi mipapage that's my addition to the non-scientific bit ;) ~ and it's not that I don't trust John (I do) ~ I personally just never learnt anything by not asking silly questions sometimes ..hehe...and after all that's what the WebmasterWorld forums are for, we ask/discuss/share/learn here.. :) [/added]
I would link to demos I wrote on my site, but I'm not allowed to, so either find them or take my word.
CSS is about more than jus' bug demos tho' and a discussion forum is a discussion forum .. There are many links to your site from this forum when it's appropriate to link to it.. but in a discussion I know I'd rather have your (anyone's actually) personal input than a link to something I've probably already read! I know when I was just learning CSS I learnt much more from discussion forums than I ever did by reading a demo.. either that or I like to ask silly questions.. and see your personal input was more valuable (to me anyway) in this particular case ;)
Please understand that M$ specifically designed the IE behaviors to prevent sites written for it from being x-browser friendly. You won't find any magic bullet to make IE a nice compliant browser.
I do understand IE, if that's possible, and instead of trying to "fight the machine" I've accepted that hacks are inevitable in order to achieve some degree of IE/CSS conformancy, much like the revered tantek hack was used when there was no other way. (btw I used it in the early days before I even understood why I had to..). Using hacks and understanding why we do is OK for those of us (and there's many) that actually understand CSS and IE, and the ability to be able to "categorize" each individual nuance/trigger of an IE Behaviour, is admirable but imo it is not what is gonna best promote everyday usage of CSS-P (advanced layouts). So the easier/more compact we can make those hacks the better..
I'm not looking for the magic bullet, at least no more than you have, I know IE's problems cannot be solved with one CSS command, else you'd have probably found it by now! But it wouldn't be any fun if we just resigned ourselves to not trying.. hehe
My thinking here was that if we can't have a magic bullet at least a "catchall" or "catchmany" would be nice. And this one does cover the vast majority of IE's display errors, like the ones in msg#1 here.. though then IE's float model goes and mucks it up..
my mental block arose because I have just been using it as a test to debug layout/display errors.. I wasn't "real worlding" it, i.e. paying attention to final content filled layouts (e.g. internal floated images) and then because I knew what was causing the bugs anyway I was removing the catchall and solving the issue in traditional ways becasue I had to, which is why I asked for the fresh eyes really, sometimes can't see the wood for the trees..
A complex discusssion of each and every IE tantrum, everytime it happens would get boring, indeed is not always required, it just depends how much of the "why" someone wants to know I suppose.. But I'm hoping this continues as discussion of a theory as often it's by brainstorming theories that something new appears.. I've personally learnt something new in this thread.. haslayout and zoom.. that I think they will be one of those never to be forgotten things..
Maybe it's just me but I like to know, in fact need to know, what is happening in order to keep up with this profession, .. but still wouldn't it would be nice to "tame" IE just a little so we can get on with the design, fun part of CSS..
I'd still recommend using this catchall method as an initial debug tool (with a caveat to remove it once actual trigger is found) especially for the type of questions that arise here on a regular basis, or at the least another tool for the box. I understand it may not be used as a "magic bullet" solution for on page use now thanks.. and that's one of the reasons I asked, and I hope it won't stop the quest to, at least, "tame" IE's CSS Bugs
;)
Suzy
/* IE/Win catchall hack - but hide from mac \*/
* {height: 1px;}
/* end hide */
This has two problems. Firstly, it affects other browsers. You need to put the code inside an 'IE only' conditional structure.
Secondly, it ruins images and form elements. Go to my site and download the Zoom Test from the Tips & Demos page. Take out the existing code in the style tags and replace it with the code quoted above. You'll see that the forms (except one) are reduced to 1 pixel high! ('Select All' if you can't see them.) Also the image (which you'll have to download manually to see it) is destroyed in the same way. I tried setting the width and height in the code, but only the width was retained (naturally).
Sorry, but this technique is too destructive to use!
Firstly, it affects other browsers...
alas might've almost worked in IE6 strict.. at least it would have less downsides..
Quote from Microft haslayout page [msdn.microsoft.com]:
As of Microsoft Internet Explorer 6, when the!DOCTYPE declaration specifies strict standards compliance, inline elements will ignore the width and height properties, and setting the width and height properties will not cause the element to have layout.BODY, IMG, INPUT, TABLE and TD elements always have layout.
Sorry, but this technique is too destructive to use!
Hester, yes I agree..using height as a catchall does throw up too many other problems..
What I should have made clearer is that I will continue to use the zoom method as a diagnostic tool to force layout.. and if full IE5 support (going the way of NN4?) is not required, then using zoom should be suitable for on page use too.
Adding zoom: 1; (no need for a hack) to the properties of an affected element once it's traced is a lot simpler than adding:
/* hide from mac \*/
* html element {height: 1%;}
/* end hide */
Clarification should perhaps also be made ...The extra problems created by the IE float model are a seperate issue than "display errors", things like peekaboo, creeping text etc...
Often times when building a columnar layout (no wrapping required) using floats and widths in IE the IE float model will be triggered anyway and it should be noted that the IE 3px text jog bug, which is probably the singular most destructive bug when trying to create layouts, can only be best fixed by triggering the quirky float model layout anyway..
so it comes down to choices and although it's highly unlikely that any one cure will fit every layout ~ "no magic bullet for IE" ~ well we can keep trying can't we ;)
anyhow thanks to Doc and this thread.. and I see John has now updated the PIE pages to reflect the latest discoveries [positioniseverything.net] about haslayout and zoom.. at least we now know why the Holly Hack is so successful, it gives an element layout!
Much credit to Doc and his thinking for making us dig deeper into IE.. lol.
For info: These are the properties and values that will give an element layout.
[b]CSS property: Value;[/b]
display: inline-block;
height: any value;
float: left or right;
position: absolute;
width: any value;
writing-mode: tb-rl;
zoom: any value;
What we should now know is that it's not that the affected elements need "dimensioning" it's that they require to have layout ~ whichever hack you choose to give them "layout" is up to you!
Suzy
SuzyUK:What I should have made clearer is that I will continue to use the zoom method as a diagnostic tool to force layout
I think you've made this abundantly clear in all of your related posts, Suzy, and I happen to feel that "behind the scenes" methods like this are just as useful to learn about in the WebmasterWorld forums as tricks that go into actual usage on a published page.
Getting IE to display pages as desired requires and interchange between figuring out (and understanding) what IE is doing, then picking a method that will cause it to do differently. Your contributions to this thread have illuminated a way to accomplish the first and facilitate the second.
Thanks!
<added>
Follow Up one Year on.. [webmasterworld.com]
</added>
[edited by: SuzyUK at 6:49 pm (utc) on Feb. 22, 2006]
[edit reason] added follow up link.. [/edit]
