W3C WBS Home

Results of Questionnaire Publish HTML 5 update with or without warnings?

The results of this questionnaire are available to anybody.

This questionnaire was open from 2009-08-10 to 2009-08-17.

96 answers have been received.

Jump to results for question:

  1. Publish draft without warnings?
  2. Publish draft with warnings?
  3. What to publish?

1. Publish draft without warnings?

Do you support publishing this Editor's draft (i.e., without the additional warnings, also a.k.a. Ian's draft) as a Working Draft at this time?

Summary

ChoiceAll responders
Results
yes 56
no 40

Details

Responder Publish draft without warnings?Comments
Geoffrey Sneddon yes
Kornel Lesinski yes
Stephen Stewart yes
Toby Inkster no
Andrew Sidwell yes
Nicolas Le Gall no
Doug Wright yes
Michael Puls II yes
Larry Masinter no If the working group is operating on "commit then discuss", then any substance that was committed without discussion (or discussed without resolution) should at least be marked as such in the text. To do otherwise is misleading.
Martin McEvoy yes
John Drinkwater no
Stephen Axthelm no
Dan Smith yes
Joe Williams yes Just the right thing to do.
Manu can be free to do whatever else he wants except control the basic keystrokes in the official standard. His effort is fine and posibly productive, but it is a side show that should be used to the advantage of the group's deliverable, but incorporated as a process help to identify problems, not in the official standard. Otherwise there will just be a continuing sequence of unintended changes.
Sam Ruby no What concerns me most is that Ian agreed to add a note for issue 32 and then removed it without explanation, and did not respond to Laura's and my suggestions to add it back in.
Martin Kliehm no
Matthew Turvey yes
Julian Reschke no The draft (a) didn't make sufficient progress on controversial issues (table/@summary), and (b) introduces new controversial stuff (for instance microdata). Publishing it without stating what the status of these sections is would give the wrong impression to the public.
David Håsäther yes
Benoit Piette no
Edward O'Connor yes As Ian's draft has already gone through FPWD, I think we should always publish new WDs whenever Ian would like to.
Catherine Roy no
John Kemp no I believe that this current draft does not adequately capture the consensus or lack thereof around sections of the document. I also believe that it is important to include that information, and further, that publishing two drafts where one is a superset of the other might be confusing to outsiders.
John Foliot no Given that there is no technical differences between the 2 competing documents at this time, I believe more information over-all is better than less. While we are only talking about a Working Draft here, the reality is that developers are using this as a basis for production class (or near production class) sites today, and providing those content creators with as much info as possible can only be good.
Chris Wilson no This draft does not give adequate information about the state of WG consensus on the individual sections.
Bruce Lawson no
Henri Sivonen yes I think we should just publish a snapshot of the draft Hixie is editing whenever the W3C Process requires a heartbeat WD.
Jeremy Keith yes
Ian Hickson yes
Tantek Çelik yes Inline warnings simply clutter up the draft. There is already an issue tracking system, and I would be ok with a link to the issue tracking system, but I don't think it is required for this working draft.
Jonas Sicking yes
David Hyatt yes
Adele Peterson yes
Lachlan Hunt yes
Maciej Stachowiak yes Ian has been our longtime editor and I believe he has been editing in good faith. It would be poor process to reject his draft based solely on a last-minute objection.
Alexey Proskuryakov yes
Lee Kowalkowski yes I just dislike having content inside attributes in general...
Adam Roben yes
Gavin Sharp yes
Robert Marshall yes
Shawn Medero yes
David Singer yes
Shelley Powers no I'd be willing to see both drafts published, but it doesn't look like this option will pass, so will go with the one that has additional information
Charles McCathie Nevile no I think Ian's current draft is not sufficiently clear as to the real status of agreement in the working group (let alone the wider HTML community), and this creates a misleading impression.

Given the importance of HTML and the value of implementation of drafts, I think that is insufficient guidance to the community, and that we would benefit from providing more clarity to people who may read the spec but not follow the endless discussions of the working group, in order that they concentrate their efforts with some understanding of what clearly enjoys wide support, and what is a temporary and speculative section really reflecting where Ian is up to in processing his email backlog more than anything else.
Channy Yun yes
Cameron McCormack yes Given that the only difference between the two drafts is a small amount of informative text, I don't mind which draft is published.
Karl Dubost no
Alex Robinson no
Leif Halvard Silli no Ian recoginizes that there are wide disagreements - as he think LC will be delayed for years by group members who will object to spec parts based on weak, unfounded "opinions".

