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/