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

[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
"undefined"s 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] RfC: LCWD of Selectors API Level 1; deadline July 19

[Tab Atkins Jr.]

On Mon, Aug 6, 2012 at 7:13 PM, Kang-Hao (Kenny) Lu  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

[Kang-Hao (Kenny) Lu]

(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

> 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].


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

[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:

  


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

[Tab Atkins Jr.]

On Mon, Aug 6, 2012 at 4:25 AM, Lachlan Hunt  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
>> "undefined"s 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

[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
"undefined"s 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

[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
"undefined"s 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 "undefined"s, 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

[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

[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

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

[Lachlan Hunt]

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

Arthur Barstow  wrote:


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



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/

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

[Stewart Brodie]

Arthur Barstow  wrote:

> This is a Request for Comments for the June 28 Last Call Working Draft 
> of Selectors API Level 1:
> 
> 
> 
> 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