On Thu, Mar 28, 2019 at 12:57 PM Rob Richards <rricha...@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.pa...@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 > >
