[selectors-api] typo in specification

2016-06-18 Thread Kirill Topolyan
Hello.

At the moment I'm translating "Selectors API Level 1" [1] and it seems I have 
noticed a typo in the original document.

[1] https://www.w3.org/TR/selectors-api/

Section 6.4:
"If result is invalid ([SELECT], section 12), raisea a SYNTAX_ERR exception 
([DOM-LEVEL-3-CORE], section 1.4) and abort this algorithm."

Probably it meant "raise a SYNTAX_ERR" instead "raisea a SYNTAX_ERR"?

Best regards,
Kirill, http://topolyan.com/




[selectors-api] How to mark TR version as obsolete/superseded? [Was: Re: Obsolete Document]

2015-04-28 Thread Arthur Barstow

On 3/26/15 8:30 AM, Gulfaraz Yasin wrote:

Hi

It has come to my notice that the following document

http://www.w3.org/TR/selectors-api/#resolving-namespaces

is obsolete.


Hi Gulfaraz,

Thanks for your e-mail and sorry for the slow reply.


I was directed to it's page from one of StackOverflow's answers and 
after following up a bit I've been informed that the above document is 
obsolete.



Yes, this is true.


It would be very helpful if there was a notice on the page that 
informed it's visitors of the same.



Yes, I agree. I think the principle of least surprise implies the 
document at w3.org/TR/selectors-api/ should be gutted of all technical 
content and a reference to the DOM spec [DOM] (which supersede Selectors 
API) should be added (as well as a clear statement work on selectors-api 
has stopped and its features/APIs are superseded by [DOM]). However, I 
suspect the consortium's publication processes might not permit that.


Xiaoqian, Yves - can we do as I suggest above? If not, what is your 
recommendation re making sure people understand work on selectors-api 
has stopped and it is superseded by [DOM]?


-Thanks, AB

[DOM] http://www.w3.org/TR/dom/





CfC: publish Selectors API Level 2 as WG Note; deadline October 11

2013-10-04 Thread Arthur Barstow

As discussed previously (e.g. [1]), this is a Call for Consensus to:

1. Publish Selectors API Level 2 as WG Note

2. Stop work on that spec with an understanding this spec's features 
will be included in the HTMLWG's version of DOM4


If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by October 11 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


-Thanks, AB

[1] 
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0045.html






Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-03 Thread Jirka Kosek
On 2.7.2013 2:53, Daniel Glazman wrote:

 a. it's not possible, even in Selectors API 2 [5], to resolve arbitrary
namespaces in querySelectorAll()

In general this might be problem, but for ITS I don't see this as a
problem. People who use ITS with non-HTML content (various flavours of
XML) will use XPath as a query language. Selectors will be likely used
only in combination with HTML content where you don't need namespaces
(of course, unless you want to target specific elements inside embedded
SVG/MathML).

 b. Selectors cannot target attributes

Indeed, this is very serious limitation of CSS selectors and we even
discussed removing CSS selectors completely from ITS because of this.
But at the end prevailing opinion was that CSS selectors will be useful
for scenarios where there is no need to care about attributes. But
without ability so select attributes some users will be forced to switch
to XPath instead of CSS selectors.

Jirka

-- 
--
  Jirka Kosek  e-mail: ji...@kosek.cz  http://xmlguru.cz
--
   Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
--
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
--
Bringing you XML Prague conferencehttp://xmlprague.cz
--



signature.asc
Description: OpenPGP digital signature


Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-02 Thread Daniel Glazman

On 02/07/13 04:46, Tab Atkins Jr. wrote:


That's already the case - the subject indicator has to precede the
compound selector.


Tab, I know, *I* designed the subject indicator *exactly* the way it
is in the spec back in *1997* in a language called STTS and an
application implementing it...

I meant !foo![attr] is forbidden.


This is unacceptable for Selectors applied against HTML in general.
Attributes are *not* nodes, either in HTML or XML, and ![foo] refers
to an element.


Unacceptable to you. And pseudo-elements can be selected by CSS without
having any existence as Nodes in the document tree...

![foo] refers to an element *for the time being* in a Draft. A
Standard is not a Standard before it's published as a Standard. And
Selectors are a selecting mechanism, the CSS case being one particular
case only. ITS proves Selectors are used outside of the CSS world.

The question is the following one: do we want Selectors to become a more
generic mechanism approaching, and possibly eventually replacing, the
power of XPath? If I look at all the additions to Selectors lev4, the
answer is obviously yes. And if you ask me, yes, we should make CSS
a selecting mechanism widely usable in full replacement of XPath.
FWIW, please see the section on STTS in Håkon's thesis and its ACK
section.


I am strongly against Selectors returning different results when used
in CSS versus qSA/find.


I never said that. I said a p![foo] would select an attribute in both
querySelectorAll() and CSS, but it would not trigger any style in CSS.
We already have similar mechanisms in CSS, with restricted sets of
properties applicable to pseudo-elements.


If you want Selectors to be able to select attribute nodes, address it
directly with a new selector.  This should not be smuggled in via the
subject indicator.


That would be a new char or ident or whatever serving exactly the
purpose of !... But why not. I want the feature, and I'm not focused
on !.

The meta-question still stands: how do we serve better W3C
specifications like ITS 2.0?

On 02/07/13 05:26, Liam R E Quin wrote:


A rigorous comparison of XPath with CSS selectors would be worth doing;
piecemeal attempts to duplicate functionality don't seem worthwhile to
me. On the other hand I do agree that it sounds like some limitation in
CSS selector namespace handling could be alleviated.


Exactly.

/Daniel




Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-02 Thread Tab Atkins Jr.
On Mon, Jul 1, 2013 at 11:53 PM, Daniel Glazman
daniel.glaz...@disruptive-innovations.com wrote:
 On 02/07/13 04:46, Tab Atkins Jr. wrote:
 That's already the case - the subject indicator has to precede the
 compound selector.

 Tab, I know, *I* designed the subject indicator *exactly* the way it
 is in the spec back in *1997* in a language called STTS and an
 application implementing it...

 I meant !foo![attr] is forbidden.

Yes, I was just saying that that is already forbidden.

 This is unacceptable for Selectors applied against HTML in general.
 Attributes are *not* nodes, either in HTML or XML, and ![foo] refers
 to an element.

 Unacceptable to you. And pseudo-elements can be selected by CSS without
 having any existence as Nodes in the document tree...

Pseudo-elements do exist in the document tree as far as layout is
concerned.  Selectors can indeed augment the tree.

 ![foo] refers to an element *for the time being* in a Draft. A
 Standard is not a Standard before it's published as a Standard. And
 Selectors are a selecting mechanism, the CSS case being one particular
 case only. ITS proves Selectors are used outside of the CSS world.

No, [foo] refers to an element, period, in Selectors all the way
back to 2.1 or earlier, and [foo] and *[foo] match exactly the
same elements.  The subject indicator doesn't change the meaning of
anything, just which element is finally selected.  Thus, ![foo]
matches the same thing as !*[foo].  (And *![foo] is illegal, but
even if we allowed it for some reason, it would still be the same as
!*[foo].)

 The question is the following one: do we want Selectors to become a more
 generic mechanism approaching, and possibly eventually replacing, the
 power of XPath? If I look at all the additions to Selectors lev4, the
 answer is obviously yes. And if you ask me, yes, we should make CSS
 a selecting mechanism widely usable in full replacement of XPath.
 FWIW, please see the section on STTS in Håkon's thesis and its ACK
 section.

I'm not saying we shouldn't.  Just that you shouldn't do it by
smuggling in the functionality via two unrelated things.  You should
introduce something that actually selects an attribute.

(Though, some of the things that XPath does don't agree well with
Selector's data model, and vice versa.  Achieving a full superset
would be rather difficult.)

 I am strongly against Selectors returning different results when used
 in CSS versus qSA/find.

 I never said that. I said a p![foo] would select an attribute in both
 querySelectorAll() and CSS, but it would not trigger any style in CSS.
 We already have similar mechanisms in CSS, with restricted sets of
 properties applicable to pseudo-elements.

I'm not necessarily against the concept of selecting attributes; I'm
arguing against your attempted abuse of syntax.  ^_^

~TJ



Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-02 Thread Daniel Glazman

On 02/07/13 09:16, Tab Atkins Jr. wrote:


Pseudo-elements do exist in the document tree as far as layout is
concerned.


No, they do not. They don't create new nodes (yet), even shadow nodes,
they can't be serialized. They belong to the layout tree, NOT the
document tree.


Selectors can indeed augment the tree.


Absolutely not, and that's precisely why we called pseudo-elements
pseudo. But that's another discussion


I'm not necessarily against the concept of selecting attributes; I'm
arguing against your attempted abuse of syntax.  ^_^


I don't think it's an abuse at all. But I see your point better now.
I still think we need to extend Selectors to attribute selection and
Selectors API to namespace resolution.

/Daniel



Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-02 Thread Tab Atkins Jr.
On Tue, Jul 2, 2013 at 12:57 AM, Daniel Glazman
daniel.glaz...@disruptive-innovations.com wrote:
 On 02/07/13 09:16, Tab Atkins Jr. wrote:
 Pseudo-elements do exist in the document tree as far as layout is
 concerned.

 No, they do not. They don't create new nodes (yet), even shadow nodes,
 they can't be serialized. They belong to the layout tree, NOT the
 document tree.

As I said in the section you quoted, *as far as layout is concerned*,
pseudo-elements exist.  I didn't say anything about creating DOM,
affecting stringification, etc.

~TJ



ITS 2.0, Selectors 4 and Selectors API 2

2013-07-01 Thread Daniel Glazman

ITS 2.0 (the Internationalization Tag Set  2.0) [1] is a specification
attaching l10n/i18n properties to elements and attributes of a document
tree through two means:

  1. locally, using attributes in the ITS namespace

  2. globally, using rules expressed in XML in the ITS namespace and
 based on a selecting mechanism (XPath, CSS, ...)

Here are two examples of the above:

locally:

span xmlns:its=http://www.w3.org/2005/11/its;
  its:translate=noNASA/span

globally:

 rules xmlns=http://www.w3.org/2005/11/its;
version=2.0
queryLanguage=css
   translateRule selector=//html:acronym
  translate=xpath
  xmlns:html=http://www.w3.org/1999/xhtml/
 /rules

In the global case, the selecting language of the rule can be chosen
through the @queryLanguage attribute on the rules element. CSS
Selectors are explicitely listed [2] as a valid selecting mechanism and
it would be really nice to see CSS used there. Unfortunately, Selectors
[3] and its Selectors API [4] companion have two problems that are more
or less blockers for Selectors inside ITS 2.0:

a. it's not possible, even in Selectors API 2 [5], to resolve arbitrary
   namespaces in querySelectorAll()

b. Selectors cannot target attributes

In the case of querySelectorAll(), we clearly need to extend Selectors
API to allow namespaces. We had little use cases in the past but that's
not true any more. And it's totally false to say we need this for html
only. A spec like ITS 2.0 will be in most cases not implemented natively
but above abstractions like document.evaluate() or querySelectorAll().
We clearly need namespace resolvers like [6] in Selectors API.

In the case of attributes not reachable through Selectors, we may have
almost everything we need in Selectors level 4 to provide a user like
ITS 2.0 with a solution: the subject indicator [7] could be easily
extended the following way:

  1. only one subject indicator is allowed per compound selector

  2. the subject indicator can precede a universal selector (potentially
 omitted), a type element selector or an attribute selector. In the
 case of an attribute selector, the selector represents then the
 attribute node matching the condition expressed by the attribute
 selector. Note: all @foo attributes of the document is not ![foo]
 - that means !*[foo] - but *![foo]

  3. both Selectors and Selectors API should allow such attribute
 matching, but CSS rules with such attribute matching would of
 course not trigger any style resolution. querySelectorAll() and
 friends should be extended to return attribute nodes. The case
 of a group of selectors where one of the selectors uses a subject
 indicator to match attributes has to be discussed but I think it's
 doable.

The above would allow to express any ITS rule not only using Selectors
but also in the future in a CSS-alike syntax. Then instead of:

 rules xmlns=http://www.w3.org/2005/11/its;
version=2.0
queryLanguage=css
   translateRule selector=html|acronym![title]
  translate=css
  xmlns:html=http://www.w3.org/1999/xhtml/
 /rules

