[whatwg] The <iframe> element and sandboxing ideas
ian at hixie.ch
Sat Feb 14 15:46:41 PST 2009
(Please only cc one mailing list when replying, to reduce cross-posting.)
On Sun, 25 May 2008, Jon Ferraiolo wrote:
> Olaf suggested that there might be another attribute to propagate
> events. This is definitely highly desirable in some scenarios. Note that
> the CDF WG has done some work that relates at least partially, although
> I wouldn't be surprised if Ian isn't all that positive on CDF.
> Nevertheless, here is the spec: http://www.w3.org/TR/WICD/. The WICD
> spec focuses on various aspects of not just event propagation, but also
> hyperlink propagation and focus management. All of these topics seem
> worthy of consideration in terms of bridging between the host web page
> and any of the iframes it embeds.
I think this would be an interesting area to extend into, but I think we
should wait until we have more experiense with <iframe sandbox> and
<iframe seamless> before going there. I have, however, noted this proposal
with the WICD link in the spec.
> 3) It seems to me that for some of the propagation areas (e.g., CSS
> propagation, event propagation, focus-model integration) you would want
> both the container and the component to opt-in before the propagation
> occurred. For example, with CSS propagation, there may be cases where
> the component only wants certain of its own characteristics to be
> stylable by the parent. If you look at typical Ajax widgets, which use
> CSS for controlling the visual rendering, there are some aspects which
> are meant to be stylable by the developer, some aspects that are meant
> to be "themable" (i.e., stylable via a shared theme), and other aspects
> which the widget needs to control exclusively and should not be
For widgets, XBL2 is probably the better way of dealing with this.
> I would assume that there are also security issues with allowing the
> parent to override the styling of an embedded iframe because conceivably
> someone could invoke a bank website within an iframe and it wouldn't be
> good if the parent could override some of the CSS for the bank's
> website. Similarly, you probably wouldn't want the parent frame to be
> able to listen to keystrokes that happen within the child iframe (e.g.,
> your password). For some of the information passing between parent and
> child, it might be best to somehow use a publish/subscribe mechanism
> like how postMessage() works, where both both parent and child have to
> opt-in before the propagation occurs.
Since seamless="" only works for same-origin resources anyway, I don't
think there's any new problem here.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg