This is a work in
progress! For the latest updates from the HTML WG, possibly
including important bug fixes, please look at the editor's draft instead.
There may also be a more
up-to-date Working Draft
with changes based on resolution of Last Call issues.

10 Rendering

User agents are not required to present HTML documents in any
particular way. However, this section provides a set of suggestions
for rendering HTML documents that, if followed, are likely to lead
to a user experience that closely resembles the experience intended
by the documents' authors. So as to avoid confusion regarding the
normativity of this section, RFC2119 terms have not been used.
Instead, the term "expected" is used to indicate behavior that will
lead to this experience. For the purposes of conformance for user
agents designated as supporting the suggested
default rendering, the term "expected" in this section has the
same conformance implications as the RFC2119-defined term
"must".

10.1 Introduction

In general, user agents are expected to support CSS, and many of
the suggestions in this section are expressed in CSS terms. User
agents that use other presentation mechanisms can derive their
expected behavior by translating from the CSS rules given in this
section.

In the absence of style-layer rules to the contrary (e.g. author
style sheets), user agents are expected to render an element so that
it conveys to the user the meaning that the element
represents, as described by this specification.

The suggestions in this section generally assume a visual output
medium with a resolution of 96dpi or greater, but HTML is intended
to apply to multiple media (it is a media-independent
language). User agent implementors are encouraged to adapt the
suggestions in this section to their target media.

An element is being rendered if it is in a
Document, either its parent node is itself
being rendered or it is the Document node,
and it is not explicitly excluded from the rendering using either:

the CSS 'display' property's 'none' value, or

the 'visibility' property's 'collapse' value unless it is being treated as equivalent to the 'hidden' value, or

some equivalent in other styling languages.

Just being off-screen does not mean the element is
not being rendered. The presence of the hidden attribute normally means the
element is not being rendered, though this might be
overridden by the style sheets.

10.2 The CSS user agent style sheet and presentational hints

10.2.1 Introduction

The CSS rules given in these subsections are, except where
otherwise specified, expected to be used as part of the user-agent
level style sheet defaults for all documents that contain HTML
elements.

Some rules are intended for the author-level zero-specificity
presentational hints part of the CSS cascade; these are explicitly
called out as presentational hints.

Some of the rules regarding left and right margins are given here
as appropriate for elements whose 'direction' property is 'ltr', and
are expected to be flipped around on elements whose 'direction'
property is 'rtl'. These are marked "LTR-specific".

Similarly, for the
purpose of the rules marked "case-insensitive", user agents are
expected to use ASCII case-insensitive matching of
attribute values rather than case-sensitive matching, even for
attributes in XHTML documents.

These markings only affect the handling of attribute
values, not attribute names or element names.

When the text below says that an attribute attribute on an element elementmaps to the pixel length property (or properties) properties, it means that if element has an attribute attribute set, and parsing that attribute's value
using the rules for parsing non-negative integers
doesn't generate an error, then the user agent is expected to use
the parsed value as a pixel length for a presentational hint for properties.

When the text below says that an attribute attribute on an element elementmaps to the dimension property (or properties) properties, it means that if element has an attribute attribute set, and parsing that attribute's value
using the rules for parsing dimension values doesn't
generate an error, then the user agent is expected to use the parsed
dimension as the value for a presentational hint for properties, with the value given as a pixel length if
the dimension was an integer, and with the value given as a
percentage if the dimension was a percentage.

For the purposes of the CSS table model, the col
element is expected to be treated as if it was present as many times
as its span attribute specifies.

For the purposes of the CSS table model, the
colgroup element, if it contains no col
element, is expected to be treated as if it had as many such
children as its span
attribute specifies.

For the purposes of the CSS table model, the colspan and rowspan attributes on
td and th elements are expected to provide the
special knowledge regarding cells spanning rows and
columns.

For the purposes of the CSS ruby model, runs of children of
ruby elements that are not rt or
rp elements are expected to be wrapped in anonymous
boxes whose 'display' property has the value 'ruby-base'. [CSSRUBY]

User agents that do not support correct ruby rendering are
expected to render parentheses around the text of rt
elements in the absence of rp elements.

The article, aside, nav,
and section elements are expected to affect the margins
of h1 elements, based on the nesting depth. If x is a selector that matches elements that are either
article, aside, nav, or
section elements, then the following rules capture what
is expected:

For each property in the table below, given a body
element, the first attribute that exists maps to the pixel
length property on the body element. If none of
the attributes for a property are found, or if the value of the
attribute that was found cannot be parsed successfully, then a
default value of 8px is expected to be used for that property
instead.

The above requirements imply that a page can
change the margins of another page (including one from another
origin) using, for example, an
iframe. This is potentially a security risk, as it
might in some cases allow an attack to contrive a situation in which
a page is rendered not as the author intended, possibly for the
purposes of phishing or otherwise misleading the user.

When a user agent is to align descendants of a node,
the user agent is expected to align only those descendants that have
both their 'margin-left' and 'margin-right' properties computing to
a value other than 'auto', that are over-constrained and that have
one of those two margins with a used value forced to a greater
value, and that do not themselves have an applicable align attribute. When multiple elements
are to align a particular
descendant, the most deeply nested such element is expected to
override the others.

User agents are expected to have a rule in their user agent
stylesheet that matches th elements that have a parent
node whose computed value for the 'text-align' property is its
initial value, whose declaration block consists of just a single
declaration that sets the 'text-align' property to the value
'center'.

