HTML

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

---

When an iframe element is inserted into a document, the user agent must create a nested browsing context, and then process the iframe attributes for the first time.

When an iframe element is removed from a document, the user agent must discard the nested browsing context.

This happens without any unload events firing (the nested browsing context and its Document are discarded, not unloaded).

Whenever an iframe element with a nested browsing context has its srcdoc attribute set, changed, or removed, the user agent must process the iframe attributes.

Similarly, whenever an iframe element with a nested browsing context but with no srcdoc attribute specified has its src attribute set, changed, or removed, the user agent must process the iframe attributes.

When the user agent is to process the iframe attributes, it must run the first appropriate steps from the following list:

If the srcdoc attribute is specified

Navigate the element's child browsing context to a resource whose Content-Type is text/html, whose URL is about:srcdoc, and whose data consists of the value of the attribute. The resulting Document must be considered an iframe srcdoc document.

Otherwise, if the element has no src attribute specified, and the user agent is processing the iframe's attributes for the first time

Queue a task to run the iframe load event steps.

Otherwise

1. If the value of the src attribute is the empty string, let url be the string "about:blank".

   Otherwise, resolve the value of the src attribute, relative to the iframe element.

   If that is not successful, then let url be the string "about:blank". Otherwise, let url be the resulting absolute URL.

2. If there exists an ancestor browsing context whose active document's address, ignoring fragment identifiers, is equal to url, then abort these steps.

3. Navigate the element's child browsing context to url.

Any navigation required of the user agent in the process the iframe attributes algorithm must be completed as an explicit self-navigation override and with the iframe element's document's browsing context as the source browsing context.

Furthermore, if the active document of the element's child browsing context before such a navigation was not completely loaded at the time of the new navigation, then the navigation must be completed with replacement enabled.

Similarly, if the child browsing context's session history contained only one Document when the process the iframe attributes algorithm was invoked, and that was the about:blank Document created when the child browsing context was created, then any navigation required of the user agent in that algorithm must be completed with replacement enabled.

When a Document in an iframe is marked as completely loaded, the user agent must synchronously run the iframe load event steps.

When content whose URL has the same origin as the iframe element's Document fails to load (e.g. due to a DNS error, network error, or if the server returned a 4xx or 5xx status code or equivalent), then the user agent must queue a task to fire a simple event named error at the element instead. (This event does not fire for parse errors, script errors, or any errors for cross-origin resources.)

The task source for these tasks is the DOM manipulation task source.

A load event is also fired at the iframe element when it is created if no other data is loaded in it.

Each Document has an iframe load in progress flag and a mute iframe load flag. When a Document is created, these flags must be unset for that Document.

The iframe load event steps are as follows:

1. Let child document be the active document of the iframe element's nested browsing context.

2. If child document has its mute iframe load flag set, abort these steps.

3. Set child document's iframe load in progress flag.

4. Fire a simple event named load at the iframe element.

5. Unset child document's iframe load in progress flag.

This, in conjunction with scripting, can be used to probe the URL space of the local network's HTTP servers. User agents may implement cross-origin access control policies that are stricter than those described above to mitigate this attack, but unfortunately such policies are typically not compatible with existing Web content.

When the iframe's browsing context's active document is not ready for post-load tasks, and when anything in the iframe is delaying the load event of the iframe's browsing context's active document, and when the iframe's browsing context is in the delaying load events mode, the iframe must delay the load event of its document.

If, during the handling of the load event, the browsing context in the iframe is again navigated, that will further delay the load event.

Whenever the name attribute is set, the nested browsing context's name must be changed to the new value. If the attribute is removed, the browsing context name must be set to the empty string.

When an iframe element with a sandbox attribute has its nested browsing context created (before the initial about:blank Document is created), and when an iframe element's sandbox attribute is set or changed while it has a nested browsing context, the user agent must parse the sandboxing directive using the attribute's value as the input, the iframe element's nested browsing context's iframe sandboxing flag set as the output, and, if the iframe has an allowfullscreen attribute, the allow fullscreen flag.

