W3C WBS Home

Results of Questionnaire How should work on the canvas element and immediate mode graphics API proceed?

The results of this questionnaire are available to anybody.

This questionnaire was open from 2007-11-16 to 2007-11-28.

36 answers have been received.

Jump to results for question:

  1. Canvas and immediate mode graphics API introductory/tutorial note
  2. Should the HTML WG charter be modified to more explicitly include canvas and immediate mode graphics?
  3. Are you interested to work on splitting the immediate mode graphics API out of the HTML 5 spec?
  4. Where should work on the immediate mode graphics API concentrate?

1. Canvas and immediate mode graphics API introductory/tutorial note

Should the Working Group produce a note to supplement the detailed specification, similar to Offline Web Applications? That is: a sort of extended abstract that might grow into a tutorial.


ChoiceAll responders
No, don't do that 14
Yes, somebody should do that 15
Yes, I'm interested to do that 2

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


Responder Canvas and immediate mode graphics API introductory/tutorial noteRationaleComments
Theresa O'Connor I'm inbetween "No, don't do that" and "Yes, somebody should do that." If somebody wants to write such a tutorial, that's fine with me, but I'm not going to say whether anybody should or not.
Geoffrey Sneddon Yes, somebody should do that Does this not fall under the prior tasks survey of a general tutorial?

Also, this is not my area of expertise, so I'm not willing to help with this section of such a tutorial.
Thomas Broyer No, don't do that There's already enough canvas examples and tutorials out there.
James Cassell Yes, somebody should do that
Bill Mason
Ian Hickson No, don't do that I don't think this is necessary -- unlike the offline APIs, <canvas> is well known and the relevant experts already know about it, so we don't have to specifically get their attention to get it reviewed.

There are also lots of pages on the Web already discussing this.

Of course if someone wants to do it I wouldn't have any problem with this group publishing such a note. Indeed I would encourage it.
I would have voted "Abstain" if that was an option.
Scott Lewis Yes, somebody should do that
Anne van Kesteren I think <canvas> already has lots of tutorial like information out there, but if someone wants to work on this we should encourage that I think.I didn't pick any option as the above three don't really reflect my answer.
Alfonso Martínez de Lizarrondo
Michael Puls II No, don't do that I'm not sure it's necessary. I don't think it would hurt though.
Daniel Schattenkirchner No, don't do that
Shawn Medero Yes, somebody should do that I'm not sure my answer is a "we must do this" - it is more of a "well, it would be nice if someone has the energy".
Lachlan Hunt No, don't do that Technically, this is an abstain vote, but the option isn't available. I don't mind if somebody wants to work on it and nor do I mind if it doesn't get written.
James Graham Yes, somebody should do that This would be nice to have but it is not so much a requirement as <canvas> is already deployed and tutorials are already available giving an overview of the functionality.
Julian Reschke No, don't do that
Arne Johannessen abstain (somebody MAY do that)
Dimitri Glazkov No, don't do that Use the resources to build a good spec. Tutorials and abstract notes will come from the community.
Terry Morris Yes, somebody should do that
Maciej Stachowiak Yes, somebody should do that It's good to have documents that give an introductory overview of particular areas of the spec. I am generally in favor, if willing volunteers can be foundI have made an effort to look for volunteers but certainly do not have the time myself.
David Dailey Yes, somebody should do that
Marek Pawlowski No, don't do that Canvas is already known. There are already examples and, which is more important, working use cases.
Scott Vesey Yes, somebody should do that
Sander van Lambalgen No, don't do that If someone wants to put in the effort, I'm not opposed, but otherwise I think there's more important things to do, and <canvas> is already pretty well known out there.
Yes, somebody should do that I think a lot of reason why the canvas element hasn't been more readily utilized and experimented within the development community is because there hasn't been any really good definitive intros to what it's purpose is and how it should be used.

By us providing a good intro, we help prevent against fragmentation and misinterpretation of the people who will be going out and teaching and writing future intros and outreach material.
Mikko Honkala Yes, somebody should do that It has not been shown that tutorials are harmful :)

