[whatwg] iframe sandbox attribute
Ian Hickson
ian at hixie.ch
Mon Jul 9 17:39:45 PDT 2012
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list