Cottleston Pie

I'm stunned. This is not what I expected. Some sort of concession, maybe, but nothing like this. Way to go, Microsoft!*

From the IEBlog post:

We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can.

I personally consider this fantastic news. I was broadly opposed to the version targeting idea as presented, i.e. that it would be an "opt-in" system, but had largely resigned myself to either ignoring it, or suffering it if I deemed the new CSS/JavaScript shinies in IE8 worth the effort.

Any site needing IE8 to render in IE7 mode (for whatever reason) need only apply a one-line fix: the meta version targeting method originally proposed to work the other way around (or the HTTP header equivalent).

In summary, this is the good news, as I see it:

• Developers need do nothing beyond using current standards to get the best standards-compliance from IE8.
• The change should encourage developers to adhere more strictly to existing standards, particularly if doing so enables more advanced CSS and JavaScript capabilities in IE8.

This should also mean that IE8 will automatically pass the Acid2 test, rather than requiring a nudge to do so. From the Microsoft press release:

IE8 has been significantly enhanced, and was designed with great support for current Internet standards. This is evidenced by the fact that even in its first beta, IE8 correctly renders the popular test known as 'Acid2', which was created by the Web community to promote real-world interoperability [...] Our initial plan had been to use IE7-compatible behavior as the default setting for IE8, to minimize potential impact on the world's existing Web sites. We have now decided to make our most current standards-based mode the default in IE8.

And this is the potentially bad:

• Anyone requiring, for some reason, IE8 to behave as IE7 will need to add the meta switch or the HTTP header to their code.
• More inconvenience in the short term for anyone supporting legacy documents.

I'm very impressed by Microsoft's move, and hope that it doesn't somehow get overruled or watered-down before IE8 is released.

(*I can honestly say that I never thought I'd write that - "never say 'never'", I guess!)

I read Eric Meyer's Reset Reloaded late last year, and have been toying with a reset.css of my own. Eric recently posted an update to his version, and the following caught my eye:

The small changes involve a paring down of the possible quotation around blockquotes and qs. Before, I was explicitly pushing in empty generated content boxes with content: "", but there was no need. A simple quotes: none; takes care of suppressing any automatic quotation marks on those elements.

Something in the back of my mind wasn't happy with that, so I went hunting. It turns out that that WebKit, and presumably Safari (as per its documentation), do not support the CSS 2.1 quotes property, so will suffer doubled quotes when only the quotes: none; method is used in conjunction with hard-coded quotes in the markup.

I've whipped up a test page that shows the lack of support in WebKit/Safari, and includes my modified version of Eric's no-quotes CSS rules from Reset Reloaded. The CSS successfully suppress generated quotes in a recent WebKit nightly, so hopefully also works in the various Safaris - confirmation would be much appreciated.

Interestingly, when I tried the :before/:after method on my alternative test page with just content: none; (a property specified in CSS 2.1), it worked fine in Konqueror 3.5.8 (using the KHTML renderer, which WebKit is derived from), but seems to be unsupported in the WebKit build I used. Using content: ""; (since none is not specified in CSS 2), as in Eric's Reset Reloaded, does the trick, but as Eric himself notes in his update, this actually creates empty generated-content boxes. Unfortunately, it seems to be the only way to strip quotes from Safari.

Also, in Konqueror 3.5.8, when using just the quotes: none; method, an unexpected black box appears at the end of the q element. I'm not entirely sure what causes this, and would appreciate any insight, but it's yet another reason to suffer the content: ""; method, at least for now.

This is my recommendation for anyone wishing to remove generated quotes:

blockquote, q
{
	quotes: none;
}

/*
Safari doesn't support the quotes attribute, so we do this instead.
*/
blockquote:before, blockquote:after, q:before, q:after
{
	/*
	CSS 2; used to remove quotes in case "none" fails below.
	*/
	content: "";
	/*
	CSS 2.1; will remove quotes if supported, and override the above.
	User-agents that don't understand "none" should ignore it, and
	keep the above value. This is here for future compatibility,
	though I'm not 100% convinced that it's a good idea...
	*/
	content: none;
}

Phew. A lot of attention for such a little problem, but duly documented in any case.

I'm still refining my own version of a reset.css, and when I'm happy with it, I'll post it on here. Happy coding!