- From: <bugzilla@jessica.w3.org>
- Date: Tue, 05 Jun 2012 09:42:32 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17298 Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kennyluck@csail.mit.edu --- Comment #5 from Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu> 2012-06-05 09:42:31 UTC --- (In reply to comment #0) > This makes it essentially impossible to extend the HTML fragment identifier > syntax with new addressing schemes such as > <http://simonstl.com/articles/cssFragID.html> or with XPointer. I think this depends on whether @id ends up overriding XPointer or the reverse. For example, "top" is still a valid ID even if #top has a default scrolling behavior written in the spec. (In reply to comment #3) > How about limiting it to (NameChar)*? This still prohibits most ASCII > punctuation, and I'm not at all sure that's a good idea. If we really want an > extension point, one character should be enough. What's wrong with assigning > special meaning to something involving a space, say? Both cssFragID and XPointer use parenthesis. So do you mean '(' and ')'? Can someone remind me why we reserve ID with space in it at first place? Is that for the purpose of letting conformance checker issues an error in case that an author thinks a space delimits multiple IDs in @id ? If helping authors is a goal here, I would instead suggest we require conformance chekcker issue an warning when @id or @class don't match IDENT in CSS as it's common error that authors think selecting an @id like "1st" or "2nd" would work in CSS. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 5 June 2012 09:42:39 UTC