> On 3/23/19 5:33 AM, Benjamin Eberlei wrote:
> > On Fri, Mar 22, 2019 at 11:26 PM Claude Pache firstname.lastname@example.org>
> > 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
> >> 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
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.