Re: Supporting Scoped Selectors in Selectors API 2

Lachlan Hunt wrote:
> fantasai wrote:
>> Or, you could not allow any shortcuts here and require :reference (or
>> :scope, as Tab recommends, and I second) to be inserted explicitly in
>> such cases. I would imagine they're less common than the descendant case.
> 
> Are you now suggesting ...

I'm not going to bother answering this. You've come up with the solution
in your other email anyway.

>> Sorry, I don't understand this. Why do you need separate methods for
>> namespaced versions? (What does it mean, a namespaced version of
>> querySelector?)
> 
> Selectors leave the issue of namespace resolution to an external 
> mechanism.  In CSS, this is @namespace.  In XBL2, xmlns declarations are 
> used.  In the API, there needs to be some other mechanism available to 
> to resolve the prefixes used in the selectors.  Using seprate NS methods 
> that accept an extra namespsace resolver as an argument would be 
> somewhat in line with how other *NS() methods in the DOM work.

Why not just pass an extra argument to querySelector()?

>> This is worse than a boolean flag. How is this not worse than a boolean
>> flag?
> 
> As I said, the boolean flag parameter provided absolutely no way for 
> scripts to detect whether or not implementations support scoped 
> selectors.  Using the syntactic flag instead at least caused a syntax 
> error to be thrown by existing implementations, allowing scripts to 
> catch it and resort to fallback behaviour.

Maybe you can't do this, but if you put the flag first then that will
trigger an exception in existing implementations.
(Not that I'm particularly in favor of this solution in any case.)

> Because, as I explained previously, the flag to enable this behaviour 
> needs to be distinct from the pseudo-class itself to avoid even more 
> complexity.

What kind of complexity? Implementation complexity, or API usage complexity?

~fantasai

Received on Tuesday, 29 September 2009 18:05:44 UTC