Robin Berjon wrote:
I don't think we need to cram as many features as possible into v1.
Defining the exact semantics of scoped CSS selectors can be a little
tricky, and it clearly is the job of the CSS WG to do so. The WG thinks
Tricky. Ah. When it comes to defining how matchSingle() and matchAll()
work, I fail to see how, sorry. You don't have to worry about
specificity, cascade or precedence because Selectors API do not deal
with it!
A stylesheet applies to a subtree, that subtree being the whole
document. A scoped stylesheet applies to a deeper subtree, that's all.
The one and only issue is the :root matching, and it makes perfect
sense here to say it matches the root of the subtree because there
is no other root element in this context ! The other option, ie match
the root of the document, is pure non-sense... In the scope, that
element is just not visible.
that it's simpler and safer to restrict ourselves to Document at first,
and extend to Element (or Node) later, rather than do the latter now and
find out later that it introduces issues with what the CSS WG intends to
do in the area.
I thought your WG was more "disruptive" than that :-)
More seriously, I really think this WD does not push far enough.
The cost is little. Your WG and the CSS WG could probably solve this
quickly.
4. I really hate having two different methods for matchSingle and
matchAll, and I'd prefer a single method with a boolean indicating
if only the first result should be retrieved or all.
I think that's largely a matter of taste, isn't it?
No. That's a matter of consistency. Having similar methods both
performing a search, the result of the first one being a subset
of the second one, reply similar constructs is a matter of
consistency.
</Daniel>
