Re: [PHP-DEV] On fixing DOMNameSpaceNode and DOM NS API Inconsistency Problems

This is only part of a thread. view whole thread
  106083
June 27, 2019 21:20 cananian@wikimedia.org ("C. Scott Ananian")
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 <cananian@wikimedia.org>
wrote:

> On Sun, Mar 17, 2019 at 6:57 PM Rob Richards <rrichards@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)