fix!: Set nodeName property to ProcessingInstruction

[cjbarth]

Closes #505

BREAKING CHANGE: (only of 0.9.x) the tagName property is no longer set since a ProcessingInstruction is not an Element

[karfau]

Hey @cjbarth this is great news and an excelent additional set of tests.

I have just one remark:

Please keep the tagName value, since it represents the value from the Element interface:

Thus, even though there is a generic Node.nodeName attribute on the Node interface, there is still a Element.tagName attribute on the Element interface; these two attributes must contain the same value, but it is worthwhile to support both, given the different constituencies the DOM API must satisfy.

https://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1CED5498

and ideally the tests should also make sure both values are aligned.

(I know it's not ideas to keep a reference to the value twice since they can get out of sync but are currently not able to have setters and getters for all supported runtimes, so that's a general issue in the code base.)

[karfau]

Oh and please run npm run format before commiting, to let prettier handle those "linting" issues. (I think I should finally add a pre-commit hook for that...)

[cjbarth]

represents the value from the Element interface

I completely agree that .tagName is a property on the Element interface. However, ProcessingInstruction doesn't inherit from Element, so it doesn't have .tagName.

[cjbarth]

As a side point, I'm curious why this library isn't at 1.x yet. The API seems stable so I would expect a semver 1.0.0 would have been released.

[cjbarth]

please run npm run format before commiting

Done.

[karfau]

Thank you for insisting/clarification.

[karfau]

You can have a look at the milestones that we currently have put all issues in that we are aware if.
So far we have had a decent amount if breaking changes in every feature/minor release and 0.9.0 will also have that, so I think it correctly reflects the current "matureness" of the implementation compared to what the native browser API offers.
There are definitely some differences in behavior compared to the browser native API, which this is claiming to ponyfill, so for a 1.0 I would at least expect to be able to have a web platform test running to make those differences as explicit as possible and have worked towards reducing them to a level that is understandable/managable

[karfau]

released as 0.7.12(@lts), 0.8.9 (@latest) and 0.9.0-beta.9 (@next) version tag

(0.7.12 and 0.8.9 still set the tagName to make it a non breaking change)