jameshopkins - 6:35 pm on Jul 12, 2009 (gmt 0)

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 ...

With regards to feature adoption, there's a difference between rolling back, and extending the scope of that feature.

I think it's entirely feasible that a browser could parse but not apply simple selectors that it doesn't understand. Whether or not vendors would actually be happy about adopting this logic - since doing so, would imply successful application of those simple selectors as well as parsing - is another story altogether, as it would go against the current spec. If I have time I might have a go at coming up with a short proposal and seeing what www-style have to say about it.

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]

I don't agree that a completely free reign should be given to vendors in terms of selector parsing; instead they should restrict parsing to selectors defined in the spec. Vendors are free to implement their own features anyway, whether that be selectors, properties, media query descriptors, etc. If Webkit wanted to implement the 'acrobatic-jump' pseudo element like you suggested, they could prepend it with the '-webkit-' prefix and create their own proprietary implementation. Of course, grouping one of these vendor-specific selectors with a currently parsable selector would mean the whole declaration is dropped - I don't think this behaviour should be changed.

too am thinking like that, but there is the potential already to use commas in other places in selectors...

I suggest that in any area where a grouping selector is used, the same proposed rules apply.

whatever, please MS just put it back, we're prepared to use script so we can wait for you to catch up with CSS3 enhancements, but don't ruin it again please!

This isn't just an IE problem. Breaking out of recognised coventions isn't the answer here. This proposal needs to be discussed at a level where all vendors can participate in the dialogue so that we can reach a resolution. In the mean time, I'll try and discuss this directly with Microsoft when I get a chance to, as I personally think it's unlikely they'll implement the full Level 3 Selector module.

I don't know how the JS workaround works as I've never liked the idea, but I'd suggest it incorporates the same selector parsing rules as specified by the W3C, so I don't see how this can be a solution.