fix: Normalize white space characters and preserve references in attributes

[karfau]

• Added normalization of white space literal characters as specified in https://www.w3.org/TR/xml/#AVNormalize, they now appear as space(s) in the attribute values when accessed from the DOM (and are also serialized as space)
• Added serialization of white space literal values to to the correct numerical character references as described in Attribute value serialization does not take whitespace normalization into account w3c/DOM-Parsing#59 to fix Incorrect serialization of XML attributes containing white space #284

BREAKING CHANGE: If you relied on the not spec compliant preservation of \t, \n or \r in attribute values. To preserve those you will have to create XML that instead contains the correct numerical (or hexadecimal) equivalent (	, 
, 
).

[brodycj]

• Added normalization of white space literal characters as specified in https://www.w3.org/TR/xml/#AVNormalize,
  [...]

I don't see support or testing of the referenced "end-of-line handling". Should we add this or am I missing something here?

[karfau]

@brodybits yes, this is something that xmldom currently doesn't do and I consider this as a change outside of the scope of this fix.
But even though I mentioned it in the related issue, I'm also surprised that I didn't put a comment or note about it here.
Will add that.

[brodycj]

Thanks for raising ... and proposing a solution for #303.

But TBH I felt a bit surprised to see the solution for #303 kept in a separate PR due to multiple factors:

• the end-of-line handling is referenced as part of the section in https://www.w3.org/TR/xml/#AVNormalize
• issue Incorrect serialization of XML attributes containing white space #284 is about whitespace, and I would have considered the end-of-line characters to be a form of whitespace

I got a couple of test snapshot errors when I merged these updates together with the updates proposed in PR #305, which I would consider to be a little bit of rapid snapshot churn.

Thoughts?

Am I too pedantic here?

[brodycj]

• I think we need to remove .only from a test in one place, guessing it was just an oversight - now fixed
• suggesting to add some spaces & blank lines

Code changes look good overall, +1 (+100) for cleaning up & removing what looks like repeated regex replacements.

[karfau]

Regarding .only, thx. I think we should add an eslint rule to prevent such things from slipping through.

Regarding the split of issues:

1. All line breaks must have been normalized on input to #xA as described in 2.11 End-of-Line Handling, so the rest of this algorithm operates on text normalized in this way.

For me sounds more like like a prerequisite than a part of the algorithm. So I propose the I land the PR for line endinge normalization first. And then deal with the issues in this PR. Or even rebase this one on top of the other to see the impact right away.
I would still prefer to land them in two separate PRs, since they are separate sections in the specs.

Thx for going as as trying to merge them both.

[brodycj]

Yeah I would favor landing PR #305 first. +1 for adding eslint rules to keep things like .only from slipping in. The Prettier project seems to have been using some nice eslint rules as well.

[karfau]

Didn't mean to close the PR

[karfau]

Such a mess... the subsequent PR landing seems to only work when the branches are all in the same repository.
So I rebased and recreated the PR in #310