Re: [RFC] [Discussion] Opt-in DOM spec-compliance

Hi Gina On 18/01/2024 14:05, Gina P. Banyard wrote: > Hello Niels, > > Thank you for the RFC and the thorough overview of the current state. > > I think converting the new aliases to proper classes which have the correct spec behaviour is > indeed the way to proceed. > > I do have some questions however, do you really think we need the DOMDocument methods to import > modern nodes into legacy documents? > As I can imagine, this would provide fewer incentives for users to move to the new spec > compliant classes. It's a double-edged sword: if we don't provide it, it becomes harder to migrate and it may take a longer time to do so. If we do provide it there may be fewer incentives. I think it's necessary as a first step to aid migration, otherwise, if we don't provide this, it's going to become more difficult for library maintainers as they'd have to effectively create two versions of their library in some cases. By creating these methods it may become possible to use libraries that are not yet adapted to the new classes. So depending on your point of view it may even accelerate adoption. One caveat is, as always, that any migration can be hindered if a library you try to use relies on bugs that are fixed in the new classes. > The other thing to clarify is why and when would those return false, compared to the methods > that import legacy nodes which never throw? {import,adopt}ModernNode may return false or throw, depending on the $strictErrorChecking property of DOMDocument, when an error occurs. The only possible error case really is when an unsupported node is imported/adopted (e.g. a document itself). The reason we don't have the false return value for {import,adopt}LegacyNode is because the DOM\{XML,HTML}Document class doesn't have a $strictErrorChecking property, i.e. it always uses exceptions. > > Best regards, > > Gina P. Banyard Kind regards Niels