Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106083
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>
 <CAK5kH3xP=k0e2CrFeaGSbi34VmyVx9w9jWP7nGPSqSEr-bu2rQ@mail.gmail.com>
 <7e338777-d258-f795-e658-b290dd6ce98b@ctindustries.net> <CAK5kH3zNTWZSsPjohm9-v5=Ba1utPB3WNF8_Qt_ktqT+QKsqFg@mail.gmail.com>
In-Reply-To: <CAK5kH3zNTWZSsPjohm9-v5=Ba1utPB3WNF8_Qt_ktqT+QKsqFg@mail.gmail.com>
Date: Thu, 27 Jun 2019 17:20:15 -0400
Message-ID: <CAK5kH3yhft40BGukBr4sQTqMHM5Z1B4--Haf9Bzb5_-ezb98MA@mail.gmail.com>
To: Rob Richards <rrichards@ctindustries.net>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, Pierre Joye <pierre.php@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000cadd6058c54bbc9"
Subject: Re: [PHP-DEV] On fixing DOMNameSpaceNode and DOM NS API Inconsistency Problems
From: cananian@wikimedia.org ("C. Scott Ananian")

--0000000000000cadd6058c54bbc9
Content-Type: text/plain; charset="UTF-8"

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)

--0000000000000cadd6058c54bbc9--