JP22: character reference inconsistency in 20.1.3.2, 20.1.3.3 and 20.1.3.5

[akr]

In the sections 20.1.3.2 (Number.prototype.toExponential), 20.1.3.3 (Number.prototype.toFixed) and 20.1.3.5 (Number.prototype.toPrecision), characters are referenced inconsistently.
For example, 20.1.3.2 step 13.b. and 20.1.3.3 step 10.c.iv refers a character as "." but
20.1.3.5 step 12.c.iii refers it as "code unit 0x002E (FULL STOP)".

Unicode character names identify the characters more reliably than the character glyphs.

[bterlson]

I tend to think the character names are unnecessary. In this case it'd be pretty easy to use the character name as we're talking about one character, but morally the same would apply to any multi-character strings used in the document. I will fix the inconsistency by making 20.1.3.5 step 12.c.iii use ".".

[bterlson]

I tend to think the character names are unnecessary. In this case it'd be pretty easy to use the character name as we're talking about one character, but morally the same would apply to any multi-character strings used in the document. I will fix the inconsistency by making 20.1.3.5 step 12.c.iii use ".".

[bterlson]

Removing all mentions of "code unit X (NAME)" would be a good regexp replace someone could do. One concern would be tough-to-read code units like HYPHEN-MINUS, but since we consider the HTML normative now (and printed copies non-normative), and the HTML actually has the code point we want in its source, I think this is fine. What do you think?

[bterlson]

Removing all mentions of "code unit X (NAME)" would be a good regexp replace someone could do. One concern would be tough-to-read code units like HYPHEN-MINUS, but since we consider the HTML normative now (and printed copies non-normative), and the HTML actually has the code point we want in its source, I think this is fine. What do you think?

[ljharb]

Should the string padding proposal then use " " to indicate a single space? Or is the code point helpful there (and should the formatting be tweaked)?

[ljharb]

Should the string padding proposal then use " " to indicate a single space? Or is the code point helpful there (and should the formatting be tweaked)?

[anba]

The code unit notation is definitely helpful when U+0020 SPACE is used, for example I didn't realize SIMD ToString uses ", " (U+002C U+0020) instead of "," (U+002C) until running the SIMD test suite.

[anba]

The code unit notation is definitely helpful when U+0020 SPACE is used, for example I didn't realize SIMD ToString uses ", " (U+002C U+0020) instead of "," (U+002C) until running the SIMD test suite.

[bterlson]

@anba yeah, totally agreed. "Easily confused" characters should probably continue to use character names (including all form of dashes and spaces).

[bterlson]

@anba yeah, totally agreed. "Easily confused" characters should probably continue to use character names (including all form of dashes and spaces).

[ljharb]

Is there a formatting convention that should be followed for this case?

[ljharb]

Is there a formatting convention that should be followed for this case?