You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
613 lines
28 KiB
613 lines
28 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
|
|
<html lang=en-US>
|
|
<head>
|
|
<title>HTML Design Principles</title>
|
|
|
|
<style type="text/css">
|
|
.example { padding-left: 1em; border-left: 3px solid green }
|
|
.note { font-style: italic; }
|
|
dfn { font-style:normal; font-weight:bold }
|
|
code { color:orangered }
|
|
code :link, code :visited { color:inherit }
|
|
pre code { color:inherit }
|
|
</style>
|
|
<link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel=stylesheet>
|
|
|
|
<body>
|
|
<div class=head>
|
|
<p><a href="http://www.w3.org/"><img alt=W3C height=48
|
|
src="http://www.w3.org/Icons/w3c_home" width=72></a></p>
|
|
|
|
<h1 id=html-design-principles>HTML Design Principles</h1>
|
|
|
|
<h2 class="no-num no-toc" id=w3c-doctype>W3C Working Draft 26 November
|
|
2007</h2>
|
|
|
|
<dl>
|
|
<dt>This Version:</dt>
|
|
<!--<dd>$Revision: 1.1 $ of $Date: 2007/11/26 10:46:03 $
|
|
(<a href="http://dev.w3.org/cvsweb/html5/html-design-principles/Overview.html">revision
|
|
log</a>)</dd>-->
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2007/WD-html-design-principles-20071126/">http://www.w3.org/TR/2007/WD-html-design-principles-20071126/</a>
|
|
|
|
<dt>Latest Version:</dt>
|
|
<!--<dd><a href="http://www.w3.org/html/wg/html5/principles/">http://www.w3.org/html/wg/html5/principles/</a></li>-->
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/html-design-principles/">http://www.w3.org/TR/html-design-principles/</a>
|
|
|
|
<dt>Editors:
|
|
|
|
<dd><a href="http://annevankesteren.nl/">Anne van Kesteren</a> (<a
|
|
href="http://www.opera.com/">Opera Software ASA</a>) <<a
|
|
href="mailto:annevk@opera.com">annevk@opera.com</a>>
|
|
|
|
<dd>Maciej Stachowiak (<a href="http://www.apple.com/">Apple Inc</a>)
|
|
<<a href="mailto:mjs@apple.com">mjs@apple.com</a>>
|
|
</dl>
|
|
|
|
<p class=copyright><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
|
|
© 2007 <a href="http://www.w3.org/"><abbr title="World Wide Web
|
|
Consortium">W3C</abbr></a><sup>®</sup> (<a
|
|
href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of
|
|
Technology">MIT</abbr></a>, <a href="http://www.ercim.org/"><abbr
|
|
title="European Research Consortium for Informatics and
|
|
Mathematics">ERCIM</abbr></a>, <a
|
|
href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
|
|
and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> rules apply.</p>
|
|
</div>
|
|
|
|
<hr>
|
|
|
|
<h2 class="no-num no-toc" id=abstract>Abstract</h2>
|
|
|
|
<p>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.
|
|
|
|
<h2 class="no-num no-toc" id=sotd>Status of this Document</h2>
|
|
|
|
<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports
|
|
index</a> at http://www.w3.org/TR/.</em>
|
|
|
|
<p>This document is the First Public Working Draft of "HTML Design
|
|
Principles" produced by the <a href="http://www.w3.org/html/wg/">HTML
|
|
Working Group</a>, part of the <a
|
|
href="http://www.w3.org/MarkUp/Activity">HTML Activity</a>. The Working
|
|
Group intends to publish this document as a <a
|
|
href="http://www.w3.org/2005/10/Process-20051014/#WGNote">Working Group
|
|
Note</a>. The working group is working on a new version of HTML not yet
|
|
published under TR. In the meantime, you can access the <a
|
|
href="http://www.w3.org/html/wg/html5/">HTML 5 Editor's draft</a>.
|
|
The appropriate forum for comments on this document is <a
|
|
href="mailto:public-html-comments@w3.org">public-html-comments@w3.org</a>,
|
|
a mailing list with a <a
|
|
href="http://lists.w3.org/Archives/Public/public-html-comments/"
|
|
title="Archive for HTML comments mailing-list">public archive</a>.
|
|
|
|
<p>The decision to request publication of the document was based on a <a
|
|
href="http://www.w3.org/2002/09/wbs/40318/wdhdp/results">poll of the
|
|
members of the HTML working group</a>, with the results being 51 "Yes"
|
|
votes, 2 "No" votes, and 1 "Formally Object", vote.
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<p>This document was produced by a group operating under the <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February
|
|
2004 W3C Patent Policy</a>. The group does not expect this document to
|
|
become a W3C Recommendation. W3C maintains a <a
|
|
href="http://www.w3.org/2004/01/pp-impl/40318/status"
|
|
rel=disclosure>public list of any patent disclosures</a> 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 <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
|
|
Claim(s)</a> must disclose the information in accordance with <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
|
|
6 of the W3C Patent Policy</a>.
|
|
|
|
<h2 class="no-num no-toc" id=toc>Table of Contents</h2>
|
|
<!--begin-toc-->
|
|
|
|
<ul class=toc>
|
|
<li><a href="#introduction"><span class=secno>1. </span>Introduction</a>
|
|
<ul class=toc>
|
|
<li><a href="#conformance"><span class=secno>1.1. </span>Conformance for
|
|
Documents and Implementations</a>
|
|
</ul>
|
|
|
|
<li><a href="#compatibility"><span class=secno>2. </span>Compatibility</a>
|
|
|
|
<ul class=toc>
|
|
<li><a href="#support-existing-content"><span class=secno>2.1.
|
|
</span>Support Existing Content</a>
|
|
<ul class=toc>
|
|
<li><a href="#examples"><span class=secno>2.1.1. </span>Examples</a>
|
|
</ul>
|
|
|
|
<li><a href="#degrade-gracefully"><span class=secno>2.2. </span>Degrade
|
|
Gracefully</a>
|
|
<ul class=toc>
|
|
<li><a href="#examples0"><span class=secno>2.2.1. </span>Examples</a>
|
|
</ul>
|
|
|
|
<li><a href="#do-not-reinvent-the-wheel"><span class=secno>2.3.
|
|
</span>Do not Reinvent the Wheel</a>
|
|
|
|
<li><a href="#pave-the-cowpaths"><span class=secno>2.4. </span>Pave the
|
|
Cowpaths</a>
|
|
|
|
<li><a href="#evolution-not-revolution"><span class=secno>2.5.
|
|
</span>Evolution Not Revolution</a>
|
|
</ul>
|
|
|
|
<li><a href="#utility"><span class=secno>3. </span>Utility</a>
|
|
<ul class=toc>
|
|
<li><a href="#solve-real-problems"><span class=secno>3.1. </span>Solve
|
|
Real Problems</a>
|
|
|
|
<li><a href="#priority-of-constituencies"><span class=secno>3.2.
|
|
</span>Priority of Constituencies</a>
|
|
|
|
<li><a href="#secure-by-design"><span class=secno>3.3. </span>Secure By
|
|
Design</a>
|
|
|
|
<li><a href="#separation-of-concerns"><span class=secno>3.4.
|
|
</span>Separation of Concerns</a>
|
|
|
|
<li><a href="#dom-consistency"><span class=secno>3.5. </span>DOM
|
|
Consistency</a>
|
|
</ul>
|
|
|
|
<li><a href="#interoperability"><span class=secno>4.
|
|
</span>Interoperability</a>
|
|
<ul class=toc>
|
|
<li><a href="#well-defined-behavior"><span class=secno>4.1.
|
|
</span>Well-defined Behavior</a>
|
|
|
|
<li><a href="#avoid-needless-complexity"><span class=secno>4.2.
|
|
</span>Avoid Needless Complexity</a>
|
|
|
|
<li><a href="#handle-errors"><span class=secno>4.3. </span>Handle
|
|
Errors</a>
|
|
</ul>
|
|
|
|
<li><a href="#universal-access"><span class=secno>5. </span>Universal
|
|
Access</a>
|
|
<ul class=toc>
|
|
<li><a href="#media-independence"><span class=secno>5.1. </span>Media
|
|
Independence</a>
|
|
|
|
<li><a href="#support-world-languages"><span class=secno>5.2.
|
|
</span>Support World Languages</a>
|
|
|
|
<li><a href="#accessibility"><span class=secno>5.3.
|
|
</span>Accessibility</a>
|
|
</ul>
|
|
|
|
<li class=no-num><a href="#acknowledgments">Acknowledgments</a>
|
|
</ul>
|
|
<!--end-toc-->
|
|
|
|
<h2 id=introduction><span class=secno>1. </span>Introduction</h2>
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<h3 id=conformance><span class=secno>1.1. </span>Conformance for Documents
|
|
and Implementations</h3>
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<h2 id=compatibility><span class=secno>2. </span>Compatibility</h2>
|
|
|
|
<p>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.
|
|
|
|
<h3 id=support-existing-content><span class=secno>2.1. </span>Support
|
|
Existing Content</h3>
|
|
|
|
<p class=note>This principle applies primarily to the supported language.
|
|
|
|
<p>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.
|
|
|
|
<p>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
|
|
<em>not</em> being implemented as specified.
|
|
|
|
<p>When considering changes to legacy features or behavior, relative to
|
|
current implementations and author expectations, the following questions
|
|
should be considered:
|
|
|
|
<ul>
|
|
<li>Does a significant quantity of existing content depend on the feature
|
|
or behavior?
|
|
|
|
<li>Does any of the dependent content occur on particularly popular
|
|
websites?
|
|
|
|
<li>Is the dependent content genuinely intended for consumption, rather
|
|
than occurring solely in test cases or examples?
|
|
|
|
<li>Is the dependent content on the public web, rather than found solely
|
|
on internal sites with a controlled user environment?
|
|
|
|
<li>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?
|
|
</ul>
|
|
|
|
<p>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.
|
|
|
|
<h4 id=examples><span class=secno>2.1.1. </span>Examples</h4>
|
|
|
|
<p class=example>Many sites use broken markup, such as badly nested
|
|
elements (<code><b>a<i>b</b>c</i></code>), 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.
|
|
|
|
<p class=example>Some sites rely on the <code><u></code> element
|
|
giving the presentational effect of an underline.
|
|
|
|
<h3 id=degrade-gracefully><span class=secno>2.2. </span>Degrade Gracefully</h3>
|
|
|
|
<p class=note>This principle applies primarily to the conforming language.
|
|
|
|
<p>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.
|
|
|
|
<p>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:
|
|
|
|
<ul>
|
|
<li>Current versions of the top mainstream Web browsers.
|
|
|
|
<li>Highly popular older versions of mainstream Web browsers.
|
|
|
|
<li>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.
|
|
</ul>
|
|
|
|
<p>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:
|
|
|
|
<ul>
|
|
<li>A new element or attribute may provide additional semantics without
|
|
losing essential functionality when not understood.
|
|
|
|
<li>A new scripting method or attribute can be tested before use in script
|
|
using ECMAScript introspection facilities.
|
|
|
|
<li>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.
|
|
|
|
<li>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.
|
|
|
|
<li>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.
|
|
</ul>
|
|
|
|
<p>This list is not exhaustive; in some cases slightly more complicated
|
|
approaches are more effective.
|
|
|
|
<h4 id=examples0><span class=secno>2.2.1. </span>Examples</h4>
|
|
<!--
|
|
<p class="example">The default presentation of the
|
|
proposed <code><section></code> element can be emulated
|
|
through the CSS rule <code>section { display: block; }</code>.</p>
|
|
-->
|
|
|
|
<p class=example>The default presentation of the proposed
|
|
<code>irrelevant</code> attribute can be emulated through the CSS rule
|
|
<code>[irrelevant] { display: none; }</code>.
|
|
|
|
<p class=example>Proposed new multimedia elements like <code><canvas>
|
|
fallback </canvas></code> or <code><video> fallback
|
|
</video></code> allow fallback content. Older user agents will show
|
|
"fallback" while user agents supporting <code>canvas</code> or
|
|
<code>video</code> will show the multimedia content.
|
|
|
|
<p class=example>The proposed <code>getElementsByClassName()</code> 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.
|
|
|
|
<p class=example>The <code><datalist></code> element can be associated
|
|
with an <code><input></code> element and may contain a hidden
|
|
<code><select></code> element. This way the fallback for the intended
|
|
"combo box" control can be a text field or a text field with an associated
|
|
pop-up menu in existing mainstream browsers
|
|
|
|
<h3 id=do-not-reinvent-the-wheel><span class=secno>2.3. </span>Do not
|
|
Reinvent the Wheel</h3>
|
|
|
|
<p>If there is already a widely used and implemented technology covering
|
|
particular use cases, consider specifying that technology in preference to
|
|
inventing something new for the same purpose. Sometimes, though, new use
|
|
cases may call for a new approach instead of more extensions on an old
|
|
approach.
|
|
|
|
<p class=example><code>contenteditable=""</code> was already used and
|
|
implemented by user agents. No need to invent a new feature.
|
|
|
|
<h3 id=pave-the-cowpaths><span class=secno>2.4. </span>Pave the Cowpaths</h3>
|
|
|
|
<p>When a practice is already widespread among authors, consider adopting
|
|
it rather than forbidding it or inventing something new.
|
|
|
|
<p class=example>Authors already use the <code><br/></code> syntax as
|
|
opposed to <code><br></code> in HTML and there is no harm done by
|
|
allowing that to be used.
|
|
|
|
<h3 id=evolution-not-revolution><span class=secno>2.5. </span>Evolution Not
|
|
Revolution</h3>
|
|
|
|
<p>Revolutions sometimes change the world to the better. Most often,
|
|
however, it is better to evolve an existing design rather than throwing it
|
|
away. This way, authors don't have to learn new models and content will
|
|
live longer. Specifically, this means that one should prefer to design
|
|
features so that old content can take advantage of new features without
|
|
having to make unrelated changes. And implementations should be able to
|
|
add new features to existing code, rather than having to develop whole
|
|
separate modes.
|
|
|
|
<p class=example>Switching to XML syntax requires a global change, so
|
|
continue supporting classic HTML syntax as well.
|
|
|
|
<h2 id=utility><span class=secno>3. </span>Utility</h2>
|
|
|
|
<p>These principles call for a design that makes sure HTML can be used
|
|
effectively for its many intended purposes.
|
|
|
|
<h3 id=solve-real-problems><span class=secno>3.1. </span>Solve Real
|
|
Problems</h3>
|
|
|
|
<p>Changes to the spec should solve actual real-world problems. Abstract
|
|
architectures that don't address an existing need are less favored than
|
|
pragmatic solutions to problems that web content faces today. And existing
|
|
widespread problems should be solved, when possible.
|
|
|
|
<h3 id=priority-of-constituencies><span class=secno>3.2. </span>Priority of
|
|
Constituencies</h3>
|
|
|
|
<p>In case of conflict, consider users over authors over implementors over
|
|
specifiers over theoretical purity. In other words costs or difficulties
|
|
to the user should be given more weight than costs to authors; which in
|
|
turn should be given more weight than costs to implementors; which should
|
|
be given more weight than costs to authors of the spec itself, which
|
|
should be given more weight than those proposing changes for theoretical
|
|
reasons alone. Of course, it is preferred to make things better for
|
|
multiple constituencies at once.
|
|
|
|
<h3 id=secure-by-design><span class=secno>3.3. </span>Secure By Design</h3>
|
|
|
|
<p>Ensure that features work with the security model of the web.
|
|
Preferrably address security considerations directly in the specification.
|
|
|
|
<p class=example>Communicating between documents from different sites is
|
|
useful, but an unrestricted version could put user data at risk.
|
|
Cross-document messaging is designed to allow this without violating
|
|
security constraints.
|
|
|
|
<h3 id=separation-of-concerns><span class=secno>3.4. </span>Separation of
|
|
Concerns</h3>
|
|
|
|
<p>HTML should allow separation of content and presentation. For this
|
|
reason, markup that expresses structure is usually preferred to purely
|
|
presentational markup. However, structural markup is a means to an end
|
|
such as <a href="#media-independence">media independence</a>. Profound and
|
|
detailed semantic encoding is not necessary if the end can be reached
|
|
otherwise. Defining reasonable default presentation for different media
|
|
may be sufficient. HTML strikes a balance between semantic expressiveness
|
|
and practical usefulness. Names of elements and attributes in the markup
|
|
may be pragmatic (for brevity, history, simplicity) rather than completely
|
|
accurate.
|
|
|
|
<p class=example>The <code>article</code> element defines an individual
|
|
article, but not the details of how it is displayed. A journal article may
|
|
be the only article on a page, formatted in multiple columns, while a blog
|
|
post may share a page with multiple other articles and be presented in a
|
|
box with a border.
|
|
|
|
<p class=example>The <code>b</code> and <code>i</code> elements are widely
|
|
used — it is better to give them good default rendering for various
|
|
media including aural than to try to ban them.
|
|
|
|
<h3 id=dom-consistency><span class=secno>3.5. </span>DOM Consistency</h3>
|
|
|
|
<p>The two serializations should be designed in such a way that the DOM
|
|
trees produced by the respective parsers appear as consistently as
|
|
feasible to scripts and other program code operating on the document
|
|
trees. Discrepancies can be allowed for compatibility with legacy
|
|
implementations, but the differences should be minimized.
|
|
|
|
<p>Also, unless required for compatibility with legacy implementations and
|
|
deployed content, gratuitous difference in syntactic appearance should be
|
|
avoided as well.
|
|
|
|
<p class=example>The HTML (<code>text/html</code>) parser puts elements in
|
|
the <code>http://www.w3.org/1999/xhtml</code> namespace in the DOM for
|
|
compatibility with the XML syntax of HTML 5.
|
|
|
|
<h2 id=interoperability><span class=secno>4. </span>Interoperability</h2>
|
|
|
|
<p>These principles exist to improve the chances of HTML implementations
|
|
being truly interoperable.
|
|
|
|
<h3 id=well-defined-behavior><span class=secno>4.1. </span>Well-defined
|
|
Behavior</h3>
|
|
|
|
<p>Prefer to clearly define behavior that content authors could rely on, in
|
|
preference to vague or implementation-defined behavior. This way, it is
|
|
easier to author content that works in a variety of user agents. However,
|
|
implementations should still be free to make improvements in areas such as
|
|
user interface and quality of rendering.
|
|
|
|
<h3 id=avoid-needless-complexity><span class=secno>4.2. </span>Avoid
|
|
Needless Complexity</h3>
|
|
|
|
<p>Simple solutions are preferred to complex ones, when possible. Simpler
|
|
features are easier for user agents to implement, more likely to be
|
|
interoperable, and easier for authors to understand. But this should not
|
|
be used as an excuse to avoid satisfying the other principles.
|
|
|
|
<h3 id=handle-errors><span class=secno>4.3. </span>Handle Errors</h3>
|
|
|
|
<p>Error handling should be defined so that interoperable implementations
|
|
can be achieved. Prefer graceful error recovery to hard failure, so that
|
|
users are not exposed to authoring errors.
|
|
|
|
<h2 id=universal-access><span class=secno>5. </span>Universal Access</h2>
|
|
|
|
<p>Features should be designed for universal access. This category covers
|
|
various principles related to that.
|
|
|
|
<h3 id=media-independence><span class=secno>5.1. </span>Media Independence</h3>
|
|
|
|
<p>Features should, when possible, work across different platforms,
|
|
devices, and media. This should not be taken to mean that a feature should
|
|
be omitted just because some media or platforms can't support it. For
|
|
example, interactive features should not be omitted merely because they
|
|
can not be represented in a printed document.
|
|
|
|
<p class=example>The general reflowability of HTML text makes it more
|
|
suitable to variable screen dimensions than a representation of exact
|
|
glyph positions.
|
|
|
|
<p class=example>A hyperlink can not be actuated in a printed document, but
|
|
that is no reason to omit the <code>a</code> element.
|
|
|
|
<h3 id=support-world-languages><span class=secno>5.2. </span>Support World
|
|
Languages</h3>
|
|
|
|
<p>Enable publication in all world languages. But this should not be taken
|
|
as equalizing writing systems by prohibiting features that do not apply to
|
|
all of them. Features for packing multiple translations of a document in a
|
|
single file are out of scope.
|
|
|
|
<p class=example>Supporting Unicode allows text in most of the world's
|
|
languages, including mixing of text in different languages.
|
|
|
|
<p class=example>Italic text is useful because it applies to many bicameral
|
|
scripts, even though some scripts have no such concept. Similarly, ruby is
|
|
useful for many scripts, even though it has a CJK focus.
|
|
|
|
<p class=example>Text in element content has better language support than
|
|
text in attribute content; in element content ruby annotations can be
|
|
inserted, as well as <code>dir</code> attributes and <code>bdo</code>
|
|
elements in case the Unicode bidirectional algorithm is insufficient to
|
|
correctly order adjacent runs of mixed direction text.
|
|
|
|
<h3 id=accessibility><span class=secno>5.3. </span>Accessibility</h3>
|
|
|
|
<p>Design features to be accessible to users with disabilities. Access by
|
|
everyone regardless of ability is essential. This does not mean that
|
|
features should be omitted entirely if not all users can make full use of
|
|
them, but alternate mechanisms should be provided.
|
|
|
|
<p class=example>The image in an <code>img</code> may not be visible to
|
|
blind users, but that is a reason to provide alternate text, not to leave
|
|
out images.
|
|
|
|
<p class=example>The <code>progress</code> element is intrinsically
|
|
accessible as it has unambiguous progress bar semantics which permits
|
|
mapping to accessibility APIs that can represent progress indicators.
|
|
|
|
<h2 class=no-num id=acknowledgments>Acknowledgments</h2>
|
|
|
|
<p>The editors would like to thank Charles McCathieNevile, Chris Wilson,
|
|
Dan Connolly, Henri Sivonen, Ian Hickson, Jirka Kosek, Lachlan Hunt, Nik
|
|
Thierry, Philip Taylor, Richard Ishida, Stephen Stewart, and Steven
|
|
Faulkner for their contributions to this document as well as to all the
|
|
people who have contributed to HTML 5 over the years for improving
|
|
the Web!
|
|
|
|
<p>If you contributed to this document, but your name is not listed above
|
|
please let the editors know so they can correct this omission.
|