W3C WBS Home

Results of Questionnaire review of HTML Design Principles

The results of this questionnaire are available to anybody.

This questionnaire was open from 2007-08-16 to 2007-08-23.

80 answers have been received.

Jump to results for question:

  1. Review survey process
  2. principle "Support Existing Content"
  3. principle "Degrade Gracefully"
  4. principle "Do not Reinvent The Wheel"
  5. principle "Pave the Cowpaths"
  6. principle "Evolution Not Revolution"
  7. principle "Solve Real Problems"
  8. principle "Priority of Constituencies"
  9. principle "Media Independence"
  10. principle "Universal Access"
  11. principle "Support World Languages"
  12. principle "Secure By Design"
  13. principle "Separation of Concerns"
  14. principle "Well-Defined Behavior"
  15. principle "Avoid Needless Complexity"
  16. principle "Handle Errors"
  17. Do you support publication?
  18. Are you OK to delegate some edits?

1. Review survey process

This survey is a non-binding, informational-gathering exercise. The chair may put a related formal proposals to the Working Group to adopt these principles and/or publish them if this survey shows a critical mass of support.

Do you support the design principles below as stated in the editors draft? (currently v 1.4 2007/08/16 15:39:50; see also revision log).

Note that the document is moving from the wiki topic.

Choices are based on a Likert scale:

Note suggestions regarding change requests:

  • Send a message to public-html@w3.org with [HDP] at the start of the subject line.
  • Please make sure your message contains the following:
    • Which principle or principles you are addressing (or none, if your comment is about introductory text or the like).
    • What change you would like made.
    • The reasoning behind your change.
    • Whether your request is in your opinion an editorial change, a substantive change (changes the meaning of the principle significantly), a request to drop one of the principles in the draft, or a request to add a new principle to the draft.

Any novel supporting arguments should be sent to public-html@w3.org for discussion and then cited in the comments field. (Of course, if you already sent your argument, just cite it.)

Details

Responder Comments
Mark DuBois
Edward O'Connor
Daniel Morrison
Matthew Freels
Michael Puls II
Jason Turnbull
Ian Massey
Chris Adams
Weston Ruter
Thomas Bradley
Danny Liang
Stephen Duncan
Dannii Willis
Andrew Fedoniouk
Jon Barnett
Frank Palinkas
Carol King
Alexey Proskuryakov
Brad Fults
Sajid Saiyed
Bill Mason
Stéphane Deschamps
Razvan MIHAIU
Julian Reschke
Egor Kloos
Craig Buckler
Bob Hopgood
Shawn Medero
Matthew Otto
Andrew Sidwell
Dimitri Glazkov
Craig Saila
Patrick Taylor
Steve Faulkner
Dean Edridge
Marc Drumm
Henri Sivonen
Daniel Schattenkirchner
Kai Hendry
Arthur Jennings
Benjamin Meadowcroft
Robert Burns
Ian Hickson I think we should also have the new "Baby Steps" principle.
David Andersson
Geoffrey Sneddon
Brian DeRocher
Josh Lawton
Robert Marshall
Scott Lewis
Stephen Axthelm
Stephen Stewart
Raphael Champeimont
Anne van Kesteren
Roger Johansson
Joshue O Connor I am curious as to why is there such a bloat amongst the design
principles for HTML 5? The design principles documents for HTML 4 seems remarkably precise, and sensible.

The XHTML 2 design aims also seem to be brief and concise. Why are the HTML 5 principles so verbose? Can the principles themselves "Avoid Needless Complexity"?

[1] http://www.w3.org/TR/WD-html40-970708/intro/h4desgn.html
[2] http://www.w3.org/TR/xhtml2/introduction.html#aims

Maurice Carey
Scott Turner
Karl Dubost * the principles label are so broad that they can be interpreted in many ways.
* the explanation text which is under each principle is mixing rationale and examples. I guess it would benefit of a grid (template) for writing the prose.
* these are mostly "Web browsers Design Principle" not that much "HTML Design Principle". As it has been repeated that the specification has been created for implementers, I guess it could be read with a class of products grid.
What each principle means for
* Browser
* Search engines
* Authoring tools
* Converters
* Conformance checkers

Template:
* HTML Context (why?)
* What issues are solved by the principle?
* Specific implications for some implementers?
* Examples (1 or 2)
Sander Tekelenburg
Nik Thierry
Andrew Maben
Ben Boyle
James Graham
David Singer
Masataka Yakura
Lachlan Hunt All of my comments are located in this post.
http://lists.w3.org/Archives/Public/public-html/2007Aug/0889.html
Michael Cooper As a "general comment", I think there should be a principle in favour of an extensibility mechanism. I don't care too much what that mechanism is and support it being easy for authors and implementors. I also recommend that W3C find a way to respond more quickly to getting widely adopted extensions into evolving versions of the spec; this idea is supported by the "pave the cowpaths" principle.
Jason White
Monika Trebo
Dylan Smith
Schalk Neethling
Laura Carlson Principles are fundamental value guides used to base decisions. DanC has said, "their main utility is as justification in discussions. if they don't work that way, they should be dropped" [1].

The premise of the principles is flawed. It says in the current document that, "They are pragmatic rules of thumb that must be balanced against each other, not absolutes." Some of the current principles serve only to confuse discourse because they are an ambiguous balancing act. For example, like Bob Hopgood points out in one of his survey responses, some of the principles start by saying 'should' and then are immediately follow with another paragraph saying it cannot be achieved. Many terms are too subjective. I question if they can be applied in a fair and consistent manner.

An indecisive principle will not be an aid to decision making but only worsen the discourse. Doublespeak often results in communication bypass.

The introduction to the design principles document, needs changing to clearly state that these principles are fundamental value guides used to base decisions. Their main utility is as justification in discussions.

The sentence: "They are pragmatic rules of thumb that must be balanced against each other, not absolutes." needs to be eliminated.

[1] http://krijnhoetmer.nl/irc-logs/html-wg/20070817#l-43
Philip TAYLOR Totally unclear what question is being asked here : "Do you support the design principles below as stated in the editors draft? (currently v 1.4 2007/08/16 15:39:50; see also revision log)." is a blanket question, whereas those that follow are focussed and therefore capable of being answered. There is also no Likert scale radio-button associated with the question, so it is not possible to offer a quantitative answer.
Richard Ishida Note that I'm providing answers according to whether or not i think changes are needed, as described above. I generally agree with the principles themselves.

For general comments, see my email at http://lists.w3.org/Archives/Public/public-html/2007Aug/0953.html
Benoit Piette
Marcin Hanclik I would make the HDP a binding document with RFC2119 header and statements. This could positively influence the process of adopting or dropping of particular features during further discussion.
Gregory Rosmaita
Leif Halvard Silli The «1. Introduction» says: «WhatWG [and] W3C… have been based on different goals and different ideas … These design principles are an attempt to capture consensus».

However, many, if not most, of the principles are proposed by the WhatWg community, which sometimes have been very eager to ensure their spesific interpretation of them.

Also the use of the word «different» seems - indifferent ... Does it mean «WhatWg used some, while W3C used others»? Or do they state that one has used entirely different ideas etc?

One should also consider that while WhatWg is one block/community, the «rest of us» does not make up one big «W3C block».
Dan Connolly
David Baron

2. principle "Support Existing Content"

Do you support the "Support Existing Content" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 47
Agree 24
Neutral 4
Disagree 4
Strongly Disagree 1

Details

Responder principle "Support Existing Content"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Agree
Michael Puls II Strongly Agree
Jason Turnbull Strongly Agree
Ian Massey Neutral I think that at some point supporting legacy standards and/or writing explicit support for substandard authoring practices becomes more harmful than helpful. The web isn't going anywhere anytime soon, the longer we continue supporting these unfavorable situations, the more difficult it will be when we're finally forced to drop them.
Chris Adams Agree
Weston Ruter Agree
Thomas Bradley Strongly Agree
Danny Liang Strongly Agree
Stephen Duncan Strongly Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Agree
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Strongly Agree
Sajid Saiyed Strongly Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree In particular I feel that a low statistic on particular usage is not sufficient enough to erase said usage (I want to keep @summary for tables, @longdesc for images, etc). Not making them mandatory suits me, deprecating them doesn't: they do work.
Razvan MIHAIU Strongly Agree Technical details should almost never take priority over business logic. Not even a monopoly can afford steps like these, otherwise they will loose market share.

And why not support "existing content" ? To save a few CPU cycles ? CPU cycles costs almost nothing these days, and it is going to be even cheaper in the future, while the work done by software engineers is never cheap.

Purists may invoke another reason – "clean design". Every design is "clean" at its first stages, but as it develops it becomes more complex, because of situations not foreseen by the initial developers. People should not be forced to upgrade their applications for the sole purpose of using a "clean design".

Let's take a practical example: deprecated HTML elements, like "CENTER", "FONT", "S", "U". Let's suppose that a purist browser will drop support for these elements. As a result of this, thousands of web sites will not display correctly in that browser. The browser's developers will argue that there is nothing wrong with the browser: it is the websites fault because they are using deprecated HTML. The developers are right, but *who* will listen ?

People just want to use that browser and they don’t care about the "perfect design / perfect application" imagined by some developer.
Julian Reschke Agree ...unless there's a conflict with another principle, such as "secure by design".
Egor Kloos Agree
Craig Buckler Agree
Bob Hopgood Neutral I agree with the need to support existing content in XHTML 1.0 and HTML 4.01 but as written it implies support for HTML 1.0 as well. There are a lot of old elements out there. New HTML 5 browsers should not be constrained by so much baggage.

Personally I don't like design principles which start by saying 'should' and then immediately follow with another paragraph that says it cannot be achieved.
Shawn Medero Strongly Agree
Matthew Otto Agree
Andrew Sidwell Strongly Agree
Dimitri Glazkov Strongly Agree
Craig Saila Strongly Agree
Patrick Taylor Strongly Agree
Steve Faulkner Agree
Dean Edridge Strongly Agree This needs to be done in a way that does not hinder us from further improving the (x)html language, but I'm sure it can be achieved.
Marc Drumm Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Agree HTML and open standards. Not so much PDFs/Flash/popups etc. ;)
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Strongly Agree
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Agree
Josh Lawton Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Neutral I suppose user agents will need to, unfortunately.
Joshue O Connor Strongly Agree In particular @summary, @longdesc and header/id combinations.

This is in keeping with "Browsers implementing the new version of HTML should still be able to handle existing content." [1]

"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."

When these changes impact heavily on users of assistive technology, then they certainly are not.

[1] http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html?rev=HEAD#support-existing-content


Maurice Carey Strongly Agree
Scott Turner Strongly Agree In my opinion the standard will fail if this is not adopted.
Karl Dubost Disagree Agree with the principle, disagree with the prose.

HTML implementations should still be able to handle existing content. Ideally, it should be possible to process web documents and applications via an HTML 5 implementation even if they were authored against previous version of the language or authored to fit the behavior of older implementations and do not specifically request HTML 5 processing.

=======
Note: For me the principle has two sub categories
- Ability to parse the document
- Ability to make it functional in future applications.

For example a converter (ala tidy) has to be able to parse it to fix the document but not to make it functional. A conformance checker has to be able to parse the existing content but not to make it functional.
=======
Sander Tekelenburg Agree
Nik Thierry Disagree I'd much rather push things forward without having legacy code hold things back. Having IE6 as a legacy browser is hard enough, and by taking a bold step and laying down a line between old and new code will stop the blurring and confusion that comes with legacy support.
Andrew Maben Strongly Agree
Ben Boyle Agree
James Graham Strongly Agree
David Singer Strongly Agree
Masataka Yakura Agree
Lachlan Hunt Agree
Michael Cooper Agree
Jason White Agree This is mandated by the scope and goals of the project.
Monika Trebo Agree To a reasonable extent, yes, with “reasonable” meaning keeping content legible but not necessarily exactly the way an author intended (eg: phasing out support for presentational markup). It may give browser vendors major headaches and cause unreasonable development costs should they have to support every single piece of badly written code on the web. To stay with the example quoted in the editor’s draft from August 16. 2007: <b>a<i>b</b>c</i>. If badly marked up text does not appear bold or italic the text will still be legible……
At some point authors will have to decide if their pages are still relevant enough to justify the effort of correcting their HTML, or if they prefer to see them degrade gracefully or even retire their pages.
Dylan Smith Strongly Agree
Schalk Neethling Agree
Laura Carlson Disagree As stated in the survey instructions,
Disagree = Some changes are needed.

Changes need to be made to the the wording to stipulate that current web sites shouldn't stop working in HTML5 user agents. Like Karl says, "HTML implementations should still be able to handle existing content. Ideally, it should be possible to process web documents and applications via an HTML 5 implementation even if they were authored against previous version of the language or authored to fit the behavior of older implementations and do not specifically request HTML 5 processing."

Delete the sentence: "We need to judge whether the value of the change is worth the cost." That is true of everything.

The sentence, "Cross-browser content on the public Web should be given the most weight." should be changed to "Valid markup should be given the most weight, but legacy invalid markup shouldn't stop working."
Philip TAYLOR Strongly Disagree "Cross-browser content on the public Web should be given the most weight." Strongly disagree. "/Valid/ cross-browser ..." should be given the most weight, and invalid content ignored. For the same reason, I strongly disagree that "We need to define processing requirements that remain compatible with the expected handling of such content."
Richard Ishida Agree See comments at http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html
Benoit Piette Neutral
Marcin Hanclik Strongly Agree
Gregory Rosmaita Strongly Agree
Leif Halvard Silli Disagree * The wordig «even if they [...] do not specifically request HTML 5 processing». How can a document «request HTML 5 processing» when we are moving away from a DOCTYPE that tells which version of HTML we are dealing with?

* The wording «We need to judge whether the value of the change is worth the cost» is a principle in its own. Remove it.

* What does «change» refer to in this principle? The spec? Well isn't it the spec we are making? In a debate on public-html, the interpretation «changes applying to the handling of legacy content» was proposed, and qualified with the word «significant»: «significant content» [1]. Further, to demonstrate that «significant» was not meant purely as a reference to quantity, an related WhatWG IRC debate was quoated where, as first requirement, it was stated that one should look for «use cases» to justify that UAs support existing legacy content. [2] As if <b>a<i>b</b>c</i> has a use case?

* «Cross browser content [etc]t»: To clear up what «existing content» is, I support Laura's proposed change: «Valid markup should be given the most weight, but legacy invalid markup shouldn't stop working.»

[1] http://lists.w3.org/Archives/Public/public-html/2007Aug/0944.html
[2] http://lists.w3.org/Archives/Public/public-html/2007Aug/0889.html
Dan Connolly Strongly Agree
David Baron Agree I think the use of "Ideally" makes the principle too weak. As stated, it would be satisfied by a magical mode-switching version declaration. However, doing that wouldn't satisfy the requirement of making a specification that documents what's needed for an HTML implementation to ease market entry into the Web browser (layout engine) market. But maybe the principle of specifying enough so that implementations don't need to reverse-engineer other implementations ought to be a design principle of its own in the Interoperability section...

3. principle "Degrade Gracefully"

Do you support the "Degrade Gracefully" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 59
Agree 14
Neutral 1
Disagree 6
Strongly Disagree

Details

Responder principle "Degrade Gracefully"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Strongly Agree
Michael Puls II Agree
Jason Turnbull Strongly Agree
Ian Massey Strongly Agree
Chris Adams Strongly Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Strongly Agree
Stephen Duncan Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Strongly Agree
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Strongly Agree
Sajid Saiyed Strongly Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree
Razvan MIHAIU Strongly Agree
Julian Reschke Strongly Agree
Egor Kloos Strongly Agree
Craig Buckler Strongly Agree
Bob Hopgood Agree
Shawn Medero Strongly Agree
Matthew Otto Agree
Andrew Sidwell Strongly Agree
Dimitri Glazkov Strongly Agree
Craig Saila Strongly Agree
Patrick Taylor Strongly Agree
Steve Faulkner Agree
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Strongly Agree
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Agree
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Agree
Josh Lawton Strongly Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Strongly Agree
Joshue O Connor Agree I also agree with Lauras' comment regarding the use of <canvas>. Using something like generic <newelement> fallback </newelement> makes the example more natural and easier to understand.
Maurice Carey Agree
Scott Turner Disagree Site authors generally are happy to put a notice on their pages "This site requires USER AGENT" and/or to use the USERAGENT header to supply useragent tuned content.
Karl Dubost Disagree Replace the first sentence by "HTML documents that include markup for new features should not create functional troubles in older user agents that do not support the functionality."

Avoid mention of browsers.


=======
---> "should work reasonably well" is not compatible with "do not support". Either there is a partial support, or either there is no support at all. For example, Loading an HTML 5 document with an HTML 4 authoring tool might create some troubles in some cases. Same thing for converter. This principle has been written with only one category of browsers in mind.
=======
Sander Tekelenburg Agree
Nik Thierry Agree
Andrew Maben Strongly Agree
Ben Boyle Strongly Agree Further to this, I think new features should be made as accessible as possible. For example, contents of a new attribute will likely be "hidden" from legacy UAs, whereas contents of a new element should be rendered (though the semantics of the new/unknown element will not apply). Both techniques are useful, varying depending on the situation.
James Graham Strongly Agree
David Singer Strongly Agree
Masataka Yakura Strongly Agree
Lachlan Hunt Strongly Agree
Michael Cooper Strongly Agree
Jason White Agree
Monika Trebo Strongly Agree
Dylan Smith Neutral
Schalk Neethling Strongly Agree
Laura Carlson Disagree As stated in the survey instructions,
Disagree = Some changes are needed.

Replace the first sentence with Karl's suggested sentence: "HTML documents that include markup for new features should not create functional troubles in older user agents that do not support the functionality."

Avoid mention of browsers.

Also change the example to a generic <newelement> fallback </newelement> instead of <canvas> fallback </canvas>, because we do not know if canvas will in fact be a new element in the final spec. This principle makes that assumption. But the element may not stand the test of time.
Philip TAYLOR Disagree "<canvas> fallback </canvas>. Older user agents will show "fallback" while user agents supporting canvas will show the element." Design principles should not cite proposed elements, since by so doing they may later be interpreted as supporting that proposal. Examples in the Principles should use either existing (HTML 4.01) elements/attributes, or nonce elements/attributes that do not (and are not likely to) form a part of the draft specification.
Richard Ishida Disagree See comments at http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html
Benoit Piette Agree
Marcin Hanclik Strongly Agree
Gregory Rosmaita Strongly Agree this is an essential principle
Leif Halvard Silli Disagree Avoid mention of browsers (see related comments of Karl Dubost and Laura Carlson and others.)
Dan Connolly Agree I don't think <canvas> is a good example. Perhaps <article>?
David Baron Strongly Agree

4. principle "Do not Reinvent The Wheel"

Do you support the "Do not Reinvent The Wheel" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 39
Agree 24
Neutral 9
Disagree 7
Strongly Disagree 1

Details

Responder principle "Do not Reinvent The Wheel"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Neutral
Michael Puls II Agree
Jason Turnbull Agree
Ian Massey Strongly Agree
Chris Adams Neutral
Weston Ruter Strongly Agree
Thomas Bradley Agree
Danny Liang Strongly Agree
Stephen Duncan Neutral
Dannii Willis Strongly Agree
Andrew Fedoniouk Disagree Depends on the quality of the wheel.
As an example: @contenteditable is not a solution.
Something like <htmlarea> input element would benefit Internet better.
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Strongly Agree
Sajid Saiyed Agree
Bill Mason Strongly Agree
Stéphane Deschamps Agree As much as possible. Sometimes it may be good to propose new solutions even if the ones in use seem obvious -which they are not always (for example legend for images is way more elegant than basic @alt for non-visually-impaired people).
Razvan MIHAIU Agree
Julian Reschke Neutral Depends on how well the wheel works.
Egor Kloos Agree
Craig Buckler Agree
Bob Hopgood Strongly Agree CSS is a widely used and implemented technology so HTML 5 does not need to consider presentation, only markup.
Shawn Medero Agree
Matthew Otto Strongly Agree
Andrew Sidwell Strongly Agree
Dimitri Glazkov Strongly Agree
Craig Saila Agree
Patrick Taylor Agree
Steve Faulkner Agree
Dean Edridge Neutral I'm concerned that in some cases the current 'wheel' has been invented to solve problems of the past and people assume this is sufficient for the future. Problem is, it's 2007 now, and we need to be creating a spec that can compete with proprietary technologies that offer resolution independence and other benefits. This just needs to be kept in mind that's all.
Marc Drumm Strongly Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Agree Couldn't this just be "Pave the Cowpaths"? Trying to think how to slim these principles down.
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Agree
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Agree
Brian DeRocher Disagree
Josh Lawton Strongly Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Agree
Anne van Kesteren Strongly Agree
Roger Johansson Neutral If the wheel is a good wheel, yes. But if there is a better way of solving the problem we should specify that instead.
Joshue O Connor Strongly Agree "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."

While I agree that the spec must progress, existing and functional implementations and methods should be conserved where needed, improved where possible and may the group find the wisdom to recognise the difference.

[1] http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html?rev=HEAD#do-not-reinvent-the-wheel
Maurice Carey Neutral Frontier wagon wheel != 24 inch Spinna Rims

They're both wheels. They both roll. But you're not going to put wooden wagon wheels on your Escalade.

Some wheels need reinventing. Some don't. Some need to be standardized to work in all browsers.

We shouldn't force an improvement to be out of the question just because some authors have some convoluted workaround that luckily works or because some WG members follow the HTML Design Principles document religiously to the letter without thinking.
Scott Turner Strongly Agree
Karl Dubost Disagree 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.

Again it is not clear what widely used and implemented technology means. For example, "q" is not implemented, except if we count the built-in style that some browsers applied to the element. How many applications parsing HTML document really use the element "q" for its meaning, using the cite attribute on it, etc.

"Sometimes, though, new use cases may call for a new approach instead of more extensions on an old approach." This sentence goes against the principle itself. If we do such comments of the type Pro/Con, then we have to do it for each principle.
Sander Tekelenburg Disagree As someone else said, it depends entirely on the wheel whether it should be reinvented or not.
Nik Thierry Disagree If that wheel is old, or even punctured, then building something that can help move forward with more speed in the long term seems like a great idea.
Andrew Maben Strongly Agree
Ben Boyle Agree
James Graham Strongly Agree
David Singer Strongly Agree
Masataka Yakura Agree
Lachlan Hunt Agree
Michael Cooper Agree
Jason White Strongly Agree
Monika Trebo Disagree depends. If the wheel works well across platforms and browsers, we might keep it. But then, what is the definition of "widely used and implemented"?
Dylan Smith Agree
Schalk Neethling Agree
Laura Carlson Strongly Disagree Drop this principle. It is ambiguous. This principle starts by saying we 'should' and immediately turns around and says but sometimes we can't. An indecisive principle like this will not be an aid to decision making but only worsen the discourse. Doublespeak often results in communication bypass.

"Widely used" is a subjective term. How can this principle be applied fair and consistent manner? I agree with Andrew Fedoniouk that the principle depends on the quality of the wheel. How can that quality be measured? Some wheels may need reinventing. Some may not.
Philip TAYLOR Neutral I would prefer "do not re-invent the wheel unnecessarily"
Richard Ishida Agree See comments at http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html
Benoit Piette Agree
Marcin Hanclik Strongly Agree
Gregory Rosmaita Neutral whose wheel are we referring to? that defined by HTML 4.01, its corrections, addenda, and errata?

i am against the codification of features and markup that is not standardized across platforms and which may, therefore, "break" the web for users of "legacy technology"

simply because feature x or element y work in a particular user agent, and is mimiced by others, does not mean that a new and improved wheel has been created. any such "wheels" need to be vetted on an individual basis to address i18n, device independence, media independence, and accessibility for persons with disabilities.
Leif Halvard Silli Disagree Delete «Sometimes, though, new use cases may call for a new approach ...».

This principle seeks to justify that we are positive about making implemented proprietary solutions into standard solutions (if and when this seems like a good solution) - as opposed to inventing parallell/competing solutions. That we also need new solutions, is another matter.
Dan Connolly Strongly Agree I prefer a positive phrasing, such as... hmm... maybe it's OK as is.
David Baron Strongly Agree

5. principle "Pave the Cowpaths"

Do you support the "Pave the Cowpaths" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 25
Agree 27
Neutral 13
Disagree 7
Strongly Disagree 5

(3 responses didn't contain an answer to this question)

Details

Responder principle "Pave the Cowpaths"Comments
Mark DuBois
Edward O'Connor
Daniel Morrison
Matthew Freels Strongly Agree
Michael Puls II Agree
Jason Turnbull Agree
Ian Massey Agree The example of <br/> is ambiguous, since it is a case of shared syntax with a member of the same language family. In this case, it's a great idea, but these should be evaluated on a case-by-case basis, this question generalizes the issue too much.
Chris Adams Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Neutral
Stephen Duncan Agree
Dannii Willis Agree
Andrew Fedoniouk Agree
Jon Barnett Strongly Agree I like how the word "consider" is used. We should not be tied to these requirement, but they have weight in consideration.
Frank Palinkas Strongly Agree
Carol King Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Agree The explanation for this principle is a bit thin. Ideally I would like to see more reasoning about why it's better to work with existing people and content on the Web rather than force them into a new and different model. More or better examples would also be helpful.
Sajid Saiyed Agree
Bill Mason Strongly Agree
Stéphane Deschamps Neutral I'm very wary of this point. We have to be very cautious so as not to pave the wrong cowpath.
Razvan MIHAIU Neutral To follow or not to follow a "cow path" is a decision that needs to be done on a case by case basis. This principle is too generic to be able to give an answer before looking at the details. That means that there is no principle of "Pave the Cow paths" or at least it shouldn't be in any dynamic organization.

People shouldn’t write new applications that build upon bad practices already in place in a business or organization. New applications are a chance to get things right and should be used as an opportunity to ask the challenging questions about why things are the way they are and what can be done better.

In other words, always keep an open mind and "pave the cow path" only after a careful analysis of the problem that needs to be solved.
Julian Reschke Disagree A cowpath is a sign that many people want to achieve something. But just paving it may be the wrong solution. For instance, microformats are widely used, but do not scale, while other solutions (role/RDFa) might.
Egor Kloos Strongly Agree
Craig Buckler Agree
Bob Hopgood Neutral It depends on the cowpath. Some make sense others don't.
Shawn Medero Strongly Agree
Matthew Otto Disagree This would depend on the practice. Just because it is widely adopted doesn't mean that it should be accepted.
Andrew Sidwell Agree I feel the name should be changed; working on a post about this.
Dimitri Glazkov Strongly Agree
Craig Saila Agree Assuming that the widespread practice makes sense within HTML's syntax and doesn't conflict with the other points.
Patrick Taylor Agree
Steve Faulkner Neutral
Dean Edridge Agree Yes, but I think that people need to be guided towards changing their bad habits. For example: support <br/> in html(text/html) by all means, but educate people into using <br> when authoring in future so at least one day html mark-up will become more consistant.
Marc Drumm Strongly Agree
Henri Sivonen Agree This is probably the most misunderstood principle. It needs more careful explanation.
Daniel Schattenkirchner Strongly Agree
Kai Hendry Strongly Agree
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Neutral
Robert Burns Neutral I like the catch phrase part, but I'm not so sure about the ways this has been interpreted. To me the PAVING part is often overlooked. For example, authors using class names to encode semantics such as 'copyright' certainly constitutes a cowpath. To me PAVIING the cowpath doesn't involve simply a nod and a wink and a thumbs up saying: "good work". It involves picking up on those semantics and often assigning new NCName facilities (i.e., a new element, attribute, or enumerated value name) into HTML (and, e.g., not just starting our own microformats class registry).

The other concern is that it sometimes gets applied to bad authoring practices: practices that can be harmful to users. Here is seems to be used to say: "well authors are going to do it anyway, so we might as well make it part of the recommendation." The recent @alt language that authors must omit @alt is a good example of that.

On the other hand, the example in the principles document is a rather good example of a practice that harms nothing and so should not lead to conformance flag headaches for authors.
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Agree
Brian DeRocher Disagree
Josh Lawton Strongly Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Disagree Needs to be reformulated to make it perfectly clear that it is not talking about adopting and encouraging widespread bad practices. Wasn't this reformulated on the list recently?
Joshue O Connor Disagree Many of these principles are subjective, this one moreso. So an author may say, why should I not continue to use <font>, tables for layout etc, I have been doing it for ages and this principle seems to back up that argument.

I find it as a principle one of the most ambiguous and mimetic, while many of the others are just vague. It sounds great. If the cows don't end up over a cliff or bad practices don't become ingrained because its the way its always been done. It conjures up organic and wholesome images which are attractive however depending on who is arguing what point, it is very open to manipulation.
Maurice Carey Agree
Scott Turner Strongly Agree I feel this expands the principle "Support Existing Content" in a positive manner.
Karl Dubost Strongly Disagree I understand the intent of the principle but it is so wide, that it is meaningless. It really on the type of authors community. A practical example of that is Weblogs software. Frontier from Userland Software had created one of the first platform offering an easy way to create weblogs, but mainly was a huge engine to create tag soup. When Movable Type and later on, Wordpress appeared, the situation changed a lot. Even if not perfect the quality of the code produced by these tools improved a lot.

There are some practices which are widespread in some communities and not in some others. Authoring practices should take into account ease of authoring, usability, etc. but not based its rules on the fact that many people do not master the language. Read my article about craft of HTML. People creating good chairs will not lower their business rules because most of the chairs in the world are crap. Most of the people are drunk driving on friday night, let's declare friday night for drunk drivers.

The principle has been written in a browser perspective. Recovering bad content is good. Making bad authoring practices a rule is NOT good. (I could also use an example with language in oral communication.)
Sander Tekelenburg Neutral The word "consider" makes this Design Principle pretty meaningless, but thus also harmless.
Nik Thierry Neutral
Andrew Maben Neutral
Ben Boyle Agree Some better wording could differentiate this from the Do Not Reinvent the Wheel principles.
James Graham Agree Text that indicates that cowpaths need not be paved by copying the exact behaviour of authors where this has significant problems.

Lachlan's example of using <video> to replace flash content is an example of this.
David Singer Agree
Masataka Yakura Neutral
Lachlan Hunt Agree
Michael Cooper Agree
Jason White Disagree This principle could allow adoption of widely used practices that are undesirable
on other grounds, thus perpetuating those practices by giving them the legitimacy of having been specified in HTML 5.
It also overlaps with Principle 2.3. I would suggest deleting it or explicitly restricting it to practices that are considered desirable and healthy for the evolution of the Web.
Monika Trebo Disagree pave the cowpaths if something works really well and "there is no harm done by allowing that to be used". What is the definition of "and there is no harm done"? Can we rephrase that to be more specific as to what we consider harmful? I personally consider <font> harmful, as it causes code bloat, but it does not cause pages to break. Would we consider something that is widely used, but not cross-platform, not cross-browser compatible, not device-independent harmful? We should be careful not to adopt bad practices, just because they are widely used.
Dylan Smith Neutral I prefer elements styled like <br />, etc. But support for this principle shouldn't imply support for table-based layouts, non-semantic markup, and other awful code, just b/c it's 'widespread.'
Schalk Neethling Neutral
Laura Carlson Strongly Disagree As stated in the survey instructions,
Strongly Disagree = No support. Delete it.

Drop this principle. It is ambiguous and confuses productive discussion. We have went round and round on this principle (over 75 posts on the mailing list) and still can not come to agreement. It is too ambiguous. It is an indecisive principle that will not be an aid to decision making but only worsen the discourse.

Just because something is widely adopted doesn't mean that it should be accepted. As with HTML 4, many authors may not have taken advantage of certain features, but some certainly did. Just ditching one feature because it's less used (or used incorrectly by well-meaning, but mistaken authors) takes away from the language, as it then forces the knowledgeable authors who were indeed using those features correctly to adapt to a lowest common denominator, impoverishing their content in the process.

Some use cases may make sense others don't. And the "Paving" the way to bad practice because it is widely adopted doesn't mean that it should be accepted.
Philip TAYLOR Strongly Disagree The example cited ("Authors already use the <br/> syntax as opposed to <br> in HTML and there is no harm done by allowing that to be used.") has totally different meanings in HTML and in XHTML : the question totally overlooks this, and pretends that there is "no harm" in allowing markup that would, were browsers to properly follow the HTML specification, cause an effect entirely different to that which the author expects.
Richard Ishida Agree See comments at http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html
Benoit Piette Agree
Marcin Hanclik Agree Bad content should remain bad content, though.
Gregory Rosmaita Strongly Disagree cattle are notoriously bad navigators, known to go far out of the way when encountering an obstacle -- for example, it is not uncommon for cattle ranchers to surround their territory not only with fences and barbed wire, but by simply digging a steep trench, deeper than a cow is tall, to keep them penned in without an actual "pen"
; what's more, they are subject to the "herd mentality" which a standard setting organization such as the W3C should strongly discourage...

what is needed is not a principle of "pave the cowpaths", but the principle "apply ockham's razor" [1] -- don't follow the meanderings of the herd, when a more direct solution is superior.

[1] http://en.wikipedia.org/wiki/Ockham%27s_razor
Leif Halvard Silli Strongly Disagree As Karl Dubost says, this has a browser perspective: «Recovering bad content is good. Making bad authoring practices a rule is NOT good.»

The debates we have had in public-wg, has also revealed this principles as fruitless: Is it about identifying positive things? Many tried to use it that way. But as it is explained in the editors draft, it is just about accepting certain wrongs (<br/>) which in the end perhaps do not lead to any harms.
Dan Connolly Strongly Agree I have followed this principle for years, though I called it
"Standardize what people do".
David Baron Strongly Agree

6. principle "Evolution Not Revolution"

Do you support the "Evolution Not Revolution" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 31
Agree 35
Neutral 8
Disagree 6
Strongly Disagree

Details

Responder principle "Evolution Not Revolution"Comments
Mark DuBois Agree
Edward O'Connor Strongly Agree
Daniel Morrison Agree
Matthew Freels Agree
Michael Puls II Agree
Jason Turnbull Agree
Ian Massey Strongly Agree
Chris Adams Agree
Weston Ruter Strongly Agree
Thomas Bradley Agree
Danny Liang Agree
Stephen Duncan Agree
Dannii Willis Agree
Andrew Fedoniouk Agree
Jon Barnett Agree This shouldn't preclude drastic, novel new features, but such features must function alongside existing features.
Frank Palinkas Strongly Agree
Carol King Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Strongly Agree
Sajid Saiyed Strongly Agree
Bill Mason Neutral
Stéphane Deschamps Strongly Agree No XHTML2 fiasco anymore... ;)
Razvan MIHAIU Agree
Julian Reschke Agree
Egor Kloos Strongly Agree
Craig Buckler Strongly Agree
Bob Hopgood Strongly Agree But evolution implies that some features become extinct. Evolution does not imply backward or forward compatibilty. It is more an expression of rate of change.
Shawn Medero Agree
Matthew Otto Agree
Andrew Sidwell Strongly Agree
Dimitri Glazkov Strongly Agree
Craig Saila Agree
Patrick Taylor Strongly Agree
Steve Faulkner Agree
Dean Edridge Agree
Marc Drumm Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Strongly Agree Does this mean HTML5 will be coming out (as recommendations) in drips and drabs?