The initial value for the 'color' property is expected to be
black. The initial value for the 'background-color' property is
expected to be 'transparent'. The canvas' background is expected to
be white.

The article, aside, nav,
and section elements are expected to affect the font
size of h1 elements, based on the nesting depth. If
x is a selector that matches elements that are
either article, aside, nav,
or section elements, then the following rules capture
what is expected:

When a body element has a alink attribute, its value is
expected to be parsed using the rules for parsing a legacy
color value, and if that does not return an error, the user
agent is expected to treat the attribute as a presentational hint setting the
'color' property of any element in the Document
matching the ':active' pseudo-class and either the ':link'
pseudo-class or the ':visited' pseudo-class to the resulting
color.

When a table element has a bordercolor attribute, its
value is expected to be parsed using the rules for parsing a
legacy color value, and if that does not return an error, the
user agent is expected to treat the attribute as a presentational hint setting the
element's 'border-top-color', 'border-right-color',
'border-bottom-color', and 'border-right-color' properties to the
resulting color.

If the character at position is a U+002B
PLUS SIGN character (+), then let mode be
relative-plus, and advance position to
the next character. Otherwise, if the character at position is a U+002D HYPHEN-MINUS character (-),
then let mode be relative-minus, and
advance position to the next
character. Otherwise, let mode be
absolute.

Rules setting the 'quotes' property appropriately for the locales
and languages understood by the user are expected to be present.

User agents are expected to
support the 'clear' property on inline elements (in order to render
br elements with clear attributes) in the manner
described in the non-normative note to this effect in CSS2.1.

If an hr element has either a color attribute or a noshade attribute, and furthermore
also has a size attribute, and
parsing that attribute's value using the rules for parsing
non-negative integers doesn't generate an error, then the
user agent is expected to use the parsed value divided by two as a
pixel length for presentational hints for the properties
'border-top-width', 'border-right-width', 'border-bottom-width', and
'border-left-width' on the element.

Otherwise, if an hr element has neither a color attribute nor a noshade attribute, but does have a
size attribute, and parsing that
attribute's value using the rules for parsing non-negative
integers doesn't generate an error, then: if the parsed value
is one, then the user agent is expected to use the attribute as a
presentational hint
setting the element's 'border-bottom-width' to 0; otherwise, if the
parsed value is greater than one, then the user agent is expected to
use the parsed value minus two as a pixel length for
presentational hints for the 'height' property on the
element.

The child is not out-of-flow (e.g. not absolutely positioned or floated).

The child is generating a box (e.g. it is not 'display:none').

A fieldset element's rendered legend,
if any, is expected to be rendered over the top border edge of the
fieldset element as a 'block' box (overriding any
explicit 'display' value). In the absence of an explicit width, the
box should shrink-wrap. If the legend element in
question has an align
attribute, and its value is an ASCII case-insensitive
match for one of the strings in the first column of the following
table, then the legend is expected to be rendered
horizontally aligned over the border edge in the position given in
the corresponding cell on the same row in the second column. If the
attribute is absent or has a value that doesn't match any of the
cases in the table, then the position is expected to be on the right
if the 'direction' property on this element has a computed value of
'rtl', and on the left otherwise.

Attribute value

Alignment position

left

On the left

right

On the right

center

In the middle

10.3 Replaced elements

10.3.1 Embedded content

The embed, iframe, and
video elements are expected to be treated as replaced
elements.

A canvas element that representsembedded content is expected to be treated as a
replaced element. Other canvas elements are expected to
be treated as ordinary elements in the rendering model.

An applet element that represents a
plugin is expected to be treated as a replaced
element. Other applet elements are expected to be
treated as ordinary elements in the rendering model.

The audio element, when it is exposing a user interface, is
expected to be treated as a replaced element about one line high, as
wide as is necessary to expose the user agent's user interface
features. When an audio element is not exposing a user
interface, the user agent is expected to hide it,
irrespective of CSS rules.

Whether a video element is exposing a user interface is not
expected to affect the size of the rendering; controls are expected
to be overlaid with the page content without causing any layout
changes, and are expected to disappear when the user does not need
them.

When a video element represents a poster frame or
frame of video, the poster frame or frame of video is expected to be
rendered at the largest size that maintains the aspect ratio of that
poster frame or frame of video without being taller or wider than
the video element itself, and is expected to be
centered in the video element.

Any subtitles or captions are expected to be overlayed directly
on top of their video element, as defined by the
relevant rendering rules; for WebVTT, those are the
WebVTT cue text rendering rules defined below.

10.3.2 Timed text tracks

This section is intended to be moved to its own CSS
module once an editor is found to run with it.

10.3.2.1 WebVTT cue text rendering rules

The rules for updating the display of WebVTT text
tracks render the text
tracks of a media element (specifically, a
video element), or of another playback mechanism, by
applying the steps below. All the text
tracks that use these rules for a given media
element, or other playback mechanism, are rendered together,
to avoid overlapping subtitles from multiple tracks.

The output of the steps below is a set of CSS boxes that covers
the rendering area of the media element or other
playback mechanism, which user agents are expected to render in a
manner suiting the user.

The rules are as follows:

If the media element is an audio
element, or is another playback mechanism with no rendering area,
abort these steps. There is nothing to render.

If the text track cue writing direction is
horizontal, then let width
be 'size vw' and height be 'auto'. Otherwise, let width be 'auto' and height be
'size vh'. (These are CSS values used
by the next section to set CSS properties for the rendering; 'vw'
and 'vh' are CSS units.) [CSSVALUES]

