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. Yandex: Charles McCathie Nevile <chaals@yandex-team.ru>
  2. Center for Mathematics and Computer Science (CWI): Jack Jansen <jack@cwi.nl>,Steven Pemberton <Steven.Pemberton@cwi.nl>
  3. Nippon Telegraph & Telephone Corp. (NTT): Kensaku KOMATSU <kensaku.komatsu@gmail.com>,Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  4. Rakuten,Inc.: Kunio Ito <kunio.ito@mail.rakuten.com>,Tsutomu Ogasawara <tsutomu.ogasawara@mail.rakuten.com>,Jose Segura <jose.segura@mail.rakuten.com>
  5. British Broadcasting Corporation: David Evans <david.evans@rd.bbc.co.uk>
  6. HTML5 Converged Technology Forum: Hyejin Lee <hjlee@html5forum.or.kr>
  7. Web3D Consortium: Don Brutzman <brutzman@nps.edu>
  8. Orange: Mohammed DADAS <mohammed.dadas@orange.com>,Arnaud Braud <arnaud.braud@orange.com>,Pascal Perrot <pascal.perrot@orange.com>
  9. Electronic Frontier Foundation: Danny O'Brien <danny@eff.org>,Seth Schoen <schoen@eff.org>
  10. Alibaba Group: Dapeng Liu <max.ldp@alibaba-inc.com>,Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  11. Disruptive Innovations: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  12. Educational Testing Service: Markku Hakkinen <mhakkinen@ets.org>,Jason White <jjwhite@ets.org>
  13. Royal National Institute of Blind People (RNIB): Sally Cain <sally.cain@rnib.org.uk>
  14. Fraunhofer Gesellschaft: Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>,Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  15. WIZVERA Co., Ltd.: Choon-Sik Cho <admin@wizvera.com>
  16. 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>
  17. INSTITUT TELECOM: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
  18. Avaya Communications: Dan Romascanu <dromasca@avaya.com>,A.S. Krishnakumar <ask@avaya.com>
  19. 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>
  20. Newphoria Corporation: Futomi Hatano <futomi.hatano@newphoria.co.jp>
  21. International Webmasters Association (IWA): Pasquale Popolizio <p.popolizio@webprofession.com>,Luca Mascaro <l.mascaro@webprofession.com>,Diego La Monica <d.lamonica@webprofession.com>,Pietro Russo <p.russo@webprofession.com>
  22. MITRE Corporation: Stanley Manoski <manoski@mitre.org>
  23. 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>
  24. Verimatrix, Inc.: Petr Peterka <ppeterka@verimatrix.com>,Tom Handal <thandal@verimatrix.com>,Niels Thorwirth <nthorwirth@verimatrix.com>
  25. European Broadcasting Union (EBU-UER): Jean-Pierre EVAIN <evain@ebu.ch>,Bram Tullemans <tullemans@ebu.ch>
  26. Department of Internal Affairs, New Zealand Government: Jason Kiss <jason@accessibleculture.org>
  27. jQuery Foundation: Yehuda Katz <wycats@gmail.com>,Brian Kardell <hitchjs@gmail.com>
  28. Hachette Livre: Gabino Alonso <gabinovincent@gmail.com>,Sam Langdon <sam.langdon@hachette.co.uk>
  29. 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>
  30. Voxeo: Daniel Burnett <dburnett@voxeo.com>
  31. Sikos Web Consulting: Leslie Sikos <sikos@sikoswebconsulting.com.au>
  32. 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>
  33. ERICSSON: Magnus Olsson <magnus.olsson@ericsson.com>,Per-Erik Brodin <per-erik.brodin@ericsson.com>
  34. Igalia: Joanmarie Diggs <jdiggs@igalia.com>
  35. W3C Staff:
  36. National ICT Australia (NICTA) Ltd: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
  37. 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>
  38. 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>
  39. 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>
  40. SAP SE: Mark Crawford <mark.crawford@sap.com>,Stefan Schnabel <stefan.schnabel@sap.com>
  41. Cable Television Laboratories Inc: Bob Lund <b.lund@cablelabs.com>,Clarke Stevens <c.stevens@cablelabs.com>
  42. 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>
  43. Deque Systems, Inc.: Preety Kumar <preety.kumar@deque.com>,John Foliot <john.foliot@deque.com>
  44. 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>
  45. National Association of Broadcasters: So Vang <svang@nab.org>
  46. Skynav, Inc.: Glenn Adams <glenn@skynav.com>
  47. Defense Information Systems Agency (DISA): Eric VonColln <eric.voncolln@navy.mil>
  48. Netflix Inc.: Mark Watson <watsonm@netflix.com>,Mick Hakobyan <mhakobyan@netflix.com>
  49. MovieLabs: James Helman <jhelman@movielabs.com>,Pierre-Anthony Lemieux <pal@sandflow.com>
  50. 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>
  51. Samsung Electronics Co., Ltd.: Youngsun Ryu <ysryu@samsung.com>,MING JIN <ming.jin.web@gmail.com>,Jungkee Song <jungkee.song@samsung.com>
  52. 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>
  53. Qihoo 360 Technology Co Ltd: Huan Ren <renhuan@360.cn>,Hanrui Gao <gaohanrui@360.cn>,yubo zhou <zhouyubo@360.cn>
  54. Tencent: Xitong Huang <stonehuang@tencent.com>,Min Ren <minren@tencent.com>
  55. Pearson plc: Suzanne Taylor <Suzanne.Taylor@pearson.com>,Greg Davis <greg.davis@pearson.com>
  56. GRIN Technologies, Inc.: Daniel Austin <daniel.austin@grintech.net>
  57. Inswave Systems Co., Ltd.: WOOGLAE KIM <wlkim@inswave.com>
  58. Lachlan Hunt <lachlan.hunt@lachy.id.au>
  59. Joseph D'Andrea <jdandrea@gmail.com>
  60. Samuel Santos <samaxes@gmail.com>
  61. Mathew Marquis <mat@matmarquis.com>
  62. Justin Anthony Knapp <justinkoavf@gmail.com>
  63. Michael Turnwall <w3c@turnwall.net>
  64. Grant Simpson <glsimpso@gmail.com>
  65. Adrian Roselli <roselli@algonquinstudios.com>
  66. François REMY <francois.remy.dev@outlook.com>
  67. Markus Fischer <markus@fischer.name>
  68. Simon Myers <Smylers@stripey.com>
  69. Don Kiely <donkiely@computer.org>
  70. Greg Johnson <greg.johnson@gmail.com>
  71. Colin Ihrig <cjihrig@gmail.com>
  72. Joseph Karr O'Connor <josephoconnor@mac.com>
  73. Dean Edridge <dean@dean.kiwi>
  74. Alejandro Fernandez <alejandro@mediadvanced.com>
  75. Martijn Croonen <martijn@martijnc.be>
  76. Yusuke Kagiwada <block.rxckin.beats@gmail.com>
  77. Lisa Seeman <lisa.seeman@zoho.com>
  78. Channy Yun <channy@gmail.com>
  79. Doug Jones <doug_b_jones@me.com>
  80. Jane Lee <applegoddess@gmail.com>
  81. Dionysios Synodinos <synodinos@gmail.com>
  82. Jim Walsh <jim@jwalshcreative.com>
  83. Shane McCarron <shane@aptest.com>
  84. Shane Thacker <shanethacker@gmail.com>
  85. Marc Drumm <mdrumm@wcupa.edu>
  86. David Child <dave@addedbytes.com>
  87. Jonas Schneider <js.sokrates@gmail.com>
  88. Patrick D F Ion <ion@ams.org>
  89. Matt Lee <mattl@cnuk.org>
  90. Mike Amundsen <mamund@yahoo.com>
  91. Gian Luca Marroni <gmarroni@libero.it>
  92. Jonathan Neal <jonathantneal@gmail.com>
  93. Tomas Caspers <tomas@tomascaspers.de>
  94. Vilem Malek <murphy@malek.cz>
  95. David Choi <daaave@gmail.com>
  96. Othmane Benyoucef <othmane_benyoucef@hotmail.com>
  97. Ian Devlin <ian@iandevlin.com>
  98. Mark Sadecki <mark.sadecki+w3c@gmail.com>
  99. Han Xu <collin@w3china.org>
  100. Zhihong Mao <zhihong.mao@gmail.com>
  101. David Bills <w3@dfbills.com>
  102. Martin Kliehm <w3c@kliehm.com>
  103. Hasan Savran <hsavran@kent.edu>
  104. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  105. Janina Sajka <janina@rednote.net>
  106. Benoit Piette <benoit.piette@gmail.com>
  107. Ron Reisor <ron@udel.edu>
  108. Nik Thierry <me@thisemail.ca>
  109. Martin McEvoy <martin@weborganics.co.uk>
  110. Ben Dalton <bendalton@gmail.com>
  111. Andrew Davis <andrew@diff.mx>
  112. Deborah Dahl <dahl@conversational-technologies.com>
  113. Erik van Kempen <erikvankempen@gmail.com>
  114. Marat Tanalin <mtanalin@yandex.ru>
  115. Andrew Ramsden <andrew@irama.org>
  116. Anders Bondehagen <anders@bondehagen.com>
  117. Marco Kotrotsos <Marco@mlabs.nl>
  118. Mallory van Achterberg <stommepoes@stommepoes.nl>
  119. Nick Fitzsimons <w3@nickfitz.co.uk>
  120. Andrew Norman <idonothaveacat@gmail.com>
  121. Shefik Macauley <allknightaccess@gmail.com>
  122. Dominik Tomaszuk <ddooss@wp.pl>
  123. Mathias Bynens <mathias@qiwi.be>
  124. Vladimir Sinelnikov <sinelnikov@gmail.com>
  125. Vicente García Díaz <vicegd@live.com>
  126. David Carlisle <davidc@nag.co.uk>
  127. Robert Accettura <robert@accettura.com>
  128. Jirka Kosek <jirka@kosek.cz>
  129. Josh Lawton <w3c@joshlawton.com>
  130. Craig Buckler <craigbuckler@gmail.com>
  131. Ole Riesenberg <or@oleriesenberg.com>
  132. Jason Boyd <jason@pixelboxdesign.co.uk>
  133. Hernan Beati <hernanbeati@gmail.com>
  134. RAVI CHANDRA RAVULAPATI <ravichandra480@gmail.com>
  135. Giovanni Gentili <giovanni.gentili@gmail.com>
  136. Matthew Turvey <mcturvey@gmail.com>
  137. Jeremy Keith <jeremy@adactio.com>
  138. Robert Stern <rstern@gmail.com>
  139. Ben Barber <barberboy@gmail.com>
  140. Chockalingam Muthian <chockam@gmail.com>
  141. Jim Allan <jimallan@tsbvi.edu>
  142. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  143. Sierk Bornemann <sierkb@gmail.com>
  144. S Emerson <w3c@accretewebsolutions.ca>
  145. Dale Hudjik <dale.hudjik@gmail.com>
  146. Jedi Lin <JediLin@Gmail.com>
  147. Dean Leigh <dean.leigh@deanleigh.co.uk>
  148. Cameron Jones <cmhjones@gmail.com>
  149. Lukáš Čihák <lukas.cihak@mensa.cz>
  150. David MacDonald <David100@sympatico.ca>
  151. Morten Tollefsen <morten@medialt.no>
  152. Jon Hughes <jon@phazm.com>
  153. Eihab Ibrahim <eihabibrahim@gmail.com>
  154. Alvar Laigna <laigna@gmail.com>
  155. Grzegorz Babula <gbabula@gmail.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)