W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2012

[whatwg] iframe sandbox attribute

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 30 Mar 2012 14:27:38 -0700
Message-ID: <CA+c2ei86xjvZbkm=fQzzjryeqN_pxdG-AsqiLCX3Yth2h45=MA@mail.gmail.com>
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
Received on Friday, 30 March 2012 14:27:38 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC