Table of contents
  1. 10 Rendering
    1. 10.1 Introduction
    2. 10.2 The CSS user agent style sheet and presentational hints
      1. 10.2.1 Introduction
      2. 10.2.2 Display types
      3. 10.2.3 Margins and padding
      4. 10.2.4 Alignment
      5. 10.2.5 Fonts and colors
      6. 10.2.6 Punctuation and decorations
      7. 10.2.7 Resetting rules for inherited properties
      8. 10.2.8 The hr element
      9. 10.2.9 The fieldset element
    3. 10.3 Replaced elements
      1. 10.3.1 Embedded content
      2. 10.3.2 Timed text tracks
        1. 10.3.2.1 WebVTT cue text rendering rules
        2. 10.3.2.2 Applying CSS properties to WebVTT Node Objects
        3. 10.3.2.3 CSS extensions
          1. 10.3.2.3.1 The '::cue' pseudo-element
          2. 10.3.2.3.2 The ':past' and ':future' pseudo-classes
      3. 10.3.3 Images
      4. 10.3.4 Attributes for embedded content and images
      5. 10.3.5 Image maps
      6. 10.3.6 Toolbars
    4. 10.4 Bindings
      1. 10.4.1 Introduction
      2. 10.4.2 The button element
      3. 10.4.3 The details element
      4. 10.4.4 The input element as a text entry widget
      5. 10.4.5 The input element as domain-specific widgets
      6. 10.4.6 The input element as a range control
      7. 10.4.7 The input element as a color well
      8. 10.4.8 The input element as a checkbox and radio button widgets
      9. 10.4.9 The input element as a file upload control
      10. 10.4.10 The input element as a button
      11. 10.4.11 The marquee element
      12. 10.4.12 The meter element
      13. 10.4.13 The progress element
      14. 10.4.14 The select element
      15. 10.4.15 The textarea element
      16. 10.4.16 The keygen element
      17. 10.4.17 The time element
    5. 10.5 Frames and framesets
    6. 10.6 Interactive media
      1. 10.6.1 Links, forms, and navigation
      2. 10.6.2 The title attribute
      3. 10.6.3 Editing hosts
      4. 10.6.4 Text rendered in native user interfaces
    7. 10.7 Print media

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:

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 element maps 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 element maps 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.

10.2.2 Display types

@namespace url(http://www.w3.org/1999/xhtml);

[hidden], area, base, basefont, command, datalist, head,
input[type=hidden], link, menu[type=context], meta, noembed, noframes,
param, rp, script, source, style, track, title { /* case-insensitive */
  display: none;
}

address, article, aside, blockquote, body, center, dd, dir, div, dl,
dt, figure, figcaption, footer, form, h1, h2, h3, h4, h5, h6, header,
hgroup, hr, html, legend, listing, menu, nav, ol, p, plaintext, pre,
section, summary, ul, xmp { display: block; unicode-bidi: isolate; }

table { display: table; unicode-bidi: isolate; }
caption { display: table-caption; unicode-bidi: isolate; }
colgroup, colgroup[hidden] { display: table-column-group; unicode-bidi: isolate; }
col, col[hidden] { display: table-column; unicode-bidi: isolate; }
thead, thead[hidden] { display: table-header-group; unicode-bidi: isolate; }
tbody, tbody[hidden] { display: table-row-group; unicode-bidi: isolate; }
tfoot, tfoot[hidden] { display: table-footer-group; unicode-bidi: isolate; }
tr, tr[hidden] { display: table-row; unicode-bidi: isolate; }
td, th, td[hidden], th[hidden] { display: table-cell; unicode-bidi: isolate; }

colgroup[hidden], col[hidden], thead[hidden], tbody[hidden],
tfoot[hidden], tr[hidden], td[hidden], th[hidden] {
  visibility: collapse;
}

li { display: list-item; unicode-bidi: isolate; }

ruby { display: ruby; }
rt { display: ruby-text; }

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 user agent is expected to hide noscript elements for whom scripting is enabled, irrespective of CSS rules.

In HTML documents, the user agent is expected to hide form elements that are children of table, thead, tbody, tfoot, or tr elements, irrespective of CSS rules.

10.2.3 Margins and padding

@namespace url(http://www.w3.org/1999/xhtml);

blockquote, dir, dl, figure, listing, menu, ol, p, plaintext,
pre, ul, xmp {
  margin-top: 1em; margin-bottom: 1em;
}

dir dir, dir dl, dir menu, dir ol, dir ul,
dl dir, dl dl, dl menu, dl ol, dl ul,
menu dir, menu dl, menu menu, menu ol, menu ul,
ol dir, ol dl, ol menu, ol ol, ol ul,
ul dir, ul dl, ul menu, ul ol, ul ul {
  margin-top: 0; margin-bottom: 0;
}

h1 { margin-top: 0.67em; margin-bottom: 0.67em; }
h2 { margin-top: 0.83em; margin-bottom: 0.83em; }
h3 { margin-top: 1.00em; margin-bottom: 1.00em; }
h4 { margin-top: 1.33em; margin-bottom: 1.33em; }
h5 { margin-top: 1.67em; margin-bottom: 1.67em; }
h6 { margin-top: 2.33em; margin-bottom: 2.33em; }

dd { margin-left: 40px; } /* LTR-specific: use 'margin-right' for rtl elements */
dir, menu, ol, ul { padding-left: 40px; } /* LTR-specific: use 'padding-right' for rtl elements */
blockquote, figure { margin-left: 40px; margin-right: 40px; }

table { border-spacing: 2px; border-collapse: separate; }
td, th { padding: 1px; }

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:

@namespace url(http://www.w3.org/1999/xhtml);

x h1 { margin-top: 0.83em; margin-bottom: 0.83em; }
x x h1 { margin-top: 1.00em; margin-bottom: 1.00em; }
x x x h1 { margin-top: 1.33em; margin-bottom: 1.33em; }
x x x x h1 { margin-top: 1.67em; margin-bottom: 1.67em; }
x x x x x h1 { margin-top: 2.33em; margin-bottom: 2.33em; }

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.

Property Source
'margin-top' body element's marginheight attribute
The body element's container frame element's marginheight attribute
body element's topmargin attribute
'margin-right' body element's marginwidth attribute
The body element's container frame element's marginwidth attribute
body element's rightmargin attribute
'margin-bottom' body element's marginheight attribute
The body element's container frame element's marginheight attribute
body element's bottommargin attribute
'margin-left' body element's marginwidth attribute
The body element's container frame element's marginwidth attribute
body element's leftmargin attribute

If the body element's Document's browsing context is a nested browsing context, and the browsing context container of that nested browsing context is a frame or iframe element, then the container frame element of the body element is that frame or iframe element. Otherwise, there is no container frame element.

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.


If the Document has a root element, and the Document's browsing context is a nested browsing context, and the browsing context container of that nested browsing context is a frame or iframe element, and that element has a scrolling attribute, then the user agent is expected to compare the value of the attribute in an ASCII case-insensitive manner to the values in the first column of the following table, and if one of them matches, then the user agent is expected to treat that attribute as a presentational hint for the aforementioned root element's 'overflow' property, setting it to the value given in the corresponding cell on the same row in the second column:

Attribute value 'overflow' value
on 'scroll'
scroll 'scroll'
yes 'scroll'
off 'hidden'
noscroll 'hidden'
no 'hidden'
auto 'auto'

The table element's cellspacing attribute maps to the pixel length property 'border-spacing' on the element.

The table element's cellpadding attribute maps to the pixel length properties 'padding-top', 'padding-right', 'padding-bottom', and 'padding-left' of any td and th elements that have corresponding cells in the table corresponding to the table element.

The table element's hspace attribute maps to the dimension properties 'margin-left' and 'margin-right' on the table element.

The table element's vspace attribute maps to the dimension properties 'margin-top' and 'margin-bottom' on the table element.

The table element's height attribute maps to the dimension property 'height' on the table element.

The table element's width attribute maps to the dimension property 'width' on the table element.

The col element's width attribute maps to the dimension property 'width' on the col element.

The tr element's height attribute maps to the dimension property 'height' on the tr element.

The td and th elements' height attributes map to the dimension property 'height' on the element.

The td and th elements' width attributes map to the dimension property 'width' on the element.


In quirks mode, the following rules are also expected to apply:

@namespace url(http://www.w3.org/1999/xhtml);

form { margin-bottom: 1em; }

When a Document is in quirks mode, margins on HTML elements at the top or bottom of body, td, or th elements are expected to be collapsed to zero.

10.2.4 Alignment

@namespace url(http://www.w3.org/1999/xhtml);

thead, tbody, tfoot, table > tr { vertical-align: middle; }
tr, td, th { vertical-align: inherit; }
sub { vertical-align: sub; }
sup { vertical-align: super; }

The following rules are also expected to apply, as presentational hints:

@namespace url(http://www.w3.org/1999/xhtml);

table[align=left] { float: left; } /* case-insensitive */
table[align=right] { float: right; } /* case-insensitive */
table[align=center], table[align=abscenter],
table[align=absmiddle], table[align=middle] { /* case-insensitive */
  margin-left: auto; margin-right: auto;
}
thead[align=absmiddle], tbody[align=absmiddle], tfoot[align=absmiddle],
tr[align=absmiddle], td[align=absmiddle], th[align=absmiddle] { /* case-insensitive */
  text-align: center;
}

caption[align=bottom] { caption-side: bottom; } /* case-insensitive */
p[align=left], h1[align=left], h2[align=left], h3[align=left],
h4[align=left], h5[align=left], h6[align=left] { /* case-insensitive */
  text-align: left;
}
p[align=right], h1[align=right], h2[align=right], h3[align=right],
h4[align=right], h5[align=right], h6[align=right] { /* case-insensitive */
  text-align: right;
}
p[align=center], h1[align=center], h2[align=center], h3[align=center],
h4[align=center], h5[align=center], h6[align=center] { /* case-insensitive */
  text-align: center;
}
p[align=justify], h1[align=justify], h2[align=justify], h3[align=justify],
h4[align=justify], h5[align=justify], h6[align=justify] { /* case-insensitive */
  text-align: justify;
}
thead[valign=top], tbody[valign=top], tfoot[valign=top],
tr[valign=top], td[valign=top], th[valign=top] { /* case-insensitive */
  vertical-align: top;
}
thead[valign=middle], tbody[valign=middle], tfoot[valign=middle],
tr[valign=middle], td[valign=middle], th[valign=middle] { /* case-insensitive */
  vertical-align: middle;
}
thead[valign=bottom], tbody[valign=bottom], tfoot[valign=bottom],
tr[valign=bottom], td[valign=bottom], th[valign=bottom] { /* case-insensitive */
  vertical-align: bottom;
}
thead[valign=baseline], tbody[valign=baseline], tfoot[valign=baseline],
tr[valign=baseline], td[valign=baseline], th[valign=baseline] { /* case-insensitive */
  vertical-align: baseline;
}

The center element, the caption element unless specified otherwise below, and the div, thead, tbody, tfoot, tr, td, and th elements when they have an align attribute whose value is an ASCII case-insensitive match for either the string "center" or the string "middle", are expected to center text within themselves, as if they had their 'text-align' property set to 'center' in a presentational hint, and to align descendants to the center.

The div, caption, thead, tbody, tfoot, tr, td, and th elements, when they have an align attribute whose value is an ASCII case-insensitive match for the string "left", are expected to left-align text within themselves, as if they had their 'text-align' property set to 'left' in a presentational hint, and to align descendants to the left.

The div, caption, thead, tbody, tfoot, tr, td, and th elements, when they have an align attribute whose value is an ASCII case-insensitive match for the string "right", are expected to right-align text within themselves, as if they had their 'text-align' property set to 'right' in a presentational hint, and to align descendants to the right.

The div, caption, thead, tbody, tfoot, tr, td, and th elements, when they have an align attribute whose value is an ASCII case-insensitive match for the string "justify", are expected to full-justify text within themselves, as if they had their 'text-align' property set to 'justify' in a presentational hint, and to align descendants to the left.

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

10.2.5 Fonts and colors

@namespace url(http://www.w3.org/1999/xhtml);

address, cite, dfn, em, i, var { font-style: italic; }
b, strong, th { font-weight: bold; }
code, kbd, listing, plaintext, pre, samp, tt, xmp { font-family: monospace; }
h1 { font-size: 2.00em; font-weight: bold; }
h2 { font-size: 1.50em; font-weight: bold; }
h3 { font-size: 1.17em; font-weight: bold; }
h4 { font-size: 1.00em; font-weight: bold; }
h5 { font-size: 0.83em; font-weight: bold; }
h6 { font-size: 0.67em; font-weight: bold; }
big { font-size: larger; }
small, sub, sup { font-size: smaller; }
sub, sup { line-height: normal; }

:link { color: blue; }
:visited { color: purple; }
mark { background: yellow; color: black; }

table, td, th { border-color: gray; }
thead, tbody, tfoot, tr { border-color: inherit; }
table[rules=none], table[rules=groups], table[rules=rows],
table[rules=cols], table[rules=all], table[frame=void],
table[frame=above], table[frame=below], table[frame=hsides],
table[frame=lhs], table[frame=rhs], table[frame=vsides],
table[frame=box], table[frame=border],
table[rules=none] > tr > td, table[rules=none] > tr > th,
table[rules=groups] > tr > td, table[rules=groups] > tr > th,
table[rules=rows] > tr > td, table[rules=rows] > tr > th,
table[rules=cols] > tr > td, table[rules=cols] > tr > th,
table[rules=all] > tr > td, table[rules=all] > tr > th,
table[rules=none] > thead > tr > td, table[rules=none] > thead > tr > th,
table[rules=groups] > thead > tr > td, table[rules=groups] > thead > tr > th,
table[rules=rows] > thead > tr > td, table[rules=rows] > thead > tr > th,
table[rules=cols] > thead > tr > td, table[rules=cols] > thead > tr > th,
table[rules=all] > thead > tr > td, table[rules=all] > thead > tr > th,
table[rules=none] > tbody > tr > td, table[rules=none] > tbody > tr > th,
table[rules=groups] > tbody > tr > td, table[rules=groups] > tbody > tr > th,
table[rules=rows] > tbody > tr > td, table[rules=rows] > tbody > tr > th,
table[rules=cols] > tbody > tr > td, table[rules=cols] > tbody > tr > th,
table[rules=all] > tbody > tr > td, table[rules=all] > tbody > tr > th,
table[rules=none] > tfoot > tr > td, table[rules=none] > tfoot > tr > th,
table[rules=groups] > tfoot > tr > td, table[rules=groups] > tfoot > tr > th,
table[rules=rows] > tfoot > tr > td, table[rules=rows] > tfoot > tr > th,
table[rules=cols] > tfoot > tr > td, table[rules=cols] > tfoot > tr > th,
table[rules=all] > tfoot > tr > td, table[rules=all] > tfoot > tr > th { /* case-insensitive */
  border-color: black;
}

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:

@namespace url(http://www.w3.org/1999/xhtml);

x h1 { font-size: 1.50em; }
x x h1 { font-size: 1.17em; }
x x x h1 { font-size: 1.00em; }
x x x x h1 { font-size: 0.83em; }
x x x x x h1 { font-size: 0.67em; }

When a body, table, thead, tbody, tfoot, tr, td, or th element has a background attribute set to a non-empty value, the new value is expected to be resolved relative to the element, and if this is successful, the user agent is expected to treat the attribute as a presentational hint setting the element's 'background-image' property to the resulting absolute URL.

When a body, table, thead, tbody, tfoot, tr, td, or th element has a bgcolor attribute set, the new 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 a body element has a text 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 'color' property to the resulting color.

When a body element has a link 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 ':link' pseudo-class to the resulting color.

When a body element has a vlink 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 ':visited' pseudo-class to the resulting color.

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.


When a font element has a color 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 'color' property to the resulting color.

When a font element has a face attribute, the user agent is expected to treat the attribute as a presentational hint setting the element's 'font-family' property to the attribute's value.

When a font element has a size attribute, the user agent is expected to use the following steps to treat the attribute as a presentational hint setting the element's 'font-size' property:

  1. Let input be the attribute's value.

  2. Let position be a pointer into input, initially pointing at the start of the string.

  3. Skip whitespace.

  4. If position is past the end of input, there is no presentational hint. Abort these steps.

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

  6. Collect a sequence of characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), and let the resulting sequence be digits.

  7. If digits is the empty string, there is no presentational hint. Abort these steps.

  8. Interpret digits as a base-ten integer. Let value be the resulting number.

  9. If mode is relative-plus, then increment value by 3. If mode is relative-minus, then let value be the result of subtracting value from 3.

  10. If value is greater than 7, let it be 7.

  11. If value is less than 1, let it be 1.

  12. Set 'font-size' to the keyword corresponding to the value of value according to the following table:

    value 'font-size' keyword Notes
    1 xx-small
    2 small
    3 medium
    4 large
    5 x-large
    6 xx-large
    7 xxx-large see below

    The 'xxx-large' value is a non-CSS value used here to indicate a font size one "step" larger than 'xx-large'.

10.2.6 Punctuation and decorations

@namespace url(http://www.w3.org/1999/xhtml);

:link, :visited, ins, u { text-decoration: underline; }
abbr[title], acronym[title] { text-decoration: dotted underline; }
del, s, strike { text-decoration: line-through; }
blink { text-decoration: blink; }

:focus { outline: auto; }

q:before { content: open-quote; }
q:after { content: close-quote; }

br { content: '\A'; white-space: pre; }

nobr { white-space: nowrap; }
listing, plaintext, pre, xmp { white-space: pre; }
textarea { white-space: pre-wrap; }

ol { list-style-type: decimal; }

dir, menu, ul {
  list-style-type: disc;
}

dir dl, dir menu, dir ul,
menu dl, menu menu, menu ul,
ol dl, ol menu, ol ul,
ul dl, ul menu, ul ul {
  list-style-type: circle;
}

dir dir dl, dir dir menu, dir dir ul,
dir menu dl, dir menu menu, dir menu ul,
dir ol dl, dir ol menu, dir ol ul,
dir ul dl, dir ul menu, dir ul ul,
menu dir dl, menu dir menu, menu dir ul,
menu menu dl, menu menu menu, menu menu ul,
menu ol dl, menu ol menu, menu ol ul,
menu ul dl, menu ul menu, menu ul ul,
ol dir dl, ol dir menu, ol dir ul,
ol menu dl, ol menu menu, ol menu ul,
ol ol dl, ol ol menu, ol ol ul,
ol ul dl, ol ul menu, ol ul ul,
ul dir dl, ul dir menu, ul dir ul,
ul menu dl, ul menu menu, ul menu ul,
ul ol dl, ul ol menu, ul ol ul,
ul ul dl, ul ul menu, ul ul ul {
  list-style-type: square;
}

table { border-style: outset; }
td, th { border-style: inset; }

:ltr { direction: ltr; }
:rtl { direction: rtl; }
[dir] { unicode-bidi: embed; }
bdi, output, [dir=auto] { unicode-bidi: isolate; } /* case-insensitive */
bdo, bdo[dir] { unicode-bidi: bidi-override; }
bdo[dir=auto] { unicode-bidi: bidi-override isolate; } /* case-insensitive */
textarea[dir=auto], pre[dir=auto] { unicode-bidi: plaintext; } /* case-insensitive */

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.


The following rules are also expected to apply, as presentational hints:

@namespace url(http://www.w3.org/1999/xhtml);

td[nowrap], th[nowrap] { white-space: nowrap; }
pre[wrap] { white-space: pre-wrap; }

br[clear=left] { clear: left; } /* case-insensitive */
br[clear=right] { clear: right; } /* case-insensitive */
br[clear=all], br[clear=both] { clear: both; } /* case-insensitive */

ol[type=1], li[type=1] { list-style-type: decimal; }
ol[type=a], li[type=a] { list-style-type: lower-alpha; }
ol[type=A], li[type=A] { list-style-type: upper-alpha; }
ol[type=i], li[type=i] { list-style-type: lower-roman; }
ol[type=I], li[type=I] { list-style-type: upper-roman; }
ul[type=disc], li[type=disc] { list-style-type: disc; } /* case-insensitive */
ul[type=circle], li[type=circle] { list-style-type: circle; } /* case-insensitive */
ul[type=square], li[type=square] { list-style-type: square; } /* case-insensitive */

table[rules=none], table[rules=groups], table[rules=rows],
table[rules=cols], table[rules=all] {
  border-style: none;
  border-collapse: collapse;
}

table[frame=void] { border-style: hidden hidden hidden hidden; }
table[frame=above] { border-style: solid hidden hidden hidden; }
table[frame=below] { border-style: hidden hidden solid hidden; }
table[frame=hsides] { border-style: solid hidden solid hidden; }
table[frame=lhs] { border-style: hidden hidden hidden solid; }
table[frame=rhs] { border-style: hidden solid hidden hidden; }
table[frame=vsides] { border-style: hidden solid hidden solid; }
table[frame=box],
table[frame=border] { border-style: solid solid solid solid; }

table[rules=none] > tr > td, table[rules=none] > tr > th,
table[rules=none] > thead > tr > td, table[rules=none] > thead > tr > th,
table[rules=none] > tbody > tr > td, table[rules=none] > tbody > tr > th,
table[rules=none] > tfoot > tr > td, table[rules=none] > tfoot > tr > th,
table[rules=groups] > tr > td, table[rules=groups] > tr > th,
table[rules=groups] > thead > tr > td, table[rules=groups] > thead > tr > th,
table[rules=groups] > tbody > tr > td, table[rules=groups] > tbody > tr > th,
table[rules=groups] > tfoot > tr > td, table[rules=groups] > tfoot > tr > th,
table[rules=rows] > tr > td, table[rules=rows] > tr > th,
table[rules=rows] > thead > tr > td, table[rules=rows] > thead > tr > th,
table[rules=rows] > tbody > tr > td, table[rules=rows] > tbody > tr > th,
table[rules=rows] > tfoot > tr > td, table[rules=rows] > tfoot > tr > th {
  border-style: none;
}

table[rules=groups] > colgroup, table[rules=groups] > thead,
table[rules=groups] > tbody, table[rules=groups] > tfoot {
  border-style: solid;
}

table[rules=rows] > tr, table[rules=rows] > thead > tr,
table[rules=rows] > tbody > tr, table[rules=rows] > tfoot > tr {
  border-style: solid;
}

table[rules=cols] > tr > td, table[rules=cols] > tr > th,
table[rules=cols] > thead > tr > td, table[rules=cols] > thead > tr > th,
table[rules=cols] > tbody > tr > td, table[rules=cols] > tbody > tr > th,
table[rules=cols] > tfoot > tr > td, table[rules=cols] > tfoot > tr > th {
  border-style: none solid none solid;
}

table[rules=all] > tr > td, table[rules=all] > tr > th,
table[rules=all] > thead > tr > td, table[rules=all] > thead > tr > th,
table[rules=all] > tbody > tr > td, table[rules=all] > tbody > tr > th,
table[rules=all] > tfoot > tr > td, table[rules=all] > tfoot > tr > th {
  border-style: solid;
}

table[border] > tr > td, table[border] > tr > th,
table[border] > thead > tr > td, table[border] > thead > tr > th,
table[border] > tbody > tr > td, table[border] > tbody > tr > th,
table[border] > tfoot > tr > td, table[border] > tfoot > tr > th {
  border-width: 1px;
}

When rendering li elements, user agents are expected to use the ordinal value of the li element to render the counter in the list item marker.

The table element's border attribute maps to the pixel length properties 'border-top-width', 'border-right-width', 'border-bottom-width', 'border-left-width' on the element. If the attribute is present but parsing the attribute's value using the rules for parsing non-negative integers generates an error, a default value of 1px is expected to be used for that property instead.

The wbr element is expected to override the 'white-space' property and always provide a line-breaking opportunity.

10.2.7 Resetting rules for inherited properties

The following rules are also expected to be in play, resetting certain properties to block inheritance by default.

@namespace url(http://www.w3.org/1999/xhtml);

table, input, select, option, optgroup, button, textarea, keygen {
  text-indent: initial;
}

In quirks mode, the following rules are also expected to apply:

@namespace url(http://www.w3.org/1999/xhtml);

table {
  font-weight: initial;
  font-style: initial;
  font-variant: initial;
  font-size: initial;
  line-height: initial;
  white-space: initial;
  text-align: initial;
}

input { box-sizing: border-box; }

10.2.8 The hr element

@namespace url(http://www.w3.org/1999/xhtml);

hr { color: gray; border-style: inset; border-width: 1px; margin: 0.5em auto; }

The following rules are also expected to apply, as presentational hints:

@namespace url(http://www.w3.org/1999/xhtml);

hr[align=left] { margin-left: 0; margin-right: auto; } /* case-insensitive */
hr[align=right] { margin-left: auto; margin-right: 0; } /* case-insensitive */
hr[align=center] { margin-left: auto; margin-right: auto; } /* case-insensitive */
hr[color], hr[noshade] { border-style: solid; }

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 width attribute on an hr element maps to the dimension property 'width' on the element.

When an hr element has a color 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 'color' property to the resulting color.

10.2.9 The fieldset element

@namespace url(http://www.w3.org/1999/xhtml);

fieldset {
  margin-left: 2px; margin-right: 2px;
  border: groove 2px ThreeDFace;
  padding: 0.35em 0.625em 0.75em;
}

The fieldset element is expected to establish a new block formatting context.

If the fieldset element has a child that matches the conditions in the list below, then the first such child is the fieldset element's rendered legend:

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 represents embedded 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 object element that represents an image, plugin, or nested browsing context is expected to be treated as a replaced element. Other object 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.

When the user agent starts exposing a user interface for a video element, the user agent should run the rules for updating the text track rendering of each of the text tracks in the video element's list of text tracks that are showing or showing by default (e.g., for text tracks based on WebVTT, the rules for updating the display of WebVTT text tracks).

Resizing video and canvas elements does not interrupt video playback or clear the canvas.


The following CSS rules are expected to apply:

@namespace url(http://www.w3.org/1999/xhtml);

iframe:not([seamless]) { border: 2px inset; }
video { object-fit: contain; }

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:

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

  2. Let video be the media element or other playback mechanism.

  3. Let output be an empty list of absolutely positioned CSS block boxes.

  4. If the user agent is exposing a user interface for video, add to output one or more completely transparent positioned CSS block boxes that cover the same region as the user interface.

  5. If the last time these rules were run, the user agent was not exposing a user interface for video, but now it is, let reset be true. Otherwise, let reset be false.

  6. Let tracks be the subset of video's list of text tracks that have as their rules for updating the text track rendering these rules for updating the display of WebVTT text tracks, and whose text track mode is showing or showing by default.

  7. Let cues be an empty list of text track cues.

  8. For each track track in tracks, append to cues all the cues from track's list of cues that have their text track cue active flag set.

  9. If reset is false, then, for each text track cue cue in cues: if cue's text track cue display state has a set of CSS boxes, then add those boxes to output, and remove cue from cues.

  10. For each text track cue cue in cues that has not yet had corresponding CSS boxes added to output, in text track cue order, run the following substeps:

    1. Let nodes be the list of WebVTT Node Objects obtained by applying the WebVTT cue text parsing rules to the cue's text track cue text.

    2. Apply the Unicode Bidirectional Algorithm's Paragraph Level steps to nodes using the following constraints, to determine the paragraph embedding level of the cue: [BIDI]

      • nodes represents a single paragraph.
      • The paragraph's text consists of the concatenation of the values of each WebVTT Text Object in nodes, in a pre-order, depth-first traversal, excluding WebVTT Ruby Text Objects and their descendants.
    3. If the paragraph embedding level determined in the previous step is even (the paragraph direction is left-to-right), let direction be 'ltr', otherwise, let it be 'rtl'.

    4. If the text track cue writing direction is horizontal, then let block-flow be 'tb'. Otherwise, if the text track cue writing direction is vertical growing left, then let block-flow be 'lr'. Otherwise, the text track cue writing direction is vertical growing right; let block-flow be 'rl'.

    5. Determine the value of maximum size for cue as per the appropriate rules from the following list:

      If the text track cue writing direction is horizontal, the text track cue alignment is start, and direction is 'ltr'
      If the text track cue writing direction is horizontal, the text track cue alignment is end, and direction is 'rtl'
      If the text track cue writing direction is vertical growing left, and the text track cue alignment is start
      If the text track cue writing direction is vertical growing right, and the text track cue alignment is start

      Let maximum size be the text track cue text position subtracted from 100.

      If the text track cue writing direction is horizontal, the text track cue alignment is end, and direction is 'ltr'
      If the text track cue writing direction is horizontal, the text track cue alignment is start, and direction is 'rtl'
      If the text track cue writing direction is vertical growing left, and the text track cue alignment is end
      If the text track cue writing direction is vertical growing right, and the text track cue alignment is end

      Let maximum size be the text track cue text position.

      If the text track cue alignment is middle, the text track cue text position is less than or equal to 50

      Let maximum size be the text track cue text position multiplied by two.

      If the text track cue alignment is middle, the text track cue text position is greater than 50

      Let maximum size be the result of subtracting text track cue text position from 100 and then multiplying the result by two.

    6. If the text track cue size is less than maximum size, then let size be text track cue size. Otherwise, let size be maximum size.

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

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

      If the text track cue writing direction is horizontal, the text track cue alignment is start, and direction is 'ltr'
      If the text track cue writing direction is horizontal, the text track cue alignment is end, and direction is 'rtl'

      Let x-position be the text track cue text position.

      If the text track cue writing direction is horizontal, the text track cue alignment is end, and direction is 'ltr'
      If the text track cue writing direction is horizontal, the text track cue alignment is start, and direction is 'rtl'

      Let x-position be the text track cue text position subtracted from 100.

      If the text track cue writing direction is vertical growing left, and the text track cue alignment is start
      If the text track cue writing direction is vertical growing right, and the text track cue alignment is start

      Let y-position be the text track cue text position.

      If the text track cue writing direction is vertical growing left, and the text track cue alignment is end
      If the text track cue writing direction is vertical growing right, and the text track cue alignment is end

      Let y-position be the text track cue text position subtracted from 100.

      If the text track cue writing direction is horizontal, the text track cue alignment is middle, and direction is 'ltr'

      Let x-position be the text track cue text position minus half of size.

      If the text track cue writing direction is horizontal, the text track cue alignment is middle, and direction is 'rtl'

      Let x-position-reverse be the text track cue text position minus half of size.

      Let x-position be x-position-reverse subtracted from 100.

      If the text track cue writing direction is vertical growing left, and the text track cue alignment is middle
      If the text track cue writing direction is vertical growing right, and the text track cue alignment is middle

      Let y-position be the text track cue text position minus half of size.

    9. Determine the value of whichever of x-position or y-position is not yet calculated for cue as per the appropriate rules from the following list:

      If the text track cue writing direction is horizontal, and the text track cue snap-to-lines flag is set

      Let y-position be zero.

      If the text track cue writing direction is horizontal, and the text track cue snap-to-lines flag is not set

      Let y-position be the text track cue line position.

      If the text track cue writing direction is vertical growing left, and the text track cue snap-to-lines flag is set
      If the text track cue writing direction is vertical growing right, and the text track cue snap-to-lines flag is set

      Let x-position be zero.

      If the text track cue writing direction is vertical growing left, and the text track cue snap-to-lines flag is not set
      If the text track cue writing direction is vertical growing right, and the text track cue snap-to-lines flag is not set

      Let x-position be the text track cue line position.

    10. 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]

    11. 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.
      • The viewport (and initial containing block) is video's rendering area.

      Let boxes be the boxes generated as descendants of the initial containing block, along with their positions.

    12. If there are no line boxes in boxes, skip the remainder of these substeps for cue. The cue is ignored.

    13. Adjust the positions of boxes according to the appropriate steps from the following list:

      If cue's text track cue snap-to-lines flag is set

      Many of the steps in this algorithm vary according to the text track cue writing direction. Steps labeled "Horizontal" must be followed only when the text track cue writing direction is horizontal, steps labeled "Vertical" must be followed when the text track cue writing direction is either vertical growing left or vertical growing right, steps labeled "Vertical Growing Left" must be followed only when the text track cue writing direction is vertical growing left, and steps labeled "Vertical Growing Right" must be followed only when the text track cue writing direction is vertical growing right.

      1. Horizontal: Let step be the height of the first line box in boxes.

        Vertical: Let step be the width of the first line box in boxes.

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

      3. Let line position be the text track cue line position.

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

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

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

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

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

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

      10. Let switched be false.

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

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

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

      14. Jump back to the step labeled step loop.

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

      16. If switched is true, jump to the step labeled done positioning below.

      17. Negate step.

      18. Set switched to true.

      19. Jump back to the step labeled step loop.

      If cue's text track cue snap-to-lines flag is not set
      1. Set up x and y as follows:

        If the text track cue writing direction is horizontal, and direction is 'ltr'

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

        If the text track cue writing direction is horizontal, and direction is 'rtl'

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

        If the text track cue writing direction is vertical growing left

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

        If the text track cue writing direction is vertical growing right

        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.

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

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

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

      5. Otherwise, jump to the step labeled done positioning below. (The boxes will unfortunately overlap.)

    14. Done positioning: If there are any line boxes in the (possibly now repositioned) boxes that do not completely fit inside video's rendering area, remove those offending line boxes from boxes.

    15. Let cue's text track cue display state have the CSS boxes in boxes.

    16. Add the CSS boxes in boxes to output.

  11. Return output.

10.3.2.2 Applying CSS properties to WebVTT Node Objects

When following the rules for updating the display of WebVTT text tracks, user agents must set properties of WebVTT Node Objects as defined in this section. [CSS]

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]

The 'background' shorthand property on the WebVTT cue background box must be set to 'rgba(0,0,0,0.8)'. [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:

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 following properties apply to the '::cue()' pseudo-element with an argument:

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

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 Object c 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 Object c.

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

A WebVTT Node Object c 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 Object c.

10.3.3 Images

When an img element or an input element when its type attribute is in the Image Button state represents an image, it is expected to be treated as a replaced element.

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.


The following CSS rules are expected to apply when the Document is in quirks mode:

@namespace url(http://www.w3.org/1999/xhtml);

img[align=left] { margin-right: 3px; } /* case-insensitive */
img[align=right] { margin-left: 3px; } /* case-insensitive */

10.3.4 Attributes for embedded content and images

The following CSS rules are expected to apply as presentational hints:

@namespace url(http://www.w3.org/1999/xhtml);

iframe[frameborder=0], iframe[frameborder=no] { border: none; } /* case-insensitive */

applet[align=left], embed[align=left], iframe[align=left],
img[align=left], input[type=image][align=left], object[align=left] { /* case-insensitive */
  float: left;
}

applet[align=right], embed[align=right], iframe[align=right],
img[align=right], input[type=image][align=right], object[align=right] { /* case-insensitive */
  float: right;
}

applet[align=top], embed[align=top], iframe[align=top],
img[align=top], input[type=image][align=top], object[align=top] { /* case-insensitive */
  vertical-align: top;
}

applet[align=baseline], embed[align=baseline], iframe[align=baseline],
img[align=baseline], input[type=image][align=baseline], object[align=baseline] { /* case-insensitive */
  vertical-align: baseline;
}

applet[align=texttop], embed[align=texttop], iframe[align=texttop],
img[align=texttop], input[type=image][align=texttop], object[align=texttop] { /* case-insensitive */
  vertical-align: text-top;
}

applet[align=absmiddle], embed[align=absmiddle], iframe[align=absmiddle],
img[align=absmiddle], input[type=image][align=absmiddle], object[align=absmiddle],
applet[align=abscenter], embed[align=abscenter], iframe[align=abscenter],
img[align=abscenter], input[type=image][align=abscenter], object[align=abscenter] { /* case-insensitive */
  vertical-align: middle;
}

applet[align=bottom], embed[align=bottom], iframe[align=bottom],
img[align=bottom], input[type=image][align=bottom],
object[align=bottom] { /* case-insensitive */
  vertical-align: bottom;
}

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.

The hspace attribute of applet, embed, iframe, img, or object elements, and input elements with a type attribute in the Image Button state, maps to the dimension properties 'margin-left' and 'margin-right' on the element.

The vspace attribute of applet, embed, iframe, img, or object elements, and input elements with a type attribute in the Image Button state, maps to the dimension properties 'margin-top' and 'margin-bottom' on the element.

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

The width and height attributes on applet, embed, iframe, img, object or video elements, and input elements with a type attribute in the Image Button state, map to the dimension properties 'width' and 'height' on the element respectively.

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]

10.4.2 The button element

@namespace url(http://www.w3.org/1999/xhtml);

button { binding: button; }

When the button binding applies to a button element, the element is expected to render as an 'inline-block' box rendered as a button whose contents are the contents of the element.

10.4.3 The details element

@namespace url(http://www.w3.org/1999/xhtml);

details { binding: details; }

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.

10.4.4 The input element as a text entry widget

@namespace url(http://www.w3.org/1999/xhtml);

input { binding: input-textfield; }
input[type=password] { binding: input-password; } /* case-insensitive */
/* later rules override this for other values of type="" */

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 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 attribute as a presentational hint for the 'width' property on the element, with the value obtained from applying the converting a character width to pixels algorithm to the value of the attribute.

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

10.4.5 The input element as domain-specific widgets

@namespace url(http://www.w3.org/1999/xhtml);

input[type=datetime] { binding: input-datetime; } /* case-insensitive */
input[type=date] { binding: input-date; } /* case-insensitive */
input[type=month] { binding: input-month; } /* case-insensitive */
input[type=week] { binding: input-week; } /* case-insensitive */
input[type=time] { binding: input-time; } /* case-insensitive */
input[type=datetime-local] { binding: input-datetime-local; } /* case-insensitive */
input[type=number] { binding: input-number; } /* case-insensitive */

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.

10.4.6 The input element as a range control

@namespace url(http://www.w3.org/1999/xhtml);

input[type=range] { binding: input-range; } /* case-insensitive */

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.

10.4.7 The input element as a color well

@namespace url(http://www.w3.org/1999/xhtml);

input[type=color] { binding: input-color; } /* case-insensitive */

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.

10.4.8 The input element as a checkbox and radio button widgets

@namespace url(http://www.w3.org/1999/xhtml);

input[type=checkbox] { binding: input-checkbox; } /* case-insensitive */
input[type=radio] { binding: input-radio; } /* case-insensitive */

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.

10.4.9 The input element as a file upload control

@namespace url(http://www.w3.org/1999/xhtml);

input[type=file] { binding: input-file; } /* case-insensitive */

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.

10.4.10 The input element as a button

@namespace url(http://www.w3.org/1999/xhtml);

input[type=submit], input[type=reset], input[type=button] { /* case-insensitive */
  binding: input-button;
}

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.

10.4.11 The marquee element

@namespace url(http://www.w3.org/1999/xhtml);

marquee { binding: marquee; }

When the marquee binding applies to a marquee element, while the element is turned on, the element is expected to render in an animated fashion according to its attributes as follows:

If the element's behavior attribute is in the scroll state

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.

Once the animation has ended, the user agent is expected to increment the marquee current loop index. If the element is still turned on after this, then the user agent is expected to restart the animation.

If the element's behavior attribute is in the slide state

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.

Once the animation has ended, the user agent is expected to increment the marquee current loop index. If the element is still turned on after this, then the user agent is expected to restart the animation.

If the element's behavior attribute is in the alternate state

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.

Once the animation has ended, the user agent is expected to increment the marquee current loop index. If the element is still turned on after this, then the user agent is expected to continue the animation.

The direction attribute has the meanings described in the following table:

direction attribute state Direction of animation Start edge End edge Opposite direction
left ← Right to left Right Left → Left to Right
right → Left to Right Left Right ← Right to left
up ↑ Up (Bottom to Top) Bottom Top ↓ Down (Top to Bottom)
down ↓ Down (Top to Bottom) Top Bottom ↑ Up (Bottom to Top)

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.

The width and height attributes on a marquee element map to the dimension properties 'width' and 'height' on the element respectively.

The intrinsic height of a marquee element with its direction attribute in the up or down states is 200 CSS pixels.

The vspace attribute of a marquee element maps to the dimension properties 'margin-top' and 'margin-bottom' on the element. The hspace attribute of a marquee element maps to the dimension properties 'margin-left' and 'margin-right' on the element.

The 'overflow' property on the marquee element is expected to be ignored; overflow is expected to always be hidden.

10.4.12 The meter element

@namespace url(http://www.w3.org/1999/xhtml);

meter { binding: meter; }

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.

10.4.13 The progress element

@namespace url(http://www.w3.org/1999/xhtml);

progress { binding: progress; }

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.

10.4.14 The select element

@namespace url(http://www.w3.org/1999/xhtml);

select { binding: select; }

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.

When the select binding applies to a select element whose multiple attribute is absent, and the element's display size is 1, the element is expected to render as a one-line drop down box whose width is the width of the select's labels.

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

If a select element contains a placeholder label option, the user agent is expected to render that option in a manner that conveys that it is a label, rather than a valid option of the control. This can include preventing the placeholder label option from being explicitly selected by the user. When the placeholder label option's selectedness is true, the control is expected to be displayed in a fashion that indicates that no valid option is currently selected.

User agents are expected to render the labels in a select in such a manner that any alignment remains consistent whether the label is being displayed as part of the page or in a menu control.

10.4.15 The textarea element

@namespace url(http://www.w3.org/1999/xhtml);

textarea { binding: textarea; white-space: pre-wrap; }

When the textarea binding applies to a textarea element, the element is expected to render as an 'inline-block' box rendered as a multiline text field.

If the element has a cols 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 attribute as a presentational hint for the 'width' property on the element, with the value being the textarea effective width (as defined below). Otherwise, 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 textarea effective width.

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

If the element has a rows 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 attribute as a presentational hint for the 'height' property on the element, with the value being the textarea effective height (as defined below). Otherwise, the user agent is expected to act as if it had a user-agent-level style sheet rule setting the 'height' property on the element to the textarea effective height.

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

10.4.16 The keygen element

@namespace url(http://www.w3.org/1999/xhtml);

keygen { binding: keygen; }

When the keygen binding applies to a keygen element, the element is expected to render as an 'inline-block' box containing a user interface to configure the key pair to be generated.

10.4.17 The time element

@namespace url(http://www.w3.org/1999/xhtml);

time[datetime] { binding: time; }

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:

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

    Use the rules for parsing a list of dimensions to parse the value of the element's cols attribute, if there is one. Let cols be the result, or an empty list if there is no such attribute.

    Use the rules for parsing a list of dimensions to parse the value of the element's rows attribute, if there is one. Let rows be the result, or an empty list if there is no such attribute.

  2. For any of the entries in cols or rows that have the number zero and the unit relative, change the entry's number to one.

  3. If cols has no entries, then add a single entry consisting of the value 1 and the unit relative to cols.

    If rows has no entries, then add a single entry consisting of the value 1 and the unit relative to rows.

  4. Invoke the algorithm defined below to convert a list of dimensions to a list of pixel values using cols as the input list, and the width of the surface that the frameset is being rendered into, in CSS pixels, as the input dimension. Let sized cols be the resulting list.

    Invoke the algorithm defined below to convert a list of dimensions to a list of pixel values using rows as the input list, and the height of the surface that the frameset is being rendered into, in CSS pixels, as the input dimension. Let sized rows be the resulting list.

  5. Split the surface into a grid of w×h rectangles, where w is the number of entries in sized cols and h is the number of entries in sized rows.

    Size the columns so that each column in the grid is as many CSS pixels wide as the corresponding entry in the sized cols list.

    Size the rows so that each row in the grid is as many CSS pixels high as the corresponding entry in the sized rows list.

  6. Let children be the list of frame and frameset elements that are children of the frameset element for which the algorithm was invoked.

  7. For each row of the grid of rectangles created in the previous step, from top to bottom, run these substeps:

    1. For each rectangle in the row, from left to right, run these substeps:

      1. If there are any elements left in children, take the first element in the list, and assign it to the rectangle.

        If this is a frameset element, then recurse the entire frameset layout algorithm for that frameset element, with the rectangle as the surface.

        Otherwise, it is a frame element; create a nested browsing context sized to fit the rectangle.

      2. If there are any elements left in children, remove the first element from children.

  8. If the frameset element has a border, draw an outer set of borders around the rectangles, using the element's frame border color.

    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:

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

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

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

    4. Otherwise, return true.

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

    1. If the element has a bordercolor attribute, and applying the rules for parsing a legacy color value to that attribute's value does not result in an error, then return the color so obtained.

    2. Otherwise, if the element has a parent element that is a frameset element, then the frame border color of that element.

    3. Otherwise, return gray.

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

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

  2. Let input dimension be the size passed to the algorithm.

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

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

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

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

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

10.6 Interactive media

User agents are expected to allow the user to control aspects of hyperlink activation and form submission, such as which browsing context is to be used for the subsequent navigation.

User agents are expected to allow users to discover the destination of hyperlinks and of forms before triggering their navigation.

User agents are expected to allow users to navigate browsing contexts to the resources indicated by the cite attributes on q, blockquote, ins, and del elements.

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.

10.6.2 The title attribute

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:

<p dir="rtl" lang="he">
 <label>
  בחר שפת תכנות:
  <select>
   <option dir="ltr">C++</option>
   <option dir="ltr">C#</option>
   <option dir="ltr">FreePascal</option>
   <option dir="ltr">F#</option>
  </select>
 </label>
</p>

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.

For a more complex example, consider the following script:

/* Warning: this script does not handle right-to-left scripts correctly */
var s;
if (s = prompt('What is your name?')) {
  alert(s + '! Ok, Fred, ' + s + ', and Wilma will get the car.');
}

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:

var s;
if (s = prompt('What is your name?')) {
  alert('\u200E' + s + '! Ok, Fred, ' + s + ', and Wilma will get the car.');
}

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.

When the user actually obtains a physical form (or a representation of a physical form) of a Document, the user agent is expected to create a new rendering of the Document for the print media.