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.

Empty: When the steps above require the user agent to
jump to the empty step, if the user agent is
processing this iframe's attributes for the first
time, then the user agent must queue a task to
fire a simple event named load at the iframe
element. (After jumping to this step, the above steps are not
resumed.)

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.

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>.
<time pubdate>2009-08-21T23:32Z</time></p>
</footer>
<article>
<footer> At <time pubdate>2009-08-21T23:35Z</time>, <a href="/users/ch">ch</a> writes: </footer>
<iframe seamless sandbox srcdoc="<p>did you get a cover picture yet?"></iframe>
</article>
<article>
<footer> At <time pubdate>2009-08-21T23:44Z</time>, <a href="/users/cap">cap</a> writes: </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> At <time pubdate>2009-08-21T23:58Z</time>, <a href="/users/ch">ch</a> writes: </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
sandbox 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 sandbox 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 QUOTATION MARK characters (") to wrap the
attribute contents and then to escape all U+0022 QUOTATION MARK (")
and U+0026 AMPERSAND (&) characters, and to specify the sandbox attribute, to ensure safe
embedding of content.

Due to restrictions of the XML syntax,
in XML the U+003C LESS-THAN SIGN character (<) needs to be
escaped as well. In order to prevent attribute-value
normalization, XML's whitespace characters — U+0009
CHARACTER TABULATION (HT), U+000A LINE FEED (LF), U+000D CARRIAGE
RETURN (CR) and U+0020 SPACE — also need to be escaped. [XML]

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 using the text/html-sandboxed MIME type.

This flag prevents content from using the seamless attribute on
descendant iframe elements.

This prevents a page inserted using the allow-same-origin
keyword from using a CSS-selector-based method of probing the DOM
of other pages on the same site (in particular, pages that contain
user-sensitive information).

The sandboxed origin browsing context flag, unless
the sandbox attribute's
value, when split on
spaces, is found to have the allow-same-origin
keyword set

First, it can be used to allow content from the same site to
be sandboxed to disable scripting, while still allowing access to
the DOM of the sandboxed content.

Second, it can be used to embed content from a third-party
site, sandboxed to prevent that site from opening popup windows,
etc, without preventing the embedded page from communicating back
to its originating site, using the database APIs to store data,
etc.

The sandboxed forms browsing context flag, unless
the sandbox attribute's
value, when split on
spaces, is found to have the allow-forms
keyword set

The sandboxed automatic features browsing context
flag, unless the sandbox attribute's value, when
split on spaces, is
found to have the allow-scripts
keyword (defined above) set

This flag blocks features that trigger automatically, such as
automatically playing a
video or automatically
focusing a form control. It is relaxed by the same flag as
scripts, because when scripts are enabled these features are
trivially possible anyway, and it would be unfortunate to force
authors to use script to do them when sandboxed rather than
allowing them to use the declarative features.

These flags must not be set unless the conditions listed above
define them as being set.

In this example, some completely-unknown, potentially hostile,
user-provided HTML content is embedded in a page. Because it is
sandboxed, it is treated by the user agent as being from a unique
origin, despite the content being served from the same site. Thus
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).

Note that cookies are still sent to the server in the getusercontent.cgi request, though they are not
visible in the document.cookie IDL
attribute.

It is important that the server serve the
user-provided HTML using the text/html-sandboxed MIME
type 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.

Potentially hostile files can be served from the
same server as the file containing the iframe element
by labeling them as text/html-sandboxed instead of
text/html. This ensures that scripts in the files are
unable to attack the site (as if they were actually served from
another server), even if the user is tricked into visiting those
pages directly, without the protection of the sandbox attribute.

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'.

In visual media, in a CSS-supporting user agent: the user
agent should set the intrinsic height of the iframe to
the height of the bounding box around the content rendered in the
iframe at its current width (as given in the previous
bullet point), as it would be if the scrolling position was such
that the top of the viewport for the content rendered in the
iframe was aligned with the origin of that content's
canvas.

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.

When the element is created with neither a src attribute nor a type attribute, and when attributes
are removed such that neither attribute is present on the element
anymore, and when the element has a media element
ancestor, and when the element has an ancestor object
element that is not showing its fallback
content, any plugins instantiated for the element must be
removed, and the embed element represents nothing.

...then the user agent must render the embed element
in a manner that conveys that the plugin was
disabled. The user agent may offer the user the option to override
the sandbox and instantiate the plugin anyway; if the
user invokes such an option, the user agent must act as if the
conditions above did not apply for the purposes of this element.

Plugins are disabled in sandboxed browsing
contexts because they might not honor the restrictions imposed by
the sandbox (e.g. they might allow scripting even when scripting in
the sandbox is disabled). User agents should convey the danger of
overriding the sandbox to the user if an option to do so is
provided.

An embed element is said to be potentially active when the
following conditions are all met simultaneously:

Otherwise, the content has no type and there can be no
appropriate plugin for it.

The embed element has no fallback
content. If the user agent can't find a suitable plugin, then
the user agent must use a default plugin. (This default could be as
simple as saying "Unsupported Format".)

Whether the resource is fetched successfully or not (e.g. whether
the response code was a 2xx code or equivalent) must be
ignored when determining the resource's type and when handing the
resource to the plugin.

Any namespace-less attribute other than name, align, hspace, and vspace may be specified on the embed element,
so long as its name is XML-compatible and contains no
characters in the range U+0041 to U+005A (LATIN CAPITAL LETTER A to
LATIN CAPITAL LETTER Z). These attributes are then passed as
parameters to the plugin.

All attributes in HTML documents get
lowercased automatically, so the restriction on uppercase letters
doesn't affect such documents.

The four exceptions are to exclude legacy attributes
that have side-effects beyond just sending parameters to the
plugin.

The user agent should pass the names and values of all the
attributes of the embed element that have no namespace
to the plugin used, when it is instantiated.

If the plugin instantiated for the
embed element supports a scriptable interface, the
HTMLEmbedElement object representing the element should
expose that interface while the element is instantiated.

Depending on the type of content instantiated by the
object element, the node also supports other
interfaces.

The object element can represent an external
resource, which, depending on the type of the resource, will either
be treated as an image, as a nested browsing context,
or as an external resource to be processed by a
plugin.

If the data attribute
is present and its value is not the empty string, then:

If the type
attribute is present and its value is not a type that the user
agent supports, and is not a type that the user agent can find a
plugin for, then the user agent may jump to the last
step in the overall set of steps (fallback) without fetching the
content to examine its real type.

Resolve the
URL specified by the data attribute, relative to the
element.

If that failed, fire a simple event named
error at the element, then jump
to the last step in the overall set of steps (fallback).

If the resource is not yet available (e.g. because the
resource was not available in the cache, so that loading the
resource required making a request over the network), then jump
to the last step in the overall set of steps (fallback). The
task that is queued by the networking task source
once the resource is available must restart this algorithm from
this step. Resources can load incrementally; user agents may opt
to consider a resource "available" whenever enough data has been
obtained to begin processing the resource.

If the load failed (e.g. there was an HTTP 404 error,
there was a DNS error), fire a simple event named
error at the element, then jump
to the last step in the overall set of steps (fallback).

If there is a type
attribute present on the object element, and that
attribute's value is not a type that the user agent supports,
but it is a type that a plugin supports,
then let the resource type be the type
specified in that type
attribute, and jump to the step below labeled
handler.

If there is a type attribute present on
the object element, and its value is not
application/octet-stream, then run the
following steps:

If the attribute's value is a type that a plugin supports, or
the attribute's value is a type that starts with "image/" that is not also an XML MIME type,
then let the resource type be the type specified in that type attribute.

When the algorithm above instantiates a
plugin, the user agent should pass to the
plugin used the names and values of all the attributes
on the element, in the order they were added to the element, with
the attributes added by the parser being ordered in source order,
followed by a parameter named "PARAM" whose value is null,
followed by all the names and values of parameters given by
param elements that are children of the
object element, in tree order. If the
plugin supports a scriptable interface, the
HTMLObjectElement object representing the element
should expose that interface. The object element
represents the plugin. The
plugin is not a nested browsing
context.

...then the steps above must always act as if they had failed to
find a plugin, even if one would otherwise have been
used.

The above algorithm is independent of CSS properties
(including 'display', 'overflow', and 'visibility'). For example, it
runs even if the element is hidden with a 'display:none' CSS style,
and does not run again if the element's visibility
changes.

Due to the algorithm above, the contents of object
elements act as fallback content, used only when
referenced resources can't be shown (e.g. because it returned a 404
error). This allows multiple object elements to be
nested inside each other, targeting multiple user agents with
different capabilities, with the user agent picking the first one it
supports.

