W3C WBS Home

Results of Questionnaire What should the HTML WG publish first?

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:

  1. Working Draft Process Background
  2. Which document should we focus on for first publication?
  3. Which documents do you think are OK for the group to publish in their current state?
  4. Which documents do you think are good for the group to publish soon but only after critical issues are addressed?

1. Working Draft Process Background

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.

Details

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
Edward O'Connor
Anne van Kesteren
Simon Pieters
Adam Nash
Chris Wilson
Geoffrey Sneddon
Laura Carlson
David Andersson
Asbjørn Ulsberg
Robert Marshall
Magnus Kristiansen
Charles McCathie Nevile
Kazuhito Kidachi
Patrick Garies
Peter Howkins
Joshue O Connor
Marek Pawlowski
Philip TAYLOR What question is being asked here ?
Jens Meiert
Kornel Lesinski
Jens Bannmann
Stéphane Deschamps
Mikko Honkala
Michaeljohn Clement
Pasquale Popolizio
Dean Edridge

2. Which document should we focus on for first publication?

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)

Summary

ChoiceAll 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)

Details

Responder Which document should we focus on for first publication?RationaleComments
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
Edward 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
Geoffrey 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.
Charles McCathie 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 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

3. Which documents do you think are OK for the group to publish in their current state?

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:

Summary

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

View by responder

Details

Responder Which documents do you think are OK for the group to publish in their current state?RationaleComments
Danny Liang
  • old Design Principles (Apr 30)
Chris Adams
Benjamin Chait
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
David McClure
  • old HTML 5 spec (Jun 1)
Jonas Sicking
  • old Design Principles (Apr 30)
Dylan Smith
  • old Design Principles (Apr 30)
Robert Burns
  • old Design Principles (Apr 30)
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
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
Ben Boyle
Henri Sivonen
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
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
  • old Design Principles (Apr 30)
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
  • old HTML 5 spec (Jun 1)
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
  • old Design Principles (Apr 30)
James Graham
  • old HTML 5 spec (Jun 1)
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
  • old Design Principles (Apr 30)
Since the design principles are the basis for everything else, they should logically be published first.
Darren West
Henrik Dvergsdal
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
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
  • old HTML 5 spec (Jun 1)
David Baron
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
Sean Fraser
  • old HTML 5 spec (Jun 1)
Ben Millard
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
* 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
  • old Design Principles (Apr 30)
Sander van Lambalgen
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
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
  • old Design Principles (Apr 30)
Shawn Medero
  • old HTML 5 spec (Jun 1)
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
  • old Design Principles (Apr 30)
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
  • old Design Principles (Apr 30)
Felipe Alvarado
Eric Daspet
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
Gavin Sharp
Brendan Cullen There still seems to be too much disagreement, a formal review would be beneficial
Eric Puidokas
Bill Mason
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
Thomas Higginbotham
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
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
  • old HTML 5 spec (Jun 1)
Stephen Axthelm
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
Matthew Ratzloff
  • old Design Principles (Apr 30)
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
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
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
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
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
  • old HTML 5 spec (Jun 1)
Brad Fults
Raphael Champeimont
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
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
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
They're works in progress. OK to share IMO. Just be sure to disclaim appropriately.
Channy Yun
  • old HTML 5 spec (Jun 1)
Michael Cooper
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
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
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
They're both public anyway, no reason _not_ to publish them.

We should publish whatever is current when we publish.
Daniel Schattenkirchner
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
Lachlan Hunt
  • HTML 5 spec draft (19 October 2007)
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.
Edward O'Connor
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
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
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
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
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
Adam Nash
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
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
  • Design Principles (2007-09-14)
Geoffrey Sneddon
  • HTML 5 spec draft (19 October 2007)
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
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
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
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
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
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
Everything is already public.The differences document should be published at the same time as the spec.
Magnus Kristiansen
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
(idem)
Charles McCathie Nevile
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
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
  • Design Principles (2007-09-14)
Patrick Garies
  • Design Principles (2007-09-14)
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
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
Many improvements were done since "old" versions of these documents. It would be wasteful to publish "old" ones.
Philip TAYLOR
Jens Meiert
  • old Design Principles (Apr 30)
  • old HTML 5 spec (Jun 1)
Kornel Lesinski
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
Jens Bannmann
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
Stéphane Deschamps
  • Design Principles (2007-09-14)
Mikko Honkala
  • Design Principles (2007-09-14)
  • HTML 5 spec draft (19 October 2007)
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
  • HTML 5 spec draft (19 October 2007)
Pasquale Popolizio
Dean Edridge No documents should be published yet.

View by choice

ChoiceResponders
old Design Principles (Apr 30)
  • Danny Liang
  • Benjamin Chait
  • Jonas Sicking
  • Dylan Smith
  • Robert Burns
  • Scott Lewis
  • Henri Sivonen
  • Terry Morris
  • James Cassell
  • Thomas Bradley
  • Henrik Dvergsdal
  • David Baron
  • Ben Millard
  • Gervase Markham
  • Sander van Lambalgen
  • Nicolas Le Gall
  • Gregory Rosmaita
  • Jon Barnett
  • Eric Daspet
  • Bill Mason
  • Thomas Higginbotham
  • Stephen Axthelm
  • Matthew Ratzloff
  • Patrick Taylor
  • Michael Puls II
  • Raphael Champeimont
  • Joseph D'Andrea
  • Michael Cooper
  • Jens Meiert
