DesignPrinciplesReview

This page is a collection of review feedback on the HTML Design Principles draft.

Editorial Changes

Abstract

Suggested Abstract text from Lachlan Hunt

[1]

This document describes the set of guiding principles used by the HTML Working Group for the development of HTML5. The principles are designed to offer guidance for the design of HTML, in the areas of compatibility, utility and interoperability.

Introduction

Instead of "Rules of thumb", consider using something like "guideposts", "practical ways" or "general principles" in the introduction. Accurate or not "Rule of thumb" has some negative (domestic violence) history/baggage. It has been often claimed that the term originally referred to the maximum thickness of a stick with which it was permissible for a man to beat his wife.

Suggestion on writing the principles: I would like that mjs write the document, replacing every occurences of browsers by implementations or softwares for himself, and then see if the principle is logical. If the sentence doesn't work anymore, it means that there is something specific toward a class of product, and then that it has to be generalized and then specifically declined for different class of products if necessary.

Support Existing Content

- In section 2.1. consider changing "browsers" to "user agents". Not everyone uses a browser. http://www.w3.org/2002/10/uaag10-faq/#ua-def

Evolution Not Revolution

Wording suggestion from Jirka Kosek [2]

"XML syntax requires a global change, so continue supporting classic HTML syntax as well." -- I have no idea what this sentence should mean. I think that you are not proposing changes to XML syntax. ;-D

Degrade Gracefully

Wording change: (presumably the goal is to recast the principle to be about HTML, not documents).

New versions of HTML should allow documents using them to work in user agents that don't yet support it. Authors will be reluctant to use new features that cause problems in older browsers, or that don't provide some sort of graceful fallback. Graceful degradation is most effective when it does not require special script or styling to work.

Solve Real Problems

Add emphasis to should in "And existing widespread problems should be solved, when possible."

Support World Languages

Suggestion to add "See W3C Internationalization (I18n) Activity."

Substantive Changes to Existing Principles

Media Independence / Device Independence

For the media device-independence principle consider including:

Deliverables will satisfy device-independence requirements. To ensure this we will work closely with UWA and be advised by the Device Independence Principles W3C Working Group Note.

The DI Principles note reflects dialog with WAI about a large area of common concerns. This is past work that the HTML WG may not have to re-invent from scratch. Applying it to HTML5 may take fresh thought, but there could be value to starting with what DI has done in the past.

Separation Of Concerns

In Separation Of Concerns it says "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 MediaIndependence. 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."

However, semantic markup for the sake of semantic markup is a good idea. Writing that means nothing (non-semantic writing) is the bad idea: it wastes the readers time. Likewise, markup that means nothing is also a bad idea. That is not to say that marking up text with bold and italics means nothing. Rather its meaning is less precise and require greater heuristics to interpret than markup that includes semantic constructs. RTF and TeX for example have many facilities for marking up meaning in a non-hierarchical fashion using common typographic/visual conventions. That is a very different approach than HTML where the document is usually markedup with precise device independent semantics that are then styled using different device dependent presentation idioms. For more information see Robert Burns post.

Ben Boyle proposed a design principle that: "All elements should have a clearly defined structural (semantic) meaning". For more information see Ben's post.

[3] -- Henri Sivonen

- In section 3.7 the example "The b and i elements are widely used" is based on the disputed "cow paths" principle. Consider removing it. [4]

Universal Access

Request to word more strongly. Suggested alternate wording:

Design features to be accessible, universal, and inclusive. Access by everyone regardless of ability is an essential. Do not omit features that provide access to users unless alternate/equivalent mechanisms are be provided. Deliverables will satisfy accessibility requirements. To ensure this we will work closely with the WAI.

[5], [6] -- Laura Carlson advocating for a stronger wording.

[7] -- Charles McCathieNevile discussing accessibility issues in general

Justification

What is the logic behind saying "when possible" in the statement, "Design features for universal access. This does not mean that features should be omitted entirely if not all users can fully make use of them, but alternate mechanisms should be provided when possible."  ?

The HTML 5 working group charter says "The HTML Working Group will cooperate with the Web Accessibility Initiative to ensure that the deliverables will satisfy accessibility requirements." The familiar Tim Berners-Lee quote, "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.", remains a powerful statement. This working group would do well to have an accessibility principle that heeds the accessibilty wisdom of TBL. Because of this principle should be strengthen and expanded.

