Re: [whatwg/dom] Valid/Invalid characters in document.createElement() (#849)

Alternate approach suggested by @annevk: be maximally lenient in the DOM APIs. The difference from the above would be something like:

- For element local names, element prefixes, attribute local names, and attribute prefixes: all characters can be anything except tab, LF, CR, FF, space, /, >, NULL.
- So in particular:
  - The first character of an element local name is much more lenient
  - Prefixes are much more lenient (although they still cannot contain : by construction)
  - Attribute local names can contain = after the first character

The upside of this is that it simplifies the spec and implementation a good bit. The intention of the current restrictions from the XML spec seems to be a misguided segmentation of Unicode which hasn't really panned out in practice. It might also give small performance wins; it's hard to say since on the one hand this is definitely a microoptimization, but on the other hand `createElement()` / `setAttribute()` / etc. are called quite often in modern web apps.

The downside is that this allows more cases where DOM APIs can produce unparseable HTML. I.e., currently you can produce HTML which does not survive a parse-serialize roundtrip using something like `document.createElement("_a")`. That is kind of sad. This more-lenient version would expand the number of cases where that's possible, to include things like `document.createElement("$a")`. Whereas the version in https://github.com/whatwg/dom/issues/849#issuecomment-1007541209 would disallow `$a` (while continuing to allow `_a`).

Additionally, if we're giving up on parse-serialize roundtrips anyway, it's not clear whether disallowing tab, LF, CR, FF, space, /, >, NULL is important either! We could just allow any string...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/849#issuecomment-1007646723
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/849/1007646723@github.com>

Received on Friday, 7 January 2022 18:43:46 UTC