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/
