Sean Hogan wrote:
On 8/01/10 1:19 AM, Lachlan Hunt wrote:
can we publish Selectors API Level 2 as an FPWD?
http://dev.w3.org/2006/webapi/selectors-api2/
FYI, it seems the whole Status of this Document hasn't been updated for
Selectors-API2.
Yeah, that will get fixed up when I get the spec ready for publication
and do all the PubRules checks, etc.
Also, the links to the W3C CVS are for Selectors-API, not Selectors-API2.
Likewise.
I can't see the value of queryScopedSelector*() methods. The original
rationale was that JS libs could potentially drop their selector
engines, but this isn't facilitated by the proposed methods. Given that
JS libs will still have to parse the selectors it is a trivial step to call
querySelector*(rewrittenSelector, refNode)
rather than
queryScopedSelector*(rewrittenSelector)
Personally, I agree and was initially hesitant about adding it, but
there were some reasonable arguments put forth suggesting that lifting
the burden of pre-processing the selector to prepend :scope from JS libs
would be useful [1]. Evidence to the contrary would be helpful. John
Resig also once told me he had an alternative proposal, but he hasn't
yet shared it with me.
The queryScopedSelector*() methods have misleading names - they don't
match the definition of scope.
It would be ridiculous to stick with those names if there are no
implementations already out there.
Do you have a better alternative suggestion?
Similarly, the :scope pseudo-class has a misleading name.
I've tried various alternative names, like :context, :reference, etc.,
but so far scope seems to be the least objectionable. But all things
considered, I don't think :scope is a particularly bad name, since it's
name somewhat describes it's purpose and relates it to its utility in
scoped stylesheets.
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