old HTML 5 spec (Jun 1)
  • Benjamin Chait
  • David McClure
  • Scott Lewis
  • Henri Sivonen
  • David Dailey
  • James Graham
  • Henrik Dvergsdal
  • Jirka Kosek
  • David Baron
  • Sean Fraser
  • Ben Millard
  • Sander van Lambalgen
  • Shawn Medero
  • Eric Daspet
  • Bill Mason
  • Thomas Higginbotham
  • Carol King
  • Stephen Axthelm
  • Patrick Taylor
  • Michael Puls II
  • Ryan Cook
  • Raphael Champeimont
  • Joseph D'Andrea
  • Channy Yun
  • Michael Cooper
  • Jens Meiert
Design Principles (2007-09-14)
  • Michael Cooper
  • Ian Hickson
  • Daniel Schattenkirchner
  • Edward O'Connor
  • Anne van Kesteren
  • Simon Pieters
  • Adam Nash
  • Chris Wilson
  • David Andersson
  • Asbjørn Ulsberg
  • Robert Marshall
  • Magnus Kristiansen
  • Charles McCathie Nevile
  • Kazuhito Kidachi
  • Patrick Garies
  • Marek Pawlowski
  • Kornel Lesinski
  • Jens Bannmann
  • Stéphane Deschamps
  • Mikko Honkala
HTML 5 spec draft (19 October 2007)
  • Michael Cooper
  • Ian Hickson
  • Daniel Schattenkirchner
  • Lachlan Hunt
  • Edward O'Connor
  • Anne van Kesteren
  • Simon Pieters
  • Adam Nash
  • Geoffrey Sneddon
  • David Andersson
  • Asbjørn Ulsberg
  • Robert Marshall
  • Magnus Kristiansen
  • Charles McCathie Nevile
  • Marek Pawlowski
  • Kornel Lesinski
  • Jens Bannmann
  • Mikko Honkala
  • Michaeljohn Clement

4. Which documents do you think are good for the group to publish soon but only after critical issues are addressed?

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?

Summary

ChoiceAll responders
Results
Design Principles 24
HTML 5 spec 16

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

Skip to view by choice.

View by responder

Details

Responder Which documents do you think are good for the group to publish soon but only after critical issues are addressed?RationaleComments
Danny Liang
  • HTML 5 spec
Chris Adams
  • HTML 5 spec
Benjamin Chait
David McClure
  • Design Principles
Jonas Sicking
  • HTML 5 spec
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
  • Design Principles
Again, perhaps a last-call discussion on the design principles
Dannii Willis
  • Design Principles
  • HTML 5 spec
Scott Lewis
Ben Boyle
Henri Sivonen I think both documents are OK to publish as WDs as they are.
Chris Veenboer
  • Design Principles
Terry Morris
  • HTML 5 spec
Sander Tekelenburg
  • Design Principles
More consensus on the design principles would make work on the spec easier. Most notable issue still seems to be 'accessibility'.
Bob Hopgood
  • Design Principles
It puts some boundaries on what is in scope and what is not.
David Dailey
  • Design Principles
Several issues remain contentious.
Murray Maloney
  • Design Principles
James Cassell
James Graham
Laurens Holst
Thomas Bradley
  • HTML 5 spec
Darren West
  • Design Principles
  • HTML 5 spec
Henrik Dvergsdal
Jirka Kosek
  • Design Principles
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
  • Design Principles
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
  • HTML 5 spec
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
  • HTML 5 spec
Gavin Sharp
  • Design Principles
  • HTML 5 spec
Both documents are already public, there would be no reason not to officially publish either of them.
Brendan Cullen
  • Design Principles
Eric Puidokas
  • Design Principles
Bill Mason
Thomas Higginbotham
Leif Halvard Silli
  • Design Principles
I subscribe to the rationale tht Laura Carlsson has given.
Cal Jacobson
  • HTML 5 spec
David Choi
  • Design Principles
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
  • HTML 5 spec
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
  • Design Principles
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
  • Design Principles
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
  • HTML 5 spec
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
Edward O'Connor
Anne van Kesteren
Simon Pieters
Adam Nash I don't object to publishing either of these in the current state.
Chris Wilson
Geoffrey Sneddon It's only a WD, and the HTML 5 spec has a disclaimer warning things might change.
Laura Carlson
  • Design Principles
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
Charles McCathie 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
  • Design Principles
Patrick Garies
  • HTML 5 spec
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
  • Design Principles
Jens Meiert
  • Design Principles
  • HTML 5 spec
Kornel Lesinski
Jens Bannmann
Stéphane Deschamps
Mikko Honkala
Michaeljohn Clement
Pasquale Popolizio
  • Design Principles
Dean Edridge
  • Design Principles
  • HTML 5 spec
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

View by choice

ChoiceResponders
Design Principles
  • David McClure
  • Robert Burns
  • Dannii Willis
  • Chris Veenboer
  • Sander Tekelenburg
  • Bob Hopgood
  • David Dailey
  • Murray Maloney
  • Darren West
  • Jirka Kosek
  • Sean Fraser
  • Gavin Sharp
  • Brendan Cullen
  • Eric Puidokas
  • Leif Halvard Silli
  • David Choi
  • Brad Fults
  • Channy Yun
  • Laura Carlson
  • Kazuhito Kidachi
  • Philip TAYLOR
  • Jens Meiert
  • Pasquale Popolizio
  • Dean Edridge
HTML 5 spec
  • Danny Liang
  • Chris Adams
  • Jonas Sicking
  • Dannii Willis
  • Terry Morris
  • Thomas Bradley
  • Darren West
  • Nicolas Le Gall
  • Eric Daspet
  • Gavin Sharp
  • Cal Jacobson
  • Matthew Ratzloff
  • Doug Schepers
  • Patrick Garies
  • Jens Meiert
  • Dean Edridge

More details on responses

Non-responders

The following persons have not answered the questionnaire:

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

Send an email to all the non-responders.


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

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


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