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

[whatwg] iframe sandbox attribute

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 29 Mar 2012 14:17:42 -0700
Message-ID: <CAJE5ia_1MURxDFH0R-LwiWCw2cde7XmX10TNCo9cVxzqcOckEQ@mail.gmail.com>
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 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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC