I think you should investigate a whitelist, not a blacklist.

Straw man: The only thing on the whitelist should be HTML Imported documents.

(From bug 21958)
>> 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.

First, the CONTEXT part. In many algorithms the spec refers to a document's context. Many documents you're interested in making light up, like template contents, or DOMImplementation.createDocument, do not have contexts. So that just needs to be fixed.

How will you fix it? You're going to need to define some mapping from document to context.

You could ask the running script environment for its context. That has two problems:

1. It probably does nothing for parsing, and you need the context during parsing.

2. A given document can be accessed in different contexts, eg a script reaches into an iframe. For predictable behavior, the mapping should be stable.

So the_funk is a strawman that says there's a method to establish this association explicitly.

(In reply to comment #1)
> 
> First, the CONTEXT part. In many algorithms the spec refers to a document's
> context. Many documents you're interested in making light up, like template
> contents, or DOMImplementation.createDocument, do not have contexts. So that
> just needs to be fixed.

Where? Can you help me find these? The only places the spec uses CONTEXT is for registration context, and that's very well-defined I thought?

(In reply to comment #2) 
> Where? Can you help me find these? The only places the spec uses CONTEXT is
> for registration context, and that's very well-defined I thought?

Just took a look--my knowledge of the spec was stale. This is looking very solid now.

My only comment then is I think you want a whitelist and not a blacklist of which means of creating document associate the document with the registration context.

What is the behavior if a custom element is parsed in a document without access to the registration context but then moved into a document with the registration context?

In Dart, we are using document.implementation.createHTMLDocument to sanitize untrusted content and need to have the opportunity to remove untrusted elements. To mitigate XSS vectors Element.innerHTML will be sanitized by default, and it would be nice to allow custom elements if they are trusted.

(In reply to comment #4)
> What is the behavior if a custom element is parsed in a document without
> access to the registration context but then moved into a document with the
> registration context?

This is slightly a different question. Specifying behavior of moving a custom element between documents is bug 20488.

> In Dart, we are using document.implementation.createHTMLDocument to sanitize
> untrusted content and need to have the opportunity to remove untrusted
> elements. To mitigate XSS vectors Element.innerHTML will be sanitized by
> default, and it would be nice to allow custom elements if they are trusted.

FWIW, the document.implementation.createHTMLDocument will have share the registration context with the main document by default.

I just realized there's an important hair that should be split. For a given document there are really two questions here:

1. Should this document process custom elements at all.

2. If this document processes custom elements, does it share a context with another document?

In terms of Question 1, the experimental implementation in Blink processes custom elements (or tries to) in HTML and XHTML documents of all kinds. This includes XHR's responseXML, a document created by DOMParser, etc.

From a security perspective, this sounds scary, because those documents may contain content the author does not trust.

I think that this is OK because of Question 2: definitions are *not* shared with these documents. So nothing is active unless the author opts into it by calling document.register on the document. So attacking this would require luring the author into calling document.register on one of these documents, etc.

In terms of Question 2, the experimental implementation in Blink will (soon) share registration contexts in these situations:

I. HTML Templates. Between a document and its template document.
II. HTML Imports. Between a document and its imported sub-documents.
III. DOMImplementation. Between a document and document.implementation.createHTMLDocument() or createDocument with an XHTML namespace URI.

This is way down in the weeds, but in my first cut implementation, the sharing is really transitive between documents. So if document A has context P and creates document B that doesn't process custom elements (for example, it is an XML document, not a HTML or XHTML document) and then document B creates document C that *does* process custom elements, document C will get a new, different context Q.

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