Determine the value of x-position or y-position for cue as per the
appropriate rules from the following list:

Let left be 'x-position vw' and top
be 'y-position vh'. (These again are
CSS values used by the next section to set CSS properties for the
rendering; 'vw' and 'vh' are CSS units.) [CSSVALUES]

Apply the terms of the CSS specifications to nodes within the following constraints, thus
obtaining a set of CSS boxes positioned relative to an initial
containing block: [CSS]

The document tree is the tree of WebVTT Node Objects rooted at
nodes.

For the purposes of processing by the CSS specification,
WebVTT Internal Node
Objects are equivalent to elements with the same
contents.

For the purposes of processing by the CSS
specification, WebVTT Text
Objects are equivalent to text nodes.

No style sheets are associated with nodes. (The nodes are subsequently restyled
using style sheets after their boxes are generated, as
described below.)

The children of the nodes must be
wrapped in an anonymous box whose 'display' property has the
value 'inline'. This is the WebVTT cue background
box.

Runs of children of WebVTT
Ruby Objects that are not WebVTT Ruby Text Objects must be wrapped in
anonymous boxes whose 'display' property has the value
'ruby-base'. [CSSRUBY]

Properties on WebVTT Node
Objects have their values set as defined in the next
section. (That section uses some of the variables whose values
were calculated earlier in this algorithm.)

Text runs must be wrapped at the edge of their containing
blocks, regardless of the value of the 'white-space' property,
even if doing so requires splitting a word where there is no
line breaking opportunity.

If step is zero, then jump to the
step labeled done positioning below.

Let line position be the
text track cue line position.

Vertical Growing Left: Add one to
line position then negate it.

Let position be the result of
multiplying step and line
position.

Vertical Growing Left: Decrease position by the width of the bounding box of
the boxes in boxes, then increase position by step.

Horizontal: If line
position is less than zero then increase position by the height of the video's rendering area, and negate step (so its value is now minus the height of
the first line box in boxes).

Vertical: If line
position is less than zero then increase position by the width of the video's rendering area, and negate step.

Horizontal: Move all the boxes in boxes down by the distance given by position.

Vertical: Move all the boxes in boxes right by the distance given by position.

Default: Remember the position of all the boxes in
boxes as their default
position.

Let switched be false.

Step loop: If none of the boxes in boxes would overlap any of the boxes in output, and all the boxes in output are within the video's rendering area, then jump to the step
labeled done positioning below.

Horizontal: If step
is negative and the top of the first line box in boxes is now above the top of the video's rendering area, or if step is positive and the bottom of the first
line box in boxes is now below the
bottom of the video's rendering area,
jump to the step labeled switch direction.

Vertical: If step is
negative and the left edge of the first line box in boxes is now to the left of the left edge of
the video's rendering area, or if step is positive and the right edge of the
first line box in boxes is now to the
right of the right edge of the video's
rendering area, jump to the step labeled switch
direction.

Horizontal: Move all the boxes in boxes down by the distance given by step. (If step is
negative, then this will actually result in an upwards
movement of the boxes in absolute terms.)

Vertical: Move all the boxes in boxes right by the distance given by step. (If step is
negative, then this will actually result in a leftwards
movement of the boxes in absolute terms.)

Jump back to the step labeled step
loop.

Switch direction: Move all the boxes in boxes back to their default
position as determined in the step above labeled
default.

Let x be a percentage given by the
text track cue line position, and let y be a percentage given by the text
track cue text position.

Position the boxes in boxes such
that the point x% along the width of the
bounding box of the boxes in boxes is
x% of the way across the width of the
video's rendering area, and the point
y% along the height of the bounding box
of the boxes in boxes is y% of the way across the height of the video's rendering area, while maintaining the
relative positions of the boxes in boxes
to each other.

If none of the boxes in boxes
would overlap any of the boxes in output,
and all the boxes in output are within
the video's rendering area, then jump to
the step labeled done positioning below.

If there is a position to which the boxes in boxes can be moved while maintaining the
relative positions of the boxes in boxes
to each other such that none of the boxes in boxes would overlap any of the boxes in output, and all the boxes in output would be within the video's rendering area, then move the boxes in
boxes to the closest such position to
their current position, and then jump to the step labeled
done positioning below. If there are multiple such
positions that are equidistant from their current position,
use the highest one amongst them; if there are several at
that height, then use the leftmost one amongst them.

10.3.2.2 Applying CSS properties to WebVTT Node Objects

On the (root) List of WebVTT Node Objects, the
'position' property must be set to 'absolute', the 'direction'
property must be set to direction, the
'block-flow' property must be set to block-flow,
the 'top' property must be set to top, the
'left' property must be set to left, the 'width'
property must be set to width, and the 'height'
property must be set to height, where direction, block-flow, top, left, width, and height are the values
with those names determined by the rules for updating the
display of WebVTT text tracks for the text track
cue from whose text
the List of WebVTT Node Objects was constructed.

The 'font' shorthand property on the (root) List of WebVTT
Node Objects must be set to '0.1vh sans-serif'. [CSSRUBY][CSSVALUES]

The 'color' property on the (root) List of WebVTT Node
Objects must be set to 'rgba(255,255,255,0)'. [CSSCOLOR]

A text outline or stroke may also be set on the (root) List
of WebVTT Node Objects, if supported.

The 'font-style' property on WebVTT Italic Objects must be set to 'italic'.

The 'font-weight' property on WebVTT Bold Objects must be set to 'bold'.

