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
What happens if the parent page sets window.location to a javascript: URI on the
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.
-Boris