Tuesday, February 27, 2024
Google search engine
HomeUncategorizedHTML Design Principles (2007)

HTML Design Principles (2007)


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

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 (abc), 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
fallback
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 element can be associated
with an element and may contain a hidden

Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments