w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
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:
- Canvas and immediate mode graphics API introductory/tutorial note
- Should the HTML WG charter be modified to more explicitly include canvas and immediate mode graphics?
- Are you interested to work on splitting the immediate mode graphics API out of the HTML 5 spec?
- 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.
Summary
| Choice | All responders |
|---|---|
| Results | |
| 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)
Details
| Responder | Canvas and immediate mode graphics API introductory/tutorial note | Rationale | Comments |
|---|---|---|---|
| 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. | ||
| Sam 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 found | I 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. | |
| Justin Thorp | 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). | |
| Adam Roben | 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 (sideshowbarker) | 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.
Summary
| Choice | All responders |
|---|---|
| Results | |
| yes | 2 |
| no | 29 |
| concur | 5 |
| abstain |
Details
| Responder | Should the HTML WG charter be modified to more explicitly include canvas and immediate mode graphics? | Rationale | Comments |
|---|---|---|---|
| Theresa O'Connor | no | Rechartering should be avoided if at all possible. | |
| Sam 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 | ||
| Justin Thorp | 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. | |
| Adam Roben | no | ||
| 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 (sideshowbarker) | 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?
Summary
| Choice | All responders |
|---|---|
| Results | |
| yes | 5 |
| no | 30 |
(1 response didn't contain an answer to this question)
Details
| 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. |
| Sam 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 | |
| Justin Thorp | no | |
| Mikko Honkala | no | It probably should be split out, since it is not HTML-specific. I am not personally interested in editing this. |
| Adam Roben | no | |
| 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 (sideshowbarker) | 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.)
Summary
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No 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 | |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| Keep using public-html@w3.org | 4.19 |
| Make a new task force within the HTML WG | 2.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 API | 1.55 |
Details
| Responder | Keep using public-html@w3.org | Make a new task force within the HTML WG | Make 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 API | Rationale | Comments |
|---|---|---|---|---|---|---|
| Theresa O'Connor | 5 | 4 | 2 | 1 | ||
| Sam 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. | |
| Justin Thorp | 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. | |
| Adam Roben | 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 W3C | i 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 (sideshowbarker) | 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
- Theresa O'Connor: last responded on 16, November 2007 at 22:09 (UTC)
- Sam Sneddon: last responded on 16, November 2007 at 23:11 (UTC)
- Thomas Broyer: last responded on 16, November 2007 at 23:30 (UTC)
- James Cassell: last responded on 17, November 2007 at 01:56 (UTC)
- Bill Mason: last responded on 17, November 2007 at 04:29 (UTC)
- Ian Hickson: last responded on 17, November 2007 at 05:19 (UTC)
- Scott Lewis: last responded on 17, November 2007 at 09:51 (UTC)
- Anne van Kesteren: last responded on 17, November 2007 at 10:32 (UTC)
- Alfonso Martínez de Lizarrondo: last responded on 17, November 2007 at 10:53 (UTC)
- Michael Puls II: last responded on 17, November 2007 at 11:04 (UTC)
- Daniel Schattenkirchner: last responded on 17, November 2007 at 13:11 (UTC)
- Shawn Medero: last responded on 17, November 2007 at 16:44 (UTC)
- Lachlan Hunt: last responded on 17, November 2007 at 18:57 (UTC)
- James Graham: last responded on 17, November 2007 at 23:13 (UTC)
- Julian Reschke: last responded on 18, November 2007 at 19:11 (UTC)
- Arne Johannessen: last responded on 18, November 2007 at 20:25 (UTC)
- Dimitri Glazkov: last responded on 19, November 2007 at 00:10 (UTC)
- Terry Morris: last responded on 19, November 2007 at 00:20 (UTC)
- Maciej Stachowiak: last responded on 19, November 2007 at 00:53 (UTC)
- David Dailey: last responded on 19, November 2007 at 14:16 (UTC)
- Marek Pawlowski: last responded on 19, November 2007 at 14:22 (UTC)
- Scott Vesey: last responded on 19, November 2007 at 17:01 (UTC)
- Sander van Lambalgen: last responded on 19, November 2007 at 17:24 (UTC)
- Justin Thorp: last responded on 19, November 2007 at 17:32 (UTC)
- Mikko Honkala: last responded on 20, November 2007 at 16:37 (UTC)
- Adam Roben: last responded on 20, November 2007 at 21:42 (UTC)
- Gregory Rosmaita: last responded on 21, November 2007 at 17:59 (UTC)
- Philip Taylor: last responded on 21, November 2007 at 18:04 (UTC)
- Andrew Sidwell: last responded on 22, November 2007 at 19:49 (UTC)
- Matthew Raymond: last responded on 23, November 2007 at 15:15 (UTC)
- Marc Drumm: last responded on 26, November 2007 at 19:09 (UTC)
- Chris Wilson: last responded on 27, November 2007 at 22:20 (UTC)
- Robert Marshall: last responded on 28, November 2007 at 19:27 (UTC)
- David Baron: last responded on 28, November 2007 at 19:54 (UTC)
- Gavin Sharp: last responded on 28, November 2007 at 20:20 (UTC)
- Michael[tm] Smith (sideshowbarker): last responded on 29, November 2007 at 07:01 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project