W3C WBS Home

Results of Questionnaire ISSUE-200: Should LEGEND be allowed to be wrapped in non-FIELDSET elements - Straw Poll for Objections

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: pcotton@microsoft.com, rubys@intertwingly.net, mjs@apple.com, mike@w3.org

This questionnaire was open from 2012-07-03 to 2012-07-19.

4 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal to permit LEGEND to be wrapped in non-FIELDSET elements.
  2. Objections to the Change Proposal to keep the existing content model of FIELDSET elements

1. Objections to the Change Proposal to permit LEGEND to be wrapped in non-FIELDSET elements.

We have a Change Proposal that proposes to permit the LEGEND element to be wrapped in non-FIELDSET elements. 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.

Details

Responder Objections to the Change Proposal to permit LEGEND to be wrapped in non-FIELDSET elements.
Tab Atkins Jr. I object to this change proposal.

The first example in the change proposal was discussed in the mailing list. There, it was demonstrated that it is very easy to change the markup to achieve the same styling effects while obeying the current <legend> placement rules.

The second example doesn't seem to solve a real problem. Legends are usually very short, and so the minor duplication that might appear between a legend and a longer explanation is not something that's sufficiently worth killing to justify adding a new element or changing the parsing of existing elements.

Further, the example as written is very likely not what's desired - the <ilegend> wraps a word in the middle of the sentence, which is lowercase, but legends are usually presented with initial caps. Similarly, the wording of a legend (acting as a section header) is often slightly different than a similar phrase in a longer description. It seems unlikely that this use-case will usually be possible without employing extra CSS and/or awkward phrasing.

The "Negative Effects" section is drastically incomplete. The most pressing omitted entry is the extra work of adjusting the parsing and display of existing <legend> elements, and adding a new <ilegend> element. Omitting this cost can make a lot of trivial changes seem worthwhile.

Another omitted entry is the possibility that existing content is (incorrectly) using <legend> in invalid locations, and the suggested change would alter the presentation of that element. In some cases this may be a minor visual change, while in others it may be a significant rearranging (if the <legend> was in the middle of other content where its placement was important).

Overall, the Change Proposal attempts to solve problems that are either insignificant or non-existent, and omits consideration of the costs involved, both in terms of implementor time and possible backwards-compat issues.
Boris Zbarsky The part of this proposal that introduces an "ilegend" element seems completely unnecessary. As far as I can tell, it would just be an alias for "legend" and needlessly increase complexity. There seems to be no good reason for introducing the new tag, and I object to that part.

Apart from that, this change proposal seems to mostly talk about changing the set of conforming documents; those changes seem reasonable to me.

Note that the spec already has the rendering requirements for a "legend" whose parent is not a "fieldset" that this change proposal is asking for, though it doesn't spell them out explicitly. Perhaps it should.
Henri Sivonen I strongly object to the part of this change proposal that adds an ilegend element. The usefulness of this alias would be too limited: the sole piece of usefulness would be working around undesirable parser behaviors in Firefox 3.6 and earlier, since the other oddities of fieldset/legend that occur when legend is a non-first child (but is a child) of fieldset could be worked around by adding a wrapper element (and some padding-zeroing CSS). I think we should not introduce new elements solely because of their fallback characteristics in Firefox 3.6 or earlier. Firefox 3.6 usage share will probably not be an issue a year from now, but an ilegend element would be with us forever.

