[whatwg] crossorigin property on iframe

Thu Apr 12 13:32:48 PDT 2012

On Thu, Apr 12, 2012 at 1:17 PM, Ojan Vafai <ojan at chromium.org> wrote:
> On Thu, Apr 12, 2012 at 1:07 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> On 4/12/12 3:49 PM, Adam Barth wrote:
>>> The seamless part might be workable, since that leaks information only
>>> from the document in question.  It's possible that there's a better
>>> mechanism than CORS for a child frame to opt into being seamless with
>>> its parent.
>>
>> Yes, I agree that having a way for a child to opt into being seamless is
>> desirable.  That doesn't have the problems direct DOM access does.
>
> OK, I'm convinced that direct DOM access is a bad idea. seamless was the
> use-case I most cared about anyways. In theory, if we use seamless + CORS
> for the @src load and any navigations of the frame (including via
> Location), then this should be feasible, yes?
>
> Alternately, we could add a special http header and/or meta tag for this,
> like x-frame-options, but for the child frame to define it's relationship
> to the parent frame.

The reason we have the crossorigin attribute for <img> and <script> is
because the request needs to follow the CORS rules, which means we
need to know ahead of time how to make the request.  In this case, we
don't need to know whether the child wants to opt into cross-origin
seamlessness until we get the response.

For that reason, something like an attribute on the <html> element
might be a better mechanism than CORS.

Adam