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 <[email protected]> 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
