w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
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:
- Review survey process
- principle "Support Existing Content"
- principle "Degrade Gracefully"
- principle "Do not Reinvent The Wheel"
- principle "Pave the Cowpaths"
- principle "Evolution Not Revolution"
- principle "Solve Real Problems"
- principle "Priority of Constituencies"
- principle "Media Independence"
- principle "Universal Access"
- principle "Support World Languages"
- principle "Secure By Design"
- principle "Separation of Concerns"
- principle "Well-Defined Behavior"
- principle "Avoid Needless Complexity"
- principle "Handle Errors"
- Do you support publication?
- 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:
- Strongly Agree = Full support as written. Include it.
- Agree = with some suggestions for consideration.
- Neutral = Neither agree or disagree.
- Disagree = Some changes are needed.
- Strongly Disagree = No support. Delete it.
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 | |
| Theresa 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 | |
| Sam 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
| Choice | All 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 | |
| Theresa 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 | |
| Sam 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
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 59 |
| Agree | 14 |
| Neutral | 1 |
| Disagree | 6 |
| Strongly Disagree |
Details
| Responder | principle "Degrade Gracefully" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Theresa 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 | |
| Sam 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
| Choice | All 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 | |
| Theresa 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 | |
| Sam 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
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 25 |
| Agree | 27 |
| Neutral | 13 |
| Disagree | 7 |
| Strongly Disagree | 5 |
Details
| Responder | principle "Pave the Cowpaths" | Comments |
|---|---|---|
| Mark DuBois | ||
| Theresa 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 | |
| Sam 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
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 31 |
| Agree | 35 |
| Neutral | 8 |
| Disagree | 6 |
| Strongly Disagree |
Details
| Responder | principle "Evolution Not Revolution" | Comments |
|---|---|---|
| Mark DuBois | Agree | |
| Theresa 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 | |
| Sam 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
| Choice | All 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 | |
| Theresa 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 | |
| Sam 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
| Choice | All 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 | |
| Theresa 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 | |
| Sam 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
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 62 |
| Agree | 14 |
| Neutral | 3 |
| Disagree | 1 |
| Strongly Disagree |
Details
| Responder | principle "Media Independence" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Theresa 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 | |
| Sam 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
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 52 |
| Agree | 18 |
| Neutral | 1 |
| Disagree | 6 |
| Strongly Disagree |
Details
| Responder | principle "Universal Access" | Comments |
|---|---|---|
| Mark DuBois | ||
| Theresa 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 | |
| Sam 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
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 57 |
| Agree | 16 |
| Neutral | 2 |
| Disagree | 5 |
| Strongly Disagree |
Details
| Responder | principle "Support World Languages" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Theresa 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 | |
| Sam 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
| Choice | All 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 | |
| Theresa 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 | |
| Sam 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
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 47 |
| Agree | 16 |
| Neutral | 5 |
| Disagree | 5 |
| Strongly Disagree | 3 |
Details
| Responder | principle "Separation of Concerns" | Comments |
|---|---|---|
| Mark DuBois | ||
| Theresa 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 | |
| Sam 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
| Choice | All 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 | |
| Theresa 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 | |
| Sam 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
| Choice | All 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 | |
| Theresa 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 | |
| Sam 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
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 44 |
| Agree | 21 |
| Neutral | 10 |
| Disagree | 3 |
| Strongly Disagree | 2 |
Details
| Responder | principle "Handle Errors" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Theresa 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 | |
| Sam 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
| Choice | All 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 | |
| Theresa 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 | |
| Sam 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
| Choice | All 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 |
|
|
| Theresa 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 |
|
Anne van Kesteren |
| Carol King |
|
|
| Alexey Proskuryakov |
|
|
| Brad Fults |
|
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 |
|
|
| Bill Mason |
|
|
| Stéphane Deschamps |
|
This is what we in France call a "vote of confidence". ;) |
| 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 |
|
Were these supposed to be checkboxes as opposed to radio buttons? |
| Daniel Schattenkirchner |
|
|
| Kai Hendry |
|
Henri Sivonen Ian Hickson |
| Arthur Jennings |
|
|
| Benjamin Meadowcroft |
|
|
| Robert Burns |
|
|
| Ian Hickson |
|
|
| David Andersson |
|
|
| Sam Sneddon |
|
|
| Brian DeRocher |
|
|
| Josh Lawton |
|
|
| Robert Marshall |
|
|
| Scott Lewis |
|
|
| Stephen Axthelm |
|
|
| Stephen Stewart |
|
|
| Raphael Champeimont |
|
|
| Anne van Kesteren |
|
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 |
|
I agree with Jason. |
| Maurice Carey | ||
| Scott Turner |
|
|
| Karl Dubost |
|
as long as the editor get backup from the WG. |
| Sander Tekelenburg |
|
|
| Nik Thierry | ||
| Andrew Maben |
|
|
| Ben Boyle |
|
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 |
|
|
| David Singer |
|
|
| Masataka Yakura |
|
|
| Lachlan Hunt |
|
The editor should be free to make any edits, without restriction. |
| Michael Cooper |
|
|
| Jason White |
|
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 |
|
Agree with Jason White;s rationale on this topic |
| Dylan Smith |
|
|
| Schalk Neethling |
|
|
| Laura Carlson |
|
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 |
|
|
| Benoit Piette | ||
| Marcin Hanclik |
|
|
| Gregory Rosmaita |
|
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 |
|
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 |
|
I have seen some organizational suggestions that I think are worth making. |
| David Baron |
|
View by choice
| Choice | Responders |
|---|---|
| any edits the editors choose |
|
| any small/editorial changes the editors choose |
|
| any small/editoral changes, where "small" is judged by the chair |
|
More details on responses
- Mark DuBois: last responded on 16, August 2007 at 22:46 (UTC)
- Theresa O'Connor: last responded on 16, August 2007 at 22:47 (UTC)
- Daniel Morrison: last responded on 16, August 2007 at 22:53 (UTC)
- Matthew Freels: last responded on 16, August 2007 at 23:00 (UTC)
- Michael Puls II: last responded on 16, August 2007 at 23:27 (UTC)
- Jason Turnbull: last responded on 16, August 2007 at 23:30 (UTC)
- Ian Massey: last responded on 16, August 2007 at 23:33 (UTC)
- Chris Adams: last responded on 16, August 2007 at 23:43 (UTC)
- Weston Ruter: last responded on 17, August 2007 at 00:06 (UTC)
- Thomas Bradley: last responded on 17, August 2007 at 01:23 (UTC)
- Danny Liang: last responded on 17, August 2007 at 01:23 (UTC)
- Stephen Duncan: last responded on 17, August 2007 at 01:48 (UTC)
- Dannii Willis: last responded on 17, August 2007 at 01:49 (UTC)
- Andrew Fedoniouk: last responded on 17, August 2007 at 02:44 (UTC)
- Jon Barnett: last responded on 17, August 2007 at 02:51 (UTC)
- Frank Palinkas: last responded on 17, August 2007 at 04:02 (UTC)
- Carol King: last responded on 17, August 2007 at 04:07 (UTC)
- Alexey Proskuryakov: last responded on 17, August 2007 at 04:30 (UTC)
- Brad Fults: last responded on 17, August 2007 at 05:08 (UTC)
- Sajid Saiyed: last responded on 17, August 2007 at 06:09 (UTC)
- Bill Mason: last responded on 17, August 2007 at 06:51 (UTC)
- Stéphane Deschamps: last responded on 17, August 2007 at 08:01 (UTC)
- Razvan MIHAIU: last responded on 17, August 2007 at 08:25 (UTC)
- Julian Reschke: last responded on 17, August 2007 at 08:31 (UTC)
- Egor Kloos: last responded on 17, August 2007 at 09:04 (UTC)
- Craig Buckler: last responded on 17, August 2007 at 10:08 (UTC)
- Bob Hopgood: last responded on 17, August 2007 at 10:15 (UTC)
- Shawn Medero: last responded on 17, August 2007 at 10:39 (UTC)
- Matthew Otto: last responded on 17, August 2007 at 11:35 (UTC)
- Andrew Sidwell: last responded on 17, August 2007 at 11:58 (UTC)
- Dimitri Glazkov: last responded on 17, August 2007 at 12:08 (UTC)
- Craig Saila: last responded on 17, August 2007 at 12:24 (UTC)
- Patrick Taylor: last responded on 17, August 2007 at 12:52 (UTC)
- Steve Faulkner: last responded on 17, August 2007 at 13:09 (UTC)
- Dean Edridge: last responded on 17, August 2007 at 13:32 (UTC)
- Marc Drumm: last responded on 17, August 2007 at 14:13 (UTC)
- Henri Sivonen: last responded on 17, August 2007 at 14:13 (UTC)
- Daniel Schattenkirchner: last responded on 17, August 2007 at 14:26 (UTC)
- Kai Hendry: last responded on 17, August 2007 at 14:45 (UTC)
- Arthur Jennings: last responded on 17, August 2007 at 20:08 (UTC)
- Benjamin Meadowcroft: last responded on 17, August 2007 at 21:35 (UTC)
- Robert Burns: last responded on 18, August 2007 at 02:42 (UTC)
- Ian Hickson: last responded on 18, August 2007 at 03:31 (UTC)
- David Andersson: last responded on 18, August 2007 at 10:36 (UTC)
- Sam Sneddon: last responded on 18, August 2007 at 20:50 (UTC)
- Brian DeRocher: last responded on 18, August 2007 at 23:15 (UTC)
- Josh Lawton: last responded on 19, August 2007 at 00:27 (UTC)
- Robert Marshall: last responded on 19, August 2007 at 00:57 (UTC)
- Scott Lewis: last responded on 19, August 2007 at 12:43 (UTC)
- Stephen Axthelm: last responded on 20, August 2007 at 05:55 (UTC)
- Stephen Stewart: last responded on 20, August 2007 at 10:25 (UTC)
- Raphael Champeimont: last responded on 20, August 2007 at 12:30 (UTC)
- Anne van Kesteren: last responded on 20, August 2007 at 12:47 (UTC)
- Roger Johansson: last responded on 20, August 2007 at 16:45 (UTC)
- Joshue O'Connor: last responded on 20, August 2007 at 18:15 (UTC)
- Maurice Carey: last responded on 20, August 2007 at 19:55 (UTC)
- Scott Turner: last responded on 20, August 2007 at 20:14 (UTC)
- Karl Dubost: last responded on 21, August 2007 at 10:35 (UTC)
- Sander Tekelenburg: last responded on 21, August 2007 at 12:20 (UTC)
- Nik Thierry: last responded on 21, August 2007 at 14:39 (UTC)
- Andrew Maben: last responded on 21, August 2007 at 14:41 (UTC)
- Ben Boyle: last responded on 21, August 2007 at 15:19 (UTC)
- James Graham: last responded on 21, August 2007 at 18:08 (UTC)
- David Singer: last responded on 21, August 2007 at 18:14 (UTC)
- Masataka Yakura: last responded on 21, August 2007 at 23:28 (UTC)
- Lachlan Hunt: last responded on 22, August 2007 at 15:11 (UTC)
- Michael Cooper: last responded on 22, August 2007 at 22:41 (UTC)
- Jason White: last responded on 23, August 2007 at 00:23 (UTC)
- Monika Trebo: last responded on 23, August 2007 at 06:04 (UTC)
- Dylan Smith: last responded on 23, August 2007 at 06:25 (UTC)
- Schalk Neethling: last responded on 23, August 2007 at 12:41 (UTC)
- Laura Carlson: last responded on 23, August 2007 at 13:49 (UTC)
- Philip TAYLOR: last responded on 23, August 2007 at 14:21 (UTC)
- Richard Ishida: last responded on 23, August 2007 at 16:00 (UTC)
- Benoit Piette: last responded on 23, August 2007 at 16:39 (UTC)
- Marcin Hanclik: last responded on 23, August 2007 at 17:35 (UTC)
- Gregory Rosmaita: last responded on 23, August 2007 at 23:35 (UTC)
- Leif Halvard Silli: last responded on 24, August 2007 at 02:00 (UTC)
- Dan Connolly: last responded on 24, August 2007 at 03:50 (UTC)
- David Baron: last responded on 24, August 2007 at 04:26 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project