Why Design Principles?

Sam has asked me (offlist) to justify the HTML Design Principles  
document[1] as a set of design principles. Here is my attempt to do so  
as clearly as I can. This is going to be somewhat long, for which I  
apologize. I realize this has the potential to spawn lengthy  
discussion. I will respond to direct questions and points but I will  
try to avoid needlessly drawing out the discussion.

If this explanation seems reasonable to most people, I'd like to  
update the front matter (Abstract and Introduction) to better reflect  
the thinking in this email.


1. == Where did the Design Principles document come from? ==

Many of the core ideas in the Design Principles date back to the 2004  
W3C Workshop on Web Applications and Compound Documents[2] and the  
schism that arose there. The W3C decided that the future of the Web  
was a new Webbased on XML + XHTML + SMIL + SVG + XForms + CDF. Some  
dissenters, chiefly but not exclusively browser vendors, felt that the  
right path forward was incremental evolution on top of HTML + CSS + JS  
+ DOM. This was based on concerns over continuity, compatibility and  
so forth. Some of the dissenters formed the WHATWG to carry on its  
vision.

While HTML5 (under the name "Web Apps 1.0" and "Web Forms 2.0") was  
under development in the WHATWG, the principles guiding its design  
were not explicitly called out or referred to. The main participants  
tended to share values, and the unofficial nature of the organization  
tended to attract those who were mostly like-minded.

In 2007, the W3C decided to return to work on HTML. The HTML Working  
Group was formed. In the early days, there was much bickering over  
basics. Clearly there was a lack of common vision and shared  
understanding between groups. Since WHATWG brought a fairly advanced  
proposal to the table, some of us who'd followed WHATWG goings-on more  
closely felt that it would be good to explicitly write down what we  
thought were the guiding principles, the better to communicate in  
these early discussions. The first version of the document was started  
on the Wiki by me, but had contributions from many others.

In early 2007, I suggested that the Design Principles be adopted by  
the group, and noted that some others thought they should be published  
as a W3C Note.[3] This resulted in two surveys, one to assess the  
level of agreement[5] and one on publishing as a Working Draft[4].  
These surveys found support for publishing and also widespread (though  
not universal) support for the individual principles.

This is part of the reason the front matter is worded as it is. There  
was > 90% agreement on the substance of almost every principle, so it  
seemed like a fairly strong statement of agreement was appropriate.

Today, my ideas about how the Design Principles can be useful are  
different.


2. == How have the Design Principles been useful, and how are they  
today? ==

The Design Principles never quite advanced to a formally adopted Note.  
However, I think they have been useful to the group and outside  
commenters in several ways.

First, they serve an explanatory purpose. Many individual design  
decisions in the HTML5 draft are much easier to understand in light of  
the principles. Note that this is not just pasting in Hixie's own  
thinking. At least the last time we asked the question, the vast  
majority of the group agreed. And I even rejected one of Hixie's own  
proposed principles ("Baby Steps") since it did not seem to help  
explain what people saw in the spec.

Second, they offer persuasive power, even for those who are not in  
full agreement. If 90% of the group believes in an abstract principle  
of design, then if you can couch your arguments for a proposal in ways  
that appeal to that principle, you will have more odds of making a  
public reasoned argument that persuades the group. Conversely, if you  
want to make a proposal that flouts many of the principles, and want  
to justify it on the basis that the principles are wrong, then it is  
likely you will be swimming upstream. So even if you violently  
disagree with a principle, you can make productive use of it in  
communicating with the group.

Third, they offer a shared vocabulary. If I we to explain the ideas of  
"Support Existing Content" or "Degrade Gracefully" from scratch, every  
time a proposal is made that is out of sync with them, it would  
quickly grow tiresome.

Fourth, they are reusable. Other Working Groups or other specs may  
choose to adopt some or all of these principles if they have similar  
goals to HTML5. XMLHttpRequest is an example of a spec where reference  
to the principles has been useful as a guidepost.


3. == Are the Design Principles really principles? ==

Yes. The fact that they are neither phrased nor treated as absolute  
doesn't make them non-principles. Keep in mind, these principles have  
a fair chunk of their cultural origin on the pragmatist side of the  
pragmatist vs. idealist schism of 2004. Naturally they will try to  
reflect practical considerations and not just unattainable ideal  
goals. As I explained[6], and as Ian also explained[7]


