This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Example: "a valid non-negative integer, followed by a U+003B SEMICOLON character (;), followed by one or more space characters, followed by a substring that is an ASCII case-insensitive match for the string "URL", followed by a U+003D EQUALS SIGN character (=), followed by a valid URL." It's unclear to me why we can't just call the characters my name, or mention them verbatim. The current style of prose makes the spec hard to read. Sets and sequences of code points that appear frequently could be assigned names upfront, see, for instance, <http://greenbytes.de/tech/webdav/rfc5234.html#rfc.section.B.1>.
See also conversation around <http://krijnhoetmer.nl/irc-logs/whatwg/20101018#l-184>.
For CSSOM whenever it is not a simple string of more than one character I use "<code>CHARACTER</code>" (U+XXXX). E.g. "<code>(</code>" (U+0028). For certain characters I use something slightly different, e.g. space (U+0020). I guess at some point we should set up some kind of style guide.
(In reply to comment #0) > Sets and sequences of code points that appear frequently could be assigned > names upfront, see, for instance, > <http://greenbytes.de/tech/webdav/rfc5234.html#rfc.section.B.1>. I disapprove of the RFC style of giving ad hoc names to Unicode characters. I object to using that style in HTML5. I want to see the Unicode code point in the U+hhhh notation and the literal character inline in the spec prose without indirection. I don't care about the UPPERCASE UNICODE NAME, but what's in the spec now works for me.
I think the UPPERCASE NAME is excessive. Just give the character itself and the code point, like """ a valid non-negative integer, followed by ";" (U+003B), followed by one or more space characters, followed by a substring that is an ASCII case-insensitive match for the string "URL", followed by "=" (U+003D), followed by a valid URL. """ or maybe """ a valid non-negative integer, followed by U+003B (;), followed by one or more space characters, followed by a substring that is an ASCII case-insensitive match for the string "URL", followed by U+003D (=), followed by a valid URL. """ or whatever. It's more concise and easier to read, but no less precise. You should only need to give a name when the character is whitespace or a combining diacritic or something, and in that case you should just use a simple description like "space", "tab", "CR", "LF", not the full Unicode name. (In reply to comment #3) > I disapprove of the RFC style of giving ad hoc names to Unicode characters. I > object to using that style in HTML5. It's already used in some places, e.g., "space characters".
(In reply to comment #3) > (In reply to comment #0) > > Sets and sequences of code points that appear frequently could be assigned > > names upfront, see, for instance, > > <http://greenbytes.de/tech/webdav/rfc5234.html#rfc.section.B.1>. > > I disapprove of the RFC style of giving ad hoc names to Unicode characters. I > object to using that style in HTML5. This is not "the" RFC style. There is no single RFC style. It's just an example. Also, I should have mentioned that I'm mainly interested in *ASCII* characters; I have no problem with the spec keeping the level of verbosity for characters outside the ASCII range. Finally, calling Carriage Return and Line Feed "CR" and "LF" may be "ad hoc", but it's certainly something readers understand. > I want to see the Unicode code point in the U+hhhh notation and the literal > character inline in the spec prose without indirection. I don't care about the > UPPERCASE UNICODE NAME, but what's in the spec now works for me. I think getting rid of the UPPERCASE UNICODE NAME (move it into title attribute, or make it a link?) would be a vast improvement. That being said, I'd like to understand why you think it's a bad idea to define once for all a few sets, such as DIGIT, ALPHA or HEXDIGIT. Unless I'm mistaken the spec already does this for other things, such as whitespace characters.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I like it the way it is.
http://www.w3.org/html/wg/tracker/issues/150
Decision: http://lists.w3.org/Archives/Public/public-html/2011Jul/0213.html Change Proposal: http://lists.w3.org/Archives/Public/public-html/2011Feb/0120.html
mass-moved component to LC1
(In reply to comment #8) > Decision: > http://lists.w3.org/Archives/Public/public-html/2011Jul/0213.html > > Change Proposal: > http://lists.w3.org/Archives/Public/public-html/2011Feb/0120.html Something went wrong here. This bug rightly should never have been escalated to an issue to begin with. Do we really want to be using to micro-manage editorial choices about which there are a variety of not-particularly-strong opinions and that therefore amount purely to judgement calls that properly are best left up to editorial discretion -- and that have no effect either way on actual implementation conformance criteria? This change is something that would require a significant amount of manual work on the part of an editor to change. And to what end? How does this rank as a priority with other actually important that need to be done?
(In reply to comment #10) > (In reply to comment #8) > > Decision: > > http://lists.w3.org/Archives/Public/public-html/2011Jul/0213.html > > > > Change Proposal: > > http://lists.w3.org/Archives/Public/public-html/2011Feb/0120.html > > Something went wrong here. > > This bug rightly should never have been escalated to an issue to begin with. Indeed. > Do we really want to be using to micro-manage editorial choices about which > there are a variety of not-particularly-strong opinions and that therefore > amount purely to judgement calls that properly are best left up to editorial > discretion -- and that have no effect either way on actual implementation > conformance criteria? Yes, this is exactly what the WG Chairs would like to do, AFAICT from their decisions. Unfortunately, you're paid to deal with their stupidity.
(In reply to comment #11) > Yes, this is exactly what the WG Chairs would like to do, AFAICT from their > decisions. Unfortunately, you're paid to deal with their stupidity. No. First off, I think we can all agree that we need to remain civil and respectful in discussions here in bugzilla, just as we do on our mailing lists. Doing otherwise is just an unproductive use of everybody's time. So let's please not do that. We're all of use here working together to solve problems. So let's try to do that and not resort to incivilities and name calling. Please. So, that said, I regret posting my most recent comment. That comment doesn't reflect what I really think. The only excuse I can make for posting it is that I was at the time (very late on Sunday evening...) in the midst of going through dozens of unresolved LC bugs to figure out what actions needed to be taken to move them further toward resolution. I should have waited before I posted that comment. But I didn't, so here we are now. Going forward, I'll make an effort to think things through more carefully before posting comments. So let's please leave it at that and get back to working together on getting stuff done in the best ways we can.
BTW if anyone can write a self-contained perl or python script that can be run against the file here: http://dev.w3.org/html5/spec/Overview.html ...that applies this decision, that would make my life a lot easier. (If you are interested in doing that let me know and I can help you — there might be things I can do to make it simpler, e.g. applying it at a different point in the pipeline.)
(In reply to comment #13) > BTW if anyone can write a self-contained perl or python script that can be run > against the file here: > > http://dev.w3.org/html5/spec/Overview.html > > ...that applies this decision, that would make my life a lot easier. (If you > are interested in doing that let me know and I can help you — there might be > things I can do to make it simpler, e.g. applying it at a different point in > the pipeline.) Julian?
(In reply to comment #14) > (In reply to comment #13) > > BTW if anyone can write a self-contained perl or python script that can be run > > against the file here: > > > > http://dev.w3.org/html5/spec/Overview.html > > > > ...that applies this decision, that would make my life a lot easier. (If you > > are interested in doing that let me know and I can help you — there might be > > things I can do to make it simpler, e.g. applying it at a different point in > > the pipeline.) > > Julian? If somebody can supply a sample that can be extended, I can give it a try (my choice would be XSLT2, but it would affect source formatting....)
(In reply to comment #13) > BTW if anyone can write a self-contained perl or python script that can be run > against the file here: > > http://dev.w3.org/html5/spec/Overview.html perl -pe 'undef $/; s/(U\+[A-F0-9]{4})\s[A-Z\s-]+(\scharacter(s)?)?\s\((.{1,3})\)/"$4" \($1\)$2/g' Overview.html
(In reply to comment #13) > BTW if anyone can write a self-contained perl or python script that can be run > against the file here: > > http://dev.w3.org/html5/spec/Overview.html > > ...that applies this decision, that would make my life a lot easier. (If you > are interested in doing that let me know and I can help you — there might be > things I can do to make it simpler, e.g. applying it at a different point in > the pipeline.) I have what I think is a complete script that attempts to implement both parts of the change proposal and that seems to work as expected: http://people.w3.org/mike/fixes/bs.pl
(In reply to comment #17) > (In reply to comment #13) > > BTW if anyone can write a self-contained perl or python script that can be run > > against the file here: > > > > http://dev.w3.org/html5/spec/Overview.html > > > > ...that applies this decision, that would make my life a lot easier. (If you > > are interested in doing that let me know and I can help you — there might be > > things I can do to make it simpler, e.g. applying it at a different point in > > the pipeline.) > > I have what I think is a complete script that attempts to implement both parts > of the change proposal and that seems to work as expected: > > http://people.w3.org/mike/fixes/bs.pl Mike, thanks A LOT for working on this; I think it's a great starting point. Maybe, to move forward, we can split this into two subtasks; definining the character classes and using them, and then reduce the remaining verbosity? I *believe* the first one should be less controversial. It also seems that applying the patch may require some grammar post-tuning; I'm happy to help with that once we agree on how to proceed.
I found some problems in the output from script and have updated the script to fix them. http://people.w3.org/mike/fixes/bs.pl
This seems to have some problems in http://dev.w3.org/html5/spec/the-script-element.html#restrictions-for-contents-of-script-elements
Would be appropriate to mark this resolved and then file bugs on specific cases where the test is failing?
(In reply to comment #19) > I found some problems in the output from script and have updated the script to > fix them. > > http://people.w3.org/mike/fixes/bs.pl Ported to Python: https://github.com/w3c/html/commit/1961b9f61501f0fc3801e0ac20a38ab43b9ef0fe
Filter on [Idon'tcareaboutHTMLWGbugspam].
Output from spec splitter after running this script: warning: can't find target for #ascii-digits warning: can't find target for #conforming-documents warning: can't find target for #lowercase-ascii-letters warning: can't find target for #uppercase-ascii-letters
Unless we hear otherwise, we are going to assume that this change is complete, and that further requests will come in the form of new bugs: http://lists.w3.org/Archives/Public/public-html/2012Aug/0398.html http://lists.w3.org/Archives/Public/public-html/2012Aug/0404.html
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: https://github.com/w3c/html/commit/1961b9f61501f0fc3801e0ac20a38ab43b9ef0fe and https://github.com/w3c/html/commit/c68e86b4736f4e7a11c4209a06976ec0618529bd Rationale: Resolving per Sam's comment.