How does it make us advance to LC any earlier if we try to push these "opinons" under the carpet?
Jason White no
Roy Fielding no table @summary should not be warned against.

Use of the term URL in a manner that directly contradicts an
Internet standard is negligent and childish. HTML5 can rot until that is fixed.
Ben Adida no
John Vernaleo yes
Masataka Yakura no
Robert O'Callahan yes
Adam Barth yes
Russell Cavell yes
Frank Palinkas no
Alfonso Martínez de Lizarrondo yes
Philip Jägenstedt yes
James Graham yes
Laura Carlson no Delineating open issues [1] in the spec will help the public become aware of topics of concern or problems. Pointing out areas of contention while they are under discussion will aid transparency. Public review and comment from outside the Working Group are vitally needed and should be vigorously sought.

As Jason points out, warnings and comments for reviewers will help enable and encourage members of the public to comment upon difficult or controversial issues, while discouraging early implementation of features that are the subject of debate.

[1] http://www.w3.org/html/wg/tracker/issues/open
Joshue O Connor no
Patrick Lauke no
Hallvord Steen yes
Jude Robinson no
Denis Boudreau no
Richard Schwerdtfeger no The draft should flag the areas being looked at for accessibility. We need to flag problem areas like canvas.

There should also be a reference to adding ARIA support. The working group is working to accelerate comment processing. The reason for not yet responding is that many are interrelated and we need to have all the working drafts modifications in.
Jace Voracek yes
Cynthia Shelly no I can live with publishing Ian's draft, but prefer Manu's.
Jens Meiert yes (Don’t feel strongly about either version.)
Arne Johannessen yes This particular draft lacks notes on the stability of individual sections; ideally, these would be added as editorial notes before publishing. However, publishing this draft as-is still is fine for fulfilling the heartbeat requirement as a matter of principle.
Rob Ennals yes I think Ian is doing roughly the right things with his draft. I appreciate the need to debate controversial issues, but I am not convinced that a public draft with warnings is the right way to do this.
Debi Orton no I don't believe accessibility issues have been adequately addressed in the current editor's draft.
Eric Carlson yes
Vicki Stanton no
Jirka Kosek no
Ben Boyle yes
Laurens Holst no
Per-Erik Brodin yes
Anne van Kesteren yes
Michaeljohn Clement yes
Chris Cressman yes
Scott Lewis yes
Tab Atkins Jr. yes
Manu Sporny no This document is a subset of the HTML-warnings document, meaning that publishing this document would be redundant.
Daniel Schattenkirchner yes Yes, I've got no single objection.
Gregory Rosmaita no clearly delineating (with markup, and NOT merely stylistically) open issues [1] in the HTML5 public working draft will help highlight and invite public comment of topics of concern or problems upon which the HTML WG has had difficulty reaching consensus. as rich schwerdtfeger, laura carlson and jason white (and others) have noted, highlighting areas of contention while they are under discussion will aid transparency, and expedite the consolidation of the working draft. public review and comment from outside the HTML WG
is essential and should be vigorously sought; in addition, the HTML WG should maintain a resource which documents what parts of HTML5 have been implemented, by whom, and what aspects of HTML5 will developers be implementing next? helping dispell questions as to what is implemented, what the HTML WG has agreed upon, and what is either abstract (no implementations) or controversial (implementations without a standard means of providing long and terse descriptions for CANVAS, to cite but a single example. warnings and comments will help
reviewers, as well as enable and encourage members of the public to comment upon difficult or controversial issues, while discouraging early implementation of features that are the subject of debate, or for which no accessible, interoperable alternate exists. test drivers of the spec need not only an accellerator, but also warning signs, alerts, and a brake -- anything else is a disservice to all of the HTML WG's target audiences. [1] http://www.w3.org/html/wg/tracker/issues/open
Steve Faulkner no
Ben Millard yes
Sander van Lambalgen yes
Krijn Hoetmer yes
Stéphane Deschamps no As has been said in several comments: it's long enough that it can stand comments. Without comments it's not clear as to what has reached potential consensus and what is still not final and needs more discussion.
Nikunj Mehta yes
Tobias Horvath no Warnings would correctly outline the current state of discussion regarding pressing issues that need to be taken into consideration. Comments need to be at hand for easy reference, not far away in an issue tracker.
Simon Myers yes

2. Publish draft with warnings?

Do you support publishing this Editor's draft (i.e., with additional warnings, also a.k.a. Manu's draft) as a Working Draft at this time?

