Align Attribute interface names with Attr from the DOM

[Zirro]

The Attribute interface has four properties named name, namespace, prefix and value. Three of these share their names with the Attr interface of the DOM. However, there namespace is named namespaceURI and the expected value of the name property is actually consistent with localName rather than name in the DOM.

It turns out that this has been a source of minor bugs in jsdom. Our adapter for getAttrList() has been returning a NamedNodeMap with DOM attributes inside. Since the interface is expecting a property named namespace rather than namespaceURI, our HTML serialization has not included namespaces. If we resolve this by changing the property name, it reveals the other problem with the difference between name and localName since name in the DOM is defined as the full qualified name.

To reduce the confusion, I'd like to suggest a breaking change to align the properties of parse5's Attribute interface with the ones from the DOM (as well as make it consistent with parse5's Element interface which also uses namespaceURI), so that namespace becomes namespaceURI and name becomes localName. Since the HTML parsing/serialization specification also refers to "local name" it could help make things clearer in several ways.

It would also avoid the potentially slow operation of renaming properties before passing them to parse5 in jsdom and other consumers with a DOM-based structure.

Potentially related: #231

[inikulin]

I recall discussing similar topic with @domenic some time ago. This puts me in a bit complicated situation: even though from spec perspective it's correct to use such terms as localName, etc. in API, I have a concern that it might be extremely confusing for casual parse5 users who just want to parse their markup and got used to term name rather than localName.

[domenic]

I'm not sure how many "casual parse5 users" there are :). Probably folks should be able to understand the DOM tree concepts...

[inikulin]

npm counts 605 dependants currently. I'm quite convinced that the vast majority of them will be confused by localName and qualifiedName terms.

[domenic]

Maybe you could add the proper terms for folks who know what they refer to, and add alias getters for folks who don't want to read the docs/DOM standard? Right now, for those of us who are aware of the difference between tagName, localName, and qualifiedName, the usage of name and tagName are confusing.

[inikulin]

Yes, that could be an acceptable solution.

[mattfysh]

Just came across this while trying to find a DOM structure that works with both css-select and xpath libraries.

I ended up using the parse5-htmlparser2-tree-adapter package to get the resultant structure working with css-select, but have now run into a couple of issues that prevents from working with xpath:

1. localName is missing from elements: https://github.com/goto100/xpath/blob/master/xpath.js#L2358
2. attributes is missing, and is required by xpath to be a NamedNodeMap: https://github.com/goto100/xpath/blob/master/xpath.js#L1867-L1875

Any suggestions for how I can fix these interop issues?

[mattfysh]

For anyone still interested in getting xpath selection working with parse5, here's the gist ✨ https://gist.github.com/mattfysh/92e160e5f2a4cf7d569f3c2bf012c217

I've run the xpath test suite and half the tests work, the other half are failing (mostly relating to namespaces, which don't make much of an appearance on the web). So far things are working well, and hopefully if any unsupported use cases come up they can be addressed by adding more DOM-like features to patch-dom.ts

@inikulin @domenic @Zirro - I'm keen to hear your thoughts 🙏