As a validator developer, I do not object to loosening the authoring conformance requirements for the placement of legend as long as: 1) each legend has a fieldset ancestor, 2) each fieldset has at most one legend descendant that doesn't have another nearer fieldset ancestor, 3) a legend whose parent is a fieldset is the first child of the fieldset (to avoid legacy oddities) and 4) the definition of finding the legend for the fieldset is changed such that the first descendant legend that doesn't have another nearer fieldset ancestor is the legend of the fieldset. On the other hand, I neither particularly support such loosening as I understand #4 might complicate accessibility implementation or break compatibility with existing accessibility implementations in ways that I'm not well positioned to assess before the deadline of this poll (so I might even object if I knew about such breakage for a fact; I encourage the Chairs to investigate the possibility of such breakage). I also acknowledge that the provisions on my non-objection as a validator developer are complex enough that it wouldn't be unreasonable to reject a change that'd involve such complexity.
David Bolter There may be some performance cost to associating a field-set element with a legend that could be anywhere in the subtree, which we would need to do in our accessibility engine (in gecko). The cost (and impact on usability) is currently unknown and I don't know how big field-set subtrees might get in the wild. I can't say this is a strong objection at this time.

2. Objections to the Change Proposal to keep the existing content model of FIELDSET elements

We have a Change Proposal that proposes to keep the existing content model of FIELDSET elements and thus NOT permit the LEGEND element to be wrapped in non-FIELDSET elements. 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.

Details

Responder Objections to the Change Proposal to keep the existing content model of FIELDSET elements
Tab Atkins Jr.
Boris Zbarsky The HTML5 parser already allows "legend" in an arbitrary place in the DOM, in the sense that if you put it there it will get parsed as if it were any other tag. The change proposal does not propose changing that.

The change proposal also does not propose changing section 14.3.12, which is pretty straightforward: the "rendered legend" of a fieldset gets some special behavior, but any other legend is just a block like any other block (because the spec says nothing to the contrary; it _does_ define that legends are display:block by default in section 14.3.3).

The various comments in the change proposal about the legacy rendering restrictions on legend and fieldset only apply to the rendered legend of the fieldset, of course, and hence have no bearing on legends that are not a child of the fieldset at all.

