document.open doesn't create a new Window, it seems? Can you help me understand the problem a bit better?

document.open does create a new window.

"Replace the Document's singleton objects with _new_ instances of those objects. (This includes in particular the Window,..."

(In reply to comment #2)
> document.open does create a new window.
> 
> "Replace the Document's singleton objects with _new_ instances of those
> objects. (This includes in particular the Window,..."

Durr. Thanks!

Maybe the registration context should not be associated with the Window per se. Instead registration contexts are transmitted between documents.

For example:

When a window loads a document, it associates that document with a new registration context.

A document X's template document Y is associated with the registration context associated with X.

document.implementation.createHTMLDocument associates the resulting document with the registration context associated with 'document'.

etc.

This has the benefit that x.implementation.createHTMLDocument gives consistent results, irregardless of which window is running the script that acts on x.

(In reply to comment #4)

> This has the benefit that x.implementation.createHTMLDocument gives
> consistent results, irregardless of which window is running the script that
> acts on x.

Can you help me understand this? If I have main document A that contains an iframe B, and A reaches into B and attempts to createHTMLDocument on its document, we need to make sure that the document has the registration context from B, right?

(In reply to comment #5)
> (In reply to comment #4)
> 
> > This has the benefit that x.implementation.createHTMLDocument gives
> > consistent results, irregardless of which window is running the script that
> > acts on x.
> 
> Can you help me understand this? If I have main document A that contains an
> iframe B, and A reaches into B and attempts to createHTMLDocument on its
> document, we need to make sure that the document has the registration
> context from B, right?

Right. The spec today has this:

"Whenever created, each document must retain a weak reference to the Window object of the browsing context's active document. This referenced Window object is called the registration context."

I assume? this means that if A reaches into B and does 

doc = B.contentDocument.implementation.createHTMLDocument();

'doc' should be associated with the registration context of A, because the window that's running the script, etc. is A's.

If you think it is B, I am prepared to believe you, but then what does

doc2 = doc.implementation.createHTMLDocument();

associate doc2 with? In terms of browsing contexts, B has fled the scene.

So I'm proposing that documents are associated with a registration context, and when creating documents in specific situations, that association is transmitted to the new document in a process like quantum entanglement.

After having a crack at implementing something in Blink, I think you could do anything right up to letting the author imperatively state which documents they want entangled.

The idea of changing the entanglement of a document after custom element processing has started sounds scary, but it is really not--remember we have to solve the adoptNode problem. Changing the entanglement would look, from the point of view of the old context, like all of the elements got put up for adoption at once.

I have no idea whether this is a good idea, except to say it is a nice conservative security default to entangle very little, maybe just template and imports. And then the author can decide to entangle other kinds of documents if he/she wants.

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > 
> > > This has the benefit that x.implementation.createHTMLDocument gives
> > > consistent results, irregardless of which window is running the script that
> > > acts on x.
> > 
> > Can you help me understand this? If I have main document A that contains an
> > iframe B, and A reaches into B and attempts to createHTMLDocument on its
> > document, we need to make sure that the document has the registration
> > context from B, right?
> 
> Right. The spec today has this:
> 
> "Whenever created, each document must retain a weak reference to the Window
> object of the browsing context's active document. This referenced Window
> object is called the registration context."
> 
> I assume? this means that if A reaches into B and does 
> 
> doc = B.contentDocument.implementation.createHTMLDocument();
> 
> 'doc' should be associated with the registration context of A, because the
> window that's running the script, etc. is A's.
> 
> If you think it is B, I am prepared to believe you, but then what does
> 
> doc2 = doc.implementation.createHTMLDocument();
> 
> associate doc2 with? In terms of browsing contexts, B has fled the scene.
> 
> So I'm proposing that documents are associated with a registration context,
> and when creating documents in specific situations, that association is
> transmitted to the new document in a process like quantum entanglement.

This is reasonable. We can start very small, by:

1) declaring the registration context its own thing, then
2) defining how a new registration context is created during http://www.whatwg.org/specs/web-apps/current-work/#read-html
3) defining how it's passed along to new Document instances in specific imperative APIs.

WDYT? This should take care of the Window/Document conundrum cleanly and allow future refinements toward solving bug 22466

(In reply to comment #7)
> This is reasonable. We can start very small, by:
> 
> 1) declaring the registration context its own thing, then
> 2) defining how a new registration context is created during
> http://www.whatwg.org/specs/web-apps/current-work/#read-html
> 3) defining how it's passed along to new Document instances in specific
> imperative APIs.
> 
> WDYT? This should take care of the Window/Document conundrum cleanly and
> allow future refinements toward solving bug 22466

Sounds like a plan.

https://dvcs.w3.org/hg/webcomponents/rev/71b32d02423b

PTAL.