[whatwg] iframe sandbox attribute

Jonas Sicking jonas at sicking.cc
Fri Mar 30 14:27:38 PDT 2012

On Fri, Mar 30, 2012 at 1:14 PM, Adam Barth <w3c at adambarth.com> wrote:
> On Fri, Mar 30, 2012 at 12:22 PM, Ian Melven <imelven at mozilla.com> wrote:
>> I agree that it's pretty likely folks won't be mutating
>> this property very often - the HTML5 spec actually
>> recommends against messing with the sandbox attribute dynamically at all :
>> "Generally speaking, dynamically removing or changing the sandbox attribute is ill-advised,
>> because it can make it quite hard to reason about what will be allowed and what will not."
>> (which I also agree with. )
>> that said, what do you think about the case Boris points out where
>> myFrame.sandbox = myFrame.sandbox; can change the sandboxing
>> of a frame ?
>> In my opinion, both this and the case involving myOtherFrame.sandbox = myFrame.sandbox;
>> are pretty non-intuitive - unless as Boris suggests, .sandbox is null for an iframe which
>> hasn't had a sandbox attribute declared. A script author could use .present
>> or .hasAttribute to work around this, but my concern is the potentially
>> surprising behavior.
> IMHO, it's better if the sandbox property behaves like other
> properties rather than being magically different.  In these cases, the
> result is more sandboxing than you might expect rather than less,
> which is probably fine.

I think there's a lot of logic to that. One thing that I think we
should do as part of that is to drop the DOMSettableTokenList. By far
more "mapped attributes" are normal DOMStrings.

/ Jonas

More information about the whatwg mailing list