provide clearer advice about USVString vs. DOMString

[dbaron]

provide clearer advice about USVString vs. DOMString

[SimonSapin]

Right, CSSOMString probably does not have its place in this WebIDL spec note. This was only a response to "not sure what other scenarios there might be".

[annevk]

The plan is to rephrase this in terms of https://infra.spec.whatwg.org/#strings and use JavaScript (for DOMString) and scalar value string (for USVString) from there. Is the difference sufficiently clear there?

[SimonSapin]

@annevk I think you’re response is about what each of the two types are, while @dbaron’s comment was about why and in what situations is one recommended over the other. I agree that it is unclear where “APIs that perform text processing” applies.

[annevk]

No, it specifically calls out UTF-8 encode as a place where USVString applies. I haven't really countered another place, though the source does mention Rust subsystems as something where this might make sense, but since Rust isn't used on a large scale that's not super relevant yet.

[domenic]

So concretely, I think we should point out that USVString should be used for URLs or for strings that are to be sent "over the wire". I'm not sure what other scenarios there might be.

[SimonSapin]

For what it’s worth, Firefox’s ongoing style system rewrite uses UTF-8 strings internally. This effectively makes CSSOM strings be USVString. CSSWG resolved to allow both, so w3c/csswg-drafts#1266 introduced a CSSOMString typedef.

[domenic]

Right... I don't think we want to propogate such implementation-specific quirks throughout the platform via Web IDL advice.