Be good if there was some evolutionary process to HTML's "policy" like Debian does it.

Though I think in this principle you generally mean we won't abandon HTML.
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Agree
Robert Burns Strongly Agree
Ian Hickson Agree I agree strongly with the principle but the current text is way too confusing. Recommend that this be completely restated. (I've tried looking for an alternative wording and failed, though.)
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Neutral
Josh Lawton Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Agree
Anne van Kesteren Strongly Agree
Roger Johansson Neutral
Joshue O Connor Disagree Should it be a principle at all? It depends on context. When something does not work and there is a need for change, then revolt. When something is organically improving, it evolves.
Maurice Carey Agree but I think <video> counts as a Revolution
Scott Turner Strongly Agree In many ways I feel evolutionary design and pave the cow paths are the same concept. One of the keys to evolution, at least as we currently understand it is: survival of the fittest. Paving cow paths could be viewed as natural selection in action, don't adopt potentially fatal changes to the core until they have had a chance to be tested for survivability.

Karl Dubost Disagree Remove "Revolutions sometimes change the world to the better." I suggest to change the principle to "Promote progressive design"

Evolving an existing design in a way that old patterns benefit from the new features is better for authors. They can smoothly adapt to new models still managing their old content. For implementers, it makes easier the development, and then the chances of adoption of the new features.
Sander Tekelenburg Agree
Nik Thierry Disagree
Andrew Maben Strongly Agree
Ben Boyle Strongly Agree (see comment for degrade gracefully)
James Graham Agree But the wording seems clumsy. Maybe something like:

Prefer to designs that allow integration new features with old content without having to make unrelated changes, thus making a seamless transition between old and new. Implementers should be able to add new features to existing code, rather than having to switch to HTML 5-specific modes.
David Singer Strongly Agree
Masataka Yakura Neutral
Lachlan Hunt Agree
Michael Cooper Neutral Not sure I understand the implications of this, would like more examples.
Jason White Disagree Sometimes, the only way to correct design choices which have been shown to lead to negative consequences, is to discard an old design and create something new.
This principle creates a presumption in favour of existing designs which is unwarranted. Further, it is redundant with "support existing documents" and "do not reinvent the wheel".
Monika Trebo Neutral evolution instead of revolution may be more author friendly, but may as well slow down necessary changes. If something has the potential to evolve, it should and will. We should not shy away from implementing revolutionary new features, as long as they function alongside with older ones.
Dylan Smith Agree
Schalk Neethling Neutral
Laura Carlson Neutral
Philip TAYLOR Disagree I support the words, but not the sub-text. By "Evolution", we should be starting from HTML 4.01 Strict (and from its "Design Principles", which are superbly stated); instead we are starting from what the WHAT WG argue was a "blank sheet", yet which is in practice a bastardisation of HTML together combined with a number of hobby horses.
Richard Ishida Agree
Benoit Piette Agree
Marcin Hanclik Strongly Agree
Gregory Rosmaita Agree evolution not only entails the growth and maturity of new features, but also the loss of features that provide nothing more than a quick path to extinction.
Leif Halvard Silli Disagree I lend my vote to Karl Dubost: «Promote progressive design»
Dan Connolly Agree "one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes." is clear, but the "Specifically, this means that ..." lead-in says the bumper-sticker rendition isn't clear on its own. I can't think of a suggestion, though.
David Baron Strongly Agree

7. principle "Solve Real Problems"

Do you support the "Solve Real Problems" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 34
Agree 25
Neutral 10
Disagree 4
Strongly Disagree 7

Details

Responder principle "Solve Real Problems"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Agree
Michael Puls II Agree
Jason Turnbull Agree
Ian Massey Strongly Agree
Chris Adams Strongly Agree
Weston Ruter Agree
Thomas Bradley Strongly Agree
Danny Liang Neutral
Stephen Duncan Neutral
Dannii Willis Agree
Andrew Fedoniouk Agree
Jon Barnett Neutral This is not specific enough as we don't seem to agree on what constitutes a "real problem" or how to present that "real problem" before attempting to solve it.
Frank Palinkas Strongly Agree
Carol King Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Agree The last sentences could be worded better. It may also be worth stressing that HTML should solve real problems *in the realm of HTML* rather than borrowing problems or solutions from other fields.
Sajid Saiyed Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree
Razvan MIHAIU Agree
Julian Reschke Neutral This principle opens the door to dismiss proposals as not solving "real" problems. I agree with the second part: "And existing widespread problems should be solved, when possible.", though.
Egor Kloos Strongly Agree
Craig Buckler Agree
Bob Hopgood Agree I agree we should solve real problems but that does not mean all solutions have to be pragmatic. A good theoretical solution may still be possible.
Shawn Medero Strongly Agree
Matthew Otto Agree
Andrew Sidwell Disagree working on a post about this
Dimitri Glazkov Strongly Agree
Craig Saila Agree Only if the real world problem is genuine, and cannot, or is not, addressed by existing technologies and solutions (i.e., can it be done in CSS? JavaScript? is there already an element for what is being proposed, not matter how limited it's adoption is [e.g., OBJECT])
Patrick Taylor Agree
Steve Faulkner Neutral
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Agree This principle needs explanation what is or isn't a Real Problem. That is, it should say that we shouldn't imagine up problems for solving if the expected beneficiaries of solving the supposed problem have never articulated that the problem needs solving nor has no one observed notable silent suffering from the alleged problem.

For example, we shouldn't imagine problems related to implementing search engines and engineer solutions to the problems if search engine developers don't ask us to solve a particular problem.
Daniel Schattenkirchner Strongly Agree
Kai Hendry Strongly Agree
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Agree
Robert Burns Strongly Disagree While all of the other principles can potentially bolster positive or negative results, this one I think has no positive benefit for the WG. No one joins a WG and volunteers their time to solve fantasy problems. Yet this design principle suggests that they might. It seems its only purpose this principle could be for is to disparage other WG member's key problems and issues as "non-real".
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Agree
Josh Lawton Strongly Agree
Robert Marshall Neutral
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Neutral
Anne van Kesteren Strongly Agree
Roger Johansson Strongly Disagree It is unclear what a "real problem" is, so this principle is just confusing. Who does not want to solve real problems?
Joshue O Connor Disagree What does it mean?
Maurice Carey Strongly Agree
Scott Turner Strongly Agree It has been my personal experience that abstract problems sometimes come with abstract requirements that don't match up well with reality when it is finally encountered. You then are left with supporting behavior just in case someone was already using it, that is otherwise awkward for the specifications based upon actual reality.
Karl Dubost Strongly Disagree This sentence is totally meaningless. Every person has a real problem, be practical or theoretical or pragmatical. People argue about a feature because they want it.

What you want to say maybe is "design by implementations" such as if the feature is being implemented and demonstrated as being interoperable, then the feature is not only a wish, but something which will be immediately usable in a very near future.
Sander Tekelenburg Disagree "Real Problems" means different things to different people. There have already been so many disagreements on the list regarding what this principle refers to that it might be wiser to throw it out. (We could try to make it more specific, so that it actually does mean something; a discussion of what "Real" is might be healthy. I have my doubts we will be able to reach consensus though.)
Nik Thierry Agree I think pushing things forward, eliminating old code/practices will help cull a lot of older problems (it will probably also bring new ones, but that is evolution for you)
Andrew Maben Strongly Agree
Ben Boyle Agree Agree, but we should also be building a robust foundation for future growth. A clear measure for a "real problem" is needed.
James Graham Agree Although I think there will be disagreement about what constitutes a real problem. Perhaps adding some text indicating that a feature for authors should be added only if there is evidence of significant demand for that feature from actual authors (for example, cases where the lack of the feature is being worked around) and similarly for implementers and other groups.
David Singer Neutral This could be better phrased as talking about supporting use cases, existing problems on the web, clear opportunities. However, we all are capable of raising problems that are only potential or theoretical, and if solving them introduces other, real, problems, there should be push-back.
Masataka Yakura Neutral
Lachlan Hunt Agree
Michael Cooper Agree
Jason White Strongly Disagree This principle provides no guidance in determing what is a real problem. It is also redundant due to the
"priority of constituencies" principle: if something is a problem for users, authors, implementors or specifiers then it is surely a real problem (whatever that means.)
Furthermore, the principle overlooks an important class of problems, those namely that would be created by making particular design choices in the spec itself. These are not "real problems" today, but would become so in the future if design choices were made - and it is important to adopt designs that avoid creating anticipated problems in the future, once the language has been implemented and deployed.
Monika Trebo Strongly Disagree I agree with those who state that this is not specific enough and the definition of a "real problem" is subjective.
Dylan Smith Agree There are, of course, disagreements over what a 'real problem' *really* is. Building consensus on what needs addressing seems to be the most difficult task.
Schalk Neethling Strongly Agree
Laura Carlson Strongly Disagree As stated in the survey instructions,
Strongly Disagree = No support. Delete it.

Drop this principle. The definition of a "real problem" is subjective. It will only cause miscommunication. It is an indecisive principle that will not be an aid to decision making but only worsen the discourse.
Philip TAYLOR Neutral Solving real problems is all very well, but it can only ever be a starting point. We need to think more freely, more "out of the box" as some might put if, if our efforts are to achieve something truly worthwhile.
Richard Ishida Strongly Agree
Benoit Piette Strongly Agree
Marcin Hanclik Disagree How to verify whether a problem is "real"?
Gregory Rosmaita Strongly Agree this is one of the cornerstones of interoperability, accessibility, usability, and internationalization.

accessibility features are particularly important "real problems", not theoretical constructs. there is an entire activity at the W3C devoted to addressing the real problems that confront users with disabilities. (http://www.w3.org/WAI)
Leif Halvard Silli Strongly Disagree I cannot see this principle as an serious «attempt to capture consensus on design approach»

This principle has the undertone of «some of you are looking to solve purely theoretical problems».
Dan Connolly Agree I saw some chat about renaming this to "Support Use Cases With Evidence". I like that. "Real" has off-putting connotations.
David Baron Strongly Agree

8. principle "Priority of Constituencies"

Do you support the "Priority of Constituencies" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 44
Agree 25
Neutral 8
Disagree 2
Strongly Disagree 1

Details

Responder principle "Priority of Constituencies"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Agree
Michael Puls II Strongly Agree
Jason Turnbull Strongly Agree
Ian Massey Strongly Agree
Chris Adams Agree
Weston Ruter Agree
Thomas Bradley Strongly Agree
Danny Liang Neutral
Stephen Duncan Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Neutral
Jon Barnett Agree I can't suggest a specific change, but some solution that would best serve users are impossible. For example, some methods of specifying alternate content would serve users very well, and would be easy for implementers to parse, but would be impossible or too cumbersome for authors to use. I don't want to say that "authors" come first but authors and implementors have much for influence than other in what its used on the web.
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Strongly Agree Best principle yet.
Sajid Saiyed Strongly Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree
Razvan MIHAIU Strongly Agree
Julian Reschke Agree
Egor Kloos Disagree Making is easier for the user and harder for the implementer will in the end make it harder for the user as well. I agree with the philosophical point being made. However, I don't believe in altruism to the degree that seems to be required here.
Craig Buckler Strongly Agree
Bob Hopgood Neutral I do not see why users take precedence over authors. HTML is a language for marking up documents by authors. Users should be taken into consideration but that is what authors do if they want to be read.
Shawn Medero Agree
Matthew Otto Agree
Andrew Sidwell Neutral
Dimitri Glazkov Strongly Agree
Craig Saila Agree
Patrick Taylor Strongly Agree
Steve Faulkner Agree
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Agree Noting that we lack enforcement methods to make those with lower priority to comply to the benefit of those with higher priority and we should take the consequences of this reality into account. (That is, we cannot force authors to do something even if it would benefit users.)
Daniel Schattenkirchner Strongly Agree
Kai Hendry Agree Perhaps stated a littler clearer? "Our priorities are our users" DFSG-esque http://www.debian.org/social_contract
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Agree
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Agree
Brian DeRocher Agree
Josh Lawton Strongly Agree
Robert Marshall Neutral
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Agree
Anne van Kesteren Strongly Agree
Roger Johansson Neutral
Joshue O Connor Strongly Agree Good to see users getting an explicit mention.
Maurice Carey Strongly Agree I especially agree with specifiers and theoretical purity being last.
Scott Turner Agree I feel users are given too much priority. I feel the major constituency in the HTML standard are the content authors. I feel users are serviced by the content authors and users generally don't care what's in the content they feed upon so long as its tasty.
Karl Dubost Strongly Agree
Sander Tekelenburg Agree
Nik Thierry Neutral
Andrew Maben Strongly Agree
Ben Boyle Strongly Agree ... but how to do ensure this principle is upheld? Members of the WG represent some of these constituencies, unfortunately giving us all a conflict of interest.
James Graham Agree Although prioritising users over authors could be used as an argument for adding difficult-to-author features on the basis that if-used-correctly they would add significant benefits to the end user, ignoring the fact that they would rarely, if ever, be used correctly.

This could be solved by adding a principle like "Consider Human Factors", which states that we should take account of problems like the tendency of authors to provide incomplete or inaccurate metadata and the tendency of browsers to favour user experience over spec compliance.
David Singer Agree I'm not sure about users vs. authors. I like specs in which authors naturally "do the right thing". Is this preferring authors, who have an easy time, or users, who get the right thing?
Masataka Yakura Strongly Agree
Lachlan Hunt Agree
Michael Cooper Agree Agree with the order of priority - content must support users first. However, authors are almost as important or they'll never do what needs to be done for the users. Abstract theory is important to keep the model consistent and future-oriented, so should be emphasized a bit more here, but agree it shouldn't trump user benefits. A good theory should support benefits to users anyways.
Jason White Strongly Agree
Monika Trebo Agree
Dylan Smith Strongly Agree
Schalk Neethling Neutral
Laura Carlson Strongly Agree
Philip TAYLOR Strongly Disagree Strongly disagree. If we put enough effort into theoretical purity, all the other aspects will automatically follow; as it is, all we are likely to do is to rubber-stamp existing (bad) practice.
Richard Ishida Strongly Agree See comments at http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html
Benoit Piette Strongly Agree
Marcin Hanclik Strongly Agree
Gregory Rosmaita Agree i agree that the cascade of constituencies begins with the user, whose needs trump those of authors (who are often limited by the limitations of an authoring tool) and who can learn "best practices", unlike someone who cannot see or hear, who cannot simply "learn" to see or hear;

the cascade of priority of constituencies should be users (with a !important), authors, then implementors

i'm not sure what the term "theoretical purity" is intended to convey; what i do know is that the pursuit of producing semantically meaningful, well structured document instances and user interfaces must be considered from the very beginning and throughout the process of developing a technical recommendation.
Leif Halvard Silli Disagree The last sentence, «Of course, it is preferred to make things better for multiple constituencies at once», seems like an unneeded tail. First, it should not say that this is the preferred solution. Rather, it should say that this would be the _perfect_ solution.

I propose that we move this forwared to be the first sentence! And thenafter, we change the wording of it so that the paragraph begins this way: «A perfect solution make things better for multiple constituencies at once. But in case of conflict [...] »
Dan Connolly Strongly Agree
David Baron Agree I prefer the restatement (in terms of weights) to the original statement (in terms of "over"-riding).

9. principle "Media Independence"

Do you support the "Media Independence" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 62
Agree 14
Neutral 3
Disagree 1
Strongly Disagree

Details

Responder principle "Media Independence"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Neutral
Michael Puls II Strongly Agree
Jason Turnbull Strongly Agree
Ian Massey Strongly Agree
Chris Adams Strongly Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Strongly Agree
Stephen Duncan Neutral
Dannii Willis Strongly Agree
Andrew Fedoniouk Agree
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Strongly Agree
Sajid Saiyed Strongly Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree
Razvan MIHAIU Strongly Agree
Julian Reschke Strongly Agree
Egor Kloos Strongly Agree
Craig Buckler Strongly Agree
Bob Hopgood Strongly Agree
Shawn Medero Strongly Agree
Matthew Otto Strongly Agree
Andrew Sidwell Neutral somewhat confused about this; will
Dimitri Glazkov Strongly Agree
Craig Saila Strongly Agree
Patrick Taylor Strongly Agree
Steve Faulkner Agree
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Strongly Agree
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Agree
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Agree
Josh Lawton Strongly Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Strongly Agree
Joshue O Connor Agree
Maurice Carey Strongly Agree
Scott Turner Strongly Agree I feel this has been a major strength in HTML.
Karl Dubost Agree you might want to say that some of the differences are handled by conformance profiles.
Sander Tekelenburg Agree
Nik Thierry Agree
Andrew Maben Strongly Agree
Ben Boyle Strongly Agree
James Graham Strongly Agree
David Singer Agree
Masataka Yakura Strongly Agree
Lachlan Hunt Strongly Agree
Michael Cooper Strongly Agree
Jason White Strongly Agree
Monika Trebo Strongly Agree
Dylan Smith Agree
Schalk Neethling Strongly Agree
Laura Carlson Strongly Agree
Philip TAYLOR Strongly Agree By definition, HTML is a /Markup Language/ : markup languages must be medium-neutral, since they denote semantics rather than presentation.
Richard Ishida Strongly Agree
Benoit Piette Agree
Marcin Hanclik Agree http://lists.w3.org/Archives/Public/public-html/2007Aug/0659.html

Suggested text:
3.3. Media, Device and Platform Independence
Features should 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. On the other hand if
it is known that some feature cannot be supported in some environment
targeted by the specification, the feature must correspondingly be
marked as optional.

Interactive features should not be omitted merely because they can not
be represented in a printed document.

The general reflowability of HTML text makes it more suitable to
variable screen dimensions than a representation of exact glyph
positions.

A hyperlink can not be actuated in a printed document, but that is no
reason to omit the a element.
Gregory Rosmaita Strongly Agree i hold this truth to be self-evident...
Leif Halvard Silli Disagree WhatWg and W3C might have been in different worlds for a while, but it seems unneccesary to state that «A hyperlink can not be actuated in a printed document, but that is no reason to omit the a element.»

Media Independence and Universal Access converge. E.g. according to CSS, screen reader and graphical UAs are different media.

One could actually state the seemingly opposite principle: «HTML should be media dependent». Meaning that it should have a useful display in all media.
Dan Connolly Strongly Agree
David Baron Agree I think it's worth noting that designing features for media independence means more than making media independence possible -- it means making it easier for authors to write media-independent content than media-dependent content. (And without making the latter artificially hard.)

10. principle "Universal Access"

Do you support the "Universal Access" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 52
Agree 18
Neutral 1
Disagree 6
Strongly Disagree

(3 responses didn't contain an answer to this question)

Details

Responder principle "Universal Access"Comments
Mark DuBois
Edward O'Connor
Daniel Morrison
Matthew Freels Strongly Agree
Michael Puls II Strongly Agree
Jason Turnbull Strongly Agree
Ian Massey Strongly Agree
Chris Adams Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Strongly Agree
Stephen Duncan Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Agree
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Agree
Sajid Saiyed Strongly Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree
Razvan MIHAIU Strongly Agree
Julian Reschke Strongly Agree
Egor Kloos Agree
Craig Buckler Strongly Agree
Bob Hopgood Strongly Agree
Shawn Medero Strongly Agree
Matthew Otto Strongly Agree
Andrew Sidwell Strongly Agree
Dimitri Glazkov Strongly Agree
Craig Saila Strongly Agree
Patrick Taylor Strongly Agree
Steve Faulkner Disagree http://lists.w3.org/Archives/Public/public-html/2007Aug/0663.html
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Agree Steve Faulkner made a good case on the list for splitting up the aspects of universality.

However, I don't think naming a particular group (WAI) belongs in a design principle, even though it is a good idea to work with WAI.
Daniel Schattenkirchner Strongly Agree
Kai Hendry Neutral I do get "Media/device Independence" and "Universal Access" confused.

I prefer "Universal Access" to be called "Accessibility". I am a little worried we can get bogged down in WAI type triple-A verbosity.

"The road to hell is paved with good intentions"
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Agree
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Agree
Josh Lawton Strongly Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Disagree Strongly agree once "when possible" is removed.
Joshue O Connor Disagree Steve Faulkner mades a very good case for explicitly adding accessibility as a subset of Universal Access, that should be discussed.[1]

Principles or ideals like 'Universal Access', 'Design For All' etc sound great but there needs to be very concrete details that cover exactly *how* they will work and Steve's suggestion is a big step in the right direction. Otherwise as a principle is it merely empty posturing.

Also remove 'where possible', to me, this is noncommital legaleze.


[1]http://lists.w3.org/Archives/Public/public-html/2007Aug/0663.html
Maurice Carey Strongly Agree You should bold, underline, italicise and increase the font size of the second sentence.

"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."
Scott Turner Agree Universal access isn't just for those content users disabled by birth or accident. Eventually time catches up with many humans and renders them disabled to some degree.

I don't feel this section should use words such as "blind" and should emphasize that its usefulness will be to almost every single content user due to the ravages of time upon the body and mind

It appears to me that across the world many societies are facing a so called "Baby Boom" generation that will begin straining government and social services during the useful life span of the HTML 5 specification. I think it is critical that this issue become more visible so the web is not only convenient for the young to seek government and social services.

I think a key to this would be to change "provided when possible." to read "provided when necessary and where possible when non-necessary."
Karl Dubost Agree It would be good to mention accessibility. Note that this principle is overlapping with the previous one media independence, and the second about World Languages.

Sander Tekelenburg Agree
Nik Thierry Agree
Andrew Maben Strongly Agree
Ben Boyle Strongly Agree
James Graham Strongly Agree
David Singer Agree But this might need splitting; it means too many things to too many people. It conflates disabled access with other things, perhaps. The principles behind accessibility design should be thought through more -- notably, that we want a spec. in which accessible web content "happens normally", for example.
Masataka Yakura Strongly Agree
Lachlan Hunt Agree
Michael Cooper Strongly Agree Strongly object to the "when possible" at the end - it should not be consider optional to provide alternate mechanisms.

Instead of "but alternate mechanisms should be provided", suggest "but the specification must provide mechanisms to allow authors to provide alternate versions".

It may be a detail in the spec rather than a principle, but I think it would be a good idea for the spec to support multiple alternate versions of different media types, so motivate authors can provide different types of fallbacks for a single object. Related, the ability to provide a text fallback must always be present.
Jason White Agree This is subject to the deletion of "when possible". I would prefer a stronger statement such as
that proposed by Laura Carlson on the public-html mailing list.
Monika Trebo Strongly Agree
Dylan Smith Agree
Schalk Neethling Strongly Agree
Laura Carlson Disagree Changes need to be made. I fully support Steve Faulkner's proposal [1] for splitting up the aspects of universality.

Accessibility does deserve a principle of its own. Accessibility should not have an escape clause of "when possible" as the current principle has.

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.

Steve's example Accessibility Principle is excellent:

"Design features to be accessible, universal, and inclusive. Access by everyone regardless of ability is an essential. Deliverables will satisfy accessibility requirements. To ensure this we will work closely with the WAI<http://www.w3.org/2007/03/HTML-WG-charter.html#wai>."

[1] http://lists.w3.org/Archives/Public/public-html/2007Aug/0663.html
Philip TAYLOR Disagree Far too weak : re-cast as "but alternate mechanisms should be provided when possible" as "but alternate mechanisms must always be provided "
Richard Ishida Strongly Agree
Benoit Piette Strongly Agree
Marcin Hanclik Agree
Gregory Rosmaita Strongly Agree while i strongly agree in theory with "universal access" i am concerned about scope creep into this principle; not everything in the document source need be exposed to the user -- a TABLE summary is redundant for anyone looking at the table and automatically associating individual data cells with their headings, so there is no need for exposition of a summary, unless the user expressly requests it, in which case, it can be used as rendered explanatory text; universal access should mean that HTML5 provides strong enough mechanisms that support the concept of the semantic web, explicit meta-data bindings (both embedded and external), and markup flexible enough to be reused or reformatted/re-presented to the user in a form which is useable; in the end, the user must be the focus of HTML5, not solely authors, authoring tool developers, or user agent developers, although i do support strong conformance criteria for authoring tool and user agent conformance in the HTML5 draft;

i would also strongly support verbiage to the effect that:

"The HTML WG is committed to defining and providing features to make the web more accessible, universal, and inclusive. Access by everyone -- regardless of ability or experience -- is an essential component of universal access. The HTML5 WG is commited to retain features that provide access to all users, unless alternate/equivalent or superior mechanisms are provided in their place. The HTML WG's deliverables will satisfy the accessibility requirements which led Tim Berners-Lee to initiate the Web Accessibility Initiative as a W3C activity. To ensure that accessibility requirements are addressed and improved, the HTML WG will work closely with the WAI, and adhere to the Technical Recommendations which the WAI has produced."
Leif Halvard Silli Disagree Drop the «... when possible» addition in «but alternate mechanisms should be provided when possible.» It only serves to relativise the principle itself.

And who should the «when possible» be aimed at? The spec-writers? Or the authors?

The word «entirely» in «This does not mean that features should be omitted entirely ...» calls for the question: Can they be halfway dropped? Please drop the word «entirely» - entirely! :-)
Dan Connolly Strongly Agree I'd like a phrasing that obviates the need for "This does not mean...", but I can't think of one.
David Baron Agree I think it's worth noting that designing features for universal access means more than making universal access possible -- it means making it easier for authors to write accessible content than inaccessible content. (And without making the latter artificially hard.)

11. principle "Support World Languages"

Do you support the "Support World Languages" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 57
Agree 16
Neutral 2
Disagree 5
Strongly Disagree

Details

Responder principle "Support World Languages"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Strongly Agree
Michael Puls II Strongly Agree
Jason Turnbull Strongly Agree
Ian Massey Strongly Agree
Chris Adams Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Agree
Stephen Duncan Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Agree
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Strongly Agree
Sajid Saiyed Strongly Agree
Bill Mason Neutral
Stéphane Deschamps Strongly Agree side note: CJK needs an <abbr> for us world-languagers ;)
Razvan MIHAIU Strongly Agree
Julian Reschke Strongly Agree
Egor Kloos Strongly Agree
Craig Buckler Agree
Bob Hopgood Strongly Agree
Shawn Medero Strongly Agree
Matthew Otto Strongly Agree
Andrew Sidwell Strongly Agree
Dimitri Glazkov Strongly Agree
Craig Saila Strongly Agree
Patrick Taylor Strongly Agree
Steve Faulkner Agree
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Strongly Agree Do we need to state this? ;)
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Agree
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Strongly Agree
Josh Lawton Strongly Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Strongly Agree
Joshue O Connor Agree
Maurice Carey Agree
Scott Turner Disagree I feel Unicode has a Latin Language bias and if I were paying for bandwidth in a CJK society I'd prefer a more compact encoding system such as that designed into Unicode for Latin Languages. As these developing economies grow their online user bases the encoded content will grow along side them. The average bytes per glyph will shift as Latin becomes a smaller percentage of the online content.

And how honest is SWL when the tag's themselves all have a basis in Latin and are as meaningless to CJK content authors as Binary Encoded XML tags? Shouldn't SWL start with a proposal to allow separation of tag encodings from tag meanings? How much more approachable would HTML content authoring be if in the CJK a content author could specify that their content is marked up using a standard Chinese name space for HTML tags rather than a Latin one?
Karl Dubost Agree
You are giving the example of italics. There is a similar mechanism to italics for kanjis which is about putting dot under the characters. Some questions might be raised by this example.

Direction of languages is also a senstive topic, vertical layout is not handled by the most common browsers and HTML authoring tools.
Sander Tekelenburg Disagree I don't understand what " Features to represent a single web page in multiple languages are out of scope." means. Aren't @lang and @dir such features?
Nik Thierry Agree
Andrew Maben Strongly Agree
Ben Boyle Agree
James Graham Strongly Agree
David Singer Agree
Masataka Yakura Strongly Agree
Lachlan Hunt Strongly Agree
Michael Cooper Agree Unsure about "Features to represent a single web page in multiple languages are out of scope." I've had a lot of feedback that it is desirable to indicate that a given page is in multiple languages (not possible in HTML 4.0 - it's possibly to indicate changes of language but not globally indicate that it's a multilingual document). I wouldn't want that to be considered out of scope. If this is about a content negotiation style approach, I agree that would be out of scope. Perhaps clarify?
Jason White Agree I strongly support the principle, except for the exclusion of "features to represent a single Web page in multiple languages".
The working group should be free to discuss, and, if necessary, adopt such features. Declaring them out of scope in advance is
unwarranted and imposes an unjustified limitation on the proposals that the working group can consider. It is also unclear what would be in the scope of the exclusion.
Monika Trebo Strongly Agree
Dylan Smith Neutral
Schalk Neethling Strongly Agree
Laura Carlson Strongly Agree
Philip TAYLOR Disagree The second sentence : "Italics is useful because it applies to many bicameral scripts, even though some scripts have no such concept."
has no place in the design principles at all. Italics are purelypresentational, and should have no 1 : 1 correspondence with any HTML element or attribute. With the underlying concept of the principle, however, I strongly agree.
Richard Ishida Disagree See comments at http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html
Benoit Piette Strongly Agree
Marcin Hanclik Strongly Agree
Gregory Rosmaita Strongly Agree it is the world wide web -- need anyone say more?
Leif Halvard Silli Disagree I support Richard Ishida's comments about this principle at <http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html>.

Also, his comment (same URI) under «Don't Reinvent the wheel» is also relevant in showing how supporting Universal Access/Accessibilty goes hand in hand with World Languages: «... adapting <img> so that alt text is content rather than an attribute would be a big help [for] Arabic and Hebrew content who need to apply directional tags to their alt text.»

The negativeness expressed in the wording «features to represent a single web page in multiple languages are out of scope» unfortunatly goes hand in hand with the negativeness of the loudest voices of the WhatWg community when it comes to alternative content in general: LONGDESC, ALT etc.
Dan Connolly Strongly Agree
David Baron Agree I would go further and say that publication in all world languages should be easy. Authors writing in some languages shouldn't need to set ten attributes on the root element to make things work correctly.

12. principle "Secure By Design"

Do you support the "Secure By Design" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 52
Agree 18
Neutral 7
Disagree 1
Strongly Disagree 2

Details

Responder principle "Secure By Design"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Agree
Michael Puls II Strongly Agree
Jason Turnbull Strongly Agree
Ian Massey Strongly Agree
Chris Adams Strongly Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Agree
Stephen Duncan Strongly Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Agree
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Agree s/Preferrably/Preferably/; "the security model of the web" is vague. This is a principle and non-normative, so something like "evaluate features and the language as a whole from a security perspective and make the best choices for the users" would be more appropriate.
Sajid Saiyed Strongly Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree Of course I agree, although I don't see how that should be taken into account in a *descriptive* language like HTML?
Razvan MIHAIU Strongly Agree
Julian Reschke Strongly Agree
Egor Kloos Neutral
Craig Buckler Agree
Bob Hopgood Neutral I looked up 'security model of the web' on Google and found 5o different ones. No idea what this means. If you are going to use a phrase like this you need to point to what it means.
Shawn Medero Agree
Matthew Otto Agree
Andrew Sidwell Strongly Agree
Dimitri Glazkov Strongly Agree
Craig Saila Agree
Patrick Taylor Agree
Steve Faulkner Agree
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Strongly Disagree I don't think HTML5 designers can be expected to get security right. I prefer if we don't accept this responsibility.
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Strongly Agree
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Agree
Josh Lawton Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Neutral I have no idea what this means.
Joshue O Connor Strongly Disagree "Ensure that features work with the security model of the web."

Which model? Microsofts, IBM, some government model, open source PGP or whatever? There are also potential oppostites at work. For example accessibility and security are two forces (sic) that could be at logger heads. In many ways they are opposing principles. How can we make the web more accessible while still making it more secure? How can they be reconsiled? Which one will get the bums rush when the chips are down?

There are enough crimes being committed against our privacy and civil liberties at this point in our history all in the name of 'security' and that abased word 'freedom' to add to them with a vague and potentially damaging mantra like this.

I also wrote about this topic recently for those interested [1]

[1] http://www.w3.org/2007/02/dmdwa-ws/Papers/joshue-oconnor.html
Maurice Carey Strongly Agree
Scott Turner Strongly Agree The Internet has lost its innocence. Rapine, pillage and murder occur daily to HTML sites.
Karl Dubost Strongly Agree
Sander Tekelenburg Agree
Nik Thierry Neutral
Andrew Maben Strongly Agree
Ben Boyle Neutral
James Graham Strongly Agree
David Singer Strongly Agree To the greatest extent possible we should make it so that authors and implementors don't have the opportunity to be insecure, because the spec. is well-designed.
Masataka Yakura Strongly Agree
Lachlan Hunt Agree
Michael Cooper Strongly Agree
Jason White Strongly Agree
Monika Trebo Neutral
Dylan Smith Agree
Schalk Neethling Strongly Agree
Laura Carlson Neutral
Philip TAYLOR Disagree Again, the Principle cites a proposed feature : "Cross-document messaging is designed to allow this without violating security constraints" This should be deleted, and an abstract or artificial example substituted.
Richard Ishida Strongly Agree
Benoit Piette Strongly Agree
Marcin Hanclik Strongly Agree
Gregory Rosmaita Strongly Agree security is an important issue for disabled users, who often need to make a "leap of faith" that their browsing experience is safe and does not make them vulnerable to malicious code, trojan horses, phishing sites, and data-interception.

it is essential that accessibility not be sacrificed on the altar of security -- there are means of ensuring security that do NOT present barriers to users with disabilities, as has been discussed in various W3C fora -- particularly surrounding the issue of final form documents -- and the HTML WG should use such exchanges as a means of re-considering the "security trumps accessibility" straw man.
Leif Halvard Silli Agree Joshue O Connor is correct when he says: «accessibility and security are two forces (sic) that could be at logger heads. In many ways they are opposing principles.» CAPCHAS can be one example of that.

Presumabely the quoted example, cross-document messaging, is an example of how one might enable usability, as well as security, through working with the rules of the web.
Dan Connolly Agree shorten to "address security considerations directly in the specification."

I don't think "the security model of the web" has a clear referent; it's not worth the screen space.
David Baron Agree Might be good to say a little about what the security model of the Web is -- e.g., that any information accessible to script can be sent anywhere.

13. principle "Separation of Concerns"

Do you support the "Separation of Concerns" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 47
Agree 16
Neutral 5
Disagree 5
Strongly Disagree 3

(4 responses didn't contain an answer to this question)

Details

Responder principle "Separation of Concerns"Comments
Mark DuBois
Edward O'Connor
Daniel Morrison
Matthew Freels
Michael Puls II Agree
Jason Turnbull Strongly Agree
Ian Massey Agree I lean toward the "separation" side of the fence, but so long as this is permissible in a valid html 5 document, I don't see any reason to prevent other authors for writing less semantic code when they have reason to do so, except as I mentioned in comments for the 2nd principle.
Chris Adams Strongly Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Strongly Agree
Stephen Duncan Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Neutral
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Neutral
Brad Fults Strongly Agree
Sajid Saiyed Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree
Razvan MIHAIU Strongly Agree
Julian Reschke Strongly Agree
Egor Kloos Neutral
Craig Buckler Strongly Agree
Bob Hopgood Agree I agree that HTML should provide structural markup and not be concerned with presentation. I agree it is a lightweight markup with no profound and detailed semantics. But that does not imply b and i should remain. Evolution implies they should die some time (soon).
Shawn Medero Agree
Matthew Otto Strongly Agree
Andrew Sidwell Agree
Dimitri Glazkov Strongly Agree
Craig Saila Strongly Agree
Patrick Taylor Strongly Agree
Steve Faulkner Agree
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Agree I think the whole "separation of content and presentation" principle should be emphasised. Not so much the stuff in the Wiki which seems to dwell on the semantics of HTML....
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Strongly Agree
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Strongly Agree
Josh Lawton Strongly Agree
Robert Marshall Strongly Agree Possibly add hr as an example of pragmatic naming.
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Neutral It starts by talking about separating content and presentation and ends by saying that we should keep the b and i elements. But ok, as long as complete separation is possible.
Joshue O Connor Agree Though I tend to agree with Laura that it could be better written. "Separation of Concerns" is odd wording.
Maurice Carey Agree
Scott Turner Strongly Agree HTML can't expect content authors to explicitly design their content for visibility on all possible medias, some of which they won't have any clue to the existence of: like say a braille user agent. In many cases the special needs of these specialized medias are served best by being able to treat HTML definitions as guidelines rather than as absolute rules.
Karl Dubost Disagree The principle explains why it is good in one sentence and then goes on on why it is a bad idea… to apply this principle, that there are exceptions, etc.

I would rewrite this principle by really supporting the separation of concerns. For example for italics, it might be widely used, it doesn't mean it is a good practice. It just mean that the concept has not been understood.

In the spec, it could be dealed by.
* Browsers have to support feature X this way.
* Authors have to prefer this correct alternative way of using feature X.
* Authoring tools should avoid to use the feature X except in case Z. * Post processing tools can convert feature X into its alternate form.
etc.
Sander Tekelenburg Strongly Disagree This Design Principle cliams that mark-up define structure, ignoring that it also defines meaning. If that omission is intentional it should be explained. Also, I really can't agree with "Profound and detailed semantic encoding is not necessary if the end can be reached otherwise." lt leaves the door way too wide open for purely presentational mark-up, or non-mark-up (as in "equivalents need not be marked up as such").
Nik Thierry Neutral
Andrew Maben Agree
Ben Boyle Agree But I'd like to see this worded around HTML providing a foundation that other technologies can interface with (presentation being one possible purpose). I see the "separation" aspect being the responsibility of many technologies. HTML should support this, but it isn't appropriate for HTML to solve it entirely (and the wording feels a bit like we're saying it is, to me).
James Graham Strongly Agree
David Singer Agree But there are plenty of ways that web pages are made (e.g. from text processing documents) where "intent" is not available to the tool, only presentation.
Masataka Yakura Strongly Agree
Lachlan Hunt Agree
Michael Cooper Strongly Agree What is most important under this principle (from an accessibility perspective) is that authors not be tempted to use features for a purpose other than that for which they are designed. The debate about <strong> and <em> vs. <b> and <i> is a red herring - regardless which element is used, they convey the notion of emphasis, and authors tend not to use these when they don't intend to convey emphasis. However, the issue of tables used for layout is a crucial problem, because the interpretation of the table is dramatically different when used for layout, and is not defined by the spec. The reason this came about was because there wasn't another satisfactory mechanism for authors to achieve the layout effects they wanted, so they started abusing the table element. This sort of problem is becoming even more difficult these days - authors reuse all sorts of elements to create custom widgets, or use <div> and <span> without defined semantics. This is because there weren't elements for those widgets, or there wasn't sufficient ability to customize the display. This led to an accessibility nightmare and is a major reason we had create the ARIA specifications.

I think there are two major ways the spec needs to ensure that this principle is followed: 1) as much as possible, make sure authors aren't tempted to abuse semantics by providing the features they need without having to resort to workarounds; 2) define an easy extensibility mechanism to support new features through that mechanism rather than abuse of semantics.
Jason White Strongly Agree
Monika Trebo Disagree tend to agree with Laura and Roger on this.

I am not happy with the phrase "Profound and detailed semantic encoding is not necessary if the end can be reached otherwise". Semantic markup should be the rule for reasons of accessibility.
Dylan Smith Strongly Agree
Schalk Neethling Strongly Agree
Laura Carlson Disagree As stated in the survey instructions,
Disagree = Some changes are needed.

Needs rewriting. Split it into two principles one for Separation of Concerns and one for Semantics.

Ben Boyle proposed a design principle that: "All elements should have a clearly defined structural (semantic) meaning". For more information see Ben's post. [1] 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 [2].

[1] http://lists.w3.org/Archives/Public/public-html/2007Jul/0885.html
[2] http://lists.w3.org/Archives/Public/public-html/2007Aug/0002.html
Philip TAYLOR Strongly Disagree Far too weak. The entire principle needs to be re-cast to emphasise that the r\^ole of HTML is /Semantic Markup/, pure and simple. And a purported justification for the retention of <b> and <i> in a Principle supposedly supporting the Separation of Concerns is not only oxymoronic but ludicrous.
Richard Ishida Disagree See comments at http://lists.w3.org/Archives/Public/public-html/2007Aug/0958.html
Benoit Piette Agree
Marcin Hanclik Strongly Agree
Gregory Rosmaita Strongly Disagree i strongly disagree with this principle as expressed in:
http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html?rev=HEAD#solve-real-problems

i do NOT agree that "seperation of concerns" is a balancing act between "semantic expressiveness" and "practical usefulness"

any seperation of concerns is a fragmentation of what is supposed to be a coherent, technical recommendation; as i have posted to the HTML WG's mailing list, i believe in the "convergence of issues" principle

that being said, i would have voted for the principle were it stated simply as "Separation of Content from Presentation"
Leif Halvard Silli Disagree The 2nd example says «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.»

What does «try to ban them» mean? Our 2nd principle is «Support Existing content». That does not sound as «banning»?

Else I find that I agree with Karl Dubost and Laura Carlsson.
Dan Connolly Strongly Agree
David Baron Strongly Agree

14. principle "Well-Defined Behavior"

Do you support the "Well-Defined Behavior" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 61
Agree 10
Neutral 5
Disagree 2
Strongly Disagree 2

Details

Responder principle "Well-Defined Behavior"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Strongly Agree
Michael Puls II Strongly Agree
Jason Turnbull Strongly Agree
Ian Massey Strongly Agree
Chris Adams Strongly Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Agree
Stephen Duncan Strongly Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Agree
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Strongly Agree
Sajid Saiyed Strongly Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree
Razvan MIHAIU Strongly Agree
Julian Reschke Neutral This principle frequently is used to defend the current approach that behavior for any kind of broken input needs to be specified, with which I disagree.
Egor Kloos Agree
Craig Buckler Agree
Bob Hopgood Strongly Agree
Shawn Medero Strongly Agree
Matthew Otto Agree
Andrew Sidwell Strongly Agree
Dimitri Glazkov Strongly Agree
Craig Saila Strongly Agree
Patrick Taylor Strongly Agree
Steve Faulkner Agree
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Agree Well we can usually only do this in hindsight, with a reference implementation. ;) Perhaps it could come under the "Handle Errors" principle?
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Neutral
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Strongly Agree
Josh Lawton Strongly Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Strongly Agree As long as markup is conforming, behaviour should be well-defined.
Joshue O Connor Neutral I find it difficult to parse this. Though I agree with "This way, it is easier to author content that works in a variety of user agents. "
Maurice Carey Agree
Scott Turner Strongly Agree
Karl Dubost Disagree Dangerous. Typical example the search form with the magnifier of Safari, which led people to create invalid markup.
Sander Tekelenburg Strongly Disagree Given that the last sentence lists specific exceptions, this Design Principle appears to close the door for a UA to for instance render tables with fixed thead and tfoot and scrollable tbody; respect Content-Type; display equivalents side by side; not support javascript; etc.
Nik Thierry Agree
Andrew Maben Strongly Agree
Ben Boyle Strongly Agree
James Graham Strongly Agree
David Singer Strongly Agree
Masataka Yakura Strongly Agree
Lachlan Hunt Strongly Agree
Michael Cooper Strongly Agree
Jason White Strongly Agree
Monika Trebo Neutral
Dylan Smith Strongly Agree
Schalk Neethling Strongly Agree
Laura Carlson Neutral
Philip TAYLOR Strongly Disagree HTML 5 should be a specification for a markup language, not a specification of browser behaviour. The present draft specification tries to be all things to all men : it would be far better as a series of distinct documents, of which by far the most important would be the specification of the HTML 5 language, but of which "Preferred browser behaviour" might also well be one.
Richard Ishida Strongly Agree
Benoit Piette Agree
Marcin Hanclik Strongly Agree
Gregory Rosmaita Strongly Agree
Leif Halvard Silli Disagree Again we see how the principle first states one thing, and then relativises itself with a «however, implementations should still be free [to improve/do what they want]». The fact that UA vendors will naturally try to improve things, might just be stated as a fact, but one do not need to say that «they are free to etc». Improvements might eventually break the «support existing content» principle.

Alternative wording:  «The spec should describe well-defined UA behaviour that content authors could rely on, in preference to vague or implementation-defined behavior. »
Dan Connolly Strongly Agree
David Baron Strongly Agree

15. principle "Avoid Needless Complexity"

Do you support the "Avoid Needless Complexity" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 51
Agree 21
Neutral 2
Disagree 3
Strongly Disagree 3

Details

Responder principle "Avoid Needless Complexity"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Agree
Michael Puls II Agree
Jason Turnbull Strongly Agree
Ian Massey Strongly Agree
Chris Adams Strongly Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Strongly Agree
Stephen Duncan Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Strongly Agree
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Strongly Agree
Brad Fults Strongly Agree
Sajid Saiyed Strongly Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree
Razvan MIHAIU Agree The KISS principle is one of the most important in life in general, not only in software development. I can remember a few notable failures in the software industry because they didn't respect this principle, for example the fall of Netscape. Those people who used "Netscape Communicator" understand what I mean.
Julian Reschke Agree
Egor Kloos Strongly Agree
Craig Buckler Strongly Agree
Bob Hopgood Strongly Agree
Shawn Medero Agree
Matthew Otto Strongly Agree
Andrew Sidwell Strongly Agree
Dimitri Glazkov Strongly Agree
Craig Saila Agree
Patrick Taylor Agree
Steve Faulkner Agree
Dean Edridge Agree I guess the problem here is that not all people will agree on what complexities are needed and what's not needed.
Marc Drumm Strongly Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Strongly Agree Less is more :)
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Neutral
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Strongly Agree
Josh Lawton Strongly Agree
Robert Marshall Neutral
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Strongly Agree Well, duh, of course. Who actually argues for needless complexity?
Joshue O Connor Strongly Disagree Is there a need for this at all? And how is it to be interpreted or implemented as a principle? For example, if there is a difficult problem the group is tackling could a retort from someone *not* supporting a proposed solution be "It's too difficult, keep it simple, you are in breach of the avoid needless complexity principle?".