The 'text-decoration' property on WebVTT Underline Objects must be set to 'underline'.

The 'display' property on WebVTT
Ruby Objects must be set to 'ruby'. [CSSRUBY]

The 'display' property on WebVTT Ruby Text Objects must be set to
'ruby-text'. [CSSRUBY]

If there are style sheets that apply to the media
element or other playback mechanism, then they must be
interpreted as defined in the next section.

All other non-inherited properties must be set to their initial
values; inherited properties on the root List of WebVTT Node
Objects must inherit their values from the media
element for which the text track cue is being
rendered, if any. If there is no media element (i.e. if
the text track is being rendered for another media
playback mechanism), then inherited properties on the root
List of WebVTT Node Objects must take their initial
values.

10.3.2.3 CSS extensions

When a user agent is rendering one or more text track cues according to the WebVTT cue
text rendering rules, WebVTT
Node Objects in the list of WebVTT Node Objects
used in the rendering can be matched by certain pseudo-selectors as
defined below. These selectors can begin or stop matching individual
WebVTT Node Objects while a
cue is being rendered, even in
between applications of the WebVTT cue text rendering
rules (which are only run when the set of active cues
changes). User agents that support the pseudo-element described
below must dynamically update renderings accordingly.

Pseudo-elements apply to elements that are matched by
selectors. For the purpose of this section, that element is the
matched element. The pseudo-elements defined in the following
sections affect the styling of parts of text track cues that are being rendered for the
matched element.

If the matched element is not a
video element, the pseudo-elements defined below won't
have any effect according to this specification.

A CSS user agent that implements the text tracks model must implement the '::cue' and
'::cue(selector)' pseudo-elements, and the
':past' and ':future' pseudo-classes.

10.3.2.3.1 The '::cue' pseudo-element

The '::cue' pseudo-element (with no
argument) matches any List of WebVTT Node Objects
constructed for the matched element, with the exception that
the properties corresponding to the 'background' shorthand must be
applied to the WebVTT cue background box rather than
the List of WebVTT Node Objects.

The following properties apply to the '::cue' pseudo-element with
no argument; other properties set on the pseudo-element must be
ignored:

'color'

'text-shadow'

'text-outline'

the properties corresponding to the 'background' shorthand

the properties corresponding to the 'outline' shorthand

the properties corresponding to the 'font' shorthand, including 'line-height'

The '::cue(selector)' pseudo-element with an argument must
have an argument that consists of a group of selectors. It matches
any WebVTT Internal Node Object constructed for the
matched element that also matches the given group of
selectors, with the nodes being treated as follows:

The document tree against which the selectors are
matched is the tree of WebVTT Node
Objects rooted at the list of WebVTT Node
Objects for the cue.

WebVTT Internal
Node Objects are elements in the tree.

WebVTT Leaf Node
Objects cannot be matched.

For the purposes of element type selectors, the names of WebVTT Internal Node
Objects are as given by the following table, where objects
having the concrete class given in a cell in the first column have
the name given by the second column of the same row:

Concrete class

Name

WebVTT Class Objects

c

WebVTT Italic Objects

i

WebVTT Bold Objects

b

WebVTT Underline Objects

u

WebVTT Ruby Objects

ruby

WebVTT Ruby Text Objects

rt

WebVTT Voice Objects

v

Other elements (specifically, Lists of WebVTT Node Objects)

No explicit name.

For the purposes of element type and universal selectors,
WebVTT Internal Node
Objects are considered as being in the namespace expressed
as the empty string.

For the purposes of attribute selector matching, WebVTT Internal Node
Objects have no attributes, except for WebVTT Voice Objects, which
have a single attribute named "voice"
whose value is the value of the WebVTT Voice
Object.

For the purposes of class selector matching, WebVTT Internal Node
Objects have the classes described as the WebVTT
Node Object's applicable classes.

The following properties apply to the '::cue()' pseudo-element
with an argument:

'color'

'text-shadow'

'text-outline'

the properties corresponding to the 'background' shorthand

the properties corresponding to the 'outline' shorthand

properties relating to the transition and animation features

The following properties apply to the '::cue()' pseudo-element
with an argument when the selector does not contain the ':past' and
':future' pseudo-classes:

the properties corresponding to the 'font' shorthand, including 'line-height'

Properties that do not apply must be ignored.

As a special exception, the properties corresponding to the
'background' shorthand, when they would have been applied to the
List of WebVTT Node Objects, must instead be applied to
the WebVTT cue background box.

10.3.2.3.2 The ':past' and ':future' pseudo-classes

The ':past' and ':future' pseudo-classes only
match WebVTT Node Objects.

The ':past' pseudo-class only matches WebVTT Node Objects that are in the past.

A WebVTT Node Objectc is
in the past if, in a pre-order, depth-first traversal of
the text track cue's List of WebVTT Node
Objects, there exists a WebVTT Timestamp Object
whose value is less than the current playback position
of the media element that is the matched
element, entirely after the WebVTT Node Objectc.

The ':future' pseudo-class only matches WebVTT Node Objects that are in the future.

A WebVTT Node Objectc is
in the future if, in a pre-order, depth-first traversal
of the text track cue's List of WebVTT Node
Objects, there exists a WebVTT Timestamp Object
whose value is greater than the current playback
position of the media element that is the
matched element, entirely before the WebVTT Node
Objectc.

10.3.3 Images

