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.


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.


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

  • Tab Atkins Jr.: last responded on 17, July 2012 at 22:32 (UTC)
  • Boris Zbarsky: last responded on 18, July 2012 at 08:04 (UTC)
  • Henri Sivonen: last responded on 18, July 2012 at 09:22 (UTC)
  • David Bolter: last responded on 18, July 2012 at 15:39 (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. David Singer <singer@apple.com>
  16. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  17. Karl Dubost <karl@la-grange.net>
  18. Ian Hickson <ian@hixie.ch>
  19. Wu Chou <wu.chou@huawei.com>
  20. Katsuhiko Momoi <momoi@google.com>
  21. Kangchan Lee <chan@w3.org>
  22. Roy Fielding <fielding@gbiv.com>
  23. Deborah Dahl <dahl@conversational-technologies.com>
  24. Michael Cooper <cooper@w3.org>
  25. Glenn Adams <glenn@skynav.com>
  26. Jonathan Jeon <hollobit@etri.re.kr>
  27. David Hyatt <hyatt@apple.com>
  28. WonSuk Lee <wonsuk.lee@etri.re.kr>
  29. Maciej Stachowiak <mjs@apple.com>
  30. Robert Accettura <robert@accettura.com>
  31. Jonathan Watt <jwatt@jwatt.org>
  32. Steve Faulkner <faulkner.steve@gmail.com>
  33. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  34. Patrick Lauke <redux@splintered.co.uk>
  35. David MacDonald <David100@sympatico.ca>
  36. Jack Jansen <jack@cwi.nl>
  37. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  38. Markku Hakkinen <mhakkinen@ets.org>
  39. Jens Oliver Meiert <jens@meiert.com>
  40. Kazuyuki Ashimura <ashimura@w3.org>
  41. Han Xu <collin@w3china.org>
  42. Sam Ruby <rubys@intertwingly.net>
  43. Mark Crawford <mark.crawford@sap.com>
  44. Preety Kumar <preety.kumar@deque.com>
  45. Ian Fette <ifette@google.com>
  46. Cameron McCormack <cam@mcc.id.au>
  47. Stefan Schnabel <stefan.schnabel@sap.com>
  48. Jirka Kosek <jirka@kosek.cz>
  49. Travis Leithead <Travis.Leithead@microsoft.com>
  50. Youngsun Ryu <ysryu@samsung.com>
  51. Sierk Bornemann <sierkb@gmail.com>
  52. James Graham <james@hoppipolla.co.uk>
  53. Krijn Hoetmer <w3c@qontent.nl>
  54. Channy Yun <channy@gmail.com>
  55. Shane Thacker <shanethacker@gmail.com>
  56. Vilem Malek <murphy@malek.cz>
  57. Zhihong Mao <zhihong.mao@gmail.com>
  58. Benoit Piette <benoit.piette@gmail.com>
  59. Erik van Kempen <erikvankempen@gmail.com>
  60. Dimitri Glazkov <dglazkov@google.com>
  61. Nick Fitzsimons <w3@nickfitz.co.uk>
  62. Josh Lawton <w3c@joshlawton.com>
  63. S Emerson <w3c@accretewebsolutions.ca>
  64. Theresa O'Connor <eoconnor@apple.com>
  65. Justin Anthony Knapp <justinkoavf@gmail.com>
  66. Simon Myers <Smylers@stripey.com>
  67. Samuel Weinig <weinig@apple.com>
  68. Alexey Proskuryakov <ap@webkit.org>
  69. Alejandro Fernandez <alejandro@mediadvanced.com>
  70. Doug Jones <doug_b_jones@me.com>
  71. Marc Drumm <mdrumm@wcupa.edu>
  72. Danny Liang <danny.glue@gmail.com>
  73. Michael Puls II <shadow2531@gmail.com>
  74. Ron Reisor <ron@udel.edu>
  75. Craig Buckler <craigbuckler@gmail.com>
  76. Dale Hudjik <dale.hudjik@gmail.com>
  77. James Cassell <w3c@cyberpear.com>
  78. Joseph D'Andrea <jdandrea@gmail.com>
  79. Eric Carlson <eric.carlson@apple.com>
  80. Don Kiely <donkiely@computer.org>
  81. David Child <dave@addedbytes.com>
  82. Mark DuBois <Mark@webprofessionals.org>
  83. David Bills <w3@dfbills.com>
  84. Nik Thierry <me@thisemail.ca>
  85. Andrew Ramsden <andrew@irama.org>
  86. John Foliot <john.foliot@deque.com>
  87. Shefik Macauley <allknightaccess@gmail.com>
  88. Joe Steele <steele@adobe.com>
  89. John Vernaleo <john@netpurgatory.com>
  90. Jeremy Keith <jeremy@adactio.com>
  91. Jedi Lin <JediLin@Gmail.com>
  92. Jon Hughes <jon@phazm.com>
  93. Samuel Santos <samaxes@gmail.com>
  94. Dean Jackson <dino@apple.com>
  95. Mohammed DADAS <mohammed.dadas@orange.com>
  96. Sally Cain <sally.cain@rnib.org.uk>
  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.