- From: David Bruant <bruant.d@gmail.com>
- Date: Fri, 07 Feb 2014 20:30:10 +0100
- To: Chris Coyier <chriscoyier@gmail.com>, whatwg@lists.whatwg.org
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
Received on Friday, 7 February 2014 19:30:36 UTC