When an iframe element's sandbox attribute is removed while it has a nested browsing context, the user agent must empty the iframe element's nested browsing context's iframe sandboxing flag set as the output.

<p>We're not scared of you! Here is your content, unedited:</p>
<iframe sandbox src="http://usercontent.example.net/getusercontent.cgi?id=12193"></iframe>

<iframe sandbox="allow-same-origin allow-forms allow-scripts"
        src="http://maps.example.com/embedded.html"></iframe>

<iframe sandbox="allow-same-origin allow-forms" src=B></iframe>

<iframe sandbox="allow-scripts" src=C></iframe>

<a href=D>Link</a>

<!DOCTYPE HTML>
<title>Mirror Mirror — MovieInfo™</title>
<header>
 <h1>Mirror Mirror</h1>
 <p>Part of the MovieInfo™ Database</p>
 <nav>
  <iframe seamless src="nav.inc"></iframe>
 </nav>
</header>
...

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

• The seamless attribute is set on the iframe element, and
• The iframe element's owner Document's active sandboxing flag set does not have the sandboxed seamless iframes flag set, and
• Either:
  • The browsing context's active document has the same origin as the iframe element's Document, or
  • The browsing context's active document's address has the same origin as the iframe element's Document, or
  • The browsing context's active document is an iframe srcdoc document.

When an iframe element is in seamless mode, the following requirements apply:

• The user agent must set the seamless browsing context flag to true for that browsing context. This will cause links to open in the parent browsing context unless an explicit self-navigation override is used (target="_self").

• Media queries in the context of the iframe's browsing context (e.g. on media attributes of style elements in Documents in that iframe) must be evaluated with respect to the nearest ancestor browsing context that is not itself being nested through an iframe that is in seamless mode. [MQ]

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

• In visual media, in a CSS-supporting user agent: the user agent must force the height of the initial containing block of the active document of the nested browsing context of the iframe to zero.

  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.

• User agents should, in general, act as if the active document of the iframe's nested browsing context was part of the document that the iframe is in, if any.

  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 nested browsing context's Window object's cross-boundary event parent is the browsing context container. [DOM]

If the attribute is not specified, or if the origin conditions listed above are not met, then the user agent should render the nested browsing context in a manner that is clearly distinguishable as a separate browsing context, and the seamless browsing context flag must be set to false for that browsing context.

It is important that user agents recheck the above conditions whenever the active document of the nested browsing context of the iframe changes, such that the seamless browsing context flag gets unset if the nested browsing context is navigated to another origin.

<nav><iframe seamless src="nav.include.html"></iframe></nav>

---

The IDL attributes src, srcdoc, name, sandbox, and seamless must reflect the respective content attributes of the same name.

The allowFullscreen IDL attribute must reflect the allowfullscreen content attribute.

The contentDocument IDL attribute must return the Document object of the active document of the iframe element's nested browsing context, if any, or null otherwise.

The contentWindow IDL attribute must return the WindowProxy object of the iframe element's nested browsing context, if any, or null otherwise.

<iframe src="http://ads.example.com/?customerid=923513721&amp;format=banner"
        width="468" height="60"></iframe>

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.

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

• The element is in a Document or was in a Document the last time the event loop reached step 1.
• The element's Document is fully active.
• The element has either a src attribute set or a type attribute set (or both).
• The element's src attribute is either absent or its value is not the empty string.
• The element is not a descendant of a media element.
• The element is not a descendant of an object element that is not showing its fallback content.
• The element is being rendered, or was being rendered the last time the event loop reached step 1.

Whenever an embed element that was not potentially active becomes potentially active, and whenever a potentially active embed element that is remaining potentially active and has its src attribute set, changed, or removed or its type attribute set, changed, or removed, the user agent must queue a task using the embed task source to run the following steps:

1. If another task has since been queued to run these steps for this element, then abort these steps.