we could have the readability of:

 @namespace html url(http://www.w3.org/1999/xhtml;);
 html|acronym![title] { its-translate: no; }

and have it merged with CSS, use the power of the cascade, etc instead
of having to rely on... ahem... XPath. We could solve two problems of
ours at the same time: *finally* extend Selectors to attribute nodes
and fix that painful hole of Selectors API not working with namespaces.

[1] http://www.w3.org/TR/its20/
[2] http://www.w3.org/TR/its20/#css-selectors
[3] http://www.w3.org/TR/2011/REC-css3-selectors-20110929/
[4] http://www.w3.org/TR/2013/REC-selectors-api-20130221/
[5] http://www.w3.org/TR/selectors-api2/
[6] http://is.gd/HVrWM5
[7] http://dev.w3.org/csswg/selectors4/#subject

/Daniel



Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-01 Thread Daniel Glazman

On 02/07/13 02:53, Daniel Glazman wrote:


  rules xmlns=http://www.w3.org/2005/11/its;
 version=2.0
 queryLanguage=css
translateRule selector=//html:acronym
   translate=xpath
   xmlns:html=http://www.w3.org/1999/xhtml/
  /rules


Sorry, the above is obviously wrong, please read

 rules xmlns=http://www.w3.org/2005/11/its;
version=2.0
queryLanguage=xpath
   translateRule selector=//html:acronym
  translate=no
  xmlns:html=http://www.w3.org/1999/xhtml/
 /rules

instead. Thanks.

/Daniel




Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-01 Thread Tab Atkins Jr.
On Mon, Jul 1, 2013 at 5:53 PM, Daniel Glazman
daniel.glaz...@disruptive-innovations.com wrote:
   1. only one subject indicator is allowed per compound selector

That's already the case - the subject indicator has to precede the
compound selector.

   2. the subject indicator can precede a universal selector (potentially
  omitted), a type element selector or an attribute selector. In the
  case of an attribute selector, the selector represents then the
  attribute node matching the condition expressed by the attribute
  selector. Note: all @foo attributes of the document is not ![foo]
  - that means !*[foo] - but *![foo]

This is unacceptable for Selectors applied against HTML in general.
Attributes are *not* nodes, either in HTML or XML, and ![foo] refers
to an element.

Against an arbitrary document language where attributes are translated
into a tree in a different manner, it would work.

   3. both Selectors and Selectors API should allow such attribute
  matching, but CSS rules with such attribute matching would of
  course not trigger any style resolution. querySelectorAll() and
  friends should be extended to return attribute nodes. The case
  of a group of selectors where one of the selectors uses a subject
  indicator to match attributes has to be discussed but I think it's
  doable.

I am strongly against Selectors returning different results when used
in CSS versus qSA/find.

If you want Selectors to be able to select attribute nodes, address it
directly with a new selector.  This should not be smuggled in via the
subject indicator.

~TJ



Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-01 Thread Liam R E Quin
On Mon, 2013-07-01 at 19:46 -0700, Tab Atkins Jr. wrote:
[...]
 If you want Selectors to be able to select attribute nodes, address it
 directly with a new selector.  This should not be smuggled in via the
 subject indicator.

Maybe it would be simpler to support an XPath() selector?

When you start using ITS you'll find other cases that get difficult with
existing CSS selectors, e.g.
  . partShortDescription elements whose id attribute value appears in
the list of id attributes in the includes attribute of a partsDiagram
element in the same section, and where that diagram has a
language=only attribute on the replacementCopies element, and the
diagram issue year is earlier than 1996.

This sort of thing is fairly frequently written with XPath selectors
today, and is a plausible use case (e.g. the older exploded parts
diagram is only available in spanish, includes Spanish labels for the
parts that readers will have to match up to a table of part numbers, so
they need the same text in the diagram and in the table).

A rigorous comparison of XPath with CSS selectors would be worth doing;
piecemeal attempts to duplicate functionality don't seem worthwhile to
me. On the other hand I do agree that it sounds like some limitation in
CSS selector namespace handling could be alleviated.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml




Re: [selectors-api] QSA and findAll definitions

2013-06-10 Thread Tab Atkins Jr.
On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 6/9/13 7:35 PM, Timmy Willison wrote:
 I was a little confused. I realized something I already knew in that
 elem.querySelector[All] does limit the matched set to the descendants of
 element

 Right. But find() does not, for what it's worth, depending on the exact
 selector used.  It can return sublings of the context object, for example,
 as far as I can tell.  Hence the wording difference.

Specifically, el.find('+ div'); will work, and find the sibling
div to the context element.  el.querySelector(':scope + div');
will *not* work, because the results are first filtered to be only
descendants of the context element.

The wording is slightly confusing now, but in Selectors 4 terminology,
selectors in find() are *relative*, but not *scoped*.  Selectors in
qSA() are scope-filtered.  (They may also be relative - it's been a
while since I read the spec, so I don't remember.)

~TJ



Re: [selectors-api] QSA and findAll definitions

2013-06-10 Thread Timmy Willison
Thank you both. That helps a lot. I figured el.querySelector(:scope +
div) would do the same thing as el.find(+ div).

Perhaps more examples in the spec that clearly demonstrate differences like
this between qSA() and findAll() would be helpful. I think some form of the
example that Tab gave would be a great addition.

Also, maybe we can clarify even further in the defintions for find() and
findAll(). Perhaps, rather than,

... from the tree within which the context object is located.

It could be,

... within the subtrees of the parent of the context object or the tree in
which the context object is located if there is no parent.

Compare this with qS[A]:

... within the subtrees of the context object.

This is an attempt to make it clear that ancestors of the context object
will never be in the resulting set and need not be considered in
implementations. In other words, it seems to me that elem.find() will never
return ancestors of elem.


On Mon, Jun 10, 2013 at 10:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky bzbar...@mit.edu wrote:
  On 6/9/13 7:35 PM, Timmy Willison wrote:
  I was a little confused. I realized something I already knew in that
  elem.querySelector[All] does limit the matched set to the descendants of
  element
 
  Right. But find() does not, for what it's worth, depending on the exact
  selector used.  It can return sublings of the context object, for
 example,
  as far as I can tell.  Hence the wording difference.

 Specifically, el.find('+ div'); will work, and find the sibling
 div to the context element.  el.querySelector(':scope + div');
 will *not* work, because the results are first filtered to be only
 descendants of the context element.

 The wording is slightly confusing now, but in Selectors 4 terminology,
 selectors in find() are *relative*, but not *scoped*.  Selectors in
 qSA() are scope-filtered.  (They may also be relative - it's been a
 while since I read the spec, so I don't remember.)

 ~TJ




Re: [selectors-api] QSA and findAll definitions

2013-06-10 Thread Tab Atkins Jr.
On Mon, Jun 10, 2013 at 1:15 PM, Timmy Willison timmywill...@gmail.com wrote:
 Thank you both. That helps a lot. I figured el.querySelector(:scope + div)
 would do the same thing as el.find(+ div).

 Perhaps more examples in the spec that clearly demonstrate differences like
 this between qSA() and findAll() would be helpful. I think some form of the
 example that Tab gave would be a great addition.

 Also, maybe we can clarify even further in the defintions for find() and
 findAll(). Perhaps, rather than,

 ... from the tree within which the context object is located.

 It could be,

 ... within the subtrees of the parent of the context object or the tree in
 which the context object is located if there is no parent.

 Compare this with qS[A]:

 ... within the subtrees of the context object.

 This is an attempt to make it clear that ancestors of the context object
 will never be in the resulting set and need not be considered in
 implementations. In other words, it seems to me that elem.find() will never
 return ancestors of elem.

It certainly can return ancestors.  You just need the right
combinators.  The reference combinator defined in Selectors 4
http://dev.w3.org/csswg/selectors/#idref-combinators can move
anywhere in the tree, including straight upwards.  The use of the
subject indicator, also defined in Selectors 4
http://dev.w3.org/csswg/selectors/#subject, can also move up the
tree.

Just throw away your notion that .find() does any scoping whatsoever.
It doesn't; all it does is provide a reference element, which is
matched by :scope and which is used to absolutize relative selectors.

~TJ



Re: [selectors-api] QSA and findAll definitions

2013-06-10 Thread Timmy Willison
On Mon, Jun 10, 2013 at 4:47 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:


 Just throw away your notion that .find() does any scoping whatsoever.


Ok, will do.


 It doesn't; all it does is provide a reference element, which is
 matched by :scope and which is used to absolutize relative selectors.

 ~TJ



[selectors-api] QSA and findAll definitions

2013-06-09 Thread Timmy
The wording of the QSA and findAll definitions are a bit confusing to me. 
Forgive me if I'm misunderstanding, but the definitions for querySelector[All] 
and find[All] seem to be partly reversed.

First, the definition of subtrees seems clear enough:
The term subtrees refers to the set of elements that are descendants of the 
specified context object.

However, the definition for querySelector currently states: return the first 
matching Element node within the subtrees of the context object. Isn't that 
the definition for find? Element#querySelector does not limit matching to 
subtrees of the context object. `elem.querySelector(div)` will return all 
divs on the page, not just descendants of `elem`. I assume this was not meant 
to be changed here.

find states: return the first matching Element node from the tree within which 
the context object is located. This sounds just like what querySelector is 
supposed to do. Element#querySelector returns results based off of the tree in 
which the element is located.

Thanks,

- Timmy





Re: [selectors-api] QSA and findAll definitions

2013-06-09 Thread Timmy Willison
I was a little confused. I realized something I already knew in that 
elem.querySelector[All] does limit the matched set to the descendants of 
element, but the selector itself is not relative. Sorry about that. 


​I guess my only question now is what is the difference between the way 
.find[All] and .querySelector[All] relate to the context object? Why the 
wording difference?


Thanks again, 


- Timmy

On Sun, Jun 9, 2013 at 5:34 PM, Timmy timmywill...@gmail.com wrote:

 The wording of the QSA and findAll definitions are a bit confusing to me. 
 Forgive me if I'm misunderstanding, but the definitions for 
 querySelector[All] and find[All] seem to be partly reversed.
 First, the definition of subtrees seems clear enough:
 The term subtrees refers to the set of elements that are descendants of the 
 specified context object.
 However, the definition for querySelector currently states: return the first 
 matching Element node within the subtrees of the context object. Isn't that 
 the definition for find? Element#querySelector does not limit matching to 
 subtrees of the context object. `elem.querySelector(div)` will return all 
 divs on the page, not just descendants of `elem`. I assume this was not meant 
 to be changed here.
 find states: return the first matching Element node from the tree within 
 which the context object is located. This sounds just like what 
 querySelector is supposed to do. Element#querySelector returns results based 
 off of the tree in which the element is located.
 Thanks,
 - Timmy

Re: [selectors-api] QSA and findAll definitions

2013-06-09 Thread Boris Zbarsky

On 6/9/13 7:35 PM, Timmy Willison wrote:

I was a little confused. I realized something I already knew in that
elem.querySelector[All] does limit the matched set to the descendants of
element


Right. But find() does not, for what it's worth, depending on the exact 
selector used.  It can return sublings of the context object, for 
example, as far as I can tell.  Hence the wording difference.


-Boris



[selectors-api2] Seeking implementation data re Selectors API Level 2

2013-04-30 Thread Arthur Barstow

Hi Lachlan,

During WebApps' f2f meeting last week, someone asked [Mins] about the 
implementation status of Selectors API Level 2. Do you have any 
implementation data re selectors-api2 you can share with us?


-Thanks, AB

[Mins] http://www.w3.org/2013/04/25-webapps-minutes.html#item03

 Original Message 
Subject: 	ACTION-680: Ask Lachlan if he has some impl data re Selectors 
API v2 (Web Applications Working Group)

Date:   Thu, 25 Apr 2013 17:04:04 +
From: 	ext Web Applications Working Group Issue Tracker 
sysbot+trac...@w3.org

Reply-To:   Web Applications Working Group public-webapps@w3.org
To: art.bars...@nokia.com



ACTION-680: Ask Lachlan if he has some impl data re Selectors API v2 (Web 
Applications Working Group)

http://www.w3.org/2008/webapps/track/actions/680

On: Arthur Barstow
Due: 2013-05-02

If you do not want to be notified on new action items for this group, please 
update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings






[selectors-api] References to Selectors 4

2013-04-03 Thread fantasai

http://www.w3.org/TR/selectors-api2/#the-scope-pseudo-class

This section has already been copied to Selectors 4 (and has been
for awhile, actually), so should be removed here and replaced with
references to Selectors 4.
  http://www.w3.org/TR/selectors4/#the-scope-pseudo

If there's anything that needs to be fixed in Selectors 4 for this
to be viable, then let us know and we'll fix it. :)

http://www.w3.org/TR/selectors-api2/#grammar

Tab just updated the grammar productions in Selectors 4 and defined
some terms, so this section shouldn't need to define anything, just
reference Selectors 4.
  http://dev.w3.org/csswg/selectors4/#grammar

http://www.w3.org/TR/selectors-api2/#processing-selectors

We also added the algorithm for absolutizing a relative selector to
the Selectors 4 spec, so you can reference scope-relative selectors,
as defined here:
  http://dev.w3.org/csswg/selectors4/#scoping

Please let us know if there are any errors.

We'll try to publish a new WD soon with the updated definitions.

~fantasai + TJ



Selectors API Level 1 is a W3C Recommendation

2013-02-21 Thread Arthur Barstow
Congratulations to Lachlan and Anne on the publication of a 
Recommendation for Selectors API Level 1 
http://www.w3.org/TR/2013/REC-selectors-api-20130221/.


Great job guys!

-ArtB




Re: [selectors-api] Matching of :scope in document.querySelector(All)

2012-12-03 Thread Lachlan Hunt
On 2012-11-30 03:01, Boris Zbarsky wrote:
 When implementing :scope support, I discovered that as things stand this
 call:
 
   document.querySelector(:scope)
 
 is specified to return null.  In particular
 http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls
 http://dev.w3.org/2006/webapi/selectors-api2/#determine-contextual-reference-nodes
 which returns an empty set.  Then this empty set is passed as an
 explicit contextual reference set to selector matching in
 http://dev.w3.org/2006/webapi/selectors-api2/#evaluate-a-selector so
 that :scope doesn't match anything.
 
 Is this intentional?

I believe the spec was written the way it was to deal with the case
where an explicitly empty set of reference nodes was given for find()
and findAll().  So it seems the current spec ended up treating these in
the same way by matching nothing:

document.querySelector(:scope)
document.findAll(:scope)

document.findAll(:scope, null)
document.findAll(:scope, [])

 I would have expected the above call to return the documentElement,
 which is what :scope would match in a non-scoped stylesheet...

I can change the spec to make the first 2 examples above match
documentElement, but keep the latter two with explicit refNodes
parameters matching nothing.

-- 
Lachlan Hunt
http://lachy.id.au/
http://www.opera.com/




Re: [selectors-api] Matching of :scope in document.querySelector(All)

2012-12-03 Thread Boris Zbarsky

On 12/3/12 7:33 AM, Lachlan Hunt wrote:

So it seems the current spec ended up treating these in
the same way by matching nothing:

document.querySelector(:scope)
document.findAll(:scope)

document.findAll(:scope, null)
document.findAll(:scope, [])


That's how I read it, yes.


I can change the spec to make the first 2 examples above match
documentElement, but keep the latter two with explicit refNodes
parameters matching nothing.


That sounds great to me.  Thanks!

-Boris




Re: [selectors-api] Matching of :scope in document.querySelector(All)

2012-12-02 Thread Dean Edwards
On 30 November 2012 02:01, Boris Zbarsky bzbar...@mit.edu wrote:
 When implementing :scope support, I discovered that as things stand this
 call:

   document.querySelector(:scope)

 is specified to return null.  In particular
 http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls
 http://dev.w3.org/2006/webapi/selectors-api2/#determine-contextual-reference-nodes
 which returns an empty set.  Then this empty set is passed as an explicit
 contextual reference set to selector matching in
 http://dev.w3.org/2006/webapi/selectors-api2/#evaluate-a-selector so that
 :scope doesn't match anything.

 Is this intentional?  I would have expected the above call to return the
 documentElement, which is what :scope would match in a non-scoped
 stylesheet...


I would expect it to return documentElement too. Webkit's
implementation does this.

-dean




[selectors-api] Matching of :scope in document.querySelector(All)

2012-11-29 Thread Boris Zbarsky
When implementing :scope support, I discovered that as things stand this 
call:


  document.querySelector(:scope)

is specified to return null.  In particular 
http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls 
http://dev.w3.org/2006/webapi/selectors-api2/#determine-contextual-reference-nodes 
which returns an empty set.  Then this empty set is passed as an 
explicit contextual reference set to selector matching in 
http://dev.w3.org/2006/webapi/selectors-api2/#evaluate-a-selector so 
that :scope doesn't match anything.


Is this intentional?  I would have expected the above call to return the 
documentElement, which is what :scope would match in a non-scoped 
stylesheet...


-Boris



Re: CfC: Selectors API Level 1 Test Suite; deadline November 23

2012-11-27 Thread Charles McCathie Nevile
On Fri, 16 Nov 2012 15:48:28 +0400, Arthur Barstow art.bars...@nokia.com  
wrote:


The RfR for the Selectors API Level 1 test suite passed WebApps' testing  
group's review (see below), and according to the agreed  
#Approvalprocess, this now means a group wide review should be done. As  
such, this is a CfC for this test suite:


http://w3c-test.org/webapps/SelectorsAPI/tests/approved/


With no negative feedback, this Call for Consensus passes and we resolve  
to accept the test suite.


for the co-chairs
chaals

If you have any comments, please send to public-webapps by November 23.  
If you review any set of the tests and find no issues, please state that  
as a reply to this RfR (so we can get a sense of who reviewed what).


In the absence of any comments, these tests will be considered Approved.

Note: for all practical purposes, I suspect the set of people that will  
actually review our tests are already subscribed to the testsuite list,  
thus this extra CfC is unlikely to result in additional review. As such,  
if no one beats me to it ;-), I will (separately) start a thread about  
streamlining the testing process a bit (for example remove the separate  
group wide CfC for a test suite and include the test suite review in the  
CfC to move a spec from CR to PR). However, let's please not derail this  
CfC on testing process issues.


-Thanks, AB

#Approval http://www.w3.org/2008/webapps/wiki/Approval


 Original Message 
Subject: 	Re: RfR: Selectors API Level 1 Test Suite - deadline 14  
November

Resent-Date:Thu, 15 Nov 2012 16:18:17 +
Resent-From:public-webapps-testsu...@w3.org
Date:   Thu, 15 Nov 2012 17:17:42 +0100
From:   ext Charles McCathie Nevile cha...@yandex-team.ru
Organization:   Yandex
To: 	public-webapps-testsu...@w3.org, Lachlan Hunt  
lachlan.h...@lachy.id.au, Charles McCathie Nevile  
cha...@yandex-team.ru




On Sun, 11 Nov 2012 16:07:08 +0100, Charles McCathie Nevile
cha...@yandex-team.ru  wrote:


On Wed, 24 Oct 2012 14:28:41 +0200, Lachlan Hunt
lachlan.h...@lachy.id.au  wrote:


This is a request for review of the Selectors API Level 1 test suite.


This is a formal resolution that the test suite has passed the review,  
and

is accepted.

Although the only review we are aware of is Opera's, there are 5 browsers
scoring 97-99% on the tests, and people seem to have checked the tests in
practice.

cheers

Chaals (as co-chair)




--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com



CfC: Selectors API Level 1 Test Suite; deadline November 23

2012-11-16 Thread Arthur Barstow
The RfR for the Selectors API Level 1 test suite passed WebApps' testing 
group's review (see below), and according to the agreed 
#Approvalprocess, this now means a group wide review should be done. As 
such, this is a CfC for this test suite:


http://w3c-test.org/webapps/SelectorsAPI/tests/approved/

If you have any comments, please send to public-webapps by November 23. 
If you review any set of the tests and find no issues, please state that 
as a reply to this RfR (so we can get a sense of who reviewed what).


In the absence of any comments, these tests will be considered Approved.

Note: for all practical purposes, I suspect the set of people that will 
actually review our tests are already subscribed to the testsuite list, 
thus this extra CfC is unlikely to result in additional review. As such, 
if no one beats me to it ;-), I will (separately) start a thread about 
streamlining the testing process a bit (for example remove the separate 
group wide CfC for a test suite and include the test suite review in the 
CfC to move a spec from CR to PR). However, let's please not derail this 
CfC on testing process issues.


-Thanks, AB

#Approval http://www.w3.org/2008/webapps/wiki/Approval


 Original Message 
Subject:Re: RfR: Selectors API Level 1 Test Suite - deadline 14 November
Resent-Date:Thu, 15 Nov 2012 16:18:17 +
Resent-From:public-webapps-testsu...@w3.org
Date:   Thu, 15 Nov 2012 17:17:42 +0100
From:   ext Charles McCathie Nevile cha...@yandex-team.ru
Organization:   Yandex
To: 	public-webapps-testsu...@w3.org, Lachlan Hunt 
lachlan.h...@lachy.id.au, Charles McCathie Nevile cha...@yandex-team.ru




On Sun, 11 Nov 2012 16:07:08 +0100, Charles McCathie Nevile
cha...@yandex-team.ru  wrote:


On Wed, 24 Oct 2012 14:28:41 +0200, Lachlan Hunt
lachlan.h...@lachy.id.au  wrote:


This is a request for review of the Selectors API Level 1 test suite.


This is a formal resolution that the test suite has passed the review, and
is accepted.

Although the only review we are aware of is Opera's, there are 5 browsers
scoring 97-99% on the tests, and people seem to have checked the tests in
practice.

cheers

Chaals (as co-chair)

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru  Find more athttp://yandex.com








Re: [selectors-api] Reference to obsolete ECMAScript Language spec version

2012-11-15 Thread Lachlan Hunt
On 2012-10-29 14:38, Norbert Lindenberg wrote:
 The current drafts of the Selectors API specifications [1, 2, 3]
 refer to the third edition of the ECMAScript Language Specification,

The references have been updated. Thank you.

-- 
Lachlan Hunt
http://lachy.id.au/
http://www.opera.com/



[selectors-api] Editoral Changes and Test Suite Progress

2012-11-15 Thread Lachlan Hunt
Hi,
The test suite has been reviewed by a colleague at Opera, which resulted
in a few minor corrections.  No corrections required any changes to the
implementation report.

However, it did result in a few editorial changes to Selectors API spec.
 These changes should not affect conformance of any implementations.

In particular, I fixed the algorithm for processing selectors to
explicitly refer to the definition for invalidity in Selectors, with
regards to throwing a syntax error. This was always implied, and is what
browsers do, but now the spec is clearer.

I also updated the Acknowledgements section to include people who have
submitted comments over the years who had been missed.  I tried to at
least include people who's comments resulted in changes to the spec.

I believe we can now finally proceed with publishing this as PR, as
discussed at TPAC.  I will co-ordinate with Chaals to make this happen
as soon as possible.

-- 
Lachlan Hunt
http://lachy.id.au/
http://www.opera.com/



Re: CFC Selectors API L1 to CR/PR

2012-11-11 Thread Charles McCathie Nevile

On Mon, 15 Oct 2012 23:13:53 +0200,  wrote:


Hi,

Formally, this is a Call for Consensus to move Selectors API to CR (and
possibly direct to Proposed Recommendation - see below). Responses are  
due by Friday 26 October, and while silence will be considered assent,

formal approval is preferred.


As foreshadowed at TPAC, this Call for consensus has passed.

We expect to request zero-length CR, if the associated RfR on the test  
quite doesn't turn up any reason to do otherwise.


cheers

Chaals


In addition, we would appreciate any information implementors may be able
to provide about proposed plans for fixing outstanding bugs in their
implementations.

The Selectors API Level 1 spec [1] has been fundamentally stable for  
quite

a while, and one issue was raised during Last Call, about what to do with
comments. Since we are working on a level 2, Lachlan has proposed to  
leave

the comments case undefined for now and figure out what to do during the
time Level 2 is finished, which has been accepted by the commenter [2].

The existing test suite [3] has not been approved yet (a separate mail is
coming on that) and Lachlan suggests it could use improvement, but it
shows two independent browsers passing each test (Opera 12.1 snapshot and
Firefox 16 Release both already pass the ns|div tests that are listed as
having no passes in the implementation report linked. General-purpose
sites like caniuse.com claim it is implemented everywhere. If it is
possible to satisfactorily demonstrate interoperable implementability, I
propose to request a direct advance to proposed Recommendation.

[1] http://www.w3.org/TR/selectors-api/
[2] http://www.w3.org/mid/501fa594.8000...@oupeng.com
[3]
http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/level1-baseline.html





--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com



[selectors-api] Reference to obsolete ECMAScript Language spec version

2012-10-29 Thread Norbert Lindenberg
The current drafts of the Selectors API specifications [1, 2, 3] refer to the 
third edition of the ECMAScript Language Specification, published 1999, 
although with a URL that is now home to edition 5.1, published 2011 [4]. Is 
there a reason to still reference the old version, or can the reference be 
updated to the current version?

BTW, an HTML version of the ECMAScript Language Specification is now available 
for reference [5].

Norbert

[1] http://www.w3.org/TR/selectors-api/
[2] http://dev.w3.org/2006/webapi/selectors-api/
[3] http://dev.w3.org/2006/webapi/selectors-api2/
[4] http://www.ecma-international.org/publications/standards/Ecma-262.htm
[5] http://www.ecma-international.org/ecma-262/5.1/





Re: CFC Selectors API L1 to CR/PR

2012-10-26 Thread Charles McCathie Nevile

On Mon, 15 Oct 2012 23:13:53 +0200,  wrote:


Formally, this is a Call for Consensus to move Selectors API to CR (and
possibly direct to Proposed Recommendation - see below). Responses are  
due by Friday 26 October, and while silence will be considered assent,

formal approval is preferred. Please reply to this thread to indicate
your response.


Yandex formally supports Selectors going forward.

cheers

Chaals


In addition, we would appreciate any information implementors may be able
to provide about proposed plans for fixing outstanding bugs in their
implementations.

The Selectors API Level 1 spec [1] has been fundamentally stable for  
quite

a while, and one issue was raised during Last Call, about what to do with
comments. Since we are working on a level 2, Lachlan has proposed to  
leave

the comments case undefined for now and figure out what to do during the
time Level 2 is finished, which has been accepted by the commenter [2].

The existing test suite [3] has not been approved yet (a separate mail is
coming on that) and Lachlan suggests it could use improvement, but it
shows two independent browsers passing each test (Opera 12.1 snapshot and
Firefox 16 Release both already pass the ns|div tests that are listed as
having no passes in the implementation report linked. General-purpose
sites like caniuse.com claim it is implemented everywhere. If it is
possible to satisfactorily demonstrate interoperable implementability, I
propose to request a direct advance to proposed Recommendation.

[1] http://www.w3.org/TR/selectors-api/
[2] http://www.w3.org/mid/501fa594.8000...@oupeng.com
[3]
http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/level1-baseline.html





--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com



[selectors-api] Updated Testsuite

2012-10-22 Thread Lachlan Hunt

Hi,
  I worked on redesigning the testsuite to resolve a number of issues 
with the design of the old tests, including removing significant amount 
of redundancy and fixing broken tests.  In the process, I have 
discovered a number of new bugs in various browsers that need to be 
addressed.


*Summary of Changes*

1. The Level 1 baseline tests are no longer a subset of the additional 
tests. The baseline and additional test files now test a completely 
separate set of tests.


2. The :target tests were moved from baseline to additional because 
:target was added in Selectors 3.


3. All selectors from CSS 1, 2 and Selectors 3 are being tested.

4. level1-lib.js now contains the common functions shared among the 3 
testsuites: baseline, additional and xhtml.


5. The files level1-content.html and level1-content.xht contain the all 
of the (X)HTML that is queried by the API, included within the iframe of 
each testsuite.  Every element in the file is assigned an ID that is 
used for verification.


6. selectors.js contains all selectors for both valid and invalid 
selector tests.  This includes annotations about the expected result 
from each selector, with a list of expected element IDs.  These IDs are 
compared with the results from the queries.


This change in architecture resolves some major issues with the old 
testsuite, which had previously resolved in false positives being 
reported.  Notably, the namespace tests. See below.


Some additional tests were added for :link and :visited, which now 
reveal failures in both Gecko and WebKit.


Notes:
* The Selectors API Level 2 tests have not yet been updated.
* Some tests are still needed for :not() and ~ sibling combinator.
* Some test descriptions have not been finished in selectors.js.


*Failures*

Opera:

Baseline: 1157 PASS, 10 FAIL
*  (no parameter) tests (throwing WRONG_ARGUMENTS_ERR instead of 
TypeError)

* #head :link, #head :visited (new bug in 12.10 beta, passes in 12.02)

Additional: 512 PASS, 0 FAIL


Chrome/Safari:

Baseline: 1140 PASS, 27 FAIL
* hasFeature() returns false
* namespace tests

Additional: 508 PASS, 4 FAIL
* :target tests


Mozilla Gecko:

Baseline: 1154 PASS, 13 FAIL
* hasFeature() returns false
*  (no parameter) tests (throwing NS_ERROR_XPC_NOT_ENOUGH_ARGS instead 
of TypeError)
* :link and :visited for fragment and detached element tests failing to 
match A and AREA elements.


Additional: 512 PASS, 0 FAIL
* No failures

(I haven't got access to IE at this time, so I have not tested it.)

The testsuite can be found here.
http://dev.w3.org/2006/webapi/selectors-api-testsuite/

All files for these tests are located in the hg repo.
http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: [selectors-api] Updated Testsuite

2012-10-22 Thread Boris Zbarsky

On 10/22/12 6:10 AM, Lachlan Hunt wrote:

* hasFeature() returns false


Just as a note, this is a pretty pointless test, and the language about 
it should be removed from this spec, assuming 
http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the 
way it is.



* :link and :visited for fragment and detached element tests failing to
match A and AREA elements.


Presumably https://bugzilla.mozilla.org/show_bug.cgi?id=787134

-Boris



Re: [selectors-api] Updated Testsuite

2012-10-22 Thread Anne van Kesteren
On Mon, Oct 22, 2012 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 10/22/12 6:10 AM, Lachlan Hunt wrote:
 * hasFeature() returns false

 Just as a note, this is a pretty pointless test, and the language about it
 should be removed from this spec, assuming
 http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the way
 it is.

Indeed, please remove http://www.w3.org/TR/selectors-api/#dom-feature-string


-- 
http://annevankesteren.nl/



Re: [selectors-api] Updated Testsuite

2012-10-22 Thread Lachlan Hunt

On 2012-10-22 16:29, Boris Zbarsky wrote:

On 10/22/12 6:10 AM, Lachlan Hunt wrote:

* hasFeature() returns false


Just as a note, this is a pretty pointless test, and the language about
it should be removed from this spec, assuming
http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the
way it is.


I dropped the feature string from both selectors api specs. I'll update 
the tests shortly.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-10-08 Thread Lachlan Hunt

On 2012-08-06 13:25, Lachlan Hunt wrote:

On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote:

(12/07/31 20:06), Arthur Barstow wrote:

On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote:

http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518


I think this is a very minor issue, and it has a simple workaround -
mark it as undefined. However, if Lachlan doesn't feel like paying extra
fee for versionning (what Anne calls make work) or he thinks having
undefineds in a spec significantly lowers the quality, I think that's
fair enough and I suggest the way to move forward (if we really want to)
is to consider my comment as retracted (let's just do so if Lachlan
doesn't reply to this).


I'd rather find a way to address the issue.  I've just been a bit busy
with other tasks for the last 2 weeks to look into this.

I'd like feedback from implementers about how best to address the issue.
  The options I can think of:

1. Disallow all comments within the selector for this API. Throw
SyntaxError when they are used.
2. Allow comments, but define that unclosed comments should throw a
SyntaxError.
3. Allow comments, define that unclosed comments are silently ignored.


After thinking about this for a while, I'm still not much closer to 
figuring out exactly what the right solution is, nor how the spec should 
change.  But I think it may be acceptable to leave this issue as 
undefined in Selectors API 1, so as to not continue to hold up taking 
that spec to Recommendation status.


Then we can figure out how to fix it in Selectors API 2, where I can 
spend more time and effort more clearly defining the parsing requirements.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: [selectors-api] Kudos on find/findAll, feedback on spec readability

2012-10-04 Thread Lachlan Hunt

On 2012-09-16 23:40, David Greenspan wrote:

6.2 -  ... first matching Element node within the subtrees...

Don't define a new term subtrees which just means descendants.  Say,
... first matching Element node that is a descendant of the context
object.


I could do that, but doing so makes it harder to rephrase this statement 
without making it more complex.


  3. The implementation must then run the algorithm to evaluate a
 selector against element nodes in the specified tree or subtrees
 using parsed selector as the selector and reference nodes as the
 contextual reference element set, as needed to return the required
 result for the invoked method.

If you have a suggestion for how to rephrase that to remove subtrees 
in a readable way without altering the meaning, please let me know.



The main take-away from section 6.2 should be that find/findAll use a
*different algorithm* from querySelector/querySelectorAll, or the same
algorithm with a different setting (relative=true).  This point is almost
entirely lost.


I think the clearest of those two alternatives is to clearly separate 
the two algorithms.  I have made this change in the spec.



I think the intent is for the reader to perform a sort of
dispatch on type when the algorithm in 6.5 is invoked, but it's confusing
because you can't really look at a selector and a relative selector and
tell them apart, and certainly not before parsing them.


The intent was that the reader is supposed to know whether you have a 
selector or relative selector based on which method was invoked. The 
above changes now make that clearer.



6.2 - When either method is invoked... - there are four methods, not 2


Good point, but with the above changes, I also made it more explicit 
about which methods are being referred to in each case.



6.5 - ... begins with a combinator and that combinator is not ' ' (space)
- how can a relative selector, in a comma-separated list with whitespace,
physically start with a space, i.e. a descendant combinator??


This was added to clarify that ' ' is excluded from the set of possible 
combinators that trigger automatic prepending of :scope, regardless of 
whether the selector meets any of the other conditions.  At this stage 
in the algorithm, no whitespace has been trimmed from the selector, so 
if the input is  div, then it needs to be clear that :scope is not 
prepended in step 1.


Note that there is a known bug in the way the grammar is defined that 
does actually allow for a relative selector to begin with a descendant 
combinator. I just haven't figured out a good way to fix this.  I have 
now noted this issue in the spec.


 Supposing it can (at the beginning of the string, perhaps), why would 

you special-case

it and prepend what's presumably a second descendant combinator in step 5?


Because if steps 2, 3 or 4 apply, then step 5 doesn't apply and :scope 
is not prepended.


e.g.
  document.find( div);  // Matches condition in step 2
  elm.find( not(:scope));   // Matches condition in step 3
  elm.find( body.foo :scope p); // Matches condition in step 4

If space was not excluded, the the spec could be interpreted such that 
:scope should be prepended in those cases.



7 - contextual reference element - This term is revealed to mean simply a
potential :scope element.  I would call it something like a scope
candidate -- or basically anything besides what it's called.


This section was intended to be dropped now that Selectors 4 defines 
:scope adequately, and as such the term contextual reference element 
has been removed.  However, the term contextual reference element set 
still remains due to its definition in Selectors 4.  If you wish to have 
that changed, please follow this up with the CSS WG.


I have now removed section 7 The :scope Pseudo-class entirely from 
this spec.



8 - Feature Strings - Change last paragraph to: Conforming implementations
must return true ... if they are perfectly compliant, and false if they are
not.


No.  Feature strings are a notoriously unreliably method of determining 
support for a given feature and it only exists to provide an indication 
that there is some support for the API, without specifying how compliant 
a given implementation is.



9 - Examples of find() and :scope MUST be added here.  Seriously.  This
section is the last chance to push that lucky reader over the final
threshold to feeling like they fully understand the spec.


They will be added in due course.  They hadn't been added yet due to the 
prior instability of the new API design and their low priority. However, 
feel free to contribute some examples if you like and I will consider 
including them.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



[selectors-api] Kudos on find/findAll, feedback on spec readability

2012-09-17 Thread David Greenspan
I've been reading the CSS/selector specs lately.  I'm interested both as a
framework implementer, designing and implementing jQuery-like functionality
for Meteor, and as an app developer who looks forward to the days when
browsers provide the APIs we want.

Coming into the new Selectors API, I was really hoping to discover that the
proposed find and findAll methods behaved essentially like the jQuery
calls.  Put simply, in running elem.find(div p), both the div and the
p in question would have to be descendants of elem (as well as each
other) in order to match.  In running elem.find( div p), there would be
the additional constraint that only immediate descendants of elem would be
considered as candidates for the div.  Unfortunately, this didn't seem to
be the case... until I read the spec about a half dozen more times, and I
realized it was!  If I'm reading it right, the spec does work this way and
is additionally much more flexible about the relationship between the
element, the scoping element (or elements), and the selector.  From reading
the list archives, I get the feeling that few web developers who come
across the spec understand this much.

First of all, I want to offer some encouragement.  The names find and
findAll are great, and their functionality is exactly what web developers
will expect and appreciate.  It's familiar and practical.  And as long as
in basic cases like element.find(a b c + d), it's required that all of a,
b, c, and d descend from the element, I am happy with whatever scope
selectors and edge cases are necessary or desirable.

However, the spec is very hard to understand.  I've read several specs
cover-to-cover (Java VM, ECMAScript, JPEG) and I think there is a lot of
low-hanging fruit in this short document (Selectors API Level 2) -- ways to
improve its clarity and enlist your readers more in support of this spec.

Some feedback from a reader, for what it's worth.

6.2 -  ... first matching Element node within the subtrees...

Don't define a new term subtrees which just means descendants.  Say,
... first matching Element node that is a descendant of the context
object.

The main take-away from section 6.2 should be that find/findAll use a
*different algorithm* from querySelector/querySelectorAll, or the same
algorithm with a different setting (relative=true).  This point is almost
entirely lost.  I think the intent is for the reader to perform a sort of
dispatch on type when the algorithm in 6.5 is invoked, but it's confusing
because you can't really look at a selector and a relative selector and
tell them apart, and certainly not before parsing them.  Isn't a relative
selector (string) just a selector (string) optionally preceded by a
combinator?  It seems to me that find() and querySelector() *do different
things*, conceptually; for example, the former will add an implicit :scope
to your selector and the latter won't.  It's nothing to do with their
arguments.  Given the same arguments, they will do different things.

To make it concrete by analogy, how would you interpret this spec (or short
of that, how does it feel to read and try to understand)?

===
Definitions: Chairs are made of wood.  Generalized Chairs are made of
wood, metal or plastic.

The VARNISH function accepts a chair.
The PAINT function accepts a generalized chair.

VARNISH must coat its input with transparent, Acme brand varnish.
PAINT must coat its input with liquid.

When either method is invoked, the implementation must perform Algorithm
Coat.

Algorithm Coat:
1) If the input is a wooden chair, coat it with varnish.
2) Otherwise, if the input is a generalized chair, coat it with paint whose
color matches the chair's referential color context.
===

Here are the stumbling blocks:

- If you try to simulate the algorithm, it's a head-scratcher.  Aren't
wooden chairs also generalized chairs?  How do we get to step 2 to paint a
wooden chair?  Are we really supposed to varnish or paint based on whether
the chair is known-to-be-wood or merely incidentally-wood, or is painting
wooden chairs not possible?

- Presumably, painting was invented to support new chair materials and
achieve color-coordinated finishes, yet there is barely a functional
description of what PAINT does, let alone the intent.  PAINT must coat its
input with liquid is the closest thing we have to a definition.

- We're describing these two functions along three axes, but the
information is so spread out that it is hard to integrate.

The ideal in clarity, which admittedly is not always possible with the need
to specify algorithms and share them between sections, is something like:
===
The VARNISH function accepts a chair and coats it with transparent, Acme
brand varnish.

The PAINT function accepts a generalized chair and coats it with paint
whose color matches the chair's referential color context.
===
That's a breath of fresh air.

However, there are many other options, like:
===
The VARNISH function accepts a chair as its argument.
The PAINT

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-07 Thread Tab Atkins Jr.
On Mon, Aug 6, 2012 at 7:13 PM, Kang-Hao (Kenny) Lu kangh...@oupeng.com wrote:
 (12/08/06 19:25), Lachlan Hunt wrote:
 On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote:
 I'd rather find a way to address the issue.  I've just been a bit busy
 with other tasks for the last 2 weeks to look into this.

 I'd like feedback from implementers about how best to address the issue.
  The options I can think of:

 1. Disallow all comments within the selector for this API. Throw
 SyntaxError when they are used.
 2. Allow comments, but define that unclosed comments should throw a
 SyntaxError.
 3. Allow comments, define that unclosed comments are silently ignored.

 Both 1. and 2. would take some extra code in Gecko, in particular 1. I'd
 note that this is not just about comments. It's about EOF fixing. See
 [1] for other testcases.

 [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0524

 (12/08/07 0:20), Tab Atkins Jr. wrote:
 Officially, 2.1 defines Kenny's example of html /* as tokenizing
 into IDENT WS DELIM DELIM, which is then an invalid selector since
 nothing recognizes those two delims as part of Selector's syntax.

 No, that's IDENT WS(S) BAD_COMMENT

Ah, whoops, indeed.  I forgot that BAD_COMMENT existed.

 This is compatible with Syntax's treatment, where it's recognized as a
 comment, but triggers a parse error.

 COMMENT is a bit special here and I think you might want to comment on
 other cases in [1].

Hm, kk.

~TJ



Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-06 Thread Kang-Hao (Kenny) Lu
(12/07/31 20:06), Arthur Barstow wrote:
 On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote:
 Sorry for my late comment.

 While I think it's fine to publish LCWD Selectors API as it is, it would
 be nice if it can address my comment in [1]. By address, I mean either
 define the desired behavior or explicitly mark it as undefined (which I
 think is better than not saying anything because an explicit undefined
 tells a spec reader that relevant discussions can be found in the list).

 [1]
 http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518

 
 Lachlan, Kenny - what is the status of this comment (f.ex. does the spec
 need to be changed)?

I think this is a very minor issue, and it has a simple workaround -
mark it as undefined. However, if Lachlan doesn't feel like paying extra
fee for versionning (what Anne calls make work) or he thinks having
undefineds in a spec significantly lowers the quality, I think that's
fair enough and I suggest the way to move forward (if we really want to)
is to consider my comment as retracted (let's just do so if Lachlan
doesn't reply to this).

To address this issue without marking undefineds, the way is:

0. Make sure this issue is addressed in css3-syntax (CCed Tab Atkins
since he is the editor).
1. Link to css3-syntax.
2. Write tests for this issue.

but I am not sure if the process will block us at 1. It sure would block
us at 2. if implementations haven't changed last since last time I
tested with this.


Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/




Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-06 Thread Lachlan Hunt

On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote:

(12/07/31 20:06), Arthur Barstow wrote:

On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote:

http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518


I completely missed that comment of yours when you originally sent it, 
which is why I didn't address it back then.



Lachlan, Kenny - what is the status of this comment (f.ex. does the spec
need to be changed)?


I think this is a very minor issue, and it has a simple workaround -
mark it as undefined. However, if Lachlan doesn't feel like paying extra
fee for versionning (what Anne calls make work) or he thinks having
undefineds in a spec significantly lowers the quality, I think that's
fair enough and I suggest the way to move forward (if we really want to)
is to consider my comment as retracted (let's just do so if Lachlan
doesn't reply to this).


I'd rather find a way to address the issue.  I've just been a bit busy 
with other tasks for the last 2 weeks to look into this.


I'd like feedback from implementers about how best to address the issue. 
 The options I can think of:


1. Disallow all comments within the selector for this API. Throw 
SyntaxError when they are used.
2. Allow comments, but define that unclosed comments should throw a 
SyntaxError.

3. Allow comments, define that unclosed comments are silently ignored.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-06 Thread Tab Atkins Jr.
On Mon, Aug 6, 2012 at 4:25 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
 On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote:
 I think this is a very minor issue, and it has a simple workaround -
 mark it as undefined. However, if Lachlan doesn't feel like paying extra
 fee for versionning (what Anne calls make work) or he thinks having
 undefineds in a spec significantly lowers the quality, I think that's
 fair enough and I suggest the way to move forward (if we really want to)
 is to consider my comment as retracted (let's just do so if Lachlan
 doesn't reply to this).


 I'd rather find a way to address the issue.  I've just been a bit busy with
 other tasks for the last 2 weeks to look into this.

 I'd like feedback from implementers about how best to address the issue.
 The options I can think of:

 1. Disallow all comments within the selector for this API. Throw SyntaxError
 when they are used.
 2. Allow comments, but define that unclosed comments should throw a
 SyntaxError.
 3. Allow comments, define that unclosed comments are silently ignored.

Officially, 2.1 defines Kenny's example of html /* as tokenizing
into IDENT WS DELIM DELIM, which is then an invalid selector since
nothing recognizes those two delims as part of Selector's syntax.

This is compatible with Syntax's treatment, where it's recognized as a
comment, but triggers a parse error.

So, go with #2.

~TJ



RE: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-06 Thread Travis Leithead
 From: Lachlan Hunt [mailto:lachlan.h...@lachy.id.au]
 
 I'd like feedback from implementers about how best to address the issue.
   The options I can think of:
 
 1. Disallow all comments within the selector for this API. Throw SyntaxError
 when they are used.
 2. Allow comments, but define that unclosed comments should throw a
 SyntaxError.
 3. Allow comments, define that unclosed comments are silently ignored.

I just checked in IE10, and it looks like we actually do:

4. Allow comments, define that unclosed comments are automatically closed.

Behavior wise, this means that given the following OM:
div id=parent
  div id=child/div
/div

The call: document.querySelector(#parent /* #child);

Returns the parent div successfully. I'm not sure that I'm thrilled about this 
behavior, but it is what it is...


Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-07-31 Thread Arthur Barstow

On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote:

Sorry for my late comment.

While I think it's fine to publish LCWD Selectors API as it is, it would
be nice if it can address my comment in [1]. By address, I mean either
define the desired behavior or explicitly mark it as undefined (which I
think is better than not saying anything because an explicit undefined
tells a spec reader that relevant discussions can be found in the list).

[1]
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518


Lachlan, Kenny - what is the status of this comment (f.ex. does the spec 
need to be changed)?


-Thanks, Art





[selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-07-19 Thread Kang-Hao (Kenny) Lu
Sorry for my late comment.

While I think it's fine to publish LCWD Selectors API as it is, it would
be nice if it can address my comment in [1]. By address, I mean either
define the desired behavior or explicitly mark it as undefined (which I
think is better than not saying anything because an explicit undefined
tells a spec reader that relevant discussions can be found in the list).

[1]
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518


Cheers,
Kenny



Reminder: RfC: LCWD of Selectors API Level 1; deadline July 19

2012-07-12 Thread Arthur Barstow

 Original Message 
Subject:RfC: LCWD of Selectors API Level 1; deadline July 19
Resent-Date:Thu, 28 Jun 2012 14:59:09 +
Resent-From:public-webapps@w3.org
Date:   Thu, 28 Jun 2012 10:58:36 -0400
From:   ext Arthur Barstow art.bars...@nokia.com
To: public-webapps public-webapps@w3.org



This is a Request for Comments for the June 28 Last Call Working Draft
of Selectors API Level 1:

http://www.w3.org/TR/2012/WD-selectors-api-20120628/

The comment deadline is July 19 and all comments should be sent to the
public-webapps@w3.org list with a Subject: prefix of  [selectors-api].

-Thanks, AB










[selectors-api] New Implementation Report for Updated Testsuite

2012-07-03 Thread Lachlan Hunt
I have now generated a new implementation report [1] to go with the 
updated testsuite.


As I detailed previously on public-webapps-testsuite [2], the new tests 
use testharness.js and, as a result, some of the tests which passed 
under the old framework now fail in some browsers. This is mostly 
because the new tests explicitly check for TypeError on the 'no 
parameter' tests, whereas the old tests accepted any exception as a pass.


WebKit is also failing one of the :target selector tests, probably 
releated to the way the test loads the testing page in an iframe.


[1] 
http://dev.w3.org/2006/webapi/selectors-api-testsuite/level1-baseline-report.html
[2] 
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2012Jun/0009.html


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/




Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-06-30 Thread Lachlan Hunt

On 2012-06-28 18:03, Stewart Brodie wrote:

Arthur Barstow art.bars...@nokia.com wrote:


This is a Request for Comments for the June 28 Last Call Working Draft
of Selectors API Level 1:

http://www.w3.org/TR/2012/WD-selectors-api-20120628/

The comment deadline is July 19 and all comments should be sent to the
public-webapps@w3.org list with a Subject: prefix of  [selectors-api].


Section 1 contains a unwanted duplication: With these methods methods,


Fixed in both level 1 and 2.


There is something odd about the way matching is defined:

Section 6 defines matching Element node directly in terms of the [SELECT]
reference, then section 6.4 defines what it means to evaluate a selector
but this is never referenced.  I think section 6 needs to define matching
Element node as something like:


Oops, this was supposed to have the content similar to that in the level 
2 spec defining what to do when the methods were invoked. I've now 
backported this from that spec, but omitted all things related to :scope.


The changes are in the editor's drafts.

http://dev.w3.org/2006/webapi/selectors-api/
http://dev.w3.org/2006/webapi/selectors-api2/

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/





RfC: LCWD of Selectors API Level 1; deadline July 19

2012-06-28 Thread Arthur Barstow
This is a Request for Comments for the June 28 Last Call Working Draft 
of Selectors API Level 1:


http://www.w3.org/TR/2012/WD-selectors-api-20120628/

The comment deadline is July 19 and all comments should be sent to the 
public-webapps@w3.org list with a Subject: prefix of  [selectors-api].


-Thanks, AB






Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-06-28 Thread Stewart Brodie
Arthur Barstow art.bars...@nokia.com wrote:

 This is a Request for Comments for the June 28 Last Call Working Draft 
 of Selectors API Level 1:
 
 http://www.w3.org/TR/2012/WD-selectors-api-20120628/
 
 The comment deadline is July 19 and all comments should be sent to the 
 public-webapps@w3.org list with a Subject: prefix of  [selectors-api].

Section 1 contains a unwanted duplication: With these methods methods,

There is something odd about the way matching is defined:

Section 6 defines matching Element node directly in terms of the [SELECT]
reference, then section 6.4 defines what it means to evaluate a selector
but this is never referenced.  I think section 6 needs to define matching
Element node as something like:

 An Element node is a matching Element node if the result of invoking the
 *evaluate a selector* algorithm with the selector and the Element bnode is
 true.

And then have the matching rules in a separate explanatory sentence in 6.4:

 Selectors are evaluated against the given element according to the rules
 for matching elements defined in Selectors [SELECT].

This would seem to be the original intention - the algorithm was added, but
then section 6 wasn't updated (it's the same as in the previous CR)  Did an
edit go missing somewhere?


-- 
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited



Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25

2012-06-26 Thread Lachlan Hunt

On 2012-06-18 15:57, Arthur Barstow wrote:

Lachlan has made some changes to the Selectors API Level 1 spec (last
published as a CR) and we consider the changes sufficient to require the
spec be published as a Working Draft (see the [1] thread). As such, this
is a Call for Consensus to publish a new LCWD of this spec using the
following document as the basis
http://dev.w3.org/2006/webapi/selectors-api/.

If you have any comments or concerns about this CfC, please send them to
public-webapps@w3.org by June 25 at the latest. Positive response is
preferred and encouraged and silence will be considered as agreement
with the proposal.


This draft has been prepared for publication and checked into the 
repository.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: CfC: publish WD of Selectors API Level 2; deadline June 25

2012-06-26 Thread Lachlan Hunt

On 2012-06-18 15:41, Arthur Barstow wrote:

Lachlan would like to publish a new Working Draft of the Selectors API
Level 2 spec and this is a Call for Consensus to do so using the
following Editor's Draft as the basis
http://dev.w3.org/2006/webapi/selectors-api2/.

If you have any comments or concerns about this proposal, please reply
to this e-mail by June 25 at the latest.


This draft has been prepared for publication and checked into the 
repository.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-21 Thread Lachlan Hunt

On 2012-06-18 11:06, Lachlan Hunt wrote:

Since it seems there are no objections to the latter option, and a few
people in favour of that, I've tentatively updated both drafts to
reflect this.

It now states:

   If the group of selectors include namespace prefixes that need to be
resolved, the implementation must raise a SYNTAX_ERR exception

http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces
http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces


I have now updated the testsuite to reflect this change.

http://dev.w3.org/2006/webapi/selectors-api-testsuite/

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/





Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Charles McCathieNevile
On Wed, 20 Jun 2012 16:26:14 +0200, Lachlan Hunt  
lachlan.h...@lachy.id.au wrote:



On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least  
objection.

...
But spending another few months arguing about it hasn't proven that we
are any wiser, nor (importantly) any closer to agreement.


This is why it should be an editorial decision, not a group vote.  The  
least-objectionable alternative is rarely the best alternative, and  
trying to please everyone is a fool's errand.  Hopefully, this time, the  
group will let me, as editor, evaluate the options and supporting  
rationale and make a decision based on that.


Yeah, if that works, it's fine. Back then we were in a position where  
people cared enough to object, so we chose a different way of making most  
of the people unhappy that drew less objection...


cheers

Chaals (You think this is bad, people bikeshed how I should write  
*my*name* ...)


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Lachlan Hunt

On 2012-06-20 17:46, Marat Tanalin | tanalin.com wrote:

20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:

4. Support for returning elements that are not descendants of the
 context object.

This feature allows a selector to be constructed such that it matches an
element anywhere in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.

elm.find(+span)// span is a sibling
elm.find(/for/ input)  // input could be anywhere
elm.find(:not(:scope)) // Everything except the context object

This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.


It's unclear why an _updated_ qSA version should have same limitation
that matching elements need to be descendants of the context
object. There is nothing obvious that makes h1.querySelector('+ H2')
impossible to work in newer implementations (in older ones it would
not work anyway -- to the same extent as `elm.querySelector(span)`
that you've declared as could work).


Supporting this without the risk of breaking compatibility would require 
switching selection behaviour based on the presence of the :scope pseudo 
class (either explicit or implied), for each individual selector in the 
group.  When :scope is present, then matching could be applied to the 
entire tree, just like it is in element.find().


That is, given the group of selectors:

  elm.querySelectorAll(:scope+p, div p)

(Note: After pre-processing, there is no difference between explicit 
:scope and implied :scope in +p)


Only :scope+p would be permitted to match non-descendant elements and 
the other div p would have to retain the backwards compatible 
selection behaviour where the subject of the selector must be a 
descendant of the context object.


That means, the implementation would need to split the group of 
selectors such that :scope+p (or any other selector with explicit or 
implied :scope) is potentially compared with all elements in the tree. 
Then the other selector div p should only be compared with descendants 
of the context object.


It will also not work for the reference combinator in some cases.  If 
switching selection behaviour depends on the presence of :scope, then 
the reference combinator will not always work effectively.


  elm.querySelectorAll(label /for/ input)

In this case with no :scope, the matching input must be a descendant of 
the context object, but the label may or may not be.  Compare that with 
this:


  elm.findAll(label /for/ input)

In this case, :scope is implied at the beginning, so the label must be a 
descendant of the context object, but the matching input elements may 
appear anywhere in the tree.


Overall, this adds significant complexity to the implementations, so 
while it may actually be technically possible in some cases, it's far 
from ideal and doesn't address all problems.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Kang-Hao (Kenny) Lu
(12/06/20 22:26), Lachlan Hunt wrote:
 On 2012-06-20 10:42, Charles McCathieNevile wrote:
 In other words we have the same arguments that we had five years ago,
 when we settled on querySelector as the one that provoked least
 objection.
 ...
 But spending another few months arguing about it hasn't proven that we
 are any wiser, nor (importantly) any closer to agreement.
 
 This is why it should be an editorial decision, not a group vote.

While I don't think a WG vote is the right way to do, I strongly
disagree that naming of a function belongs to an editorial decision.
Changing the name of a function requires all the tests be rewritten, and
therefore it is by definition not editorial.

 The least-objectionable alternative is rarely the best alternative, and
 trying to please everyone is a fool's errand. 

While I agree that trying to please everyone is foolish, I am curious
about data that can be used to prove the the least-objectionable
alternative is rarely the best alternative statement.

 Hopefully, this time, the group will let me, as editor, evaluate the
 options and supporting rationale and make a decision based on that.

I don't know what happened when the WG decided on the poor name
querySeletor, but from a outsider's point of view, along with the
final decision, I also care about a detailed description about why a
function name is chosen.

For example, attributing the poor querySelector decision to an
abstract concept of design by committee doesn't seem to be reasonable
and genuine. I'd rather want to see a long explanation like:

Despite the fact the editor thinks function name X is better than
'querySelector', there were a few people (name goes here) who were
strongly opposed to X and a group vote happened and a decision was made
by (name goes here). Nobody ran a compatibility research.

And this time, I would like to ask whoever is going to make the decision
to take the opinion of the *public* into account. I am not saying it
should be the sole factor, but what I am looking for is an explanation like

Compatibility research shows that both name X and Y are fine. 70% of
the Web developers are in favor of name X and therefore X is chosen.

or

Despite 70% of the Web developers are in favor of name X, compatibility
research shows that 

or even

Despite 70% of the Web developers are in favor of name X, 100% of
browser developers are not and therefore ...

or even

Nobody ran either a public vote and compatibility research and the
editor made the decision on X because he likes it.

(Seriously, I don't see why a rationale like this is better than the one
for querySelector as this is pretty much just s/WG/editor/ of that
since the WG vote didn't represent the public, but at least this is
easier to understand than design by committee or design by editor,
which is just well, difficult to understand to a causal person who cares
about the standard but doesn't have the bandwidth to go in.)

In other words, while I can agree that a single +1/-1 statement isn't
strong as a rationale (or even not a rationale) I beg you to take the
sum as a valid and strong rationale, at least in this case where X and Y
don't have much difference.

And I am still interested in what really happened last time.


(will try to bring real feedback next time.)


Cheers,
Kenny




Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Lachlan Hunt

On 2012-06-21 15:56, Kang-Hao (Kenny) Lu wrote:

(12/06/20 22:26), Lachlan Hunt wrote:

On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least
objection.
...
But spending another few months arguing about it hasn't proven that we
are any wiser, nor (importantly) any closer to agreement.


This is why it should be an editorial decision, not a group vote.


While I don't think a WG vote is the right way to do, I strongly
disagree that naming of a function belongs to an editorial decision.
Changing the name of a function requires all the tests be rewritten, and
therefore it is by definition not editorial.


By editorial decision, I meant that the decision of what to name it 
should be up to the editor, not that it is a minor editorial issue. 
Sorry for the confusion.  Fixing tests is trivial, but the name should 
be decided before implementation begins and a testsuite is written anyway.


At this stage, I haven't seen any overly strong objections to the names 
find/findAll anyway, so hopefully this is a non-issue.



Hopefully, this time, the group will let me, as editor, evaluate the
options and supporting rationale and make a decision based on that.


I don't know what happened when the WG decided on the poor name
querySeletor, but from a outsider's point of view, along with the
final decision, I also care about a detailed description about why a
function name is chosen.

For example, attributing the poor querySelector decision to an
abstract concept of design by committee doesn't seem to be reasonable
and genuine. I'd rather want to see a long explanation like:


What happened last time was that I carefully reviewed the entire debate, 
taking into account all arguments for and against every suggested 
alternative I found at the time and posted a thorough review and 
rationale for the decision I made at the end.


http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0077.html

This then resulted in some people in the group complaining loudly enough 
because they weren't happy, mostly because it's impossible to please 
everyone, leading to a vote between 6 choices, ultimately overruling me.


Anecdotally, I heard from a few web developers at the time saying they 
even liked the names I'd chosen, despite them being a little long, but 
were later disappointed with the result of the vote.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/





Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Charles McCathieNevile
On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu  
kennyl...@csail.mit.edu wrote:



(12/06/20 22:26), Lachlan Hunt wrote:

On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least
objection.
...



The least-objectionable alternative is rarely the best alternative, and
trying to please everyone is a fool's errand.


While I agree that trying to please everyone is foolish, I am curious
about data that can be used to prove the the least-objectionable
alternative is rarely the best alternative statement.


I don't think there is any readily available. There are no clear criteria  
for judging best, although there are some clear criteria for judging bad  
- for example things that often get confused are definitely bad.



Hopefully, this time, the group will let me, as editor, evaluate the
options and supporting rationale and make a decision based on that.


I don't know what happened when the WG decided on the poor name
querySeletor


Pretty much what Lachy said. As chair, I was the one who decided there ws  
too much objection and called for some other process. I don't claim it was  
especially good or came up with a great name, but I don't think it was  
awful and I don't see a better alternative if the situation arises again.



Despite the fact the editor thinks function name X is better than
'querySelector', there were a few people (name goes here) who were
strongly opposed to X and a group vote happened and a decision was made
by (name goes here). Nobody ran a compatibility research.

And this time, I would like to ask whoever is going to make the decision
to take the opinion of the *public* into account. I am not saying it
should be the sole factor, but what I am looking for is an explanation  
like


Compatibility research shows that both name X and Y are fine. 70% of
the Web developers are in favor of name X and therefore X is chosen.


We don't have that data. We don't agree which web developers are the ones  
whose opinions matter - those who type a name once a month and want  
something self-explanatory, or those who type it once every 3 minutes, or  
those who write tools to avoid typing it at all, or ...


And then we don't have representative samples. We know, for example, that  
focus/blur made sense to english-speaking developers but confused millions  
of developers whose first language was something else.


So claiming we are basing a decision on the data will probably give  
results as arbitrary as the process we used, but with a veneer of  
intellectual dishonesty.



Seriously, I don't see why a rationale like this is better than the one
for querySelector as this is pretty much just s/WG/editor/ of that
since the WG vote didn't represent the public


Sure.


In other words, while I can agree that a single +1/-1 statement isn't
strong as a rationale (or even not a rationale) I beg you to take the
sum as a valid and strong rationale, at least in this case where X and Y
don't have much difference.

And I am still interested in what really happened last time.


(It is instructive to think for five minutes about the things that can go  
wrong, and how much effort we should spend on trying to get it right)


Essentially, a bunch of people tossed up all the reasons to object to a  
name that they could think of based on their experience of things that go  
wrong. Based on that, some proposals were rapidly rejected, and then we  
looked at the rest, kicking the tyres of each in turn until we figured out  
which one the most people didn't think was truly problematic. It can be  
dismissed as design by committee, but it can also be characterised as  
applying the wisdom of several smart people to avoid as many pitfalls as  
possible.


Frankly I think that suggesting one is smarter than any committee of smart  
people could be is a bold claim - if nobody is especially happy with the  
outcome, it can often be said that a number of very clever hardworking  
people recognise that it doesn't have any of several obvious problems they  
can name, and they think it is an acceptable outcome.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Selectors API Implementation Report

2012-06-21 Thread Lachlan Hunt

Hi,
  I have created a basic implementation report covering the baseline 
tests.  All 5 browser implementations are at 99.2% pass rate, each 
browser only failing 8 of these tests because of the recent change for 
the NAMESPACE_ERR issue.


http://dev.w3.org/2006/webapi/selectors-api-testsuite/001-report.html

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/




Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Kang-Hao (Kenny) Lu
(12/06/21 23:28), Charles McCathieNevile wrote:
 On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu
 kennyl...@csail.mit.edu wrote:
 (12/06/20 22:26), Lachlan Hunt wrote:
 The least-objectionable alternative is rarely the best alternative, and
 trying to please everyone is a fool's errand.

 While I agree that trying to please everyone is foolish, I am curious
 about data that can be used to prove the the least-objectionable
 alternative is rarely the best alternative statement.
 
 I don't think there is any readily available. There are no clear
 criteria for judging best, although there are some clear criteria for
 judging bad - for example things that often get confused are definitely
 bad.

Well, yes, though I wonder why we can't define best to be what gets
the most public votes (just in this case, please don't generalize this
to cases when X and Y are having different implementation difficulty).

 Hopefully, this time, the group will let me, as editor, evaluate the
 options and supporting rationale and make a decision based on that.

 I don't know what happened when the WG decided on the poor name
 querySeletor
 
 Pretty much what Lachy said. As chair, I was the one who decided there
 ws too much objection and called for some other process. I don't claim
 it was especially good or came up with a great name, but I don't think
 it was awful and I don't see a better alternative if the situation
 arises again.

Thanks for the information (and to Lachy too). I also found the vote[1]
itself quite interesting.

[1] http://www.w3.org/2002/09/wbs/38482/selectorsNames/results

 Despite the fact the editor thinks function name X is better than
 'querySelector', there were a few people (name goes here) who were
 strongly opposed to X and a group vote happened and a decision was made
 by (name goes here). Nobody ran a compatibility research.

 And this time, I would like to ask whoever is going to make the decision
 to take the opinion of the *public* into account. I am not saying it
 should be the sole factor, but what I am looking for is an explanation
 like

 Compatibility research shows that both name X and Y are fine. 70% of
 the Web developers are in favor of name X and therefore X is chosen.
 
 We don't have that data. We don't agree which web developers are the
 ones whose opinions matter - those who type a name once a month and want
 something self-explanatory, or those who type it once every 3 minutes,
 or those who write tools to avoid typing it at all, or ...
 
 And then we don't have representative samples. We know, for example,
 that focus/blur made sense to english-speaking developers but confused
 millions of developers whose first language was something else.
 
 So claiming we are basing a decision on the data will probably give
 results as arbitrary as the process we used, but with a veneer of
 intellectual dishonesty.

I claim that numeric data is as honest as we ever can be. Taking a look
at Lachy's summary, I have to say while I appreciate the effort spent on
this, there are really just contradictory sentences that made me frown,
and Lachy later admitted[2]:

[[
In hindsight, looking at the arguments above, I probably did let my own
personal dislike of the name get in the way of my objectivity in this
case, as much as I tried to avoid doing so.  As such, I am now willing
to consider these alternatives.
]]

. Debating these rationale seems to be a waste of time too.

I don't see why doing a public poll can be considered dishonest. The
honest description would just be

We ran a public poll on (pointer goes here) with X people, Y % of
them are Web developers (pointer to the statistics goes here). The
result ... 

[2] http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0120

 (It is instructive to think for five minutes about the things that can
 go wrong, and how much effort we should spend on trying to get it right)
 
 Essentially, a bunch of people tossed up all the reasons to object to a
 name that they could think of based on their experience of things that
 go wrong. Based on that, some proposals were rapidly rejected, and then
 we looked at the rest, kicking the tyres of each in turn until we
 figured out which one the most people didn't think was truly
 problematic. It can be dismissed as design by committee, but it can
 also be characterised as applying the wisdom of several smart people to
 avoid as many pitfalls as possible.
 
 Frankly I think that suggesting one is smarter than any committee of
 smart people could be is a bold claim - if nobody is especially happy
 with the outcome, it can often be said that a number of very clever
 hardworking people recognise that it doesn't have any of several obvious
 problems they can name, and they think it is an acceptable outcome.

I never like the design by committee term because it seems to suggest
a solution (the benevolent dictator) without explaining what's going on.

In the querySelector case, although I admit that I think what 

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Charles McCathieNevile
On Wed, 20 Jun 2012 06:19:22 +0200, Elliott Sprehn espr...@gmail.com  
wrote:


On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr.  
jackalm...@gmail.comwrote:



...
This is not a good argument.  qSA is used often enough, and has a long
enough name, that the name is actually a pretty significant
misfeature.  This is a pretty core API, and both it and its precursors
(getElementByID, etc.) are very commonly renamed by libraries
precisely because you need a very short name for such a commonly used
function.



Why does it need a short name? If the name is too long to type then  
that's

an argument for better IDEs. Otherwise you end up with stuff like strncpy
to save typing. gzip eliminates the file size issue.

I'm in agreement with Marat that find() is not as clear as most DOM APIs
usually are. findBySelector() makes much more sense.


In other words we have the same arguments that we had five years ago, when  
we settled on querySelector as the one that provoked least objection.


getElementsB(y)Selector is consistent with the platform, subject to  
getting the s wrong, awfully long. find is too short for a general  
platform that has lots of ways of finding things and things you might be  
finding. querySelector is just sucky.


But spending another few months arguing about it hasn't proven that we are  
any wiser, nor (importantly) any closer to agreement.


If you want quick typing, alias it. If you want to know what it does  
because you only use it once a month (or in my case about once every six  
months), the name is barely clear enough.


There are no good answers here, since there are significant and competing  
needs.


cheers

Chaals


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Lachlan Hunt

On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least objection.
...
But spending another few months arguing about it hasn't proven that we
are any wiser, nor (importantly) any closer to agreement.


This is why it should be an editorial decision, not a group vote.  The 
least-objectionable alternative is rarely the best alternative, and 
trying to please everyone is a fool's errand.  Hopefully, this time, the 
group will let me, as editor, evaluate the options and supporting 
rationale and make a decision based on that.


Right now, that draft uses find/findAll() simply because they're the 
names that were used throughout the discussion that led to them being 
added.  There are still issues to resolve, however, which I would like 
feedback on.


In particular, is there really value in adding two distinct methods that 
differ only by whether they return 1 element or a collection?  Resolving 
this issue first would help with resolving the naming issue.


It should be noted that JQuery/sizzle does not use querySelector() at 
all, AFAICS. It only uses querySelectorAll() and sometimes switches to 
.getElementById() or document.body.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Marat Tanalin | tanalin . com
20.06.2012, 18:26, Lachlan Hunt lachlan.h...@lachy.id.au:
 In particular, is there really value in adding two distinct methods that
 differ only by whether they return 1 element or a collection?  Resolving
 this issue first would help with resolving the naming issue.

 It should be noted that JQuery/sizzle does not use querySelector() at
 all, AFAICS. It only uses querySelectorAll() and sometimes switches to
 .getElementById() or document.body.

The whole jQuery's paragigm of always searching all matching elements is a 
potentially big shortcoming of jQuery as for (at least) performance. It's 
natural to suppose that searching for just _first_ matching element and 
returning immediately once it's found should be much _faster_ than searching 
for _all_ matching elements (be it 100 or 1000 elements) even if we need just 
first one.

So yes, we need two separate methods: one to select first matching element and 
another one to select all matching elements. They could be united into one 
single method with an optional argument, but I doubt it would be quite handy 
and nonconfusing for using. Also, a method generally should return consistent 
result as for type of returning value, so if we had one method that always 
returns collection of elements, that would force us to often use the method 
with item accessor (like find('A')[0]) that would be redundant, unusable and 
less readable.

For example, I very like `querySelector()` and use it at least as much as (and 
maybe even more often than) `querySelectorAll()`.



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Dave Methvin


 It should be noted that JQuery/sizzle does not use querySelector() at all,
 AFAICS. It only uses querySelectorAll() and sometimes switches to
 .getElementById() or document.body.


I took a look at using querySelector as an optimization a while back but it
did not seem to make a significant difference in speed, at least once the
library overheads were included. This test html is based on the
msn.comhome page to be representative of a big real-life document.
http://jsperf.com/findone-vs-findall

The reason we switch to getElementById is because querySelectorAll is much
slower for that case. qSA can retrieve multiple elements in invalid
documents with duplicate IDs, but that's not a case we are worried about.


Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Marat Tanalin | tanalin . com
20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:
 4. Support for returning elements that are not descendants of the
 context object.

 This feature allows a selector to be constructed such that it matches an
 element anywhere in the tree relative to the context element. This
 feature is not relevant to document.find(), since it can already return
 anything from the whole tree.

    elm.find(+span)    // span is a sibling
    elm.find(/for/ input)  // input could be anywhere
    elm.find(:not(:scope)) // Everything except the context object

 This feature cannot be supported on Element.qSA, even when using eplicit
 :scope, because matching elements need to be descendants of the context
 object.

It's unclear why an _updated_ qSA version should have same limitation that 
matching elements need to be descendants of the context object. There is 
nothing obvious that makes h1.querySelector('+ H2') impossible to work in newer 
implementations (in older ones it would not work anyway -- to the same extent 
as `elm.querySelector(span)` that you've declared as could work).



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Boris Zbarsky

On 6/20/12 10:52 AM, Dave Methvin wrote:

This test html is based on the
msn.com http://msn.com home page to be representative of a big
real-life document.


For what it's worth, that document has about 2200 DOM nodes.  That's two 
orders of magnitude smaller than big real-life documents.  This is a 
medium-small real-life document.


Just for scale, the google.com homepage has about 500 DOM nodes.  The 
W3C homepage has about 1400 DOM nodes.  A Zimbra UI with about 200 
messages in the inbox is about 5000 nodes.  Anything that does dynamic 
UI stuff will tend to be in the 5k-50k node range.


Of course the library overhead might still kill you enough that it 
doesn't matter...


-Boris



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Boris Zbarsky

On 6/20/12 11:34 AM, Marat Tanalin | tanalin.com wrote:

It's natural to suppose that searching for just _first_ matching element and 
returning immediately once it's found should be much _faster_ than searching 
for _all_ matching elements (be it 100 or 1000 elements) even if we need just 
first one.


It's natural to suppose that, but it would be wrong if the majority of 
the time is spent setting up the search (e.g. preprocessing the 
selector, which jQuery does), not actually searching



For example, I very like `querySelector()` and use it at least as much as (and 
maybe even more often than) `querySelectorAll()`.


If you're calling these directly, there's a lot less preprocessing going on.

-Boris




Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Simon Pieters
On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu  
kennyl...@csail.mit.edu wrote:



(12/06/18 22:45), Simon Pieters wrote:

I think we should instead either fix the old API (if it turns out to not
Break the Web) or live with past mistake (if it turns out it does). To
find out whether it Breaks the Web (and the breakage can't be evanged),
I suggest we ship the backwards-incompatible change to querySelector()
in nightly/aurora (or equivalent) in one or more browsers for some time.


I didn't read through all the QSA threads, but isn't the function name
itself a mistake that many people don't want to live with?


We have lots of shipped APIs with worse names. I think we should live with  
past mistakes, try not to make them again, and move on.


--
Simon Pieters
Opera Software



Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25

2012-06-19 Thread Charles McCathieNevile
On Mon, 18 Jun 2012 15:57:02 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


Lachlan has made some changes to the Selectors API Level 1 spec (last  
published as a CR) and we consider the changes sufficient to require the  
spec be published as a Working Draft (see the [1] thread). As such, this  
is a Call for Consensus to publish a new LCWD of this spec using the  
following document as the basis  
http://dev.w3.org/2006/webapi/selectors-api/.


Please publish :)

cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Brian Kardell
I am very opposed to this, they do different things.  Having abilities
isn't a bad thing and numerous Web sites and libraries make use of qsa, not
just because find was not available but because different APIs shapes
interesting new possibilities, different ways of looking at problems,
etc... We solve problems with the tools at hand, so given that it has been
widely implemented a long time, you can safely assume we have found good
uses for it.

There are a vast number of libraries and websites that have use cases for
find, this is especially true because selector engines that solved those
cases evolved in the wild a long time ago it probably would have been
nice to have had that native first, as it would have been a more immediate
help for the vast number of users, but qsa is definitely useful.
On Jun 18, 2012 10:45 AM, Simon Pieters sim...@opera.com wrote:

 So 
 http://dev.w3.org/2006/webapi/**selectors-api2/http://dev.w3.org/2006/webapi/selectors-api2/introduces
  the methods find() and findAll() in addition to querySelector()
 and querySelectorAll() and changes the scoping behavior for the former
 methods to match what people expect them to do.

 I'm not convinced that doubling the API surface is a good idea. If we were
 to do that every time we find that a shipped API has suboptimal behavior,
 the API surface on the Web would grow exponentially and we wouldn't make
 the overall situation any better. What if we find a new problem with find()
 after it has shipped? Do we introduce yet another method?

 I think we should instead either fix the old API (if it turns out to not
 Break the Web) or live with past mistake (if it turns out it does). To find
 out whether it Breaks the Web (and the breakage can't be evanged), I
 suggest we ship the backwards-incompatible change to querySelector() in
 nightly/aurora (or equivalent) in one or more browsers for some time.

 --
 Simon Pieters
 Opera Software




Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Tab Atkins Jr.
On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters sim...@opera.com wrote:
 On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu
 kennyl...@csail.mit.edu wrote:
 (12/06/18 22:45), Simon Pieters wrote:

 I think we should instead either fix the old API (if it turns out to not
 Break the Web) or live with past mistake (if it turns out it does). To
 find out whether it Breaks the Web (and the breakage can't be evanged),
 I suggest we ship the backwards-incompatible change to querySelector()
 in nightly/aurora (or equivalent) in one or more browsers for some time.

 I didn't read through all the QSA threads, but isn't the function name
 itself a mistake that many people don't want to live with?

 We have lots of shipped APIs with worse names. I think we should live with
 past mistakes, try not to make them again, and move on.

This is not a good argument.  qSA is used often enough, and has a long
enough name, that the name is actually a pretty significant
misfeature.  This is a pretty core API, and both it and its precursors
(getElementByID, etc.) are very commonly renamed by libraries
precisely because you need a very short name for such a commonly used
function.

~TJ



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Marat Tanalin | tanalin . com
20.06.2012, 00:38, Tab Atkins Jr. jackalm...@gmail.com:
 On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters sim...@opera.com wrote:

  On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu
  kennyl...@csail.mit.edu wrote:
  We have lots of shipped APIs with worse names. I think we should live with
  past mistakes, try not to make them again, and move on.

 This is not a good argument.  qSA is used often enough, and has a long
 enough name, that the name is actually a pretty significant
 misfeature.  This is a pretty core API, and both it and its precursors
 (getElementByID, etc.) are very commonly renamed by libraries
 precisely because you need a very short name for such a commonly used
 function.

There is a key difference between native functionality and one implemented as a 
library -- they quite differently relate to backward compatibility. A library 
can be rewritten partially or even entirely if needed (older applications can 
just continue using older versions of the library), while native functionality, 
once widely implemented, have to be supported forever and in fact cannot (and 
should never) be dropped. 

As for `querySelector()` in particular, its name is indeed not the best, but 
_not_ because it's too long, but because it's not quite _clear_ / 
_self-documenting_. `querySelector()` and `querySelectorAll()` should have been 
named `getElementBySelector()` and `getElementsBySelector()` instead.

In this regard, `find()` is far less clear (and even confusing) as for what it 
does.



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Elliott Sprehn
On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 ...
 This is not a good argument.  qSA is used often enough, and has a long
 enough name, that the name is actually a pretty significant
 misfeature.  This is a pretty core API, and both it and its precursors
 (getElementByID, etc.) are very commonly renamed by libraries
 precisely because you need a very short name for such a commonly used
 function.


Why does it need a short name? If the name is too long to type then that's
an argument for better IDEs. Otherwise you end up with stuff like strncpy
to save typing. gzip eliminates the file size issue.

I'm in agreement with Marat that find() is not as clear as most DOM APIs
usually are. findBySelector() makes much more sense.

- Elliott

- E


Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-18 Thread Simon Pieters
On Sun, 17 Jun 2012 13:10:11 +0200, Kang-Hao (Kenny) Lu  
kennyl...@csail.mit.edu wrote:



1. Explicitly undefine this case.


That would not be my preference.



2. Spec IE9, Firefox13 and Opera12alpha's behavior

Roughly speaking, the choice is an invalid token or '|' whichever comes
first, but I'd note that in the corner case


These are valid:

|a
*|a


My proposed spec change:


  # If the group of selectors include namespace prefixes that need to
  # be resolved, the implementation must raise a NAMESPACE_ERR
  # exception.


s/NAMESPACE_ERR/SYNTAX_ERR/

--
Simon Pieters
Opera Software



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-18 Thread Lachlan Hunt

On 2012-06-18 04:29, Boris Zbarsky wrote:

Consider how this is parsed in a depth-first recursive descent parser:

   a|b +,

1)  The identifier a is scanned.  This might be a tag name or a
 namespace; look at the next token.
2)  The symbol '|' is scanned.  Great. a was a namespace.  Resolve it.

And you're done.  You have an error and bail out.  You never even got to
the '+'.


This is a good reason not to strictly define one having precedence over 
the other. That leaves 2 options: Leaving it explicitly undefined (only 
mildly better than the current situation) or using only syntax error.


Since it seems there are no objections to the latter option, and a few 
people in favour of that, I've tentatively updated both drafts to 
reflect this.


It now states:

  If the group of selectors include namespace prefixes that need to be
   resolved, the implementation must raise a SYNTAX_ERR exception

I also removed the note about non-namespace supporting implementations 
throwing a syntax error instead of a namespace error.


http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces
http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/





Re: Updates to Selectors API

2012-06-18 Thread Arthur Barstow

On 6/14/12 10:11 AM, ext Lachlan Hunt wrote:

Hi,
I have updated the specification for Selectors API Level 1, which is 
currently in CR.


Most of it was editorial in nature, to bring it in line with Selectors 
API Level 2, except without adding any of the new features like 
findAll() or or matches().


Importantly, the IDL has now been updated to comply with the most 
recent WebIDL specificiation.  This was basically to split it up into 
3 partial interfaces, just like what was previously done in v2.


Some of the prose was rewritten, but none of the changes should 
adversely affect implementation requirements. This was mostly done by 
back porting the content from v2, but while ensuring that all the 
normative references still refer to the older, stable specs. (e.g. 
DOM3Core instead of using DOM4, as is used in the v2 draft.)  This now 
makes v1 a proper subset of v2.


In the process, I also made a few minor editorial changes to v2 just 
to tidy it up.


At this stage, we should be able to publish v1 as a revised CR, or 
possibly move it up to PR. 


I like the changes Lachlan, especially the new section 6.4.

Although I have argued to the Advisory Committee and Advisory Board the 
process should (under certain circumstances) permit a CR to be directly 
re-published as a CR, that currently is not possible. Nevertheless, I 
think it could be a bit tricky to argue to the Director in this case 
that there were no substantive changes (e.g. the new 6.4) so my 
recommendation is that we publish a new LCWD with the minimum 3-week 
review period (and make sure all of the changes can be reviewed).


At the end of the LC review period, if no substantive changes are 
needed, and we already have sufficient interop data (i.e. the 2009 CR 
exit criteria is already met), we could skip a new CR and directly 
publish a PR.


Do you or Chaals have the interop data now (and if so, where is it)? 
What do you think about going the LC-PR route?



We can also publish v2. as a new WD.


If you want me to start a CfC to publish a new WD of v2, just let me know.

-Thanks, Art

Alternatively, we could forgo any further progress with v1 and let v2 
supersede it entirely, at which point I could simply rename it back to 
Selectors API without a version number and move on.  (This is my 
preferred approach).


http://dev.w3.org/2006/webapi/selectors-api/
http://dev.w3.org/2006/webapi/selectors-api2/





Re: Updates to Selectors API

2012-06-18 Thread Lachlan Hunt

On 2012-06-18 13:57, Arthur Barstow wrote:

In the process, I also made a few minor editorial changes to v2 just
to tidy it up.

At this stage, we should be able to publish v1 as a revised CR, or
possibly move it up to PR.


I like the changes Lachlan, especially the new section 6.4.

Although I have argued to the Advisory Committee and Advisory Board the
process should (under certain circumstances) permit a CR to be directly
re-published as a CR, that currently is not possible. Nevertheless, I
think it could be a bit tricky to argue to the Director in this case
that there were no substantive changes (e.g. the new 6.4) so my
recommendation is that we publish a new LCWD with the minimum 3-week
review period (and make sure all of the changes can be reviewed).


OK. Let's get started on that process.


Do you or Chaals have the interop data now (and if so, where is it)?
What do you think about going the LC-PR route?


Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline 
(HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests.


Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 
tests. Opera only passes 99.2% of these and IE only passes 67.7% of 
these. However, these are additional tests that are not required to 
declare interoperability of the API, as the failures relate more to 
XHTML and Selectors support, rather than any particular bug with the API.


http://dev.w3.org/2006/webapi/selectors-api-testsuite/

Do I need to prepare some kind of formal testsuite report with the 
results for each test?


However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this 
test suite will need to be updated with new tests, so this will likely 
delay PR for a little bit longer.



We can also publish v2. as a new WD.


If you want me to start a CfC to publish a new WD of v2, just let me know.


Yes please.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/





Re: Updates to Selectors API

2012-06-18 Thread Arthur Barstow

On 6/18/12 8:34 AM, ext Lachlan Hunt wrote:

On 2012-06-18 13:57, Arthur Barstow wrote:

In the process, I also made a few minor editorial changes to v2 just
to tidy it up.

At this stage, we should be able to publish v1 as a revised CR, or
possibly move it up to PR.


I like the changes Lachlan, especially the new section 6.4.

Although I have argued to the Advisory Committee and Advisory Board the
process should (under certain circumstances) permit a CR to be directly
re-published as a CR, that currently is not possible. Nevertheless, I
think it could be a bit tricky to argue to the Director in this case
that there were no substantive changes (e.g. the new 6.4) so my
recommendation is that we publish a new LCWD with the minimum 3-week
review period (and make sure all of the changes can be reviewed).


OK. Let's get started on that process.


OK, I'll start the CfC for LC today.



Do you or Chaals have the interop data now (and if so, where is it)?
What do you think about going the LC-PR route?


Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline 
(HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests.


Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 
tests. Opera only passes 99.2% of these and IE only passes 67.7% of 
these. However, these are additional tests that are not required to 
declare interoperability of the API, as the failures relate more to 
XHTML and Selectors support, rather than any particular bug with the API.


http://dev.w3.org/2006/webapi/selectors-api-testsuite/

Do I need to prepare some kind of formal testsuite report with the 
results for each test?


Yes, we do need to document the spec has interoperable implementations 
(and that is typically called the interop report). I think we have 
considerable flexibility on the format of the data. Here are a couple of 
examples:


* Cam's Element Traversal
http://www.w3.org/2008/webapps/ElementTraversal/index.html

* Marcos' widget spec
http://dev.w3.org/2006/waf/widgets/imp-report/

However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this 
test suite will need to be updated with new tests, so this will likely 
delay PR for a little bit longer.


OK, that's good to know. The LC's status section should include the URI 
of the interop report although that document can be empty when the LC is 
published. (I think the status section should also mention the group 
expects to skip CR and go directly to PR.)




We can also publish v2. as a new WD.


If you want me to start a CfC to publish a new WD of v2, just let me 
know.


Yes please.


Will do.

-Thanks, Art




CfC: publish WD of Selectors API Level 2; deadline June 25

2012-06-18 Thread Arthur Barstow
Lachlan would like to publish a new Working Draft of the Selectors API 
Level 2 spec and this is a Call for Consensus to do so using the 
following Editor's Draft as the basis 
http://dev.w3.org/2006/webapi/selectors-api2/.


Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please reply 
to this e-mail by June 25 at the latest.


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean  agreement with the proposal.


-Thanks, AB




CfC: publish a LCWD of Selectors API Level 1; deadline June 25

2012-06-18 Thread Arthur Barstow
Lachlan has made some changes to the Selectors API Level 1 spec (last 
published as a CR) and we consider the changes sufficient to require the 
spec be published as a Working Draft (see the [1] thread). As such, this 
is a Call for Consensus to publish a new LCWD of this spec using the 
following document as the basis 
http://dev.w3.org/2006/webapi/selectors-api/.


This CfC satisfies the group's requirement to record the group's 
decision to request advancement for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by June 25 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


The proposed LC review period is 3 weeks.

-Thanks, AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1189.html






[selectors-api] Consider backporting find() behavior to querySelector()

2012-06-18 Thread Simon Pieters
So http://dev.w3.org/2006/webapi/selectors-api2/ introduces the methods  
find() and findAll() in addition to querySelector() and querySelectorAll()  
and changes the scoping behavior for the former methods to match what  
people expect them to do.


I'm not convinced that doubling the API surface is a good idea. If we were  
to do that every time we find that a shipped API has suboptimal behavior,  
the API surface on the Web would grow exponentially and we wouldn't make  
the overall situation any better. What if we find a new problem with  
find() after it has shipped? Do we introduce yet another method?


I think we should instead either fix the old API (if it turns out to not  
Break the Web) or live with past mistake (if it turns out it does). To  
find out whether it Breaks the Web (and the breakage can't be evanged), I  
suggest we ship the backwards-incompatible change to querySelector() in  
nightly/aurora (or equivalent) in one or more browsers for some time.


--
Simon Pieters
Opera Software



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-18 Thread Kang-Hao (Kenny) Lu
(12/06/18 22:45), Simon Pieters wrote:
 I think we should instead either fix the old API (if it turns out to not
 Break the Web) or live with past mistake (if it turns out it does). To
 find out whether it Breaks the Web (and the breakage can't be evanged),
 I suggest we ship the backwards-incompatible change to querySelector()
 in nightly/aurora (or equivalent) in one or more browsers for some time.

I didn't read through all the QSA threads, but isn't the function name
itself a mistake that many people don't want to live with?

I'd rather like to see querySelector() marked as deprecated so it
doesn't appear in tutorials in the future.


Cheers,
Kenny



RE: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-18 Thread Travis Leithead
 -Original Message-
 From: Kang-Hao (Kenny) Lu [mailto:kennyl...@csail.mit.edu]
 
 (12/06/18 22:45), Simon Pieters wrote:
  I think we should instead either fix the old API (if it turns out to
  not Break the Web) or live with past mistake (if it turns out it
  does). To find out whether it Breaks the Web (and the breakage can't
  be evanged), I suggest we ship the backwards-incompatible change to
  querySelector() in nightly/aurora (or equivalent) in one or more browsers 
  for
 some time.
 
 I didn't read through all the QSA threads, but isn't the function name itself 
 a
 mistake that many people don't want to live with?
 
 I'd rather like to see querySelector() marked as deprecated so it doesn't 
 appear
 in tutorials in the future.

Despite being non-optimal according to a vocal sub-set of people, 
querySelector[All] has been deployed in browsers for around 3-4 years. 
I strongly oppose any notion of altering its behavior now.

As to find/findAll, let's just make sure we get the behavior right the 
second time so we don't go through this again.


RE: publish WD of Selectors API Level 2; deadline June 25

2012-06-18 Thread Travis Leithead
 From: Arthur Barstow [mailto:art.bars...@nokia.com]
 
 Lachlan would like to publish a new Working Draft of the Selectors API Level 2
 spec and this is a Call for Consensus to do so using the following Editor's 
 Draft as
 the basis http://dev.w3.org/2006/webapi/selectors-api2/.
 
 Positive response to this CfC is preferred and encouraged and silence will be
 assumed to mean  agreement with the proposal.

I support the publication of a new WD.
-Travis




[selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Kang-Hao (Kenny) Lu
The spec (either Level 1 or Level 2) is unclear about which error should
be raised in a situation when both NAMESAPCE_ERR and SYNTAX_ERR apply,
and this is not the same in all browsers. That is, for a selector like

  a|b +

or

  a|b, +

IE9, Firefox 13 and Opera12alpha raise NAMESAPCE_ERR, while Chrome19
raises SYNTAX_ERR.


Two proposed solutions (sorted by my preference):

1. Explicitly undefine this case.

I don't think having interoperability on this is of big importance, but
in general having an explicit undefined is usually better than an
implicit one.

Proposed text:

change

  # If the group of selectors include namespace prefixes that need to
  # be resolved, the implementation must raise a NAMESPACE_ERR
  # exception.

to

  | If the group of selectors include namespace prefixes that need to
  | be resolved and match either dom_selectors_group or
  | dom_relative_selectors_group, the implementation must raise a
  | NAMESPACE_ERR exception. If the group of selectors include
  | namespace prefixes that need to be resolved and /doesn't/ match
  | either dom_selectors_group or dom_relative_selectors_group, the
  | implementation must raise either a NAMESPACE_ERR exception or a
  | SYNTAX_ERR exception. The exact choice is undefined.

2. Spec IE9, Firefox13 and Opera12alpha's behavior

Roughly speaking, the choice is an invalid token or '|' whichever comes
first, but I'd note that in the corner case

  a|

Firefox13 and Oper12alpha raise NAMESPACE_ERR but IE9 raises SYNTAX_ERR.


Cheers,
Kenny



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Anne van Kesteren
Always throwing SyntaxError is probably better. Which reminds me, the
specification needs to be updated for new-style exceptions.



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Boris Zbarsky

On 6/17/12 9:33 AM, Anne van Kesteren wrote:

Always throwing SyntaxError is probably better.


Also probably incompatible with a depth-first recursive descent parser 
implementation.  Are we sure we want to overconstrain implementations 
like that?


-Boris



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Anne van Kesteren
On Jun 17, 2012, at 3:44 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 Also probably incompatible with a depth-first recursive descent parser 
 implementation.  Are we sure we want to overconstrain implementations like 
 that?

Incompatible how?



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Aryeh Gregor
On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 6/17/12 9:33 AM, Anne van Kesteren wrote:

 Always throwing SyntaxError is probably better.


 Also probably incompatible with a depth-first recursive descent parser
 implementation.  Are we sure we want to overconstrain implementations like
 that?

I'm not sure what Anne meant, but I'd think we should just always
require SyntaxError, including for namespace errors.  Do enough people
really use namespaces that they deserve a separate exception?  CSS
itself treats namespace errors the same as syntax errors in
stylesheets (right?), so it doesn't make sense to require Selectors
APIs to distinguish them.



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Kang-Hao (Kenny) Lu
(12/06/17 21:33), Anne van Kesteren wrote:
 Always throwing SyntaxError is probably better. 

I have no opinion here besides that I think this should be well-defined.

(12/06/17 21:50), Aryeh Gregor wrote:
 I'm not sure what Anne meant, but I'd think we should just always
 require SyntaxError, including for namespace errors.  Do enough people
 really use namespaces that they deserve a separate exception?

Probably no.

 CSS itself treats namespace errors the same as syntax errors in
 stylesheets (right?),

In the Selectors spec, in some sense, yes, but the spec didn't have to
touch the JS stuff so I wouldn't rely on its insights into this.

 so it doesn't make sense to require Selectors
 APIs to distinguish them.

As long as browsers are willing to change this old behavior, agreed.



(By the way, another irrelevant editorial feedback:

http://dev.w3.org/2006/webapi/selectors-api2/

6.5 3-1 s/dom_relative_selectors_group/dom_selectors_group/ )


Cheers,
Kenny




Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Lachlan Hunt

On 2012-06-17 15:50, Aryeh Gregor wrote:

On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarskybzbar...@mit.edu  wrote:

On 6/17/12 9:33 AM, Anne van Kesteren wrote:

Always throwing SyntaxError is probably better.


Also probably incompatible with a depth-first recursive descent parser
implementation.  Are we sure we want to overconstrain implementations like
that?


I don't know what this means.  Could you clarify?


I'm not sure what Anne meant, but I'd think we should just always
require SyntaxError, including for namespace errors.  Do enough people
really use namespaces that they deserve a separate exception?  CSS
itself treats namespace errors the same as syntax errors in
stylesheets (right?), so it doesn't make sense to require Selectors
APIs to distinguish them.


The distinction made sense when we were considering supporting 
namespaces, as it would help authors to diagnose mistakes.  But looking 
at sizzle.js [1], it doesn't make a distinction between them at all. It 
just catches the error, ignores it and moves on.


This may be one thing that could be changed without risk of breaking 
anything, since the lack of any namespace support means its unlikely 
that there are any scripts performing any special error handling for 
namespace errors that differs from other syntax errors.


Is there any reason we should keep this distinction?

[1] https://github.com/jquery/sizzle/blob/master/sizzle.js

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Boris Zbarsky

On 6/17/12 9:50 AM, Anne van Kesteren wrote:

On Jun 17, 2012, at 3:44 PM, Boris Zbarskybzbar...@mit.edu  wrote:

Also probably incompatible with a depth-first recursive descent parser 
implementation.  Are we sure we want to overconstrain implementations like that?


Incompatible how?


Consider how this is parsed in a depth-first recursive descent parser:

  a|b +,

1)  The identifier a is scanned.  This might be a tag name or a
namespace; look at the next token.
2)  The symbol '|' is scanned.  Great. a was a namespace.  Resolve it.

And you're done.  You have an error and bail out.  You never even got to 
the '+'.


-Boris

P.S.  This is basically what the Gecko parser does, afaik.  On the other 
hand, WebKit's parser is breadth-first, again as far as I know: it first 
breaks up the selector on ',', then tries to match the various bits 
against the relevant productions and only after that actually deals with 
the leaf parse nodes.  Hence it actually sees the missing stuff after 
'+' error before it ever tries to figure out anything about a in there.




Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Anne van Kesteren
On Mon, Jun 18, 2012 at 4:29 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 And you're done.  You have an error and bail out.

Yeah, so I should have been more clear. My suggestion was to never
throw a NamespaceError and just always use SyntaxError. That
distinction has never made much sense. (Well I guess it might have
somewhat when it was still theoretically possible to have a
namespace-aware and non-namespace-aware DOM...)


-- 
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/



Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Boris Zbarsky

On 6/18/12 1:33 AM, Anne van Kesteren wrote:

On Mon, Jun 18, 2012 at 4:29 AM, Boris Zbarskybzbar...@mit.edu  wrote:

And you're done.  You have an error and bail out.


Yeah, so I should have been more clear. My suggestion was to never
throw a NamespaceError and just always use SyntaxError.


Ah, ok.  That would certainly be pretty easy.  ;)

-Boris



Updates to Selectors API

2012-06-14 Thread Lachlan Hunt

Hi,
I have updated the specification for Selectors API Level 1, which is 
currently in CR.


Most of it was editorial in nature, to bring it in line with Selectors 
API Level 2, except without adding any of the new features like 
findAll() or or matches().


Importantly, the IDL has now been updated to comply with the most recent 
WebIDL specificiation.  This was basically to split it up into 3 partial 
interfaces, just like what was previously done in v2.


Some of the prose was rewritten, but none of the changes should 
adversely affect implementation requirements. This was mostly done by 
back porting the content from v2, but while ensuring that all the 
normative references still refer to the older, stable specs. (e.g. 
DOM3Core instead of using DOM4, as is used in the v2 draft.)  This now 
makes v1 a proper subset of v2.


In the process, I also made a few minor editorial changes to v2 just to 
tidy it up.


At this stage, we should be able to publish v1 as a revised CR, or 
possibly move it up to PR.  We can also publish v2. as a new WD.


Alternatively, we could forgo any further progress with v1 and let v2 
supersede it entirely, at which point I could simply rename it back to 
Selectors API without a version number and move on.  (This is my 
preferred approach).


http://dev.w3.org/2006/webapi/selectors-api/
http://dev.w3.org/2006/webapi/selectors-api2/

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/



Re: Updates to Selectors API

2012-06-14 Thread Bjoern Hoehrmann
* Lachlan Hunt wrote:
At this stage, we should be able to publish v1 as a revised CR, or 
possibly move it up to PR.  We can also publish v2. as a new WD.

It does not seem that additional implementation experience is required
to make sure no major changes are needed, so, Proposed Recommendation.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 



Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-29 Thread Yehuda Katz
Yehuda Katz
(ph) 718.877.1325


On Fri, Nov 25, 2011 at 7:49 AM, William Edney
bed...@technicalpursuit.comwrote:

 All -

 I'm going to throw my 2 cents in here and say that, whatever ends up
 happening with scoping, that the equivalent of the current
 querySelector()/querySelectorAll() should be named matchesSelector().


I'd be ok with querySelector/querySelectorAll/matchesSelector and
find/findAll/matches

As I have said, I personally consider qS/qSA to be implementation mistakes
and would like to see find and findAll replace querySelector[All] in all
cases, so maybe we don't need a matchesSelector then?



 As a longtime Web developer (and trainer of other Web developers) it is
 important to me to have consistency in naming above all else. JS libraries
 can always alias / wrap these names should they so desire. Name shortening
 has already been occurring... if we had followed 'old W3C DOM-style
 naming', querySelectorAll() would've been 'documentGetElementsBySelector()'.

 Providing a balance between short names and descriptive names is
 important. One of the things that drives me nuts about the (non-standard)
 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is
 that it is not explicit enough... 'evaluate' what? JS? XPath? CSS?

 While I don't disagree that shorter names could've been chosen all of
 those years ago, as Austin Powers would say, That train has sailed,
 baby...

 Cheers,

 - BIll

 On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote:

  On 25/11/11 6:49 PM, Lachlan Hunt wrote:
  On 2011-11-25 01:07, Sean Hogan wrote:
  On 24/11/11 7:46 PM, Lachlan Hunt wrote:
  On 2011-11-23 23:38, Sean Hogan wrote:
  - If you want to use selectors with :scope implied at the start of
 each
  selector in the selector list (as most js libs currently do) then you
  use find / findAll / matches.
 
  The matches method will not change behaviour depending on whether or
  not there is an explicit :scope because it is always evaluated in the
  context of the entire tree. There is never an implied :scope inserted
  into the selector, so there will not be two alternative matches
 methods.
 
  If and when there is a need for a matching method that does imply
 :scope
  (which I provided a use-case for in
 
 http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html)
  then it could be called matches().
 
  Oh, it wasn't clear that you were talking about a case involving
 explicit reference nodes before.
 
  But adding two separate methods that are only subtly different would
 add more complexity for authors, since the difference will not always be
 obvious where there is no explicit reference nodes supplied and they may
 get them confused.
 
  In fact, with a method that always prepends :scope, it could result in
 an unexpected result in some cases:
 
  e.g.
 
root.matches(html.foo);
root.matchesSelector(html.foo);
 
  These aren't obviously different, but when you consider that the first
 would always prepend :scope under your proposal, the first would
 unexpectedly return false, since it's equivalent to:
 
root.matchesSelector(:scope html.foo);
 
  This would happen whether the root element is the root of the document,
 or the root of a disconnected tree.
 
  We could instead address your use case by implying :scope if a
 refElement or refNodes is supplied.  That way, if the author calls
 .matches() without any refNodes, they get the expected result with no
 implied :scope.  If they do supply refNodes, and there is no explicit
 :scope, then imply :scope at the beginning.
 
  This approach would be completely backwards compatible with the
 existing implementations, as nothing changes until refNodes/refElement and
 :scope are supported.
 
 
  You mentioned this before, but anyway:
 
  el.matches(div span) - ok
 
  el.matches( div span) - throws, because no :scope implied
 
  el.matches(div :scope span) - ok, but can't match anything
  el.matches( div span, refNode) - ok
  el.matches(div :scope span, refNode) - ok
 
  el.matches(div span, refNode) - what does this do? How do you know
 that the intention isn't to just ignore the refNode if there is no explicit
 :scope?
 
  I guess if you wanted this last behavior, you could call something like
 /:scope\b/.test(selector)
  before-hand and if it is false then not pass the refNode to matches().
 
  I'm not sure if there are other problematic cases.
 
  Sean
 
 





Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-29 Thread John-David Dalton
 so maybe we don't need a matchesSelector then?

We totally need a matchesSelector. It's perfect for event delegation.
In Diego Perini's NWMatcher his `match` method is what drives the lib.
https://github.com/dperini/nwmatcher/blob/master/src/nwmatcher-base.js#L391

Though he avoids the matchesSelector API at the moment because the
cost of testing/avoiding cross-browser bugs kills any perf gains.
https://github.com/dperini/nwmatcher/commit/10a48ac54c3673c125c540447bb74c75cd1a9ed4

-JDD

On Tue, Nov 29, 2011 at 10:26 PM, Yehuda Katz wyc...@gmail.com wrote:

 Yehuda Katz
 (ph) 718.877.1325


 On Fri, Nov 25, 2011 at 7:49 AM, William Edney bed...@technicalpursuit.com
 wrote:

 All -

 I'm going to throw my 2 cents in here and say that, whatever ends up
 happening with scoping, that the equivalent of the current
 querySelector()/querySelectorAll() should be named matchesSelector().


 I'd be ok with querySelector/querySelectorAll/matchesSelector and
 find/findAll/matches

 As I have said, I personally consider qS/qSA to be implementation mistakes
 and would like to see find and findAll replace querySelector[All] in all
 cases, so maybe we don't need a matchesSelector then?



 As a longtime Web developer (and trainer of other Web developers) it is
 important to me to have consistency in naming above all else. JS libraries
 can always alias / wrap these names should they so desire. Name shortening
 has already been occurring... if we had followed 'old W3C DOM-style naming',
 querySelectorAll() would've been 'documentGetElementsBySelector()'.

 Providing a balance between short names and descriptive names is
 important. One of the things that drives me nuts about the (non-standard)
 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is
 that it is not explicit enough... 'evaluate' what? JS? XPath? CSS?

 While I don't disagree that shorter names could've been chosen all of
 those years ago, as Austin Powers would say, That train has sailed,
 baby...

 Cheers,

 - BIll

 On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote:

  On 25/11/11 6:49 PM, Lachlan Hunt wrote:
  On 2011-11-25 01:07, Sean Hogan wrote:
  On 24/11/11 7:46 PM, Lachlan Hunt wrote:
  On 2011-11-23 23:38, Sean Hogan wrote:
  - If you want to use selectors with :scope implied at the start of
  each
  selector in the selector list (as most js libs currently do) then
  you
  use find / findAll / matches.
 
  The matches method will not change behaviour depending on whether or
  not there is an explicit :scope because it is always evaluated in the
  context of the entire tree. There is never an implied :scope inserted
  into the selector, so there will not be two alternative matches
  methods.
 
  If and when there is a need for a matching method that does imply
  :scope
  (which I provided a use-case for in
 
  http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html)
  then it could be called matches().
 
  Oh, it wasn't clear that you were talking about a case involving
  explicit reference nodes before.
 
  But adding two separate methods that are only subtly different would
  add more complexity for authors, since the difference will not always be
  obvious where there is no explicit reference nodes supplied and they may 
  get
  them confused.
 
  In fact, with a method that always prepends :scope, it could result in
  an unexpected result in some cases:
 
  e.g.
 
    root.matches(html.foo);
    root.matchesSelector(html.foo);
 
  These aren't obviously different, but when you consider that the first
  would always prepend :scope under your proposal, the first would
  unexpectedly return false, since it's equivalent to:
 
    root.matchesSelector(:scope html.foo);
 
  This would happen whether the root element is the root of the document,
  or the root of a disconnected tree.
 
  We could instead address your use case by implying :scope if a
  refElement or refNodes is supplied.  That way, if the author calls
  .matches() without any refNodes, they get the expected result with no
  implied :scope.  If they do supply refNodes, and there is no explicit
  :scope, then imply :scope at the beginning.
 
  This approach would be completely backwards compatible with the
  existing implementations, as nothing changes until refNodes/refElement and
  :scope are supported.
 
 
  You mentioned this before, but anyway:
 
  el.matches(div span) - ok
 
  el.matches( div span) - throws, because no :scope implied
 
  el.matches(div :scope span) - ok, but can't match anything
  el.matches( div span, refNode) - ok
  el.matches(div :scope span, refNode) - ok
 
  el.matches(div span, refNode) - what does this do? How do you know
  that the intention isn't to just ignore the refNode if there is no explicit
  :scope?
 
  I guess if you wanted this last behavior, you could call something like
     /:scope\b/.test(selector)
  before-hand and if it is false then not pass the refNode to matches().
 
  I'm not sure if there are other 

  1   2   3   4   5   6   >