w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody.
This questionnaire was open from 2007-06-01 to 2007-10-25.
85 answers have been received.
Jump to results for question:
If you're not familiar with the process of Working Draft publication, see the list of W3C working drafts, section 7.4.1 First Public Working Draft of the Process document, and the heartbeat requirement.
Responder | Comments |
---|---|
Danny Liang | |
Chris Adams | |
Benjamin Chait | |
David McClure | |
Jonas Sicking | |
Dylan Smith | |
Robert Burns | |
Dannii Willis | |
Scott Lewis | |
Ben Boyle | |
Henri Sivonen | |
Chris Veenboer | |
Terry Morris | |
Sander Tekelenburg | |
Bob Hopgood | |
David Dailey | |
Murray Maloney | |
James Cassell | |
James Graham | |
Laurens Holst | |
Thomas Bradley | |
Darren West | |
Henrik Dvergsdal | |
Jirka Kosek | |
David Baron | |
Sean Fraser | |
Ben Millard | |
Gervase Markham | |
Sander van Lambalgen | |
Nicolas Le Gall | |
Shawn Medero | |
Gregory Rosmaita | http://lists.w3.org/Archives/Public/public-html/2007May/0652.html |
Jon Barnett | |
Felipe Alvarado | |
Eric Daspet | |
Gavin Sharp | |
Brendan Cullen | |
Eric Puidokas | |
Bill Mason | |
Thomas Higginbotham | |
Leif Halvard Silli | |
Cal Jacobson | |
David Choi | |
Steve Faulkner | |
Carol King | |
Stephen Axthelm | |
Matthew Ratzloff | |
Patrick Taylor | |
Michael Puls II | |
Ryan Cook | |
Brad Fults | |
Raphael Champeimont | |
Joseph D'Andrea | |
Channy Yun | |
Michael Cooper | |
Doug Schepers | |
Ian Hickson | |
Daniel Schattenkirchner | |
Lachlan Hunt | |
Theresa O'Connor | |
Anne van Kesteren | |
Simon Pieters | |
Adam Nash | |
Chris Wilson | |
Sam Sneddon | |
Laura Carlson | |
David Andersson | |
Asbjørn Ulsberg | |
Robert Marshall | |
Magnus Kristiansen | |
Chaals Nevile | |
Kazuhito Kidachi | |
Patrick Garies | |
Peter Howkins | |
Joshue O'Connor | |
Marek Pawlowski | |
Philip TAYLOR | What question is being asked here ? |
Jens Oliver Meiert | |
Kornel Lesinski | |
Jens Bannmann | |
Stéphane Deschamps | |
Mikko Honkala | |
Michaeljohn Clement | |
Pasquale Popolizio | |
Dean Edridge |
Which should we target first, regardless of whether it's currently ready to release?
If you'd like more choices added, say so in a comment and perhaps send mail to the WG (public-html@w3.org)
Choice | All responders |
---|---|
Results | |
design principles, requirements | 41 |
HTML 5 specification | 33 |
tutorial | |
a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | 9 |
a testing plan/proposal |
(2 responses didn't contain an answer to this question)
Responder | Which document should we focus on for first publication? | Rationale | Comments |
---|---|---|---|
Danny Liang | a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | ||
Chris Adams | HTML 5 specification | ||
Benjamin Chait | design principles, requirements | ||
David McClure | HTML 5 specification | ||
Jonas Sicking | design principles, requirements | The most important document to get started on the specification itself, but I have a strong feeling we're going to have problems keeping a focused discussion without having some design principles and requirements laid down. | |
Dylan Smith | design principles, requirements | ||
Robert Burns | a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | Especially focussing on semantic expressions introduced and deprecated; and the content models of elements. Discussions may end up exploring eimplemenation, serialization and DOM details, but I think the focus should begin at the level of content models and semantics. | |
Dannii Willis | design principles, requirements | ||
Scott Lewis | HTML 5 specification | ||
Ben Boyle | |||
Henri Sivonen | HTML 5 specification | The HTML 5 draft and the Design Principles documents are the two that exists unless you count http://wiki.whatwg.org/wiki/Differences_from_HTML4 as an existing version of "What's new in HTML 5". Considering that we have less than a month to our expected first WD, I think the first WD needs to be an existing document. In particular, I don't believe the WG can produce a satisfactory tutorial draft in less than a month. The HTML 5 specification is the main deliverable of the WG, so I have answered "HTML 5 specification", although I think it would be good the get the Design Principles down as well. | |
Chris Veenboer | a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | An overview of differences will make it easier for people to get involved with a specific item. | |
Terry Morris | design principles, requirements | ||
Sander Tekelenburg | design principles, requirements | I don't see how you can write a spec without design principles. I don't see how you can write a tutorial or a "what's new" without a spec. "testing plan/proposal" is too vague to vote for or against. | |
Bob Hopgood | design principles, requirements | That is probably the only way to make sensible decisions and not revisit issues over and over again. Define some principles and stick to them. Like: CSS is outside the scope of this standard. That would remove a great wadge of discussion;-) | |
David Dailey | HTML 5 specification | ||
Murray Maloney | a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | The WG needs to be able to identify the differences in order to discuss the proposed changes rationally. An authoritative differences document would ensure that every change is identified, reviewed, and considered before it is accepted by the WG. This should be the hub document until it contains only resolved and accepted changes. | |
James Cassell | design principles, requirements | ||
James Graham | HTML 5 specification | The spec is our final deliverable and the group has formally agreed on the current draft. Publishing the draft increases its exposure and so the chance of people with useful expertise on the content of the spec making comments which will lead to an improved document overall. | |
Laurens Holst | design principles, requirements | ||
Thomas Bradley | HTML 5 specification | The spec should be targetted first--the tutorial and 'What's new...' are completely dependent upon it. | |
Darren West | design principles, requirements | ||
Henrik Dvergsdal | a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | If the HTML WG is to own the spec, the rationale behind changes made to HTML4 should not be buried in an external mailing list. | |
Jirka Kosek | design principles, requirements | I think that HTML5 should be justified by existence of requirements which will list features that are missing in HTML4.01. IMHO current WHATWG HTML5 proposal contains some features that are needless, and at the same time it lacks some features that are critical for non-Web usage of HTML (e.g. HTML in email). | |
David Baron | HTML 5 specification | ||
Sean Fraser | HTML 5 specification | WG momentum would be maintained were the specification released, i.e., Schedule of Deliverables: 2007 Jun: First Working Draft. In my opinion, all other choices are dependent on the specification being published first. | |
Ben Millard | HTML 5 specification | The "First Public Working Draft" is just to "invite review". Which is what we are already doing, more or less. So let's make it official. | |
Gervase Markham | design principles, requirements | We need to all be on the same page - or at least understand the different philosophical viewpoints of the participants. The first para of the current document makes this point well. | |
Sander van Lambalgen | HTML 5 specification | This is the main focus of the working group. Having it officially published should also provide an impetus for review comments from outside the WG, which I consider likely to complement the planned structured review of this document by the WG itself. | |
Nicolas Le Gall | HTML 5 specification | ||
Shawn Medero | HTML 5 specification | The HTML 5 spec is the main deliverable. | |
Gregory Rosmaita | design principles, requirements | our charter states that we are to evolve HTML 4.01 - we should, before presenting a completely new draft specification, upon which the WG must first reach consensus. this is why we shouldn't suddenly switch to the WHAT WG's HTML5 in toto, but consider each difference between HTML 4.01 and HTML5 (as well as the list of dependencies listed in the above referenced post on this topic). before we can move forward, we need to explicitly express our design principles in evolving HTML 4.01 into a new, improved specification, as well as the specific requirements of the new spec. | our charter states that we are to evolve HTML 4.01 - we should, before presenting a completely new draft specification, upon which the WG must first reach consensus. this is why we shouldn't suddenly switch to the WHAT WG's HTML5 in toto, but consider each difference between HTML 4.01 and HTML5 (as well as the list of dependencies listed in http://lists.w3.org/Archives/Public/public-html/2007May/0652.html. before we can move forward, we need to explicitly express our design principles in evolving HTML 4.01 into a new, improved specification, as well as the specific requirements of the new spec. |
Jon Barnett | design principles, requirements | ||
Felipe Alvarado | design principles, requirements | ||
Eric Daspet | HTML 5 specification | ||
Gavin Sharp | design principles, requirements | The current text of the HTML 5 specification is already effectively "published" and relatively well known among people interested in web standards. Officially publishing our design principles and requirements would bring them forward and perhaps clear up confusion about this group's goals and principles. | |
Brendan Cullen | design principles, requirements | The design principals/requirements should act as a foundation to build the spec on | |
Eric Puidokas | design principles, requirements | ||
Bill Mason | HTML 5 specification | ||
Thomas Higginbotham | HTML 5 specification | Tutorials, testing plans, and a "What's new" document are dependent on the spec. It's also the primary deliverable and should have the most time devoted to it. | |
Leif Halvard Silli | design principles, requirements | I subscribe to the rationale that Laura Carlson has given. | |
Cal Jacobson | design principles, requirements | We need some solid guidelines as to how to proceed. | As much as I like the idea of the "What's New" document as a means to provide everybody with a clear picture of our goals, I fear that without some solid requirements we're going to be mired in endless discussions about trivial and/or unrelated items. I think there is a great risk of the WG debating the frequency at which the bell should ring and what color it should be rather than focusing on getting the darn thing on the cat. |
David Choi | design principles, requirements | The last three choices (tutorial, what's new, testing plan) are impossible to implement prior to the development of the first two (design principles/requirements, spec). I also believe that the spec should be largely dictated by the design principles and requirements. Developing the spec without well established design principles opens the door for all sorts of developmental train wrecks and internal inconsistency. Wouldn't it have been nice if multi-word function names in PHP were all camel case or all divided by underscores, instead of having to memorize each, or taking a guess? A little bit of consensus in planning goes a long way. | |
Steve Faulkner | design principles, requirements | I subscribe to the rationale that Laura Carlson has given. | |
Carol King | design principles, requirements | ||
Stephen Axthelm | design principles, requirements | This really is the base that all other items flow from. | |
Matthew Ratzloff | design principles, requirements | Clear, concise design principles should be agreed upon before the specification work begins so that the final specification document is consistent. | |
Patrick Taylor | design principles, requirements | The specification is most important, but we need to have agreement on basic principles. | |
Michael Puls II | HTML 5 specification | http://www.whatwg.org/specs/web-apps/current-work/ and the way it got to where it's currently at is great. Let's get it out there and start going at it so we can start resolving more issues with the spec. Design principles can be tweaked as we go along, but they're secondary to publishing the spec. A lot of the design principles seem like a given anyway (but it's good to document them as we go along). | |
Ryan Cook | HTML 5 specification | ||
Brad Fults | design principles, requirements | Publishing a spec that doesn't conform to the design principles of the group seems premature and rather useless. Likewise, the other documents here depend on a solid spec. | |
Raphael Champeimont | design principles, requirements | I think design principles and requirements are necessary to address some issues about the spec, so it is logical to publish it first to show how we make choices about the spec. | |
Joseph D'Andrea | a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | Start at a high level, acquire mindshare/understanding, and work from there. | |
Channy Yun | a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | ||
Michael Cooper | design principles, requirements | Requirements need to come in advance of the actual spec. If the spec is ready but the requirements are not, the question is under what framework were decisions about features in the spec made? | |
Doug Schepers | a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | Many people are unsure about what the status of the work done in HTML5 is. The official stance is that no technical decisions have been made, but the reality is that decisions are being made and implemented in browsers, locking the group into those decisions. This does not adequately ensure oversight by interested parties (in the group, or outside) into the decision process. We should publish a definitive state of the document, | A "What's new in HTML 5" document would also be good to publish. |
Ian Hickson | HTML 5 specification | It's the working group's primary deliverable. | The Design Principles would be useful too, since they would give us some sort of baseline to address issues. But we could muddle through without. |
Daniel Schattenkirchner | design principles, requirements | ||
Lachlan Hunt | HTML 5 specification | The spec is the only sensible document to focus on at this stage. | See this for my comments regarding the "What's new in HTML 5" document. http://lists.w3.org/Archives/Public/public-html/2007Jun/0021.html |
Theresa O'Connor | I don't have a preference on what should be published first -- I think all of the document we currently have can and should be published. | ||
Anne van Kesteren | HTML 5 specification | It's time we get it out on TR/. | I think publishing the html4-differences and html-design-principles documents might be useful too as these help people go through the main draft. |
Simon Pieters | HTML 5 specification | ||
Adam Nash | HTML 5 specification | I think our focus should always remain on the spec itself. If we were starting from scratch I might think otherwise for the early stages of the process, but we have considerable foundations laid already. | |
Chris Wilson | design principles, requirements | ||
Sam Sneddon | HTML 5 specification | ||
Laura Carlson | design principles, requirements | In order to apply consistent decision making throughout the specification, it is critical to come to consensus on the design principles. No principles or disputed principles can very well lead to inconsistent, contradictory, and discriminating decision making. Principles are fundamental value guides used to base spec decisions. As DanC has said, "their main utility is as justification in discussions." [1]. Publishing the differences document or spec, etc before coming to consensus on the design principles is backward. No agreed upon principles, at best result in decisions (e.g. dropping/adding/changing elements and attributes) without foundation. At worst it results in arbitrary, inconsistent, unjust, partial, wrong-headed, and discriminating decisions. Like TBL said, "design principles very hairy...journey of arriving on consensus valuable; have whole group in on discussion, creates common vocabulary and trust in one another..." [2] Consensus of guiding principles, definition of terms, and a common set of reviewing questions for features would: 1. Aid in communication and understanding. 2. Help avoid needless arguments and churning of issues. 3. Promote consistent and fair decision making. 5. Encourage outcomes that reflect what is important to the working group. 6. Benefit working group progress. [1] http://krijnhoetmer.nl/irc-logs/html-wg/20070817#l-43 [2] http://www.w3.org/2007/04/26-html-wg-minutes | |
David Andersson | HTML 5 specification | The design principles or requirements are supposed to guide us in the building of the spec, in other words they should be finished as soon as possible. | The differences document is something that depends on the spec, the tutorial likewise, and the testing plan/proposal is somewhat independent from the process of producing the spec. |
Asbjørn Ulsberg | HTML 5 specification | I think it's good to "get it out there", to let as many people share their opinions on it in public fora like blogs, on mailing lists, etc. Based on the responses, we can sketch out a way forward, to see if what we've got so far is something that's at least pointing in the right direction and worth continuing working on. | |
Robert Marshall | HTML 5 specification | The group is chartered primarily to create the spec, and I don't think formally publishing design principles provides any benefit. If I understand things correctly, publication as a WD as opposed to the current state is a way of formally encouraging review, which only seems like a good thing. | Work on the other documents can happen in parallel, but they shouldn't be the main focus. |
Magnus Kristiansen | HTML 5 specification | We've been dragging our feet on this too long. There is no harm in publishing a draft. | |
Chaals Nevile | HTML 5 specification | It has taken too long for the group to meet a heartbeat requirement. Since the primary deliverable is actually being edited, it should be published as a snapshot so people get a chance to see what is happening. The HTML 5 diff document should be published in parallel as a kind of primer for reviewers. | |
Kazuhito Kidachi | design principles, requirements | ||
Patrick Garies | design principles, requirements | It doesn’t make sense to author a specification to requirements that have yet to be specified. You may as well drop the design principles document altogether if is isn’t going to be used. | |
Peter Howkins | design principles, requirements | Without solid design principles any spec could not be effectively critiqued. | |
Joshue O'Connor | design principles, requirements | It makes sense to me to first publish the principles/requirments so people can then follow the rational for the spec. To publish first the spec and then to later produce the reasons for it will make it look like the spec was designed first and then the rational came after the fact. | |
Marek Pawlowski | HTML 5 specification | It's our primary target. We should look for public feedback as soon as possible and WD is a good way to achieve this. | |
Philip TAYLOR | design principles, requirements | To publish /anything/ before agreeing the design principles would be like establishing a committee to decide how best to nail together a large number of pieces of wood with no guidance or consensus as to what structure the committee is trying to create ... | |
Jens Oliver Meiert | design principles, requirements | Staking out. | |
Kornel Lesinski | HTML 5 specification | ||
Jens Bannmann | HTML 5 specification | The only document where publishing before the spec makes sense would be the design principles, but I doubt there's much to gain in doing so - besides causing web-wide discussions about it, and those would be too abstract/high-level to be useful feedback. The spec is our target, so we should start with it. Other documents could be added later, if feedback to the spec implies the need. | |
Stéphane Deschamps | a "What's new in HTML 5" document, enumerating differences from HTML 4, and perhaps discussing their status | ||
Mikko Honkala | design principles, requirements | Spec work makes not much sense without requirements -- design principles is a step into this direction. That said -- the HTML 5 spec draft is ready to be published as well IMHO. | |
Michaeljohn Clement | HTML 5 specification | The specification itself is what will be most important to those following the progress of the WG. The design principles are relevant only in that they effect the spec. | |
Pasquale Popolizio | design principles, requirements | ||
Dean Edridge | design principles, requirements |
summary | by responder | by choice
You might have comments on such a document, but you wouldn't mind if your comments didn't get addressed before we publish.
Note new options for the re-issue of this survey:
Choice | All responders |
---|---|
Results | |
old Design Principles (Apr 30) | 29 |
old HTML 5 spec (Jun 1) | 26 |
Design Principles (2007-09-14) | 20 |
HTML 5 spec draft (19 October 2007) | 19 |
Skip to view by choice.
Responder | Which documents do you think are OK for the group to publish in their current state? | Rationale | Comments |
---|---|---|---|
Danny Liang |
|
||
Chris Adams | |||
Benjamin Chait |
|
||
David McClure |
|
||
Jonas Sicking |
|
||
Dylan Smith |
|
||
Robert Burns |
|
It is way too early to publsih the HTML 5 spec. The dicussion has barely begun. I have no objection to the design pricniples, but perhaps some last-call discussion could be facilitated. | |
Dannii Willis | |||
Scott Lewis |
|
||
Ben Boyle | |||
Henri Sivonen |
|
The HTML 5 spec draft is very well WD quality. The non-disputed parts of the design principles are good stuff worthy of publication. | I'm assuming here that the Design Principles would be publish as a WD as-is with the disputes unresolved. If the disputes are to be resolved before publication, I favor Visible Metadata on the Visible Metadata vs. Metadata Anywhere issue, because visible metadata is more likely to be right. On the No Version Syntax vs Explicit Versioning issue I favor No Version Syntax, because I think version proliferation is bad for interop, but I realize that if a prominent vendor decides to introduce browser engine version switches, it is better to coordinate it through the WG than to have a vendor introduce such switches without WG consultation. Moreover, I believe the implementability of the spec is in the risk of falling apart if non-implementor participants feel that it is OK to suggest backwards-incompatible changes that are triggered by versioning (and they get their way). |
Chris Veenboer | |||
Terry Morris |
|
||
Sander Tekelenburg | Neither seems enough agreement on just yet However, it wouldn't be healthy to spend 'too much' time on the Design principles. Perhaps they can be published as a 1.0 alpha, to indicate intention without being cast in stone yet. | ||
Bob Hopgood | It depends what you mean by publish. Make available as a very rough draft for comment so that everybody is using the same document then that is OK but if it implies anything more than that, like the Group's first Working Draft for general comment, then I don't believe there is anu consensus for that. | ||
David Dailey |
|
It would be obvious that the HTML 5 document is a draft. Design Principles adopted without consensus could lead to major problems down the road. | |
Murray Maloney | The Design Principles have not been through a moderated discussion, which I would hope Dan Connolly would lead. The HTML 5 spec has not been subject to any formal WG review at all. | ||
James Cassell |
|
||
James Graham |
|
I don't see the need to formally publish the design principles. I see them as more internal to the WG than an externally interesting document. | |
Laurens Holst | |||
Thomas Bradley |
|
Since the design principles are the basis for everything else, they should logically be published first. | |
Darren West | |||
Henrik Dvergsdal |
|
IMO both are fit for publication as drafts. Furthermore I think it is important to bring the HTML5 spec into the domain of the HTML WG. I guess formal publication is the best way of accomplishing this. | |
Jirka Kosek |
|
||
David Baron |
|
||
Sean Fraser |
|
||
Ben Millard |
|
* I agree with most of the Design Principles. * There will be years for us to comment on and develop the HTML5 proposal after publishing it as the current draft. | |
Gervase Markham |
|
||
Sander van Lambalgen |
|
The HTML 5 spec is published by the WHATWG anyway; it would be good to show the W3C being on the same page with it. The spec is definitely not perfect, but it makes a very good starting point "as is" to get outside feedback. The design principles do more good than harm with explaining from which angle to approach the spec and its issues, and as such will be useful to be out there. | |
Nicolas Le Gall |
|
||
Shawn Medero |
|
The Design Principles seem fit for draft publication but the benefits of doing so aren't clear. The document feels like a set of internal guidelines more than anything else. If the majority would like to publish it though, I have no objections. The current version of the HTML 5 spec is of draft quality and has been available to the public for sometime. I'm a little surprised at the lingering WHATWG vs. W3C turf issues but it seems that moving it to working draft status will help clear this matter up as well. | |
Gregory Rosmaita |
|
before embarking on a path already taken, we should first stop to examine all possible pathways for evolving HTML 4.01. this doesn't mean throwing out the HTML5 work, but treating each difference deprecation and introduction on a case-by-case basis. | before embarking on a path already taken, we should first stop to examine all possible pathways for evolving HTML 4.01. this doesn't mean throwing out the HTML5 work, but treating each difference deprecation and introduction on a case-by-case basis. |
Jon Barnett |
|
||
Felipe Alvarado | |||
Eric Daspet |
|
||
Gavin Sharp | |||
Brendan Cullen | There still seems to be too much disagreement, a formal review would be beneficial | ||
Eric Puidokas | |||
Bill Mason |
|
||
Thomas Higginbotham |
|
They're public anyway as mentioned before. | |
Leif Halvard Silli | This question is confusing. Therefore, I did not make a choice. | I interpreted the first question about whether we should publish the design principles first or the HTML 5 spec first as a question about what we should focus on **finishing** first. If something needs focus, then it because we need to work on it. (Obviously, the HTML 5 spec isn't ready, so why are we asked about publishing that?) | |
Cal Jacobson | |||
David Choi | There's still heavy debate on issues with both. | ||
Steve Faulkner | |||
Carol King |
|
||
Stephen Axthelm |
|
||
Matthew Ratzloff |
|
The group hasn't really even had an opportunity to review (as a whole) the HTML 5 specification in detail. We should not blanket-endorse it as-is without at least a period of time specifically devoted to going over it. | |
Patrick Taylor |
|
the HTML5 spec via WHATWG is already public. The design principles should be, but it isn't critical. | As long as they are marked draft, I would encourage publication. |
Michael Puls II |
|
Design Principles can be published in its current state also. It's no big deal though compared to the HTML5 spec, which is definitely ready to be *officially* published so we can get going on it. | |
Ryan Cook |
|
||
Brad Fults | |||
Raphael Champeimont |
|
Design principles are ready, there are many issues with the spec but everyone knows it is "current work" so we can still publish it. And anyway they are already public, so publishing them won't hurt. | |
Joseph D'Andrea |
|
They're works in progress. OK to share IMO. Just be sure to disclaim appropriately. | |
Channy Yun |
|
||
Michael Cooper |
|
Both documents look more than ready for a First Public Working Draft. They don't need to be polished - in fact, they _should not_ be polished. There should be lots of opportunity for comment from the broader community, and something too polished might suggest that the ship has sailed. | This survey question was changed between when I answered and submitted the survey. If the new versions of the documents have taken into account feedback received to date on the old ones, publish the new ones. If not, publish the old ones. I'm more concerned about that with respect to the design principles, as I had what I considered crucial points of feedback. But I'll just resubmit them on the public draft if they're not addressed yet. |
Doug Schepers | |||
Ian Hickson |
|
They're both public anyway, no reason _not_ to publish them. We should publish whatever is current when we publish. | |
Daniel Schattenkirchner |
|
||
Lachlan Hunt |
|
The spec is nearly feature complete and could be suitable for publishing as a first public working draft, but this isn't essential given that it's already available in public CVS. But when it is published, it should be the latest version checked into CVS at the time of publication. | |
Theresa O'Connor |
|
I voted for the latest versions selectable in the survey, but I would prefer if if we publish whatever the latest revisions are at publish time. | |
Anne van Kesteren |
|
I think all three drafts are ok to publish. Please do publish the latest version. Publishing an older draft as new will only cause confusion. | There are no critical issues that would prevent publishing as a WD as far as I can tell. |
Simon Pieters |
|
||
Adam Nash |
|
I like our Design Principles document, and I think it's a good idea to publish that so that everyone can get a good idea of what the working group's goals are. ("To Design HTML5" can mean a lot of things.) For the spec itself, I have no objections to publishing the current spec draft, and since I last responded to this survey, I think it has grown more important to do so. It'd be useful for anyone who isn't tracking the progress of the mailing list to have "milestones" as a point of reference, rather than referring to the rapidly changing latest editor's copy (or whatever it's called). Besides, unless I missed something we're way behind on the heartbeat even with a granted extension. Either of these documents is more than sufficient to fulfill this requirement without "rushing something out". | |
Chris Wilson |
|
||
Sam Sneddon |
|
It's only a WD, and the HTML 5 spec has a disclaimer warning things might change. Also, a diff document should probably be released along-side the actual spec. | |
Laura Carlson | . | ||
David Andersson |
|
The design principles document has been edited to account for most objections to it, and I do not envision that a full consensus will ever arise considering members of the WG may have entirely conflicting ideas of the goals for HTML 5. The HTML 5 spec can any time be released as a first draft, I do not think releasing a first WD will have more than minor effects on the editing process or WG discussions. | I'd prefer if the multipage version of the spec and not the single page version was the one we published as first WD. |
Asbjørn Ulsberg |
|
While I think there's still work to be done on both documents, I think they are ripe for public discussion and will give a good statement of what the HTML WG is up to and where we are going. | |
Robert Marshall |
|
Everything is already public. | The differences document should be published at the same time as the spec. |
Magnus Kristiansen |
|
(idem) | |
Chaals Nevile |
|
The design principles are just rough ideas, and while they are valuable I am not convinced that we need to get consensus on them before we start (although it would be nice if it happened to exist). The HTML 5 spec should be published, so there is a clear point to work from. Both of these would be drafts, so there is no need to wait for some magical point. We expect them to change. | |
Kazuhito Kidachi |
|
||
Patrick Garies |
|
If necessary, publish the newer design principles and alter them as necessary. I would expect that the newer version should reflect what the working group desires more so than the older version. | |
Peter Howkins | |||
Joshue O'Connor | Most of this stuff is in the public domain already. | ||
Marek Pawlowski |
|
Many improvements were done since "old" versions of these documents. It would be wasteful to publish "old" ones. | |
Philip TAYLOR | |||
Jens Oliver Meiert |
|
||
Kornel Lesinski |
|
||
Jens Bannmann |
|
||
Stéphane Deschamps |
|
||
Mikko Honkala |
|
Whether to publish or not is not so critical question, since the work of the group is open anyway, and based on many years of work by the WhatWG. We are talking about a DRAFT anyway. | |
Michaeljohn Clement |
|
||
Pasquale Popolizio | |||
Dean Edridge | No documents should be published yet. |
Choice | Responders |
---|---|
old Design Principles (Apr 30) |
|
old HTML 5 spec (Jun 1) |
|
Design Principles (2007-09-14) |
|
HTML 5 spec draft (19 October 2007) |
|
summary | by responder | by choice
Which documents are high priority but have critical issues that have to be addressed before they should be released by the Working Group?
Choice | All responders |
---|---|
Results | |
Design Principles | 24 |
HTML 5 spec | 16 |
(45 responses didn't contain an answer to this question)
Skip to view by choice.
Responder | Which documents do you think are good for the group to publish soon but only after critical issues are addressed? | Rationale | Comments |
---|---|---|---|
Danny Liang |
|
||
Chris Adams |
|
||
Benjamin Chait | |||
David McClure |
|
||
Jonas Sicking |
|
I'd like us to do at reviews of at least parts of the spec before we publish it. If for no other reason to give people a fair chance to voice their opinion. | |
Dylan Smith | |||
Robert Burns |
|
Again, perhaps a last-call discussion on the design principles | |
Dannii Willis |
|
||
Scott Lewis | |||
Ben Boyle | |||
Henri Sivonen | I think both documents are OK to publish as WDs as they are. | ||
Chris Veenboer |
|
||
Terry Morris |
|
||
Sander Tekelenburg |
|
More consensus on the design principles would make work on the spec easier. Most notable issue still seems to be 'accessibility'. | |
Bob Hopgood |
|
It puts some boundaries on what is in scope and what is not. | |
David Dailey |
|
Several issues remain contentious. | |
Murray Maloney |
|
||
James Cassell | |||
James Graham | |||
Laurens Holst | |||
Thomas Bradley |
|
||
Darren West |
|
||
Henrik Dvergsdal | |||
Jirka Kosek |
|
I think that Design Principles shouldn't be published before "No Version Syntax vs Explicit Versioning" is resolved. In standards creation it is usual that feature which is not mandatory is accepted by opponents in order to achieve consensus. I really do not understand why some people are not happy with "optional explicit versioning". Since it is optional they doesn't have to use it. | |
David Baron | |||
Sean Fraser |
|
||
Ben Millard | Although there are important issues, I don't think they are so critical that they prevent publishing either of these as a First Working Draft. We can still change them after its published. | ||
Gervase Markham | |||
Sander van Lambalgen | I doubt any issues that are seen as critical can be resolved without a lot of work, and as such they should not delay publication of a first working draft which is very clearly a "work in progress". | ||
Nicolas Le Gall |
|
||
Shawn Medero | These are working drafts and there will always be various issues (at different levels of criticality) that the group will be working out. It seems better to place the documents in front of a larger public audience and continue to work our the issues in an iterative manner. | ||
Gregory Rosmaita | we are evolving a draft, not adopting and tweaking a fait accompli. | we are evolving a draft, not adopting and tweaking a fait accompli. | |
Jon Barnett | |||
Felipe Alvarado | |||
Eric Daspet |
|
||
Gavin Sharp |
|
Both documents are already public, there would be no reason not to officially publish either of them. | |
Brendan Cullen |
|
||
Eric Puidokas |
|
||
Bill Mason | |||
Thomas Higginbotham | |||
Leif Halvard Silli |
|
I subscribe to the rationale tht Laura Carlsson has given. | |
Cal Jacobson |
|
||
David Choi |
|
I still don't think there's a strong consensus regarding the paving cowpaths principle and certain aspects of separation of concerns, among others. Better not to confuse people by drastically changing a document after publishing rather than throwing it out too soon just to prove that we're doing something. | |
Steve Faulkner | |||
Carol King | |||
Stephen Axthelm | |||
Matthew Ratzloff |
|
I think the remaining disputed design principles will be worked out while the group is working on the specification as issues come to light and/or consensus is achieved. The HTML 5 specification should be examined more fully, even though it would only be a first draft. First drafts get a lot of notice. Note that I'm not suggesting a long, drawn-out timeline--simply some time where the chairs accept concerns and then the group has a set amount of time to discuss those concerns. If, at the end of the process there is no consensus, it is tabled for discussion following the first draft. | |
Patrick Taylor | As long as it is obvious that these are living documents, there should be no reason to not publish them as drafts. | ||
Michael Puls II | |||
Ryan Cook | |||
Brad Fults |
|
The latest version of the Design Principles is very close to being ready for publishing. The chairs should make any final arbitrations and push it out the door. | |
Raphael Champeimont | |||
Joseph D'Andrea | |||
Channy Yun |
|
||
Michael Cooper | Not checking either, since I checked both in the previous question. Publishing public drafts of the documents may help in addressing critical issues, so I encourage early publication. | ||
Doug Schepers |
|
There are several instances within the current document that refer to copyrighted material (books and TV shows), or specific products or services. A W3C spec should not be seen to endorse any such thing, and these references should be changed to non-existing example resources. More generally, the current spec is too broad in its scope. It should be trimmed down only to its minimal necessary core, which seems to be the parser, and updated frequently back to its current scope (deliverables every month or so?). That way, each addition can be reviewed carefully before committing to it. | I don't object to publishing the Design Principle, but I believe them to be a distraction from what is actually going on in the specification+implementation process. |
Ian Hickson | I don't think it matters if there are issues. Everything is public anyway, the "publishing" step doesn't mean much IMHO. | ||
Daniel Schattenkirchner | |||
Lachlan Hunt | |||
Theresa O'Connor | |||
Anne van Kesteren | |||
Simon Pieters | |||
Adam Nash | I don't object to publishing either of these in the current state. | ||
Chris Wilson | |||
Sam Sneddon | It's only a WD, and the HTML 5 spec has a disclaimer warning things might change. | ||
Laura Carlson |
|
In order to apply consistent decision making throughout the specification, it is critical to come to consensus on the design principles. No principles or disputed principles can very well lead to inconsistent, contradictory, and discriminating decision making. Principles are fundamental value guides used to base spec decisions. As DanC has said, "their main utility is as justification in discussions." [1]. Publishing the differences document or spec, etc before coming to consensus on the design principles is backward. No agreed upon principles, at best result in decisions (e.g. dropping/adding/changing elements and attributes) without foundation. At worst it results in arbitrary, inconsistent, unjust, partial, wrong-headed, and discriminating decisions. Like TBL said, "design principles very hairy...journey of arriving on consensus valuable; have whole group in on discussion, creates common vocabulary and trust in one another..." [2] Consensus of guiding principles, definition of terms, and a common set of reviewing questions for features would: 1. Aid in communication and understanding. 2. Help avoid needless arguments and churning of issues. 3. Promote consistent and fair decision making. 5. Encourage outcomes that reflect what is important to the working group. 6. Benefit working group progress. [1] http://krijnhoetmer.nl/irc-logs/html-wg/20070817#l-43 [2] http://www.w3.org/2007/04/26-html-wg-minutes | |
David Andersson | |||
Asbjørn Ulsberg | While I don't think the documents are perfect, I don't think they have critical issues either. They need more time in the oven and a lot more exposure, discussions, test cases and implementations, but they are good enough to be put out so all those actions can commence. | ||
Robert Marshall | |||
Magnus Kristiansen | |||
Chaals Nevile | These are drafts. If we can't address the issues in reasonable time (often enough to meet the heartbeat requirements) then the chairs should ensure that issues regarded as critical are noted in the draft and that it is published. | ||
Kazuhito Kidachi |
|
||
Patrick Garies |
|
Features of HTML 4.01 that do not appear in the HTML 5 draft specification should have notes explaining why even if to say nothing more than that the issue has not been thoroughly investigated yet, that more feedback is needed, or that the section has yet to be defined. | Examples of such instances where this is needed include dropped attributes and elements referenced by the specification (such as marquee) that haven’t been defined yet. |
Peter Howkins | |||
Joshue O'Connor | I agree with Michael Coopers comments about leaving these documents unpolished. This is allow transparency. They both have issue (naturally) but that is unavoidable as well as healthy. | ||
Marek Pawlowski | I don't see any critical issues to prevent these documents to be published as First Working Draft. We should publish them as soon as possible. | ||
Philip TAYLOR |
|
||
Jens Oliver Meiert |
|
||
Kornel Lesinski | |||
Jens Bannmann | |||
Stéphane Deschamps | |||
Mikko Honkala | |||
Michaeljohn Clement | |||
Pasquale Popolizio |
|
||
Dean Edridge |
|
Design principles: The design principles should make it clear that the specification is actually HTML and XHTML. And that when contributing to the specification people should ensure that markup & scripting be compatible with text/html and application/xhtml+xml mime types wherever possible. This would mean that most basic (X)HTML5 documents would be almost identical besides the mime type. The spec: As has been pointed out before by a few people in the last questionnaire. There is a problem with having a spec for HTML and XHTML that is called HTML5. How can some one create a XHTML document and call it HTML5? People on mailing lists and forums are already getting confused due to the inappropriate naming of the specification and are saying things like "XHTML is not the future of the web because the W3C has dropped it in favour of HTML5". [1][2][3] The only way that the name HTML5 could possibly work is if the name XHTML5 was used for the XML serialisation of the spec. Otherwise HTML5 by it self is misleading and inappropriate. I believe that the specification should be officially named (X)HTML5. Another option would be to use the names HTML5 and XHTML5 in a parallel spec(this has obviously been suggested before but has not been officially accepted). I think that this is very important and should be addressed before any publication is made of the design principles or the specification. [1] http://ayvahrobby.livejournal.com/201979.html?view=655099#t655099 [2] http://code.google.com/p/swffix/wiki/SWFFix_documentation (scroll down to near bottom of page to see reasons why they are not supporting XHTML) [3] http://www.mail-archive.com/wsg@webstandardsgroup.org/msg30711.html |
Choice | Responders |
---|---|
Design Principles |
|
HTML 5 spec |
|
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
w3c/wbs-design
or
by mail to sysreq
.