W3C WBS Home

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?

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.


ChoiceAll responders
yes 40
no 10
concur 7
abstain 3

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


Responder Accept requirement for immediate mode graphics a la canvas element?RationaleComments
University of Innsbruck DUPLICATE (Alexander Graf <alexander.graf@sti2.at>) yes Canvas is already used in many browser implementations. Specifying the exact behaviour should benefit everyone.
Cisco Systems (Michael Whitley <miwhitle@cisco.com>) concur
Google, Inc. (Ian Hickson <ian@hixie.ch>) yes Yes, of course. It's part of any modern UI widget API.
Opera Software (Anne van Kesteren <annevk@annevk.nl>) yes Immediate mode graphics are part of most (if not all, dunno) application platforms.
Mitsue-Links Co., Ltd. (Kazuhito Kidachi <k-kidachi@mitsue.co.jp>) concur
Apple, Inc. (Maciej Stachowiak <mjs@apple.com>) 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 <scott.r.vesey@boeing.com>) concur
Nokia Corporation (Mikko Honkala <mikko.honkala@nokia.com>) 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 <jthorp@gmail.com>) yes
IBM Corporation (Sam Ruby <rubys@intertwingly.net>) 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".
W3C Invited Experts
ACCESS Co., Ltd. DUPLICATE (Marcin Hanclik <marcin.hanclik@access-company.com>) yes
AOL LLC (Kevin Lawver <kevin.lawver@corp.aol.com>) yes
Microsoft Corp. (Chris Wilson <cwilso@google.com>) 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 <dbaron@dbaron.org>) yes
Invited Experts without Member Access
W3C/Keio (Michael[tm] Smith <mike@w3.org>) yes See URL in Comments.http://lists.w3.org/Archives/Public/public-html/2007Nov/0449.html
Thomas Broyer (Thomas Broyer <t.broyer@ltgt.net>) 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 <maurice@thymeonline.com>) 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 <w3c@cyberpear.com>) no
Sander van Lambalgen (Sander van Lambalgen <w3c@have-skill.com>) yes
Jon Barnett (Jon Barnett <jonbarnett@gmail.com>) 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 <patrick@healtheconomics.org>) yes
Michael Puls II (Michael Puls II <shadow2531@gmail.com>) 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 <arne@thaw.de>) yes
Danny Liang (Danny Liang <danny.glue@gmail.com>) no
Philip TAYLOR (Philip TAYLOR <P.Taylor@Rhul.Ac.Uk>) 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 <rdm@rdmsoft.com>) yes
Stephen Axthelm (Stephen Axthelm <steveax@pobox.com>) yes
Andrew Duck (Andrew Duck <andrew.duck@quiqcorp.com>) yes
John Vernaleo (John Vernaleo <john@netpurgatory.com>) yes
Philip Taylor (Philip Taylor <excors@gmail.com>) yes
Marek Pawlowski (Marek Pawlowski <marekp.w3c@gmail.com>) 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 <scotfl@gmail.com>) yes
Brendan Cullen (Brendan Cullen <brendan@brendancullen.com>) yes
Thomas Bradley (Thomas Bradley <thomasjbradley@gmail.com>) yes
Mark DuBois (Mark DuBois <Mark@webprofessionals.org>) no
Lee Kowalkowski (Lee Kowalkowski <Lee.Kowalkowski@googlemail.com>) 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 <MorrisW3C@gmail.com>) concur
Jason Lefkowitz (Jason Lefkowitz <jason@jasonlefkowitz.net>) no
Edward O'Connor (Edward O'Connor <eoconnor@apple.com>) yes Canvas is already deployed in several major browsers; its behavior should be specified for the purpose of 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.
Shawn Medero (Shawn Medero <smedero@uw.edu>) yes
Alex Robinson (Alex Robinson <w3c@alex.fu2k.org>) yes
David Håsäther (David Håsäther <hasather@gmail.com>) yes
Ryan King (Ryan King <ryan@theryanking.com>) yes An open specification (as opposed to proprietary ones, like Flash and Silverlight) for graphics is vital for interoperability.
James Graham (James Graham <james@hoppipolla.co.uk>) 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 <julian.reschke@gmx.de>) 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 Meiert (Jens Meiert <jens@meiert.com>) no Cons have been stronger so far, especially the “questioned need” and “potential solution” arguments.
Steve Faulkner (Steve Faulkner <faulkner.steve@gmail.com>) abstain
Krijn Hoetmer (Krijn Hoetmer <w3c@qontent.nl>) yes
Bill Mason (Bill Mason <billm@accessibleinter.net>) abstain
Daniel Schattenkirchner (Daniel Schattenkirchner <schattenkirchner.daniel@gmx.de>) concur
Shunsuke Kurumatani (Shunsuke Kurumatani <kurumatani.shunsuke@lab.ntt.co.jp>) yes
Jens Bannmann (Jens Bannmann <jens.b@web.de>) yes Without the canvas element, there will be no significant advance in graphics interaction on the web.
satish sangaru (satish sangaru <satish.sangaru@symphonysv.com>) 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 <david.dailey@sru.edu>) 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 <mattraymond@insightbb.com>) 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 <amla70@gmail.com>) yes Yes, it provides an API easy to use that allows to bring new features to the web.
Laura Carlson (Laura Carlson <laura.lee.carlson@gmail.com>) abstain
Dimitri Glazkov (Dimitri Glazkov <dglazkov@google.com>) 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 <gregory.rosmaita@gmail.com>) 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


