- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 30 Mar 2012 14:27:38 -0700
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