- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 29 Mar 2012 14:17:42 -0700
I guess I don't see much value in using DOMSettableTokenList for the sandbox property. I don't expect folks to mutate the property much. They're just likely to set it to a constant and be done with it. The situation is very different for a property like className, where there's a strong use case for mutating. Adam On Mon, Mar 26, 2012 at 4:06 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 3/26/12 3:19 PM, Ian Hickson wrote: >> >> Changing it to a string doesn't affect that, though, does it? > > > Well, changing to a nullable string does affect it because doing something > like this: > > ?myFrame.sandbox = myFrame.sandbox; > > is a no-op, as by all sane rights it should be.... ?More importantly, > > ?myOtherFrame.sandbox = myFrame.sandbox; > > doesn't have weird surprising behavior if the attribute is something whose > value sanely distinguishes between the various possible sandbox values. > > >> We can certainly add an attribute to DOMSettableTokenList (or rather, a >> descendant, for use specifically with iframe.sandbox) that does the same >> as .hasAttribute(), e.g.: >> >> ? ?iframe.sandbox.present >> >> ...or something, if that would help. > > > Would we also make the attribute readonly, then, and require that it be set > via the token list? ?Otherwise, it seems like the snippets above would still > have pretty unexpected behavior. ?But even then they might, since sets of > readonly props are just silently ignored. ?:( > > -Boris
Received on Thursday, 29 March 2012 14:17:42 UTC