2. If the element has a src attribute set

   The user agent must resolve the value of the element's src attribute, relative to the element. If that is successful, the user agent should fetch the resulting absolute URL, from the element's browsing context scope origin if it has one. The task that is queued by the networking task source once the resource has been fetched must find and instantiate an appropriate plugin based on the content's type, and hand that plugin the content of the resource, replacing any previously instantiated plugin for the element.

   Fetching the resource must delay the load event of the element's document.

   If the element has no src attribute set

   The user agent should find and instantiate an appropriate plugin based on the value of the type attribute.

Whenever an embed element that was potentially active stops being potentially active, any plugin that had been instantiated for that element must be unloaded.

When a plugin is to be instantiated but it cannot be secured and the sandboxed plugins browsing context flag is set on the embed element's Document's active sandboxing flag set, then the user agent must not instantiate the plugin, and must instead 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 that cannot be secured 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.

The type of the content being embedded is defined as follows:

1. If the element has a type attribute, and that attribute's value is a type that a plugin supports, then the value of the type attribute is the content's type.

2. Otherwise, if applying the URL parser algorithm to the URL of the specified resource (after any redirects) results in a parsed URL whose path component matches a pattern that a plugin supports, then the content's type is the type that that plugin can handle.

   For example, a plugin might say that it can handle resources with path components that end with the four character string ".swf".

3. Otherwise, if the specified resource has explicit Content-Type metadata, then that is the content's type.

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

This allows servers to return data for plugins even with error responses (e.g. HTTP 500 Internal Server Error codes can still contain plugin data).

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.