Conceivably, yes.

"But this should not be used as an excuse to avoid satisfying the other principles."

This is pointless as an addendum.
Maurice Carey Agree should maybe add that often it takes tons of complexity on the implementers end in order to give the authors and users the desired simplicity.
Scott Turner Strongly Agree
Karl Dubost Agree remove "But this should not be used as an excuse to avoid satisfying the other principles." this is true for all principles.
Sander Tekelenburg Agree
Nik Thierry Strongly Agree
Andrew Maben Strongly Agree
Ben Boyle Strongly Agree Although might be nice to word this in a positive tone: Keep it simple.
James Graham Strongly Agree
David Singer Disagree As stated, who would want *needless* complexity? Even re-phrased as "prefer simple over complex" would hardly warrant a discussion. The struggle is always between complexity and feature-richness and coverage. Perhaps "simple things should be simple; complex things might be possible" (shamelessly paraphrasing).
Masataka Yakura Strongly Agree
Lachlan Hunt Strongly Agree
Michael Cooper Agree
Jason White Agree
Monika Trebo Agree No one wants needless complexity, but who defines what is needed and what is needless?
Dylan Smith Strongly Agree
Schalk Neethling Agree
Laura Carlson Strongly Disagree As stated in the survey instructions,
Strongly Disagree = No support. Delete it.

