swa66 - 2:24 pm on Jul 9, 2009 (gmt 0)

I was indeed assuming a browser crafter to implement CSS3 modules as a whole, but there is indeed lots of evidence to the contrary. So I guess I gave them too much credibility.

However, since it is not known if the comma may acquire other meanings in future versions of CSS, the whole statement should be ignored if there is an error anywhere in the selector IMO, I don't think this statement has any real meaning to it anymore. Although commas are used in other areas of CSS, I can't see the meaning of a comma change in a selector, at least.

Agree, the too far looking ahead attitude is going to cause loads of trouble in expanding selectors instead of removing trouble. But it's a done deal I'm afraid we cant roll back the implemented standard out there in the field ...

Anyway it should get fixed that CSS3 selectors that are beyond what is in the CSS selectors module are goign to be accepted syntax-wise by all CSS3 parsers, even if they don't implement the pseudo class or the pseudo element yet, even for unknown future classes and elements. At least they could allow all letters, dashes, digits in a name and allow those as room to expand without letting them have special chracters (so you could add ::acrobatic-jump, but not ::acro[flight]

In the end for the person writing CSS3, it's going to become irrelevant in what level of CSS that selector became available, and if there are implementations out there that lack this one, with the potential to trigger it all into what a retarded implementation thinks is a syntax error and unexpectedly drop the parts it would normally.

Anyway as is this is a nightmare.