w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire Accept requirement for immediate mode graphics a la canvas element?
The results of this questionnaire are available to anybody.
This questionnaire was open from 2007-11-16 to 2007-11-29.
62 answers have been received.
Jump to results for question:
1. Accept requirement for immediate mode graphics a la canvas element?
Do use cases such as games, shared whiteboards, and yahoo pipes and others in the ESW wiki motivate a requirement that HTML 5 provide an immediate mode graphics API and canvas element?
This is a proposal to close ISSUE-15 immediate-mode-graphics.
Possible impact on the charter has been moved to a separate survey.
Summary
| Choice | All responders |
|---|---|
| Results | |
| yes | 40 |
| no | 10 |
| concur | 7 |
| abstain | 3 |
(2 responses didn't contain an answer to this question)
Details
| Responder | Accept requirement for immediate mode graphics a la canvas element? | Rationale | Comments |
|---|---|---|---|
| University of Innsbruck DUPLICATE (Alexander Graf) | yes | Canvas is already used in many browser implementations. Specifying the exact behaviour should benefit everyone. | |
| Cisco (Michael Whitley) | concur | ||
| Google LLC (Ian Hickson) | yes | Yes, of course. It's part of any modern UI widget API. | |
| Opera Software AS (Anne van Kesteren) | yes | Immediate mode graphics are part of most (if not all, dunno) application platforms. | |
| Mitsue-Links Co., Ltd. (Kazuhito Kidachi) | concur | ||
| Apple Inc. (Maciej Stachowiak) | yes | Immediate mode graphics drawing areas are a standard part of almost every application UI toolkit. To provide complete support for web applications, HTML5 needs to include such a feature. Also, <canvas> is already supported by Firefox, Opera and Safari, making it probably the most successful new feature in HTML5. | |
| Boeing Company (Scott Vesey) | concur | ||
| Nokia Corporation (Mikko Honkala) | yes | The main rationale behind HTML5 is Rich Web Applications, and vector graphics play a major role in this application scope. My only major concern about the canvas solution to this requirement is performance in mobile platforms. The main reason is using ECMAScript in the drawing loop. Hopefully the next version ECMAScript will enable better performing implementations (although the API should be checked wheather it can be typed). On the other hand, SVG has not been proven to perform any better in real world applications. | |
| Library of Congress (Justin Thorp) | yes | ||
| IBM Corporation (Sam Ruby) | no | an immediate mode graphics API and canvas element would clearly be a good thing; my only issue is the scope question, which the separate survey doesn't adequately address in my opinion. Please treat this answer as if it were "yes, but only if the charter was modified first". | |
| Invited Experts with Member Access | |||
| ACCESS Co., Ltd. DUPLICATE (Marcin Hanclik) | yes | ||
| AOL LLC (Kevin Lawver) | yes | ||
| Microsoft Corporation (Chris Wilson) | no | Although the idea of a standardized immediate mode graphics api is a good one, I have two objections - first, that I believe this requirement is not captured within the current HTML5 charter, as it is not a semantic API; secondly, that HTML5 already must cover a lot of ground, and graphics are a very specialized field. It would be radically better to have different group of people representing the expertise in this field, and those people are not all interested in the rest of HTML5. | |
| Mozilla Foundation (David Baron) | yes | ||
| W3C Invited Experts | |||
| W3C/Keio (Michael[tm] Smith (sideshowbarker)) | yes | See URL in Comments. | http://lists.w3.org/Archives/Public/public-html/2007Nov/0449.html |
| Thomas Broyer (Thomas Broyer) | yes | It's already there and won't be removed from UAs already implementing it. | I'm already using it for graphs (with ExplorerCanvas for Internet Explorer compatibility,doing VML behind the scene). I don't know VML enough but I think it could be used as a "compat' replacement" for SVG too... ...but the canvas' API is far easier to use than playing with SVG elements (and could be implemented with SVG behind the scene if needed) |
| Maurice Carey (Maurice Carey) | yes | If some of the canvas examples given are truly impossible or extremely difficult to implement with svg then I guess canvass is needed. I still think the ability to use .svg files with <img> and css backgrounds is more important than canvas at the moment. | |
| James Cassell (James Cassell) | no | ||
| Sander van Lambalgen (Sander van Lambalgen) | yes | ||
| Jon Barnett (Jon Barnett) | yes | Bitmap editing mas many use cases beyond trivial ones. The simple task of getting a digital image from a camera to the web by cropping, transforming and rotating the image is non-trivial for novices today and should be an easier task. Currently, sites like Flickr require a lot of server-side processing of an image. Moving that processing to the client will make the task much easier for smaller web sites. | |
| Patrick Taylor (Patrick Taylor) | yes | ||
| Michael Puls II (Michael Puls II) | yes | There's already content out there and UAs already support it. The spec should support existing content. Games alone are a sufficient reason for supporting Canvas, but it's generally useful for graphics also. For native game solutions in web pages, canvas has the potential to be a better solution than JS alone. We should make sure it's fully standardized so all implementations can be aligned properly to provide a better experience. It's also important to have the canvas element specifically. For one, it's already implemented that way and degrades nicely. That means we should support it that way and should not overload any existing element. If there are any issues with canvas, it can be fixed. No need to throw away a good thing. | |
| Arne Johannessen (Arne Johannessen) | yes | ||
| Danny Liang (Danny Liang) | no | ||
| Philip TAYLOR (Philip TAYLOR) | no | The question conflates two distinct issues : (1) Should HTML 5 provide an immediate-mode graphics API; and (2) if so, should this be implemented using a <canvas> element. I am willing to be convinced that there is a case for (1), but the case for (2) remains unproven. | Future questions should avoid conflating distinct issues. |
| Robert Marshall (Robert Marshall) | yes | ||
| Stephen Axthelm (Stephen Axthelm) | yes | ||
| Andrew Duck (Andrew Duck) | yes | ||
| John Vernaleo (John Vernaleo) | yes | ||
| Philip Taylor (Philip Taylor) | yes | ||
| Marek Pawlowski (Marek Pawlowski) | yes | Time has passed and HTML is no longer for "pure" hypertext. If HTML5 is to provide means for developers to build real web apps (which can compete with Flash/Silverlight) canvas is a must. | |
| Scott Lewis (Scott Lewis) | yes | ||
| Brendan Cullen (Brendan Cullen) | yes | ||
| Thomas Bradley (Thomas Bradley) | yes | ||
| Mark DuBois (Mark DuBois) | no | ||
| Lee Kowalkowski (Lee Kowalkowski) | yes | Although I think it would be better to have a canvas attribute on the img element instead (or also), to provide a simple fallback for authors. | |
| Terry Morris (Terry Morris) | concur | ||
| Jason Lefkowitz (Jason Lefkowitz) | no | ||
| Theresa O'Connor (Theresa O'Connor) | yes | Canvas is already deployed in several major browsers; its behavior should be specified for the purpose of interoperability. | |
| Sam Sneddon | yes | We should define existing browser treatment of HTML elements and DOM that interacts specifically with them. There is also no reason not to make the <canvas> element conforming, as far as I can see. | |
| Shawn Medero (Shawn Medero) | yes | ||
| Alex Robinson (Alex Robinson) | yes | ||
| David Håsäther (David Håsäther) | yes | ||
| Ryan King (Ryan King) | yes | An open specification (as opposed to proprietary ones, like Flash and Silverlight) for graphics is vital for interoperability. | |
| James Graham (James Graham) | yes | Immediate mode graphics are a common feature of GUI toolkits and there is no reason to artificially exclude this capability from HTML, especially given that a highly-interoperable mechanism for providing this functionality is already implemented and seeing use in real applications. | |
| Julian Reschke (Julian Reschke) | concur | Some of them, but then, the wiki page isn't the charter. So I'm favor of everything that makes HTML5 itself smaller -- it should be easy to move canvas into a separate spec (if it turns out not to be easy that's a bad sign in itself). | |
| Jens Oliver Meiert (Jens Oliver Meiert) | no | Cons have been stronger so far, especially the “questioned need” and “potential solution” arguments. | |
| Steve Faulkner (Steve Faulkner) | abstain | ||
| Krijn Hoetmer (Krijn Hoetmer) | yes | ||
| Bill Mason (Bill Mason) | abstain | ||
| Daniel Schattenkirchner (Daniel Schattenkirchner) | concur | ||
| Shunsuke Kurumatani (Shunsuke Kurumatani) | yes | ||
| Jens Bannmann (Jens Bannmann) | yes | Without the canvas element, there will be no significant advance in graphics interaction on the web. | |
| satish sangaru (satish sangaru) | no | The API is going to be a big deal if we want developers to create any meaningful games or whiteboard applications. It needs to be thought through well. | |
| David Dailey (David Dailey) | concur | The language of the survey is a bit strong: "motivate a requirement" -- probably not. I have considerable ambivalence about <canvas> as I have noted previously. If we were designing HTML 5 from the ground up , SVG and canvas ought to share syntax and ought not to duplicate so much functionality. <canvas> brings a few needed things with it, though it seems rather a bit of poor planning on the part of the advocates of <canvas> that has gotten us to this point. Those historically frustrated with W3C chose to ignore SVG and now seem to want W3C to ignore SVG in favor of a lesser technology. At the same time, <canvas> does enable client-side image analysis by giving the developer access to pixel values, and that alone allows for some tolerance of what otherwise seems to be a curious decoupling of reason from politics. Does it re-invent the wheel? -- only about 95% of it is redundant with 20% of SVG. May we sanction this departure from our Design Principles? I suppose it is a moot point. | |
| Matthew Raymond (Matthew Raymond) | yes | Memory concerns, performance considerations and the need for programmable effects will naturally lend themselves to an immediate-mode graphics API. The idea that SVG and <canvas> are competing technologies is in the large a fallacy, and only true in a specific, limited set of use cases. What's more is that there are existing implementations on all major browsers, with IE having the only non-native implementation. | There is no evidence to support that SVG will be displaced by <canvas>. Opera, Mozilla and Apple all support _BOTH_ SVG and <canvas> natively, while IE currently supports neither natively. In fact, I can see cases for both using immediate-mode graphics inside SVG and rendering SVG to a graphics buffer and manipulating it using an immediate-mode API. Semantics is a red herring, because this assumes the image created using <canvas> is presentational in nature. This is no more the case with <canvas> than it is with <img>. Furthermore, formats like APNG and the complexity of using <canvas> for presentational purposes will discourage much of the frivolous use that we see with <img> today. The idea that the API is out of scope is weak, given the fact "UI widgets" and "Editing APIs and user-driven WYSIWYG editing features" are already within scope per the charter. At best, you could argue that the API should be JOINTLY developed with another group, but since there are already at least four existing implementations "in the wild" with few compatibility issues between them, such an arrangement would largely be an exercise in bureaucracy. What's more, for compatibility, we can always just keep the existing <canvas> "2d" context as-is and create a "w3c-2d" context at a later date. |
| Alfonso Martínez de Lizarrondo (Alfonso Martínez de Lizarrondo) | yes | Yes, it provides an API easy to use that allows to bring new features to the web. | |
| Laura Carlson (Laura Carlson) | abstain | ||
| Dimitri Glazkov (Dimitri Glazkov) | yes | The need for this functionality is already evident from the multiple graphic toolkits for JS, as well as Java Applets and Flash movies being used as a surrogate replacement. | |
| Gregory Rosmaita (Gregory Rosmaita) | no | CANVAS is incapable of providing semantics, while with SVG, one can apply semantic relationships. | aside from my concerns about the accessibility of CANVAS and my questions as to whether CANVAS is being forced upon users by developers loathe to provide the same functionality using an extant, proven, standardized and accessible graphical markup mechanism such as SVG, i do not believe that it falls under the HTML WG's charter to define immediate mode graphics and CANVAS -- this is properly the domain of the W3C's graphics activity |
More details on responses
- University of Innsbruck DUPLICATE: last responded on 16, November 2007 at 16:43 (UTC)
- Cisco: last responded on 16, November 2007 at 16:53 (UTC)
- Google LLC: last responded on 17, November 2007 at 03:07 (UTC)
- Opera Software AS: last responded on 17, November 2007 at 10:21 (UTC)
- Mitsue-Links Co., Ltd.: last responded on 19, November 2007 at 02:25 (UTC)
- Apple Inc.: last responded on 19, November 2007 at 07:11 (UTC)
- Boeing Company: last responded on 19, November 2007 at 16:53 (UTC)
- Nokia Corporation: last responded on 20, November 2007 at 16:16 (UTC)
- Library of Congress: last responded on 21, November 2007 at 16:09 (UTC)
- IBM Corporation: last responded on 21, November 2007 at 17:14 (UTC)
- Invited Experts with Member Access: last responded on 21, November 2007 at 17:45 (UTC)
- ACCESS Co., Ltd. DUPLICATE: last responded on 22, November 2007 at 13:24 (UTC)
- AOL LLC: last responded on 24, November 2007 at 01:49 (UTC)
- Microsoft Corporation: last responded on 27, November 2007 at 21:35 (UTC)
- Mozilla Foundation: last responded on 28, November 2007 at 19:46 (UTC)
- W3C Invited Experts: last responded on 29, November 2007 at 14:59 (UTC)
- W3C/Keio: last responded on 30, November 2007 at 09:21 (UTC)
- Thomas Broyer: last responded on 18, May 2009 at 13:21 (UTC)
- Maurice Carey: last responded on 18, May 2009 at 13:21 (UTC)
- James Cassell: last responded on 18, May 2009 at 13:21 (UTC)
- Sander van Lambalgen: last responded on 18, May 2009 at 13:21 (UTC)
- Jon Barnett: last responded on 18, May 2009 at 13:21 (UTC)
- Patrick Taylor: last responded on 18, May 2009 at 13:21 (UTC)
- Michael Puls II: last responded on 18, May 2009 at 13:21 (UTC)
- Arne Johannessen: last responded on 18, May 2009 at 13:21 (UTC)
- Danny Liang: last responded on 18, May 2009 at 13:21 (UTC)
- Philip TAYLOR: last responded on 18, May 2009 at 13:21 (UTC)
- Robert Marshall: last responded on 18, May 2009 at 13:21 (UTC)
- Stephen Axthelm: last responded on 18, May 2009 at 13:21 (UTC)
- Andrew Duck: last responded on 18, May 2009 at 13:21 (UTC)
- John Vernaleo: last responded on 18, May 2009 at 13:21 (UTC)
- Philip Taylor: last responded on 18, May 2009 at 13:21 (UTC)
- Marek Pawlowski: last responded on 18, May 2009 at 13:21 (UTC)
- Scott Lewis: last responded on 18, May 2009 at 13:21 (UTC)
- Brendan Cullen: last responded on 18, May 2009 at 13:21 (UTC)
- Thomas Bradley: last responded on 18, May 2009 at 13:21 (UTC)
- Mark DuBois: last responded on 18, May 2009 at 13:21 (UTC)
- Lee Kowalkowski: last responded on 18, May 2009 at 13:21 (UTC)
- Terry Morris: last responded on 18, May 2009 at 13:21 (UTC)
- Jason Lefkowitz: last responded on 18, May 2009 at 13:21 (UTC)
- Theresa O'Connor: last responded on 18, May 2009 at 13:21 (UTC)
- Sam Sneddon: last responded on 18, May 2009 at 13:21 (UTC)
- Shawn Medero: last responded on 18, May 2009 at 13:21 (UTC)
- Alex Robinson: last responded on 18, May 2009 at 13:21 (UTC)
- David Håsäther: last responded on 18, May 2009 at 13:21 (UTC)
- Ryan King: last responded on 18, May 2009 at 13:21 (UTC)
- James Graham: last responded on 18, May 2009 at 13:21 (UTC)
- Julian Reschke: last responded on 18, May 2009 at 13:21 (UTC)
- Jens Oliver Meiert: last responded on 18, May 2009 at 13:21 (UTC)
- Steve Faulkner: last responded on 18, May 2009 at 13:21 (UTC)
- Krijn Hoetmer: last responded on 18, May 2009 at 13:21 (UTC)
- Bill Mason: last responded on 18, May 2009 at 13:21 (UTC)
- Daniel Schattenkirchner: last responded on 18, May 2009 at 13:21 (UTC)
- Shunsuke Kurumatani: last responded on 18, May 2009 at 13:21 (UTC)
- Jens Bannmann: last responded on 18, May 2009 at 13:21 (UTC)
- satish sangaru: last responded on 18, May 2009 at 13:21 (UTC)
- David Dailey: last responded on 18, May 2009 at 13:21 (UTC)
- Matthew Raymond: last responded on 18, May 2009 at 13:21 (UTC)
- Alfonso Martínez de Lizarrondo: last responded on 18, May 2009 at 13:21 (UTC)
- Laura Carlson: last responded on 18, May 2009 at 13:21 (UTC)
- Dimitri Glazkov: last responded on 18, May 2009 at 13:21 (UTC)
- Gregory Rosmaita: last responded on 18, May 2009 at 13:21 (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