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:
This survey is a non-binding, informational-gathering exercise. The chair may put a related formal proposals to the Working Group to adopt these principles and/or publish them if this survey shows a critical mass of support.
Do you support the design principles below as stated in the editors draft? (currently v 1.4 2007/08/16 15:39:50; see also revision log).
Note that the document is moving from the wiki topic.
Choices are based on a Likert scale:
Note suggestions regarding change requests:
- Send a message to public-html@w3.org with [HDP] at the start of the subject line.
- Please make sure your message contains the following:
- Which principle or principles you are addressing (or none, if your comment is about introductory text or the like).
- What change you would like made.
- The reasoning behind your change.
- Whether your request is in your opinion an editorial change, a substantive change (changes the meaning of the principle significantly), a request to drop one of the principles in the draft, or a request to add a new principle to the draft.
Any novel supporting arguments should be sent to public-html@w3.org for discussion and then cited in the comments field. (Of course, if you already sent your argument, just cite it.)
| Responder | |
|---|---|
| Mark DuBois | |
| Edward O'Connor | |
| Daniel Morrison | |
| Ian Hickson | I think we should also have the new "Baby Steps" principle. |
| 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 | |
| Robert Burns | |
| 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 | |
| Maurice Carey | |
| Marc Drumm | |
| Henri Sivonen | |
| Daniel Schattenkirchner | |
| Kai Hendry | |
| Arthur Jennings | |
| Benjamin Meadowcroft | |
| David Andersson | |
| Roger Johansson | |
| Geoffrey Sneddon | |
| Brian DeRocher | |
| Josh Lawton | |
| Robert Marshall | |
| Jason White | |
| 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 |
| Scott Lewis | |
| Stephen Axthelm | |
| Stephen Stewart | |
| Andrew Maben | |
| 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 |
| Raphael Champeimont | |
| Anne van Kesteren | |
| 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 | |
| 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 |
| 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. |
| 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. |
| Monika Trebo | |
| Dylan Smith | |
| Schalk Neethling | |
| 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 |
Do you support the "Support Existing Content" principle?
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 47 |
| Agree | 24 |
| Neutral | 4 |
| Disagree | 4 |
| Strongly Disagree | 1 |
| Responder | principle "Support Existing Content" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Edward O'Connor | Strongly Agree | |
| Daniel Morrison | Strongly Agree | |
| Ian Hickson | 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 | |
| Robert Burns | 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. |
| Maurice Carey | Strongly Agree | |
| 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 | |
| David Andersson | Strongly Agree | |
| Roger Johansson | Neutral | I suppose user agents will need to, unfortunately. |
| Geoffrey Sneddon | Strongly Agree | |
| Brian DeRocher | Agree | |
| Josh Lawton | Agree | |
| Robert Marshall | Strongly Agree | |
| Jason White | Agree | This is mandated by the scope and goals of the project. |
| 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." |
| Scott Lewis | Strongly Agree | |
| Stephen Axthelm | Agree | |
| Stephen Stewart | Strongly Agree | |
| Andrew Maben | Strongly Agree | |
| 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 |
| Raphael Champeimont | Strongly Agree | |
| Anne van Kesteren | 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. |
| Ben Boyle | Agree | |
| James Graham | Strongly Agree | |
| David Singer | Strongly Agree | |
| Masataka Yakura | Agree | |
| Lachlan Hunt | Agree | |
| 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." |
| Michael Cooper | Agree | |
| 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 | |
| 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... |
Do you support the "Degrade Gracefully" principle?
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 59 |
| Agree | 14 |
| Neutral | 1 |
| Disagree | 6 |
| Strongly Disagree |
| Responder | principle "Degrade Gracefully" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Edward O'Connor | Strongly Agree | |
| Daniel Morrison | Strongly Agree | |
| Ian Hickson | 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 | |
| Robert Burns | 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 | |
| Maurice Carey | Agree | |
| Marc Drumm | Strongly Agree | |
| Henri Sivonen | Strongly Agree | |
| Daniel Schattenkirchner | Strongly Agree | |
| Kai Hendry | Strongly Agree | |
| Arthur Jennings | Strongly Agree | |
| Benjamin Meadowcroft | Agree | |
| David Andersson | Strongly Agree | |
| Roger Johansson | Strongly Agree | |
| Geoffrey Sneddon | Strongly Agree | |
| Brian DeRocher | Agree | |
| Josh Lawton | Strongly Agree | |
| Robert Marshall | Strongly Agree | |
| Jason White | 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. |
| Scott Lewis | Strongly Agree | |
| Stephen Axthelm | Strongly Agree | |
| Stephen Stewart | Strongly Agree | |
| Andrew Maben | 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. |
| Raphael Champeimont | Strongly Agree | |
| Anne van Kesteren | Strongly 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 | |
| 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 | |
| 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. |
| Michael Cooper | Strongly Agree | |
| Monika Trebo | Strongly Agree | |
| Dylan Smith | Neutral | |
| Schalk Neethling | Strongly Agree | |
| 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 |
Do you support the "Do not Reinvent The Wheel" principle?
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 39 |
| Agree | 24 |
| Neutral | 9 |
| Disagree | 7 |
| Strongly Disagree | 1 |
| Responder | principle "Do not Reinvent The Wheel" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Edward O'Connor | Strongly Agree | |
| Daniel Morrison | Strongly Agree | |
| Ian Hickson | 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 | |
| Robert Burns | 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. |
| 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. |
| 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 | |
| David Andersson | 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. |
| Geoffrey Sneddon | Agree | |
| Brian DeRocher | Disagree | |
| Josh Lawton | Strongly Agree | |
| Robert Marshall | Strongly Agree | |
| Jason White | Strongly 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. |
| Scott Lewis | Strongly Agree | |
| Stephen Axthelm | Strongly Agree | |
| Stephen Stewart | Strongly Agree | |
| Andrew Maben | Strongly Agree | |
| 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 |
| Raphael Champeimont | Agree | |
| Anne van Kesteren | Strongly Agree | |
| 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. |
| Ben Boyle | Agree | |
| James Graham | Strongly Agree | |
| David Singer | Strongly Agree | |
| Masataka Yakura | Agree | |
| Lachlan Hunt | Agree | |
| Philip TAYLOR | Neutral | I would prefer "do not re-invent the wheel unnecessarily" |
| Michael Cooper | 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 | |
| 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 |
Do you support the "Pave the Cowpaths" principle?
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 25 |
| Agree | 27 |
| Neutral | 13 |
| Disagree | 7 |
| Strongly Disagree | 5 |
(3 responses didn't contain an answer to this question)
| Responder | principle "Pave the Cowpaths" | Comments |
|---|---|---|
| Mark DuBois | ||
| Edward O'Connor | ||
| Daniel Morrison | ||
| Ian Hickson | Strongly Agree | |
| 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 | |
| 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. |
| 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. |
| Maurice Carey | Agree | |
| 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 | |
| David Andersson | 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? |
| Geoffrey Sneddon | Agree | |
| Brian DeRocher | Disagree | |
| Josh Lawton | Strongly Agree | |
| Robert Marshall | Strongly 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. |
| 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. |
| Scott Lewis | Strongly Agree | |
| Stephen Axthelm | Agree | |
| Stephen Stewart | Strongly Agree | |
| Andrew Maben | Neutral | |
| 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. |
| Raphael Champeimont | Strongly Agree | |
| Anne van Kesteren | Strongly 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 | |
| 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 | |
| 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. |
| Michael Cooper | Agree | |
| 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 | |
| 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 |
Do you support the "Evolution Not Revolution" principle?
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 31 |
| Agree | 35 |
| Neutral | 8 |
| Disagree | 6 |
| Strongly Disagree |
| Responder | principle "Evolution Not Revolution" | Comments |
|---|---|---|
| Mark DuBois | Agree | |
| Edward O'Connor | Strongly Agree | |
| Daniel Morrison | 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.) |
| 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 | |
| Robert Burns | Strongly Agree | |
| 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 | |
| Maurice Carey | Agree | but I think <video> counts as a Revolution |
| 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 | |
| David Andersson | Strongly Agree | |
| Roger Johansson | Neutral | |
| Geoffrey Sneddon | Strongly Agree | |
| Brian DeRocher | Neutral | |
| Josh Lawton | Agree | |
| Robert Marshall | Strongly Agree | |
| 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". |
| Laura Carlson | Neutral | |
| Scott Lewis | Strongly Agree | |
| Stephen Axthelm | Agree | |
| Stephen Stewart | Strongly Agree | |
| Andrew Maben | Strongly Agree | |
| 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. |
| Raphael Champeimont | Agree | |
| Anne van Kesteren | Strongly Agree | |
| 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 | |
| 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 | |
| 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. |
| Michael Cooper | Neutral | Not sure I understand the implications of this, would like more examples. |
| 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 | |
| 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 |
Do you support the "Solve Real Problems" principle?
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 34 |
| Agree | 25 |
| Neutral | 10 |
| Disagree | 4 |
| Strongly Disagree | 7 |
| Responder | principle "Solve Real Problems" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Edward O'Connor | Strongly Agree | |
| Daniel Morrison | Strongly Agree | |
| Ian Hickson | 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 | |
| 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". |
| 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 | |
| Maurice Carey | 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 | |
| David Andersson | 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? |
| Geoffrey Sneddon | Strongly Agree | |
| Brian DeRocher | Agree | |
| Josh Lawton | Strongly Agree | |
| Robert Marshall | Neutral | |
| 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. |
| 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. |
| Scott Lewis | Strongly Agree | |
| Stephen Axthelm | Strongly Agree | |
| Stephen Stewart | Strongly Agree | |
| Andrew Maben | Strongly Agree | |
| Joshue O Connor | Disagree | What does it mean? |
| Raphael Champeimont | Neutral | |
| Anne van Kesteren | 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) |
| 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 | |
| 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. |
| Michael Cooper | Agree | |
| 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 | |
| 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 |
Do you support the "Priority of Constituencies" principle?
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 44 |
| Agree | 25 |
| Neutral | 8 |
| Disagree | 2 |
| Strongly Disagree | 1 |
| Responder | principle "Priority of Constituencies" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Edward O'Connor | Strongly Agree | |
| Daniel Morrison | Strongly Agree | |
| Ian Hickson | 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 | |
| Robert Burns | 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 | |
| Maurice Carey | Strongly Agree | I especially agree with specifiers and theoretical purity being last. |
| 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 | |
| David Andersson | Strongly Agree | |
| Roger Johansson | Neutral | |
| Geoffrey Sneddon | Agree | |
| Brian DeRocher | Agree | |
| Josh Lawton | Strongly Agree | |
| Robert Marshall | Neutral | |
| Jason White | Strongly Agree | |
| Laura Carlson | Strongly Agree | |
| Scott Lewis | Strongly Agree | |
| Stephen Axthelm | Strongly Agree | |
| Stephen Stewart | Strongly Agree | |
| Andrew Maben | Strongly Agree | |
| Joshue O Connor | Strongly Agree | Good to see users getting an explicit mention. |
| Raphael Champeimont | Agree | |
| Anne van Kesteren | Strongly Agree | |
| 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 | |
| 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 | |
| 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. |
| 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. |
| Monika Trebo | Agree | |
| Dylan Smith | Strongly Agree | |
| Schalk Neethling | Neutral | |
| 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). |
Do you support the "Media Independence" principle?
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 62 |
| Agree | 14 |
| Neutral | 3 |
| Disagree | 1 |
| Strongly Disagree |
| Responder | principle "Media Independence" | Comments |
|---|---|---|
| Mark DuBois | Strongly Agree | |
| Edward O'Connor | Strongly Agree | |
| Daniel Morrison | Strongly Agree | |
| Ian Hickson | 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 | |
| Robert Burns | 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 | |
| Maurice Carey | Strongly Agree | |
| Marc Drumm | Strongly Agree | |
| Henri Sivonen | Agree | |
| Daniel Schattenkirchner | Strongly Agree | |
| Kai Hendry | Strongly Agree | |
| Arthur Jennings | Strongly Agree | |
| Benjamin Meadowcroft | Agree | |
| David Andersson | Strongly Agree | |
| Roger Johansson | Strongly Agree | |
| Geoffrey Sneddon | Strongly Agree | |
| Brian DeRocher | Agree | |
| Josh Lawton | Strongly Agree | |
| Robert Marshall | Strongly Agree | |
| Jason White | Strongly Agree | |
| Laura Carlson | Strongly Agree | |
| Scott Lewis | Strongly Agree | |
| Stephen Axthelm | Strongly Agree | |
| Stephen Stewart | Strongly Agree | |
| Andrew Maben | Strongly Agree | |
| Joshue O Connor | Agree | |
| Raphael Champeimont | Strongly Agree | |
| Anne van Kesteren | 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 | |
| Ben Boyle | Strongly Agree | |
| James Graham | Strongly Agree | |
| David Singer | Agree | |
| Masataka Yakura | Strongly Agree | |
| Lachlan Hunt | 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. |
| Michael Cooper | Strongly Agree | |
| Monika Trebo | Strongly Agree | |
| Dylan Smith | Agree | |
| Schalk Neethling | Strongly Agree | |
| 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.) |
Do you support the "Universal Access" principle?
| Choice | All responders |
|---|---|
| Results | |
| Strongly Agree | 52 |
| Agree | 18 |
| Neutral | 1 |
| Disagree | 6 |
| Strongly Disagree |
(3 responses didn't contain an answer to this question)
| Responder | principle "Universal Access" | Comments |
|---|---|---|
| Mark DuBois | ||
| Edward O'Connor | ||
| Daniel Morrison | ||
| Ian Hickson | 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 | 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 | |
| Robert Burns | 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 | |
| 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 |