Forum Moderators: not2easy
Obviously, this involves figuring things a little differently for IE.
Now, I enounter a problem, and will spend several hours figuring a workaround for it.
In most cases, I can fix things quite easily...... yet I go out of my way to avoid using "Hacks".
Please, correct me if I'm wrong..... but a Hack is a non-validating snippet/code within the CSS used to fix something.... things like using "*" or "_", "/" etc.....
Not only is it "illegal" code, I swear it will only come back to haunt me.
So I envest the time and effort to "workaround" these things.
In most cases, I default to the following.....
* I include additional Divs, and split the CSS code between them, putting the code that normally gets "stuffed" by IE in the second "encapsulated/wrapped" div.
* I apply things like "display: block;" or "height: 1%;" etc......
* <!-- whatever I want to put here -->
is positioned in the HTML above the Doctype, which is set as strict. This seems to affect IE rather nicely, without touching other browsers.
Pleased with this, as I think I'm the only one that uses it...... yet have no idea why it works...... I think it convinces IE to remain in Quirks mode...?
Yet I still browse the web looking for other ways to do things, as I'm not stupid enough to think I know the best (well, not all the time ;) ).
I have finally found this old thread here.....
[webmasterworld.com...]
which explain why half the workarounds I figure out seem to work.
Genius.
Has this been taken anyfurther?
Does anyone know of sure fire ways of....
Adding Layout to an element/object/entity?
Removing Layout from an element/object/entity?
Has this been taken any further?
An update of sorts [webmasterworld.com]
Also Microsft released their own explanation [msdn.microsoft.com] after the above two threads, and at the bottom of it you will find a link to another great article "on Having Layout" ~ which helps explain just what it affects. There is just too many ways it can affect pages! mi
Adding Layout to an element/object/entity?
they are explained in that thread, and you might want to consider zoom: 1; a bit more that was emphasised there (unless you want to support IE5.0) because * HTML which was feeding IE a height will no longer be supported in IE7, and while it won't break IE6 and below, the layout issues are showing to be a little different. Some gone some new!
I received a message this weekend which I think sums it up..
Star HTML is Dead, long live zoom: 1;
Removing Layout from an element/object/entity?
My advice is not to get too caught up it it all yet, just use zoom: 1; (and/or - STAR html to feed a small height) on the elements that works to fix it for your site and put them inside a conditional comment targetted at all of IE, then when IE7 comes out proper it's very likely that some of the existing ones will be needed for it too and there could even be some new ones but some of them may not be needed, that will be house keeping time!
but that's too much information likely the reading should be enough for now :)
Suzy
Still confused with the Quirks mode bit though!
Just by putting
<!-- nnn -->
above the Doc tag seems to work small wonders for me in IE.
I'm not 100%, but it seems to reomve some of the!uirks bugs, and some of the Strict ones as well, (either that, or I automatically workaround those bugs now without thinking ;) ).
Still confused with the Quirks mode bit though!
Quirks Mode = Quirks Rendering Mode, the opposite of "standards-compliant mode" which is usually referred to as "Strict Mode" ~ it does not = "Quirky rendering behaviour" ;)
autocrat, Quirks Mode invokes IE's box model, and a few other little differences they had before making some CSS enhancements in IE6 [msdn.microsoft.com], the enhancements were made as the first introduction towards more compliant behaviour into IE.
What this means in simple terms and regarding the Box Model is that if you have a box with padding, borders and width set then IE, in Quirks Mode, will need a different explicit width than compliant browsers in order for the box width (not the content width), to be the same x-browser : this is typically fed through a target ALL IE Hack as IE6 will follow the IE layout model.
In Strict rendering Mode this means that IE6 is now following the "standards" Box Model and now does not need that different width set but you may still need an Alternative Box Model Hack to target <lte IE5.5
-------
>>Quirks mode triggers rendering bugs
are you sure about that? to me there's just as many in Strict rendering mode than are in Quirks, virtually the same ones usually... have you an example of one that might be quirks mode triggered or fixed
All that quirks mode will do is cause some extra box model workarounds for widths/heights, and if you've got a width set whether it needs a subsequent quirks/strict workaround or not then the rendering issue is usually triggered anyway, therefore not mode dependant
To my mind it's the setting of the width (or height) in general that triggers/fixes some rendering issues, although it could be said that anyone making a lot of use of explicit widths/heights in their layouts is more likely in general not to trip up IE display rendering errors quite so often, or is actually tripping it up but subsequently fixing it by the nature of the design.. but that would apply whether in Strict or Quirks mode?
Suzy
have you an example of one that might be quirks mode triggered or fixed
Certainly! The incorrect box model is a rendering bug :)
Whether that affects your layout or not is really not relevant. But, the fact that IE's proprietary box model is invoked in quirks mode is well known.
I can't think of any other bugs right now ... but that's one for sure. The fact that it is handled that way on purpose doesn't make it less of a bug ;)
You are correct, however, that all other bugs (Peekaboo, 3px Jog, Double Float Margin, etc) can be seen whether in Strict or Quirks mode.
The fact that it is handled that way on purpose doesn't make it less of a bug
We will have to agree to disagree .. my belief is that IE's Box Model cannot be classified as a bug, it is a feature, it works as per their intention for it to, whether or not we like that way is another matter, we could just call IE a bug as a whole if we want to think that way.. ;)
just thinking.. if Conditional Comments had been touted/favoured since they were introduced in IE5 then there would have been no need for Box Model Hacks (that is a misleading name these days isn't it, especially when they're used for other things like font-size..) anyway, we would just be used to using IE prorietary comments to workaround IE proprietary behaviours, again whether we agree with that method is a personal choice also.. but anyway I think they got the message about doing it (the Box Model) the standards-compliant way :)
IE's Proprietary "Layout" Model may be a different thing altogether, yes it's theirs but it doesn't work very well, resulting in unexpected display errors frequently, affecting floats and positioning often, no documentation to support it - so one could rightly call it buggy?
Suzy
I've been looking/playing, and reading my notes, and the main reason I ended up having that tag-use was for the
width/height:(expression)
what not for Min/Max width/height
for somereason, (possible poor coding on my part), some of the designs cause IE to freeze-out if it's not in quirks mode, so I implement that tag...... then again, some designs don't cause that problem!
*scratches head*
still, atleast I know whats happening now, not htat it makes a lot of difference, just nice to know that I can implent some other CSS techniques rather than height:1% to fix some bugs.
and just for the record, (probably get shot for this), it's not just IE that requires hacks/workarounds.... NN and MFF aren't particularly perfect either. They have their own little issues too, (though MS bashing is a fun hobby ;) )