This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21196 - [mispaste]
Summary: [mispaste]
Status: RESOLVED INVALID
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-05 08:59 UTC by contributor
Modified: 2014-02-26 22:15 UTC (History)
2 users (show)

See Also:


Attachments

Description contributor 2013-03-05 08:59:23 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html
Multipage: http://www.whatwg.org/C#attr-iframe-srcdoc
Complete: http://www.whatwg.org/c#attr-iframe-srcdoc

Comment:
 HTML Living Standard — Last Updated 5 March 2013  Section Bugs: 21030,
20871, 20998, 20870, 20803, 20999 ← 4.8 Embedded content – Table of
contents – 4.8.6 The video element → 4.8.2 The iframe element 4.8.3 The
embed element 4.8.4 The object element 4.8.5 The param element 4.8.2 The
iframe element	Ready for first implementations Latest Internet Explorer beta:
incomplete supportLatest Firefox trunk nightly build: incomplete supportLatest
WebKit or Chromium trunk build: incomplete supportLatest Opera beta or preview
build: incomplete supportJavaScript libraries, plugins, etc: unknown
Categories: Flow content. Phrasing content. Embedded content. Interactive
content. Palpable content. Contexts in which this element can be used: Where
embedded content is expected. Content model: Text that conforms to the
requirements given in the prose. Content attributes: Global attributes src
srcdoc name sandbox seamless allowfullscreen width height DOM interface:
interface HTMLIFrameElement : HTMLElement {	       attribute DOMString
src;		attribute DOMString srcdoc;	       attribute DOMString
name;	[PutForwards=value] readonly attribute DOMSettableTokenList sandbox;  
	 attribute boolean seamless;		attribute boolean
allowFullscreen;	    attribute DOMString width;		  attribute
DOMString height;   readonly attribute Document? contentDocument;   readonly
attribute WindowProxy? contentWindow;	 // also has obsolete members }; The
iframe element represents a nested browsing context.  The src attribute gives
the address of a page that the nested browsing context is to contain. The
attribute, if present, must be a valid non-empty URL potentially surrounded by
spaces. If the itemprop is specified on an iframe element, then the src
attribute must also be specified.  The srcdoc Ready for first implementations 
attribute gives the content of the page that the nested browsing context is to
contain. The value of the attribute is the source of an iframe srcdoc
document.  For iframe elements in HTML documents, the srcdoc attribute, if
present, must have a value using the HTML syntax that consists of the
following syntactic components, in the given order:  Any number of comments
and space characters. Optionally, a DOCTYPE. Any number of comments and space
characters. The root element, in the form of an html element. Any number of
comments and space characters. 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 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 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 U+0009 CHARACTER TABULATION
(tab), U+000A LINE FEED (LF), and U+000D CARRIAGE RETURN (CR) — 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.  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 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.  If there exists an ancestor browsing context
whose active document's address, ignoring fragment identifiers, is equal to
url, then abort these steps.  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:	Let child document be
the active document of the iframe element's nested browsing context.  If child
document has its mute iframe load flag set, abort these steps.	Set child
document's iframe load in progress flag.  Fire a simple event named load at
the iframe element.  Unset child document's iframe load in progress flag. 
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.  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.
 If the user navigates away from this page, the iframe's corresponding
WindowProxy object will proxy new Window objects for new Document objects, but
the src attribute will not change.  The name attribute, if present, must be a
valid browsing context name. The given value is used to name the nested
browsing context. When the browsing context is created, if the 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. 
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.  The sandbox attribute, when specified,
enables a set of extra restrictions on any content hosted by the iframe. Its
value must be an unordered set of unique space-separated tokens that are ASCII
case-insensitive. The allowed values are allow-forms, allow-pointer-lock,
allow-popups, allow-same-origin, allow-scripts, and allow-top-navigation. 
When the attribute is set, the content is treated as being from a unique
origin, forms, scripts, and various potentially annoying APIs are disabled,
links are prevented from targeting other browsing contexts, and plugins are
secured. The allow-same-origin keyword causes the content to be treated as
being from its real origin instead of forcing it into a unique origin; the
allow-top-navigation keyword allows the content to navigate its top-level
browsing context; and the allow-forms, allow-pointer-lock, allow-popups and
allow-scripts keywords re-enable forms, the pointer lock API, popups, and
scripts respectively. [POINTERLOCK]  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.  These flags only take effect when the nested browsing
context of the iframe is navigated. Removing them, or removing the entire
sandbox attribute, has no effect on an already-loaded page.  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.  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. 
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).  <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> 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.  <iframe
sandbox="allow-same-origin allow-forms allow-scripts"	     
src="http://maps.example.com/embedded.html"></iframe> Suppose a file A
contained the following fragment:  <iframe sandbox="allow-same-origin
allow-forms" src=B></iframe> Suppose that file B contained an iframe also: 
<iframe sandbox="allow-scripts" src=C></iframe> Further, suppose that file C
contained a link:  <a href=D>Link</a> For this example, suppose all the files
were served as text/html.  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 HTML inclusion is effected using this attribute as in the
following example. In this case, the inclusion is of a site-wide navigation
bar.  <!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.  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.  <nav><iframe seamless src="nav.include.html"></iframe></nav> The
contenteditable attribute does not propagate into seamless iframes.  The
allowfullscreen attribute is a boolean attribute. When specified, it indicates
that Document objects in the iframe element's browsing context are to be
allowed to use requestFullScreen() (if it's not blocked for other reasons,
e.g. there is another ancestor iframe without this attribute set).  The iframe
element supports dimension attributes for cases where the embedded content has
specific dimensions (e.g. ad units have well-defined dimensions).  An iframe
element never has fallback content, as it will always create a nested browsing
context, regardless of whether the specified initial contents are successfully
used.  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.	The iframe element must be empty in XML documents. 
The HTML parser treats markup inside iframe elements as text.  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. 
Here is an example of a page using an iframe to include advertising from an
advertising broker:  <iframe
src="http://ads.example.com/?customerid=923513721&amp;format=banner"	    
width="468" height="60"></iframe> 4.8.3 The embed element  Ready for first
implementations Bugs: 16136 Latest Internet Explorer beta: buggy supportLatest
Firefox trunk nightly build: buggy supportLatest WebKit or Chromium trunk
build: buggy supportLatest Opera beta or preview build: buggy
supportJavaScript libraries, plugins, etc: unknown Categories: Flow content.
Phrasing content. Embedded content. Interactive content. Palpable content.
Contexts in which this element can be used: Where embedded content is
expected. Content model: Empty. Content attributes: Global attributes src type
width height Any other attribute that has no namespace (see prose). DOM
interface: interface HTMLEmbedElement : HTMLElement {		 attribute
DOMString src;		  attribute DOMString type;	       attribute
DOMString width;	    attribute DOMString height;   legacycaller any
(any... arguments);    // also has obsolete members }; Depending on the type
of content instantiated by the embed element, the node may also support other
interfaces.  The embed element represents an integration point for an external
(typically non-HTML) application or interactive content.  The src attribute
gives the address of the resource being embedded. The attribute, if present,
must contain a valid non-empty URL potentially surrounded by spaces.  If the
itemprop is specified on an embed element, then the src attribute must also be
specified.  The type attribute, if present, gives the MIME type by which the
plugin to instantiate is selected. The value must be a valid MIME type. If
both the type attribute and the src attribute are present, then the type
attribute must specify the same type as the explicit Content-Type metadata of
the resource given by the src attribute.  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:  If another task has since been
queued to run these steps for this element, then abort these steps.  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:  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. 
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".  Otherwise, if the specified resource has explicit Content-Type
metadata, then that is the content's type.  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).	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 uppercase ASCII letters. 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. 
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 embed element supports dimension
attributes.  The IDL attributes src and type each must reflect the respective
content attributes of the same name.  Here's a way to embed a resource that
requires a proprietary plugin, like Flash:  <embed src="catgame.swf"> If the
user does not have the plugin (for example if the plugin vendor doesn't
support the user's platform), then the user will be unable to use the
resource.  To pass the plugin a parameter "quality" with the value "high", an
attribute can be specified:  <embed src="catgame.swf" quality="high"> This
would be equivalent to the following, when using an object element instead: 
<object data="catgame.swf">  <param name="quality" value="high"> </object>
4.8.4 The object element  Ready for first implementations Latest Internet
Explorer beta: incomplete supportLatest Firefox trunk nightly build:
incomplete supportLatest WebKit or Chromium trunk build: incomplete
supportLatest Opera beta or preview build: incomplete supportJavaScript
libraries, plugins, etc: unknown Categories: Flow content. Phrasing content.
Embedded content. If the element has a usemap attribute: Interactive content.
Listed, submittable, form-associated element. Palpable content. Contexts in
which this element can be used: Where embedded content is expected. Content
model: Zero or more param elements, then, transparent. Content attributes:
Global attributes data type typemustmatch name usemap form width height DOM
interface: interface HTMLObjectElement : HTMLElement {		  attribute
DOMString data; 	   attribute DOMString type;		attribute
boolean typeMustMatch;		  attribute DOMString name;	      
attribute DOMString useMap;   readonly attribute HTMLFormElement? form;       
    attribute DOMString width;		  attribute DOMString height;  
readonly attribute Document? contentDocument;	readonly attribute
WindowProxy? contentWindow;    readonly attribute boolean willValidate;  
readonly attribute ValidityState validity;   readonly attribute DOMString
validationMessage;   boolean checkValidity();	void
setCustomValidity(DOMString error);    legacycaller any (any... arguments);   
// also has obsolete members }; 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.  The data
attribute, if present, specifies the address of the resource. If present, the
attribute must be a valid non-empty URL potentially surrounded by spaces. 
Authors who reference resources from other origins that they do not trust are
urged to use the typemustmatch attribute defined below. Without that
attribute, it is possible in certain cases for an attacker on the remote host
to use the plugin mechanism to run arbitrary scripts, even if the author has
used features such as the Flash "allowScriptAccess" parameter.	The type
attribute, if present, specifies the type of the resource. If present, the
attribute must be a valid MIME type.  At least one of either the data
attribute or the type attribute must be present.  If the itemprop is specified
on an object element, then the data attribute must also be specified.  The
typemustmatch attribute is a boolean attribute whose presence indicates that
the resource specified by the data attribute is only to be used if the value
of the type attribute and the Content-Type of the aforementioned resource
match.	The typemustmatch attribute must not be specified unless both the data
attribute and the type attribute are present.  The name attribute, if present,
must be a valid browsing context name. The given value is used to name the
nested browsing context, if applicable.  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. 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.  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).  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).  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).  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).  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). 
Determine the resource type, as follows:  Let the resource type be unknown. 
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.  If the object element has a
typemustmatch attribute, jump to the step below labeled handler.  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. 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. 
Run the approprate set of steps from the following list:  The resource has
associated Content-Type metadata Let binary be false.  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.  If
the type specified in the resource's Content-Type metadata is
"application/octet-stream", then set binary to true.  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.  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.  Jump to the step
below labeled handler.	The resource does not have associated Content-Type
metadata 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.  If tentative type is
not application/octet-stream, then let resource type be tentative type and
jump to the step below labeled handler.  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. 
Ready for first implementations Latest Internet Explorer beta: unknownLatest
Firefox trunk nightly build: buggy supportLatest WebKit or Chromium trunk
build: unknownLatest Opera beta or preview build: unknownJavaScript libraries,
plugins, etc: unknown 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.  The element's contents are not part of what the object
element represents.  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.  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).  (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.  Ready for
first implementations 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.  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.  The form attribute
is used to explicitly associate the object element with its form owner. 
Constraint validation: object elements are always barred from constraint
validation.  The object element supports dimension attributes.	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
Section Latest Internet Explorer beta: unknownLatest Firefox trunk nightly
build: unknownLatest WebKit or Chromium trunk build: unknownLatest Opera beta
or preview build: excellent supportJavaScript libraries, plugins, etc: unknown
 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.  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.)	<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> In
this example, an HTML page is embedded in another using the object element. 
<figure>  <object data="clock.html"></object>  <figcaption>My HTML
Clock</figcaption> </figure> 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.  <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> 4.8.5 The param element	Implemented and widely deployed Latest
Internet Explorer beta: excellent supportLatest Firefox trunk nightly build:
excellent supportLatest WebKit or Chromium trunk build: excellent
supportLatest Opera beta or preview build: excellent supportJavaScript
libraries, plugins, etc: unknown Categories: None. Contexts in which this
element can be used: As a child of an object element, before any flow content.
Content model: Empty. Content attributes: Global attributes name value DOM
interface: interface HTMLParamElement : HTMLElement {		 attribute
DOMString name; 	   attribute DOMString value;	 // also has obsolete
members }; 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.  <!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>	Watch for updates  Specification annotation system:   
  Section "attr-iframe-srcdoc" selected. Comment:    Ready for first
implementations 

Posted from: 76.120.19.117
User agent: Mozilla/5.0 (iPad; CPU OS 6_1_2 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B146 Safari/8536.25