In order to provide more useful feedback regarding which warning text should not be considered controversial and thus, should be removed, please follow the suggestions outlined in this email.

Summary

ChoiceAll responders
Results
yes 45
no 51

Details

Responder Publish draft with warnings?Comments
Geoffrey Sneddon no
Kornel Lesinski no
Stephen Stewart no
Toby Inkster yes
Andrew Sidwell no
Nicolas Le Gall yes
Doug Wright no I don't see the value in publishing this draft - the warnings don't add anything on a technical level, and simply rehash (some) of the many emails/open bug reports that the Editor's draft already links to and that interested parties should be skim-reading before sending technical feedback.
Michael Puls II yes
Larry Masinter yes If the working group is operating on "commit then discuss", then any substance that was committed without discussion (or discussed without resolution) should at least be marked as such in the text. To do otherwise is misleading.
Martin McEvoy no
John Drinkwater yes REWORD #the-source-element
Stephen Axthelm yes
Dan Smith no
Joe Williams no
Sam Ruby yes While the criteria is a bit unclear, in general I would prefer to err on the side of too much warning than not enough. The feedback I've seen to date seems to mostly be of the nature of "is this warning necessary?" rather than "this warning should have been included".
Martin Kliehm yes
Matthew Turvey no
Julian Reschke yes (will follow up on the mailing list with respect to the precise warning texts)
David Håsäther no
Benoit Piette yes
Edward O'Connor no
Catherine Roy yes
John Kemp yes I would suggest that for now, it is useful to provide as much information about the ongoing discussion as possible. If there are sections which have warnings, but for which there is no associated tracked issue, I would recommend that either an associated issue is suggested which captures the controversy, or that the warning is dropped (_after_ the draft is published, and has received some review).
John Foliot yes It is my hope that moving forward, warnings or advisories might also note affected W3C Working Groups outside of HTML WG; ideally with some form of indication of communications or requests for feedback.
Chris Wilson yes
Bruce Lawson yes
Henri Sivonen no I think the selection of warnings is too arbitrary to support. I would support porting the WHATWG status marker data into the HTML WG draft in a way that doesn't use scripting (to comply with pubrules).

REMOVE #urls

This warning is redundant, because the spec already says there's a willful violation. The warning is also misleading, because "challenging" it doesn't change requirements for compat with existing content.

REWORD #fetch

HTML 5 is now delegating to MIMESNIFF. The section in HTML 5 doesn't seem to need an update if MIMESNIFF is edited.

REMOVE #misinterpreted-for-compatibility

The warning about the willful violation is redundant, because the spec already says there's a willful violation (again, required for compat as willful violations always are).

As far as I can tell, banning encodings that are problematic from the security perspective or that contribute to gratuitous encoding proliferation isn't controversial.

REMOVE #implied-strong-reference

I haven't seen evidence of this section being controversial. Normative implementation advice is what a sufficiently detailed spec is!

REWORD #other-metadata-names

I don't agree that the sentence "The IETF, IANA and W3C have proven that they are capable of operating these types of registries" can be presented as a statement of fact using the word "proven" due to past issues with the timely functioning of the IANA MIME type registry (consider video/mp4, image/jp2 and image/svg+xml).

REWORD #microdata

I think it would be appropriate to note the immature implementation status of microdata. However, I think it's inappropriate to use the microdata section as a promotional soap box for RDFa. The note shouldn't make forward-looking statements about RDFa or promote a present RDFa REC that is inappropriate for text/html. It would be the clearest not to mention RDFa at all and to focus on the implementation status of microdata.

REWORD #the-source-element

I think a note saying that a baseline codec would be good to have would be appropriate. (Something like the note that was in the spec from December 2007 until recently.) However, I don't think the W3C publication should repeat anyone's speculative patent concerns about other formats.

REWORD #alt

The past controversy has been about absent alt--not about blank alt. The PFWG has sent a response to the HTML WG, and the response OKs absent alt under certain conditions. The issues raised have been about accessibility--not about "usability".

REWORD #the-head-element

In practice, microformat consumers ignore @profile, so it's inappropriate to cite microformats as a reason to have it.
Jeremy Keith no
Ian Hickson no Please count this as a YES if "I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts." wins.

