Results of Questionnaire ISSUE-90: Removing the figure Element - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2010-05-12 to 2010-05-19.

9 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal to Remove the figure Element
  2. Objections to the Change Proposal to Keep New Elements and Attributes

1. Objections to the Change Proposal to Remove the figure Element

We have a Change Proposal to remove the figure element. If you have strong objections to adopting this Change Proposal, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.


Responder Objections to the Change Proposal to Remove the figure Element
Leif Halvard Silli
Cynthia Shelly The other change proposal makes the case very well for keeping this element. I object strongly to the removal of figure.
Larry Masinter
Henri Sivonen I agree with what the no-change counter proposal has to say in favor of <figure>. I also agree with the points the counter-proposal makes about ARIA.

Authors have wanted a figure+caption grouping mechanism for a long time. Now that we have it specced, I object to making the WG fail to deliver to Web authors by removing the element, because I think this author needs deserves to be addressed. Furthermore, I object to the notion that native markup isn't needed when something can be expressed in ARIA. First, as mentioned in the counter-proposal, ARIA is only for ATs, so it doesn't cover other modes of content consumption. Second, the ARIA example requires authors to build the structure using attributes. I object to refusing to make the basic construct easier for authors by introducing native elements for the purpose. I think refusing to improve HTML where ARIA already provides less usable syntax would set a very bad precedent to evolving HTML (or rather, failing to evolve) to address the needs of Web authors.
David Singer - Having an element that can associate an image or other illustration with a caption has been a wishlist item for Web content authors and standards experts for a long time.
- The "HTML5 Superfriends" group of Web standards experts supports the <figure> element, demonstrating support in the authoring community.
- Semantic elements lead to improved accessibility. The HTML WG Accessibility Task Force has endorsed the <figure> element and opposed the call to remove it.
- Implementors of multiple browser engines, including WebKit, Gecko and Presto, have expressed interest in implementing this element.

Given the interest from authors, implementors and the accessibility community in keeping it, the <figure> element should not be removed.
Gregory Rosmaita i am not opposed to FIGURE providing a containing element for multiple images that combine to produce a single narrative whole, as follows:

<LEGEND>Three Stages in the Life Cycle of a Frog</LEGEND>
<IMG src="frog-lc1" alt="Egg" longdesc="frog-lc1-desc.html">
<IMG src="frog-lc2" alt="Tadpole" longdesc="frog-lc2-desc.html">
<IMG src="frog-lc3" alt="Fully Grown Frog" longdesc="frog-lc3-desc.html">

in the above example, the FIGURE contains the 3 individual pieces of the overall illustration, all of which are described by the LEGEND (as in the FIELDSET/LEGEND/LABEL model familiar from forms in HTML4x); this provides a stronger native binding for these page elements than would exist if FIGURE were removed. alternately, if FIGCAPTION is also retained, then the above example would be:

<FIGCAPTION>Three Stages in the Life Cycle of a Frog</FIGCAPTION>
<IMG src="frog-lc1" alt="Egg" longdesc="frog-lc1-desc.html">
<IMG src="frog-lc2" alt="Tadpole" longdesc="frog-lc2-desc.html">
<IMG src="frog-lc3" alt="Fully Grown Frog" longdesc="frog-lc3-desc.html">

one thing in the change proposal with which i strongly disagree is the assertion that MathML is a graphical markup language -- The change proposal at http://www.w3.org/html/wg/wiki/ChangeProposals/removefigure makes several references to content that the author believes should be contained in a FIGURE element, if such an element is to be retained, listing MathML as appropriate content for a FIGURE element. MathML is not a graphical markup language, such as SVG, but a semantically-based XML-dialect which can be represented in a specific stylized means -- that is, as a mathematical expression -- but a mathematical expression is not a graphic, but a convention for expressing mathematical functions. MathML provides a modality neutral means of expressing mathematical functions so that they can be rendered in the modality that makes most sense/is most usable for a particular user. Note, as well, that the ARIA role value "math" descends from text, not a graphical representation of the mathematical expression.
Jonas Sicking I object to removing the <figure> element as it would result in missing out of the positive effects listed in http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements#Positive_Effects

My experience working with web authors for several years is that they tend to do what is easy, whereas accessibility often ends up coming second due to time constraints and unawareness.

