Bjoern Hoehrmann wrote:
> * Lachlan Hunt wrote:
>>> If we do this, we should say that selectors are evaluated in a context,
>>> and that the context optionally consists of (among things like default
>>> namespace and namespace bindings) an element called the context element
>>> and the context element and only the context element matches :context.
>> Yes, that is basically how it works. Note that :context does not
>> necessary match the context node, as defined in the proposal. Rather,
>> it matches a specific element node that is determined based upon what
>> the context node is.
>
> I am saying you should identify the context element directly, rather
> than say the object you call querySelector on is the "context node".
When I first drafted it, I did try to do something like that. But the
problem is that for selecors api, the context element needs to be
determined based upon which node the methods are invoked on, and for
scoped stylesheets, it's the parent of the style element. I failed to
find any other way to define it clearly enough that would work for each
case. If you could more clearly explain how else I can do it, that
would help a lot.
>> The methods in Selectors API are defined to apply to Document,
>> DocumentFragment and Element nodes. So, defining behaviour for at least
>> those cases is essential. Defining behaviour in the case of all other
>> nodes is just making sure there's no holes left behind.
>
> So define that there is no context element for DocumentFragments.
> There are so many ways, current and future, to do this, there is no
> need to be able to do this with the CSS Query API.
In that case, unless there are really compelling use cases raised to
keep it, I'm willing to drop it. However, even if there are, I guess it
would be reasonable to look for other solutions first.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/http://www.opera.com/