This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There are a couple of things that I noticed in the new document.register implementation in the spec. If NAME is an invalid custom element name, throw an InvalidCharacterError and stop. The check for an "invalid custom element name" involves comparing it to a few known element names but in an HTML document we lowercase NAME after dealing with PROTOTYPE. The spec probably has to lowercase NAME here and TYPE later to get case-sensitivity correct. Let INTERFACE be PROTOTYPE's interface This means that we should walk PROTOTYPE's prototype chain, looking for an object with an interface, right? Let BASE be INTERFACE's inherited interface that is nearest to BASE in the prototype chain and that is an element interface This defines BASE recursively. This should probably read: Let BASE be INTERFACE's inherited interface that is nearest to PROTOTYPE in the prototype chain and that is an element interface (note the second instance of BASE has been changed to PROTOTYPE). If BASE is not HTMLElement or SVGElement, let NAME be the local name, associated with BASE element interface It isn't entirely clear how to do this. If I see HTMLHeadingElement.prototype, should NAME be "h1", "h2", etc? While we have HTMLAudioElement and HTMLVideoElement, what should happen if the author uses HTMLMediaElement? I guess I don't see a clear relationship in the spec as it's written currently between "interface" and "local name" (or, for that matter, a clear definition of "element interface" as it applies to prototype objects, are these simply objects that delegate to Element?).
(In reply to comment #0) > If BASE is not HTMLElement or SVGElement, let NAME be the local > name, associated with BASE element interface > > It isn't entirely clear how to do this. If I see > HTMLHeadingElement.prototype, should NAME be "h1", "h2", etc? While we have > HTMLAudioElement and HTMLVideoElement, what should happen if the author uses > HTMLMediaElement? FYI bug 21886 discusses this specific issue. The other points are all good ones: +1.
(In reply to comment #0) > There are a couple of things that I noticed in the new document.register > implementation in the spec. > > If NAME is an invalid custom element name, throw an > InvalidCharacterError and stop. > > The check for an "invalid custom element name" involves comparing it to a > few known element names but in an HTML document we lowercase NAME after > dealing with PROTOTYPE. The spec probably has to lowercase NAME here and > TYPE later to get case-sensitivity correct. Thanks! I don't need to do anything with TYPE, since it's either NAME or localName of BASE, which will already have the correct case. https://dvcs.w3.org/hg/webcomponents/rev/08b3fd017d6e > > Let INTERFACE be PROTOTYPE's interface > > This means that we should walk PROTOTYPE's prototype chain, looking for an > object with an interface, right? No, it's just is a weird construct that appeases Web IDL. The interface is just a logical construct, which represents the object's properties and methods as a Web IDL thing: http://www.w3.org/TR/WebIDL/#dfn-interface It's a no-op from the implementation perspective. I need it to rely on Web IDL's meaning of "inherits", etc. > > Let BASE be INTERFACE's inherited interface that is nearest to BASE > in the prototype chain and that is an element interface > > This defines BASE recursively. This should probably read: > > Let BASE be INTERFACE's inherited interface that is nearest to > PROTOTYPE in the prototype chain and that is an element interface > > (note the second instance of BASE has been changed to PROTOTYPE). Thank you! Fixed it as part of https://dvcs.w3.org/hg/webcomponents/rev/ea07a8c6329c.