Re: [css-houdini-drafts] Should we be using DOMString, USVString, or CSSOMString?

I don't want to get into a debate over the word "mistake", let me rephrase: JS strings based on 16 bit values were from a time when it was believed this would be sufficient to represent all unicode codepoints (I was there). If we were building JS from scratch today, we wouldn't allow unpaired surrogates in strings. Carrying this forward is a burden, if we have a chance to fix it, we should at least think about it very carefully and weigh the pros and cons.

Again, if that's already been done, and the decision was "too late, we just have to live with this forever, suck it up", then fine, but I'd like to see the records of that discussion, and clear documentation of the outcome.

I've read that section of Web IDL and I don't find it sufficiently clear (apparently the same is true for others or we wouldn't ever have been discussing DOMString vs USVString here). Define "perform text processing" (as opposed to working with text in strings, or text from the DOM for that matter, isn't that _all_ text processing?), what is the rationale behind "When in doubt"?

If the current thinking is use USVString only for URLs, and other strings that have specific similar needs, I'd like to see that stated explicitly and a list of exactly what those needs are so rational decisions can be made, not just default due to doubt (which comes from not understanding the issue and then leads to bad decisions).

-- 
GitHub Notification of comment by plinss
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/687#issuecomment-367761865 using your GitHub account

Received on Thursday, 22 February 2018 17:44:08 UTC