Drop it. I'm not arguing for needless complexity :-) But term "Needless Complexity" is too subjective. The whole id/headers debate come to mind. Like Dean Edridge has said people will not agree on what complexities are needed and what's not needed. It is an indecisive principle that will not be an aid to decision making but only worsen the discourse.
Philip TAYLOR Disagree Again, I strongly agree with the Principle, but not with the supporting text. "But this should not be used as an excuse to avoid satisfying the other principles" is completely redundant, since the Principle speaks of "Needless" complexity, not complexity for its own sake.
Richard Ishida Strongly Agree
Benoit Piette Agree
Marcin Hanclik Agree It's quite subjective point, though.
Gregory Rosmaita Strongly Disagree some issues are complex by nature, and by avoiding them, the ML becomes weaker, rather than stronger; this is an author-centric and developer-centric idea -- it has little to do with the ultimate beneficiary of HTML's reform -- the end user
Leif Halvard Silli Disagree Again, the «when possible» phrase modifies. This is bad. I also support removing « But this should not be used as an excuse to avoid satisfying the other principles.» as this is true about all principles. «Needless» is also a subjective term. Avoid complexity is perhaps enough.

But I also wonder about the word «complexity»: «complex is the opposite of independent, while complicated is the opposite of simple.» [1]

The principle also needs better explanation.

