[whatwg] iframe sandbox attribute

[Ian Melven]

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. 

thanks,
ian


----- Original Message -----
From: "Adam Barth" <w3c at adambarth.com>
To: "Boris Zbarsky" <bzbarsky at mit.edu>
Cc: whatwg at lists.whatwg.org
Sent: Thursday, March 29, 2012 2:17:42 PM
Subject: Re: [whatwg] iframe sandbox attribute

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