jameshopkins - 12:56 pm on Jul 13, 2009 (gmt 0)

This isn't just an IE problem. Breaking out of recognised coventions isn't the answer here It is an IE only problem, no other browser is "not recognising" advanced selectors whether they support them or not...

I'm unsure as to what you mean. As we concluded earlier on in the discussion when we discussed grouping selectors, if a browser comes across a selector that it can't parse (whether it be invalid or unknown), the subsequent declaration block is dropped. If the opposite were true - like it sounds as though you might be stating - it would be a clear violation of established parsing rules. If instead you're referring to the substitutional parsing of an older generation selector of the same type, there is no difference; the selector that hasn't been implemented still won't be parsed. Selector parsing rules and providing an older version of that selector as a fallback, are two completely different things.

... and it not breaking out, it's breaking back into, regressing to their previous support which will just happen to aid the transition should they ever get around to any CSS3 support

Which selector are you suggesting falls back "to their previous support"?

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. You might never have liked them, but without them CSS wouldn't have been free to get this far, it's thanks in no small part to those Dean Edward scripts that we were able to force IE's turnaround

In my previous post, I specifically mention "JS workarounds", in the context of discussing workarounds that bring inferior browsers up to a superior level of support (be it, in an emulated sense). However, a distinction needs to be made between a JS framework that patches up broken CSS implementations (Dean Edwards' scripts), and scripts that provide both authors and implementors a chance to preview forthcoming CSS features, by emulating those specs. The latter is a superb idea; not only does it give authors a chance to test out forthcoming features, but it can also highlight spec ambiguities [lists.w3.org] which can then be fed back to implementors, as Alex Deveria's recent emulation of the Template Layout module [a.deveria.com] showed. I can give several reasons why I don't like those implementation-patching scripts, but this thread isn't the right place to do that in, I don't feel.

The scripts don't always use W3C standards, at least not in the CSS1, 2, 3 sense, when it comes to selector parsing "rules" but like forward thinking browsers they pave the way and give us the opportunity to try and use more advanced CSS. That's exactly why they are the solution.

IMHO, I don't believe they are the solution. As I mentioned before I think they're great at giving authors a preview of forthcoming yet-to-be-implemented features, but I feel every day adoption of those emulation methods are the wrong way to go about things. I guess we have to agree to disagree.

It's been known for an absolute age that early adoption and usage of future CSS is the key to proving a selector, or property's worth and aids in the writing or even rewriting of a specification. How could we use them consistently x-browser without these scripts?

The simple answer is we can't use them cross browser without the scripts. But why would we want to test the actual browser implementations of a yet-to-be-implemented feature cross browser, if we're only concerned with testing out the fundamental functionality of that feature?