[1] http://en.wikipedia.org/wiki/Complexity
Dan Connolly Agree prefer positive phrasing, such as "Maintain Simplicity"
David Baron Agree I think the statement that this principle is weaker than all the others should be removed. I think there are many cases where it should override others. Simplicity has the advantages already stated in the principle; these advantages should be weighed against the advantages of alternatives, not presumed to be smaller.

16. principle "Handle Errors"

Do you support the "Handle Errors" principle?

Summary

ChoiceAll responders
Results
Strongly Agree 44
Agree 21
Neutral 10
Disagree 3
Strongly Disagree 2

Details

Responder principle "Handle Errors"Comments
Mark DuBois Strongly Agree
Edward O'Connor Strongly Agree
Daniel Morrison Strongly Agree
Matthew Freels Agree
Michael Puls II Strongly Agree
Jason Turnbull Agree
Ian Massey Strongly Agree
Chris Adams Strongly Agree
Weston Ruter Strongly Agree
Thomas Bradley Strongly Agree
Danny Liang Neutral
Stephen Duncan Agree
Dannii Willis Strongly Agree
Andrew Fedoniouk Disagree There is some logical error in the statemnt "Error handling should be defined so that interoperable implementations can be achieved".

If you define error handling for grammar A then this effectively means that you define grammar B that is deriviation of A but is a different entity.
Jon Barnett Strongly Agree
Frank Palinkas Strongly Agree
Carol King Strongly Agree
Alexey Proskuryakov Disagree I think that the "prefer graceful error recovery to hard failure" part needs clarification. I do not necessarily disagree, but I don't quite understand the implications (e.g., are we going to introduce non-draconian XML parsing?!). Also, this principle often conflicts with 15 "Avoid needless complexity", and with 12 "Secure by design".
Brad Fults Strongly Agree
Sajid Saiyed Strongly Agree
Bill Mason Strongly Agree
Stéphane Deschamps Strongly Agree
Razvan MIHAIU Neutral To my knowledge, error handling is implemented by each browser in its own way. Changing this behavior so that the errors will be treated according to a specification will not be easy. Besides that, a generic error handling that fits every user is not possible. Publishers will want as much details as possible about errors while most users will want some graceful error recovery (this is not a rule because some users may want more details).

Perhaps the best way is to allow "graceful error recovery" by default but at the same time support plugins (that must be installed by the users themselves) that permit the extraction of more information about an error. Can such principles be embedded in a HTML design specification ?
Julian Reschke Neutral "Handling errors" seems to mean "hiding errors" most of the time. I'm ok with user agent vendors to collaborate to specify and harmonize error handling, but I strongly believe that does not belong into the specification of the language itself.
Egor Kloos Agree
Craig Buckler Agree
Bob Hopgood Agree
Shawn Medero Strongly Agree
Matthew Otto Strongly Agree
Andrew Sidwell Strongly Disagree
Dimitri Glazkov Strongly Agree
Craig Saila Agree
Patrick Taylor Strongly Agree
Steve Faulkner Agree
Dean Edridge Strongly Agree
Marc Drumm Strongly Agree
Henri Sivonen Strongly Agree
Daniel Schattenkirchner Strongly Agree
Kai Hendry Strongly Agree Error handling can be tricky to say the least. I think this is having a dig at XML, which turned its back on the fact that documents will probably be wrong. :)
Arthur Jennings Strongly Agree
Benjamin Meadowcroft Neutral
Robert Burns Strongly Agree
Ian Hickson Strongly Agree
David Andersson Strongly Agree
Geoffrey Sneddon Strongly Agree
Brian DeRocher Strongly Disagree
Josh Lawton Agree
Robert Marshall Strongly Agree
Scott Lewis Strongly Agree
Stephen Axthelm Strongly Agree
Stephen Stewart Strongly Agree
Raphael Champeimont Strongly Agree
Anne van Kesteren Strongly Agree
Roger Johansson Neutral User agents should make the user aware of errors. Users should obviously be able to disable such a feature.

Having user agents somehow indicate that they have needed to do error recovery will benefit novice authors who would never install a developer extension or similar.

I don't see how this is different from browsers making the user aware of JavaScript errors.
Joshue O Connor Neutral Neutral = I tend to agree but it needs clarification.

How much of

"Error handling should be defined so that interoperable implementations can be achieved."

is a user agent issue? However, the discussion on improving accessible error handling is a worthwhile topic.
Maurice Carey Agree
Scott Turner Agree I feel error handling should also have the stated goal of delivering as much content as possible e.g. fail gracefully and continue until the end of the <HTML> block if at all possible.
Karl Dubost Strongly Agree
Sander Tekelenburg Agree
Nik Thierry Agree
Andrew Maben Strongly Agree
Ben Boyle Strongly Agree This supports users (Priority of constituencies). Authors definitely need tools to help them identify errors, this does not need to be the responsibility of HTML or web browsers.
James Graham Strongly Agree
David Singer Agree
Masataka Yakura Strongly Agree
Lachlan Hunt Strongly Agree
Michael Cooper Agree
Jason White Neutral While I value error handling, I am also concerned that, if the errors in non-conforming documents
aren't obviously errors when the content is viewed, this allows too much scope for mal-formed documents to be produced, and
weakens the practical value of producing conformant HTML. The negative impact of erroneous content falls disproportionately on users of non-visual user agents, with which the documents may never have been tested. To the extent that error handling is specified, it should be as simple as possible and applicable across all types of user agents and other HTML processors.
Monika Trebo Neutral
Dylan Smith Agree
Schalk Neethling Agree
Laura Carlson Neutral
Philip TAYLOR Neutral Ambivalent. I can see some benefit, but by concealing author's errors from end users we are removing 99% of the possible pressure on authors to avoid (or correct) these errors in the first place. On balance, I disagree.
Richard Ishida Agree
Benoit Piette Agree
Marcin Hanclik Strongly Agree
Gregory Rosmaita Strongly Agree
Leif Halvard Silli Disagree The wording "so that users are not exposed to authoring errors" could just as well have been "so that documents do not expose authoring errors when they are being read".

The principle is related to "Support Existing Content" , whose «badly nested elements»  example fits just as well under this principle. Actually, that example actually better belongs under "Handler Errors" than under "Support Existing Content"! Because, first we must define what elements falls under "existing content", and then - if "existing content" (marquee for instance) involves "badly nested elements", we must have error handeling. I.e. MARQUEE first need to be supported as "existing content", and then, if MARQUE is badly nested, then that error needs to be handled.

This principle involves semantics, as the error handeling will have to try to display it in a sensible way.
Dan Connolly Agree I see this as a necessary expedient. I prefer to merge it in with "Well-defined Behavior" in any case.
David Baron Agree This principle seems a bit vague, partly since it lacks a definition of interoperability. It may also be worth mentioning the Simplicity principle, since choosing simple error-handling behavior reduces implementation cost (at little cost to users when the error-handling behavior is interoperable).

17. Do you support publication?

Whether you support adopting any one principle or not, do you support publishing the draft for community review?

Summary

ChoiceAll responders
Results
Abstain 5
no; let's not work on this
Only after critical issues are addressed 19
yes 56

Details

Responder Do you support publication?Rationale
Mark DuBois yes
Edward O'Connor yes
Daniel Morrison yes
Matthew Freels Abstain
Michael Puls II yes
Jason Turnbull yes
Ian Massey yes There are a couple of issues that I strongly think should be addressed right away, however, I think that publishing the draft will only enlist massive support for my opinions on these things, so I'm for it.
Chris Adams yes
Weston Ruter yes
Thomas Bradley yes
Danny Liang Only after critical issues are addressed
Stephen Duncan yes
Dannii Willis yes
Andrew Fedoniouk Abstain
Jon Barnett yes
Frank Palinkas yes
Carol King yes
Alexey Proskuryakov yes
Brad Fults yes It's better to get community feedback early and often.
Sajid Saiyed yes
Bill Mason yes
Stéphane Deschamps yes
Razvan MIHAIU yes
Julian Reschke yes
Egor Kloos yes
Craig Buckler yes
Bob Hopgood yes Just to see what other views are expressed. I assume any comments made from this straw vote will be taken into account before publication.
Shawn Medero yes
Matthew Otto Only after critical issues are addressed
Andrew Sidwell yes
Dimitri Glazkov yes
Craig Saila yes
Patrick Taylor yes
Steve Faulkner yes I would support publishing the document if there was a clearly worded principle providing a commitment to supporting Accessibility.
Dean Edridge Only after critical issues are addressed
Marc Drumm yes
Henri Sivonen yes
Daniel Schattenkirchner yes
Kai Hendry yes I support "Media Independence", "separation of content and presentation" and "Pave the Cowpaths".
Arthur Jennings yes
Benjamin Meadowcroft Abstain
Robert Burns yes I would support publication as a public draft as is. If the "solve real-world problems" was removed and some clarifying language was added to "pave the cowpaths", I would zealously support the entire document.
Ian Hickson yes
David Andersson yes
Geoffrey Sneddon yes
Brian DeRocher Abstain
Josh Lawton yes
Robert Marshall yes
Scott Lewis yes
Stephen Axthelm yes
Stephen Stewart yes
Raphael Champeimont yes
Anne van Kesteren yes
Roger Johansson Only after critical issues are addressed The following principles are those I would call "critical issues".

"Pave the cowpaths": This needs to be reformulated to make it perfectly clear that it is not talking about adopting and encouraging widespread bad practices. Several improvements have been suggested on the wiki.

"Solve real problems": It is unclear what a "real problem" is, so this principle is just confusing. Who does not want to solve real problems?

"Universal access": Strongly agree once "when possible" is removed.
Joshue O Connor Only after critical issues are addressed An explicit commitment to accessibility needs to be included. I agree with Steve when he suggested that accessibility be an explicit
part of the Universal Access principle [1]. Many others can be dropped without any adverse effect where this one addition will have a positive impact and show the world the HTML 5 WG's commitment to inclusion.

[1] http://lists.w3.org/Archives/Public/public-html/2007Aug/0663.html
Maurice Carey yes
Scott Turner Only after critical issues are addressed Even drafts need to achieve a certain level of reasonableness or we risk the community turning on us like a pack of wolves.
Karl Dubost Only after critical issues are addressed
Sander Tekelenburg yes
Nik Thierry Only after critical issues are addressed
Andrew Maben Only after critical issues are addressed While I personally would be comfortable with publication "as is", I think it may in the end speed up the process if some of the concerns raised by others are addressed first. Some strongly felt, and clearly argued opinions have been raised.

The most controversial issues appear to be "Pave the Cowpaths" and "Solve Real Problems". Dropping these principles would be rather draconian, but some clarification may be needed.

In the case of "Cowpaths", it may be obvious, but it can do no harm to make explicit that bad practices should not be legitimized merely because they are widespread.

"Real World Problems" might be rephrased along the lines of: "Changes to the spec should solve actual real-world problems. The emphasis should be on providing solutions to existing widespread problems." The sentence dealing with "Abstract architectures..." is probably unnecessary, may be confusing, and might even be construed as snide or condescending. If something is needed to fill the spot, then perhaps: "Solutions to theoretically possible future problems should be considered as secondary."?
Ben Boyle yes It's already semi public. Make it official and start dealing with official feedback. I'd like the group to start the drafting cycle, feels like we are just sitting in draft mode (no review cycle happening).
James Graham yes
David Singer Only after critical issues are addressed We need to complete the current phase of rough review, and then define a process and timetable for what happens. We'll need to have a way to identify and (ideally) isolate issues, and so on.
Masataka Yakura Only after critical issues are addressed
Lachlan Hunt yes
Michael Cooper yes
Jason White Only after critical issues are addressed Let's find out which principles are the most controversial within the working group, see whether those can be
addressed first, and then publish the results for community review within a reasonable period of time.
Monika Trebo Only after critical issues are addressed
Dylan Smith Abstain I'm still not totally comfortable w/ the word 'publish,' which tends to connotate finality. 'Release for review' is a phrase I'd prefer.
Schalk Neethling Only after critical issues are addressed
Laura Carlson Only after critical issues are addressed Principles are fundamental value guides used to base decisions. DanC has said, "their main utility is as justification in discussions. if they don't work that way, they should be dropped" [1].

The premise of the principles is flawed. It says in the current document that, "They are pragmatic rules of thumb that must be balanced against each other, not absolutes." Some of the current principles serve only to confuse discourse because they are an ambiguous balancing act. For example, like Bob Hopgood points out in one of his survey responses, some of the principles start by saying 'should' and then are immediately follow with another paragraph saying it cannot be achieved. Many terms are too subjective. I question if they can be applied in a fair and consistent manner.

An indecisive principle will not be an aid to decision making but only worsen the discourse. Doublespeak often results in communication bypass.

The introduction to the design principles document, needs changing to clearly state that these principles are fundamental value guides used to base decisions. Their main utility is as justification in discussions.

The sentence: "They are pragmatic rules of thumb that must be balanced against each other, not absolutes." needs to be eliminated.

I strongly disagree with the following four principles:

1. "Do not Reinvent The Wheel" - Drop this principle. It is ambiguous. This principle starts by saying we 'should' and immediately turns around and says but sometimes we can't. An indecisive principle like this will not be an aid to decision making but only worsen the discourse. Doublespeak often results in communication bypass.

'Widely used' is a subjective term. How can this principle be applied fair and consistent manner? I agree with Andrew Fedoniouk that the principle depends on the quality of the wheel. How can that quality be measured? Some wheels may need reinventing. Some may not.

2. "Pave the Cowpaths" - Drop this principle. It is ambiguous and confuses productive discussion. We have went round and round on this principle (over 75 posts on the mailing list) and still can not come to agreement. It is too ambiguous. It is an indecisive principle that will not be an aid to decision making but only worsen the discourse.

Just because something is widely adopted doesn't mean that it should be accepted. As with HTML 4, many authors may not have taken advantage of certain features, but some certainly did. Just ditching one feature because it's less used (or used incorrectly by well-meaning, but mistaken authors) takes away from the language, as it then forces the knowledgeable authors who were indeed using those features correctly to adapt to a lowest common denominator, impoverishing their content in the process.

Some use cases may make sense others don't. And the "Paving" the way to bad practice because it is widely adopted doesn't mean that it should be accepted.

3. "Solve Real Problems" - Drop this principle. The definition of a "real problem" is subjective. It will only cause miscommunication. It is an indecisive principle that will not be an aid to decision making but only worsen the discourse.

4. "Avoid Needless Complexity" - Drop it. I'm not arguing for needless complexity :-) But term "Needless Complexity" is too subjective. The whole id/headers debate come to mind. Like Dean Edridge has said people will not agree on what complexities are needed and what's not needed. It is an indecisive principle that will not be an aid to decision making but only worsen the discourse.

IN ADDITION changes need to be made to the "Universal Access" principle. I fully support Steve Faulkner's proposal [2] of splitting up the aspects of universality. Accessibility does deserve a principle of its own. Steve's example Accessibility Principle is excellent:

"Design features to be accessible, universal, and inclusive. Access by everyone regardless of ability is an essential. Deliverables will satisfy accessibility requirements. To ensure this we will work closely with the WAI<http://www.w3.org/2007/03/HTML-WG-charter.html#wai>."

But until that can be worked out, removing the two words "when possible" (an escape clause) from the current principle would be satisfactory. 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.

[1] http://krijnhoetmer.nl/irc-logs/html-wg/20070817#l-43
[2] http://lists.w3.org/Archives/Public/public-html/2007Aug/0663.html
Philip TAYLOR Only after critical issues are addressed Define "community". This draft needs real work by the HTML WG if it is to represent /our/ views rather than the view of the WHAT WG.
Richard Ishida yes
Benoit Piette yes I think we should continue to work on the document and add other principles if necessary (but not more than 1 or 2). Community review would help.