The usemap attribute,
if present while the object element represents an
image, can indicate that the object has an associated image
map. The attribute must be ignored if the
object element doesn't represent an image.

In the following example, a Java applet is embedded in a page
using the object element. (Generally speaking, it is
better to avoid using applets like these and instead use native
JavaScript and HTML to provide the functionality, since that way
the application will work on all Web browsers without requiring a
third-party plugin. Many devices, especially embedded devices, do
not support third-party technologies like Java.)

The following example shows how a plugin can be used in HTML (in
this case the Flash plugin, to show a video file). Fallback is
provided for users who do not have Flash enabled, in this case
using the video element to show the video for those
using user agents that support video, and finally
providing a link to the video for those who have neither Flash nor
a video-capable browser.

The param element defines parameters for plugins
invoked by object elements. It does not represent anything on its own.

The name
attribute gives the name of the parameter.

The value
attribute gives the value of the parameter.

Both attributes must be present. They may have any value.

If both attributes are present, and if the parent element of the
param is an object element, then the
element defines a parameter with the given
name/value pair.

If either the name or value of a parameter defined by a
param element that is the child of an
object element that represents an
instantiated plugin changes, and if that
plugin is communicating with the user agent using an
API that features the ability to update the plugin when
the name or value of a parameter so changes, then
the user agent must appropriately exercise that ability to notify
the plugin of the change.

The IDL attributes name and value must both
reflect the respective content attributes of the same
name.

The following example shows how the param element
can be used to pass a parameter to a plugin, in this case the O3D
plugin.