While in the past UAs have had various rendering restrictions on such legends, they have been moving away from that for years (e.g. see https://bugzilla.mozilla.org/show_bug.cgi?id=476063 ) and there is actually fairly good interoperability on the rendering behavior of legends whose parent is not a fieldset, with very few bugs remaining.

Given that the rendering for both legends which are a child of a fieldset but not the first child and legends that are not a child of a fieldset at all is already well-defined in a sane way and that UAs are already converging on that rendering, I see no benefit to keeping the completely arbitrary restriction that legend must only appear as the first child of the fieldset. While sticking with that rule does ensure that content will render in a reasonable way on certain old UAs, and that is probably worth calling out in the spec, I don't think that necessitates an authoring conformance requirement.

Furthermore, I don't think that loosening this restriction increases implementation complexity: a UA has to have code to do the "just a block" thing no matter what, since legends can in fact appear as children of non-fieldsets and a fieldset can have multiple child "legend" elements, all but one of which have to be treated as blocks.

Therefore I object to this change proposal: it's unnecessarily restricting authors, while changing nothing for implementors in practice.
Henri Sivonen Cursory testing suggests that both Firefox and IE are quite okay with legend as a non-child descendent of a fieldset from the CSS perspective. It also appears that Opera merely special-cases the meaning of display: inline; in that case and non-inline display values (including inline-block) behave normally. It appears that WebKit special cases display for legend so that it's permanently stuck, which seems like a weakness in WebKit in the light of what the other engines do and the weakness isn't even fatal when considering plausible use cases that want a block-ish appearance for legend.

Thus, the CSS-oriented rationale of this change proposal seems weak to the extent it applies to legend as a non-child descendant of fieldset. (Layout-oriented rationale for not allowing legend as a non-first child of fieldset seems reasonable in the light of the legacy, though.)
David Bolter

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Tantek Çelik <tantek@cs.stanford.edu>
  2. Patrick D F Ion <ion@ams.org>
  3. Richard Schwerdtfeger <schwer@us.ibm.com>
  4. Judy Brewer <jbrewer@w3.org>
  5. Wayne Carr <wayne.carr@linux.intel.com>
  6. Liam Quin <liam@w3.org>
  7. Richard Ishida <ishida@w3.org>
  8. Chris Wilson <cwilso@google.com>
  9. Wendy Chisholm <wendc@microsoft.com>
  10. David Carlisle <davidc@nag.co.uk>
  11. James Helman <jhelman@movielabs.com>
  12. Jim Allan <jimallan@tsbvi.edu>
  13. Chris Marrin <cmarrin@apple.com>
  14. Charles McCathie Nevile <chaals@yandex-team.ru>
  15. Philippe Le Hégaret <plh@w3.org>
  16. Don Brutzman <brutzman@nps.edu>
  17. T.V. Raman <raman@google.com>
  18. David Singer <singer@apple.com>
  19. Cynthia Shelly <cyns@microsoft.com>
  20. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  21. Sean Hayes <sean.hayes@microsoft.com>
  22. Karl Dubost <karl@la-grange.net>
  23. Larry Masinter <masinter@adobe.com>
  24. Ian Hickson <ian@hixie.ch>
  25. David Baron <dbaron@dbaron.org>
  26. Lisa Seeman <lisa.seeman@zoho.com>
  27. Paul Cotton <Paul.Cotton@microsoft.com>
  28. Shane McCarron <shane@aptest.com>
  29. wu chou <wu.chou@huawei.com>
  30. Katsuhiko Momoi <momoi@google.com>
  31. Kangchan Lee <chan@w3.org>
  32. Roy Fielding <fielding@gbiv.com>
  33. Silvia Pfeiffer <silviapfeiffer1@gmail.com>
  34. Johnny Stenback <jst@mozilla.com>
  35. Janina Sajka <janina@rednote.net>
  36. Deborah Dahl <dahl@conversational-technologies.com>
  37. Michael Cooper <cooper@w3.org>
  38. Glenn Adams <glenn@skynav.com>
  39. Jonathan Jeon <hollobit@etri.re.kr>
  40. David Hyatt <hyatt@apple.com>
  41. Robin Berjon <robin@w3.org>
  42. WonSuk Lee <wonsuk.lee@etri.re.kr>
  43. Maciej Stachowiak <mjs@apple.com>
  44. Robert Accettura <robert@accettura.com>
  45. Jonathan Watt <jwatt@jwatt.org>
  46. Steve Faulkner <faulkner.steve@gmail.com>
  47. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  48. Patrick Lauke <redux@splintered.co.uk>
  49. David MacDonald <David100@sympatico.ca>
  50. Jack Jansen <jack@cwi.nl>
  51. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  52. Markku Hakkinen <mhakkinen@ets.org>
  53. Cyril Concolato <cyril.concolato@telecom-paristech.fr>
  54. Gez Lemon <glemon@paciellogroup.com>
  55. Pasquale Popolizio <p.popolizio@webprofession.com>
  56. Luca Mascaro <l.mascaro@webprofession.com>
  57. Markus Mielke <mmielke@microsoft.com>
  58. Arun Ranganathan <arun@mozilla.com>
  59. Jens Meiert <jens@meiert.com>
  60. Felix Sasaki <fsasaki@w3.org>
  61. Kazuyuki Ashimura <ashimura@w3.org>
  62. Daniel Burnett <dburnett@voxeo.com>
  63. Tomas Caspers <tomas@tomascaspers.de>
  64. Han Xu <collin@w3china.org>
  65. Sam Ruby <rubys@intertwingly.net>
  66. Jonas Sicking <jonas@sicking.cc>
  67. Doug Schepers <schepers@w3.org>
  68. Ian Fette <ifette@google.com>
  69. Michael[tm] Smith <mike@w3.org>
  70. Julian Reschke <julian.reschke@gmx.de>
  71. Kelly Ford <kelly.ford@microsoft.com>
  72. Cameron McCormack <cam@mcc.id.au>
  73. Jirka Kosek <jirka@kosek.cz>
  74. Robert O'Callahan <robert@ocallahan.org>
  75. Travis Leithead <Travis.Leithead@microsoft.com>
  76. Youngsun Ryu <ysryu@samsung.com>
  77. Sierk Bornemann <sierkb@gmail.com>
  78. Martijn Wargers <martijn.martijn@gmail.com>
  79. Simon Pieters <simonp@opera.com>
  80. James Graham <james@hoppipolla.co.uk>
  81. Lachlan Hunt <lachlan.hunt@lachy.id.au>
  82. Krijn Hoetmer <w3c@qontent.nl>
  83. Markus Fischer <markus@fischer.name>
  84. Dean Edridge <dean@dean.kiwi>
  85. Channy Yun <channy@gmail.com>
  86. Shane Thacker <shanethacker@gmail.com>
  87. Bill Mason <billm@accessibleinter.net>
  88. Vilem Malek <murphy@malek.cz>
  89. Zhihong Mao <zhihong.mao@gmail.com>
  90. Benoit Piette <benoit.piette@gmail.com>
  91. Erik van Kempen <erikvankempen@gmail.com>
  92. Jude Robinson <dotcode+w3@gmail.com>
  93. Dimitri Glazkov <dglazkov@google.com>
  94. Diego La Monica <d.lamonica@webprofession.com>
  95. Nick Fitzsimons <w3@nickfitz.co.uk>
  96. Josh Lawton <w3c@joshlawton.com>
  97. Giovanni Gentili <giovanni.gentili@gmail.com>
  98. Adele Peterson <adele@apple.com>
  99. S Emerson <w3c@accretewebsolutions.ca>
  100. Morten Tollefsen <morten@medialt.no>
  101. Daniel Schattenkirchner <schattenkirchner.daniel@gmx.de>
  102. Edward O'Connor <eoconnor@apple.com>
  103. Justin Anthony Knapp <justinkoavf@gmail.com>
  104. Simon Myers <Smylers@stripey.com>
  105. Samuel Weinig <weinig@apple.com>
  106. Alexey Proskuryakov <ap@webkit.org>
  107. Alejandro Fernandez <alejandro@mediadvanced.com>
  108. Doug Jones <doug_b_jones@me.com>
  109. Marc Drumm <mdrumm@wcupa.edu>
  110. Danny Liang <danny.glue@gmail.com>
  111. Arne Johannessen <arne@thaw.de>
  112. Michael Puls II <shadow2531@gmail.com>
  113. Ron Reisor <ron@udel.edu>
  114. Marat Tanalin <mtanalin@yandex.ru>
  115. Andrew Norman <idonothaveacat@gmail.com>
  116. Craig Buckler <craigbuckler@gmail.com>
  117. Matthew Turvey <mcturvey@gmail.com>
  118. Dale Hudjik <dale.hudjik@gmail.com>
  119. James Cassell <w3c@cyberpear.com>
  120. Joseph D'Andrea <jdandrea@gmail.com>
  121. Pietro Russo <p.russo@webprofession.com>
  122. Moto Ishizawa <summerwind.jp+w3c@gmail.com>
  123. Chris Adams <chris@tuesdaybegins.com>
  124. Eric Carlson <eric.carlson@apple.com>
  125. Michael Turnwall <w3c@turnwall.net>
  126. Don Kiely <donkiely@computer.org>
  127. Robert Marshall <rdm@rdmsoft.com>
  128. Jane Lee <applegoddess@gmail.com>
  129. David Child <dave@addedbytes.com>
  130. Mark DuBois <Mark@webprofessionals.org>
  131. David Choi <daaave@gmail.com>
  132. David Bills <w3@dfbills.com>
  133. Nik Thierry <me@thisemail.ca>
  134. Andrew Ramsden <andrew@irama.org>
  135. John Foliot <john.foliot@deque.com>
  136. Shefik Macauley <allknightaccess@gmail.com>
  137. Joe Steele <steele@adobe.com>
  138. John Vernaleo <john@netpurgatory.com>
  139. Jeremy Keith <jeremy@adactio.com>
  140. Jedi Lin <JediLin@Gmail.com>
  141. Kenny Johar <kensingh@microsoft.com>
  142. Jon Hughes <jon@phazm.com>
  143. Anssi Kostiainen <anssi.kostiainen@intel.com>
  144. Samuel Santos <samaxes@gmail.com>
  145. Dean Jackson <dino@apple.com>
  146. Mohammed DADAS <mohammed.dadas@orange.com>
  147. Sally Cain <sally.cain@rnib.org.uk>
  148. Dan Romascanu <dromasca@avaya.com>
  149. Chris Double <cdouble@mozilla.com>
  150. Jeanne F Spellman <jeanne@w3.org>
  151. James Craig <jcraig@apple.com>
  152. MING JIN <ming.jin.web@gmail.com>
  153. Leonard Rosenthol <lrosenth@adobe.com>
  154. Philip Jägenstedt <philipj@opera.com>
  155. Adrian Bateman <adrianba@microsoft.com>
  156. Dionysios Synodinos <synodinos@gmail.com>
  157. Jean-Pierre EVAIN <evain@ebu.ch>
  158. Mark Pilgrim <pilgrim@google.com>
  159. Matt Lee <mattl@cnuk.org>
  160. Magnus Olsson <magnus.olsson@ericsson.com>
  161. Chris Pearce <cpearce@mozilla.com>
  162. Dzung Tran <dzung.d.tran@intel.com>
  163. Mark Miller <erights@google.com>
  164. Andrew Wilson <atwilson@google.com>
  165. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  166. Ojan Vafai <ojan@chromium.org>
  167. Martin Kliehm <w3c@kliehm.com>
  168. Martin McEvoy <martin@weborganics.co.uk>
  169. Aryeh Gregor <ayg@aryeh.name>
  170. Gavin Carothers <gavin@carothers.name>
  171. Eliot Graff <eliotgra@microsoft.com>
  172. Frank Olivier <frank.olivier@microsoft.com>
  173. Jonathan Griffin <jgriffin@mozilla.com>
  174. Kris Krueger <krisk@microsoft.com>
  175. Erik Isaksen <erik_isaksen@hotmail.com>
  176. Daniel Davis <ddavis@w3.org>
  177. Anders Bondehagen <anders@bondehagen.com>
  178. Steven Pemberton <Steven.Pemberton@cwi.nl>
  179. Raul Hudea <rhudea@adobe.com>
  180. Raghavan Gurumurthy <raghavan@adobe.com>
  181. Mayank Kumar <mayankk@adobe.com>
  182. Monikandan S <smonikan@adobe.com>
  183. Dragos Georgita <dgeorgit@adobe.com>
  184. Christopher Bank <cbank@adobe.com>
  185. Dominik Tomaszuk <ddooss@wp.pl>
  186. Ole Riesenberg <or@oleriesenberg.com>
  187. Takuya Oikawa <takuya@google.com>
  188. Jatinder Mann <jmann@microsoft.com>
  189. Robert Stern <rstern@gmail.com>
  190. Dean Leigh <dean.leigh@deanleigh.co.uk>
  191. Eihab Ibrahim <eihabibrahim@gmail.com>
  192. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  193. Ian Pouncey <w3c@ipouncey.co.uk>
  194. Jer Noble <jer.noble@apple.com>
  195. Léonie Watson <lwatson@paciellogroup.com>
  196. Masatomo Kobayashi <mstm@jp.ibm.com>
  197. Grant Simpson <glsimpso@gmail.com>
  198. Peter Beverloo <beverloo@google.com>
  199. Andrew Scherkus <scherkus@google.com>
  200. Greg Johnson <greg.johnson@gmail.com>
  201. Martijn Croonen <martijn@martijnc.be>
  202. John Jansen <johnjan@microsoft.com>
  203. Stanley Manoski <manoski@mitre.org>
  204. Jonas Schneider <js.sokrates@gmail.com>
  205. Yosuke Funahashi <yosuke@w3.org>
  206. Mounir Lamouri <mlamouri@google.com>
  207. Mike Amundsen <mamund@yahoo.com>
  208. Tony Gentilcore <tonyg@google.com>
  209. Jacob Rossi <Jacob.Rossi@microsoft.com>
  210. Joseph Pecoraro <pecoraro@apple.com>
  211. Othmane Benyoucef <othmane_benyoucef@hotmail.com>
  212. Shoko Okuma <okuma@tomo-digi.co.jp>
  213. Fumitaka Watanabe <fwtnb@tomo-digi.co.jp>
  214. Yoshimitsu Tsurimaki <tsurimaki@tomo-digi.co.jp>
  215. Bob Lund <b.lund@cablelabs.com>
  216. Tatsuya Igarashi <Tatsuya.Igarashi@jp.sony.com>
  217. John Simmons <johnsim@microsoft.com>
  218. Mathias Bynens <mathias@qiwi.be>
  219. Mark Watson <watsonm@netflix.com>
  220. Clarke Stevens <c.stevens@cablelabs.com>
  221. Mark Vickers <mark_vickers@cable.comcast.com>
  222. Sree Kotay <Sree_Kotay@cable.comcast.com>
  223. Cameron Jones <cmhjones@gmail.com>
  224. Rik Cabanier <Cabanier@adobe.com>
  225. Jeremy LaCivita <jeremy.lacivita@theplatform.com>
  226. Denis Ah-Kang <denis@w3.org>
  227. Alvar Laigna <laigna@gmail.com>
  228. Kunio Ito <kunio.ito@mail.rakuten.com>
  229. David Mays <david_mays@comcast.com>
  230. Michael Chen <michael_chen@cable.comcast.com>
  231. jongyoul Park <jongyoul@etri.re.kr>
  232. Adrian Roselli <roselli@algonquinstudios.com>
  233. Colin Ihrig <cjihrig@gmail.com>
  234. Kilroy Hughes <kilroy.hughes@microsoft.com>
  235. Reinaldo Ferraz <reinaldo@nic.br>
  236. Bill Mandel <bill.mandel@nbcuni.com>
  237. Jonas Jacek <w3c@jonas.me>
  238. Eva Lingyun Jing <jinglingyun@baidu.com>
  239. GANG LIANG <gang.liang@huawei.com>
  240. Ryosuke Niwa <rniwa@apple.com>
  241. Jason Kiss <jason@accessibleculture.org>
  242. Gian Luca Marroni <gmarroni@libero.it>
  243. Ian Devlin <ian@iandevlin.com>
  244. Greg Billock <gbillock@google.com>
  245. Xingrong Guo <guoxingrong@baidu.com>
  246. Jet Villegas <w3c@junglecode.net>
  247. Alexander Surkov <surkov.alexander@gmail.com>
  248. Hasan Savran <hsavran@kent.edu>
  249. Ben Dalton <bendalton@gmail.com>
  250. Marco Kotrotsos <Marco@mlabs.nl>
  251. Brian Blakely <anewpage.media@gmail.com>
  252. Eric VonColln <eric.voncolln@navy.mil>
  253. Jason Boyd <jason@pixelboxdesign.co.uk>
  254. Jerry Jiang <jerry@ucweb.com>
  255. Jungkee Song <jungkee.song@samsung.com>
  256. Huan Ren <renhuan@360.cn>
  257. Xitong Huang <stonehuang@tencent.com>
  258. Rayi Lei <leiyi@baidu.com>
  259. Daniel Austin <daniel.austin@grintech.net>
  260. David Dorwin <ddorwin@google.com>
  261. jiexuan gao <gaojiexuan@baidu.com>
  262. Mathew Marquis <mat@matmarquis.com>
  263. Xiaoqing Yang <yangxiaoqing@baidu.com>
  264. Aaron Colwell <acolwell@google.com>
  265. Alex Giladi <alex.giladi@huawei.com>
  266. Motomasa Futagami <Motomasa.Futagami@jp.sony.com>
  267. Kevin Streeter <kstreete@adobe.com>
  268. Christian Kaiser <kaiserc@google.com>
  269. François REMY <francois.remy.dev@outlook.com>
  270. Xuejian Li <lixuejian@baidu.com>
  271. Zuncheng Yang <yangzuncheng@baidu.com>
  272. Qianglong Zheng <zhengqianglong@baidu.com>
  273. Zhou Shen <shenzhou@baidu.com>
  274. Duoyi Wu <wuduoyi@baidu.com>
  275. Zheng Jia <jiazheng@baidu.com>
  276. Weifeng Feng <fengweifeng@baidu.com>
  277. Damin Hu <hudamin@baidu.com>
  278. Yang Liu <liuyang12@baidu.com>
  279. Zhixing Lei <leizhixing@baidu.com>
  280. Honggang Tang <tanghonggang@baidu.com>
  281. Kefeng Li <buaadallas@gmail.com>
  282. Xu Ma <maxu@baidu.com>
  283. Junzhong Liu <liujunzhong@baidu.com>
  284. Yusuke Maehama <maehama@tomo-digi.co.jp>
  285. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  286. Sheau Ng <Sheau.ng@nbcuni.com>
  287. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  288. Ami Fischman <fischman@google.com>
  289. Arnaud Braud <arnaud.braud@orange.com>
  290. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  291. Bram Tullemans <tullemans@ebu.ch>
  292. Petr Peterka <ppeterka@verimatrix.com>
  293. lei wang <wanglei03@baidu.com>
  294. Milan Patel <Milan.Patel@huawei.com>
  295. Yiling Gu <guyiling@baidu.com>
  296. Yehuda Katz <wycats@gmail.com>
  297. Xueqing Huang <huangxueqing@baidu.com>
  298. Zefa Xiong <xiongzefa@baidu.com>
  299. shanglin chen <chenshanglin@baidu.com>
  300. Yaso Córdova <yaso@nic.br>
  301. Dongsheng Zhang <zhangdongsheng@baidu.com>
  302. Ping Wu <wuping02@baidu.com>
  303. Yao Tong <tongyao@baidu.com>
  304. Bin Chen <chenbin01@baidu.com>
  305. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  306. Patrick Ladd <Pat_Ladd2@cable.comcast.com>
  307. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  308. Billy Gregory <bgregory@paciellogroup.com>
  309. Hanrui Gao <gaohanrui@360.cn>
  310. Hao Jing <jh.jinghao@huawei.com>
  311. Glenn Deen <glenn.deen@nbcuni.com>
  312. Lei Wang <wanglei@baidu.com>
  313. Tom Handal <thandal@verimatrix.com>
  314. Tsutomu Ogasawara <tsutomu.ogasawara@mail.rakuten.com>
  315. Jose Segura <jose.segura@mail.rakuten.com>
  316. Pengcheng Guo <guopengcheng@baidu.com>
  317. Erika Doyle Navara <erika.doyle@microsoft.com>
  318. Tom Wiltzius <wiltzius@google.com>
  319. Pierre-Anthony Lemieux <pal@sandflow.com>
  320. Xie Jianhui <xiejianhui@baidu.com>
  321. Yujie Jiang <jiangyujie@baidu.com>
  322. Leslie Sikos <sikos@sikoswebconsulting.com.au>
  323. Mark Sadecki <mark.sadecki+w3c@gmail.com>
  324. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  325. Brady Eidson <beidson@apple.com>
  326. Reimundo Garcia <reimundo.garcia@hbo.com>
  327. Jerry Smith <jdsmith@microsoft.com>
  328. Michael Thornburgh <mthornbu@adobe.com>
  329. Cyril Rickelton-Abdi <cyril.rickelton-abdi@turner.com>
  330. Andrew Davis <andrew@diff.mx>
  331. Mick Hakobyan <mhakobyan@netflix.com>
  332. Mallory van Achterberg <stommepoes@stommepoes.nl>
  333. Vladimir Sinelnikov <sinelnikov@gmail.com>
  334. Chris Wong <huanghoujin@baidu.com>
  335. Yiliang LIU <liuyiliang@baidu.com>
  336. Hernan Beati <hernanbeati@gmail.com>
  337. mingqiang zhang <imcnan@gmail.com>
  338. yubo zhou <zhouyubo@360.cn>
  339. Ben Barber <barberboy@gmail.com>
  340. Matt Rakow <marakow@microsoft.com>
  341. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  342. Grzegorz Babula <gbabula@gmail.com>
  343. Brian Kardell <hitchjs@gmail.com>
  344. xueliang fan <fanxueliang@baidu.com>
  345. Niels Thorwirth <nthorwirth@verimatrix.com>
  346. David Evans <david.evans@rd.bbc.co.uk>
  347. Danny O'Brien <danny@eff.org>
  348. Joseph Karr O'Connor <josephoconnor@mac.com>
  349. Seth Schoen <schoen@eff.org>
  350. Jamil Ellis <jamil.ellis@hbo.com>
  351. Jim Walsh <jim@jwalshcreative.com>
  352. Greg Davis <greg.davis@pearson.com>
  353. Gabino Alonso <gabinovincent@gmail.com>
  354. Sam Langdon <sam.langdon@hachette.co.uk>
  355. Michael Kelly <mkelly@mozilla.com>
  356. Xiaoqian Wu <xiaoqian@w3.org>
  357. Yue Min <minyue@baidu.com>
  358. Min Li <limin04@baidu.com>
  359. A.S. Krishnakumar <ask@avaya.com>
  360. Shijun Sun <shijuns@microsoft.com>
  361. Jonathan Neal <jonathantneal@gmail.com>
  362. Joanmarie Diggs <jdiggs@igalia.com>
  363. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  364. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  365. Tetsushi Matsuda <Matsuda.Tetsushi@dh.MitsubishiElectric.co.jp>
  366. So Vang <svang@nab.org>
  367. Nathalia Sautchuk Patrício <nathalia@nic.br>
  368. Deblyn prado <deblyn@nic.br>
  369. Vicente García Díaz <vicegd@live.com>
  370. Nolan Butcher <nolan.butcher@hbo.com>
  371. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  372. RAVI CHANDRA RAVULAPATI <ravichandra480@gmail.com>
  373. John Riviello <john_riviello@comcast.com>
  374. yaolong wang <wangyaolong@baidu.com>
  375. Shun-ichi Sekiguchi <Sekiguchi.Shunichi@eb.MitsubishiElectric.co.jp>
  376. Tao Liang <liangtao01@baidu.com>
  377. Glenn Eguchi <geguchi@adobe.com>
  378. Hirofumi Nishikawa <Nishikawa.Hirofumi@cs.MitsubishiElectric.co.jp>
  379. Hiroyuki Yamada <Yamada.Hiroyuki@dn.MitsubishiElectric.co.jp>
  380. Chockalingam Muthian <chockam@gmail.com>
  381. Lukáš Čihák <lukas.cihak@mensa.cz>
  382. Anatoly Shikolay <shikolay@gmail.com>
  383. WOOGLAE KIM <wlkim@inswave.com>
  384. Min Ren <minren@tencent.com>
  385. Rustam Khashimkhodjaev <Rustam_Khashimkhodjaev@cable.comcast.com>
  386. Brian Evans <Brian.Evans@microsoft.com>
  387. Jason White <jjwhite@ets.org>
  388. Hyejin Lee <hjlee@html5forum.or.kr>
  389. Richard Grzeczkowski <richard_grzeczkowski@cable.comcast.com>
  390. Pascal Perrot <pascal.perrot@orange.com>
  391. Dongseong Hwang <dongseong.hwang@intel.com>
  392. Matthew Wolenetz <wolenetz@google.com>
  393. Cory Heslip <cory_heslip@cable.comcast.com>
  394. Shaohang Yang <shaohang.ysh@alibaba-inc.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.127 2015-02-04 08:52:34 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)