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 AS (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".
Member Access for Invited Experts and TAG
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
W3C Invited Experts
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
Theresa O'Connor (Theresa 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 Oliver Meiert (Jens Oliver 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. MITRE Corporation: Stanley Manoski <manoski@mitre.org>
  2. The Paciello Group, LLC: Steve Faulkner <faulkner.steve@gmail.com>,Patrick Lauke <redux@splintered.co.uk>
  3. Cable Television Laboratories Inc: Bob Lund <b.lund@cablelabs.com>,Clarke Stevens <c.stevens@cablelabs.com>
  4. Pearson plc: Suzanne Taylor <Suzanne.Taylor@pearson.com>,Greg Davis <greg.davis@pearson.com>
  5. Inswave Systems Co., Ltd.: WOOGLAE KIM <wlkim@inswave.com>
  6. W3C Staff:
  7. Sony Corporation: Tatsuya Igarashi <Tatsuya.Igarashi@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>
  8. HTML5 Converged Technology Forum: Hyejin Lee <hjlee@html5forum.or.kr>
  9. Orange: Mohammed DADAS <mohammed.dadas@orange.com>,Arnaud Braud <arnaud.braud@orange.com>,Pascal Perrot <pascal.perrot@orange.com>
  10. Netflix Inc.: Mark Watson <watsonm@netflix.com>,Mick Hakobyan <mhakobyan@netflix.com>
  11. JS Foundation: Brian Kardell <hitchjs@gmail.com>
  12. Alibaba Group: Dapeng Liu <max.ldp@alibaba-inc.com>,Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  13. Center for Mathematics and Computer Science (CWI): Jack Jansen <jack@cwi.nl>,Steven Pemberton <Steven.Pemberton@cwi.nl>
  14. Royal National Institute of Blind People (RNIB): Sally Cain <sally.cain@rnib.org.uk>
  15. Comcast Corporation: Mark Vickers <mark_vickers@comcast.com>,Jeremy LaCivita <jeremy.lacivita@comcast.com>,David Mays <david_mays@comcast.com>,Michael Chen <michael_chen@comcast.com>,Patrick Ladd <Pat_Ladd2@comcast.com>,Glenn Deen <glenn.deen@nbcuni.com>,John Riviello <john_riviello@comcast.com>,Rustam Khashimkhodjaev <Rustam_Khashimkhodjaev@comcast.com>,Richard Grzeczkowski <richard_grzeczkowski@comcast.com>,Cory Heslip <cory_heslip@comcast.com>,Ali C. Begen <ali_begen@comcast.com>
  16. British Broadcasting Corporation: David Evans <david.evans@rd.bbc.co.uk>
  17. MovieLabs: James Helman <jhelman@movielabs.com>,Pierre-Anthony Lemieux <pal@sandflow.com>
  18. European Broadcasting Union (EBU-UER): Jean-Pierre EVAIN <evain@ebu.ch>,Bram Tullemans <tullemans@ebu.ch>
  19. Electronic Frontier Foundation: Danny O'Brien <danny@eff.org>,Seth Schoen <schoen@eff.org>
  20. Educational Testing Service: Markku Hakkinen <mhakkinen@ets.org>,Jason White <jjwhite@ets.org>
  21. Rakuten,Inc.: Kunio Ito <kunio.ito@mail.rakuten.com>
  22. ERICSSON: Magnus Olsson <magnus.olsson@ericsson.com>,Per-Erik Brodin <per-erik.brodin@ericsson.com>
  23. NIC.br - Brazilian Network Information Center: Reinaldo Ferraz <reinaldo@nic.br>,Nathalia Sautchuk Patrício <nathalia@nic.br>
  24. Yandex: Charles McCathie Nevile <chaals@yandex.ru>
  25. 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>,Zefa Xiong <xiongzefa@baidu.com>,shanglin chen <chenshanglin@baidu.com>,Ping Wu <wuping02@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>
  26. Tencent: smallni ding <smallniding@tencent.com>,Min Ren <minren@tencent.com>,qigang huang <qiganghuang@tencent.com>
  27. Web3D Consortium: Don Brutzman <brutzman@nps.edu>
  28. Disruptive Innovations: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  29. Hachette Livre: Gabino Alonso <gabinovincent@gmail.com>,Sam Langdon <sam.langdon@hachette.co.uk>
  30. 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>,Dragos Georgita <dgeorgit@adobe.com>,Christopher Bank <cbank@adobe.com>,Kevin Streeter <kstreete@adobe.com>,Michael Thornburgh <mthornbu@adobe.com>,Glenn Eguchi <geguchi@adobe.com>
  31. SAP SE: Mark Crawford <mark.crawford@sap.com>,Stefan Schnabel <stefan.schnabel@sap.com>
  32. Igalia: Joanmarie Diggs <jdiggs@igalia.com>
  33. 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>
  34. Deque Systems, Inc.: Preety Kumar <preety.kumar@deque.com>,John Foliot <john.foliot@deque.com>
  35. Defense Information Systems Agency (DISA): Eric VonColln <eric.voncolln@navy.mil>
  36. 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>
  37. Nippon Telegraph & Telephone Corp. (NTT): Kensaku KOMATSU <kensaku.komatsu@gmail.com>,Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  38. Fraunhofer Gesellschaft: Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>,Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  39. Mitsubishi Electric Corporation: Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>,Yusuke Yokosuka <Yokosuka.Yusuke@bx.MitsubishiElectric.co.jp>,Seiji Okumura <Okumura.Seiji@bc.MitsubishiElectric.co.jp>,Eiji Yamamoto <Yamamoto.Eiji@db.MitsubishiElectric.co.jp>
  40. Newphoria Corporation: Futomi Hatano <futomi.hatano@newphoria.co.jp>
  41. National Association of Broadcasters: So Vang <svang@nab.org>
  42. Skynav, Inc.: Glenn Adams <glenn@skynav.com>
  43. Samsung Electronics Co., Ltd.: Youngsun Ryu <ysryu@samsung.com>,Jungkee Song <jungkee.song@samsung.com>
  44. Verimatrix, Inc.: Petr Peterka <ppeterka@verimatrix.com>,Tom Handal <thandal@verimatrix.com>,Niels Thorwirth <nthorwirth@verimatrix.com>
  45. Robert Accettura <robert@accettura.com>
  46. Sierk Bornemann <sierkb@gmail.com>
  47. Jedi Lin <JediLin@Gmail.com>
  48. Vladimir Sinelnikov <sinelnikov@gmail.com>
  49. Lukáš Čihák <lukas.cihak@mensa.cz>
  50. Patrick D F Ion <pion@umich.edu>
  51. Jon Hughes <jon@phazm.com>
  52. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  53. Channy Yun <channy@gmail.com>
  54. Ron Reisor <ron@udel.edu>
  55. Samuel Santos <samaxes@gmail.com>
  56. Grzegorz Babula <gbabula@gmail.com>
  57. David MacDonald <David100@sympatico.ca>
  58. Shane Thacker <shanethacker@gmail.com>
  59. Craig Buckler <craigbuckler@gmail.com>
  60. David Carlisle <davidc@nag.co.uk>
  61. Vilem Malek <murphy@malek.cz>
  62. Dale Hudjik <dale.hudjik@gmail.com>
  63. Zhihong Mao <zhihong.mao@gmail.com>
  64. Alvar Laigna <laigna@gmail.com>
  65. Jim Allan <jimallan@tsbvi.edu>
  66. Benoit Piette <benoit.piette@gmail.com>
  67. Joseph D'Andrea <jdandrea@gmail.com>
  68. Matt Lee <mattl@cnuk.org>
  69. Joseph Karr O'Connor <josephoconnor@mac.com>
  70. Erik van Kempen <erikvankempen@gmail.com>
  71. Don Kiely <donkiely@computer.org>
  72. Yusuke Kagiwada <block.rxckin.beats@gmail.com>
  73. Tomas Caspers <tomas@tomascaspers.de>
  74. Nick Fitzsimons <w3@nickfitz.co.uk>
  75. David Child <dave@addedbytes.com>
  76. Martin McEvoy <martin@weborganics.co.uk>
  77. Han Xu <collin@w3china.org>
  78. Josh Lawton <w3c@joshlawton.com>
  79. Anders Bondehagen <anders@bondehagen.com>
  80. Gian Luca Marroni <gmarroni@libero.it>
  81. Jim Walsh <jim@jwalshcreative.com>
  82. S Emerson <w3c@accretewebsolutions.ca>
  83. David Bills <w3@dfbills.com>
  84. Ole Riesenberg <or@oleriesenberg.com>
  85. Ian Devlin <ian@iandevlin.com>
  86. Justin Anthony Knapp <justinkoavf@gmail.com>
  87. Nik Thierry <me@thisemail.ca>
  88. Robert Stern <rstern@gmail.com>
  89. Hasan Savran <hsavran@kent.edu>
  90. Simon Myers <Smylers@stripey.com>
  91. Andrew Ramsden <andrew@irama.org>
  92. Eihab Ibrahim <eihabibrahim@gmail.com>
  93. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  94. Jirka Kosek <jirka@kosek.cz>
  95. Alejandro Fernandez <alejandro@mediadvanced.com>
  96. Shefik Macauley <allknightaccess@gmail.com>
  97. Deborah Dahl <dahl@conversational-technologies.com>
  98. Doug Jones <doug_b_jones@me.com>
  99. Greg Johnson <greg.johnson@gmail.com>
  100. Marc Drumm <mdrumm@wcupa.edu>
  101. Jeremy Keith <jeremy@adactio.com>
  102. Martijn Croonen <martijn@martijnc.be>
  103. Vicente García Díaz <vicegd@live.com>

Send an email to all the non-responders.

Compact view of the results / list of email addresses of the responders

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.135 2017/06/02 08:50:36 carcone 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)