Warning:
This wiki has been archived and is now read-only.

DefinitionCompatibility

From HTML WG Wiki
Jump to: navigation, search

Compatibility

The issue of compatibility is an important part of our design principles. It is often raised without careful consideration of what compatibility might mean: as if it can only mean one thing.

We can consider compatibility from two separate angles. First, how do changes to the normative UA processing requirements affect existing content. Second how do additions and modifications to HTML document conformance work with existing UAs.

Like many other issues surrounding HTML, compatibility can affect either semantics or presentation. For the most part UAs are concerned mostly with presentation, however authors and readers are concerned with semantics. This relates to the issue of namespace. For example, the S element could be changed from meaning "text visually styled strike-through text" to "text proposed for deletion." This would have no affect on the presentation in most UAs using default stylesheets. However, it would have a profound impact on semantics. The interoperability of common browsers would present this the same, though that would mask a more serious failure of semantic compatibility.

Compatibility can mean many things and involves balancing all sorts or priorities even before considering other design principles. For example, making a UA compatible with one HTML document may break its compatibility with another HTML document. Making a document compatible with a particular UA may break its compatibility with all of the other UAs. So it can be easy to presume on person is breaking compatibility even when they perceive their work as fixing compatibility. Everyone should keep this in mind when evaluating proposals.

Compatibility with existing content

Compatibility with existing content implies that UA conformance criteria should strive to improve interoperability. Adding new features should leave old features largely untouched. It may often be necessary to introduce new elements and new attributes with entirely new names to avoid breaking the content already deployed on the internet and on LANs throughout the world. Much of the compatibility with existing content can be achieved through HTML5's typical approach to leave existing features alone, except to analyze existing UA processing of those features.

Compatibility with existing UAs

Compatibility with existing UAs is a tricker problem. To be completely compatible with existing UAs, HTML5 would have to avoid introducing any new features to HTML. Even some features from HTML 4.01 have little support from existing UAs (such as LINK and data cell/header cell association). Therefore another important part of the compatibility design principle is to degrade gracefully. Degrading gracefully means that content based on newly introduced features should still convey the same meaning in UAs that do not yet support that feature.

This graceful degradation is effected by several things.

  • Some feature may require more than simply CSS styling or scripting to work (e.g., VIDEO, AUDIO and CANVAS)
  • Even for features that just require CSS styling to work, existing UAs may not always process the content properly to provide those CSS hooks. For example
    • some UAs do not support CSS attribute selectors
    • UAs differ in how they process unknown elements:some treat them:
      • as empty elements on either side of the elements intended content (such as <unknown />some content</unknown />)
      • as elements that need automatic closing by known block elements (such as <heading />

        and a thrown-away </heading>)
      • as useable anywhere (this is the most compatible approach that degrades most gracefully for anything that might be added to HTML5)
  • Newly introduced attributes have the same problems with UA compatibility as newly introduced elements.

HTML UA conformance changes

In considering changes to UA processing, the need likely arises only to improve interoperability for edge-case and error-handling issues. Changes that do not undermine compatibility in this case can be tricky. If all the major browsers agree, then there's no problem: the HTML5 recommendation can simply codify what the major browsers already do. When the major browsers disagree, then changes to advance interoperability can break content that's targeted at the other browsers (the ones not selected for codification).

For example a proposed change to UA conformance for XML processing of the <img> element would not break existing content. However, it still caused many WG members to object to the change in UA conformance criteria.

HTML document conformance changes

In considering HTML language changes, We can identify several levels or categories changes to modifications to HTML that could cause compatibility issues. 

From most severe compatibility problem to least severe compatibility

