Warn that Infra's and XML's notion of ascii whitespace aren't the same.

[jyasskin]

This change is inspired by Candidate Correction 4 in EPUB, where they accidentally used the Infra definition of whitespace where they'd meant the XML one. See w3c/epub-specs#2637 by @mattgarrish. Their citation is to XML 1.0, but the definitions are the same between 1.0 and 1.1.

I'm not tied to the exact wording here, but it seems worth warning about the semantic difference as Infra gets more widely used in non-HTML contexts.

---

Preview | Diff

[domenic]

LGTM although I'd like @annevk to take a look and in particular comment on XML 1.1 vs. other versions, as I remember there being some confusion there about whether 1.1 is actually used.

[annevk]

WebKit has a "ASCII whitespace without FF" definition that is used for JSON/HTTP/XML. Perhaps we should add the same definition to Infra?

See also https://fetch.spec.whatwg.org/#http.

And yeah, it's not clear to me that 1.1 is actually supported. Chromium and WebKit seem rather lenient and allow data:text/xml,<?xml version="1.2"?><test/> which I don't think is permitted by the XML specifications, and Gecko rejects that and also rejects 1.1.

[jyasskin]

I'm happy with any of Anne's suggestions. It sounds like referring to XML 1.0 is clearly better. What name do y'all prefer for the new whitespace-sans-FF definition?

[domenic]

I would slightly prefer not introducing a new definition. Because, I doubt XML, JSON, or HTTP specifications will update to be based on Infra, and I think we prefer that other specifications match "the rest of the web" when possible instead of adopting the without-FF definition.

However, it could be good to update the note to something like:

The XML, JSON, and HTTP specifications exclude U+000C FF in their definition of whitespace:

• [Link to XML's definition]
• [Link to JSON's definition]
• [Link to HTTP's definition]

Prefer using Infra's [ASCII whitespace] definition for new features, unless your specification deals exclusively with XML/JSON/HTTP.

(maybe it should even be a class="warning" instead of class="note".)

WDYT?

(I'm also happy to land this PR as-is and iterate on something like the above in a followup, because I don't want to require you to do more work on top of what is already a clear, helpful improvement.)

[jyasskin]

Done. I'm not sure of the HTTP citation because HTTP itself says whitespace is just space and tab. Fetch and mimesniff include CR/LF and FF inconsistently. So I went with "parts of HTTP" and a link to the Fetch definition. I don't have a strong opinion between note and warning.

[domenic]

Looks great, will give @annevk a day or two to check it as well.