Definitions from the glossary:

Accessibility 

Access for people with disabilities.

Alternate 

Refers to the mechanism through which equivalents are provided and can be chosen from by the user.

Equivalent 

Content that conveys the same meaning as other content, through a different means. For instance, both an image and its alt attribute are to convey the same message. Thus "equivalent" refers strictly to content, not to any mechanism.

Inclusive Design 

Inclusive design means developing systems, products or web sites flexible enough to serve the broadest possible range of users. It provides access to users with disabilities and provides better usability for everyone.

Usability 

Usability is the art and science of designing systems or products that are effective, efficient, engaging, error tolerant and easy to learn. Usability and accessibility are often confused. For instance some believe that a usable web site is accessible and vice versa. The two are not exclusive, but it is important to understand the difference. Usability means intuitive and easy to use. Accessibility means as barrier-free as possible. Accessibility and usability are closely related, as they both improve satisfaction, effectiveness, and efficiency of the generic user population. But while accessibility is aimed at making systems or products open to a much wider user population, usability is aimed at making the target population happier, more efficient, more effective. Accessibility is actually a prerequisite to usability. If a person can not access a web page he/she certainly can not use it.

Universality 

Access for all users in all circumstances

Note that Accessibility is a subset of Universality. Converting this into an Accessibility only principle is counter productive. -- Lachlan Hunt

Principles to Drop

Principles to Add

No Version Syntax

The next version of HTML should avoid any explicit syntax indicating the version. Following the "Degrade Gracefully" and "Don't Break The Web" principles, it is expected that explicit indications of version will not be needed by producers or consumers of content. And including a version marker will only encourage breaking compatibility. Similarly, profiles of the language are to be discouraged, since a proliferation of profiles harms interoperability.

Explicit Versioning

The next version of HTML should have a way to indicate version and possibly a profile relative to that version. This will allow versions to be distinguished in order, say, to help resolve a dilemma between conflicting spec versions and what the HTML author intended, and will allow definition of profiled subsets.

Support Extensions

The next version of HTML should be designed to support extensibility. Extensions are new constructs that are not part of the standard, including: markup elements and attributes; new allowed values for attributes; newly allowed content for an element; and added DOM API methods and attributes. There are several possible sources of extensions. Vendor implementations may include extensions. Authors may wish to use extensions in their own document. And third parties (like the JavaScript libraries currently popular) may wish to provide extensions that authors can use. The markup and APIs should cater to these needs in a reasonable way.

Some pro-extensibility commentary:

[8] [9]

Visible Metadata

Metadata is more effective when it is directly tied to user-visible data. Invisible metadata may be incorrect, out of date, or intentionally deceptive, depending on intended use. For example, <a> is often more trustworthy as a cross-reference than <link>. User-visible tags are generally more trustworthy than <meta> keywords. On the other hand, occasionally metadata may not be suited to any kind of direct presentation, or may count on specialized presentation outside the main content area.

Commentary:

[10] -- Mike Shinkel [11] -- Murray Maloney [12] -- L. David Baron

Metadata Anywhere

Metadata is useful. Sometimes it should be attached to user-visible data, sometimes not. The working group should express no preference one way or the other.

Baby Steps

Suggested by Ian Hickson

The arbitrary 80% (Baby Steps) - Ian Hickson (Wed, 15 Aug 2007)

BabySteps: Not every content producer use case will be handled by HTML. We must draw a line just slightly beyond what can be done today, and not succomb to the tendency of feature creep.

• User agents need time to implement features, adding too many features at once results in poor, uninteroperable implementations, which results in a bad author experience.
• A language that does everything will result in a language with many features that are used by nearly nobody, yet that get in the way of all authors.

Example: The context menu features in HTML5 only allow for simple commands, radio buttons, and check boxes. We don't support colour pickers or text fields inside menus yet. While a future version of HTML might support those, we have to move slowly so that the quality of the spec and of implementations stays high.

Note that this principle has nothing to do with the users. While not every content producer use case will be taken into account, we should still cater for all users of documents and applications that use the language (see Universal Access).