problem:

  1. no modifications that would break compatibility with existing browsers (i.e., redefine either: <script>, <style>, <title>, <link>, <meta>, <html>,
      ,,
        , , etc. There are also less obvious compatibility-breaking changes such as using a

        in a table which causes problems because of the heroic efforts UAs take to repair ill-formed and even invalid code. Other changes to other content models might have similar negative results. Especially since these are very subtle and very obscure compatibility breaking changes, they are not exposed without careful testing (much of it already performed by WhatWG).
      • no modification that would add an element incapable of behaving as intended within existing browsers (e.g., XHTML2 <handler> element)
        • a) especially if the addition of a new facility was accompanied by the immediate removal of the current means for this behavior
        • b) especially if the addition of a new facility was accompanied by the deprecation of the current means for this behavior
        • c) unless current facilities to accomplish the same results (though perhaps not as easily) are still included in document conformance
      • no modification that would not have a default presentation as intended in existing browsers.
      • no modifications to the HTML that would require a browser to make any changes before claiming 100% full conformance with HTML5. Some in the HTML WG are aiming at (4).

        • Number (4) aside, (3) should not be that big of a concern for us if the facilities were adding are useful for authors and users. I don't have the ability to test this hypothesis, but I would imagine that the number of pages on the web that do not have either a embedded or linked stylesheet must be very small. Those that do exist in any appreciable number must certainly have very utilitarian aims and would not really be candidates for using new HTML5 semantics and therefore would not suffer the problem of having the wrong default presentation. For any other page that wanted to take advantage of new HTML5 semantic elements (this does not include <video> and <audio> and the like their presentation is not merely a matter of properly applied default CSS), we could publish an HTML5 recommended CSS stylesheet under a suitable open source license. Everyone would simply link to their own html5.css. So that is my motivation for listing (3) where I did: these things can be used immediately upon HTML5 reaching recommendation status (if not sooner). The bulk of my phrase element proposed enhancements fall into the category (3). The proposal of <quote> (subject to testing verification) likely has better compatibility than , considering IE does not even present correctly today (and it give authors a way to use in-line quotes across browsers immediately in a HTML5 document conforming way). Most other browsers could even be configured through a publicly available HTML5 default stylesheet to respect the @needsmarks attribute on <quote> (and if we attach it to that element too).

        So any modifications that fall under category (4) nor (3) should be any great concern to us: especially for any proposed facility that really serves authors and users. Level (2) is more complicated. Proposals such as <canvas>, <video>, and <audio> all fall under (2c) Many DOM additions or content attribute additions such as @ping likewise fall under (2c). On the other hand, some XHTML2 proposals fall under (2a) or (2b) and these changes are what that may have given XHTML the reputation for being backwards incompatible. The elimination of <script> from XHTML2 might be considered a level (1) incompatibility: especially if UAs took the removal of <script> in the HTML namespace very seriously (i.e., XHTML UAs stopped recognizing <script>).

        Some of the content model changes like the introduction of structural inline elements to previously strictly inline containing elements causes some sort of incompatibility between the text/html serialization and the xml serialization (though this may be another issue entirely).

        Document conformance compatibility strategies: introducing new facilities with legacy UAs

        Elements

        Existing UAs each handle unknown elements in different ways. For example IE treats all unknown elements as empty self--closing elements with forbidden closing tags. This means that no newly introduced element that is meant to have contents will work in IE. Newly introduced empty elements will work in IE however. Other UAs (Gecko, WebKit, Presto) allow non-empty elements, however another issue is introduced: whether to close elements that have optional close tags such as P. If an element is intended as an strictly inline-level element it should be parsed as a child of a paragraph element. However, if the UA presumes any unknown element is instead block-level, it will close the P element and not permit the unknown element as a child or P.

        In part this is do to minimizations in HTML syntax such as the optional omission of the P close tag (i.e., including "</p>" is unnecessary). However, the approach also gets extended to other elements that do not have optional closing tags to deal with author ill-formedness errors (i.e., the UA presumes an ill-formedness error even when none exists).

        So adding new elements to HTML5 provides little compatibility with existing UAs. With IE, even styling of newly added attributes is not possible until IE updates to HTML5 conformance. With other UAs (e.g., Firefox), the addition of unknown block-level elements will not necessarily wrap the elements it contains because the UA will presume the unknown element should not contain other block-level elements.

        DOM attribute and methods

        Newly added DOM attributes and DOM methods would both require updates to existing UAs.

        Markup attribute

        Markup attributes will be recognized by most existing UAs and added to the DOM in the appropriate way.

        Foreign namespaces in text/html

        UAs have some foreign namespace capabilities using arbitrary prefixed elements like <prefix:non-html-element>.

        UAs vary in how the namespace prefixes relate to foreign namespace xmlns:URI declarations.

        XML element

        Some UAs support an element named XML that supports the processing of XML from namespaces foreign to HTML.

        Degrading gracefully

        The introduction of new elements will likely break compatibility with existing UAs. Newly introduced empty elements will be the most backwards compatible. Strictly inline-level elements introduced will be backwards compatible with most existing UAs (other than IE). The introduction of elements or markup attributes that require more than default styling by a UA: in other words those that have additional behavior like interactive elements or embedded content elements will not be backwards compatible with existing UAs. In that case, the use of these elements should degrade gracefully in existing UAs. In other words some fallback mechanism or the like is needed to ensure that the content can be used for HTML5 UAs, but will provide meaningful content for users of non-HTML5 UAs.

        Related Resources

        Email Threads

        On the question of compatibility

        Namespace

        extracting semantics

        Structuralism or non-presentationalism principle

        Small print is not a good idea Re: Namespace

        See also
Retrieved from "https://www.w3.org/html/wg/wiki/index.php?title=DefinitionCompatibility&oldid=4764"