figure elementlegend
element, and exactly one embedded content
element.
HTMLElement.
The figure element represents a paragraph consisting of embedded content and a
caption.
The first embedded content element child of the
figure element, if any, is the
paragraph's content.
The first legend element child of the
element, if any, represents the caption of the embedded content. If there
is no child legend element, then there
is no caption.
If the embedded content cannot be used, then, for the purposes of
establishing what the figure element
represents:
figure element must be treated
as if that embedded content element was the
figure element's embedded content. (If
that embedded content can't be used either, then this processing must be
done again, with the new embedded content's fallback
content.)
figure element
(including the caption, if any) must be ignored.
figure element
(including the caption, if any) must be treated as being a single paragraph with that inline-level content as its content.
figure element
(including the caption, if any) must be treated as being replaced by that
fallback content.
img elementStrictly inline-level embedded content.
figure element.
alt
src (required)
usemap
ismap (but only
if one of the ancestor elements is an a
element)
width
height
interface HTMLImageElement : HTMLElement {
attribute DOMString alt;
attribute DOMString src;
attribute DOMString useMap;
attribute boolean isMap;
attribute long width;
attribute long height;
readonly attribute boolean complete;
};
An instance of HTMLImageElement can be obtained
using the Image
constructor.
An img element represents an image.
The image given by the src attribute is the embedded
content, and the value of the alt attribute is the img element's fallback
content.
Authoring requirements: The src attribute must be present, and must contain a
URI (or IRI).
Should we restrict the URI to pointing to an image? What's an image? Is PDF an image? (Safari supports PDFs in <img> elements.) How about SVG? (Opera supports those). WMFs? XPMs? HTML?
The requirements for the alt attribute depend on what the image is intended
to represent:
Sometimes something can be more clearly stated in graphical form, for
example as a flowchart, a diagram, a graph, or a simple map showing
directions. In such cases, an image can be given using the img element, but the lesser textual version must
still be given, so that users who are unable to view the image (e.g.
because they have a very slow connection, or because they are using a
text-only browser, or because they are listening to the page being read
out by a hands-free automobile voice Web browser, or simply because they
are blind) are still able to understand the message being conveyed.
The text must be given in the alt attribute, and must convey the same message
as the the image specified in the src attribute.
In the following example we have a flowchart in image form,
with text in the alt
attribute rephrasing the flowchart in prose form:
<p>In the common case, the data handled by the tokenisation stage comes from the network, but it can also come from script.</p> <p><img src="images/parsing-model-overview.png" alt="The network passes data to the Tokeniser stage, which passes data to the Tree Construction stage. From there, data goes to both the DOM and to Script Execution. Script Execution is linked to the DOM, and, using document.write(), passes data to the Tokeniser."></p>
Here's another example, showing a good solution and a bad solution to the problem of including an image in a description.
First, here's the good solution. This sample shows how the alternative text should just be what you would have put in the prose if the image had never existed.
<!-- This is the correct way to do things. --> <p> You are standing in an open field west of a house. <img src="house.jpeg" alt="The house is white, with a boarded front door."> There is a small mailbox here. </p>
Second, here's the bad solution. In this incorrect way of doing things, the alternative text is simply a description of the image, instead of a textual replacement for the image. It's bad because when the image isn't shown, the text doesn't flow as well as in the first example.
<!-- This is the wrong way to do things. --> <p> You are standing in an open field west of a house. <img src="house.jpeg" alt="A white house, with a boarded front door."> There is a small mailbox here. </p>
It is important to realise that the alternative text is a replacement for the image, not a description of the image.
A document can contain information in iconic form. The icon is intended to help users of visual browsers to recognise features at a glance.
In some cases, the icon is supplemental to a text label conveying the
same meaning. In those cases, the alt attribute must be present but must be empty.
Here the icons are next to text that conveys the same meaning, so
they have an empty alt attribute:
<nav> <p><a href="/help/"><img src="/icons/help.png" alt=""> Help</a></p> <p><a href="/configure/"><img src="/icons/configuration.png" alt=""> Configuration Tools</a></p> </nav>
In other cases, the icon has no text next to it describing what it
means; the icon is supposed to be self-explanatory. In those cases, an
equivalent textual label must be given in the alt attribute.
Here, posts on a news site are labelled with an icon indicating their topic.
<body> <article> <header> <h1>Ratatouille wins <i>Best Movie of the Year</i> award</h1> <p><img src="movies.png" alt="Movies"></p> </header> <p>Pixar has won yet another <i>Best Movie of the Year</i> award, making this its 8th win in the last 12 years.</p> </article> <article> <header> <h1>Latest TWiT episode is online</h1> <p><img src="podcasts.png" alt="Podcasts"></p> </header> <p>The latest TWiT episode has been posted, in which we hear several tech news stories as well as learning much more about the iPhone. This week, the panelists compare how reflective their iPhones' Apple logos are.</p> </article> </body>
Many pages include logos, insignia, flags, or emblems, which stand for a particular entity such as a company, organisation, project, band, software package, country, or some such.
If the logo is being used to represent the entity, the alt attribute must contain
the name of the entity being represented by the logo. The alt attribute must
not contain text like the word "logo", as it is not the fact
that it is a logo that is being conveyed, it's the entity itself.
If the logo is being used next to the name of the entity that it
represents, then the logo is supplemental, and its alt attribute must instead
be empty.
If the logo is merely used as decorative material (as branding, or, for example, as a side image in an article that mentions the entity to which the logo belongs), then the entry below on purely decorative images applies. If the logo is actually being discussed, then it is being used as a phrase or paragraph (the description of the logo) with an alternative graphical representation (the logo itself), and the first entry above applies.
In the following snippets, all four of the above cases are present. First, we see a logo used to represent a company:
<h1><img src="XYZ.gif" alt="The XYZ company"></h1>
Next, we see a paragraph which uses a logo right next to the company name, and so doesn't have any alternative text:
<article> <h2>News</h2> <p>We have recently been looking at buying the <img src="alpha.gif" alt=""> ΑΒΓ company, a small Greek company specialising in our type of product.</p>
In this third snippet, we have a logo being used in an aside, as part of the larger article discussing the acquisition:
<aside><p><img src="alpha-large.gif" alt=""></p></aside> <p>The ΑΒΓ company has had a good quarter, and our pie chart studies of their accounts suggest a much bigger blue slice than its green and orange slices, which is always a good sign.</p> </article>
Finally, we have an opinion piece talking about a logo, and the logo is therefore described in detail in the alternative text.
<p>Consider for a moment their logo:</p> <p><img src="/images/logo" alt="It consists of a green circle with a green question mark centered inside it."></p> <p>How unoriginal can you get? I mean, oooooh, a question mark, how <em>revolutionary</em>, how utterly <em>ground-breaking</em>, I'm sure everyone will rush to adopt those specifications now! They could at least have tried for some sort of, I don't know, sequence of rounded squares with varying shades of green and bold white outlines, at least that would look good on the cover of a blue book.</p>
This example shows how the alternative text should be written such that if the image isn't available, and the text is used instead, the text flows seamlessly into the surrounding text, as if the image had never been there in the first place.
In many cases, the image is actually just supplementary, and its
presence merely reinforces the surrounding text. In these cases, the
alt attribute must be
present but its value must be the empty string.
A flowchart that repeats the previous paragraph in graphical form:
<p>The network passes data to the Tokeniser stage, which passes data to the Tree Construction stage. From there, data goes to both the DOM and to Script Execution. Script Execution is linked to the DOM, and, using document.write(), passes data to the Tokeniser.</p> <p><img src="images/parsing-model-overview.png" alt=""></p>
A graph that repeats the previous paragraph in graphical form:
<p>According to a study covering several billion pages, about 62% of documents on the Web in 2007 triggered the Quirks rendering mode of Web browsers, about 30% triggered the Almost Standards mode, and about 9% triggered the Standards mode.</p> <p><img src="rendering-mode-pie-chart.png" alt=""></p>
In general, an image falls into this category if removing the image doesn't make the page any less useful, but including the image makes it a lot easier for users of visual browsers to understand the concept.
In some cases, the image isn't discussed by the surrounding text, but
it has some relevance. Such images are decorative, but still form part
of the content. In these cases, the alt attribute must be present but its value must
be the empty string.
Examples where the image is purely decorative despite being relevant would include things like a photo of the Black Rock City landscape in a blog post about an event at Burning Man, or an image of a painting inspired by a poem, on a page reciting that poem. The following snippet shows an example of the latter case (only the first verse is included in this snippet):
<h1>The Lady of Shalott</h1> <p><img src="shalott.jpeg" alt=""></p> <p>On either side the river lie<br> Long fields of barley and of rye,<br> That clothe the wold and meet the sky;<br> And through the field the road run by<br> To many-tower'd Camelot;<br> And up and down the people go,<br> Gazing where the lilies blow<br> Round an island there below,<br> The island of Shalott.</p>
In general, if an image is decorative but isn't especially page-specific, for example an image that forms part of a site-wide design scheme, the image should be specified in the site's CSS, not in the markup of the document.
In certain rare cases, the image is simply a critical part of the content, and there might even be no alternative text available. This could be the case, for instance, in a photo gallery, where a user has uploaded 3000 photos from a vacation trip, without providing any descriptions of the images. The images are the whole point of the pages containing them.
In such cases, the alt attribute may be omitted, but the alt attribute should be
included, with a useful value, if at all possible. If an image is a key
part of the content, the alt attribute must not be specified with an empty
value.
A photo on a photo-sharing site:
<figure> <img src="1100670787_6a7c664aef.jpg"> <legend>Bubbles traveled everywhere with us.</legend> </figure>
A screenshot in a gallery of screenshots for a new OS:
<figure> <img src="KDE%20Light%20desktop.png"> <legend>Screenshot of a KDE desktop.</legend> </figure>
In both cases, though, it would be better if a detailed description of the important parts of the image were included.
Sometimes there simply is no text that can do justice to an image. For example, there is little that can be said to usefully describe a Rorschach inkblot test.
<figure> <img src="/commons/a/a7/Rorschach1.jpg"> <legend>A black outline of the first of the ten cards in the Rorschach inkblot test.</legend> </figure>
Note that the following would be a very bad use of alternative text:
<!-- This example is wrong. Do not copy it. --> <figure> <img src="/commons/a/a7/Rorschach1.jpg" alt="A black outline of the first of the ten cards in the Rorschach inkblot test."> <legend>A black outline of the first of the ten cards in the Rorschach inkblot test.</legend> </figure>
Including the caption in the alternative text like this isn't useful because it effectively duplicates the caption for users who don't have images, taunting them twice yet not helping them any more than if they had only read or heard the caption once.
Since some users cannot use images at all (e.g. because they have a
very slow connection, or because they are using a text-only browser, or
because they are listening to the page being read out by a hands-free
automobile voice Web browser, or simply because they are blind), the
alt attribute should
only be omitted when no alternative text is available and none can be
made available, e.g. on automated image gallery sites.
When an image is included in a communication (such as an HTML e-mail)
aimed at someone who is known to be able to view images, the alt attribute may be
omitted. However, even in such cases it is stongly recommended that
alternative text be included (as appropriate according to the kind of
image involved, as described in the above entries), so that the e-mail
is still usable should the user use a mail client that does not support
images, or should the e-mail be forwarded on to other users whose
abilities might not include easily seeing images.
The img must not be used as a layout
tool. In particular, img elements should
not be used to display fully transparent images, as they rarely convey
meaning and rarely add anything useful to the document.
There has been some suggestion that the longdesc attribute from HTML4, or some other mechanism
that is more powerful than alt="", should be
included. This has not yet been considered.
User agent requirements: When the alt attribute is present and
its value is the empty string, the image supplements the surrounding
content. In such cases, the image may be omitted without affecting the
meaning of the document.
When the alt
attribute is present and its value is not the empty string, the image is a
graphical equivalent of the string given in the alt attribute. In such cases,
the image may be replaced in the rendering by the string given in the
attribute without significantly affecting the meaning of the document.
When the alt
attribute is missing, the image represents a key part of the content.
Non-visual user agents should apply image analysis heuristics to help the
user make sense of the image.
The alt attribute
does not represent advisory information. User agents must not present the
contents of the alt
attribute in the same way as content of the title attribute.
If the src attribute
is omitted, the image represents whatever string is given by the element's
alt attribute, if any,
or nothing, if that attribute is empty or absent.
When the src
attribute is set, the user agent must immediately begin to download the
specified
resource,
unless the user agent cannot support images, or its support for images has
been disabled.
The download of the image must delay the load event.
This, unfortunately, can be used to perform a rudimentary port scan of the user's local network (especially in conjunction with scripting, though scripting isn't actually necessary to carry out such an attack). User agents may implement cross-origin access control policies that mitigate this attack.
Once the download has completed, if the image is a valid image, the user
agent must fire a load
event on the img element. If the
download fails or it completes but the image is not a valid or supported
image, the user agent must fire an error event on the img element.
The remote server's response metadata (e.g. an HTTP 404 status code, or associated Content-Type headers) must be ignored when determining whether the resource obtained is a valid image or not.
This allows servers to return images with error responses.
User agents must not support non-image resources with the img element.
The usemap attribute, if present, can indicate that
the image has an associated image map.
The ismap
attribute, when used on an element that is a descendant of an a element with an href attribute, indicates by its presence that
the element provides access to a server-side image map. This affects how
events are handled on the corresponding a
element.
The ismap
attribute is a boolean attribute. The attribute
must not be specified on an element that does not have an ancestor
a element.
The img element supports dimension attributes.
The img element must be empty.
The DOM attributes alt, src, useMap, and isMap each must reflect the respective content attributes of the same
name.
The DOM attributes height and width must return the rendered
height and width of the image, in CSS pixels, if the image is being
rendered, and is being rendered to a visual medium, or 0 otherwise. [CSS21]
The DOM attribute complete must return true if the
user agent has downloaded the image specified in the src attribute, and it is a
valid image, and false otherwise.
iframe elementStrictly inline-level embedded content.
figure element.
src
interface HTMLIFrameElement : HTMLElement {
attribute DOMString src;
};
Objects implementing the HTMLIFrameElement interface must
also implement the EmbeddingElement interface defined in
the Window Object specification. [WINDOW]
The iframe element introduces a new
nested browsing context.
The src attribute,
if present, must be a URI (or IRI) to a page that the nested browsing context is to contain. When the browsing
context is created, if the attribute is present, the user agent must navigate this browsing context to the given URI, with
replacement enabled. If the user navigates away from this page, the
iframe's corresponding Window object will reference new
Document objects, but the src attribute will not change.
Whenever the src
attribute is set, the nested browsing context
must be navigated to the given URI.
If the src
attribute is not set when the element is created, the browsing context
will remain at the initial about:blank page.
When content loads in an iframe,
after any load events
are fired within the content itself, the user agent must fire a load event at the
iframe element. When content fails to
load (e.g. due to a network error), then the user agent must fire an error event at
the element instead.
When there is an active parser in the iframe, and when anything in the iframe that is delaying the load event
in the iframe's browsing context, the iframe must delay the load event.
If, during the handling of the load event, the browsing
context in the iframe is again navigated, that will further delay the load event.
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.
iframe elements may contain any text.
iframe elements must not contain
element nodes. 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.)
restrictions for what that text must be?
The HTML parser treats markup inside
iframe elements as text.
The DOM attribute src must reflect the content attribute of the same name.
embed elementStrictly inline-level embedded content.
figure element.
src (required)
type
width
height
interface HTMLEmbedElement : HTMLElement {
attribute DOMString src;
attribute DOMString type;
attribute long width;
attribute long height;
};
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 must be
present and contain a URI (or IRI).
If the src
attribute is missing, then the embed
element must be ignored.
When the src
attribute is set, user agents are expected to find an appropriate handler
for the specified resource, based on the content's type, and hand that handler the
content of the resource. If the handler supports a scriptable interface,
the HTMLEmbedElement object
representing the element should expose that interfaces.
The download of the resource must delay the load event.
The user agent should pass the names and values of all the attributes of
the embed element that have no namespace
to the handler used. Any (namespace-less) attribute may be specified on
the embed element.
This specification does not define a mechanism for interacting with third-party handlers, as it is expected to be user-agent-specific. Some UAs might opt to support a plugin mechanism such as the Netscape Plugin API; others may use remote content convertors or have built-in support for certain types. [NPAPI]
The embed element has no fallback content. If the user agent can't display the
specified resource, e.g. because the given type is not supported, then the
user agent must use a default handler for the content. (This default could
be as simple as saying "Unsupported Format", of course.)
The type
attribute, if present, gives the MIME type of the linked resource. The
value must be a valid MIME type, optionally with parameters. [RFC2046]
The type of the content being embedded is defined as follows:
type attribute, then the value of the type attribute is the
content's type.
Should we instead say that the content-sniffing that we're going to define for top-level browsing contexts should apply here?
Should we require the type attribute to match the server information?
We should say that 404s, etc, don't affect whether the resource is used or not. Not sure how to say it here though.
Browsers should take extreme care when interacting with external content intended for third-party renderers. When third-party software is run with the same privileges as the user agent itself, vulnerabilities in the third-party software become as dangerous as those in the user agent.
The embed element supports dimension attributes.
The DOM attributes src and type each must reflect the respective content attributes of the same
name.
object elementStrictly inline-level embedded content.
figure element.
figure
element, or, when used as a figure
fallback object: Zero or more
param elements, followed by either zero
or more block-level elements or a single
object element, which is then
considered to be a figure fallback
object.
param
elements, followed by inline-level content.
data (required
if type is not
given)
type
(required if data
is not given)
usemap
width
height
interface HTMLObjectElement : HTMLElement {
attribute DOMString data;
attribute DOMString type;
attribute DOMString useMap;
attribute long width;
attribute long height;
};
Objects implementing the HTMLObjectElement interface must
also implement the EmbeddingElement interface defined in
the Window Object specification. [WINDOW]
Depending on the type of content instantiated by the object element, the node may also support
other interfaces.
Shouldn't allow inline-level content to be the content model when the parent's content model is strictly inline only.
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 third-party
software package.
The data
attribute, if present, specifies the address of the resource. If present,
the attribute must be a URI (or IRI).
The type
attribute, if present, specifies the type of the resource. If present, the
attribute must be a valid MIME type, optionally with parameters. [RFC2046]
One or both of the data and type attributes must be present.
Whenever the data attribute changes, or, if the data attribute is not
present, whenever the type attribute changes, the user agent must run
the following steps to determine what the object element represents:
If the data
attribute is present, then:
Begin a load for the resource.
The download of the resource must delay the load event.
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 step 3 in the overall set of steps (fallback). When the resource becomes available, or if the load fails, 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. DNS error), fire an
error event at the element, then
jump to step 3 in the overall set of steps (fallback).
Determine the resource type, as follows:
This says to trust the type. Should we instead use the same mechanism as for browsing contexts?
type attribute is present
type attribute.
Handle the content as given by the first of the following cases that matches:
The user agent should find an appropriate handler for the
specified resource, based on the resource type found in the
previous step, and pass the content of the resource to that handler.
If the handler supports a scriptable interface, the HTMLObjectElement object
representing the element should expose that interface. The handler
is not a nested browsing context. If no
appropriate handler can be found, then jump to step 3 in the overall
set of steps (fallback).
The user agent should pass the names and values of all the parameters given by param elements that are children of the
object element to the handler
used.
This specification does not define a mechanism for interacting with third-party handlers, as it is expected to be user-agent-specific. Some UAs might opt to support a plugin mechanism such as the Netscape Plugin API; others may use remote content convertors or have built-in support for certain types. [NPAPI]
this doesn't completely duplicate the navigation section, since it handles <param>, etc, but surely some work should be done to work with it
image/"
The object element must be
associated with a nested browsing context,
if it does not already have one. The element's nested browsing context must then be navigated to the given resource,
with replacement enabled. (The data attribute of
the object element doesn't get
updated if the browsing context gets further navigated to other
locations.)
navigation might end up treating it as something else, because it can do sniffing. how should we handle that?
The object element represents
the specified image. The image is not a nested browsing context.
shouldn't we use the image-sniffing stuff here?
The object element represents
the specified image, but the image cannot be shown. Jump to step 3
below in the overall set of steps (fallback).
The element's contents are not part of what the object element represents.
Once the resource is completely loaded, fire a
load event at the element.
If the data
attribute is absent but the type attribute is present, and if the user
agent can find a handler suitable according to the value of the type attribute, then
that handler should be used. If the handler supports a scriptable
interface, the HTMLObjectElement object
representing the element should expose that interface. The handler is
not a nested browsing context. If no suitable
handler can be found, jump to the next step (fallback).
(Fallback.) The object element
doesn't represent anything except what the element's contents represent,
ignoring any leading param element
children. This is the element's fallback
content.
In the absence of other factors (such as style sheets), user agents must
show the user what the object element
represents. Thus, the contents of object elements act as fallback content, to be 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 best 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.
The object element supports dimension attributes.
The DOM attributes data, type, and useMap each must reflect the respective content attributes of the same
name.
param elementobject element,
before any content other than param
elements.
name
(required)
value
(required)
interface HTMLParamElement : HTMLElement {
attribute DOMString name;
attribute DOMString value;
};
The param element defines parameters
for handlers invoked by object
elements.
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.
The DOM attributes name and value must both reflect the respective content attributes of the same
name.