[whatwg] iframes, more sandbox
David Bruant
bruant.d at gmail.com
Fri Feb 7 11:30:10 PST 2014
Hi Chris,
Le 06/02/2014 16:54, Chris Coyier a écrit :
> Hey folks. Long time listener, first time caller.
Thanks for participating :-)
> I'm hoping for more a little bit more control over <iframe>s. We have
> <iframe sandbox> which is pretty fantastic right now. I'd like to see some
> possibilities in both directions (more and less strict).
>
> More strict:
> - Disallow modal dialogs (e.g. alert, confirm) but otherwise allowing
> scripts via allow-scripts
I like this. It enables to prevent sandboxed iframes from disrupting the
user.
Maybe alongside allow-popup or as its own independent flag?
> - Also dialogs like when a page or resource is .htpasswd protected
Is this part of the previous point or an independent addition?
> - Do not make sound, period. Autoplay is already disabled in sandbox, but
> can be circumvented (e.g. by creating new audio element that autoplays,
> apis that create iframes (soundcloud, vimeo) that then play).
yep.
> - Cannot contain another iframe
Why? Which problem does this solve?
> - Essentially lower the risk-of-annoyance of an <iframe>
Do you have others in mind?
> Less strict:
> - Allow some safe version of target="_blank" links
Can you elaborate on that?
> Right now the model for sandbox is "as strict as possible by default" then
> loosen restrictions with attribute values. So I'm not sure how this could
> be approached, since it feels like it would be weird to all the sudden make
> the sandbox attribute more strict than it was before and it also seems
> weird to have some attributes that strengthen strictness and some
> attributes that loosen it.
No worries, that can change. Wouldn't be the first time assumptions
changes for a feature :-p
David
More information about the whatwg
mailing list