Replies: 2 comments 3 replies
-
Thank you for taking the time to raise this question. There is a related thread in #176 which mostly raises questions that should be considered along this topic, but doesn't come to any conclusion yet. The readme states something related:
And the linked document regarding all the related specs gives a clear indication that the general decision is to at least document differences to tge living standard or even align the behavior, even if it means it is a breaking change: I would really like to find a way to run the relevant parts of the web platform tests using xmldom, to make it very obvious how aligned this library is with the browser implementation, but no time has been invested into how this would be possible. I just know that Deno seems to also be doing that, and that might be a good resource to look at. Looking forward to any input/ideas on the topic. |
Beta Was this translation helpful? Give feedback.
-
Thank you for your input, @karfau. Your insights in discussion #176 are appreciated. However, I believe that the library name, xmldom, underscores a definitive commitment to using the XML DOM, and it should fully leverage the XML DOM Core. Implementing and keeping up with the living standard seems unfeasible, given the scarcity of active contributors to this project. The HTML part seems to be added more as an after thought, barely even being mentioned in the projects README. Of course, my viewpoint may be biased as I only utilize this library for handling XML documents. |
Beta Was this translation helpful? Give feedback.
-
While working on adding JSDoc annotations to the
dom.js
module, I've observed a blend of DOM specifications being used - including XML DOM L2 Core, L3 Core, and the WHATWG Living Standard. There seems to be no discernible pattern behind this choice, which can make the library's behavior a bit unpredictable.Given the name 'XMLDOM', adhering strictly to the XML DOM L3 Core spec might seem like the most logical choice. However, considering the library also claims to ponyfill for DOM in browsers, and recognizing that browsers are largely aligned with the Living Standard, there's a compelling argument for leaning in that direction too.
I'd love to hear everyone's thoughts on this, especially @karfau. Should we align more closely with L3 Core, or pivot towards the Living Standard to better mimic modern browser behavior?
For example:
We have the method
DOMImplementation.createHTMLDocument()
This method is not part of any Level of XML DOM Core.
In DOM L2 CORE the function was introduced, but not on
DOMImplementation
but as a member ofHTMLDOMImplementation
which extendsDOMImplementation
In the living standard, the function is indeed present on the
DOMImplementation
interfaceBeta Was this translation helpful? Give feedback.
All reactions