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, "must" has 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 "must".
14.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 has any associated CSS layout boxes, SVG layout
boxes, or some equivalent in other styling languages.
Just being off-screen does not mean the element is not being
rendered. The presence of the hidden attribute normally
means the element is not being rendered, though this might be overridden by the style
sheets.
User agents that do not honor author-level CSS style sheets are nonetheless expected to act as
if they applied the CSS rules given in these sections in a manner consistent with this
specification and the relevant CSS and Unicode specifications. [CSS][UNICODE][BIDI]
14.2 The CSS user agent style sheet and presentational hints
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.
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 a length, and
with the value given as a percentage if the dimension was a percentage.
When the text below says that an attribute attribute on an element
element maps to the dimension property (ignoring zero) (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-zero 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 a length, and
with the value given as a percentage if the dimension was a percentage.
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-inline-start' and
'margin-inline-end' 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.
Aligned elements are expected to be aligned by having the used
values of their margins on the line-left and line-right sides be
set accordingly. [CSSLOGICAL][CSSWM]
@namespace url(http://www.w3.org/1999/xhtml);
html, body { display: block; }
For each property in the table below, given a body element, the first attribute
that exists maps to the pixel length property on the body element. If
none of the attributes for a property are found, or if the value of the attribute that was found
cannot be parsed successfully, then a default value of 8px is expected to be used for that
property instead.
The above requirements imply that a page can change the margins of another page
(including one from another origin) using, for example, an iframe. This
is potentially a security risk, as it might in some cases allow an attack to contrive a situation
in which a page is rendered not as the author intended, possibly for the purposes of phishing or
otherwise misleading the user.
When a 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.
In quirks mode, the following rules are also expected to apply:
@namespace url(http://www.w3.org/1999/xhtml);
form { margin-block-end: 1em; }
The center element, and the div element when it has 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.
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]
When a particular part of a ruby has more than one annotation, the annotations should be
distributed on both sides of the base text so as to minimize the stacking of ruby annotations on
one side.
When it becomes possible to do so, the preceding requirement will be updated to be
expressed in terms of CSS ruby. (Currently, CSS ruby does not handle nested ruby
elements or multiple sequential rt elements, which is how this semantic is
expressed.)
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.
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 the CSS
specification.
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's background is expected to be white.
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.
The font element is expected to
override the color of any text decoration that spans the text of the element to the
used value of the element's 'color' property.
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, known as the rules for
parsing a legacy font size, to treat the attribute as a presentational hint setting the element's 'font-size' property:
Let input be the attribute's value.
Let position be a pointer into input, initially pointing at the
start of the string.
If position is past the end of input, there is no presentational hint. Abort these steps.
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.
The 'xxx-large' value is a non-CSS value used here to
indicate a font size 50% larger than 'xx-large'.
14.3.5 Bidirectional text
@namespace url(http://www.w3.org/1999/xhtml);
[dir]:dir(ltr), bdi:dir(ltr), input[type=tel i]:dir(ltr) { direction: ltr; }
[dir]:dir(rtl), bdi:dir(rtl) { direction: rtl; }
address, blockquote, center, div, figure, figcaption, footer, form, header, hr,
legend, listing, main, p, plaintext, pre, summary, xmp, article, aside, h1, h2,
h3, h4, h5, h6, hgroup, nav, section, table, caption, colgroup, col, thead,
tbody, tfoot, tr, td, th, dir, dd, dl, dt, menu, ol, ul, li, bdi, output,
[dir=ltr i], [dir=rtl i], [dir=auto i] {
unicode-bidi: isolate;
}
bdo, bdo[dir] { unicode-bidi: isolate-override; }
input[dir=auto i]:matches([type=search i], [type=tel i], [type=url i],
[type=email i]), textarea[dir=auto i], pre[dir=auto i] {
unicode-bidi: plaintext;
}
/* see prose for input elements whose type attribute is in the Text state */
/* the rules setting the 'content' property on br and wbr elements also has bidi implications */
When an input element's dir attribute is in the
auto state and its type
attribute is in the Text state, then the user agent is
expected to act as if it had a user-agent-level style sheet rule setting the
'unicode-bidi' property to 'plaintext'.
Input fields (i.e. textarea elements, and input elements when their
type attribute is in the Text, Search,
Telephone, URL,
or E-mail state) are expected to present an editing
user interface with a directionality that matches the element's 'direction'
property.
When the document's character encoding is ISO-8859-8, the following rules are
additionally expected to apply, following those above: [ENCODING]
This block is automatically generated from the Unicode Common Locale Data Repository. [CLDR]
User agents are expected to use either the block below (which will be regularly updated) or to
automatically generate their own copy directly from the source material. The language codes are
derived from the CLDR file names. The quotes are derived from the delimiter
blocks, with fallback handled as specified in the CLDR documentation.
When rendering li elements, non-CSS user agents are expected to use the
ordinal value of the li element to render the counter in the list item
marker.
This specification does not yet define the
CSS-specific rules for rendering li elements, because CSS doesn't yet provide
sufficient hooks for this purpose.
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.
In HTML documents, the following rules are also expected to apply:
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'.
Rules marked "only if border is not equivalent to zero"
in the CSS block above is expected to only be applied if the border attribute mentioned in the selectors for the rule is not
only present but, when parsed using the rules for parsing non-negative integers, is
also found to have a value other than zero or to generate an error.
In quirks mode, a td element or a th element that has a
nowrap attribute but also has a width attribute whose value, when parsed using the rules for
parsing non-zero dimension values, is found to be a length (not an error or a number
classified as a percentage), is expected to have a presentational hint setting the element's 'white-space' property to
'normal', overriding the rule in the CSS block above that sets it to 'nowrap'.
14.3.10 Margin collapsing quirks
A node is substantial if it is a text node
that is not inter-element whitespace, or if it is an element node.
A node is blank if it is an element that contains no
substantial nodes.
In quirks mode, any p element that is the child of a td or th element and has
no substantial following siblings, is expected
to have a user-agent level style sheet rule that sets its 'margin-block-end' property
to zero.
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.
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.
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:
The child is not out-of-flow (e.g. not absolutely positioned or floated).
The child is generating a box (e.g. it is not 'display:none' or 'display:contents').
A fieldset element's rendered legend, if any, is expected to be
rendered over the block-startborder edge of the fieldset
element as a block box (overriding any explicit 'display' value). In the
absence of an explicit inline size, 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
aligned in the inline direction 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
inline-start side. [CSSWM]
A canvas element that representsembedded content is
expected to be treated as a replaced element; the contents of such elements are the
element's bitmap, if any, or else a transparent black bitmap with the same intrinsic
dimensions as the element. Other canvas elements are expected to be treated
as ordinary elements in the rendering model.
An applet element that represents a plugin is expected
to be treated as a replaced element. Other applet elements are expected
to be treated as ordinary elements in the rendering model.
The audio element, when it is exposing a user interface, is expected to be treated as a
replaced element about one line high, as wide as is necessary to expose the user
agent's user interface features. When an audio element is not exposing a user interface, the user agent is expected to force
its 'display' property to compute to 'none', 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 above 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.
User agents are expected to render img elements and input elements
whose type attributes are in the Image Button state, according to the first applicable rules
from the following list:
The user agent is expected to treat the element 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 (if applicable). For input elements, the element
is expected to appear button-like to indicate that the element is a button.
If the element is an img element that represents some text and the
user agent does not expect this to change
The user agent is expected to treat the element as a non-replaced phrasing element whose
content is the text, optionally with an icon indicating that an image is missing, so that the
user can request the image be displayed or investigate why it is not rendering. In non-graphical
contexts, such an icon should be omitted.
If the element is an img element that represents nothing and the
user agent does not expect this to change
The user agent is expected to treat the element as an empty inline element. (In the absence
of further styles, this will cause the element to essentially not be rendered.)
If the element is an input element that does not represent an image and the user agent does not expect this to change
The user agent is expected to treat the element 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 least recent addition to the group.
In other words, when a second image with the same absolute URL and
animated image data is inserted into a document, it jumps to the point in the animation cycle that
is currently being displayed by the first image.
When a user agent is to restart the animation for an img element
showing an animated image, all animated images with the same absolute URL and the
same image data in that img element's node document are expected to restart
their animation from the beginning.
The following CSS rules are expected to apply when the Document is in quirks
mode:
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.
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.
14.5 Widgets
14.5.1 Introduction
The elements defined in this section can be rendered in a variety of manners, within the
guidelines provided below. User agents are encouraged to 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.
The details element is expected to render as a block box. The
element's shadow tree is expected to take the element's first childsummary 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 allow the user to request the details be shown or
hidden.
The second container is expected to be removed from the rendering when the details
element does not have an open attribute.
An input element whose type attribute is in
the Password state is expected to render as an
'inline-block' box depicting a text control that obscures data entry.
If these text controls provide a text selection, then, when the user changes the current
selection, the user agent is expected to queue a task, using the user
interaction task source, to fire an event named
select at the element, with the bubbles attribute initialized to true.
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.)
14.5.5 The input element as domain-specific widgets
An input element whose type attribute is in
the Date state is expected to render as an
'inline-block' box depicting a date control.
An input element whose type attribute is in
the Month state is expected to render as an
'inline-block' box depicting a month control.
An input element whose type attribute is in
the Week state is expected to render as an
'inline-block' box depicting a week control.
An input element whose type attribute is in
the Time state is expected to render as an
'inline-block' box depicting a time control.
An input element whose type attribute is in
the Range state 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.
User agents are expected to use the used value of the 'direction'
property on the element to determine the direction in which the slider operates. Typically, a
left-to-right ('ltr') horizontal control would have the lowest value on the left and the highest
value on the right, and vice versa.
An input element whose type attribute is in
the Color state 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.
14.5.8 The input element as a checkbox and radio button widgets
An input element whose type attribute is in
the Checkbox state is expected to render as an
'inline-block' box containing a single checkbox control, with no label.
An input element whose type attribute is in
the Radio Button state is expected to render as an
'inline-block' box containing a single radio button control, with no label.
An input element whose type attribute is in
the File Upload state is expected to render as an
'inline-block' box containing a span of text giving the file name(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.
An input element whose type attribute is in
the Submit Button, Reset Button, or Button state is expected to render as an
'inline-block' box depicting 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.
The marquee element, while turned on, 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.
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:
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 the element is wider than it is tall (or square), the depiction is expected to be of a
horizontal gauge, with the minimum value on the right if the 'direction' property on
this element has a computed value of 'rtl', and on the left otherwise. When the
element is taller than it is wide, it is expected to depict a vertical gauge, with the minimum
value on the bottom.
User agents are expected to use a presentation consistent with platform conventions for gauges,
if any.
Requirements for what must be depicted in the gauge are
included in the definition of the meter element.
When the
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 be
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 a
"spinner" 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.
A select element whose multiple
attribute is present is expected to render as a multi-select list box.
A select element whose multiple
attribute is absent, and whose display size is greater
than 1, is expected to render as a single-select list box.
When the element renders as a list box, it is expected to render as an
'inline-block' box whose 'height' is the height necessary to contain as
many rows for items as given by the element's display
size, or four rows if the attribute is absent, and whose 'width' is the
width of the select's labels plus the width of a scrollbar.
In either case (list box or drop-down box), the element's items are expected to be the
element's list of options, with the element's
optgroup element children providing headers
for groups of options where applicable.
An optgroup element is expected to be rendered by displaying the element's label attribute.
An option element is expected to be rendered by displaying the element's label, indented under its optgroup element if it
has one.
The width of the select's labels is the wider of the width necessary to
render the widest optgroup, and the width necessary to render the widest
option element in the element's list of
options (including its indent, if any).
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.
The textarea element is expected to render as an 'inline-block' box
depicting a multiline text control. If this multiline text control provides a selection, then,
when the user changes the current selection, the user agent is expected to queue a
task, using the user interaction task source, to fire an event named select
at the element, with the bubbles attribute initialized to
true.
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'.
14.6 Frames and framesets
User agent are expected to render frameset elements as a box with the height and
width of the viewport, with a surface rendered according to the following layout
algorithm:
The cols and rows variables are lists of zero or more pairs consisting
of a number and a unit, the unit being one of percentage, relative, and
absolute.
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.
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.
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.
For each rectangle, if there is an element assigned to that rectangle, and that element
has a border, draw an inner set of borders around that rectangle, using the
element's frame border color.
For each (visible) border that does not abut a rectangle that is assigned a
frame element with a noresize
attribute (including rectangles in further nested frameset elements), the user
agent is expected to allow the user to move the border, resizing the rectangles within, keeping
the proportions of any nested frameset grids.
A frameset or frame element has a border if the
following algorithm returns true:
If the element has a frameborder attribute whose value is not the
empty string and whose first character is either a U+0031 DIGIT ONE (1) character, a U+0079
LATIN SMALL LETTER Y character (y), or a U+0059 LATIN CAPITAL LETTER Y character (Y), then
return true.
Otherwise, if the element has a frameborder attribute, return
false.
Otherwise, if the element has a parent element that is a frameset element,
then return true if that element has a border, and false if it does
not.
Otherwise, return true.
The frame border color of a
frameset or frame element is the color obtained from the following
algorithm:
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.
Otherwise, if the element has a parent element that is a frameset element,
then return the frame border color of that element.
Otherwise, return gray.
The algorithm to convert a list of dimensions to a list of pixel values consists of
the following steps:
Let input list be the list of numbers and units passed to the algorithm.
Let output list be a list of numbers the same length as input list, all
zero.
Entries in output list correspond to the entries in input list that
have the same position.
Let input dimension be the size passed to the algorithm.
Let count percentage be the number of entries in input list whose unit
is percentage.
Let total percentage be the sum of all the numbers in input list whose
unit is percentage.
Let count relative be the number of entries in input list whose unit is
relative.
Let total relative be the sum of all the numbers in input list whose
unit is relative.
Let count absolute be the number of entries in input list whose unit is
absolute.
Let total absolute be the sum of all the numbers in input list whose
unit is absolute.
Let remaining space be the value of input dimension.
If total absolute is greater than remaining space, then for each entry
in input list whose unit is absolute, set the corresponding value in
output list to the number of the entry in input list multiplied by
remaining space and divided by total absolute. Then, set remaining
space to zero.
Otherwise, for each entry in input list whose unit is absolute, set the
corresponding value in output list to the number of the entry in input
list. Then, decrement remaining space by total absolute.
If total percentage multiplied by the input dimension and divided by
100 is greater than remaining space, then for each entry in input list
whose unit is percentage, set the corresponding value in output list to the
number of the entry in input list multiplied by remaining space and
divided by total percentage. Then, set remaining space to zero.
Otherwise, for each entry in input list whose unit is percentage, set the
corresponding value in output list to the number of the entry in input
list multiplied by the input dimension and divided by 100. Then, decrement
remaining space by total percentage multiplied by the input
dimension and divided by 100.
For each entry in input list whose unit is relative, set the corresponding
value in output list to the number of the entry in input list multiplied
by remaining space and divided by total relative.
Return output list.
User agents working with integer values for frame widths (as opposed to user agents that can
lay frames out with subpixel accuracy) are expected to distribute the remainder first to the last
entry whose unit is relative, then equally (not proportionally) to each entry whose unit is
percentage, then equally (not proportionally) to each entry whose unit is absolute,
and finally, failing all else, to the last entry.
The contents of a frame element that does not have a frameset parent
are expected to be rendered as transparent black; the user agent is expected to not render the
nested browsing context in this case, and that nested browsing context
is expected to have a viewport with zero width and zero height.
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 inform the user of whether a hyperlink includes
hyperlink auditing, and to let them know at a minimum which domains will be contacted
as part of such auditing.
User agents may surface hyperlinks created by link
elements in their user interface.
While link elements that create hyperlinks will match the :link or
:visitedpseudo-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.
User agents are expected to expose the advisory information of elements upon user
request, and to make the user aware of the presence of such information.
On interactive graphical systems where the user can use a pointing device, this could take the
form of a tooltip. When the user is unable to use a pointing device, then the user agent is
expected to make the content available in some other fashion, e.g. by making the element a
focusable area and always displaying the advisory information of the currently
focused element, or by showing the advisory information of the elements
under the user's finger on a touch device as the user pans around the screen.
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 glyph 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.
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.
14.7.3 Editing hosts
The current text editing caret (i.e. the active range, if it is empty and in an
editing host), if any, 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.
14.7.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 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. Text from attributes is expected to be rendered in a manner that honours the
directionality of the attribute.
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.
The directionality of attributes depends on the attribute and on the element's dir attribute, as the following example demonstrates. Consider this
markup:
If the abbr attributes are rendered, e.g. in a tooltip or
other user interface, the first will have a left parenthesis (because the direction is 'ltr'),
the second will have a right parenthesis (because the direction is 'rtl'), and the third will
have a right parenthesis (because the direction is determined from the attribute value
to be 'rtl').
In this case, if the user agent were to expose the data-abbr attribute
in the user interface (e.g. in a debugging environment), the last case would be rendered with a
left parenthesis, because the direction would be determined from the element's
contents.
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 behavior 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.');
}
14.8 Print media
User agents are expected to allow the user to request the opportunity to obtain a physical
form (or a representation of a physical form) of a Document. For example,
selecting the option to print a page or convert it to PDF format. [PDF]
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.
14.9 Unstyled XML documents
HTML user agents may, in certain circumstances, find themselves rendering non-HTML documents
that use vocabularies for which they lack any built-in knowledge. This section provides for a way
for user agents to handle such documents in a somewhat useful manner.
A Document is an unstyled document while it matches the following
conditions:
The Document has no author style sheets (whether referenced by HTTP headers, processing instructions, elements like link, inline elements like style, or any other mechanism).
None of the elements in the Document have any registered event listeners.
An unstyled document view is one where the DOM is not rendered according to CSS
(which would, since there are no applicable styles in this context, just result in a wall of
text), but is instead rendered in a manner that is useful for a developer. This could consist of
just showing the Document object's source, maybe with syntax highlighting, or it
could consist of displaying just the DOM tree, or simply a message saying that the page is not a
styled document.
If a Document stops being an unstyled document, then the
conditions above stop applying, and thus a user agent following these requirements will switch to
using the regular CSS rendering.
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 be
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).