Change Proposal for ISSUE-150 - Revision history

Hixie at 03:06, 16 June 2011

2011-06-16T03:06:08Z

← Older revision		Revision as of 03:06, 16 June 2011
Line 24:		Line 24:

	Editors will not feel micromanaged. W3C consistency can still be pursued at a higher level and applied retroactively later. Interoperability is not risked.		Editors will not feel micromanaged. W3C consistency can still be pursued at a higher level and applied retroactively later. Interoperability is not risked.


			[[Category:W3C Issue]]

Hixie at 21:55, 6 February 2011

2011-02-06T21:55:08Z

← Older revision		Revision as of 21:55, 6 February 2011
Line 8:		Line 8:

	With any edit of this scale, errors are made. Given the sensitive nature of the particular topic at hand, these errors could be especially bad, ranging for interoperability errors (where different browsers implement different rules because they were done before or after the edit), to validators giving bad advice (because of inconsistencies between sections giving authoring conformance criteria and sections giving implementation requirements), to introducing oddities into the platform (e.g. using an unusual character for separating a list).		With any edit of this scale, errors are made. Given the sensitive nature of the particular topic at hand, these errors could be especially bad, ranging for interoperability errors (where different browsers implement different rules because they were done before or after the edit), to validators giving bad advice (because of inconsistencies between sections giving authoring conformance criteria and sections giving implementation requirements), to introducing oddities into the platform (e.g. using an unusual character for separating a list).

			Listing the code point, the character name, and including the character itself is the least ambiguous way of referring to Unicode characters and thus the way most likely to lead to good interoperability. Omitting the character name would lead to readers unfamiliar with Unicode codepoints confusing characters such as the U+0031 DIGIT ONE character (1), the U+0049 LATIN CAPITAL LETTER I character, the U+006C LATIN SMALL LETTER L character, and the U+007C VERTICAL LINE character (\|). Omitting the code points would lead to implementors making mistakes when looking up the code points (which are often needed to implement the requirements). Omitting the character would lead to worse readability for people for whom English is not their first language, or who are are not familiar with the names of punctuation characters.

			Listing the code point, the character name, and including the character itself provides redundancy that reviewers can use to check for unintentional mistakes. Omitting one or two of these leads to a higher likelihood that errors will be missed. (The redundancy has already caught numerous problems like this, in fact.)

			Omitting the character name can lead to extra confusion when control characters and characters with no glyphs are shown next to characters with glyphs. For example, "U+000A (LF), U+0020 ( ), and U+0031 (1)" is much more confusing than "U+000A LINE FEED (LF) character, U+0020 SPACE character, and U+0031 DIGIT ONE character (1)" to someone unfamiliar with code points. Listing the character name as well makes such lists much easier to skim and understand.

			Just listing the code point and the character is atheistically displeasing in lists, especially when including characters for which no glyph can be shown (e.g. U+000A LF). Including the name only for control characters is leads to a very unbalanced feel for the specification text. Thus, all three need to be included for the text to be pleasant to read in lists. Being consistent throughout (in lists and outside lists) leads to fewer editing mistakes, which is important in achieving the goal of interoperability.

	==Details==		==Details==
Line 15:		Line 23:
	==Impact==		==Impact==

	Editors will not feel micromanaged. W3C consistency can still be pursued at a higher level and applied retroactively later.		Editors will not feel micromanaged. W3C consistency can still be pursued at a higher level and applied retroactively later. Interoperability is not risked.

Hixie: /* Rationale */

2011-02-06T21:42:45Z

Rationale

← Older revision		Revision as of 21:42, 6 February 2011
Line 6:		Line 6:

	Pushing for details such as how to write down Unicode character names only makes sense if all W3C specifications were using the same notation. As they are not using the same notation this problem is greater than HTML5 and cannot be solved by this Working Group micromanaging its editors.		Pushing for details such as how to write down Unicode character names only makes sense if all W3C specifications were using the same notation. As they are not using the same notation this problem is greater than HTML5 and cannot be solved by this Working Group micromanaging its editors.

			With any edit of this scale, errors are made. Given the sensitive nature of the particular topic at hand, these errors could be especially bad, ranging for interoperability errors (where different browsers implement different rules because they were done before or after the edit), to validators giving bad advice (because of inconsistencies between sections giving authoring conformance criteria and sections giving implementation requirements), to introducing oddities into the platform (e.g. using an unusual character for separating a list).

	==Details==		==Details==

Annevk: Created page with '==Summary== Do not micromanage editors on editorial details. ==Rationale== Pushing for details such as how to write down Unicode character names only makes sense if all W3C s...'

2011-02-06T21:10:44Z

Created page with '==Summary== Do not micromanage editors on editorial details. ==Rationale== Pushing for details such as how to write down Unicode character names only makes sense if all W3C s...'

New page

==Summary==

Do not micromanage editors on editorial details.

==Rationale==

Pushing for details such as how to write down Unicode character names only makes sense if all W3C specifications were using the same notation. As they are not using the same notation this problem is greater than HTML5 and cannot be solved by this Working Group micromanaging its editors.

==Details==

No change.

==Impact==

Editors will not feel micromanaged. W3C consistency can still be pursued at a higher level and applied retroactively later.