For iframe elements in XML documents, the srcdoc attribute, if present, must have a value that matches the
production labeled document in the XML specification. [XML]

Here a blog uses the srcdoc attribute in conjunction
with the sandbox and seamless attributes described below to provide users of user
agents that support this feature with an extra layer of protection from script injection in the
blog post comments:

<article>
<h1>I got my own magazine!</h1>
<p>After much effort, I've finally found a publisher, and so now I
have my own magazine! Isn't that awesome?! The first issue will come
out in September, and we have articles about getting food, and about
getting in boxes, it's going to be great!</p>
<footer>
<p>Written by <a href="/users/cap">cap</a>, 1 hour ago.
</footer>
<article>
<footer> Thirteen minutes ago, <a href="/users/ch">ch</a> wrote: </footer>
<iframe seamless sandbox srcdoc="<p>did you get a cover picture yet?"></iframe>
</article>
<article>
<footer> Nine minutes ago, <a href="/users/cap">cap</a> wrote: </footer>
<iframe seamless sandbox srcdoc="<p>Yeah, you can see it <a href=&quot;/gallery?mode=cover&amp;amp;page=1&quot;>in my gallery</a>."></iframe>
</article>
<article>
<footer> Five minutes ago, <a href="/users/ch">ch</a> wrote: </footer>
<iframe seamless sandbox srcdoc="<p>hey that's earl's table.
<p>you should get earl&amp;amp;me on the next cover."></iframe>
</article>

Notice the way that quotes have to be escaped (otherwise the srcdoc attribute would end prematurely), and the way raw
ampersands (e.g. in URLs or in prose) mentioned in the sandboxed content have to be
doubly escaped — once so that the ampersand is preserved when originally parsing
the srcdoc attribute, and once more to prevent the
ampersand from being misinterpreted when parsing the sandboxed content.

In the HTML syntax, authors need only remember to use """ (U+0022) characters to wrap the attribute contents and then to escape all """ (U+0022) and U+0026 AMPERSAND (&) characters, and to specify the sandbox attribute, to ensure safe embedding of content.

Due to restrictions of the XHTML syntax, in XML the U+003C LESS-THAN
SIGN character (<) needs to be escaped as well. In order to prevent attribute-value normalization, some of XML's
whitespace characters — specifically "tab" (U+0009), "LF" (U+000A), and "CR" (U+000D) — also need to be escaped. [XML]

If the src attribute and the srcdoc attribute are both specified together, the srcdoc attribute takes priority. This allows authors to provide
a fallback URL for legacy user agents that do not support the srcdoc attribute.

If, when the element is created, the srcdoc attribute is not set, and the src attribute is either also not set or set but its value cannot be
resolved, the browsing context will remain at the initial
about:blank page.

Setting both the allow-scripts and allow-same-origin keywords together when the
embedded page has the same origin as the page containing the iframe
allows the embedded page to simply remove the sandbox
attribute and then reload itself, effectively breaking out of the sandbox altogether.

Potentially hostile files should not be served from the same server as the file
containing the iframe element. Sandboxing hostile content is of minimal help if an
attacker can convince the user to just visit the hostile content directly, rather than in the
iframe. To limit the damage that can be caused by hostile HTML content, it should be
served from a separate dedicated domain. Using a different domain ensures that scripts in the
files are unable to attack the site, even if the user is tricked into visiting those pages
directly, without the protection of the sandbox
attribute.

In this example, some completely-unknown, potentially hostile, user-provided HTML content is
embedded in a page. Because it is served from a separate domain, it is affected by all the normal
cross-site restrictions. In addition, the embedded page has scripting disabled, plugins disabled,
forms disabled, and it cannot navigate any frames or windows other than itself (or any frames or
windows it itself embeds).

It is important to use a separate domain so that if the attacker convinces the
user to visit that page directly, the page doesn't run in the context of the site's origin, which
would make the user vulnerable to any attack found in the page.

In this example, a gadget from another site is embedded. The gadget has scripting and forms
enabled, and the origin sandbox restrictions are lifted, allowing the gadget to communicate with
its originating server. The sandbox is still useful, however, as it disables plugins and popups,
thus reducing the risk of the user being exposed to malware and other annoyances.

Page C in this scenario has all the sandboxing flags set. Scripts are disabled, because the
iframe in A has scripts disabled, and this overrides the allow-scripts keyword set on the
iframe in B. Forms are also disabled, because the inner iframe (in B)
does not have the allow-forms keyword
set.

Suppose now that a script in A removes all the sandbox attributes in A and B.
This would change nothing immediately. If the user clicked the link in C, loading page D into the
iframe in B, page D would now act as if the iframe in B had the allow-same-origin and allow-forms keywords set, because that was the
state of the nested browsing context in the iframe in A when page B was
loaded.

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.

The seamless attribute is a boolean
attribute. When specified, it indicates that the iframe element's
browsing context is to be rendered in a manner that makes it appear to be part of the
containing document (seamlessly included in the parent document).

An iframe element is said to be in seamless mode when all of the
following conditions are met:

In a CSS-supporting user agent: the user agent must add all the style sheets that apply to
the iframe element to the cascade of the active document of the
iframe element's nested browsing context, at the appropriate cascade
levels, before any style sheets specified by the document itself.

In a CSS-supporting user agent: the user agent must, for the purpose of CSS property
inheritance only, treat the root element of the active document of the
iframe element's nested browsing context as being a child of the
iframe element. (Thus inherited properties on the root element of the document in
the iframe will inherit the computed values of those properties on the
iframe element instead of taking their initial values.)

In visual media, in a CSS-supporting user agent: the user agent should set the intrinsic
width of the iframe to the width that the element would have if it was a
non-replaced block-level element with 'width: auto', unless that width would be zero (e.g. if the
element is floating or absolutely positioned), in which case the user agent should set the
intrinsic width of the iframe to the shrink-to-fit width of the root element (if
any) of the content rendered in the iframe.

In visual media, in a CSS-supporting user agent: the user agent should set the intrinsic
height of the iframe to the shortest height that would make the content rendered in
the iframe at its current width (as given in the previous bullet point) have no
scrollable overflow at its bottom edge. Scrollable overflow is any overflow that would increase the range to
which a scrollbar or other scrolling mechanism can scroll.

This is intended to get around the otherwise circular dependency of percentage
dimensions that depend on the height of the containing block, thus affecting the height of the
document's bounding box, thus affecting the height of the viewport, thus affecting the size of
the initial containing block.

In speech media, the user agent should render the nested browsing context
without announcing that it is a separate document.

For example if the user agent supports listing all the links in a document,
links in "seamlessly" nested documents would be included in that list without being
significantly distinguished from links in the document itself.

The attribute can be set or removed dynamically, with the rendering updating in
tandem.

In this example, the site's navigation is embedded using a client-side include using an
iframe. Any links in the iframe will, in new user agents, be
automatically opened in the iframe's parent browsing context; for legacy user
agents, the site could also include a base element with a target attribute with the value _parent.
Similarly, in new user agents the styles of the parent page will be automatically applied to the
contents of the frame, but to support legacy user agents authors might wish to include the styles
explicitly.

Descendants of iframe elements represent nothing. (In legacy user agents that do
not support iframe elements, the contents would be parsed as markup that could act as
fallback content.)

When used in HTML documents, the allowed content model
of iframe elements is text, except that invoking the HTML fragment parsing
algorithm with the iframe element as the context element and the text contents as the input must result in a list of nodes that are all phrasing content,
with no parse errors having occurred, with no script
elements being anywhere in the list or as descendants of elements in the list, and with all the
elements in the list (including their descendants) being themselves conforming.