This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider this script: var proto = { myProp: 1 }; proto.__proto__ = HTMLElement.prototype; var fun = document.register("x-foo", { prototype: obj }); var elem = new fun(); alert(elem.localName); alert(elem.namespaceURI); as far as I can tell, the specification does not define what those two alerts should show. It needs to do that.
(In reply to comment #0) > var fun = document.register("x-foo", { prototype: obj }); Boris probably meant var fun = document.register("x-foo", { prototype: proto });
I rewrote most of the definitions (Terminology and Instantiating Custom Elements section), so please take a look. Let me know if I messed up. https://dvcs.w3.org/hg/webcomponents/rev/85c8d5e0f8f9
This needs more work. Hold please...
It's this freaky territory between WebIDL and DOM core, where things actually live: 1) DOM Core doesn't want to have anything to do with prototypes. createElement just creates a DOM object (http://dom.spec.whatwg.org/#dom-document-createelement) 2) WebIDL is working with abstract concepts like interfaces, and is a bit coy about the actual relationship between interfaces and interface prototype objects (the JS truth is that the latter defines the former): http://www.w3.org/TR/WebIDL/#interface-prototype-object I feel like a pioneer! :)
The DOM thing is just a bug in the DOM spec, imo. When you create an object, you need to say what sort of object it is and in particular what its primary interface is. See http://dev.w3.org/2006/webapi/WebIDL/#dfn-primary-interface As for WebIDL... The prototype object does not in fact define the interface, really. Again, an interface is a syntactic concept. Then in the ES binding an interface may have a corresponding interface object, a corresponding interface prototype object, or both. The syntactic construct that is the interface then leads to certain properties on those ES objects (e.g. the constants and static attributes/operations go on the interface object, while the non-static operations and attributes go on the interface prototype object). And yes, you're a pioneer. We all are to this business of actually speccing the interaction of the DOM and ES, really. ;)
I suppose we could create some kind of (namespace, localName) -> interface mapping table. I wonder if it's best to define a hook for this or just keep the mapping table in DOM as it is in implementations.
(In reply to comment #6) > I suppose we could create some kind of (namespace, localName) -> interface > mapping table. I wonder if it's best to define a hook for this or just keep > the mapping table in DOM as it is in implementations. Right, I think a hook is what you're looking for here. HTML can hook into it, and I can hook into it, too.
(In reply to comment #7) > (In reply to comment #6) > > I suppose we could create some kind of (namespace, localName) -> interface > > mapping table. I wonder if it's best to define a hook for this or just keep > > the mapping table in DOM as it is in implementations. > > Right, I think a hook is what you're looking for here. HTML can hook into > it, and I can hook into it, too. Here's the monkeypatch I made: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element
That's good text (well, at least much better), but doesn't actually address _this_ bug, which is about what happens when the return value of register() is called.
(In reply to comment #9) This is now done: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-custom-element-constructor-generation There's discussion that will probably trigger more changes in bug 20913.