Forum Moderators: open
Here are some pointers and ideas on how to avoid getting shocked, should you decide to view your page in a "real" browser ;)
Don't use IE as your default browser
When you design/develop a new page, or try out a new design/layout - do not use IE as your primary browser. Make the page work in a good browser, such as Mozilla, first - then tweak it a little so IE will understand how to render the page as well. Make sure your tweaks don't cause the page to break in Mozilla/Opera ;)
Use a full DOCTYPE
Always, always use a full doctype, whether you're worried about validating your pages or not. The doctype serves a far greater purpose than validation. You will be surprised how much a page layout will change depending on whether you use a full (and valid) doctype or not. Again, IE is the black sheep. Layouts can be stable or break depending on the doctype.
Unsure about which doctypes you can use? Check W3C's list of valid DTDs [w3.org]
Realize that IE does not render CSS correctly
On this forum I have seen the following numerous times:
:link {
text-decoration: none;
}
:hover {
text-decoration: underline;
}
Ok, that looks ok, doesn't it? There's no problem with the first selector. It will do what you expect it to do - remove the underline on links. However, the second selector will cause all elements to be underlined when you move the mouse over them.
Why? According to the CSS "rule book" :link, :hover, :active, etc can be applied to any element. Right now, the anchor tag is the only element to which :link and :visited can apply. But, you can hover all elements. Again, IE is the only browser that doesn't get this. IE will not apply any :hover rules, unless the element is an anchor. But all good browsers will... and they are right.
IE 6 is not much better than IE 5
IE 6 was supposed to be fully "CSS1 compliant". Is it? No! Basically, the only things they fixed were:
• correct boxmodel rendering (if using a full doctype)
• fixed rendering bug which was exploited in the boxmodel hack
...and, that's about it. IE is not CSS1 compliant. It doesn't support some of the most basic CSS rules. You would think that something that has been around for over seven years would be implemented by now, but it's not. Not in IE. But it is in most other browsers.
So, when you read the CSS "rule book" on W3C's Web site [w3.org], keep in mind that even though something is supposed to render a certain way, that doesn't necessarily apply to IE ;)
Bottom line is by coding and testing in a browser such as Mozilla rather than going the IE route, you will be saving your time on your way to creating pages that work across all browsers.
And while you are saving your time you will have the added bonus of writing correct html and css.
Quirks mode
Need I say more? Why would you even think to implement something that will trigger "quirks mode"? However, contrary to most people's beliefs - quirks mode does not mean that IE6 will now start rendering pages the way IE5.5 did. So, what does it mean?
Quirks mode simply means that IE6 will simulate the incorrect boxmodel rendering. Period.
Furthermore, the IE dev team also saw it fit to implement a couple bug fixes. (Good for them! Now, what about the rest of the bugs?!) "Well, that's good, isn't it?" Not really...
While they implemented a "quirks mode" trigger (still can't get over that!) they patched the rendering bug that caused the boxmodel hack to work. So, here we are with a broken boxmodel, but the hack no longer works! Way to go, fixing one problem while causing two new ones!
Standards suck!
...seems to be Microsoft's take on, well, everything! They think they are above the law, they believe they don't have to answer to anyone.
That's why they have implemented HTML tags that don't exist (do I need to say <marquee>?), JavaScript functions that don't exist (<cough style="type: faked;">document.all</cough>), and CSS functionality that is not part of any standard (vague: expression();).
Is this helpful? Not really... While the CSS expressions may be the only really neat thing coming out of M$'s gold plated trap, it only serves one purpose - fix something they broke in the first place.
So, instead of truly solving the problem, IE is implementing non-standard fixes that are likely not to work as you expected, unless hidden from other browsers.
And, I won't even mention M$ Office proprietary CSS. It is uuuuuuuuuuugly!
While they implemented a "quirks mode" trigger (still can't get over that!) they patched the rendering bug that caused the boxmodel hack to work. So, here we are with a broken boxmodel, but the hack no longer works! Way to go, fixing one problem while causing two new ones!
Did they really _implement_ that quirks mode trigger, or did they just get it wrong again?
And further re: the box model hack.... never liked it anyway ;) there are better ways to get around it. IE conditionals for example..which is M$'s way of really patching up!
However although I don't want to have to use them.. I now consider them the best way out...(OK so that relies on me knowing the calculations in the first place... but so do the various hacks)..
<rant>I hate hacks for something that should work in the first place!</rant>
So again they are taking us (the ones who know they're wrong!) and giving us a way out, which will ultimately force us back to picking faults with the other browsers and so the myth will continue..
Suzy
Did they really _implement_ that quirks mode trigger, or did they just get it wrong again?
CSS "enhancements" in IE6: [msdn.microsoft.com...]
[edited by: DrDoc at 8:05 pm (utc) on Oct. 6, 2003]
Two additional CSS properties are supported: min-height...Remarks
With Internet Explorer 6, this property applies only to td, th and tr elements in fixed-layout tables. Auto-layout tables are the default. To create a fixed-layout table, set the tableLayout property of a table element to fixed.
Yeah, right! Wow, what a "fix"! I'm so glad you "implemented" min-height! ;)
too many people fall victim to IE's "forgiving" nature and become frustrated or confused when they find out that the other browsers are less "forgiving."
ALL browsers to date have been forgiving of errors. It was/is an essential factor in the popularity of the web.
I would imagine that people who fall victim to Moz's better standards compliance (;)) may become equally frustrated or confused when they discover their "correct" code goes wobbly for 95% of their audience.
The frustration and confusion in each case is because browsers render pages differently. Mainly using Moz or Opera etc to test doesn't change that. Unless of course you are going for w3c-compliance over audience-compliance... ;)
ALL browsers to date have been forgiving of errors. It was/is an essential factor in the popularity of the web.
...and one of the main factors to decreased usability.
may become equally frustrated or confused when they discover their "correct" code goes wobbly for 95% of their audience
Never been a problem ;)
At least this way you have a shot at getting it to work in 100% of the browsers, whereas otherwise your goal is 95% at best :)
I'll be quiet now...
I would imagine that people who fall victim to Moz's better standards compliance () may become equally frustrated or confused when they discover their "correct" code goes wobbly for 95% of their audience.The frustration and confusion in each case is because browsers render pages differently. Mainly using Moz or Opera etc to test doesn't change that.
Your missing the point. If your goal is to make pages that are accessible and work correctly in everyones browser, you will save more time and effort by testing in mozilla and then adding a few fixes for IE rather then doing it the other way around. Try it you might like it :).
Unless of course you are going for w3c-compliance over audience-compliance...
Contrary to popular belief these are most often the same thing.
I just can't see a clear benefit, and to be honest I suspect this discussion is driven more by standards-fanaticism than pragmaticism.
Try it for yourself. I used to test in IE6 and then work through the other browsers. That was the way I did things. I was quite frankly amazed at how much easier it is to go the other way around. It saves time and a lot of headaches. Whether your 'pro standards', 'pro mozilla' or 'anti-microsoft' it really doesnt matter. If your goal is to have pages that work in all browsers, its simply easier.
Well I don't need to, since I don't usually have any problems..
So you write perfect pages that work in every browser without ever testing them, thats pretty amazing.
As long as the pages work - that's all that matters :)
As long as the pages work - that's all that matters
Agreed! :)
CSS "enhancements" in IE6that's incredible.. or is that incredulous?
mattur it's a good job you keep changing your mind.. it just keeps getting worse ;) in fact I'd stay on the fence too if I were you.... cos.... it ok you don't want to know
Suzy
Something that I think is being missed when saying that MSIE is less strict (which BTW is generally true (though sometimes the opposite is true) and is also IMO a Bad Thing) is that in general MSIE also includes less features of HTML than the the other browsers; therefore, if you want to include a lot of "cool" features you might find they will work in, say, Gecko but not MSIE - this is another reason, if you are not a strict follower of W3C standards (but at least a bit of a get-things-to-look-right-in-the-different-browsers designer) to use Gecko to test first (maybe after Lynx) then Opera, KHTML, MSIE, &c.
Anyway, the main reason I was posting here was to do a shameless plug of a post I posted in a thread a while back (regarding getting round MSIE's bad design): post 27 at [webmasterworld.com...] .