By including the semantic <figure> element, we both make it easier for developers to do what they want, since <div class=figure>+CSS is more work than <figure>, as well as automatically get good accessibility in pages.

I think it's very unlikely that as many people would add proper ARIA attributes, as would use the <figure> element. I think this is the reason that the WAI-ARIA specification encourages developers of markup languages to add semantic elements and explicitly declares ARIA as a bridge technology. I also think this is why the HTML Accessibility TF has endorsed the <figure> element.
Krzysztof Maczy&#324;ski 1. This CP assumes that figures need to be graphical entities. While true, obviously and necessarily, in print, a medium from which many Web ideas have been and still are borrowed and abstracted, this happens with generalization and should take media independence into account. The abstract idea of figure is distinct enough (though perhaps the spec wording may benefit from more massaging) and fits well enough into a general language for marking up hypertext. (To phrase it remarkably, this objection of mine has the same grounds on which I object to img not even being deprecated.)
2. This CP does a disservice to the ASCII art use case.
Note that this response doesn't constitute support for the naming of figcaption (particularly whether it should be separate from all of legend, summary, etc.).
Laura Carlson

2. Objections to the Change Proposal to Keep New Elements and Attributes

We have a Change Proposal to keep several newly-introduced semantic elements, attributes, and controls. If you have strong objections to adopting this Change Proposal specifically with respect to the figure element, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.


Responder Objections to the Change Proposal to Keep New Elements and Attributes
Leif Halvard Silli (This is identical with my response on the details element.)

Long version: http://lists.w3.org/Archives/Public/public-html/2010May/0010
Shorter version:


<figure> and <details> are not fully baked. <figure> and <details> are apparently considered as such good *ideas*, that the ideas are considered worth more than a high quality and straight forward/simple implementation of those ideas.

Caption related reasons to object:

The caption issue has been the main problem all along (and the editor many times postponed the entire issue). And we have ended up with an ad-hoc and expensive solution: two caption elements with unclear vs. overclear links to their parent elemetns.

<details> and <figure> are quite similar elements. They should at best have been able to reuse table's <caption> element as their own caption (and if we took our time, I'm sure we could do that, despite the Webkit hurdles). But as a second best, the should have had one and the same caption element. As it stands, then <summary> is not in any whatsoever way especially fit as a name for the caption of <details> - there is no semantic or logical link between the word "summary" and <details> any more than there is between "summary" and <figure>. And <figcaption> is a very untraditional element name for html - it's odd. Other optiosn have been <label>, <legend>, <dt>. And also <dd> as child body element. The current solution looks more as a reaction to the problem that we couldn't use <dt> and <dd>, than a pleasing quality solution.

The name of the caption is such an important feature of both elements, that it will hamper the take up of them. Not every <figure> may need a caption. But the caption is still a core to the very figure concept.

Design related reasons to object:

Neither <figure> nor <details> can be used inline - e.g. inside a <p> element. Thus there is no way to create captions e.g. for inline images. One can of course use wrap an inline image inside a <span> and use ARIA etc. However one of the argumetns for keeping <figure> as is, is that one may then avoid using ARIA ... I have filed bugs about the <object> element, so that it can be used as a container for <figure> or <details> .... But that also requires that <object> is permitted used more like in HTML4 ... The defends of <figure> as it stands, have shown no interest in this problem - as far as I have noticed.

