The results of this questionnaire are available to anybody.
This questionnaire was open from 2007-11-16 to 2007-11-29.
60 answers have been received.
Jump to results for question:
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.
| Choice | All responders |
|---|---|
| Results | |
| yes | 40 |
| no | 10 |
| concur | 7 |
| abstain | 3 |
| Responder | Accept requirement for immediate mode graphics a la canvas element? | Rationale | Comments |
|---|---|---|---|
| Mark DuBois (Mark DuBois) | no | ||
| John Vernaleo (John Vernaleo) | yes | ||
| Edward O'Connor (Edward O'Connor) | yes | Canvas is already deployed in several major browsers; its behavior should be specified for the purpose of interoperability. | |
| 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. | |
| University of Innsbruck (Alexander Graf) | yes | Canvas is already used in many browser implementations. Specifying the exact behaviour should benefit everyone. | |
| David Håsäther (David Håsäther) | yes | ||
| 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. | |
| Cisco Systems (Michael Whitley) | concur | ||
| 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. |
| Shawn Medero (Shawn Medero) | yes | ||
| Jens Meiert (Jens Meiert) | no | Cons have been stronger so far, especially the “questioned need” and “potential solution” arguments. | |
| 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) |
| Jens Bannmann (Jens Bannmann) | yes | Without the canvas element, there will be no significant advance in graphics interaction on the web. | |
| 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. | |
| Google, Inc. (Ian Hickson) | yes | Yes, of course. It's part of any modern UI widget API. | |
| 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. | |
| Ryan King (Ryan King) | yes | An open specification (as opposed to proprietary ones, like Flash and Silverlight) for graphics is vital for interoperability. | |
| Geoffrey 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. | |
| Arne Johannessen (Arne Johannessen) | yes | ||
| James Cassell (James Cassell) | no | ||
| Thomas Bradley (Thomas Bradley) | yes | ||
| Bill Mason (Bill Mason) | abstain | ||
| Andrew Duck (Andrew Duck) | yes | ||
| Scott Lewis (Scott Lewis) | yes | ||
| Opera Software (Anne van Kesteren) | yes | Immediate mode graphics are part of most (if not all, dunno) application platforms. | |
| 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. | |
| Danny Liang (Danny Liang) | no | ||
| Daniel Schattenkirchner (Daniel Schattenkirchner) | concur | ||
| Stephen Axthelm (Stephen Axthelm) | 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. | |
| Philip Taylor (Philip Taylor) | yes | ||
| 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. | |
| 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. | |
| Terry Morris (Terry Morris) | concur | ||
| Brendan Cullen (Brendan Cullen) | yes | ||
| Mitsue-Links Co., Ltd. (Kazuhito Kidachi) | concur | ||
| Steve Faulkner (Steve Faulkner) | abstain | ||
| 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. | |
| Laura Carlson (Laura Carlson) | abstain | ||
| 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. | |
| 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. | |
| Boeing Company (Scott Vesey) | concur | ||
| Sander van Lambalgen (Sander van Lambalgen) | yes | ||
| Shunsuke Kurumatani (Shunsuke Kurumatani) | yes | ||
| 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". | |
| 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 |
| W3C/Keio (Michael(tm) Smith) | yes | See URL in Comments. | http://lists.w3.org/Archives/Public/public-html/2007Nov/0449.html |
| 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). | |
| ACCESS Co., Ltd. (Marcin Hanclik) | yes | ||
| Patrick Taylor (Patrick Taylor) | yes | ||
| 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. |
| AOL LLC (Kevin Lawver) | yes | ||
| Alex Robinson (Alex Robinson) | yes | ||
| Krijn Hoetmer (Krijn Hoetmer) | yes | ||
| Microsoft Corp. (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. | |
| Jason Lefkowitz (Jason Lefkowitz) | no | ||
| Robert Marshall (Robert Marshall) | yes | ||
| Mozilla Foundation (David Baron) | yes |
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire