The excellent out-of-process iframe work that's been done in:
http://www.chromium.org/developers/design-documents/oop-iframes

is a great basis for prototyping uploading HTML rendering results to WebGL textures, a longstanding feature request.

As discussed in the WebGL working group, the general direction for this feature that all browser vendors supported was:

1. Adding a new tag understood by the iframe "sandbox" attribute which would mean:

1a. Only allow resource fetches from the same origin as the top-level document. This restriction would prevent cross-origin resources from becoming accessible to untrusted WebGL code, which is not allowed. (The "crossOrigin" attribute on HTMLMediaElement provides a targeted solution for just those elements; a more general solution needs to be devised here, but this severe restriction should make it safe.)

1b. Treat the iframe as incognito mode. This should prevent personally identifiable information from showing up in the rendering results.

2. Adding APIs, which only work in this iframe mode, which would allow dispatching of synthetic mouse and keyboard events into the iframe. These are needed because only the embedding WebGL application knows where clicks should occur.

These security restrictions might limit the utility of the API, but they should make it safe. From a safe beginning, the API can then be relaxed.

An initial prototype (not to be shipped) could try using the out-of-process iframe rendering framework described here:
http://www.chromium.org/developers/design-documents/oop-iframes/oop-iframes-rendering

to see how difficult it is to get it into a WebGL texture. If the security properties above could then be enforced, the prototype could be placed behind a flag.