Justin, You make a lot of very good points. However, a lot depends on the layout you are doing. For many layouts, I don't think this should be necessary.
I generally do not run into major IE problems, or at least problems that are not well documented (3 pixel jpg, box model, double margin, carriage returns etc), so testing IE as I go is not a problem. I think there are two reasons for this: 1. I have the luxury of designing my own layouts, so I am often keeping layout issues in mind during the design phase. The downside is that my layouts are probably not pushed as far as some. 2. Before I start building a layout in CSS, I think carefully about how the browsers will handle the various positioning methods - and which methods will run into the least problems. Examples of this include choosing to pad the content inside container to avoid box model issues and floating both columns to avoid the 3 pixel jog bug. This means you should not run into as many IE specific problems during the build. Of the two points, this is probably the most critical in avoiding IE issues. Having said that, I can see that in specific cases (if experiencing major IE issues) this would be a good alternative. And sharing a completely different methodology is also great, as it provides everyone with a wider range of alternatives. Viva la difference (or words to that effect)! :) Russ > I really don't agree with this. I know you didn't specifically mention > IE in your post, but testing across all browsers all the time slows > down the speed at which you can build pages -- especially when dealing > with IE as well. > > Personally, I just work directly in Firefox and Safari, *occasionally* > checking it out in Opera and others. Only once I'm happy with all that > do I bother with IE. > > Why? > > IE is not standards compliant, so any time you spend on it, and > anything you use in your main style sheet to force IE to behave will > bloat you style sheet. This is NOT the point of standards -- we're > supposed to be minimising code and keeping things clean and simple, so > that everything is forwards compatible. > > IE is not a forward-thinking browser. Whilst it may have dominance > right now, other browsers, or at least Microsoft's next 'browser' will > take over from it, and we'll have thousands or millions of style sheets > out there intricately targeting IE 5-6 in a mess of hacks, code and > comments. > > > Instead, I write my style sheets to work on standards compliant > browsers, and worry about forwards compatibility, not backwards (or > even sideways). > > > But what about IE, the market leader???? > > In some cases, the rendering bugs are OK with me, and the layout is > still *passable*. In other cases, I write (a) separate style sheet(s) > to target IE specifically, cascading over the standards sheets, to > bring IE into line. > > How? > > MS included a great proprietary (but still standards compliant) system > of comments called conditional comments. By using these, we can: > > a) completely hide these IE-only style sheets from non-IE browsers > > b) target the specific versions of IE (from 5 through to 6, including > all minor builds) > > > Sample: > > <style type='text/css'>@import(css/main.css)</style> > <!--[if gte IE 5]> > <link rel="stylesheet" type="text/css" href="css/ie.css" /> > <![endif]--> > > > My experience tells me that ignoring IE during the build, then looking > at it SPECIFICALLY with it's own set of style sheets later saves me > heaps of time and grief. > > Your mileage may vary though :) ***************************************************** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *****************************************************
