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

This is only part of a thread. view whole thread
  104833
March 20, 2019 15:48 cananian@wikimedia.org ("C. Scott Ananian")
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
  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)