REMOVE warnings on all sections
Tantek Çelik no
Jonas Sicking no NOTE: I'd prefer to publish both drafts, but the current votes seems to lean towards that not happening. In this case I would prefer to just publish Ians draft, which is why I answered 'No' on this question.

However if publishing both drafts is an option then please consider my vote a 'Yes' vote.


Original comment: While I support publishing any draft that someone makes a serious effort to produce, I'm not yet convinced that putting warnings in the spec is the best way to track outstanding issues. Nor am I convinced that we need to track controversial issues separately from outstanding issues (which HTMLWG currently tracks in the issue tracker/bugzilla).

However since I value other peoples opinions, and concede that I could very well be wrong in what the best way to track outstanding/controversial issues is, I'm all for publishing Manu's draft as well.
David Hyatt no
Adele Peterson no
Lachlan Hunt no My previous comments
http://lists.w3.org/Archives/Public/public-html/2009Aug/0447.html

I concur with these comments from James Graham
http://lists.w3.org/Archives/Public/public-html/2009Aug/0563.html

I also concur with Henri's comments about the content of the warnings themselves.
Maciej Stachowiak no I suggest removing the <bb> and garbage collection warnings. I suggest reviewing all warnings to see if they meet the proposed criteria for "controversial issue". I suggest rewording all the issue markers to start with "issue" instead of "warning", and to link to the relevant issues in the issue tracker.


Upon further review: I also agree with all of Henri's remove and reword suggestions.
Alexey Proskuryakov no
Lee Kowalkowski no
Adam Roben no
Gavin Sharp no
Robert Marshall no
Shawn Medero no
David Singer no I don't mind the warnings, as they are true, but overall, I think it should be clear that while some parts of a WD may be more stable than others, all parts are 'undecided and open to change' until the group formally declares consensus on a complete draft. I'm concerned about the implication of stability on un-warned sections
Shelley Powers yes Rather than clutter up the draft, the inline warnings give a good idea of issues still to be resolved, without having to dig through a database.
Charles McCathie Nevile yes There are various unhelpful value-judgements (terms like "wilfully ..." in the warnings) that should be removed first. However, clarifying the status of various sections is something I think should be done, and I far prefer to see the annotation of sections that do not enjoy consensus as part of the formal drafts that we produce.

I support the comments of others who suggest that these annotations should be based on general stability, not just because some things are "controversial".

In a draft that is way too long to sit down and read quickly anyway, a few extra notes that clarify the status of what I am planning to read don't clutter it, but help understand it.
Channy Yun no
Cameron McCormack yes If Manu's draft is published, I would like it to be published only after the split-out spec sections (e.g. Databases) are removed.

I have no opinion on whether certain warnings should be removed or reworded, without having looked into it in detail.
Karl Dubost yes
Alex Robinson yes
Leif Halvard Silli yes NOW - at this time - is the time for warnings. Lifting these issues more into the light will make us reach LC faster.

It is also in the spirit of the hearthbeat requirement to make clear where we stand right now.
Jason White yes Publishing drafts with editorial notes that call the attention of reviewers to
material on which comments are especially sought in order to resolve
controversies or address complex issues is good practice. This is particularly
so in this case, since the draft specification is relatively long, hence
potentially time-consuming to review as a whole.

By pointing out specific issues in the draft, members of the public with
particular expertise in those areas will have a better opportunity to locate,
and comment upon, issues on which members of the working group desire more
input. I am also in favour of noting aspects of the draft which are subject to
disagreement and therefore likely to change, in order to forestall early
implementation of these features that could conflict with subsequent
resolutions arrived at by the working group.
Roy Fielding yes Only because the warnings make it better than the last published draft. A proper solution would remove anything controversial that is not supported by existing practice, perhaps moving it to a separate document on proposed extensions.
Ben Adida yes
John Vernaleo no
Masataka Yakura yes I support the idea of showing issues that HTML5 currently has. so yes.
However, there are some errors (like "alt that is blank" is not what PFWG claimed) and should be corrected. But I think it's a good start.
Robert O'Callahan no
Adam Barth no
Russell Cavell no
Frank Palinkas yes
Alfonso Martínez de Lizarrondo no Those warnings seems to have been picked randomly. To understand the status of each section of the document I've found much better to use the WHAT WG version.
Philip Jägenstedt no The warning at http://html5.digitalbazaar.com/specs/html5-warnings.html#the-source-element reduces the issue to being just about patents while at the same bringing in non-arguments about "open-source" in relation to submarine patents. It also calls out Apple and Microsoft as potential targets if they shipped "Ogg Vorbis and Theora or Dirac" even though Microsoft has said nothing on the issue. This kind of speculation belongs on the mailing list or issue tracker comments, not in the spec. Ian's original note was better, but nothing at all is fine too. Warnings don't help implementors agree on a codec and authors would be better helped by a link to something like http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support
James Graham no I believe this draft takes a counterproductive approach to addressing the problem it was designed to solve; see http://lists.w3.org/Archives/Public/public-html/2009Aug/0563.html for more details.
Laura Carlson yes Delineating open issues [1] in the spec will help the public become aware of topics of concern or problems. Pointing out areas of contention while they are under discussion will aid transparency. Public review and comment from outside the Working Group are vitally needed and should be vigorously sought.

