Brief update: We found a few more PHP DOM compatibility bugs, including one with DOMNode::normalize(): https://bugs.php.net/bug.php?id=78221
In addition, one of our engineers implemented a pure-PHP DOM implementation: https://github.com/linehan/DOMOperator We're not using that in production yet, but it's probably quicker than trying to make PHP's DOM implementation spec-compliant. --scott On Wed, Mar 20, 2019 at 11:48 AM C. Scott Ananian <canan...@wikimedia.org> wrote: > On Sun, Mar 17, 2019 at 6:57 PM Rob Richards <rricha...@ctindustries.net> > wrote: > >> I'll take a look through the lists you have but you need to remember >> that the DOM specs were not written for HTML. While HTML might have some >> more restrictive requirements that piggy back on the DOM specs >> themselves, they are not the standard for DOM. The output HTML >> functionality was more convenience methods than part of the core >> extension, >> > > Just dealing with the latest WHATWG DOM specs (not the html-specific part) > would still involve grappling with `getAttribute` behavior, the case of > nodeName (search for "HTML-uppercased qualified name" in the DOM spec), the > numeric node type of the root document, performance of methods on > namespaced nodes, etc. It would certainly be a useful step forward, even > if it weren't a full HTML DOM. > > What would be even better is if the hooks were present to allow > subclassing the core DOM types so that you could implement HTMLElement in > pure PHP as a subclass of DOMElement, etc. For example, right now it is > impossible to create a new DOMNodeList from PHP, which makes pure PHP > implementations of the missing HTML DOM methods (like querySelectorAll) > impossible (for example wikimedia/zest-css has to return an array instead > of a DOMNodeList). > --scott > > -- (http://cscott.net)