The following W3C Members and Invited Experts have not answered the questionnaire:

  1. Voxeo: Daniel Burnett <dburnett@voxeo.com>
  2. Huawei: Wu Chou <wu.chou@huawei.com>,GANG LIANG <gang.liang@huawei.com>,Alex Giladi <alex.giladi@huawei.com>,Milan Patel <Milan.Patel@huawei.com>,Hao Jing <jh.jinghao@huawei.com>
  3. Netflix Inc.: Mark Watson <watsonm@netflix.com>,Mick Hakobyan <mhakobyan@netflix.com>
  4. Qihoo 360 Technology Co Ltd: Huan Ren <renhuan@360.cn>,Hanrui Gao <gaohanrui@360.cn>,yubo zhou <zhouyubo@360.cn>
  5. Electronics and Telecommunications Research Institute (ETRI): Kangchan Lee <chan@w3.org>,Jonathan Jeon <hollobit@etri.re.kr>,WonSuk Lee <wonsuk.lee@etri.re.kr>,jongyoul Park <jongyoul@etri.re.kr>
  6. Comcast Corporation: Mark Vickers <mark_vickers@cable.comcast.com>,Sree Kotay <Sree_Kotay@cable.comcast.com>,Jeremy LaCivita <jeremy.lacivita@theplatform.com>,David Mays <david_mays@comcast.com>,Michael Chen <michael_chen@cable.comcast.com>,Bill Mandel <bill.mandel@nbcuni.com>,Sheau Ng <Sheau.ng@nbcuni.com>,Patrick Ladd <Pat_Ladd2@cable.comcast.com>,Glenn Deen <glenn.deen@nbcuni.com>,John Riviello <john_riviello@comcast.com>,Rustam Khashimkhodjaev <Rustam_Khashimkhodjaev@cable.comcast.com>,Richard Grzeczkowski <richard_grzeczkowski@cable.comcast.com>,Cory Heslip <cory_heslip@cable.comcast.com>
  7. Tencent: Xitong Huang <stonehuang@tencent.com>,Min Ren <minren@tencent.com>
  8. Pearson plc: Suzanne Taylor <Suzanne.Taylor@pearson.com>,Greg Davis <greg.davis@pearson.com>
  9. W3C Staff:
  10. National ICT Australia (NICTA) Ltd: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
  11. SAP SE: Mark Crawford <mark.crawford@sap.com>,Stefan Schnabel <stefan.schnabel@sap.com>
  12. GRIN Technologies, Inc.: Daniel Austin <daniel.austin@grintech.net>
  13. Inswave Systems Co., Ltd.: WOOGLAE KIM <wlkim@inswave.com>
  14. Intel Corporation: Wayne Carr <wayne.carr@linux.intel.com>,Dzung Tran <dzung.d.tran@intel.com>,Anssi Kostiainen <anssi.kostiainen@intel.com>,Dongseong Hwang <dongseong.hwang@intel.com>
  15. Deque Systems, Inc.: Preety Kumar <preety.kumar@deque.com>,John Foliot <john.foliot@deque.com>
  16. British Broadcasting Corporation: David Evans <david.evans@rd.bbc.co.uk>
  17. HTML5 Converged Technology Forum: Hyejin Lee <hjlee@html5forum.or.kr>
  18. Nippon Telegraph & Telephone Corp. (NTT): Kensaku KOMATSU <kensaku.komatsu@gmail.com>,Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  19. Rakuten,Inc.: Kunio Ito <kunio.ito@mail.rakuten.com>,Tsutomu Ogasawara <tsutomu.ogasawara@mail.rakuten.com>,Jose Segura <jose.segura@mail.rakuten.com>
  20. Electronic Frontier Foundation: Danny O'Brien <danny@eff.org>,Seth Schoen <schoen@eff.org>
  21. Alibaba Group: Dapeng Liu <max.ldp@alibaba-inc.com>,Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  22. Skynav, Inc.: Glenn Adams <glenn@skynav.com>
  23. Fraunhofer Gesellschaft: Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>,Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  24. WIZVERA Co., Ltd.: Choon-Sik Cho <admin@wizvera.com>
  25. Samsung Electronics Co., Ltd.: Youngsun Ryu <ysryu@samsung.com>,MING JIN <ming.jin.web@gmail.com>,Jungkee Song <jungkee.song@samsung.com>
  26. Orange: Mohammed DADAS <mohammed.dadas@orange.com>,Arnaud Braud <arnaud.braud@orange.com>,Pascal Perrot <pascal.perrot@orange.com>
  27. Newphoria Corporation: Futomi Hatano <futomi.hatano@newphoria.co.jp>
  28. MovieLabs: James Helman <jhelman@movielabs.com>,Pierre-Anthony Lemieux <pal@sandflow.com>
  29. The Paciello Group, LLC: Steve Faulkner <faulkner.steve@gmail.com>,Patrick Lauke <redux@splintered.co.uk>,Gez Lemon <glemon@paciellogroup.com>,Ian Pouncey <w3c@ipouncey.co.uk>,Léonie Watson <lwatson@paciellogroup.com>,Billy Gregory <bgregory@paciellogroup.com>
  30. Royal National Institute of Blind People (RNIB): Sally Cain <sally.cain@rnib.org.uk>
  31. NIC.br - Brazilian Network Information Center: Reinaldo Ferraz <reinaldo@nic.br>,Yaso Córdova <yaso@nic.br>,Nathalia Sautchuk Patrício <nathalia@nic.br>,Deblyn prado <deblyn@nic.br>
  32. Verimatrix, Inc.: Petr Peterka <ppeterka@verimatrix.com>,Tom Handal <thandal@verimatrix.com>,Niels Thorwirth <nthorwirth@verimatrix.com>
  33. Avaya Communications: Dan Romascanu <dromasca@avaya.com>,A.S. Krishnakumar <ask@avaya.com>
  34. MITRE Corporation: Stanley Manoski <manoski@mitre.org>
  35. Baidu, Inc.: Eva Lingyun Jing <jinglingyun@baidu.com>,Xingrong Guo <guoxingrong@baidu.com>,Rayi Lei <leiyi@baidu.com>,jiexuan gao <gaojiexuan@baidu.com>,Xiaoqing Yang <yangxiaoqing@baidu.com>,Xuejian Li <lixuejian@baidu.com>,Zuncheng Yang <yangzuncheng@baidu.com>,Qianglong Zheng <zhengqianglong@baidu.com>,Zhou Shen <shenzhou@baidu.com>,Duoyi Wu <wuduoyi@baidu.com>,Zheng Jia <jiazheng@baidu.com>,Weifeng Feng <fengweifeng@baidu.com>,Damin Hu <hudamin@baidu.com>,Yang Liu <liuyang12@baidu.com>,Zhixing Lei <leizhixing@baidu.com>,Honggang Tang <tanghonggang@baidu.com>,Kefeng Li <buaadallas@gmail.com>,Xu Ma <maxu@baidu.com>,Junzhong Liu <liujunzhong@baidu.com>,lei wang <wanglei03@baidu.com>,Yiling Gu <guyiling@baidu.com>,Xueqing Huang <huangxueqing@baidu.com>,Zefa Xiong <xiongzefa@baidu.com>,shanglin chen <chenshanglin@baidu.com>,Dongsheng Zhang <zhangdongsheng@baidu.com>,Ping Wu <wuping02@baidu.com>,Yao Tong <tongyao@baidu.com>,Bin Chen <chenbin01@baidu.com>,Lei Wang <wanglei@baidu.com>,Pengcheng Guo <guopengcheng@baidu.com>,Xie Jianhui <xiejianhui@baidu.com>,Yujie Jiang <jiangyujie@baidu.com>,Chris Wong <huanghoujin@baidu.com>,Yiliang LIU <liuyiliang@baidu.com>,mingqiang zhang <imcnan@gmail.com>,xueliang fan <fanxueliang@baidu.com>,Yue Min <minyue@baidu.com>,Min Li <limin04@baidu.com>,yaolong wang <wangyaolong@baidu.com>,Tao Liang <liangtao01@baidu.com>
  36. jQuery Foundation: Yehuda Katz <wycats@gmail.com>,Brian Kardell <hitchjs@gmail.com>
  37. Hachette Livre: Gabino Alonso <gabinovincent@gmail.com>,Sam Langdon <sam.langdon@hachette.co.uk>
  38. Department of Internal Affairs, New Zealand Government: Jason Kiss <jason@accessibleculture.org>
  39. Sikos Web Consulting: Leslie Sikos <sikos@sikoswebconsulting.com.au>
  40. Yandex: Charles McCathie Nevile <chaals@yandex-team.ru>
  41. Center for Mathematics and Computer Science (CWI): Jack Jansen <jack@cwi.nl>,Steven Pemberton <Steven.Pemberton@cwi.nl>
  42. European Broadcasting Union (EBU-UER): Jean-Pierre EVAIN <evain@ebu.ch>,Bram Tullemans <tullemans@ebu.ch>
  43. Igalia: Joanmarie Diggs <jdiggs@igalia.com>
  44. Web3D Consortium: Don Brutzman <brutzman@nps.edu>
  45. Home Box Office, Inc.: Cyril Rickelton-Abdi <cyril.rickelton-abdi@turner.com>,Jamil Ellis <jamil.ellis@hbo.com>,Nolan Butcher <nolan.butcher@hbo.com>,Pramod Patlolla <pramod.patlolla@turner.com>,Cooper Pope <cooper.pope@turner.com>
  46. Disruptive Innovations: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  47. Educational Testing Service: Markku Hakkinen <mhakkinen@ets.org>,Jason White <jjwhite@ets.org>
  48. ERICSSON: Magnus Olsson <magnus.olsson@ericsson.com>,Per-Erik Brodin <per-erik.brodin@ericsson.com>
  49. Tomo-Digi Corporation: Shoko Okuma <okuma@tomo-digi.co.jp>,Fumitaka Watanabe <fwtnb@tomo-digi.co.jp>,Yoshimitsu Tsurimaki <tsurimaki@tomo-digi.co.jp>,Yusuke Maehama <maehama@tomo-digi.co.jp>
  50. Mitsubishi Electric Corporation: Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>,Shun-ichi Sekiguchi <Sekiguchi.Shunichi@eb.MitsubishiElectric.co.jp>,Hirofumi Nishikawa <Nishikawa.Hirofumi@cs.MitsubishiElectric.co.jp>,Hiroyuki Yamada <Yamada.Hiroyuki@dn.MitsubishiElectric.co.jp>
  51. Adobe Systems Inc.: Larry Masinter <masinter@adobe.com>,Roy Fielding <fielding@gbiv.com>,Joe Steele <steele@adobe.com>,Leonard Rosenthol <lrosenth@adobe.com>,Raul Hudea <rhudea@adobe.com>,Raghavan Gurumurthy <raghavan@adobe.com>,Mayank Kumar <mayankk@adobe.com>,Monikandan S <smonikan@adobe.com>,Dragos Georgita <dgeorgit@adobe.com>,Christopher Bank <cbank@adobe.com>,Rik Cabanier <Cabanier@adobe.com>,Kevin Streeter <kstreete@adobe.com>,Michael Thornburgh <mthornbu@adobe.com>,Glenn Eguchi <geguchi@adobe.com>
  52. INSTITUT TELECOM: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
  53. Cable Television Laboratories Inc: Bob Lund <b.lund@cablelabs.com>,Clarke Stevens <c.stevens@cablelabs.com>
  54. National Association of Broadcasters: So Vang <svang@nab.org>
  55. Sony Corporation: Tatsuya Igarashi <Tatsuya.Igarashi@jp.sony.com>,Motomasa Futagami <Motomasa.Futagami@jp.sony.com>,Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>,Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>,Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  56. Defense Information Systems Agency (DISA): Eric VonColln <eric.voncolln@navy.mil>
  57. Shane McCarron <shane@aptest.com>
  58. Vilem Malek <murphy@malek.cz>
  59. Andrew Ramsden <andrew@irama.org>
  60. Anders Bondehagen <anders@bondehagen.com>
  61. Mathias Bynens <mathias@qiwi.be>
  62. Jason Boyd <jason@pixelboxdesign.co.uk>
  63. Hernan Beati <hernanbeati@gmail.com>
  64. RAVI CHANDRA RAVULAPATI <ravichandra480@gmail.com>
  65. Patrick D F Ion <ion@ams.org>
  66. Tomas Caspers <tomas@tomascaspers.de>
  67. Zhihong Mao <zhihong.mao@gmail.com>
  68. Ron Reisor <ron@udel.edu>
  69. Shefik Macauley <allknightaccess@gmail.com>
  70. Ole Riesenberg <or@oleriesenberg.com>
  71. Ben Barber <barberboy@gmail.com>
  72. Chockalingam Muthian <chockam@gmail.com>
  73. Han Xu <collin@w3china.org>
  74. Benoit Piette <benoit.piette@gmail.com>
  75. Marat Tanalin <mtanalin@yandex.ru>
  76. Robert Stern <rstern@gmail.com>
  77. Lukáš Čihák <lukas.cihak@mensa.cz>
  78. Erik van Kempen <erikvankempen@gmail.com>
  79. Andrew Norman <idonothaveacat@gmail.com>
  80. Jeremy Keith <jeremy@adactio.com>
  81. Dean Leigh <dean.leigh@deanleigh.co.uk>
  82. Cameron Jones <cmhjones@gmail.com>
  83. Grzegorz Babula <gbabula@gmail.com>
  84. Janina Sajka <janina@rednote.net>
  85. Nick Fitzsimons <w3@nickfitz.co.uk>
  86. Craig Buckler <craigbuckler@gmail.com>
  87. Jedi Lin <JediLin@Gmail.com>
  88. Eihab Ibrahim <eihabibrahim@gmail.com>
  89. Alvar Laigna <laigna@gmail.com>
  90. Mathew Marquis <mat@matmarquis.com>
  91. Deborah Dahl <dahl@conversational-technologies.com>
  92. Josh Lawton <w3c@joshlawton.com>
  93. Matthew Turvey <mcturvey@gmail.com>
  94. Jon Hughes <jon@phazm.com>
  95. François REMY <francois.remy.dev@outlook.com>
  96. Jirka Kosek <jirka@kosek.cz>
  97. Giovanni Gentili <giovanni.gentili@gmail.com>
  98. Dale Hudjik <dale.hudjik@gmail.com>
  99. Samuel Santos <samaxes@gmail.com>
  100. Grant Simpson <glsimpso@gmail.com>
  101. Adrian Roselli <roselli@algonquinstudios.com>
  102. Joseph Karr O'Connor <josephoconnor@mac.com>
  103. David Carlisle <davidc@nag.co.uk>
  104. Robert Accettura <robert@accettura.com>
  105. S Emerson <w3c@accretewebsolutions.ca>
  106. Greg Johnson <greg.johnson@gmail.com>
  107. Colin Ihrig <cjihrig@gmail.com>
  108. Yusuke Kagiwada <block.rxckin.beats@gmail.com>
  109. Sierk Bornemann <sierkb@gmail.com>
  110. Morten Tollefsen <morten@medialt.no>
  111. Joseph D'Andrea <jdandrea@gmail.com>
  112. Martijn Croonen <martijn@martijnc.be>
  113. Jim Walsh <jim@jwalshcreative.com>
  114. Jim Allan <jimallan@tsbvi.edu>
  115. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  116. Michael Turnwall <w3c@turnwall.net>
  117. David MacDonald <David100@sympatico.ca>
  118. Lachlan Hunt <lachlan.hunt@lachy.id.au>
  119. Justin Anthony Knapp <justinkoavf@gmail.com>
  120. Don Kiely <donkiely@computer.org>
  121. Dionysios Synodinos <synodinos@gmail.com>
  122. Jonas Schneider <js.sokrates@gmail.com>
  123. Jonathan Neal <jonathantneal@gmail.com>
  124. Simon Myers <Smylers@stripey.com>
  125. Mike Amundsen <mamund@yahoo.com>
  126. Gian Luca Marroni <gmarroni@libero.it>
  127. Mark Sadecki <mark.sadecki+w3c@gmail.com>
  128. Markus Fischer <markus@fischer.name>
  129. Alejandro Fernandez <alejandro@mediadvanced.com>
  130. David Child <dave@addedbytes.com>
  131. Matt Lee <mattl@cnuk.org>
  132. Othmane Benyoucef <othmane_benyoucef@hotmail.com>
  133. Ian Devlin <ian@iandevlin.com>
  134. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  135. Channy Yun <channy@gmail.com>
  136. Doug Jones <doug_b_jones@me.com>
  137. Hasan Savran <hsavran@kent.edu>
  138. Andrew Davis <andrew@diff.mx>
  139. Shane Thacker <shanethacker@gmail.com>
  140. Marc Drumm <mdrumm@wcupa.edu>
  141. David Bills <w3@dfbills.com>
  142. Martin Kliehm <w3c@kliehm.com>
  143. Marco Kotrotsos <Marco@mlabs.nl>
  144. Mallory van Achterberg <stommepoes@stommepoes.nl>
  145. Lisa Seeman <lisa.seeman@zoho.com>
  146. Nik Thierry <me@thisemail.ca>
  147. Martin McEvoy <martin@weborganics.co.uk>
  148. Vladimir Sinelnikov <sinelnikov@gmail.com>
  149. Vicente García Díaz <vicegd@live.com>

Send an email to all the non-responders.

Compact view of the results

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

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