Another reason why it might be cleaner to associate it with a browsing context is that all the DOM constructors are shared between all the documents in the browsing context.

For example:

var doc2 = document.implementation.createHTMLDocument('');
doc2.constructor === document.constructor;
doc2.createElement('div').constructor === HTMLDivElement;

You'll need to do special contortions now to make "new X()" still work. Perhaps you can import them from what HTML5 does for "Image":

<http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#dom-image>

There's a slight wrinkle in that it says:

"The element's document must be the active document of the browsing context of the Window object on which the interface object of the invoked constructor is found."

Perhaps register should move to window and the language should be

"The element's document must be the active document of the browsing context of the Window object on which DEFINITION was registered."

or something like that.

Blake, William -- yell at me if you hate this. I am hoping to do this soon.

(In reply to comment #2)
> Perhaps register should move to window and the language should be
> 
> "The element's document must be the active document of the browsing context
> of the Window object on which DEFINITION was registered."
> 
> or something like that.

I would keep the method on document. We can always walk up to the right document with some spec language magic :)

This seems generally fine to me. I agree with comment 4, adding a "register" function to the window is just asking to conflict with existing content and there isn't really a better place to put it (navigator? hah!).

In general it's easy to go from a document to its associated window except after the window has been closed or navigated, so as long as we can figure out something sane to do in those cases (throw?) I don't see any problems with it.

Notes to self: definition construction algorithm checks whether DOCUMENT is HTML Document to decide whether to ignore NAME and TYPE case. Need to move this check elsewhere when switching to use browsing context.

https://dvcs.w3.org/hg/webcomponents/rev/d24e6050bb34

I think this needs more work. Specifically, the HTML spec says

"A Document created using an API such as createDocument() has no browsing context."

When "the register method must run these steps" says the input includes "CONTEXT, the browsing context", what does that mean? The script's browsing context [1], or the document's browsing context? The latter seems to contradict the use case in Comment 2. Also, the spec limps along instead of bailing out in the case of empty browsing contexts.

[1] <http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#script's-browsing-context>

Also this step needs updating:

"If an element definition with matching NAME, NAMESPACE, and TYPE is not registered with token's document, set TYPE to NAME"

since element definitions are registered with browsing contexts, not documents.

I discussed this with abarth. Briefly, having documents without browsing contexts (like document.implementation.createHTMLDocument('')) use custom elements seems fraught; would this mean other contextless documents like XMLHTTPResponse.responseXML or DOMParser-created documents run script where they couldn't before?

If the idea is to share definitions/prototypes between documents, the spec really needs something like a unit of related documents.

Another problem with the spec as written--you presumably need to discard the definitions associated with a browsing context when the document changes, but there's no language like that in the spec.

