*/\thank html> goodness [xmlns*=""] for @media that !

test in the most compliant browser first, then move on to the ugly step children

Fortunately, all of the (current) major browsers today are pretty much "the most compliant".

Mm, I dunno. Sometimes I still have to ask people to set aside MSIE 8 and go try it in a real browser :(

Admittedly it's nowhere near as dreadful as in times past.

Now back to trying to figure out why two-and-a-half of three families of browsers think "display: table-cell" means "divide content among two or more lines if it contains any whitespace whatsoever, even if the whole thing is only two words"

I haven't felt any need to do this for over a decade, but I feel compelled to offer a modest defense for NN4. It was my browser of choice in the 1990's. I started out using Netscape. It had a couple of features that I appreciated, like it's JavaScript debugger and built-in HTML editor. Back then, my development work largely consisted of doing simple table-based sites with some silly JavaScript effects here and there. And so, whatever it's flaws, Netscape always had everything I needed, and I sorely hated the idea of capitulating to Microsoft. In 2000, I was happy to upgrade to NN6. NN6 was reasonably Standards Compliant (at least in terms of the box model and z-index support), so I was able to hold onto Netscape until around 2003 when AOL truly abandoned it. Of course, I'm so change-averse that I also hung onto Eudora as my Email client until 2007 when I got a Windows 7-based system and my copy of Eudora went into a death spiral.

@media doesn't work in IE8.

IE is not 'pretty much "the most compliant"' and we have to hack it on almost every project we work on. By "hack it", I mean use polyfills or other javascript. Sometimes avoiding properties and elements altogether to the detriment of the modern browsers (anything but IE).

While IE10 causes the least of our problems, it is still the worst of the major ones and always causes queasy stomachs upon opening.

We actually write code in IE8 first. We know that browser will struggle the most but, if we can get it working there, then it will be easy to get code/markup working in the more modern browsers and then do 'progressive enhancements'. If you test in a good browser first, Firefox/Chrome, then you risk your code not working in IE and that's when you have to find workarounds.

All versions of IE almost always need "adjustments" that aren't needed in any other browser. It's the worst on the planet.

I don't consider IE8 to be a "current" browser. IE8 is certainly the weakest link of the browsers that should still be supported, but it's not anywhere near the headache that IE6 was a few years ago.

@drhowarddrfine:

I have always done it the absolute opposite way ... Write standards compliant HTML and CSS, ensuring it works in the strictest of browsers. Then, it's been easy to get it to work in IE. Typically, the only thing I've had to change (through conditional comments) as been use of filters where CSS3 features have been unsupported.

Then again, being aware of where the issues lie makes it easier as well. I simply don't write CSS in a way that causes IE to barf. Much fewer head aches.

These days, Microsoft is promoting IE browser in cinemas, I have seen many times their ad! They don't need to advertise if it's really an outstanding browser and isn't shipped with Windows? Why people bother installing another browser when they have preinstalled browser in their windows? You and I know that very well :)

/ off topic

I believe the main reason being that IE was such a bad browser for so very long ... Now that it has become a pretty decent browser, people are so used to installing a different browser on each fresh Windows installation.

Sadly, there are no "outstanding" browsers these days. Most are just "really good".

In any case -- there's really no need to hack it for any browser any more.

For some of us, such as myself:

- 12% of my users are visiting from corporate computers still stuck with IE7/IE8.
- Parts of the site are using third party software that doesn't have well written HTML/CSS (VBulletin)

.... requires the use of CSS hacks. Unless I want to rewrite the hundreds of VBulletin templates, that's the reality I'm stuck with. Rewriting the templates is an exercise in futility, because updates of the software requires merging and rewriting them again.

Pages I write from the ground up, or were better written in the first place, that's a whole different ball game where I do not have to resort to hacks.

rainborick, how did you run Windows 7 in 2007, it was not out until 2009? I ran Eudora up until 2010, even on Windows 7 in one of compatibility modes. Gave it up not due to compatibility issues, but rather that while it beat so many others in features, they eventually caught up and Eudora became long in the tooth.

I recognize that third party software is an exception. But, that also means they (those who wrote that software) simply didn't know any better.

Malformed HTML is really the bane of everything CSS to begin with. If the HTML structure is malformed, our best efforts at writing standards compliant CSS may be futile.

However, if the HTML is clean, validates, etc. -- we have, still, no excuse for using hacks, since conditional comments (as much as I dislike those, too) are a "clean" way of accomplishing the need, without having to worry about whether a hack will break in future CSS parsers.

I am stuck supporting IE8 sometimes, but there's generally no need for hacks - conditional comments are not hacks and I don't really see polyfills as hacks. I prefer to avoid them if possible, but it's not a hack in the sense that DrDoc is talking about (at least to my mind).

To me, the essence of a CSS hack is that it depends on a defect in the way the browser parses a CSS file (or perhaps a minority interpretation of the standard in some cases). The problem with that is that it's a secondary effect and not built for the purpose for which you're using it. It's a hack, a kludge, a workaround.

Conditional comments, on the other hand, if you must support IE, are pretty much future-proof and are totally standards compliant. Generally that's true with polyfills as well - they're using client-side scripting to perform a function that you wish was built into the browser, but they're not exploiting a defect in the browser.

BTW - I wish MS had not extended End of Life for XP. The main reason that people are still on IE 8 is because they're stuck on XP and IE is the max version on XP. When XP finally dies, IE8 will be dead. Since almost no large corps or institutions standardized on Vista, that means that when IE8 goes, so will IE 9. At that point, every browser in use will be very good with respect to CSS2 and a large portion of CSS3. Yay!

I tried to create a site with the most horrendous code I could to make the site 'look' right but throw the most errors possible in tools like the W3 validator. I managed to get a simple page to have over 1000 errors and elements on the page moved depending on browser used, and not in an intentional way. On page css, tables etc... it was bad.

result: It ranked just fine and got no complaints from visitors. Obsolete or not - don't waste time on css hacks.

BTW - I wish MS had not extended End of Life for XP. The main reason that people are still on IE 8 is because they're stuck on XP and IE is the max version on XP. When XP finally dies, IE8 will be dead.

I have a user base on a few of my sites that ranges from age 13 to 75+ with a few over 80. An extreme case as they are historic preservationists focused on ONE mode of transportation. So it's a small niche, of a small niche within a very small niche!

Quite a few of these people are 65+ years old and have proudly told me the first thing they do with their new computers is to take it to their computer guy with the directive to 'Wipe that *&^% off!" (Windows XP installed over the Windows7). Most also stayed with IE6 (ignored the upgrade prompts). These sites' logs have verified this. Unlike other 'retail' sales sites the older users make up >50% of this niche's 'spend factor' and CAN NOT be ignored.

I also start by coding with a recent browser but refrain from doing a 'pixel perfect' layout coding. I go for a mostly Responsive design. I DO NOT offer a mobile version for the 8+ year old cell phones with <300 pixel screens.

I do EVENTUALLY view all sites on IE6/IE7/IE8/IE9 but only make SLIGHT changes to address major forms of visually disruptive behavior like overlap, items popping out of intended flow, etc. I do use CSS to turn off image borders & outlines when used in A tags but I DO NOT have a separate style sheet for any version of IE.

>>refrain from doing a 'pixel perfect' layout coding

This can be a hard sell. I have found that the layout often has to look pixel-perfect on the primary device of the highest paid person involved in approving the site.

In your case, it sounds like that's always you and you're always the one doing the coding. That's handy

I also start by coding with a recent browser but refrain from doing a 'pixel perfect' layout coding. I go for a mostly Responsive design. I DO NOT offer a mobile version for the 8+ year old cell phones with <300 pixel screens.

I do EVENTUALLY view all sites on IE6/IE7/IE8/IE9 but only make SLIGHT changes to address major forms of visually disruptive behavior like overlap, items popping out of intended flow, etc. I do use CSS to turn off image borders & outlines when used in A tags but I DO NOT have a separate style sheet for any version of IE.

Respect! In my humble opinion, that's how it should be done.

We actually write code in IE8 first.

This is actually the single worst thing you can do. While Microsoft spent 98% of it's effort on cleaning up the CSS out of all of it's work on IE8 it does not serve as any baseline. You either code for Gecko or WebKit first, then the other, then Presto (while it's still around) and then lastly and always lastly Internet Explorer. I have an IECCSS tutorial which shows how there is absolutely no need to use CSS hacks ever regardless of how old a version of IE you support.

- John

You either code for Gecko or WebKit first, then the other, then Presto (while it's still around) and then lastly and always lastly Internet Explorer.

Coding to ANY browser is what an amateur does. Professionals code to standards without regard to browsers. What I meant was, we test our code in IE8 first. The purpose is to make sure that paste-eating browser can understand fundamental markup first because we already know the other browsers DO understand it. otoh, if you write and test markup for Chrome/Firefox/etc you run the risk of creating a page that breaks down in IE but runs well everywhere else. THEN you may wind up taking code apart and away from those browsers causing even more issues, all while trying to "fix" it for IE. It is far easier to teach a 2-year old to walk than run but then let the more mature children run to their hearts content.

When you know the fundamentals are working in IE, you can move on, without worry, to the better browsers but you never, EVER code to any browser.

In the past, we did as some of you did, testing in a more advanced browser first and thought that was the best way. Never again and we are far more productive because of it and we have far better, more advanced, better written web sites.

Afterthought. Coding in parallel for "rules" and "cssRules" may not technically be a CSS hack ... but it's still a browser-specific extra that affects the stylesheet. Fortunately I only need to do this in the occasional e-book, and then only for Added Value, but still.