Not all valid attribute names can be parsed

[karfau]

This is a continuation of jindw/xmldom#267 which already contains an elaborate discussion.

Two examples that are used in vue, are attributes starting with : or @.

According to the XML 1.1 spec https://www.w3.org/TR/xml11/#sec-common-syn:

The Namespaces in XML Recommendation [XML Names] assigns a meaning to names containing colon characters. Therefore, authors should not use the colon in XML names except for namespace purposes, but XML processors must accept the colon as a name character.

But according to the latest HTML spec, in which namespaces are not something to consider, the definition of what is allowed in attribute names is different: https://html.spec.whatwg.org/multipage/syntax.html#attributes-2

[karfau]

We will need to understand how this would impact the current parsing of attributes with a namespace prefix. Nothing should change when parsing XML

We also need to decide whether there should be a different behavior for XML vs HTML.
According to the next comment, there needs to be different behavior, so this is blocked by the upcoming solution for #203 which is why this issue is not considered a "next release priority" before 203 has been resolved and released.

Contributions to resolve this are of course welcome, either by discussing details here or (after the resolution of 203!) by providing a PR including tests.

[marrus-sh]

So, to add additional context to this, the mentioned Namespaces in XML Recommendation introduces a new concept known as “namespace-well-formed” which requires element and attribute names to match the QName production, and other names to match the NCName production, from that specification XML Names. QName notably forbids leading colons in attribute names, so while :foo is a well‐formed XML Name, it does not produce namespace‐well‐formed documents.

Because XML parsing for the DOM is namespace‐aware, documents need to be namespace‐well‐formed in addition to just being ordinarily well‐formed. So it should produce an error when parsing as XML.

HTML’s rules have been made considerably more lax in order to support data-* attributes and HTML custom elements. Importantly, it is entirely possible to write an HTML custom element with a :foo attribute. So ideally you would have different behaviour here.

[karfau]

@marrus-sh Thank you, that was very helpful. I updated my last comment accordingly.

[Kevin44]

It also appears that there is a problem with the attribute "constructor" also. Here is an example element with that attribute that it is failing on:

<java:new doc:name="Get date instance" doc:id="f5784e1d-4a0d-428f-9833-9f33694bbf10" class="java.util.Date" constructor="Date()" target="dateVar"/>

[marrus-sh]

This appears to be because the attributes are stored on an ordinary empty object {}, and attribute presence is checked using the in operator, which walks the prototype chain. "constructor" in {} returns true, because constructor is a property on Object.prototype. (A similar problem should exists with any other property defined on Object.prototype, like toString or valueOf.)

To fix this, one of the following approaches can be taken:

• The attributes object can be created without a prototype (Object.create(null))
• Attributes can be stored in a Map instead of an Object
• Object.prototype.hasOwnProperty() can be used instead of in to check for property presence

[karfau]

Interesting finding and thx a lot for tge investigation.
The check using in was added very recently, so I would prefer to switch to hasOwnProperty.

This also means the issue about constructor is different from the one in the description of this issue, so we should split it out.
PRs welcome

[karfau]

FYI: The issue regarding attribute names conflicting with the prototype chain was solved and released as 0.7.4