Re: [whatwg] <iframe async>

On 27 Feb 2015 at 18:52, Fady Samuel <fsamuel@chromium.org> wrote:

> This is obviously larger than the particular set of use cases mentioned
> here, but another set of iframe discussions I've seen lately have centered
> around going off thread or out of process. I wonder if there is a more
> basic primitive here that can apply to all these use cases [and perhaps
> even allow for new behaviors we haven't thought of]? Perhaps a new email
> thread would be appropriate for such a discussion?
>
> In all these use cases we want to defer content within an iframe or render
> content off the main thread. Perhaps there is a fundamental API whereby we
> can decouple content from container (for non-seamless iframes)? Perhaps
> lifetime management, and the question of what context the content is
> loaded, and rendered in can be decoupled from the lifetime and layout of
> the container iframe?

One thing I'd like would be to be able to put content into an iframe (and thus have it parsed), but defer any rendering or speculative download of resources referred to in the content. This will allow me to modify it. What happens is that I am given a text string, which is untrusted HTML and which may be badly formed, and which I want to modify to remove or disable certain elements before the browser proceeds with it. The content *may* be spam and I want to prevent it from "phoning home".

In principle I could parse the string myself but the browser will do a much better job than I can, which is why I want to modify the content *after* parsing, rather than before.

--
Cheers  --  Tim

Received on Friday, 27 February 2015 19:19:09 UTC