In a group of this size (hundreds of persons), producing tutorial notes should not take too much effort away from the main thing (which is producing specifications for IMPLEMENTERS).
Yes, I'm interested to do that Probably combining this with the Offline Web Applications document to create an Introduction to HTML5 makes the most sense.
Gregory Rosmaita No, don't do that
Philip Taylor Yes, I'm interested to do that It would be helpful to explain the design rationale, and to describe the canvas/SVG relationship and where each would be more appropriate, and perhaps to provide a quick API reference. There is already a reasonable tutorial on the Mozilla wiki, so that should not be duplicated.
Andrew Sidwell Yes, somebody should do that Not within my area of expertise.
Matthew Raymond Yes, somebody should do that As long as there are good tutorials out there, I could care less either way. It couldn't hurt, though, so I vote yes.
Marc Drumm Yes, somebody should do that
Chris Wilson No, don't do that
Robert Marshall No, don't do that
David Baron No, don't do that This seems like reasonably well-understood material, which means tutorials can be written quite well by others. Thus it doesn't seem like the working group needs to spend time on it.
Gavin Sharp No, don't do that
Michael[tm] Smith Yes, somebody should do that Despite the fact that there are existing tutorials and documention on the canvas element and API, I don't think that necessarily should prevent the HTML working group from publishing a primer/extended-abstract Note on canvas, if we have volunteers who can commit long-term to acting as editors for that Note. I can't see that it would hurt anything to have it, and a Yes decision from the group on this question does not absolutely bind the group to actually producing the document (unless/until we have a willing editor and have set public expectations by publicly announcing plans to deliver it).

2. Should the HTML WG charter be modified to more explicitly include canvas and immediate mode graphics?

Note discussion 19 November where some WG participants consider this implicitly in the scope of our March 2007 charter under "Forms and common UI widgets such as progress bars, datagrids, menus, and other controls" but others would prefer to make it more explicit in the charter.

The chairs are obliged to keep the Hypertext Coordination Group, the W3C Director, and the W3C membership informed about issues on the edge of our scope. But first we'd like advice from WG participants. Should a revised charter be reviewed by the W3C membership per section 5.3 Modification of an Activity of the W3C Process document?

If so, please suggest specific changes in a comment.


ChoiceAll responders
yes 2
no 29
concur 5


Responder Should the HTML WG charter be modified to more explicitly include canvas and immediate mode graphics?RationaleComments
Theresa O'Connor no Rechartering should be avoided if at all possible.
Geoffrey Sneddon no It was known at the time of the chartering that this was part of the WHATWG draft, on which the majority of the charter is based. If the W3C staff did not see fit to include it here explicitly, it should be implied.

Also, re-chartering would waste even more time than this WG really needs. We've spent an insane amount of time dealing with W3C bureaucracy and discussing process issues on the mailing list all ready, can we not just get on and write the damned spec?
Thomas Broyer no
James Cassell concur
Bill Mason no
Ian Hickson no Reopening the charter discussion would be entering a rathole with rats the size of lions and would put back the working group by months.It's unnecessary anyway, all modern widget libraries include graphics canvases as a matter of course. Suggesting that the aforementioned charter line item doesn't include a canvas is IMHO disingenuous.
Scott Lewis no
Anne van Kesteren no As I said in the other survey, immediate mode graphics are part of most (if not all) application platforms.
Alfonso Martínez de Lizarrondo no
Michael Puls II no
Daniel Schattenkirchner no
Shawn Medero no Three of the charter's deliverables cover <canvas> or a similar immediate mode graphics element+api:

# Document Object Model (DOM) interfaces providing APIs for such a language.
# Forms and common UI widgets such as progress bars, datagrids, menus, and other controls.
# APIs for the manipulation of linked media.
Lachlan Hunt no Too much bureaucracy involved in rechartering.In hindsight, it probably would have been better if it were more explicit in the original charter, but
James Graham no I strongly believe that the precedence of existing GUI toolkits is enough to establish that immediate mode graphics falls under the scope of "common UI widgets". Furthermore my understanding of the rechartering process is that it will significantly disrupt the activity of the group for a period of months; a consequence which seems wholly out of proportion to the magnitude of the problem.
Julian Reschke yes In the last months, every time I mentioned "canvas" being a new HTML element to colleagues not being involved in either the WHATWG or latest browser releases, the response was complete surprise -- most people assumed that the natural thing to work on would be better support for embedded SVG, not something new.

So yes, if this is meant to be in HTML5, I think it needs to be stated in the charter. And no, the fact it has been in the WHATWG draft for a long time doesn't make it automatically part of the charter.
Arne Johannessen no
Dimitri Glazkov no Not sure why this is necessary. The charter IMHO is inclusive of this part of the spec.
Terry Morris concur
Maciej Stachowiak no 1) It is unneccessary - this is already covered by the following charter requirements:

"A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web." -- Applications frequently use graphics drawing areas.

"Document Object Model (DOM) interfaces providing APIs for such a language." -- An immediate-mode graphics API is a critical aspect of an element that represents the semantics of an application drawing area.

"Forms and common UI widgets such as progress bars, datagrids, menus, and other controls." -- Most UI widget toolkits (including, to my knowledge, Cocoa, Carbon, Win32, WPF, Gtk+, Qt, WxWidgets, Tk) provide an immediate-mode custom drawing widget.

"APIs for the manipulation of linked media." -- The canvas API provides for basic manipulation of linked images using drawImage().

