- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Mon, 08 Oct 2012 16:27:24 +0200
- To: "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com>
- CC: WebApps Working Group <public-webapps@w3.org>
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/
Received on Monday, 8 October 2012 14:27:57 UTC