Meta: Impact of "Superseeded" Status of DOM Level 2 Specification

[karfau]

According the specification this library is trying to implement it has been marked as "superseeded" in November 2020:

Status of this document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This specification is a Superseded Recommendation. A newer specification exists that is recommended for new adoption in place of this specification.

For purposes of the W3C Patent Policy, this Superseded Recommendation has the same status as an active Recommendation; it retains licensing commitments and remains available as a reference for old — and possibly still deployed — implementations, but is not recommended for future implementation. New implementations should follow the Living Standard of the DOM specification.

The question is: What impact should this have on the goals/long term strategy of this library?

[karfau]

I just did some research (in the context of #203) related to all the different specs xmldom implements (at least some) parts of, here are my findings:

• Both the HTML and the DOM spec are under active development by the WATHWG, and most of those specs are way out of the scope of xmldom. But of course this is what people are looking at first, when looking for documentation about certain interfaces.
• "Older" versions/levels of both HTML and DOM specs exist, that have seen more or less adoption and are "stable" in a way, since they are no longer developed or maintained. This is what most of the documentation in this repo points to. But they also contain things that are either deprecated or even conflicting with the newer specs.

I think a basic overview of the related specs should be part of the repo and what our goals are towards each of them and how they relate to each other, e.g. in a SPECS.md.

Since I created labels for some of them, I think we should also add labels for the missing ones.

[karfau]

And since I didn't say it explicitly:

I think it will be hard to reach a point in time, where xmldom can say that it conforms/complies with any single (or even multiple) spec, so I think it makes more sense to document the behavior of each class/method, including the alignment or difference to any related spec.

[brodybits]

@karfau can we say that this implements an API similar to (some parts of?) the XML DOM API implemented by many browsers, based on API documented in [link into documentation. on MDN], say based on the now superseded DOM level 2 specs?

I would agree 100% with keeping the scope limited for the foreseeable future, and furthermore (sorry for veering off-topic) that we should now focus on some near-term priorities such as:

• add some more testing as needed to improve the Stryker testing coverage scores
• apply linting standards such as Prettier and "Standard JS" to the code base, as I had already started work in existing, draft PRs
• review the code base and refactor as needed to modernize and improve readability

While it would be nice to add new features from the living standards, I think this would need both user community interest and external support in the form of sponsorships, for example.

[brodybits]

My apologies, looks like some of my ideas were already part of PR #211.