When an img element or an input element
when its type attribute is in
the Image Button state
does not represent an image, but the
element already has intrinsic dimensions (e.g. from the
dimension attributes or CSS rules), and either the user
agent has reason to believe that the image will become available
and be rendered in due course or the Document is in
quirks mode, the element is expected to be treated as a
replaced element whose content is the text that the element
represents, if any, optionally alongside an icon indicating that the
image is being obtained. For input elements, the text
is expected to appear button-like to indicate that the element is a
button.

When an img element represents some
text and the user agent does not expect this to change, the element
is expected to be treated as an inline element whose content is the
text, optionally with an icon indicating that an image is
missing.

When an img element represents nothing
and the user agent does not expect this to change, the element is
expected to not be rendered at all.

When an img element might be a key part of the
content, but neither the image nor any kind of alternative text is
available, and the user agent does not expect this to change, the
element is expected to be treated as an inline element whose content
is an icon indicating that an image is missing.

When an input element whose type attribute is in the Image Button state does not
represent an image and the user
agent does not expect this to change, the element is expected to be
treated as a replaced element consisting of a button whose content
is the element's alternative text. The intrinsic dimensions of the
button are expected to be about one line in height and whatever
width is necessary to render the text on one line.

The icons mentioned above are expected to be relatively small so
as not to disrupt most text but be easily clickable. In a visual
environment, for instance, icons could be 16 pixels by 16 pixels
square, or 1em by 1em if the images are scalable. In an audio
environment, the icon could be a short bleep. The icons are intended
to indicate to the user that they can be used to get to whatever
options the UA provides for images, and, where appropriate, are
expected to provide access to the context menu that would have come
up if the user interacted with the actual image.

All animated images with the same absolute URL and
the same image data are expected to be rendered synchronized to the
same timeline as a group, with the timeline starting at the time of
the most recent addition to the group.

In other words, the animation loop of an animated
image is restarted each time another image with the same
absolute URL and image data begins to animate, e.g.
after being inserted into the document.

When an applet, embed,
iframe, img, or object
element, or an input element whose type attribute is in the Image Button state, has an
align attribute whose value is
an ASCII case-insensitive match for the string "center" or the string "middle", the user agent is expected to act as if the
element's 'vertical-align' property was set to a value that aligns
the vertical middle of the element with the parent element's
baseline.

When an img element, object element, or
input element with a type attribute in the Image Button state is contained
within a hyperlink and has a border attribute whose value, when
parsed using the rules for parsing non-negative
integers, is found to be a number greater than zero, the user
agent is expected to use the parsed value for eight
presentational hints: four setting the parsed value as
a pixel length for the element's 'border-top-width',
'border-right-width', 'border-bottom-width', and 'border-left-width'
properties, and four setting the element's 'border-top-style',
'border-right-style', 'border-bottom-style', and 'border-left-style'
properties to the value 'solid'.

10.3.5 Image maps

Shapes on an image map are expected to act, for the
purpose of the CSS cascade, as elements independent of the original
area element that happen to match the same style rules
but inherit from the img or object
element.

For the purposes of the rendering, only the 'cursor' property is
expected to have any effect on the shape.

Thus, for example, if an area
element has a style attribute that
sets the 'cursor' property to 'help', then when the user designates
that shape, the cursor would change to a Help cursor.

Similarly, if an area element had a
CSS rule that set its 'cursor' property to 'inherit' (or if no rule
setting the 'cursor' property matched the element at all), the
shape's cursor would be inherited from the img or
object element of the image map, not from
the parent of the area element.

10.3.6 Toolbars

When a menu element's type attribute is in the toolbar state, the element is
expected to be treated as a replaced element with a height about two
lines high and a width derived from the contents of the element.

The element is expected to have, by default, the appearance of a
toolbar on the user agent's platform. It is expected to contain the
menu that is built
from the element.

10.4 Bindings

10.4.1 Introduction

A number of elements have their rendering defined in terms of the
'binding' property. [BECSS]

The CSS snippets below set the 'binding' property to a
user-agent-defined value, represented below by keywords like button. The rules then described for
these bindings are only expected to apply if the element's 'binding'
property has not been overridden (e.g. by the author) to have
another value.

Exactly how the bindings are implemented is not specified by this
specification. User agents are encouraged to make their bindings set
the 'appearance' CSS property appropriately to achieve
platform-native appearances for widgets, and are expected to
implement any relevant animations, etc, that are appropriate for the
platform. [CSSUI]

When the details binding applies to a
details element, the element is expected to render as a
'block' box with its 'padding-left' property set to '40px' for
left-to-right elements (LTR-specific) and with its
'padding-right' property set to '40px' for right-to-left
elements. The element's shadow tree is expected to take the
element's first child summary element, if any, and
place it in a first 'block' box container, and then take the
element's remaining descendants, if any, and place them in a second
'block' box container.

The first container is expected to contain at least one line box,
and that line box is expected to contain a disclosure widget
(typically a triangle), horizontally positioned within the left
padding of the details element. That widget is expected
to allow the user to request that the details be shown or
hidden.

The second container is expected to have its 'overflow' property
set to 'hidden'. When the details element does not have
an open attribute, this
second container is expected to be removed from the rendering.

When the input-textfield binding applies to an
input element whose type attribute is in the Text, Search, Telephone, URL, or E-mail state, the element is
expected to render as an 'inline-block' box rendered as a text
field.

When the input-password binding applies, to an
input element whose type attribute is in the Password state, the element
is expected to render as an 'inline-block' box rendered as a text
field whose contents are obscured.

