https://www.w3.org/TR/html-design-principles/
W3C
HTML Design Principles
W3C Working Draft 26 November 2007
This Version:
http://www.w3.org/TR/2007/WD-html-design-principles-20071126/
Latest Version:
http://www.w3.org/TR/html-design-principles/
Editors:
Anne van Kesteren (Opera Software ASA)
Maciej Stachowiak (Apple Inc)
Copyright (c) 2007 W3C^(r) (MIT, ERCIM, Keio), All Rights Reserved. W3C
liability, trademark and document use rules apply.
---------------------------------------------------------------------
Abstract
HTML 5 defines the fifth major revision of the core language of the
World Wide Web, HTML. This document describes the set of guiding
principles used by the HTML Working Group for the development of
HTML5. The principles offer guidance for the design of HTML in the
areas of compatibility, utility and interoperability.
Status of this Document
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical
report can be found in the W3C technical reports index at http://
www.w3.org/TR/.
This document is the First Public Working Draft of "HTML Design
Principles" produced by the HTML Working Group, part of the HTML
Activity. The Working Group intends to publish this document as a
Working Group Note. The working group is working on a new version of
HTML not yet published under TR. In the meantime, you can access the
HTML 5 Editor's draft. The appropriate forum for comments on this
document is public-html-comments@w3.org, a mailing list with a public
archive.
The decision to request publication of the document was based on a
poll of the members of the HTML working group, with the results being
51 "Yes" votes, 2 "No" votes, and 1 "Formally Object", vote.
The specific objection recorded was judged to fall under the category
of a comment that can be addressed in future drafts -- not a critical
reason to delay publication, and with the understanding that full
consensus is not a prerequisite to publication, because the decision
of the HTML working group to publish the document reflects the intent
of the group to signal to the community to begin carefully reviewing
the document, and to encourage wide review of the document within and
outside of W3C.
Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite
this document as other than work in progress.
This document was produced by a group operating under the 5 February
2004 W3C Patent Policy. The group does not expect this document to
become a W3C Recommendation. W3C maintains a public list of any
patent disclosures made in connection with the deliverables of the
group; that page also includes instructions for disclosing a patent.
An individual who has actual knowledge of a patent which the
individual believes contains Essential Claim(s) must disclose the
information in accordance with section 6 of the W3C Patent Policy.
Table of Contents
* 1. Introduction
+ 1.1. Conformance for Documents and Implementations
* 2. Compatibility
+ 2.1. Support Existing Content
o 2.1.1. Examples
+ 2.2. Degrade Gracefully
o 2.2.1. Examples
+ 2.3. Do not Reinvent the Wheel
+ 2.4. Pave the Cowpaths
+ 2.5. Evolution Not Revolution
* 3. Utility
+ 3.1. Solve Real Problems
+ 3.2. Priority of Constituencies
+ 3.3. Secure By Design
+ 3.4. Separation of Concerns
+ 3.5. DOM Consistency
* 4. Interoperability
+ 4.1. Well-defined Behavior
+ 4.2. Avoid Needless Complexity
+ 4.3. Handle Errors
* 5. Universal Access
+ 5.1. Media Independence
+ 5.2. Support World Languages
+ 5.3. Accessibility
* Acknowledgments
1. Introduction
In the HTML Working Group, we have representatives from many
different communities, including the WHATWG and other W3C Working
Groups. The HTML 5 effort under WHATWG, and much of the work on
various W3C standards over the past few years, have been based on
different goals and different ideas of what makes for good design. To
make useful progress, we need to have some basic agreement on goals
for this group.
These design principles are an attempt to capture consensus on design
approach. They are pragmatic rules of thumb that must be balanced
against each other, not absolutes. They are similar in spirit to the
TAG's findings in Architecture of the World Wide Web, but specific to
the deliverables of this group.
1.1. Conformance for Documents and Implementations
Many language specifications define a set of conformance requirements
for valid documents, and corresponding conformance requirements for
implementations processing these valid documents. HTML 5 is somewhat
unusual in also defining implementation conformance requirements for
many constructs that are not allowed in conforming documents.
This dual nature of the spec allows us to have a relatively clean and
understandable language for authors, while at the same time
supporting existing documents that make use of older or nonstandard
constructs, and enabling better interoperability in error handling.
Some of the design principles below apply much more to the
conformance requirements for content (the "conforming language")
while others apply much more to the conformance requirements for
implementations (the "supported language"). Since the supported
language is a strict superset of the conforming language, there is
considerable overlap, but the principles will do their best to make
clear which set of requirements they apply to.
2. Compatibility
There are many ways of interpreting compatibility. Sometimes the
terms "backwards compatibility" and "forwards compatibility" are
used, but sometimes the meaning of those terms can be unclear. The
principles in this section address different facets of compatibility.
2.1. Support Existing Content
This principle applies primarily to the supported language.
Existing content often relies upon expected user agent processing and
behavior to function as intended. Processing requirements should be
specified to ensure that user agents implementing this specification
will be able to handle most existing content. In particular, it
should be possible to process existing HTML documents as HTML 5 and
get results that are compatible with the existing expectations of
users and authors, based on the behavior of existing browsers. It
should be made possible, though not necessarily required, to do this
without mode switching.
Content relying on existing browser behavior can take many forms. It
may rely on elements, attributes or APIs that are part of earlier
HTML specifications, but not part of HTML 5, or on features that are
entirely proprietary. It may depend on specific error handling rules.
In rare cases, it may depend on a feature from earlier HTML
specifications not being implemented as specified.
When considering changes to legacy features or behavior, relative to
current implementations and author expectations, the following
questions should be considered:
* Does a significant quantity of existing content depend on the
feature or behavior?
* Does any of the dependent content occur on particularly popular
websites?
* Is the dependent content genuinely intended for consumption,
rather than occurring solely in test cases or examples?
* Is the dependent content on the public web, rather than found
solely on internal sites with a controlled user environment?
* Does the dependent content currently work as intended in multiple
popular user agents, rather than explicitly targeting only one
particular user agent, or only very old or otherwise unpopular
ones?
The benefit of the proposed change should be weighed against the
likely cost of breaking content, as measured by these criteria. In
some cases, it may be desirable to make a nonstandard feature or
behavior part of the conforming language, if it satisfies a valid use
case. However, the fact that something is part of the supported
language does not by itself mean that relying on it is condoned or
encouraged.
2.1.1. Examples
Many sites use broken markup, such as badly nested elements (ab
c), and both authors and users have expectations based on the
error handling used by legacy user agents. We need to define
processing requirements that remain compatible with the expected
handling of such content.
Some sites rely on the element giving the presentational effect
of an underline.
2.2. Degrade Gracefully
This principle applies primarily to the conforming language.
On the World Wide Web, authors are often reluctant to use new
language features that cause problems in older user agents, or that
do not provide some sort of graceful fallback. HTML 5 document
conformance requirements should be designed so that Web content can
degrade gracefully in older or less capable user agents, even when
making use of new elements, attributes, APIs and content models.
It is not necessarily appropriate to consider every Web user agent
ever made, including even very old versions of browsers or tools that
are extremely unpopular even in their niche markets. However, strong
consideration should be given to the following categories of user
agents. It is highly likely that content authors will find it
important to target these categories:
* Current versions of the top mainstream Web browsers.
* Highly popular older versions of mainstream Web browsers.
* The top user agents designed to meet specific needs or address
specialized markets, such as assistive technologies, mobile
browsers or user agents targeting less typical media such as
text-only terminals or print.
In some cases, a new feature may simply not apply to a certain class
of user agents, or may be impractical to design in a way that can
degrade. For example, new scripting APIs cannot be made to work in
scriptless user agents. But in many cases, approaches like the
following can be used:
* A new element or attribute may provide additional semantics
without losing essential functionality when not understood.
* A new scripting method or attribute can be tested before use in
script using ECMAScript introspection facilities.
* A new element or attribute may provide semantics and a simple
default rendering that can be achieved using CSS, so addition of
a small stylesheet allows graceful degradation.
* A new element, attribute or scripting API may have behavior that
can be emulated through the use of additional script, although
the scripted approach may not provide the same level of
performance and convenience.
* A new element may call for a highly specialized rendering, but
allow different content to be provided as fallback for user
agents that do not understand the element.
This list is not exhaustive; in some cases slightly more complicated
approaches are more effective.
2.2.1. Examples
The default presentation of the proposed irrelevant attribute can be
emulated through the CSS rule [irrelevant] { display: none; }.
Proposed new multimedia elements like or
allow fallback content. Older user agents
will show "fallback" while user agents supporting canvas or video
will show the multimedia content.
The proposed getElementsByClassName() method can be made considerably
faster than pure ECMAScript implementations found in existing
libraries, but a script-based implementation can be used when the
native version is not available.
The