ThoughtExperimentInGracefulDegradation

From HTML WG Wiki
Jump to: navigation, search

Thought experiment in graceful degradation

HTML5, in part, introduces new semantics to HTML that are meant to be expressed though new elements and new attributes. However, unlike XML processors, legacy HTML UAs do not handle unknown elements in the same ways. Therefore one goal for HTML5 might be to specify how HTML5 UAs should handled unknown elements and attributes: particularly in how they should be tokenized, parsed and added to the DOM. However, in the meantime, it is worth considering the ways current UAs process unknown elements and attributes and how that might effect the possibilities for newly introduced facilities to degrade gracefully.

The point of this page is not to discourage the introduction of new elements when those new elements would be useful. Such new elements will work iin HTML5 UAs and work partially or even fully with XML UAs. However, where the semantics really do fit well with an existing element, perhaps the addition of an attribute or attribute value is the better way to go. Perhaps the addition of an attribute for legacy browsers and the addition of new elements for HTML5 UAs is a feasible approach. That way many years down the road, the new elements might work with all current UAs and authors will be able to make full use of those new elements. It might also be useful to consider how much is lost and how much is gained in introducing a new element when compared with a more focussed use of an existing element.

Current browsers

This table shows how the latest versions of current browsers handle unknown elements and attributes. Presumably if the browser recognizes unknown elements and attributes and adds them to the DOM they can be styled using an author stylesheet. However, some browsers treat unknown elements as void elements (always empty with the closing tag forbidden) or as elements terminated by a block-level element (as if they're a an errant inline element that should be implicitly closed by a new block-level element). Also many browsers move unknown elements from the head to the body or from the body to the head. ThisIsAVoidBodyElement'%3E%0A%09%3Cp%3EA%20paragraph%20with%20%3Cunknownphrase%3Ea%20phrase%3C%2Funknownphrase%3E%20to%20make%20sure%20it%20doesn't%20impliitly%20close%20the%20p%20element.%3C%2Fp%3E%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E%0AThis Live DOM Viewer permalink provides a test of some basic element types.

  • F = full DOM support
  • V = treated as a void element (no contents like <img>)
  • N = treated as a non-void element (any content like
    )
  • I = treated as an inline only non-void element (i.e., it is implicitly closed by a trailing block element like a cross between

    and )

  • B = moved from head to body
  • H = moved from body to head
  • C = CSS attribute selector support
unknown element unknown
attribute
CSS
in head in body
iCab V*
Gecko V* I F C
KHTML
Presto V** N F C
Trident V V F C
WebKit N,B*** N F C
  • * Gecko and iCab expect unknown elements in the head to be void elements. The contents of any non-void elements and any remaining unknown elements (void or not) are moved to the body.
  • ** Presto expects unknown elements in the head to be void elements. The contents of any non-void elements and any remaining elements (void or not, known or unknown) are moved to the body.
  • *** WebKit presumes all elements are non-void elements and that they should all be part of the body.

Browser test results

These results indicate that void elements would most likely degrade the most gracefully in all browsers. Void elements in the body could also include a closing tag without serious problems in current browsers and this would ensure that the elements was treated as empty by browsers other than IE. Aside from IE, the other browsers handle phrase elements adequately. Safari's approach to unknown elements in the document body is probably the most flexible since even with an explicit close tag, it can handle empty elements and it can also handle phrase or block-level elements in the body. Adopting the same approach to elements in the head would provide the greatest forward compatibility for newly introduced elements. Unknown element testing within table elements, form elements and list elements might also be advised.

Newly introduced attributes

Since all of the major browsers handle unknown attributes by adding them to the DOM appropriately.

Newly introduced elements

This table explores how the semantics enabled through newly introduced elements — that will be parsed differently in legacy browsers — might instead be handled through the introduction of a 'type' attribute and then styled through standard CSS2 element and attribute selectors. The danger in this approach is that it lowers the incentive for authors and implementors to move to new elements. However, this approach does allow newly introduced semantics to degrade gracefully in non-HTML5 UAs and even given the authors the opportunity to style these semantics as desired in UAs supporting CSS.

RSH = Requires special handling beyond simple stylesheets

Editor proposed semantics
Element RSH Block context Inline context Comment
AddedElementVideo: video Y OBJECT@type='video/*'
AddedElementAudio: audio Y OBJECT@type='audio/*'
AddedElementCanvas: canvas Y OBJECT@type='application/x-canvas' or 'image/x-canvas'
AddedElementEmbed: embed Y OBJECT@type='*/*' important for UA conformance criteria, but not necessary for document conformance criteria
AddedElementSection: section DIV@type='section' N/A The sectioning elements would require special UA handling to apply the table-of-contents algorithm.
AddedElementArticle: article DIV@type='article' N/A
AddedElementHeader: header DIV@type='header' N/A
AddedElementFooter: footer DIV@type='footer' N/A
AddedElementAside: aside DIV@type='aside' N/A
AddedElementNav: nav DIV@type='nav' N/A
[[AddedElementFigure: figure > legend]] TABLE@type='figure' > caption A one-cell table with caption indicating itself as a figure.
p DIV@type='p' N/A with the new structured-inline content model
AddedElementM: m N/A SPAN@type='marker'
AddedElementMeter: meter Y
AddedElementProgress: progress Y
AddedElementTime: time Y
AddedElementCommand: command Y
AddedElementEventsource: event-source Y
AddedElementDetails: details Y
AddedElementDatagrid: datagrid Y
AddedElementDialog: dialog DL@type='dialog' N/A
ChangedElementMenu: menu Y adding the attributes to the 'select' element may be a more consistent approach, though as a formerly deprecated element, it should parse properly
AddedElementDatalist: datalist Y this too might be better treated as merely a presentationally (and slightly behaviorally) unique variant of 'select'
AddedElementOutput: output Y this too might be better treated as merely a presentationally (and slightly behaviorally) unique variant of '<input readonly>
WG proposed semantics
Element RSH Block context Inline context Comment
LongdescRetention#head-1d6f039a0cb590a0bf9f7e2608c8b6f548b0300e: picture Y OBJECT@type='image/*'
AbbrAndInitialisms#head-f8059d3b02de8226db5def28fc6b69a52939d034: iabbr Partial N/A may work with adding attributes to ABBR
DefiningTermsEtc#head-63d194b1518481f9fa334d3bff07ca050ae4ad85: define Partial DIV@type='define' SPAN@type=define'
DefiningTermsEtc#head-63d194b1518481f9fa334d3bff07ca050ae4ad85: term Partial N/A SPAN@type='term'
DefiningTermsEtc#head-63d194b1518481f9fa334d3bff07ca050ae4ad85: propern Partial N/A SPAN@type='propern'
AttrtibuCitaQuotationReferencing#head-c70ffafe7295e26ede0cbeb45ae64cfc4a2de9dd: reference list UL|OL|DL@type='reference-list'
AttrtibuCitaQuotationReferencing#head-c70ffafe7295e26ede0cbeb45ae64cfc4a2de9dd: reference item Partial DT/DD@type='reference-item' N/A
ABetterAlt: alt UL|OL@type='alternate' OR DIV@type='alternate'
Subtext: subtext (CSS3) DIV@type='subtext' SPAN@type=subtext' to support semantics for newly introduced CSS3 styling
Subtext: bmark (CSS3) N/A A@type='bmark' [or simply an empty anchor]
KeyBindingMarkup: access Y N/A (void head element) A key binding mechanism that could be handled by adding its attributes to the elements: 'select', 'menu', 'command', 'optgroup', 'option' or perhaps 'meta'
tlead Y N/A (table element) for a leading heading table column group
ttrail Y N/A (table element) for a trailing heading table column group
table summary cell Y N/A (table element) Or a TS element to compliment the TH element
XHTML2 semantics
Element RSH Block context Inline context Comment
handler Y N/A (head element)
h DIV@type='h' N/A
l N/A SPAN@type='line'
blockcode CODE@type='block' OR CODE@layout='relevant' N/A
section DIV@type='section' N/A The sectioning elements would require special UA handling to apply the table-of-contents algorithm.
access Y N/A (void head element) A key binding mechanism that could be handled by adding its attributes to the elements: 'select', 'menu', 'command', 'optgroup', 'option' or perhaps 'meta'

Specifying HTML5 parsing rules for unknown elements

The approach that would allow the most flexibility in evolving HTML's semantics is the one taken by WebKit for unknown body elements. If this same approach was applied to unknown elements in the head element (instead WebKit moves all unknown elements to the body) and this approach was employed by all browsers, adding new semantics to HTML5 would be immediately backwards compatible with only stylesheet changes. For replaced elements such as form controls and embedded content, obviously more would be required from browsers for full support. However, the new semantics would degrade gracefully.

Using namespaces for graceful degradation

Microsoft defines a method to use namespaces within HTML even in the text/html serialization. This may also be a way to define new elements with some level of graceful degradation.

<html xml:lang='en' 
      xmlns='http://www.w3.org/1999/xhtml'
      xmlns:html5='http://www.w3.org/1999/xhtml'
>

Then authors can use 'html5' as a prefix for newly introduced html5 elements and have them still work for older browsers. For browsers other than IE, the browsers will often handle those elements as non-namespaced elements (ignoring the namespace declarations) that happen to contain a colon within their name. Even in IE, the prefix and the colon and the local name all comprise the tagname (need to verify this).

ThisIsAVoidBodyElement'%2F%3E%0A%09%3Cp%3EA%20paragraph%20with%20%3Chtml5%3Aunknownphrase%3Ea%20phrase%3C%2Fhtml5%3Aunknownphrase%3E%20to%20make%20sure%20it%20doesn't%20impliitly%20close%20the%20p%20element.%3C%2Fp%3E%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E Live DOM Viewer with prefixed elements

ThisIsAVoidBodyElement'%2F%3E%0A%09%3Cp%3EA%20paragraph%20with%20%3Chtml5%3Aunknownphrase%3Ea%20phrase%3C%2Fhtml5%3Aunknownphrase%3E%20to%20make%20sure%20it%20doesn't%20impliitly%20close%20the%20p%20element.%3C%2Fp%3E%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E Live DOM Viewer with prefixed elements and no declarations (for comparison to see if IE handles things any differently for things such as CSS selectors and getElementByTagnameNS and getElementByTagname methods).

See also

Retrieved from "http://www.w3.org/html/wg/wiki/index.php?title=ThoughtExperimentInGracefulDegradation&oldid=1784"