If an input element whose type attribute is in one of the above
states does not have a size attribute, then the user agent
is expected to act as if it had a user-agent-level style sheet rule
setting the 'width' property on the element to the value obtained
from applying the converting a character width to
pixels algorithm to the number 20.

The converting a character width to pixels algorithm
returns (size-1)×avg + max, where
size is the character width to convert, avg is the average character width of the primary
font for the element for which the algorithm is being run, in
pixels, and max is the maximum character width
of that same font, also in pixels. (The element's 'letter-spacing'
property does not affect the result.)

When the input-datetime binding applies to an
input element whose type attribute is in the Date and Time state, the
element is expected to render as an 'inline-block' box depicting a
Date and Time control.

When the input-date binding applies to an
input element whose type attribute is in the Date state, the element is
expected to render as an 'inline-block' box depicting a Date
control.

When the input-month binding applies to an
input element whose type attribute is in the Month state, the element is
expected to render as an 'inline-block' box depicting a Month
control.

When the input-week binding applies to an
input element whose type attribute is in the Week state, the element is
expected to render as an 'inline-block' box depicting a Week
control.

When the input-time binding applies to an
input element whose type attribute is in the Time state, the element is
expected to render as an 'inline-block' box depicting a Time
control.

When the input-datetime-local binding applies to an
input element whose type attribute is in the Local Date and Time
state, the element is expected to render as an 'inline-block' box
depicting a Local Date and Time control.

When the input-number binding applies to an
input element whose type attribute is in the Number state, the element is
expected to render as an 'inline-block' box depicting a Number
control.

These controls are all expected to be about one line high, and
about as wide as necessary to show the widest possible value.

When the input-range binding applies to an
input element whose type attribute is in the Range state, the element is
expected to render as an 'inline-block' box depicting a slider
control.

When the control is wider than it is tall (or square), the
control is expected to be a horizontal slider, with the lowest value
on the right if the 'direction' property on this element has a
computed value of 'rtl', and on the left otherwise. When the control
is taller than it is wide, it is expected to be a vertical slider,
with the lowest value on the bottom.

Predefined suggested values (provided by the list attribute) are expected to be
shown as tick marks on the slider, which the slider can snap to.

When the input-color binding applies to an
input element whose type attribute is in the Color state, the element is
expected to render as an 'inline-block' box depicting a color well,
which, when activated, provides the user with a color picker (e.g. a
color wheel or color palette) from which the color can be
changed.

Predefined suggested values (provided by the list attribute) are expected to be
shown in the color picker interface, not on the color well
itself.

When the input-checkbox binding applies to an
input element whose type attribute is in the Checkbox state, the element
is expected to render as an 'inline-block' box containing a single
checkbox control, with no label.

When the input-radio binding applies to an
input element whose type attribute is in the Radio Button state, the element
is expected to render as an 'inline-block' box containing a single
radio button control, with no label.

When the input-file binding applies to an
input element whose type attribute is in the File Upload state, the element
is expected to render as an 'inline-block' box containing a span of
text giving the filename(s) of the selected files, if
any, followed by a button that, when activated, provides the user
with a file picker from which the selection can be changed.

When the input-button binding applies to an
input element whose type attribute is in the Submit Button, Reset Button, or Button state, the element is
expected to render as an 'inline-block' box rendered as a button,
about one line high, containing the contents of the element's value attribute, if any, or text
derived from the element's type
attribute in a user-agent-defined (and probably locale-specific)
fashion, if not.

Slide the contents of the element in the direction described by
the direction
attribute as defined below, such that it begins off the start side
of the marquee, and ends flush with the inner end
side.

For example, if the direction attribute is left (the default),
then the contents would start such that their left edge are off
the side of the right edge of the marquee's content
area, and the contents would then slide up to the point where the
left edge of the contents are flush with the left inner edge of
the marquee's content area.

Slide the contents of the element in the direction described by
the direction
attribute as defined below, such that it begins off the start side
of the marquee, and ends off the end side of the
marquee.

For example, if the direction attribute is left (the default),
then the contents would start such that their left edge are off
the side of the right edge of the marquee's content
area, and the contents would then slide up to the point where the
right edge of the contents are flush with the left inner
edge of the marquee's content area.

When the marquee current loop index is even (or
zero), slide the contents of the element in the direction
described by the direction attribute as
defined below, such that it begins flush with the start side of
the marquee, and ends flush with the end side of the
marquee.

When the marquee current loop index is odd, slide
the contents of the element in the opposite direction than that
described by the direction attribute as
defined below, such that it begins flush with the end side of the
marquee, and ends flush with the start side of the
marquee.

For example, if the direction attribute is left (the default),
then the contents would with their right edge flush with the right
inner edge of the marquee's content area, and the
contents would then slide up to the point where the left
edge of the contents are flush with the left inner edge of the
marquee's content area.

In any case, the animation should proceed such that there is a
delay given by the marquee scroll interval between each
frame, and such that the content moves at most the distance given by
the marquee scroll distance with each frame.

When a marquee element has a bgcolor attribute set, the value
is expected to be parsed using the rules for parsing a legacy
color value, and if that does not return an error, the user
agent is expected to treat the attribute as a presentational hint setting the
element's 'background-color' property to the resulting color.

When the meter binding applies to a
meter element, the element is expected to render as an
'inline-block' box with a 'height' of '1em' and a 'width' of '5em',
a 'vertical-align' of '-0.2em', and with its contents depicting a
gauge.

