Misc spec review feedback

[j9t]

I’ve filed several individual issues as well as section-related PRs, but am feeling free to share the remaining notes in one issue for cherry-picking. I keep it brief, but the brevity does not imply correctness or imposition :)

• The 13.2.1 script block example may not need the ellipses around it
• IANA section 17 begs the question what the status of several submissions is (“will be submitted”)
• Also section 17, check on “Person & email”—“Person and email” seems to read better, and consistent with how the spec is otherwise not making this use of an ampersand, either

General Observations

• Consider reviewing spec code breaks and indentation
• Consider using the typographically correct apostrophes, quotation marks, and ellipses
• Consider not splitting the infinitive
• Replace dashes [and other character references] by actual characters (like — → —)
• Revisit typographically correct use of units (like “60Hz”, “16.7ms”, &c.—these may need a no-break or thin space in between)
• Revisit “Note that…” sentences (this can usually, safely be omitted)
• Some CSS units seem unoptimized (trailing “00”s, leading “0”s)
• Check on use of guillemets (“« … »”) [Suggestion: Revisit spec copy for quote need and consistency #7158 suggests this is correct, but it may be worth reviewing the few cases]
• Check on “e.g.” and “i.e.” comma use consistency (via @annevk, really)
• Check on the spelling of “non-zero” vs. ”nonzero” (the spec uses both) [addressed with docs/nonzero #7194]
• Check on cases of “greater than zero” where there are numerical values and where therefore “0” could be clearer
• Check on spelling of “Base64”, as it usually seems to be written with a capital “B”
• Check on phrases like “in the example above” (“…previous example” may work better)
• Consider rephrasing “View this example online.” texts (the spec is likely viewed online, and these come off as better “click here”s)
• Check on “document.write(),” in code snippets, as it seems to be lacking code formatting

[j9t]

Will use this issue to collect other observations:

• In “An ASCII case-insensitive match for the name _charset_ is special”, the writing of “_charset_” (currently 4.10.18.1) looks like the underscores were a mistake.

[j9t]

• In 13.2.4.2, The part “MathML mi, MathML mo, MathML mn, MathML ms, MathML mtext, and MathML annotation-xml; and SVG foreignObject, SVG desc, and SVG title” (here unformatted) could be rephrased to be easier to read, like “MathML’s mi, mo, mn, ms, mtext, and annotation-xml; and SVG’s foreignObject, desc, and title” (likewise unformatted).
• Similar for “a dd element, a dt element, an li element, an optgroup element, an option element, a p element, an rb element, an rp element, an rt element, or an rtc element,” which would be easier to read if it said, say, “a dd, dt, li, optgroup, option, p, rb, rp, rt, or rtc element.”
• …and again similar for ”s a caption element, a colgroup element, a dd element, a dt element, an li element, an optgroup element, an option element, a p element, an rb element, an rp element, an rt element, an rtc element, a tbody element, a td element, a tfoot element, a th element, a thead element, or a tr element” (both currently in 13.2.6.3).