On Fri, Mar 30, 2012 at 1:14 PM, Adam Barth <[email protected]> wrote: > On Fri, Mar 30, 2012 at 12:22 PM, Ian Melven <[email protected]> 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