Marcin Hanclik Only after critical issues are addressed Seeing the arguments presented by others, I think those issues have to be addressed before publication. Higher level of consensus should be reached. It should be defined how HDP influences further work on the actual spec, therefore I would recommend RFC2119 terms to follow the process: charter -> HDP -> HTML5 and make HDP binding somehow.
Gregory Rosmaita Only after critical issues are addressed there is no agreement on the principles due to WG members talking past one another, and -- in some cases, the most troubling being ian hickson's -- actively ignoring the contributions and concerns of other WG members; i am also concerned that one of the editors of the HTML5 draft has repeatedly stated that he is obligated to clear all WHAT WG issues before attending to HTML WG issues; that is his perogative if the changes are effected to an external draft or submitted on an individual basis for review, but once a W3C editorship is accepted, that editor has an obligation to fellow working group members to address the issues raised in the forum in which the draft is being developed, and that forum is the W3C;
Leif Halvard Silli Only after critical issues are addressed In this poll, many have issues have been raised. The principles have at times bad language (the repeated relativising comments).
Dan Connolly yes it's well past time to explicitly invite community review, regardless of how much more work we have to do on our documents.
David Baron yes

18. Are you OK to delegate some edits?

summary | by responder | by choice

The document will have to go through at least some edits required by W3C publication process. In particular, the "Status of this document" section is written by the Staff Contact (with input from the editor, chair, and WG).

It often helps to allow the editor to incorporate edits at their discretion, either just small things or in general.

It's often useful to get a the chair or some other WG member to check any changes just before publication. If there's some WG member you're happy to delegate to, please nominate them in a comment.

Maciej Stachowiak and Anne van Kesteren have offered to work on this document, and they seem like reasonable editor candidates.

Summary

ChoiceAll responders
Results
any edits the editors choose 44
any small/editorial changes the editors choose 32
any small/editoral changes, where "small" is judged by the chair 28

Skip to view by choice.

View by responder

Details

Responder Are you OK to delegate some edits?Comments
Mark DuBois
  • any edits the editors choose
Edward O'Connor
  • any edits the editors choose
Daniel Morrison
  • any edits the editors choose
Matthew Freels
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Michael Puls II
  • any edits the editors choose
Jason Turnbull
  • any edits the editors choose
Ian Massey
  • any small/editoral changes, where "small" is judged by the chair
Chris Adams
  • any small/editorial changes the editors choose
Weston Ruter
  • any small/editoral changes, where "small" is judged by the chair
Thomas Bradley
Danny Liang
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Stephen Duncan
  • any edits the editors choose
Dannii Willis
Andrew Fedoniouk
  • any edits the editors choose
Jon Barnett
Frank Palinkas
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Anne van Kesteren
Carol King
  • any edits the editors choose
Alexey Proskuryakov
  • any small/editorial changes the editors choose
Brad Fults
  • any small/editorial changes the editors choose
I am happy to delegate to Maciej Stachowiak if I have to choose only one. Otherwise both Maciej and Anne van Kesteren are worthy candidates.
Sajid Saiyed
  • any edits the editors choose
Bill Mason
  • any small/editoral changes, where "small" is judged by the chair
Stéphane Deschamps
  • any edits the editors choose
This is what we in France call a "vote of confidence". ;)
Razvan MIHAIU
  • any edits the editors choose
Julian Reschke
  • any small/editorial changes the editors choose
Egor Kloos
  • any edits the editors choose
Craig Buckler
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Bob Hopgood
  • any edits the editors choose
Shawn Medero
  • any edits the editors choose
Matthew Otto
  • any small/editorial changes the editors choose
Andrew Sidwell
  • any edits the editors choose
Dimitri Glazkov
  • any edits the editors choose
  • any small/editorial changes the editors choose
Craig Saila
  • any small/editoral changes, where "small" is judged by the chair
Patrick Taylor
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Steve Faulkner
  • any small/editoral changes, where "small" is judged by the chair
Dean Edridge
  • any edits the editors choose
Marc Drumm
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Henri Sivonen
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Were these supposed to be checkboxes as opposed to radio buttons?
Daniel Schattenkirchner
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Kai Hendry
  • any edits the editors choose
  • any small/editorial changes the editors choose
Henri Sivonen
Ian Hickson
Arthur Jennings
  • any small/editoral changes, where "small" is judged by the chair
Benjamin Meadowcroft
  • any small/editorial changes the editors choose
Robert Burns
  • any small/editoral changes, where "small" is judged by the chair
Ian Hickson
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
David Andersson
  • any edits the editors choose
Geoffrey Sneddon
  • any edits the editors choose
Brian DeRocher
  • any edits the editors choose
Josh Lawton
  • any small/editorial changes the editors choose
Robert Marshall
  • any edits the editors choose
Scott Lewis
  • any edits the editors choose
Stephen Axthelm
  • any small/editorial changes the editors choose
Stephen Stewart
  • any edits the editors choose
Raphael Champeimont
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Anne van Kesteren
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Any edits the editors choose suits me. Then again, I'm nominated as one.
Roger Johansson Only very minor editorial changes - nothing that affects the meaning of the principles.
Joshue O Connor
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
I agree with Jason.
Maurice Carey
Scott Turner
  • any small/editoral changes, where "small" is judged by the chair
Karl Dubost
  • any edits the editors choose
as long as the editor get backup from the WG.
Sander Tekelenburg
  • any edits the editors choose
Nik Thierry
Andrew Maben
  • any edits the editors choose
Ben Boyle
  • any edits the editors choose
There are options for tracking the draft (not the least of which being reading it when it is formally published!) so I'm happy to work my reviews with that process.
James Graham
  • any edits the editors choose
David Singer
  • any edits the editors choose
Masataka Yakura
  • any small/editorial changes the editors choose
Lachlan Hunt
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
The editor should be free to make any edits, without restriction.
Michael Cooper
  • any small/editorial changes the editors choose
Jason White
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
The version accepted by the working group as suitable for publication (whatever unresolved issues remain)
needs to be substantially the same as the version which is published, and this isn't compatible with giving too broad a discretion to the editors to make changes. Editorial corrections are fine.
It should also be open to the working group to publish the draft as is, with editorial notes pointing out particularly controversial or difficult problems that public reviewers should consider in commenting on the principles.
Monika Trebo
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Agree with Jason White;s rationale on this topic
Dylan Smith
  • any small/editorial changes the editors choose
Schalk Neethling
  • any edits the editors choose
Laura Carlson
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
I agree with Jason White's logic on this question.

I suggest Robert Burns <rob@robburns.com>, Joshue O Connor <joshue.oconnor@cfit.ie>, and Philip Taylor <P.Taylor@rhul.ac.uk> to work on this document.
Philip TAYLOR Maciej, like Henri, Lachlan and Ian, is a long-term members of the WHAT WG, and whilst they do not necessarily support each other 100%, they do do so at least 98,5% of the time. Anne is also a WHAT WG member, but (IMHO) is far more open to alternative points of view than Maciej, Henri, Ian or Lachlan. I believe that it is /essential/ that this document have at least as many editors who are not aligned with the WHAT WG as those who are. I understand that Laura Carlson, who has contributed enormous sense in these debate, is either willing to stand as an editor herself, or is compiling a list of those willing to serve. I nominate Laura, or Laura's nominees, to serve in this capacity.
Richard Ishida
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Benoit Piette
Marcin Hanclik
  • any edits the editors choose
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
Gregory Rosmaita
  • any small/editoral changes, where "small" is judged by the chair
i would prefer that a dual editorship not be monopolized by individuals with a vested interest in HTML5 as it stands; i would support a neutral alternative to maciej -- namely, laura carlson, who has displayed an adeptness at communicating and bridge building which maciej has not

as for the question, as long as the WG is notified of changes via the WG's announce list, "any small/editoral changes, where "small" is judged by the chair" should be announced to the WG as a whole -- small is a relative concept, and we are attempting to pin down concrete concepts

if there was a "none of the above" or "abstain" choice for this question, i would have chosen one or the other, until the matter of editorial responsibility is addressed and a firm commitment to tracking issues in the HTML WG is made part of the editor's responsibility, although i always thought that was part of the editor's responsibility anyway.

i would also request that the chairs define "small" before this question is closed.
Leif Halvard Silli
  • any small/editorial changes the editors choose
  • any small/editoral changes, where "small" is judged by the chair
For the Design Principles to count as a true «attempt to capture consensus on design approach», someone - at least one! – from outside the inner circles of the WhatWg community should do the edits.

I suggest these names: Laura Carlsson, Karl Dubost, Richard Ishida, Philip Taylor, Joshue O Connor, Robert Burns.
Dan Connolly
  • any edits the editors choose
I have seen some organizational suggestions that I think are worth making.
David Baron
  • any edits the editors choose

View by choice

ChoiceResponders
any edits the editors choose
  • Mark DuBois
  • Edward O'Connor
  • Daniel Morrison
  • Michael Puls II
  • Jason Turnbull
  • Danny Liang
  • Stephen Duncan
  • Andrew Fedoniouk
  • Frank Palinkas
  • Carol King
  • Sajid Saiyed
  • Stéphane Deschamps
  • Razvan MIHAIU
  • Egor Kloos
  • Bob Hopgood
  • Shawn Medero
  • Andrew Sidwell
  • Dimitri Glazkov
  • Patrick Taylor
  • Dean Edridge
  • Marc Drumm
  • Henri Sivonen
  • Daniel Schattenkirchner
  • Kai Hendry
  • Ian Hickson
  • David Andersson
  • Geoffrey Sneddon
  • Brian DeRocher
  • Robert Marshall
  • Scott Lewis
  • Stephen Stewart
  • Raphael Champeimont
  • Anne van Kesteren
  • Karl Dubost
  • Sander Tekelenburg
  • Andrew Maben
  • Ben Boyle
  • James Graham
  • David Singer
  • Lachlan Hunt
  • Schalk Neethling
  • Marcin Hanclik
  • Dan Connolly
  • David Baron
any small/editorial changes the editors choose
  • Matthew Freels
  • Chris Adams
  • Danny Liang
  • Frank Palinkas
  • Alexey Proskuryakov
  • Brad Fults
  • Julian Reschke
  • Craig Buckler
  • Matthew Otto
  • Dimitri Glazkov
  • Patrick Taylor
  • Marc Drumm
  • Henri Sivonen
  • Daniel Schattenkirchner
  • Kai Hendry
  • Benjamin Meadowcroft
  • Ian Hickson
  • Josh Lawton
  • Stephen Axthelm
  • Raphael Champeimont
  • Anne van Kesteren
  • Joshue O Connor
  • Masataka Yakura
  • Lachlan Hunt
  • Michael Cooper
  • Jason White
  • Monika Trebo
  • Dylan Smith
  • Laura Carlson
  • Richard Ishida
  • Marcin Hanclik
  • Leif Halvard Silli