The HTMLEmbedElement object representing the element must expose the scriptable interface of the plugin instantiated for the embed element. At a minimum, this interface must implement the legacy caller operation. (It is suggested that the default behavior of this legacy caller operation, e.g. the behavior of the default plugin's legacy caller operation, be to throw a NotSupportedError exception.)

The IDL attributes src and type each must reflect the respective content attributes of the same name.

<embed src="catgame.swf">

<embed src="catgame.swf" quality="high">

<object data="catgame.swf">
 <param name="quality" value="high">
</object>

Whenever one of the following conditions occur:

• the element is created,
• the element is popped off the stack of open elements of an HTML parser or XML parser,
• the element is not on the stack of open elements of an HTML parser or XML parser, and it is either inserted into a document or removed from a document,
• the element's Document changes whether it is fully active,
• one of the element's ancestor object elements changes to or from showing its fallback content,
• the element's classid attribute is set, changed, or removed,
• the element's classid attribute is not present, and its data attribute is set, changed, or removed,
• neither the element's classid attribute nor its data attribute are present, and its type attribute is set, changed, or removed,
• the element changes from being rendered to not being rendered, or vice versa,

...the user agent must queue a task to run the following steps to (re)determine what the object element represents. The task source for this task is the DOM manipulation task source. This task being queued or actively running must delay the load event of the element's document.

1. If the user has indicated a preference that this object element's fallback content be shown instead of the element's usual behavior, then jump to the last step in the overall set of steps (fallback).

   For example, a user could ask for the element's fallback content to be shown because that content uses a format that the user finds more accessible.

2. If the element has an ancestor media element, or has an ancestor object element that is not showing its fallback content, or if the element is not in a Document with a browsing context, or if the element's Document is not fully active, or if the element is still in the stack of open elements of an HTML parser or XML parser, or if the element is not being rendered, then jump to the last step in the overall set of steps (fallback).

3. If the classid attribute is present, and has a value that isn't the empty string, then: if the user agent can find a plugin suitable according to the value of the classid attribute, and either plugins aren't being sandboxed or that plugin can be secured, then that plugin should be used, and the value of the data attribute, if any, should be passed to the plugin. If no suitable plugin can be found, or if the plugin reports an error, jump to the last step in the overall set of steps (fallback).

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

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

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

   3. 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).

   4. Fetch the resulting absolute URL, from the element's browsing context scope origin if it has one.

      Fetching the resource must delay the load event of the element's document until the task that is queued by the networking task source once the resource has been fetched (defined next) has been run.

      For the purposes of the application cache networking model, this fetch operation is not for a child browsing context (though it might end up being used for one after all, as defined below).

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

   6. 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).

   7. Determine the resource type, as follows:

      1. Let the resource type be unknown.

      2. If the object element has a type attribute and a typemustmatch attribute, and the resource has associated Content-Type metadata, and the type specified in the resource's Content-Type metadata is an ASCII case-insensitive match for the value of the element's type attribute, then let resource type be that type and jump to the step below labeled handler.

      3. If the object element has a typemustmatch attribute, jump to the step below labeled handler.

      4. If the user agent is configured to strictly obey Content-Type headers for this resource, and the resource has associated Content-Type metadata, then let the resource type be the type specified in the resource's Content-Type metadata, and jump to the step below labeled handler.

         This can introduce a vulnerability, wherein a site is trying to embed a resource that uses a particular plugin, but the remote site overrides that and instead furnishes the user agent with a resource that triggers a different plugin with different security characteristics.

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

      6. Run the appropriate set of steps from the following list:

         If the resource has associated Content-Type metadata

         1. Let binary be false.

         2. If the type specified in the resource's Content-Type metadata is "text/plain", and the result of applying the rules for distinguishing if a resource is text or binary to the resource is that the resource is not text/plain, then set binary to true.

         3. If the type specified in the resource's Content-Type metadata is "application/octet-stream", then set binary to true.

         4. If binary is false, then let the resource type be the type specified in the resource's Content-Type metadata, and jump to the step below labeled handler.

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

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

            2. Jump to the step below labeled handler.

         Otherwise, if the resource does not have associated Content-Type metadata

         1. If there is a type attribute present on the object element, then let the tentative type be the type specified in that type attribute.

            Otherwise, let tentative type be the sniffed type of the resource.

         2. If tentative type is not application/octet-stream, then let resource type be tentative type and jump to the step below labeled handler.

      7. If applying the URL parser algorithm to the URL of the specified resource (after any redirects) results in a parsed URL whose path component matches a pattern that a plugin supports, then let resource type be the type that that plugin can handle.

         For example, a plugin might say that it can handle resources with path components that end with the four character string ".swf".

      It is possible for this step to finish, or for one of the substeps above to jump straight to the next step, with resource type still being unknown. In both cases, the next step will trigger fallback.

   8. Handler: Handle the content as given by the first of the following cases that matches:

      If the resource type is not a type that the user agent supports, but it is a type that a plugin supports

      If plugins are being sandboxed and the plugin that supports resource type cannot be secured, jump to the last step in the overall set of steps (fallback).

      Otherwise, the user agent should use the plugin that supports resource type and pass the content of the resource to that plugin. If the plugin reports an error, then jump to the last step in the overall set of steps (fallback).

      If the resource type is an XML MIME type, or if the resource type does not start with "image/"

      The object element must be associated with a newly created nested browsing context, if it does not already have one.

      If the URL of the given resource is not about:blank, the element's nested browsing context must then be navigated to that resource, with replacement enabled, and with the object element's document's browsing context as the source browsing context. (The data attribute of the object element doesn't get updated if the browsing context gets further navigated to other locations.)

      If the URL of the given resource is about:blank, then, instead, the user agent must queue a task to fire a simple event named load at the object element. No load event is fired at the about:blank document itself.

      The object element represents the nested browsing context.

      If the name attribute is present, the browsing context name must be set to the value of this attribute; otherwise, the browsing context name must be set to the empty string.

      In certain situations, e.g. if the resource was fetched from an application cache but it is an HTML file with a manifest attribute that points to a different application cache manifest, the navigation of the browsing context will be restarted so as to load the resource afresh from the network or a different application cache. Even if the resource is then found to have a different type, it is still used as part of a nested browsing context: only the navigate algorithm is restarted, not this object algorithm.

      If the resource type starts with "image/", and support for images has not been disabled

      Apply the image sniffing rules to determine the type of the image.

      The object element represents the specified image. The image is not a nested browsing context.

      If the image cannot be rendered, e.g. because it is malformed or in an unsupported format, jump to the last step in the overall set of steps (fallback).

      Otherwise

      The given resource type is not supported. Jump to the last step in the overall set of steps (fallback).

      If the previous step ended with the resource type being unknown, this is the case that is triggered.

   9. The element's contents are not part of what the object element represents.

   10. Once the resource is completely loaded, queue a task to fire a simple event named load at the element.

       The task source for this task is the DOM manipulation task source.