<details> also seems to "eat" from other elements. I concur with Benoit Piette (http://lists.w3.org/Archives/Public/public-html/2010May/0006) in that the details behavior should rather be integrated into existing elements. <details> looks like an "easy way out" when the author is unable to get e.g. a <dl> list to behave in a <details> alike way.

Not sure how crucial *this* is but, <figure> will also "compete" with <dl> - what's the advantage over <dl><dt>caption<dd>content</dl>?


1. I question whether the long term issues have been given enough thought when it comes to the choice of caption element(s)
2. Figure and Details are far less generic than it may seem on the sureface due to their inability to be used inline.
3. <details> seems like a teaser that may get authors to use it purely for the behavior. (Remember <blink> anyone ...)
4. Regarding 1., 2. and 3.: I fail to see the over all goals behind the creation of <figure> and <details>. If we had concrete goals, then we could have compared and decided if 1., 2. and 3. was in line with the the reasons why we started to work on <figure> and <details> in the first place.

I therefore recommend that we take <details> and <figure> out of HTML5 for now, with the prmise to look at them again. We should also write up more detailed the goals with these elements, and be open to take them back in, once we see that they can fulfil what we want them to fulfill.
Cynthia Shelly
Larry Masinter I'm not *strongly* opposed to the concepts that these semantic elements, attributes and controls add, but I do think that, in order to actually reach a W3C standard quickly, controversial additions that are likely to slow down progress or result in poor interoperability should be removed from the specification so that the W3C HTML working group can reach closure quickly.

One thing that concerns me about many of these is that the transition plan is unclear to me: how can authors can introduce these new features and still be compatible with older browsers? Without a clear, acceptable transition plan, the risk is to fragment the web, and to encourage authors to create "best viewed by HTML5" web sites, in a repeat of Browser Wars 1.0. The current specification does not address the transition and fallback issues, and for that reason alone, these elements should be removed until those details can be worked out and reviewed fully.

Henri Sivonen
David Singer
Gregory Rosmaita
Jonas Sicking
Krzysztof Maczy&#324;ski
Laura Carlson Rationale is at:

More details on responses

  • Leif Halvard Silli: last responded on 13, May 2010 at 02:25 (UTC)
  • Cynthia Shelly: last responded on 13, May 2010 at 18:30 (UTC)
  • Larry Masinter: last responded on 13, May 2010 at 20:37 (UTC)
  • Henri Sivonen: last responded on 14, May 2010 at 13:50 (UTC)
  • David Singer: last responded on 18, May 2010 at 18:32 (UTC)
  • Gregory Rosmaita: last responded on 19, May 2010 at 14:54 (UTC)
  • Jonas Sicking: last responded on 19, May 2010 at 18:51 (UTC)
  • Krzysztof Maczy&#324;ski: last responded on 19, May 2010 at 19:52 (UTC)
  • Laura Carlson: last responded on 20, May 2010 at 01:47 (UTC)


The following persons have not answered the questionnaire:

  1. Tantek Çelik <tantek@cs.stanford.edu>
  2. Patrick D F Ion <pion@umich.edu>
  3. Judy Brewer <jbrewer@w3.org>
  4. Liam Quin <liam@w3.org>
  5. Richard Ishida <ishida@w3.org>
  6. Chris Wilson <cwilso@google.com>
  7. David Carlisle <davidc@nag.co.uk>
  8. James Helman <jhelman@movielabs.com>
  9. Jim Allan <jimallan@tsbvi.edu>
  10. Chris Marrin <cmarrin@apple.com>
  11. Charles McCathie Nevile <chaals@yandex.ru>
  12. Philippe Le Hégaret <plh@w3.org>
  13. Don Brutzman <brutzman@nps.edu>
  14. T.V. Raman <raman@google.com>
  15. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  16. Karl Dubost <karl@la-grange.net>
  17. Ian Hickson <ian@hixie.ch>
  18. Wu Chou <wu.chou@huawei.com>
  19. Katsuhiko Momoi <momoi@google.com>
  20. Kangchan Lee <chan@w3.org>
  21. Roy Fielding <fielding@gbiv.com>
  22. Deborah Dahl <dahl@conversational-technologies.com>
  23. Michael Cooper <cooper@w3.org>
  24. Glenn Adams <glenn@skynav.com>
  25. Jonathan Jeon <hollobit@etri.re.kr>
  26. David Hyatt <hyatt@apple.com>
  27. WonSuk Lee <wonsuk.lee@etri.re.kr>
  28. Maciej Stachowiak <mjs@apple.com>
  29. Robert Accettura <robert@accettura.com>
  30. Jonathan Watt <jwatt@jwatt.org>
  31. Steve Faulkner <faulkner.steve@gmail.com>
  32. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  33. Patrick Lauke <redux@splintered.co.uk>
  34. David MacDonald <David100@sympatico.ca>
  35. Jack Jansen <jack@cwi.nl>
  36. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  37. Markku Hakkinen <mhakkinen@ets.org>
  38. Jens Oliver Meiert <jens@meiert.com>
  39. Kazuyuki Ashimura <ashimura@w3.org>
  40. Han Xu <collin@w3china.org>
  41. Sam Ruby <rubys@intertwingly.net>
  42. Mark Crawford <mark.crawford@sap.com>
  43. Preety Kumar <preety.kumar@deque.com>
  44. Ian Fette <ifette@google.com>
  45. Cameron McCormack <cam@mcc.id.au>
  46. Stefan Schnabel <stefan.schnabel@sap.com>
  47. Jirka Kosek <jirka@kosek.cz>
  48. Travis Leithead <Travis.Leithead@microsoft.com>
  49. Youngsun Ryu <ysryu@samsung.com>
  50. Sierk Bornemann <sierkb@gmail.com>
  51. James Graham <james@hoppipolla.co.uk>
  52. Krijn Hoetmer <w3c@qontent.nl>
  53. Channy Yun <channy@gmail.com>
  54. Shane Thacker <shanethacker@gmail.com>
  55. Vilem Malek <murphy@malek.cz>
  56. Zhihong Mao <zhihong.mao@gmail.com>
  57. Benoit Piette <benoit.piette@gmail.com>
  58. Erik van Kempen <erikvankempen@gmail.com>
  59. Dimitri Glazkov <dglazkov@google.com>
  60. Nick Fitzsimons <w3@nickfitz.co.uk>
  61. Josh Lawton <w3c@joshlawton.com>
  62. S Emerson <w3c@accretewebsolutions.ca>
  63. Theresa O'Connor <eoconnor@apple.com>
  64. Justin Anthony Knapp <justinkoavf@gmail.com>
  65. Simon Myers <Smylers@stripey.com>
  66. Samuel Weinig <weinig@apple.com>
  67. Alexey Proskuryakov <ap@webkit.org>
  68. Alejandro Fernandez <alejandro@mediadvanced.com>
  69. Doug Jones <doug_b_jones@me.com>
  70. Marc Drumm <mdrumm@wcupa.edu>
  71. Danny Liang <danny.glue@gmail.com>
  72. Michael Puls II <shadow2531@gmail.com>
  73. Ron Reisor <ron@udel.edu>
  74. Craig Buckler <craigbuckler@gmail.com>
  75. Dale Hudjik <dale.hudjik@gmail.com>
  76. James Cassell <w3c@cyberpear.com>
  77. Joseph D'Andrea <jdandrea@gmail.com>
  78. Eric Carlson <eric.carlson@apple.com>
  79. Don Kiely <donkiely@computer.org>
  80. David Child <dave@addedbytes.com>
  81. Mark DuBois <Mark@webprofessionals.org>
  82. David Bills <w3@dfbills.com>
  83. Nik Thierry <me@thisemail.ca>
  84. Andrew Ramsden <andrew@irama.org>
  85. John Foliot <john.foliot@deque.com>
  86. Shefik Macauley <allknightaccess@gmail.com>
  87. Joe Steele <steele@adobe.com>
  88. John Vernaleo <john@netpurgatory.com>
  89. Jeremy Keith <jeremy@adactio.com>
  90. Jedi Lin <JediLin@Gmail.com>
  91. Jon Hughes <jon@phazm.com>
  92. Samuel Santos <samaxes@gmail.com>
  93. Dean Jackson <dino@apple.com>
  94. Mohammed DADAS <mohammed.dadas@orange.com>
  95. Sally Cain <sally.cain@rnib.org.uk>
  96. David Bolter <dbolter@mozilla.com>
  97. James Craig <jcraig@apple.com>
  98. Leonard Rosenthol <lrosenth@adobe.com>
  99. Jean-Pierre EVAIN <evain@ebu.ch>
  100. Mark Pilgrim <pilgrim@google.com>
  101. Matt Lee <mattl@cnuk.org>
  102. Magnus Olsson <magnus.olsson@ericsson.com>
  103. Chris Pearce <cpearce@mozilla.com>
  104. Andrew Wilson <atwilson@google.com>
  105. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  106. Ojan Vafai <ojan@chromium.org>
  107. Martin McEvoy <martin@weborganics.co.uk>
  108. Aryeh Gregor <ayg@aryeh.name>
  109. Anders Bondehagen <anders@bondehagen.com>
  110. Steven Pemberton <Steven.Pemberton@cwi.nl>
  111. Raul Hudea <rhudea@adobe.com>
  112. Raghavan Gurumurthy <raghavan@adobe.com>
  113. Mayank Kumar <mayankk@adobe.com>
  114. Dragos Georgita <dgeorgit@adobe.com>
  115. Christopher Bank <cbank@adobe.com>
  116. Ole Riesenberg <or@oleriesenberg.com>
  117. Takuya Oikawa <takuya@google.com>
  118. Jatinder Mann <jmann@microsoft.com>
  119. Robert Stern <rstern@gmail.com>
  120. Eihab Ibrahim <eihabibrahim@gmail.com>
  121. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  122. Jer Noble <jer.noble@apple.com>
  123. Masatomo Kobayashi <mstm@jp.ibm.com>
  124. Peter Beverloo <beverloo@google.com>
  125. Andrew Scherkus <scherkus@google.com>
  126. Greg Johnson <greg.johnson@gmail.com>
  127. Martijn Croonen <martijn@martijnc.be>
  128. Stanley Manoski <manoski@mitre.org>
  129. Mounir Lamouri <mlamouri@google.com>
  130. Tony Gentilcore <tonyg@google.com>
  131. Joseph Pecoraro <pecoraro@apple.com>
  132. Bob Lund <b.lund@cablelabs.com>
  133. Tatsuya Igarashi <Tatsuya.Igarashi@sony.com>
  134. John Simmons <johnsim@microsoft.com>
  135. Mark Watson <watsonm@netflix.com>
  136. Clarke Stevens <c.stevens@cablelabs.com>
  137. Mark Vickers <mark_vickers@comcast.com>
  138. Jeremy LaCivita <jeremy.lacivita@comcast.com>
  139. Denis Ah-Kang <denis@w3.org>
  140. Alvar Laigna <laigna@gmail.com>
  141. Kunio Ito <kunio.ito@mail.rakuten.com>
  142. David Mays <david_mays@comcast.com>
  143. Michael Chen <michael_chen@comcast.com>
  144. jongyoul Park <jongyoul@etri.re.kr>
  145. Reinaldo Ferraz <reinaldo@nic.br>
  146. Eva Lingyun Jing <jinglingyun@baidu.com>
  147. GANG LIANG <gang.liang@huawei.com>
  148. Ryosuke Niwa <rniwa@apple.com>
  149. Gian Luca Marroni <gmarroni@libero.it>
  150. Ian Devlin <ian@iandevlin.com>
  151. Xingrong Guo <guoxingrong@baidu.com>
  152. Jet Villegas <w3c@junglecode.net>
  153. Alexander Surkov <surkov.alexander@gmail.com>
  154. Hasan Savran <hsavran@kent.edu>
  155. Eric VonColln <eric.voncolln@navy.mil>
  156. Jungkee Song <jungkee.song@samsung.com>
  157. Rayi Lei <leiyi@baidu.com>
  158. David Dorwin <ddorwin@google.com>
  159. jiexuan gao <gaojiexuan@baidu.com>
  160. Xiaoqing Yang <yangxiaoqing@baidu.com>
  161. Aaron Colwell <acolwell@google.com>
  162. Alex Giladi <alex.giladi@huawei.com>
  163. Motomasa Futagami <Motomasa.Futagami@jp.sony.com>
  164. Kevin Streeter <kstreete@adobe.com>
  165. Christian Kaiser <kaiserc@google.com>
  166. Xuejian Li <lixuejian@baidu.com>
  167. Zuncheng Yang <yangzuncheng@baidu.com>
  168. Qianglong Zheng <zhengqianglong@baidu.com>
  169. Zhou Shen <shenzhou@baidu.com>
  170. Duoyi Wu <wuduoyi@baidu.com>
  171. Zheng Jia <jiazheng@baidu.com>
  172. Weifeng Feng <fengweifeng@baidu.com>
  173. Damin Hu <hudamin@baidu.com>
  174. Yang Liu <liuyang12@baidu.com>
  175. Zhixing Lei <leizhixing@baidu.com>
  176. Honggang Tang <tanghonggang@baidu.com>
  177. Kefeng Li <buaadallas@gmail.com>
  178. Xu Ma <maxu@baidu.com>
  179. Junzhong Liu <liujunzhong@baidu.com>
  180. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  181. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  182. Ami Fischman <fischman@google.com>
  183. Arnaud Braud <arnaud.braud@orange.com>
  184. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  185. Bram Tullemans <tullemans@ebu.ch>
  186. Petr Peterka <ppeterka@verimatrix.com>
  187. lei wang <wanglei03@baidu.com>
  188. Milan Patel <Milan.Patel@huawei.com>
  189. Yiling Gu <guyiling@baidu.com>
  190. Zefa Xiong <xiongzefa@baidu.com>
  191. shanglin chen <chenshanglin@baidu.com>
  192. Ping Wu <wuping02@baidu.com>
  193. Bin Chen <chenbin01@baidu.com>
  194. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  195. Patrick Ladd <Pat_Ladd2@comcast.com>
  196. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  197. Hao Jing <jh.jinghao@huawei.com>
  198. Glenn Deen <glenn.deen@nbcuni.com>
  199. Lei Wang <wanglei@baidu.com>
  200. Tom Handal <thandal@verimatrix.com>
  201. Pengcheng Guo <guopengcheng@baidu.com>
  202. Tom Wiltzius <wiltzius@google.com>
  203. Pierre-Anthony Lemieux <pal@sandflow.com>
  204. Xie Jianhui <xiejianhui@baidu.com>
  205. Yujie Jiang <jiangyujie@baidu.com>
  206. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  207. Brady Eidson <beidson@apple.com>
  208. Michael Thornburgh <mthornbu@adobe.com>
  209. Mick Hakobyan <mhakobyan@netflix.com>
  210. Vladimir Sinelnikov <sinelnikov@gmail.com>
  211. Chris Wong <huanghoujin@baidu.com>
  212. Yiliang LIU <liuyiliang@baidu.com>
  213. mingqiang zhang <imcnan@gmail.com>
  214. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  215. Grzegorz Babula <gbabula@gmail.com>
  216. Brian Kardell <hitchjs@gmail.com>
  217. xueliang fan <fanxueliang@baidu.com>
  218. Niels Thorwirth <nthorwirth@verimatrix.com>
  219. David Evans <david.evans@rd.bbc.co.uk>
  220. Joseph Karr O'Connor <josephoconnor@mac.com>
  221. Yusuke Kagiwada <block.rxckin.beats@gmail.com>
  222. smallni ding <smallniding@tencent.com>
  223. Jim Walsh <jim@jwalshcreative.com>
  224. Greg Davis <greg.davis@pearson.com>
  225. Gabino Alonso <gabinovincent@gmail.com>
  226. Sam Langdon <sam.langdon@hachette.co.uk>
  227. Michael Kelly <mkelly@mozilla.com>
  228. Xiaoqian Wu <xiaoqian@w3.org>
  229. Yue Min <minyue@baidu.com>
  230. Min Li <limin04@baidu.com>
  231. Joanmarie Diggs <jdiggs@igalia.com>
  232. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  233. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  234. So Vang <svang@nab.org>
  235. Nathalia Sautchuk Patrício <nathalia@nic.br>
  236. Vicente García Díaz <vicegd@live.com>
  237. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  238. Yusuke Yokosuka <Yokosuka.Yusuke@bx.MitsubishiElectric.co.jp>
  239. John Riviello <john_riviello@comcast.com>
  240. yaolong wang <wangyaolong@baidu.com>
  241. Tao Liang <liangtao01@baidu.com>
  242. Glenn Eguchi <geguchi@adobe.com>
  243. Lukáš Čihák <lukas.cihak@mensa.cz>
  244. WOOGLAE KIM <wlkim@inswave.com>
  245. Min Ren <minren@tencent.com>
  246. Jason White <jjwhite@ets.org>
  247. Hyejin Lee <hjlee@html5forum.or.kr>
  248. Richard Grzeczkowski <richard_grzeczkowski@comcast.com>
  249. Pascal Perrot <pascal.perrot@orange.com>
  250. Dapeng Liu <max.ldp@alibaba-inc.com>
  251. Matthew Wolenetz <wolenetz@google.com>
  252. Cory Heslip <cory_heslip@comcast.com>
  253. Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  254. Seiji Okumura <Okumura.Seiji@bc.MitsubishiElectric.co.jp>
  255. Eiji Yamamoto <Yamamoto.Eiji@db.MitsubishiElectric.co.jp>
  256. Ali C. Begen <ali_begen@comcast.com>
  257. HENGBING LIU <herbertliu@tencent.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

Report issues on GitHub project w3c/wbs-design (preferred) or by mail to sysreq.