any small/editoral changes, where "small" is judged by the chair
  • Matthew Freels
  • Ian Massey
  • Weston Ruter
  • Danny Liang
  • Frank Palinkas
  • Bill Mason
  • Craig Buckler
  • Craig Saila
  • Patrick Taylor
  • Steve Faulkner
  • Marc Drumm
  • Henri Sivonen
  • Daniel Schattenkirchner
  • Arthur Jennings
  • Robert Burns
  • Ian Hickson
  • Raphael Champeimont
  • Anne van Kesteren
  • Joshue O Connor
  • Scott Turner
  • Lachlan Hunt
  • Jason White
  • Monika Trebo
  • Laura Carlson
  • Richard Ishida
  • Marcin Hanclik
  • Gregory Rosmaita
  • Leif Halvard Silli

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Tantek Çelik <tantek@cs.stanford.edu>
  2. Patrick D F Ion <ion@ams.org>
  3. Richard Schwerdtfeger <schwer@us.ibm.com>
  4. Judy Brewer <jbrewer@w3.org>
  5. Wayne Carr <wayne.carr@linux.intel.com>
  6. Liam Quin <liam@w3.org>
  7. Chris Wilson <cwilso@google.com>
  8. Wendy Chisholm <wendc@microsoft.com>
  9. David Carlisle <davidc@nag.co.uk>
  10. James Helman <jhelman@movielabs.com>
  11. Jim Allan <jimallan@tsbvi.edu>
  12. Chris Marrin <cmarrin@apple.com>
  13. Charles McCathie Nevile <chaals@yandex-team.ru>
  14. Philippe Le Hégaret <plh@w3.org>
  15. Don Brutzman <brutzman@nps.edu>
  16. T.V. Raman <raman@google.com>
  17. Cynthia Shelly <cyns@microsoft.com>
  18. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  19. Sean Hayes <sean.hayes@microsoft.com>
  20. Larry Masinter <masinter@adobe.com>
  21. Lisa Seeman <lisa.seeman@zoho.com>
  22. Paul Cotton <Paul.Cotton@microsoft.com>
  23. Shane McCarron <shane@aptest.com>
  24. wu chou <wu.chou@huawei.com>
  25. Katsuhiko Momoi <momoi@google.com>
  26. Kangchan Lee <chan@w3.org>
  27. Roy Fielding <fielding@gbiv.com>
  28. Silvia Pfeiffer <silviapfeiffer1@gmail.com>
  29. Johnny Stenback <jst@mozilla.com>
  30. Janina Sajka <janina@rednote.net>
  31. Deborah Dahl <dahl@conversational-technologies.com>
  32. Glenn Adams <glenn@skynav.com>
  33. Jonathan Jeon <hollobit@etri.re.kr>
  34. David Hyatt <hyatt@apple.com>
  35. Robin Berjon <robin@w3.org>
  36. WonSuk Lee <wonsuk.lee@etri.re.kr>
  37. Maciej Stachowiak <mjs@apple.com>
  38. Robert Accettura <robert@accettura.com>
  39. Jonathan Watt <jwatt@jwatt.org>
  40. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  41. Patrick Lauke <redux@splintered.co.uk>
  42. David MacDonald <David100@sympatico.ca>
  43. Jack Jansen <jack@cwi.nl>
  44. Boris Zbarsky <bzbarsky@mit.edu>
  45. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  46. Markku Hakkinen <mhakkinen@ets.org>
  47. Cyril Concolato <cyril.concolato@telecom-paristech.fr>
  48. Gez Lemon <glemon@paciellogroup.com>
  49. Pasquale Popolizio <p.popolizio@webprofession.com>
  50. Luca Mascaro <l.mascaro@webprofession.com>
  51. Markus Mielke <mmielke@microsoft.com>
  52. Arun Ranganathan <arun@mozilla.com>
  53. Jens Meiert <jens@meiert.com>
  54. Felix Sasaki <fsasaki@w3.org>
  55. Kazuyuki Ashimura <ashimura@w3.org>
  56. Daniel Burnett <dburnett@voxeo.com>
  57. Tomas Caspers <tomas@tomascaspers.de>
  58. Han Xu <collin@w3china.org>
  59. Sam Ruby <rubys@intertwingly.net>
  60. Jonas Sicking <jonas@sicking.cc>
  61. Mark Crawford <mark.crawford@sap.com>
  62. Doug Schepers <schepers@w3.org>
  63. Ian Fette <ifette@google.com>
  64. Michael[tm] Smith <mike@w3.org>
  65. Kelly Ford <kelly.ford@microsoft.com>
  66. Cameron McCormack <cam@mcc.id.au>
  67. Stefan Schnabel <stefan.schnabel@sap.com>
  68. Jirka Kosek <jirka@kosek.cz>
  69. Robert O'Callahan <robert@ocallahan.org>
  70. Travis Leithead <Travis.Leithead@microsoft.com>
  71. Youngsun Ryu <ysryu@samsung.com>
  72. Sierk Bornemann <sierkb@gmail.com>
  73. Martijn Wargers <martijn.martijn@gmail.com>
  74. Simon Pieters <simonp@opera.com>
  75. Krijn Hoetmer <w3c@qontent.nl>
  76. Markus Fischer <markus@fischer.name>
  77. Channy Yun <channy@gmail.com>
  78. Shane Thacker <shanethacker@gmail.com>
  79. Vilem Malek <murphy@malek.cz>
  80. Zhihong Mao <zhihong.mao@gmail.com>
  81. Erik van Kempen <erikvankempen@gmail.com>
  82. Jude Robinson <dotcode+w3@gmail.com>
  83. Diego La Monica <d.lamonica@webprofession.com>
  84. Nick Fitzsimons <w3@nickfitz.co.uk>
  85. Giovanni Gentili <giovanni.gentili@gmail.com>
  86. Adele Peterson <adele@apple.com>
  87. S Emerson <w3c@accretewebsolutions.ca>
  88. Morten Tollefsen <morten@medialt.no>
  89. Justin Anthony Knapp <justinkoavf@gmail.com>
  90. Simon Myers <Smylers@stripey.com>
  91. Samuel Weinig <weinig@apple.com>
  92. Alejandro Fernandez <alejandro@mediadvanced.com>
  93. Doug Jones <doug_b_jones@me.com>
  94. Arne Johannessen <arne@thaw.de>
  95. Ron Reisor <ron@udel.edu>
  96. Marat Tanalin <mtanalin@yandex.ru>
  97. Andrew Norman <idonothaveacat@gmail.com>
  98. Matthew Turvey <mcturvey@gmail.com>
  99. Dale Hudjik <dale.hudjik@gmail.com>
  100. James Cassell <w3c@cyberpear.com>
  101. Joseph D'Andrea <jdandrea@gmail.com>
  102. Pietro Russo <p.russo@webprofession.com>
  103. Moto Ishizawa <summerwind.jp+w3c@gmail.com>
  104. Eric Carlson <eric.carlson@apple.com>
  105. Michael Turnwall <w3c@turnwall.net>
  106. Don Kiely <donkiely@computer.org>
  107. Jane Lee <applegoddess@gmail.com>
  108. David Child <dave@addedbytes.com>
  109. David Choi <daaave@gmail.com>
  110. David Bills <w3@dfbills.com>
  111. Andrew Ramsden <andrew@irama.org>
  112. John Foliot <john.foliot@deque.com>
  113. Shefik Macauley <allknightaccess@gmail.com>
  114. Joe Steele <steele@adobe.com>
  115. John Vernaleo <john@netpurgatory.com>
  116. Jeremy Keith <jeremy@adactio.com>
  117. Jedi Lin <JediLin@Gmail.com>
  118. Kenny Johar <kensingh@microsoft.com>
  119. Jon Hughes <jon@phazm.com>
  120. Anssi Kostiainen <anssi.kostiainen@intel.com>
  121. Samuel Santos <samaxes@gmail.com>
  122. Dean Jackson <dino@apple.com>
  123. Mohammed DADAS <mohammed.dadas@orange.com>
  124. Sally Cain <sally.cain@rnib.org.uk>
  125. Dan Romascanu <dromasca@avaya.com>
  126. David Bolter <dbolter@mozilla.com>
  127. Chris Double <cdouble@mozilla.com>
  128. Jeanne F Spellman <jeanne@w3.org>
  129. James Craig <jcraig@apple.com>
  130. MING JIN <ming.jin.web@gmail.com>
  131. Leonard Rosenthol <lrosenth@adobe.com>
  132. Philip Jägenstedt <philipj@opera.com>
  133. Adrian Bateman <adrianba@microsoft.com>
  134. Dionysios Synodinos <synodinos@gmail.com>
  135. Jean-Pierre EVAIN <evain@ebu.ch>
  136. Mark Pilgrim <pilgrim@google.com>
  137. Matt Lee <mattl@cnuk.org>
  138. Magnus Olsson <magnus.olsson@ericsson.com>
  139. Chris Pearce <cpearce@mozilla.com>
  140. Dzung Tran <dzung.d.tran@intel.com>
  141. Mark Miller <erights@google.com>
  142. Andrew Wilson <atwilson@google.com>
  143. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  144. Ojan Vafai <ojan@chromium.org>
  145. Martin Kliehm <w3c@kliehm.com>
  146. Martin McEvoy <martin@weborganics.co.uk>
  147. Aryeh Gregor <ayg@aryeh.name>
  148. Eliot Graff <eliotgra@microsoft.com>
  149. Frank Olivier <frank.olivier@microsoft.com>
  150. Jonathan Griffin <jgriffin@mozilla.com>
  151. Kris Krueger <krisk@microsoft.com>
  152. Erik Isaksen <erik_isaksen@hotmail.com>
  153. Daniel Davis <ddavis@w3.org>
  154. Anders Bondehagen <anders@bondehagen.com>
  155. Steven Pemberton <Steven.Pemberton@cwi.nl>
  156. Raul Hudea <rhudea@adobe.com>
  157. Raghavan Gurumurthy <raghavan@adobe.com>
  158. Mayank Kumar <mayankk@adobe.com>
  159. Monikandan S <smonikan@adobe.com>
  160. Dragos Georgita <dgeorgit@adobe.com>
  161. Christopher Bank <cbank@adobe.com>
  162. Dominik Tomaszuk <ddooss@wp.pl>
  163. Ole Riesenberg <or@oleriesenberg.com>
  164. Takuya Oikawa <takuya@google.com>
  165. Jatinder Mann <jmann@microsoft.com>
  166. Robert Stern <rstern@gmail.com>
  167. Dean Leigh <dean.leigh@deanleigh.co.uk>
  168. Eihab Ibrahim <eihabibrahim@gmail.com>
  169. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  170. Ian Pouncey <w3c@ipouncey.co.uk>
  171. Jer Noble <jer.noble@apple.com>
  172. Léonie Watson <lwatson@paciellogroup.com>
  173. Masatomo Kobayashi <mstm@jp.ibm.com>
  174. Grant Simpson <glsimpso@gmail.com>
  175. Peter Beverloo <beverloo@google.com>
  176. Andrew Scherkus <scherkus@google.com>
  177. Greg Johnson <greg.johnson@gmail.com>
  178. Martijn Croonen <martijn@martijnc.be>
  179. John Jansen <johnjan@microsoft.com>
  180. Stanley Manoski <manoski@mitre.org>
  181. Jonas Schneider <js.sokrates@gmail.com>
  182. Yosuke Funahashi <yosuke@w3.org>
  183. Mounir Lamouri <mlamouri@google.com>
  184. Mike Amundsen <mamund@yahoo.com>
  185. Tony Gentilcore <tonyg@google.com>
  186. Jacob Rossi <Jacob.Rossi@microsoft.com>
  187. Joseph Pecoraro <pecoraro@apple.com>
  188. Othmane Benyoucef <othmane_benyoucef@hotmail.com>
  189. Shoko Okuma <okuma@tomo-digi.co.jp>
  190. Fumitaka Watanabe <fwtnb@tomo-digi.co.jp>
  191. Yoshimitsu Tsurimaki <tsurimaki@tomo-digi.co.jp>
  192. Bob Lund <b.lund@cablelabs.com>
  193. Tatsuya Igarashi <Tatsuya.Igarashi@jp.sony.com>
  194. John Simmons <johnsim@microsoft.com>
  195. Mathias Bynens <mathias@qiwi.be>
  196. Mark Watson <watsonm@netflix.com>
  197. Clarke Stevens <c.stevens@cablelabs.com>
  198. Mark Vickers <mark_vickers@cable.comcast.com>
  199. Sree Kotay <Sree_Kotay@cable.comcast.com>
  200. Cameron Jones <cmhjones@gmail.com>
  201. Rik Cabanier <Cabanier@adobe.com>
  202. Jeremy LaCivita <jeremy.lacivita@theplatform.com>
  203. Denis Ah-Kang <denis@w3.org>
  204. Alvar Laigna <laigna@gmail.com>
  205. Kunio Ito <kunio.ito@mail.rakuten.com>
  206. David Mays <david_mays@comcast.com>
  207. Michael Chen <michael_chen@cable.comcast.com>
  208. jongyoul Park <jongyoul@etri.re.kr>
  209. Adrian Roselli <roselli@algonquinstudios.com>
  210. Colin Ihrig <cjihrig@gmail.com>
  211. Kilroy Hughes <kilroy.hughes@microsoft.com>
  212. Reinaldo Ferraz <reinaldo@nic.br>
  213. Bill Mandel <bill.mandel@nbcuni.com>
  214. Jonas Jacek <gaccesss@gmail.com>
  215. Eva Lingyun Jing <jinglingyun@baidu.com>
  216. GANG LIANG <gang.liang@huawei.com>
  217. Ryosuke Niwa <rniwa@apple.com>
  218. Jason Kiss <jason@accessibleculture.org>
  219. Gian Luca Marroni <gmarroni@libero.it>
  220. Ian Devlin <ian@iandevlin.com>
  221. Xingrong Guo <guoxingrong@baidu.com>
  222. Jet Villegas <w3c@junglecode.net>
  223. Alexander Surkov <surkov.alexander@gmail.com>
  224. Hasan Savran <hsavran@kent.edu>
  225. Ben Dalton <bendalton@gmail.com>
  226. Marco Kotrotsos <Marco@mlabs.nl>
  227. Brian Blakely <anewpage.media@gmail.com>
  228. Eric VonColln <eric.voncolln@navy.mil>
  229. Jason Boyd <jason@pixelboxdesign.co.uk>
  230. Jungkee Song <jungkee.song@samsung.com>
  231. Huan Ren <renhuan@360.cn>
  232. Xitong Huang <stonehuang@tencent.com>
  233. Rayi Lei <leiyi@baidu.com>
  234. Daniel Austin <daniel.austin@grintech.net>
  235. David Dorwin <ddorwin@google.com>
  236. jiexuan gao <gaojiexuan@baidu.com>
  237. Mathew Marquis <mat@matmarquis.com>
  238. Xiaoqing Yang <yangxiaoqing@baidu.com>
  239. Aaron Colwell <acolwell@google.com>
  240. Alex Giladi <alex.giladi@huawei.com>
  241. Motomasa Futagami <Motomasa.Futagami@jp.sony.com>
  242. Kevin Streeter <kstreete@adobe.com>
  243. Christian Kaiser <kaiserc@google.com>
  244. François REMY <francois.remy.dev@outlook.com>
  245. Xuejian Li <lixuejian@baidu.com>
  246. Zuncheng Yang <yangzuncheng@baidu.com>
  247. Qianglong Zheng <zhengqianglong@baidu.com>
  248. Zhou Shen <shenzhou@baidu.com>
  249. Duoyi Wu <wuduoyi@baidu.com>
  250. Zheng Jia <jiazheng@baidu.com>
  251. Weifeng Feng <fengweifeng@baidu.com>
  252. Damin Hu <hudamin@baidu.com>
  253. Yang Liu <liuyang12@baidu.com>
  254. Zhixing Lei <leizhixing@baidu.com>
  255. Honggang Tang <tanghonggang@baidu.com>
  256. Kefeng Li <buaadallas@gmail.com>
  257. Xu Ma <maxu@baidu.com>
  258. Junzhong Liu <liujunzhong@baidu.com>
  259. Yusuke Maehama <maehama@tomo-digi.co.jp>
  260. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  261. Sheau Ng <Sheau.ng@nbcuni.com>
  262. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  263. Ami Fischman <fischman@google.com>
  264. Arnaud Braud <arnaud.braud@orange.com>
  265. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  266. Bram Tullemans <tullemans@ebu.ch>
  267. Petr Peterka <ppeterka@verimatrix.com>
  268. lei wang <wanglei03@baidu.com>
  269. Milan Patel <Milan.Patel@huawei.com>
  270. Yiling Gu <guyiling@baidu.com>
  271. Yehuda Katz <wycats@gmail.com>
  272. Xueqing Huang <huangxueqing@baidu.com>
  273. Zefa Xiong <xiongzefa@baidu.com>
  274. shanglin chen <chenshanglin@baidu.com>
  275. Yaso Córdova <yaso@nic.br>
  276. Dongsheng Zhang <zhangdongsheng@baidu.com>
  277. Ping Wu <wuping02@baidu.com>
  278. Yao Tong <tongyao@baidu.com>
  279. Bin Chen <chenbin01@baidu.com>
  280. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  281. Patrick Ladd <Pat_Ladd2@cable.comcast.com>
  282. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  283. Billy Gregory <bgregory@paciellogroup.com>
  284. Hanrui Gao <gaohanrui@360.cn>
  285. Hao Jing <jh.jinghao@huawei.com>
  286. Glenn Deen <glenn.deen@nbcuni.com>
  287. Lei Wang <wanglei@baidu.com>
  288. Tom Handal <thandal@verimatrix.com>
  289. Tsutomu Ogasawara <tsutomu.ogasawara@mail.rakuten.com>
  290. Jose Segura <jose.segura@mail.rakuten.com>
  291. Pengcheng Guo <guopengcheng@baidu.com>
  292. Erika Doyle Navara <erika.doyle@microsoft.com>
  293. Tom Wiltzius <wiltzius@google.com>
  294. Pierre-Anthony Lemieux <pal@sandflow.com>
  295. Xie Jianhui <xiejianhui@baidu.com>
  296. Yujie Jiang <jiangyujie@baidu.com>
  297. Leslie Sikos <sikos@sikoswebconsulting.com.au>
  298. Mark Sadecki <mark.sadecki+w3c@gmail.com>
  299. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  300. Brady Eidson <beidson@apple.com>
  301. Jerry Smith <jdsmith@microsoft.com>
  302. Michael Thornburgh <mthornbu@adobe.com>
  303. Cyril Rickelton-Abdi <cyril.rickelton-abdi@turner.com>
  304. Andrew Davis <andrew@diff.mx>
  305. Mick Hakobyan <mhakobyan@netflix.com>
  306. Mallory van Achterberg <stommepoes@stommepoes.nl>
  307. Vladimir Sinelnikov <sinelnikov@gmail.com>
  308. Chris Wong <huanghoujin@baidu.com>
  309. Yiliang LIU <liuyiliang@baidu.com>
  310. Hernan Beati <hernanbeati@gmail.com>
  311. mingqiang zhang <imcnan@gmail.com>
  312. yubo zhou <zhouyubo@360.cn>
  313. Ben Barber <barberboy@gmail.com>
  314. Matt Rakow <marakow@microsoft.com>
  315. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  316. Grzegorz Babula <gbabula@gmail.com>
  317. Brian Kardell <hitchjs@gmail.com>
  318. xueliang fan <fanxueliang@baidu.com>
  319. Niels Thorwirth <nthorwirth@verimatrix.com>
  320. David Evans <david.evans@rd.bbc.co.uk>
  321. Danny O'Brien <danny@eff.org>
  322. Joseph Karr O'Connor <josephoconnor@mac.com>
  323. Seth Schoen <schoen@eff.org>
  324. Jamil Ellis <jamil.ellis@hbo.com>
  325. Jim Walsh <jim@jwalshcreative.com>
  326. Greg Davis <greg.davis@pearson.com>
  327. Gabino Alonso <gabinovincent@gmail.com>
  328. Sam Langdon <sam.langdon@hachette.co.uk>
  329. Michael Kelly <mkelly@mozilla.com>
  330. Xiaoqian Wu <xiaoqian@w3.org>
  331. Yue Min <minyue@baidu.com>
  332. Min Li <limin04@baidu.com>
  333. A.S. Krishnakumar <ask@avaya.com>
  334. Shijun Sun <shijuns@microsoft.com>
  335. Jonathan Neal <jonathantneal@gmail.com>
  336. Joanmarie Diggs <jdiggs@igalia.com>
  337. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  338. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  339. So Vang <svang@nab.org>
  340. Nathalia Sautchuk Patrício <nathalia@nic.br>
  341. Deblyn prado <deblyn@nic.br>
  342. Vicente García Díaz <vicegd@live.com>
  343. Nolan Butcher <nolan.butcher@hbo.com>
  344. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  345. RAVI CHANDRA RAVULAPATI <ravichandra480@gmail.com>
  346. John Riviello <john_riviello@comcast.com>
  347. yaolong wang <wangyaolong@baidu.com>
  348. Shun-ichi Sekiguchi <Sekiguchi.Shunichi@eb.MitsubishiElectric.co.jp>
  349. Tao Liang <liangtao01@baidu.com>
  350. Glenn Eguchi <geguchi@adobe.com>
  351. Hirofumi Nishikawa <Nishikawa.Hirofumi@cs.MitsubishiElectric.co.jp>
  352. Hiroyuki Yamada <Yamada.Hiroyuki@dn.MitsubishiElectric.co.jp>
  353. Chockalingam Muthian <chockam@gmail.com>
  354. Lukáš Čihák <lukas.cihak@mensa.cz>
  355. Anatoly Shikolay <shikolay@gmail.com>
  356. WOOGLAE KIM <wlkim@inswave.com>
  357. Min Ren <minren@tencent.com>
  358. Rustam Khashimkhodjaev <Rustam_Khashimkhodjaev@cable.comcast.com>
  359. Brian Evans <Brian.Evans@microsoft.com>
  360. Jason White <jjwhite@ets.org>
  361. Hyejin Lee <hjlee@html5forum.or.kr>
  362. Richard Grzeczkowski <richard_grzeczkowski@cable.comcast.com>
  363. Pascal Perrot <pascal.perrot@orange.com>
  364. Dongseong Hwang <dongseong.hwang@intel.com>
  365. Dapeng Liu <max.ldp@alibaba-inc.com>
  366. Matthew Wolenetz <wolenetz@google.com>
  367. Cory Heslip <cory_heslip@cable.comcast.com>
  368. Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  369. Nirankush Panchbhai <npanch@microsoft.com>
  370. Pramod Patlolla <pramod.patlolla@turner.com>
  371. Cooper Pope <cooper.pope@turner.com>
  372. Grisha Lyukshin <glyuk@microsoft.com>

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.129 2015/07/01 16:13:23 kahan Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)