5. If the data attribute is absent but the type attribute is present, and the user agent can find a plugin suitable according to the value of the type attribute, and either plugins aren't being sandboxed or the plugin can be secured, then that plugin should be used. If these conditions cannot be met, or if the plugin reports an error, jump to the next step (fallback).

6. (Fallback.) The object element represents the element's children, ignoring any leading param element children. This is the element's fallback content. If the element has an instantiated plugin, then unload it.

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.

Plugins are considered sandboxed for the purpose of an object element if the sandboxed plugins browsing context flag is set on the object element's Document's active sandboxing flag set.

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.

Whenever the name attribute is set, if the object element has a nested browsing context, its name must be changed to the new value. If the attribute is removed, if the object element has a browsing context, the browsing context name must be set to the empty string.

Constraint validation: object elements are always barred from constraint validation.

The IDL attributes data, type and name each must reflect the respective content attributes of the same name. The typeMustMatch IDL attribute must reflect the typemustmatch content attribute. The useMap IDL attribute must reflect the usemap content attribute.

The contentDocument IDL attribute must return the Document object of the active document of the object element's nested browsing context, if it has one; otherwise, it must return null.

The contentWindow IDL attribute must return the WindowProxy object of the object element's nested browsing context, if it has one; otherwise, it must return null.

The willValidate, validity, and validationMessage attributes, and the checkValidity() and setCustomValidity() methods, are part of the constraint validation API. The form IDL attribute is part of the element's forms API.

All object elements have a legacy caller operation. If the object element has an instantiated plugin that supports a scriptable interface that defines a legacy caller operation, then that must be the behavior of the object's legacy caller operation. Otherwise, the object's legacy caller operation must be to throw a NotSupportedError exception.

<figure>
 <object type="application/x-java-applet">
  <param name="code" value="MyJavaClass">
  <p>You do not have Java available, or it is disabled.</p>
 </object>
 <figcaption>My Java Clock</figcaption>
</figure>

<figure>
 <object data="clock.html"></object>
 <figcaption>My HTML Clock</figcaption>
</figure>

<p>Look at my video:
 <object type="application/x-shockwave-flash">
  <param name=movie value="http://video.example.com/library/watch.swf">
  <param name=allowfullscreen value=true>
  <param name=flashvars value="http://video.example.com/vids/315981">
  <video controls src="http://video.example.com/vids/315981">
   <a href="http://video.example.com/vids/315981">View video</a>.
  </video>
 </object>
</p>

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.

<!DOCTYPE HTML>
<html lang="en">
  <head>
   <title>O3D Utah Teapot</title>
  </head>
  <body>
   <p>
    <object type="application/vnd.o3d.auto">
     <param name="o3d_features" value="FloatingPointTextures">
     <img src="o3d-teapot.png"
          title="3D Utah Teapot illustration rendered using O3D."
          alt="When O3D renders the Utah Teapot, it appears as a squat
          teapot with a shiny metallic finish on which the
          surroundings are reflected, with a faint shadow caused by
          the lighting.">
     <p>To see the teapot actually rendered by O3D on your
     computer, please download and install the <a
     href="http://code.google.com/apis/o3d/docs/gettingstarted.html#install">O3D plugin</a>.</p>
    </object>
    <script src="o3d-teapot.js"></script>
   </p>
  </body>
</html>