HTML Design Principles (Proposed)
The HTML5 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. In the HTML Working Group, we have people from both communities. 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.
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.
Support Existing Content
SupportExistingContent: Browsers implementing the new version of HTML should still be able to handle existing content. Ideally, it should be possible to process web documents and applications via an HTML5 implementation even if they were authored against older implementations and do not specifically request HTML5 processing.
All changes and additions could cause some content to malfunction at least in theory, but this will vary in degree. We need to judge whether the value of the change is worth the cost. Cross-browser content on the public Web should be given the most weight.
Example: Many sites use broken markup, such as badly nested elements (<b>a<i>b</b>c</i>), 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.
Degrade Gracefully
DegradeGracefully: 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.
Example: <canvas> fallback </canvas>. Older user agents will show "fallback" while user agents supporting <canvas> will show the element.
Don't Reinvent The Wheel
DontReinventTheWheel: If there's 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.
Example: contenteditable= was already used and implemented by user agents. No need to invent a new feature.
Pave The Cowpaths
PaveTheCowpaths: When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.
Example: Authors already used the <br/> syntax as opposed to <br> in HTML. Lets just allow that.
Evolution Not Revolution
EvolutionNotRevolution: 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.
Example: XML syntax requires a global change, so continue supporting classic HTML syntax as well.
Note: TAG's thoughts on compatibility
The TAG is working on a document on compatibility and vesioning, which mentions:
Utility
These principles call for a design that makes sure HTML can be used effectively for its many intended purposes.
Solve Real Problems
SolveRealProblems: 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.
Priority of Constituencies
PriorityOfConstituencies: 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.
Media Independence
MediaIndependence: 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't be represented in a printed document.
Example: The general reflowability of HTML text makes it more suitable to variable screen dimensions than a representation of exact glyph positions.
Example: A hyperlink can't be actuated in a printed document, but that is no reason to omit the <a> element.
Universal Access
UniversalAccess: 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.
Example: The image in an <img> may not be visible to blind users, but that is a reason to provide alt text, not to leave out images.
Support World Languages
SupportWorldLanguages: Enable publication in all world languages. But this should not be taken as equalizing writing systems by prohibiting features that don't apply to all of them. Features to represent a single web page in multiple languages are out of scope.
Example: Supporting Unicode allows text in most of the world's languages, including mixing of text in different languages.
Example: Italics 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.
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 dir attributes and bdo elements in case the Unicode bidirectional algorithm is insufficient to correctly order adjacent runs of mixed direction text.
See W3C Internationalization (I18n) Activity.
Secure By Design
SecureByDesign: Ensure that features work with the security model of the web. Preferrably address security considerations directly in the specification.
Example: Communicating between documents from different sites is handy, but an unrestricted version could put user data at risk. Cross-document messaging is designed to allow this without violating security constraints.
Separation Of Concerns
SeparationOfConcerns: 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.
Example: The <article> 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 colums, while a blog post may share a page with multiple other articles and be presented in a box with a border.
Example: The <b> and <i> elements are widely used - it is better to give them good default rendering for various media including aural than to try to ban them.
Interoperability
These principles exist to improve the chances of HTML implementations being truly interoperable.
Well-Defined Behavior
WellDefinedBehavior: 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.
Avoid Needless Complexity
AvoidNeedlessComplexity: 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.
Handle Errors
HandleErrors: 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.
Disputed Principles
The following principles are disputed to varying degrees.
Visible Metadata vs. Metadata Anywhere
VisibleMetadata: 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.
MetadataAnywhere: 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.
No Version Syntax vs Explicit Versioning
NoVersionSyntax: 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.
ExplicitVersioning: 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
SupportExtensions: 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.