Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104978
MIME-Version: 1.0
References: <CAEPJdu=DYZ8RTUtb-mDOGPdXGK4Z-h59rUq_A=wB=u6AaO7aDg@mail.gmail.com>
 <C3F1FF05-7D74-4B5F-82D9-B527B4E5F9BB@gmail.com> <CAEPJdu=dQFwB6=YXBAW0REXP+bZHUrRxkbDsKwyQLAXBr-iSzA@mail.gmail.com>
 <0df89058-0878-48b3-3f67-d8960e84a912@cdatazone.org>
In-Reply-To: <0df89058-0878-48b3-3f67-d8960e84a912@cdatazone.org>
Date: Thu, 28 Mar 2019 13:20:27 +0100
Message-ID: <CAEPJdukOkT8qGDvw+CRfdQaJhieEK-6mYsEhSBFjCL-rE40kfA@mail.gmail.com>
To: Rob Richards <rrichards@cdatazone.org>
Cc: Claude Pache <claude.pache@gmail.com>, PHP Internals <internals@lists.php.net>, 
	Thomas Weinert <thomas@weinert.info>
Content-Type: multipart/alternative; boundary="0000000000000252300585269559"
Subject: Re: [PHP-DEV] [RFC] DOM Living Standard API
From: kontakt@beberlei.de (Benjamin Eberlei)

--0000000000000252300585269559
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 28, 2019 at 12:57 PM Rob Richards <rrichards@cdatazone.org>
wrote:

> On 3/23/19 5:33 AM, Benjamin Eberlei wrote:
> > On Fri, Mar 22, 2019 at 11:26 PM Claude Pache <claude.pache@gmail.com>
> > wrote:
> >
> >> Beware that behaviour of some methods should differ between HTML and
> >> non-HTML documents. For instance, the RFC says:
> >>
> >>> DOMElement=E2=86=92nodeName casing was previously undefined, it is no=
w changed
> >> to always uppercase.
> >>
> >> However, the DOM Living Standard says it is uppercase (even,
> >> ASCII-uppercased) only in the HTML namespace. For XML documents, the
> casing
> >> is not modified.
> >>
> > You are absolutely right, i missed that in the convoluted description o=
f
> > the behavior :-) I need to rethink how this would fit with the
> > compatibility flags, it might cause a problem given that loadHTML for
> > example doesn't automatically put the elements into HTML namespace. I
> > updated the RFC to reflect this.
> >
> > To be honest, the compatibility thing is what i am least sure in,
> > especially if this should be combined with the new methods + removal of
> > unused code or should be handled separately.
> >
> >
> >> =E2=80=94Claude
> >>
> >>
> I'm still running through all the changes but my suggestion would be to
> start with only new methods and then deal with the rest. At least with
> the new functionality you don't cause any unintended BC breaks.
>

Yes, thinking about this more I am coming to this conclusion myself :-) I
think the DOMImplementation and compatibility layer changes should probably
not be part of this RFC, it should only be about adding the new
functionality.

However, we will break BC anyways I realized with the registerNodeClass, if
you provide a subclass for DOMElement that implements
next/previousElementSibling (for example) with a __get overwrite, then this
RFC adding this method potentially with a slightly different behavior will
cause a BC break for users subclassing via registerNodeClass.


>
> Rob
>
>

--0000000000000252300585269559--