10.5. Bindings

10.5.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.5.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.5.4 The input element as a text entry widget

@namespace url(http://www.w3.org/1999/xhtml);input { binding: input-textfield; }input[type=password i] { binding: input-password; }/* 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.5.5 The input element as domain-specific widgets

@namespace url(http://www.w3.org/1999/xhtml);input[type=datetime i] { binding: input-datetime; }input[type=date i] { binding: input-date; }input[type=month i] { binding: input-month; }input[type=week i] { binding: input-week; }input[type=time i] { binding: input-time; }input[type=datetime-local i] { binding: input-datetime-local; }input[type=number i] { binding: input-number; }

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.5.6 The input element as a range control

@namespace url(http://www.w3.org/1999/xhtml);input[type=range i] { binding: input-range; }

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.

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.

10.5.7 The input element as a color well

@namespace url(http://www.w3.org/1999/xhtml);input[type=color i] { binding: input-color; }

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.5.8 The input element as a checkbox and radio button widgets

@namespace url(http://www.w3.org/1999/xhtml);input[type=checkbox i] { binding: input-checkbox; }input[type=radio i] { binding: input-radio; }

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.5.9 The input element as a file upload control

@namespace url(http://www.w3.org/1999/xhtml);input[type=file i] { binding: input-file; }

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.5.10 The input element as a button

@namespace url(http://www.w3.org/1999/xhtml);input[type=submit i], input[type=reset i], input[type=button i] {  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.5.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:

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

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 "1" (U+0031) character, a "y" (U+0079) character, or a "Y" (U+0059) character, 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.7 Interactive media

10.7.1 Links, forms, and navigation

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.7.2 The title attribute

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

"LF" (U+000A) characters are expected to cause line breaks in the tooltip; "tab" (U+0009) 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.

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

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

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

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 "LF" (U+000A) 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.

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

/* 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.');}

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

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

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

While a Document is an unstyled document, the user agent is expected to render an unstyled document view.

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 presentational hints.
• None of the elements in the Document have any CSS styling attributes.
• None of the elements in the Document are in any of the following namespaces: HTML namespace, SVG namespace, MathML namespace
• The Document has no focusable elements (e.g. from XLink).
• The Document has no hyperlinks (e.g. from XLink).
• There exists no script whose document is this Document.
• 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 thes a user agent following these requirements will switch to using the regular CSS rendering.