4. == Can the Design Principles be abused? ==

Yes. Anything can be abused. But the Design Principles are not  
intended as a club to silence dissent. They are a tool to help  
dissenters couch their arguments in terms that will be more  
persuasive, and to make proposals that are more likely to be successful.


5. == What about the fact that some people may disagree with some  
details? ==

As I said above, I believe the Design Principles can be useful to you  
even if you don't agree in all respects. You will have a much easier  
time if you put your arguments in terms that the majority of the  
group, the editor, and key stakeholders such as browser vendors can  
relate to and believe in, then if you try to fight over first  
principles. You will also have a much easier time understanding the  
reasoning behind decisions in the spec. And they can provide a handy  
shorthand for the group.


6. == Some of the most successful Design Principles ==

I believe the following Design Principles have been the most  
successful. By success I mean, they have actually driven design  
decisions and have a lot of explanatory power as to the contents of  
the spec. I list them here approximately in order from most important  
to least important.

- Support Existing Conten: Has influenced many decisions. Core  
original reason for HTML5 to exist. Explains many details of the spec.  
Not negotiable to browser vendors.
- Degrade Gracefully:  Same as above.
- Accessibility: A proposal that violates this is a nonstarter (though  
there has been much debate over what violates it).
- Secure by Design: A proposal that violates this is a nonstarter.
- Handle Errors: Has influenced many decisions. Core original reason  
for HTML5 to exist. Explains many details of the spec. Not negotiable  
to browser vendors.
- Well-Defined Behavior: Same as above.
- Separation of Concerns / Media Independence: These have been core  
principles since HTML4. Much of the language is designed around these  
assumptions.
- Evolution Not Revolution: Has influenced many decisions. Core  
original reason for HTML5 to exist. Explains many details of the spec,  
though at a high level. A bit too general and high level to be a  
strong decision tool.
- DOM Consistency: Much more specific than the other principles, but  
stands up for a useful and non-obvious idea.
- Priority of Constituencies: Almost risks being a truism.
- Don't Reinvent the Wheel: Despite some dissent about the wording, it  
clearly explains why we have contentEditable, canvas and IE-style drag- 
and-drop, instead of new clean designs for these features.

7. == Some of the least successful Design Principles ==

I believe the following Design Principles are some of the least  
successful. By this I mean, they have generated more debate than  
useful understanding.

- Pave the Cowpaths - People get caught up on the word "Cowpath". The  
spec has not done literally what this principle says that often. Not  
worth having it there to fight about.
- Solve Real Problems - Little explanatory power. Sometimes triggers  
useless debate over what "Real" means.
- Don't Reinvent the Wheel - Yes, I put it on both lists. I think the  
content has been useful, the the name and implications sometimes  
trigger unproductive arguments. I think it is useful to capture the  
idea of addressing use cases with existing not-yet-standard solutions  
when possible.


8. == Design Principles that likely should be added ==

- Work from Use Cases - This is clearly a key practice, and important  
to keep in mind to prepare a successful proposal.
- Learn from Data - Quantitative analysis has been a factor in some  
decisions. I think we have seen (for instance from Ben Millard's table  
study) that providing better data is more effective than arguing with  
the idea of using data.
- Incremental Improvement - This could be a more general statement of  
"Evolution and not Revolution", as well as something like the  
Microformats 80/20 rule. Building on the de facto existing Web  
platform is in a very real sense HTML5's reason for being. And it's  
clearly a goal to avoid defining too much of a feature directly, until  
there is more experience with the initial version.


[1] http://dev.w3.org/html5/html-design-principles/Overview.html
[2] http://lists.w3.org/Archives/Public/public-webapps-cdf-discuss/2004Jun/att-0000/2004jun01.html
[3] http://lists.w3.org/Archives/Public/public-html/2007Apr/1103.html
[4] http://www.w3.org/2002/09/wbs/40318/wdhdp/
[5] http://www.w3.org/2002/09/wbs/40318/dprv/results
[6] http://lists.w3.org/Archives/Public/public-html/2009May/0653.html
[7] http://lists.w3.org/Archives/Public/public-html/2009Jun/0037.html

Received on Tuesday, 2 June 2009 03:12:33 UTC