Re: [PHP-DEV] [RFC] DOM Living Standard API

This is only part of a thread. view whole thread
  104976
March 28, 2019 11:57 rrichards@cdatazone.org (Rob Richards)
On 3/23/19 5:33 AM, Benjamin Eberlei wrote:
> On Fri, Mar 22, 2019 at 11:26 PM Claude Pache pache@gmail.com> > wrote: > >> Beware that behaviour of some methods should differ between HTML and >> non-HTML documents. For instance, the RFC says: >> >>> DOMElement→nodeName casing was previously undefined, it is now 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 of > 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. > > >> —Claude >> >> 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. Rob
  104978
March 28, 2019 12:20 kontakt@beberlei.de (Benjamin Eberlei)
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 pache@gmail.com> > > wrote: > > > >> Beware that behaviour of some methods should differ between HTML and > >> non-HTML documents. For instance, the RFC says: > >> > >>> DOMElement→nodeName casing was previously undefined, it is now 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 of > > 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. > > > > > >> —Claude > >> > >> > 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 > >