[whatwg] The <iframe> element and sandboxing ideas
bzbarsky at MIT.EDU
Thu May 22 09:27:00 PDT 2008
Ian Hickson wrote:
> - by default, content in sandboxed browsing contexts, and any
> browsing contexts nested in them
How do those nested browsing contexts come about, given that later you say:
> - content in those browsing contexts cannot create new browsing
> contexts or open modal dialogs or alerts
> have a unique origin
> (independent of the origin of their URI); this can be overriden
> using the "allow-same-origin" keyword
So the parent page cannot script the contents of the iframe by default, right?
> - by default, script in those browsing contexts cannot run; this can
> be overriden using the "allow-scripts" keyword
sandbox iframe? Does the script run? If so, in which browsing context?
> causes the iframe to size vertically to the bounding box
> of the contents, and horizontally to the width of the container
I assume that the bounding box is computed after setting the width?
By "the width of the container" do you mean that the iframe computed width
should be equal to its containing block's computed width? Or that the
display:block non-replaced width algorithm from CSS should be used?
> and which causes the initial containing block of the contents to be
> treated as zero height.
So percentage heights would end up being 0, while the iframe would be whatever
height is needed if one assumes they're auto?
> and the style sheets that apply to the <iframe>
> must also apply to the contents.
But the ' ' and '>' combinators don't cross the iframe boundary, right?
> This is all HIGHLY EXPERIMENTAL. I am looking for feedback on the general
> approaches taken.
As someone else pointed out, this doesn't seem like it would be usable without
some UA sniffing or something, as things stand.
> There are various things that this doesn't address yet; e.g. there's no
> way to force (or even allow) a non-seamless iframe to open links in the
> parent window.
This could be an @sandbox keyword value.
> This attribute would
> take a string which would then be interpreted as the source document
> markup of an HTML document, much like the above
This seems very prone to security issues (injection of the closing quote in the
content) to me... The base64 approach is nice in that you can't shoot yourself
in the foot with it.
More information about the whatwg