Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104775
MIME-Version: 1.0
References: <CAEPJdu=BuS8rf7_=GikUtCArdHSUD4AqY3+27tAJ1HPCP4Jm4A@mail.gmail.com>
 <CAEZPtU5r9oFDdDj_81+u+a2ZUQk3EjQ8FK1TvOnsODHGJUUVqw@mail.gmail.com>
 <08e09ea4-20d0-277d-8919-4e3d4387699c@ctindustries.net> <CAEPJdumgrq9+SSyw=F3OBRGanhOcx=vZSoWEGbXUs2T6GdkJKQ@mail.gmail.com>
In-Reply-To: <CAEPJdumgrq9+SSyw=F3OBRGanhOcx=vZSoWEGbXUs2T6GdkJKQ@mail.gmail.com>
Date: Sun, 17 Mar 2019 09:52:29 -0400
Message-ID: <CAK5kH3xP=k0e2CrFeaGSbi34VmyVx9w9jWP7nGPSqSEr-bu2rQ@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Rob Richards <rrichards@ctindustries.net>, Pierre Joye <pierre.php@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d3e0f305844a9503"
Subject: Re: [PHP-DEV] On fixing DOMNameSpaceNode and DOM NS API Inconsistency Problems
From: cananian@wikimedia.org ("C. Scott Ananian")

--000000000000d3e0f305844a9503
Content-Type: text/plain; charset="UTF-8"

On Sun, Mar 17, 2019, 9:34 AM Benjamin Eberlei <kontakt@beberlei.de> wrote:

>
> It is still a draft but Thomas and I have started working on an RFC and
> code to update ext/dom to cover the latest standard release:
> https://wiki.php.net/rfc/dom_living_standard_api - we plan on proposing
> that soon, maybe you have some feedback.
>

Updating the DOM extension would be something the Wikimedia Foundation
would very much like to see happen.  It's more complicated than just adding
some new methods, though: there are significantly spec-compliance issues
with the current code and performance problems too.  We've been porting
code from JS to PHP which (in the JS version) used a good spec-compliance
DOM implementation, and have been keeping a list of all the crazy bugs and
workarounds that have been necessary.

Start from the basic fact that the modern DOM requires Node#nodeName to be
uppercase for HTML elements, and the current code uses all lowercase.  It's
hard to see how that could be addressed without breaking backward compat.

Here are our notes/discussions/etc:
https://phabricator.wikimedia.org/T215000
https://mediawiki.org/wiki/Parsoid/PHP/Help_wanted
(and there's more where that came from)
  --scott

PS. My personal feeling at this time is that it would be better to put the
core libxml abstractions in an extension, to allow fast xpath and perhaps
parse/serialize, but that the actual DOM should be built as a php library
on top of that, in order to allow rapid changes (the WHATWG is pretty
actively making additions/changes to the we spec these days) which are
decoupled from the PHP release cycle.

--000000000000d3e0f305844a9503--