As Jason pointed out, warnings and comments for reviewers will help enable and encourage members of the public to comment upon difficult or controversial issues, while discouraging early implementation of features that are the subject of debate.

I agree with Henri to reword the alt warning. The issue is about the spec allowing an <img> element to have no text alternative - not about blank alt. WAI CG has provided advice [2] which has not been acted upon. It is an accessibility issue. It is not a usability issue. Details are in the Wiki. [3]

[1] http://www.w3.org/html/wg/tracker/issues/open
[2] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
[3] http://esw.w3.org/topic/HTML/IssueAltAttribute
Joshue O Connor yes
Patrick Lauke yes
Hallvord Steen no I strongly support the idea of doing this, but not its rushed and random implementation in Manu's draft.

Some sort of consensus tracking could be added to the spec review copy so that reviewers could give thumbs up/down for each section and subsection. It would be fairly obvious from a high number of "votes" for a specific section that it has generated passionate disagreements, and this information should be presented along with implementation status details. (As this as described is not really a *vote* for/against the feature, vote rigging might not be a problem).
Jude Robinson yes
Denis Boudreau yes
Richard Schwerdtfeger yes There should also be a note regarding investigation of canvas for accessibility.
Jace Voracek no
Cynthia Shelly yes I prefer this draft, but can live with publishing Ian's.
Jens Meiert yes (Don’t feel strongly about either version.)
Arne Johannessen no Concurring with Charles McCathieNevile's comments, I generally support incorporating notes on the stability of individual sections (for example, based on existing WHATWG data). However, none of this particular draft's selection and wording of notes appears to me as being ready for publishing at this time.
Rob Ennals no
Debi Orton yes This version provides more information for those web authors who relied on the accessibility techniques associated with WCAG 1.0. Providing this additional information allows more informed comment and may expose some more palatable options for achieving the same ends.
Eric Carlson no
Vicki Stanton yes
Jirka Kosek yes
Ben Boyle no I know there's been some explanation on the list but needs to be clear for those who just come to the draft what's going on. Drafts look the same, this is confusing.
Laurens Holst yes Agreement with all of the reservations in Sporny’s draft, except for #the-source-element.
Per-Erik Brodin no
Anne van Kesteren no We should either be exhaustive with warnings or have it based on some criteria, but not arbitrary. Having said that, the draft already announces it is WIP and I have not seen anything that suggests this is not enough.
Michaeljohn Clement no
Chris Cressman no
Scott Lewis no Criticisms of the set of warnings currently in the draft have convinced me that there should be more discussion in-group and possibly changes to the set of warnings before publication.
Tab Atkins Jr. yes With Manu's new updates, I'm satisfied with the 'warning draft'
Manu Sporny yes
Daniel Schattenkirchner no The warnings in this draft add no real information.
If there are issues they have to be discussed, if there are features at risk, maybe mention them in the Differences document that has been published along with the HTML5 draft.
Gregory Rosmaita yes editors drafts should be public, but must be clearly marked as such, and every editor's draft needs he same comments embedded in it as should any public working draft
Steve Faulkner yes
Ben Millard no
Sander van Lambalgen no Lack of consensus and the possibility of change is implied in the working draft status. Although I appreciate the constructive approach to more explicitly informing readers about known areas under heavy discussion, this particular subset seems too hastily thrown together on more or less arbitrary grounds. Additionally these warnings might give the false impression that sections not marked up with a warning are guaranteed to be more stable and/or carry more consensus than might actually be true.
Krijn Hoetmer no
Stéphane Deschamps yes Warnings are vital, from what I've gathered when I tell people of HTML5. So many things change (or are not stable yet) that people want to understand, and they don't necessarily have the time to read the oh-so lengthy discussions on the public-html list.
Nikunj Mehta no
Tobias Horvath yes
Simon Myers yes REMOVE as per Henri Sivonen's comments
REWORD as per Henri Sivonen's comments

