Hi, folks-
Since the Selectors API is so closely tied to CSS Selectors, which may
affect implementations and the development of the CSS specs, I would
suggest that there be a closer working relationship between the editors
of Selectors API and the CSS WG. It's a bad sign of coordination to see
emails from people on the CSS WG who are unpleasantly surprised by
developments in the Selectors API spec. This requires more than the
usual inter-group review.
Please let me know how I can help facilitate this.
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Daniel Glazman wrote (on 1/20/10 2:50 AM):
Hi there.
(this message contains personal comments and does not represent an
official response from the CSS WG)
I have read the recent Selectors API Level 2 draft [1] and have a few
important comments to make:
1. I don't like the idea of refNodes. I think having the APIs specified
at Element level makes it confusing. I would recommend applying the
NodeSelector interface to NodeList instead. If queryScopedSelector()
and queryScopedSelectorAll() are applied to an Element or a NodeList,
the corresponding element(s) are the refNodes of the query.
Same comment for matchesSelector().
2. I am extremely puzzled by the parsing model of scoped selectors. In
particular, I think that the :scope pseudo-class introduces things
that go far beyond scoping. Let's consider the selector ":scope+p".
Clearly, it's _not_ scoped since it queries element that are outside
of the subtree the context element is the root of. Furthermore, these
elements can be queried without scopes, and I don't see why this is
needed at all!!!
I would recommend dropping the pseudo-class :scope and make a simpler
model where a fictional :scope pseudo-class and a descendant
combinator are prepended to all selectors passed as the argument of
the corresponding APIs.
I don't like the idea that implementors will have to check if the
first sequence of simple selectors in a selector contains or does
not contain a given pseudo-class to prepend something to the context.
This is clearly the kind of things I think we should avoid in
Selectors in general.
3. the section about :scope does not include error handling. What
happens if multiple :scope are present?
4. what's the specificity of that pseudo? Since it's proposed as a
regular and non-fictional pseudo, web authors _can_ use it in
regular stylesheets, even if it's meaningless outside of a scoped
stylesheet. What's the behaviour in that case? What's the
specificity?
[1] http://www.w3.org/TR/selectors-api2/
</Daniel>
--
W3C CSS WG, Co-chair
