W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2012

Re: [whatwg] iframe sandbox attribute

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 10 Jul 2012 00:39:45 +0000 (UTC)
To: whatwg@lists.whatwg.org
Message-ID: <Pine.LNX.4.64.1207100033080.30734@ps20323.dreamhostps.com>
On Mon, 26 Mar 2012, Boris Zbarsky 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....

Surely that's going to set the attribute regardless of whether the 
attribute is nullable or whatnot. I mean, this always sets the attribute 
even if the attribute wasn't previously set:

   myElement.title = myElement.title


> 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.

I'm not sure I follow.


> > 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.  :(

I think remaining consistent with other non-boolean attributes, and thus 
having the setter always set the attribute, is fine.


On Thu, 29 Mar 2012, Adam Barth wrote:
>
> 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.

On Fri, 30 Mar 2012, Ian Melven 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."

On Fri, 30 Mar 2012, Adam Barth wrote:
> 
> 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.

On Fri, 30 Mar 2012, Jonas Sicking wrote:
> 
> 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.

On Sat, 31 Mar 2012, Anne van Kesteren wrote:
> 
> Such as? I thought the whole point was to do away with that so that 
> authors do not have to implement the parsing logic anymore.

Upon reflection, I haven't changed anything here. I don't see much value 
in making an exception to 'sandbox' here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 10 July 2012 00:40:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:09 GMT