W3C home > Mailing lists > Public > www-style@w3.org > January 2010

Re: [selectors-api] comments on Selectors API Level 2

From: Doug Schepers <schepers@w3.org>
Date: Wed, 20 Jan 2010 11:32:41 -0500
Message-ID: <4B573029.3080306@w3.org>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
CC: public-webapps@w3.org, "www-style@w3.org" <www-style@w3.org>
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.

-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
Received on Wednesday, 20 January 2010 16:32:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:42 UTC