This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20485 - [Custom]: Creation of custom elements via constructor function is underdefined
Summary: [Custom]: Creation of custom elements via constructor function is underdefined
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 17103 20684
  Show dependency treegraph
 
Reported: 2012-12-21 23:54 UTC by Boris Zbarsky
Modified: 2013-02-08 23:48 UTC (History)
5 users (show)

See Also:


Attachments

Description Boris Zbarsky 2012-12-21 23:54:47 UTC
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.
Comment 1 Peter Van der Beken 2012-12-26 11:07:49 UTC
(In reply to comment #0)
>   var fun = document.register("x-foo", { prototype: obj });

Boris probably meant

   var fun = document.register("x-foo", { prototype: proto });
Comment 2 Dimitri Glazkov 2013-01-18 23:49:15 UTC
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
Comment 3 Dimitri Glazkov 2013-01-19 00:14:42 UTC
This needs more work. Hold please...
Comment 4 Dimitri Glazkov 2013-01-19 00:28:50 UTC
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! :)
Comment 5 Boris Zbarsky 2013-01-19 02:08:31 UTC
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.  ;)
Comment 6 Anne 2013-01-19 09:18:46 UTC
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.
Comment 7 Dimitri Glazkov 2013-01-22 21:51:59 UTC
(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.
Comment 8 Dimitri Glazkov 2013-01-22 22:13:50 UTC
(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
Comment 9 Boris Zbarsky 2013-01-22 22:18:17 UTC
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.
Comment 10 Dimitri Glazkov 2013-02-08 23:48:22 UTC
(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.