(In reply to comment #10)
> I discussed this with abarth. Briefly, having documents without browsing
> contexts (like document.implementation.createHTMLDocument('')) use custom
> elements seems fraught; would this mean other contextless documents like
> XMLHTTPResponse.responseXML or DOMParser-created documents run script where
> they couldn't before?

This we can mitigate easily. There's a http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#scripting-flag, and it's explicitly set for documents, created that way. We should explicitly check for that flag.

> If the idea is to share definitions/prototypes between documents, the spec
> really needs something like a unit of related documents.

I wonder if "browsing context" is simply the wrong abstraction to associate with. Perhaps http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#document-environment is the right one.

> Another problem with the spec as written--you presumably need to discard the
> definitions associated with a browsing context when the document changes,
> but there's no language like that in the spec.

Associating with document environment should fix that?

(In reply to comment #11)
> I wonder if "browsing context" is simply the wrong abstraction to associate
> with. Perhaps
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.
> html#document-environment is the right one.

I only just realized that what the spec defines as "browsing context" and what I thought was a browsing context were not the same thing. It is definitely the wrong abstraction to be using here. Document environment is actually what I thought a browsing context was, so I support this change.

(In reply to comment #12)
> (In reply to comment #11)
> > I wonder if "browsing context" is simply the wrong abstraction to associate
> > with. Perhaps
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.
> > html#document-environment is the right one.
> 
> I only just realized that what the spec defines as "browsing context" and
> what I thought was a browsing context were not the same thing. It is
> definitely the wrong abstraction to be using here. Document environment is
> actually what I thought a browsing context was, so I support this change.

"document environment" definition is a bit too squishy in HTML spec. We should just use the Window object?

(In reply to comment #13)
> "document environment" definition is a bit too squishy in HTML spec. We
> should just use the Window object?

I've lost the use-case we're trying to solve with this change. Is the idea to share custom elements among groups of same-origin (related?) documents or to make document.implementation.crweateHTMLDocument().register work by registering the new custom element somewhere where "document" can get at it?

(In reply to comment #14)
> (In reply to comment #13)
> > "document environment" definition is a bit too squishy in HTML spec. We
> > should just use the Window object?
> 
> I've lost the use-case we're trying to solve with this change. Is the idea
> to share custom elements among groups of same-origin (related?) documents or
> to make document.implementation.crweateHTMLDocument().register work by
> registering the new custom element somewhere where "document" can get at it?

The latter. I think this statement is right: for one set of built-ins, there's also one custom element registry. This is important for <template> and later <link rel="import">.

(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > "document environment" definition is a bit too squishy in HTML spec. We
> > > should just use the Window object?
> > 
> > I've lost the use-case we're trying to solve with this change. Is the idea
> > to share custom elements among groups of same-origin (related?) documents or
> > to make document.implementation.crweateHTMLDocument().register work by
> > registering the new custom element somewhere where "document" can get at it?
> 
> The latter. I think this statement is right: for one set of built-ins,
> there's also one custom element registry. This is important for <template>
> and later <link rel="import">.

Adam would point out that there could be code in the wild using DOMParser or document.implementation.createHTMLDocument to parse untrusted content, or Cross-Origin XHR to retrieve documents, and that code assumes those documents don't activate anything.

If you make this change, the custom elements defined by the page can be activated by that untrusted content. That may not be a good idea.

(In reply to comment #16)

> Adam would point out that there could be code in the wild using DOMParser or
> document.implementation.createHTMLDocument to parse untrusted content, or
> Cross-Origin XHR to retrieve documents, and that code assumes those
> documents don't activate anything.
> 
> If you make this change, the custom elements defined by the page can be
> activated by that untrusted content. That may not be a good idea.

This is interesting. I guess there are vectors of attack that could be thought up that way. But... if the attacker can register an element, isn't the battle already over?

Just to enumerate our choices, while the discussion is still in progress:

1) Keep the registry on the document. This ensures there aren't any new opportunities to run JS, but means we need to special-case the <template> and the <link rel=import>, which is magic.

2) Move the registry to Window (or "document environment"). Most aligned from the layering perspective, but scary from security perspective.

3) Build some mechanism/API to share registries between documents and provide sensible defaults. A bit of work and complexity (not sure on cost/benefit ratio), but potentially heals both layering and security worries.

Another interesting bit I just remembered: Declarative syntax sets a property on Window when an element is registered. This also implies pretty strong association between element registry and a Window.

So I did this: https://dvcs.w3.org/hg/webcomponents/rev/da49e83784ac

I know we still have security challenges, but Window really does feel like the right place to hang the registry off. I wonder if we could track the security issues separately and go forward with this. WDYT?

(In reply to comment #17)
> (In reply to comment #16)
> > If you make this change, the custom elements defined by the page can be
> > activated by that untrusted content. That may not be a good idea.
> 
> This is interesting. I guess there are vectors of attack that could be
> thought up that way. But... if the attacker can register an element, isn't
> the battle already over?

In this case the untrusted content is not registering an element (I assume it could not do that?) but running the script of an element already registered.

(In reply to comment #18)
> Just to enumerate our choices, while the discussion is still in progress:
> 
> ...

Moving the registry to the Window/document environment is right. Now you need to come to terms with not all documents being active documents.

Here's a strawman: document.the_funk() This opts the document into Custom Element processing of the calling document environment.

Not having the_funk is evident everywhere by the spec's use of CONTEXT. These no-active documents do not have a browsing context.

(In reply to comment #21)

> Moving the registry to the Window/document environment is right. Now you
> need to come to terms with not all documents being active documents.

Split this off into bug 22466.

> 
> Here's a strawman: document.the_funk() This opts the document into Custom
> Element processing of the calling document environment.
> 
> Not having the_funk is evident everywhere by the spec's use of CONTEXT.
> These no-active documents do not have a browsing context.

Can you explain this a bit more on that bug? I don't think I understood this well.