When the element is wider than it is tall (or square), the
depiction is expected to be of a horizontal gauge, with the minimum
value on the right if the 'direction' property on this element has a
computed value of 'rtl', and on the left otherwise. When the element
is taller than it is wide, it is expected to depict a vertical
gauge, with the minimum value on the bottom.

User agents are expected to use a presentation consistent with
platform conventions for gauges, if any.

Requirements for what must be depicted in the gauge
are included in the definition of the meter
element.

When the progress binding applies to a
progress element, the element is expected to render as
an 'inline-block' box with a 'height' of '1em' and a 'width' of
'10em', and a 'vertical-align' of '-0.2em'.

When the element is wider than it is tall, the element is
expected to be depicted as a horizontal progress bar, with the start
on the right and the end on the left if the 'direction' property on
this element has a computed value of 'rtl', and with the start on
the left and the end on the right otherwise. When the element is
taller than it is wide, it is expected to depicted as a vertical
progress bar, with the lowest value on the bottom. When the element
is square, it is expected to be depicted as a direction-independent
progress widget (e.g. a circular progress ring).

User agents are expected to use a presentation consistent with
platform conventions for progress bars. In particular, user agents
are expected to use different presentations for determinate and
indeterminate progress bars. User agents are also expected to vary
the presentation based on the dimensions of the element.

For example, on some platforms for showing
indeterminate progress there is an asynchronous progress indicator
with square dimensions, which could be used when the element is
square, and an indeterminate progress bar, which could be used when
the element is wide.

Requirements for how to determine if the progress
bar is determinate or indeterminate, and what progress a determinate
progress bar is to show, are included in the definition of the
progress element.

When the select binding applies to a
select element whose multiple attribute is present,
the element is expected to render as a multi-select list box.

When the select binding applies to a
select element whose multiple attribute is absent,
and the element's display
size is greater than 1, the element is expected to render as
a single-select list box.

When the element renders as a list box, it is expected to render
as an 'inline-block' box whose 'height' is the height necessary to
contain as many rows for items as given by the element's display size, or four rows if the
attribute is absent, and whose 'width' is the width of the
select's labels plus the width of a
scrollbar.

In either case (list box or drop-down box), the element's items
are expected to be the element's list of options, with the
element's optgroup element children providing headers
for groups of options where applicable.

An optgroup element is expected to be rendered by
displaying the element's label attribute.

An option element is expected to be rendered by
displaying the element's label, indented under its
optgroup element if it has one.

The width of the select's labels is the
wider of the width necessary to render the widest
optgroup, and the width necessary to render the widest
option element in the element's list of options (including
its indent, if any).