"Editing APIs and user-driven WYSIWYG editing features." -- The canvas API provides for interactive user editing of bitmap images, both creation of whole new images and interactive adjustment (cropping, rotation, filter effects, color adjustment, etc) of existing linked images.

2) Modifying the charter carries high risk. The rechartering process can take a long time, and can change the charter in arbitrary ways.

- The original HTML WG charter process took at least 6 months, maybe more since much of it was invisible to the outside world.

- Many changes were made to the charter between circulated drafts, with no explanation. The final published charter did not match anything that anyone outside the W3C team had ever seen (indeed, that is part of the source of the confusion over canvas).

So our group could be under a cloud of uncertainty for many months. We should avoid taking unnecessary risks.

3) It sets a bad precedent. We should interpret the charter as covering all reasonable application and document features. Otherwise, we will have to recharter every time someone realizes we are missing important functionality that doesn't already have a detailed line item in the charter.

David Dailey concur I believe that the task of creating an HTML that supports client-side applications requires both client-side graphics and client-side image analysis. Hence immediate mode graphics (whatever that may mean) is within my own sense of the purpose of the Working Group. On the other hand, forcing a recharter to allow the systematic re-examination of the boundaries between the existing SVG and the reinvention of the wheel that <canvas> proposes would seem a) beneficial and b) consistent with the groups Design Principles. As proponents point out, <canvas> is lighter-weight than SVG (despite its redundancy with it), and the rebel WHATWG has already adopted it, so it may provide a way for those browser developers who want to ignore SVG an out. Overall, that would not in the best interest of developers interested in rich content development, and may indeed hurt the overall goal of interoperability.
Marek Pawlowski no Rechartering would be a waste of time.
Scott Vesey no The current charter is not and should not be considered an inclusive list of all work contained within the HTML 5 specification.
Sander van Lambalgen no
no It seems like it does fall within our scope but I also think that others should be notified.
Mikko Honkala no Already covered by the charter.
Gregory Rosmaita no it is not in the purview of the HTML WG or the Markup Activity, but belongs in the Graphics activity (http://www.w3.org/Graphics/Activity)
Philip Taylor concur
Andrew Sidwell no We really don't want to recharter now.
Matthew Raymond concur Explicit mention in the charter, while probably not technically necessary, may avoid endless debate about jurisdiction and authority. However, since most of the old hands seem against, including <canvas> supporters, I'll just do go with the majority on this one.
Marc Drumm no
Chris Wilson yes Actually, I'd prefer that an immediate mode graphics API be specified in a separate working group, because it would be a lot easier to have the appropriate people in that group. However, barring that I do believe quite strongly that our current charter does not cover immediate mode graphics apis.
Robert Marshall no
David Baron no
Gavin Sharp no
Michael[tm] Smith no Based on discussion with others on the team I don't think the HTML working-group charter necessarily needs to be modified before we can publish the FPWD of HTML5 with the immediate-mode graphics API included. Discussion can and will continue after we publish the FPWD, and I will make it a personal priority to help ensure that the working group moves towards consensus on this issue with all interested parties -- in particular, our membership and the WAI PF -- well before requesting transition of the spec to CR.

3. Are you interested to work on splitting the immediate mode graphics API out of the HTML 5 spec?

Some WG participants have argued that the canvas API is an odd fit for the HTML 5 specification; are you interested to work on splitting it out?

If so, please note your qualifications and availability in a comment. Would you like to edit it? Review it? Do you have general technical writing qualifications? Graphics API design experience?


ChoiceAll responders
yes 5
no 30

(1 response didn't contain an answer to this question)


Responder Are you interested to work on splitting the immediate mode graphics API out of the HTML 5 spec?Comments
Theresa O'Connor no I think <canvas> is an excellent example of the sort of thing that should be in HTML 5.
Geoffrey Sneddon no It requires a specific HTML element to interact with, and so shouldn't be moved outwith of the HTML spec.
Thomas Broyer no
James Cassell no
Bill Mason
Ian Hickson yes The actual 2D graphics context APIs probably should be split out on the long term, like many other parts of the spec. On the short term, if anyone actually is willing to edit this as a separate spec, there are much higher priority items that need splitting out and editing, and I would strongly recommend they work on that instead (like setTimeout and the Alternative Stylesheets OM). I would be very happy to work closely with people on doing such work. The WebAPI working group would also be a good forum for such work.

(Note though that even if we take out the 2D graphics context, the element still belongs in the HTML spec, as it's part of the language. So technically "<canvas>" still would be in the spec; just the graphics context API would be taken out. One could argue that that would lead to the spec being overly confusing to implementors, who generally prefer things in one place to implement them, as it leads to fewer "cracks between the specs".)
Scott Lewis no
Anne van Kesteren no I agree that it would make sense to split parts out of the HTML 5 specification, but so far I haven't seen much enthusiasm from people to take things over.

Also, if we find people it might make more sense to make them do some of the things the Web API WG is currently lacking resources for.
Alfonso Martínez de Lizarrondo no
Michael Puls II no
Daniel Schattenkirchner no
Shawn Medero no
Lachlan Hunt yes I don't mind if this does get split into a separate spec, though I would prefer it stayed where it is at the moment. But if it does we need a suitable editor for it. However, given that this section is fairly stable anyway, there really isn't too much to do with it.
James Graham no
Julian Reschke no
Arne Johannessen no
Dimitri Glazkov no I've been back and forth on fragmenting the spec. My current opinion is that due to the unique situation of the spec being born outside of W3C, the community around it and resources and experience of designated editors, the spec should not be fragmented.
Terry Morris no
Maciej Stachowiak no I tried to split out part of the HTML5 spec before, as the Window spec, and the work turned out to be much harder than anticipated.
David Dailey yes I am fairly fluent with SVG and know pretty well what <canvas> is supposed to do. If this work were split out, I'd be willing to help with review of such a document.
Marek Pawlowski no
Scott Vesey no
Sander van Lambalgen no
Mikko Honkala no It probably should be split out, since it is not HTML-specific. I am not personally interested in editing this.
Gregory Rosmaita no the CANVAS API is an odd fit for the HTML5 editor's draft because it doesn't belong in the HTML5 specification, but -- if split out of the HTML5 editors' draft, the canvas API should be submitted to the Graphics activity
Philip Taylor yes I wouldn't want to put much effort into this since I don't see much practical benefit; but if it does happen, I would be happy to help with reviewing.
Andrew Sidwell no I have no experience in it, but it seems that the canvas element could be safely split out into a separate specification if that would actually help someone.
Matthew Raymond no
Marc Drumm no
Chris Wilson yes I would get support for this from Microsoft resources, who would be qualified at the very least to review it. I would find an editor, but then the specification would have to be open to input.
Robert Marshall no
David Baron no
Gavin Sharp no
Michael[tm] Smith no I support the idea of potentially moving the canvas API out of the HTML5 spec if we get consensus about moving it out and to where it should be moved and if we have a qualified editor willing to commit to working on it and progressing it through to CR (e.g., dealing with public LC comments and incorporating changes based on them) and to Rec.

But I personally am not qualified to edit it (no graphics API design experience). For what it's worth, I would suggest that a good candidate for this particular editorial work would be implementor (e.g., a browser developer who has actually implemented support for the canvas API in a browser or is at least somewhat familiar with code for a particular implementation), if we could manage to recruit such a person.

4. Where should work on the immediate mode graphics API concentrate?

Among the W3C Activities are Graphics, with SVG and WebCGM working groups, as well as a Rich Web Client Activity with a WebAPI WG working on XMLHTTPRequest and such. We could migrate work on the canvas API to one of those groups or a new W3C working group.

We could also refine the organization of the HTML WG by making a new task force, drawn from this HTML WG and/or other WGs.

If you're interested in a leadership role in work on Canvas, please note your qualifications and availability. (If you are already visibly active in canvas development, this is perhaps unnecessary.)


ChoiceAll responders
12345No opinion
Keep using public-html@w3.org 4 1 3 1 23 4
Make a new task force within the HTML WG 12 6 8 1 1 8
Make a task force and invite participation from WGs in the Graphics and Rich Web Client activities. 8 8 5 3 4 8
charter a new W3C working group for the 2d graphics API 23 2 2 2 7


Choices All responders:
Keep using public-html@w3.org4.19
Make a new task force within the HTML WG2.04
Make a task force and invite participation from WGs in the Graphics and Rich Web Client activities.2.54
charter a new W3C working group for the 2d graphics API1.55


Responder Keep using public-html@w3.orgMake a new task force within the HTML WGMake a task force and invite participation from WGs in the Graphics and Rich Web Client activities.charter a new W3C working group for the 2d graphics APIRationaleComments
Theresa O'Connor 5 4 2 1
Geoffrey Sneddon 5 1 2 1
Thomas Broyer 3 No opinion No opinion 1
James Cassell No opinion No opinion No opinion No opinion
Bill Mason No opinion No opinion No opinion No opinion
Ian Hickson 5 1 1 1 Doing the work in the HTML WG will be by far the cheapest option in terms of time and effort. I don't see a good reason to split this out specifically. There are far more complex parts of the spec that would be a concern first if we were to split sections out (for example the repetition model section or the data templates section).Note that this part of the spec is highly mature, with multiple interoperable implementations already. There really isn't that much work to do here. We mostly just need to bring together links to the test suites.
Scott Lewis 5 3 4 1
Anne van Kesteren 5 1 1 1 This part of the specification is already pretty stable. Creating more overhead for it seems bad.
Alfonso Martínez de Lizarrondo No opinion No opinion No opinion No opinion
Michael Puls II 5 No opinion No opinion No opinion
Daniel Schattenkirchner 5 1 1 1
Shawn Medero 5 1 1 1
Lachlan Hunt 5 1 1 1 It's easier to keep it where it is.
James Graham 5 1 1 2 I see no pressing reason to reorganize the way in which the 2D graphics api is specified; since this part of the spec is already widely implemented, the scope for substantial change in the API seems limited so any reorganization of the specification work would be largely cosmetic. Artificially limiting the people working on the API by creating a taskforce seems counter-productive as it eliminates many of the advantages of being in an open working group. Setting up a new working group with the same open structure as the HTML-WG and similar design principles, enabling the 2D API spec to be published independently, has some theoretical advantages over the current approach such as enabling the API to be reused by other specifications more easily. However I have not yet seen any significant evidence that these benefits would exceed the cost in time and effort of setting up a new group to work on this spec.
Julian Reschke 1 2 5 2
Arne Johannessen 5 No opinion No opinion 1
Dimitri Glazkov 5 3 3 1
Terry Morris 1 2 5 4
Maciej Stachowiak 5 1 1 1 The <canvas> element is part of the HTML markup language. It would be inappropriate for a separate working group to define elements in HTML. The API itself also has dependencies on HTML-specific elements and interfaces.
David Dailey 2 3 5 4 The sheer amount of redundancy between <canvas> and SVG tells me a proper effort toward harmonization makes sense. SVG already exists as a W3C recommendation. <canvas> doesn't. It makes more sense for <canvas> to allow for some redesign at this stage before pandemonium occurs.
Marek Pawlowski 4 5 1 1
Scott Vesey No opinion No opinion No opinion No opinion
Sander van Lambalgen 5 1 2 1 <canvas> belongs here, and the people who care about it should already be here. A new TF/WG is likely to take a long time to get up to speed, and would further fragment the attention of the people working on it.
5 2 3 1
Mikko Honkala 3 2 5 1 The work could be done as a task force of HTML5 and graphics API specialists in W3C (SVG WG?)
Canvas is there -- it is clearly needed and already used. It has good set of implementations. W3C needs to standardize it and HTML5 WG plus some related working groups seems like the best group currently to do it.
3 No opinion 3 No opinion Seems like this would be a good fit for the WebAPI WG.
Gregory Rosmaita 1 1 2 5 the new W3C WG for a canvas API should be developed by and within the Graphics activity at W3Ci would have voted zero for the first 2 options offered if that choice had been available
Philip Taylor 5 1 2 1 There is not a great scope for working on the 2D API, since it is already widely implemented and any future changes will be fixing edge cases or small feature additions. Additional organisational overhead seems unlikely to be worthwhile.
Andrew Sidwell 5 3 2 1
Matthew Raymond 5 3 No opinion No opinion The task force for forms has largely been a bureaucratic disaster. Doing the same to <canvas> would grind standards work on it to a halt while providing no significant benefit for developers and giving Microsoft yet another excuse not to implement it.I would not oppose creating a new context for <canvas> that might be better designed and potentially more compatible with what is in other XML languages, but the existing "2d" context already has enough support to be standardized with little or no change.
Marc Drumm 5 3 4 1
Chris Wilson 1 2 3 5 1) Not having to change or expand the HTML WG charter, and 2)enabling close directed participation from those most qualified in graphics.
Robert Marshall 5 1 3 1
David Baron 5 3 2 1
Gavin Sharp 5 2 2 1
Michael[tm] Smith 5 3 4 1 I believe that for now it is best for discussion to take place on public-html with the whole working group, though I can imagine the discussion moving elsewhere (if and when the working group decides to move the canvas API to a separate spec). But there would be real value in finding ways to get active involvement and review of the current canvas API spec by graphics experts (e.g, those familiar with Open GL and Open GL ES and such), though perhaps we don't necessarily need to create a separate task force in order to help make that happen.

More details on responses


The following persons have not answered the questionnaire:

  1. Tantek Çelik <tantek@cs.stanford.edu>
  2. Patrick D F Ion <pion@umich.edu>
  3. Judy Brewer <jbrewer@w3.org>
  4. Liam Quin <liam@w3.org>
  5. Richard Ishida <ishida@w3.org>
  6. David Carlisle <davidc@nag.co.uk>
  7. James Helman <jhelman@movielabs.com>
  8. Jim Allan <jimallan@tsbvi.edu>
  9. Chris Marrin <cmarrin@apple.com>
  10. Charles McCathie Nevile <chaals@yandex.ru>
  11. Philippe Le Hégaret <plh@w3.org>
  12. Don Brutzman <brutzman@nps.edu>
  13. T.V. Raman <raman@google.com>
  14. David Singer <singer@apple.com>
  15. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  16. Karl Dubost <karl@la-grange.net>
  17. Wu Chou <wu.chou@huawei.com>
  18. Katsuhiko Momoi <momoi@google.com>
  19. Kangchan Lee <chan@w3.org>
  20. Roy Fielding <fielding@gbiv.com>
  21. Deborah Dahl <dahl@conversational-technologies.com>
  22. Michael Cooper <cooper@w3.org>
  23. Glenn Adams <glenn@skynav.com>
  24. Jonathan Jeon <hollobit@etri.re.kr>
  25. David Hyatt <hyatt@apple.com>
  26. WonSuk Lee <wonsuk.lee@etri.re.kr>
  27. Robert Accettura <robert@accettura.com>
  28. Jonathan Watt <jwatt@jwatt.org>
  29. Steve Faulkner <faulkner.steve@gmail.com>
  30. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  31. Patrick Lauke <redux@splintered.co.uk>
  32. David MacDonald <David100@sympatico.ca>
  33. Jack Jansen <jack@cwi.nl>
  34. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  35. Markku Hakkinen <mhakkinen@ets.org>
  36. Jens Oliver Meiert <jens@meiert.com>
  37. Kazuyuki Ashimura <ashimura@w3.org>
  38. Tomas Caspers <tomas@tomascaspers.de>
  39. Han Xu <collin@w3china.org>
  40. Sam Ruby <rubys@intertwingly.net>
  41. Mark Crawford <mark.crawford@sap.com>
  42. Preety Kumar <preety.kumar@deque.com>
  43. Ian Fette <ifette@google.com>
  44. Cameron McCormack <cam@mcc.id.au>
  45. Stefan Schnabel <stefan.schnabel@sap.com>
  46. Jirka Kosek <jirka@kosek.cz>
  47. Travis Leithead <Travis.Leithead@microsoft.com>
  48. Youngsun Ryu <ysryu@samsung.com>
  49. Sierk Bornemann <sierkb@gmail.com>
  50. Henri Sivonen <hsivonen@hsivonen.fi>
  51. Krijn Hoetmer <w3c@qontent.nl>
  52. Channy Yun <channy@gmail.com>
  53. Shane Thacker <shanethacker@gmail.com>
  54. Vilem Malek <murphy@malek.cz>
  55. Zhihong Mao <zhihong.mao@gmail.com>
  56. Benoit Piette <benoit.piette@gmail.com>
  57. Erik van Kempen <erikvankempen@gmail.com>
  58. Nick Fitzsimons <w3@nickfitz.co.uk>
  59. Josh Lawton <w3c@joshlawton.com>
  60. S Emerson <w3c@accretewebsolutions.ca>
  61. Justin Anthony Knapp <justinkoavf@gmail.com>
  62. Simon Myers <Smylers@stripey.com>
  63. Samuel Weinig <weinig@apple.com>
  64. Alexey Proskuryakov <ap@webkit.org>
  65. Alejandro Fernandez <alejandro@mediadvanced.com>
  66. Doug Jones <doug_b_jones@me.com>
  67. Danny Liang <danny.glue@gmail.com>
  68. Ron Reisor <ron@udel.edu>
  69. Craig Buckler <craigbuckler@gmail.com>
  70. Dale Hudjik <dale.hudjik@gmail.com>
  71. Joseph D'Andrea <jdandrea@gmail.com>
  72. Eric Carlson <eric.carlson@apple.com>
  73. Don Kiely <donkiely@computer.org>
  74. David Child <dave@addedbytes.com>
  75. Mark DuBois <Mark@webprofessionals.org>
  76. David Bills <w3@dfbills.com>
  77. Nik Thierry <me@thisemail.ca>
  78. Andrew Ramsden <andrew@irama.org>
  79. John Foliot <john.foliot@deque.com>
  80. Shefik Macauley <allknightaccess@gmail.com>
  81. Joe Steele <steele@adobe.com>
  82. John Vernaleo <john@netpurgatory.com>
  83. Jeremy Keith <jeremy@adactio.com>
  84. Jedi Lin <JediLin@Gmail.com>
  85. Jon Hughes <jon@phazm.com>
  86. Samuel Santos <samaxes@gmail.com>
  87. Dean Jackson <dino@apple.com>
  88. Mohammed DADAS <mohammed.dadas@orange.com>
  89. Sally Cain <sally.cain@rnib.org.uk>
  90. David Bolter <dbolter@mozilla.com>
  91. James Craig <jcraig@apple.com>
  92. Leonard Rosenthol <lrosenth@adobe.com>
  93. Jean-Pierre EVAIN <evain@ebu.ch>
  94. Mark Pilgrim <pilgrim@google.com>
  95. Matt Lee <mattl@cnuk.org>
  96. Magnus Olsson <magnus.olsson@ericsson.com>
  97. Chris Pearce <cpearce@mozilla.com>
  98. Mark Miller <erights@google.com>
  99. Andrew Wilson <atwilson@google.com>
  100. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  101. Ojan Vafai <ojan@chromium.org>
  102. Martin McEvoy <martin@weborganics.co.uk>
  103. Aryeh Gregor <ayg@aryeh.name>
  104. Anders Bondehagen <anders@bondehagen.com>
  105. Steven Pemberton <Steven.Pemberton@cwi.nl>
  106. Raul Hudea <rhudea@adobe.com>
  107. Raghavan Gurumurthy <raghavan@adobe.com>
  108. Mayank Kumar <mayankk@adobe.com>
  109. Dragos Georgita <dgeorgit@adobe.com>
  110. Christopher Bank <cbank@adobe.com>
  111. Ole Riesenberg <or@oleriesenberg.com>
  112. Takuya Oikawa <takuya@google.com>
  113. Jatinder Mann <jmann@microsoft.com>
  114. Robert Stern <rstern@gmail.com>
  115. Eihab Ibrahim <eihabibrahim@gmail.com>
  116. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  117. Jer Noble <jer.noble@apple.com>
  118. Masatomo Kobayashi <mstm@jp.ibm.com>
  119. Peter Beverloo <beverloo@google.com>
  120. Andrew Scherkus <scherkus@google.com>
  121. Greg Johnson <greg.johnson@gmail.com>
  122. Martijn Croonen <martijn@martijnc.be>
  123. Stanley Manoski <manoski@mitre.org>
  124. Mounir Lamouri <mlamouri@google.com>
  125. Tony Gentilcore <tonyg@google.com>
  126. Joseph Pecoraro <pecoraro@apple.com>
  127. Bob Lund <b.lund@cablelabs.com>
  128. Tatsuya Igarashi <Tatsuya.Igarashi@sony.com>
  129. John Simmons <johnsim@microsoft.com>
  130. Mark Watson <watsonm@netflix.com>
  131. Clarke Stevens <c.stevens@cablelabs.com>
  132. Mark Vickers <mark_vickers@comcast.com>
  133. Jeremy LaCivita <jeremy.lacivita@comcast.com>
  134. Denis Ah-Kang <denis@w3.org>
  135. Alvar Laigna <laigna@gmail.com>
  136. Kunio Ito <kunio.ito@mail.rakuten.com>
  137. David Mays <david_mays@comcast.com>
  138. Michael Chen <michael_chen@comcast.com>
  139. jongyoul Park <jongyoul@etri.re.kr>
  140. Reinaldo Ferraz <reinaldo@nic.br>
  141. Eva Lingyun Jing <jinglingyun@baidu.com>
  142. GANG LIANG <gang.liang@huawei.com>
  143. Ryosuke Niwa <rniwa@apple.com>
  144. Gian Luca Marroni <gmarroni@libero.it>
  145. Ian Devlin <ian@iandevlin.com>
  146. Xingrong Guo <guoxingrong@baidu.com>
  147. Jet Villegas <w3c@junglecode.net>
  148. Alexander Surkov <surkov.alexander@gmail.com>
  149. Hasan Savran <hsavran@kent.edu>
  150. Eric VonColln <eric.voncolln@navy.mil>
  151. Jungkee Song <jungkee.song@samsung.com>
  152. Rayi Lei <leiyi@baidu.com>
  153. David Dorwin <ddorwin@google.com>
  154. jiexuan gao <gaojiexuan@baidu.com>
  155. Xiaoqing Yang <yangxiaoqing@baidu.com>
  156. Aaron Colwell <acolwell@google.com>
  157. Alex Giladi <alex.giladi@huawei.com>
  158. Motomasa Futagami <Motomasa.Futagami@jp.sony.com>
  159. Kevin Streeter <kstreete@adobe.com>
  160. Christian Kaiser <kaiserc@google.com>
  161. Xuejian Li <lixuejian@baidu.com>
  162. Zuncheng Yang <yangzuncheng@baidu.com>
  163. Qianglong Zheng <zhengqianglong@baidu.com>
  164. Zhou Shen <shenzhou@baidu.com>
  165. Duoyi Wu <wuduoyi@baidu.com>
  166. Zheng Jia <jiazheng@baidu.com>
  167. Weifeng Feng <fengweifeng@baidu.com>
  168. Damin Hu <hudamin@baidu.com>
  169. Yang Liu <liuyang12@baidu.com>
  170. Zhixing Lei <leizhixing@baidu.com>
  171. Honggang Tang <tanghonggang@baidu.com>
  172. Kefeng Li <buaadallas@gmail.com>
  173. Xu Ma <maxu@baidu.com>
  174. Junzhong Liu <liujunzhong@baidu.com>
  175. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  176. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  177. Ami Fischman <fischman@google.com>
  178. Arnaud Braud <arnaud.braud@orange.com>
  179. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  180. Bram Tullemans <tullemans@ebu.ch>
  181. Petr Peterka <ppeterka@verimatrix.com>
  182. lei wang <wanglei03@baidu.com>
  183. Milan Patel <Milan.Patel@huawei.com>
  184. Yiling Gu <guyiling@baidu.com>
  185. Zefa Xiong <xiongzefa@baidu.com>
  186. shanglin chen <chenshanglin@baidu.com>
  187. Ping Wu <wuping02@baidu.com>
  188. Bin Chen <chenbin01@baidu.com>
  189. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  190. Patrick Ladd <Pat_Ladd2@comcast.com>
  191. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  192. Hao Jing <jh.jinghao@huawei.com>
  193. Glenn Deen <glenn.deen@nbcuni.com>
  194. Lei Wang <wanglei@baidu.com>
  195. Tom Handal <thandal@verimatrix.com>
  196. Pengcheng Guo <guopengcheng@baidu.com>
  197. Tom Wiltzius <wiltzius@google.com>
  198. Pierre-Anthony Lemieux <pal@sandflow.com>
  199. Xie Jianhui <xiejianhui@baidu.com>
  200. Yujie Jiang <jiangyujie@baidu.com>
  201. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  202. Brady Eidson <beidson@apple.com>
  203. Jerry Smith <jdsmith@microsoft.com>
  204. Michael Thornburgh <mthornbu@adobe.com>
  205. Mick Hakobyan <mhakobyan@netflix.com>
  206. Vladimir Sinelnikov <sinelnikov@gmail.com>
  207. Chris Wong <huanghoujin@baidu.com>
  208. Yiliang LIU <liuyiliang@baidu.com>
  209. mingqiang zhang <imcnan@gmail.com>
  210. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  211. Grzegorz Babula <gbabula@gmail.com>
  212. Brian Kardell <hitchjs@gmail.com>
  213. xueliang fan <fanxueliang@baidu.com>
  214. Niels Thorwirth <nthorwirth@verimatrix.com>
  215. David Evans <david.evans@rd.bbc.co.uk>
  216. Joseph Karr O'Connor <josephoconnor@mac.com>
  217. Yusuke Kagiwada <block.rxckin.beats@gmail.com>
  218. smallni ding <smallniding@tencent.com>
  219. Jim Walsh <jim@jwalshcreative.com>
  220. Greg Davis <greg.davis@pearson.com>
  221. Gabino Alonso <gabinovincent@gmail.com>
  222. Sam Langdon <sam.langdon@hachette.co.uk>
  223. Michael Kelly <mkelly@mozilla.com>
  224. Xiaoqian Wu <xiaoqian@w3.org>
  225. Yue Min <minyue@baidu.com>
  226. Min Li <limin04@baidu.com>
  227. Joanmarie Diggs <jdiggs@igalia.com>
  228. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  229. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  230. So Vang <svang@nab.org>
  231. Nathalia Sautchuk Patrício <nathalia@nic.br>
  232. Vicente García Díaz <vicegd@live.com>
  233. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  234. Yusuke Yokosuka <Yokosuka.Yusuke@bx.MitsubishiElectric.co.jp>
  235. John Riviello <john_riviello@comcast.com>
  236. yaolong wang <wangyaolong@baidu.com>
  237. Tao Liang <liangtao01@baidu.com>
  238. Glenn Eguchi <geguchi@adobe.com>
  239. Lukáš Čihák <lukas.cihak@mensa.cz>
  240. WOOGLAE KIM <wlkim@inswave.com>
  241. Min Ren <minren@tencent.com>
  242. Rustam Khashimkhodjaev <Rustam_Khashimkhodjaev@comcast.com>
  243. Jason White <jjwhite@ets.org>
  244. Hyejin Lee <hjlee@html5forum.or.kr>
  245. Richard Grzeczkowski <richard_grzeczkowski@comcast.com>
  246. qigang huang <qiganghuang@tencent.com>
  247. Pascal Perrot <pascal.perrot@orange.com>
  248. Dapeng Liu <max.ldp@alibaba-inc.com>
  249. Matthew Wolenetz <wolenetz@google.com>
  250. Cory Heslip <cory_heslip@comcast.com>
  251. Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  252. Seiji Okumura <Okumura.Seiji@bc.MitsubishiElectric.co.jp>
  253. Eiji Yamamoto <Yamamoto.Eiji@db.MitsubishiElectric.co.jp>
  254. Ali C. Begen <ali_begen@comcast.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.135 2017/06/02 08:50:36 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)