3. What to publish?

Given that these documents differ only in the presence or absence of warnings, how would you like the results of the poll to be interpreted?

Summary

ChoiceAll responders
Results
I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. 30
I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. 66

Details

Responder What to publish?Comments
Geoffrey Sneddon I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Kornel Lesinski I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Stephen Stewart I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Toby Inkster I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Andrew Sidwell I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Nicolas Le Gall I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Doug Wright I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Whilst I believe the approach of annotating/selectively editing the Editor's draft potentially has merit as a platform for discussion within the WG, I believe that actually publishing multiple versions of the same document as official WDs of the WG is just plain confusing.

I would not vote against publishing a reformulation of the additional material as separate WG Note.
Michael Puls II I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Larry Masinter I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. I think neither "majority" nor "most votes" should be used: if there is not "consensus" and there are votes (rather than straw polls), then one-vote-per-independent organization should be retained (one company has 17 members in "good standing"), and the "good standing" role of "invited experts" who are not actually experts or who do not actually participate should be reevaluated. A vote should not determined by those who are listed as working group members out of courtesy or for the rationale that their IPR disclaimer is needed.

As far as IPR is concerned, both drafts contain new, unreviewed material that might trigger a patent review; commit-then-discuss should be evaluated against the patent policy to see if some adjustment is needed.
Martin McEvoy I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
John Drinkwater I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Stephen Axthelm I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Dan Smith I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Joe Williams I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Manu's work can be used but not directly.
Sam Ruby I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. In this case could live with either document and in the case of competing technical drafts I would support publishing both; but publishing two drafts simultaneously that differ only in informative content seems like it would cause confusion.
Martin Kliehm I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Matthew Turvey I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Julian Reschke I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Publishing both would create confusion, and also raise the question about which is "the right one".
David Håsäther I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Benoit Piette I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Edward O'Connor I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. I think each "fork" should go through FPWD (which so far has only happened with formal WG decision-by-vote).

Once through FPWD, I think we should always publish new WDs whenever the editor(s) would like to.

(I think it wouldn't be a good thing for Manu's draft to also go through FPWD, as it only differs in warnings from Ian's, but nevertheless if we're going to embrace the "anyone can author a spec" idea, we should embrace it fully.)
Catherine Roy I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
John Kemp I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. As mentioned, I think it might be confusing to publish two drafts where one is a superset of the other.
John Foliot I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. If there were technical differences between the 2 documents, my answer would likely have been very different. Since I currently see the "Manu's Draft" version as simply an enhanced copy of the work produced by Ian I see no benefit in making both available as Working Drafts.
Chris Wilson I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Bruce Lawson I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. changed my answer, having seen John Foliot's cleverer response: If there were technical differences between the 2 documents, my answer
would likely have been very different. Since I currently see the "Manu's
Draft" version as simply an enhanced copy of the work produced by Ian I see
no benefit in making both available as Working Drafts.
Henri Sivonen I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. The purpose of heartbeat WDs is to communicate to the community outside the WG itself, and publishing multiple drafts with only differences in informative statements fails at clear communication.
Jeremy Keith I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Ian Hickson I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. If "I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts." wins, please count my vote as YES to both drafts.
Tantek Çelik I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Jonas Sicking I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
David Hyatt I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Adele Peterson I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Lachlan Hunt I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Publishing two separate drafts that are almost identical except for a few editorial comments about the stability of some random "controversial" sections does not solve any real problems, and will only serve to create confusion among the wider community.

Even though I do not support the draft with extra warnings, I would rather see that one published by itself than have both needlessly published together.
Maciej Stachowiak I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Alexey Proskuryakov I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Lee Kowalkowski I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Adam Roben I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Gavin Sharp I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. I think publishing multiple drafts would be problematic from a PR perspective.
Robert Marshall I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Shawn Medero I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
David Singer I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. I fear having two variants of one document would be confusing.
Shelley Powers I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. Two drafts would acknowledge the Editor's work, while providing another document that shows issues of concern. There is no PR problem with this approach--it reflects the current state of the group. On the other hand, I have a difficult time understanding why people who profess support for making information both visible and semantic, would vote for a choice that does neither.
Charles McCathie Nevile I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Publishing two drafts seems likely to lead to confusion.