The textarea effective width of a
textarea element is size×avg + sbw, where size is the
element's character
width, avg is the average character width
of the primary font of the element, in CSS pixels, and sbw is the width of a scroll bar, in CSS pixels. (The
element's 'letter-spacing' property does not affect the result.)

The textarea effective height of a
textarea element is the height in CSS pixels of the
number of lines specified the element's character height, plus the
height of a scrollbar in CSS pixels.

User agents are expected to apply the 'white-space' CSS property
to textarea elements. For historical reasons, if the
element has a wrap attribute
whose value is an ASCII case-insensitive match for the
string "off", then the
user agent is expected to treat the attribute as a presentational hint setting the
element's 'white-space' property to 'pre'.

When the time binding applies to a
time element, the element is expected to render as if
it contained text conveying the date (if known), time (if known), and time-zone offset (if known)
represented by the element, in the fashion most convenient for the
user.

10.5 Frames and framesets

When an html element's second child element is a
frameset element, the user agent is expected to render
the frameset element as described below across the
surface of the viewport, instead of applying the usual CSS rendering
rules.

When rendering a frameset on a surface, the user
agent is expected to use the following layout algorithm:

The cols and rows
variables are lists of zero or more pairs consisting of a number
and a unit, the unit being one of percentage,
relative, and absolute.

For each rectangle, if there is an element assigned to that
rectangle, and that element has a border, draw an
inner set of borders around that rectangle, using the
element's frame border color.

For each (visible) border that does not abut a rectangle that
is assigned a frame element with a noresize attribute (including
rectangles in further nested frameset elements), the
user agent is expected to allow the user to move the border,
resizing the rectangles within, keeping the proportions of any
nested frameset grids.

A frameset or frame element has
a border if the following algorithm returns true:

If the element has a frameborder attribute
whose value is not the empty string and whose first character is
either a U+0031 DIGIT ONE (1) character, a U+0079 LATIN SMALL
LETTER Y character (y), or a U+0059 LATIN CAPITAL LETTER Y
character (Y), then return true.

Otherwise, if the element has a frameborder attribute,
return false.

Otherwise, if the element has a parent element that is a
frameset element, then return true if that
element has a border, and false if it does
not.

Otherwise, return true.

The frame border color of a frameset or
frame element is the color obtained from the
following algorithm:

The algorithm to convert a list of dimensions to a list of
pixel values consists of the following steps:

Let input list be the list of numbers and
units passed to the algorithm.

Let output list be a list of numbers the
same length as input list, all zero.

Entries in output list correspond to the
entries in input list that have the same
position.

Let input dimension be the size passed
to the algorithm.

Let count percentage be the number of
entries in input list whose unit is
percentage.

Let total percentage be the sum of all the
numbers in input list whose unit is
percentage.

Let count relative be the number of
entries in input list whose unit is
relative.

Let total relative be the sum of all the
numbers in input list whose unit is
relative.

Let count absolute be the number of
entries in input list whose unit is
absolute.

Let total absolute be the sum of all the
numbers in input list whose unit is
absolute.

Let remaining space be the value of input dimension.

If total absolute is greater than remaining space, then for each entry in input list whose unit is absolute, set the
corresponding value in output list to the
number of the entry in input list multiplied
by remaining space and divided by total absolute. Then, set remaining
space to zero.

Otherwise, for each entry in input list
whose unit is absolute, set the corresponding value in output list to the number of the entry in input list. Then, decrement remaining
space by total absolute.

If total percentage multiplied by the input dimension and divided by 100 is greater than
remaining space, then for each entry in input list whose unit is percentage, set the
corresponding value in output list to the
number of the entry in input list multiplied
by remaining space and divided by total percentage. Then, set remaining
space to zero.

Otherwise, for each entry in input list
whose unit is percentage, set the corresponding value in
output list to the number of the entry in input list multiplied by the input
dimension and divided by 100. Then, decrement remaining space by total
percentage multiplied by the input
dimension and divided by 100.

For each entry in input list whose unit is
relative, set the corresponding value in output list to the number of the entry in input list multiplied by remaining
space and divided by total relative.

Return output list.

User agents working with integer values for frame widths (as
opposed to user agents that can lay frames out with subpixel
accuracy) are expected to distribute the remainder first to the last
entry whose unit is relative, then equally (not
proportionally) to each entry whose unit is percentage, then
equally (not proportionally) to each entry whose unit is
absolute, and finally, failing all else, to the last
entry.

User agents are expected to surface hyperlinks created by link
elements in their user interface.

While link elements that create hyperlinks will match the ':link' or
':visited' pseudo-classes, will react to clicks if visible, and so
forth, this does not extend to any browser interface constructs that
expose those same links. Activating a link through the browser's
interface, rather than in the page itself, does not trigger click events and the like.

Given an element (e.g. the element designated by the mouse
cursor), if the element, or one of its ancestors, has a title attribute, and the nearest such
attribute has a value that is not the empty string, it is expected
that the user agent will expose the contents of that attribute as a
tooltip.

U+000A LINE FEED (LF) characters are expected to cause line
breaks in the tooltip, U+0009 CHARACTER TABULATION (tab) characters
are expected to render as a non-zero horizontal shift that lines up
the next glpyh with the next tab stop, with tab stops occurring at
points that are multiples of 8 times the width of a U+0020 SPACE
character.

User agents are encouraged to make it possible to view tooltips
without the use of a pointing device, since not all users are able
to use pointing devices.

For example, a visual user agent could make elements with a
title attribute focusable, and
could make any focused element with a title attribute show its tooltip under
the element while the element has focus. This would allow a user to
tab around the document to find all the advisory text.

As another example, a screen reader could provide an audio cue
when reading an element with a tooltip, with an associated key to
read the last tooltip for which a cue was played.

10.6.3 Editing hosts

The current text editing caret (the one at the caret
position in a focused editing host) is expected
to act like an inline replaced element with the vertical dimensions
of the caret and with zero width for the purposes of the CSS
rendering model.

This means that even an empty block can have the
caret inside it, and that when the caret is in such an element, it
prevents margins from collapsing through the element.

10.6.4 Text rendered in native user interfaces

User agents are expected to honor the Unicode semantics of text
that is exposed in user interfaces, for example supporting the
bidirectional algorithm in text shown in dialogs, title bars, pop-up
menus, and tooltips. Text from elements (either attribute values or
the contents of elements) is expected to be rendered in a manner
that honors the directionality of the element from
which the text was obtained.

Consider the following markup, which has Hebrew text asking for
a programming language, the languages being text for which a
left-to-right direction is important given the punctuation in some
of their names:

If the select element was rendered as a drop down
box, a correct rendering would ensure that the punctuation was the
same both in the drop down, and in the box showing the current
selection.

A string provided by a script (e.g. the argument to window.alert()) is expected to be treated
as an independent set of one or more bidirectional algorithm
paragraphs when displayed, as defined by the bidirectional
algorithm, including, for instance, supporting the
paragraph-breaking behaviour of U+000A LINE FEED (LF) characters.
For the purposes of determining the paragraph level of such text in
the bidirectional algorithm, this specification does not
provide a higher-level override of rules P2 and P3. [BIDI]

When necessary, authors can enforce a particular direction for a
given paragraph by starting it with the Unicode U+200E LEFT-TO-RIGHT
MARK or U+200F RIGHT-TO-LEFT MARK characters.

Thus, the following script:

alert('\u05DC\u05DE\u05D3 HTML \u05D4\u05D9\u05D5\u05DD!')

...would always result in a message reading
"למד LMTH היום!"
(not "דמל HTML םויה!"),
regardless of the language of the user agent interface or the
direction of the page or any of its elements.

When the user enters "Kitty", the user agent would
alert "Kitty! Ok, Fred, Kitty, and Wilma will get the
car.". However, if the user enters "لا أفهم",
then the bidirectional algorithm will determine that the direction
of the paragraph is right-to-left, and so the output will be the
following unintended mess: "لا أفهم! derF ,kO, لا أفهم, rac eht teg lliw amliW dna."

To force an alert that starts with user-provided text (or other
text of unknown directionality) to render left-to-right, the string
can be prefixed with a U+200E LEFT-TO-RIGHT MARK character:

10.7 Print media

User agents are expected to allow the user to request the
opportunity to obtain a physical form (or a
representation of a physical form) of a Document. For
example, selecting the option to print a page or convert it to PDF
format.