Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
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] RfC: LCWD of Selectors API Level 1; deadline July 19
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
(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
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
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
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
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
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
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/
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
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