However I agree with Larry that a serious attempt to reach consensus makes more sense than going through with something that receives a large minority of dissent.

I recognise that the decision on how to proceed is up to the chairs, rather than a poll of all comers actually being binding.

Please note that Opera Software, with many participants in the group, is not expressing a formal opinion at this time, but rather each participant is free to vote as they see fit, in what we understand to be the spirit of this poll. Should a suggestion such as Larry's be accepted, we would of course submit a single formal vote clarifying that it is such.
Channy Yun I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Cameron McCormack I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. While I am happy for the WG to publish multiple documents, I don't think selecting between drafts to publish as the main HTML 5 spec at a given point in time is the best way to proceed.

I wonder if David Hyatt should really be listed as editor on whichever documents end up being published, though, given that he has not edited either.
Karl Dubost I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Alex Robinson I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Leif Halvard Silli I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. Now is the time to, eventually, display disagreement.
Jason White I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Roy Fielding I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Ben Adida I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. I would prefer that we pick a consistent long-term approach: if we are CTR, then everyone gets to CTR.
John Vernaleo I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. For what it's worth, I don't feel as strongly about my answer to this question than the other two and can see good reasons for either way.
Masataka Yakura I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Robert O'Callahan I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Adam Barth I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Publishing two very similar editor's drafts would be pretty confusing. If we end up doing that, we should explain what the differences are and why we're choosing to publish both.
Russell Cavell I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Frank Palinkas I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Alfonso Martínez de Lizarrondo I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Philip Jägenstedt I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Publishing multiple drafts would be harmful. Instead of having polls like this we should spend our time discussing the specific issues, possibly resulting in the inclusion/removal of notes or warnings in Ian's draft, but preferably actual solutions.
James Graham I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Laura Carlson I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Joshue O Connor I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Patrick Lauke I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Hallvord Steen I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Jude Robinson I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Denis Boudreau I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Richard Schwerdtfeger I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. These choices seem redundant.
Jace Voracek I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Although I believe that publishing these approved drafts would be acceptable for those that have a preference, I conclude that taking a vote of which individual draft to publish will lead to the best outcome.
Cynthia Shelly I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Jens Meiert I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Arne Johannessen I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Rob Ennals I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Publishing multiple drafts will be confusing.
Debi Orton I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. Based on what I have read in the workgroup's listserv, I fully expect the draft with less accessibility support to receive the majority of votes. In that case, I would like the explanatory draft to be available also, so that we could point authors to that version for explanations of changes.
Eric Carlson I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Vicki Stanton I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Jirka Kosek I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Publication of multiple drafts will confuse spec readers from outside of HTML WG.
Ben Boyle I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. I would prefer there be one draft for clarity, however I am not opposed to publishing multiple drafts to see if that achieves anything (other than confusion), which it might. Think the differences need to be highlighted in a clear and obvious way for this to be effective.
Laurens Holst I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Per-Erik Brodin I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Anne van Kesteren I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. In general I'm ok with publishing all Editor's Draft that have majority approval, but they have to offer some normative difference in my opinion.
Michaeljohn Clement I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Chris Cressman I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Scott Lewis I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Tab Atkins Jr. I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Manu Sporny I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Daniel Schattenkirchner I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. The original draft is sufficient.
Gregory Rosmaita I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Steve Faulkner I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Ben Millard I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. Being able to fork the development of HTML5 so that alternative approaches can be worked on and reviewed has always been part of the project, as I understand it. Competition and collaboration can co-exist within a project and improve it.
Sander van Lambalgen I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Krijn Hoetmer I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.
Stéphane Deschamps I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. I expect it's a matter of democracy. But I really don't see the point of publishing a draft at this point without comments and warnings.
Nikunj Mehta I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. Our vote is focused on the continued progress of HTML5. We are supportive of Manu's intention to clarify to the general audience a full measure of where the working group stands. Given the relative short life to date of Manu's draft and the rather daunting task of adding adequate and appropriate warnings in the existing draft, we feel it is best to advance Ian's draft at this time and revisit this topic at the next heartbeat.
Tobias Horvath I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts.
Simon Myers I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft.

More details on responses

Non-responders

The following persons have not answered the questionnaire:

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

Send an email to all the non-responders.


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

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


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