Three Monkeys, Three Typewriters, Two Days

I think you dropped the word "invalid" from the third sentence.

> Just as important is whether the browser handles
> invalid css correctly.

How can this be done? The possible input errors are enumerable, but they are quite definitly outnumbering anything you want to define a specified behaviour for. At least I don't see an implementation doing anything more than signaling an error (implementation dependent) and recover from something like "kiss my hairy ass, you (/§")$/"!§=)(" ;-). No insult on the reader or writer, just to make sure that a dd if=/dev/random might eventually generate that. Even should. Theoretically.

Or was you whole point dealing with "that's an error, recover"? (That can be hard enough, judging from the XSLT1 spec)

Well, the CSS spec specifies some very specific error-recovery rules that are NOT implementation-dependent. And testing of implementation compliance to those rules is nearly nonexistent.

In fact (barring some tokenizer issues that are still being discussed), there is no concept of "error" due to the idea that all CSS should be parsed forward-compatibly; there is only CSS from versions of CSS that you don't implement; such CSS should be skipped over in a very specific way.