Results of Questionnaire ISSUE-144: Make "u" element conforming - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-03-27 to 2011-04-04.

9 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal to make the "u" element conforming.
  2. Objections to the Change Proposal for no change there are no new use cases

1. Objections to the Change Proposal to make the "u" element conforming.

We have a Change Proposal to make the "u" element conforming. 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 make the "u" element conforming.
Silvia Pfeiffer
John Foliot
Laura Carlson The <u> element causes confusion and poor readability [1].

Users expect underlined text to be hyperlinks. Underlines are calls to action. Pretty much everyone has gotten into the idea that "underline = link".

"...users are trained to click on underlined things...Many people who use the web for a long time start to become conditioned to look for underlines. If you watch them with an eye tracker, you can see their focus dart from underlined-text to underlined-text when they first see a page." [2]

Making the "u" element conforming would encourage underlining text that is not a link. Underlining text that is not linked confuses and frustrates users who are trying to make their way around a website as they will click on underlines that are not links and go nowhere. It is bad usability.

Authors should not underline non-link text [3] [4]. "Users shouldn't have to guess or scrub the page to find out where they can click." [5] [6]

Underlining cuts through the descenders of some text characters, which can interfere with on-screen readability. Underlining text can clutter and make reading difficult.

Preserving underlines exclusively for use on links is particularly important for people with low vision [7], color blindness, and monochrome displays.

Making the "u" element non-conforming would help users.

[1] http://www.d.umn.edu/~lcarlson/demos/u.html
[2] http://www.uie.com/brainsparks/2006/07/05/do-links-need-underlines/
[3] http://www.usability.gov/articles/newsletter/pubs/052007news.html
[4] http://webstyleguide.com/wsg3/8-typography/5-typographic-emphasis.html
[5] http://www.useit.com/alertbox/designmistakes.html
[6] http://www.useit.com/alertbox/20040510.html
[7] http://www.useit.com/alertbox/20040510.html
Tab Atkins Jr. I object to making the <u> element conforming, for the reasons listed in the counter proposal - <u> has no new use-cases, use of <u> is often confusing with use of <a>, and making <u> conforming without making several other presentational elements conforming is inconsistent.
Aryeh Gregor
Leif Halvard Silli
I may have weak objection against the proposed text depending on the following two factors:

1. The use cases of Chinese proper noun marks[1] do /exist/. But whether they should be addressed by the <u> element is a separate issue without consensus. Some people feel strong about it[2], but most people don't.

2. Whether the HTML WG excludes ebooks as a factor that drives the development of HTML5, as the proper noun marks are only significant in ebooks.

As a solution to my concern, perhaps the editor should consider separating the definition of <b>, <i>, <u> from their use cases, as proposed in [3] (that was considered by the WG as out of the scope of this issue).

Nitpicking on Aryeh Gregor's objection:

WikiMedia doesn't provide a button for underlining text, but that's the only one I've ever seen.

[1] http://www.w3.org/html/wg/wiki/UseCasesOfUElement
[2] http://littlepotato.webfreehosting.net/html-u-removal.php
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12178
Ian Hickson The length savings argument is bogus because the alternative to <u> is not <span style="blablabla"> but simple an appropriate semantic element. Which element is appropriate depends on the use case; for the suggested use case in the proposal -- stylistic offset -- there is already an element, namely <i>, which is not any longer at all.

The fact that many tools use <u> is insufficient; many tools use all kinds of presentational markup. Authoring conformance criteria have to be forward-looking, as they set the stage for the world's best practices going forward. The best practice (for accessibility, maintainability, and semantic analysis) is widely recognised to be the separation of semantics and styles, which argues against presentational markup such as in this proposal.

The proposed text suggests that marking misspelled words and proper nouns in Chinese are important enough use cases to have an element for them, but it appears that underlining proper nouns in Chinese happens on the Web only on Wikipedia pages that talk about underlining proper nouns (where the use of <u> is actually a side-effect of the {{du}} double-underline template which actually uses a CSS border-bottom style to achieve the effect, and where <u> is therefore not really a full solution anyway), and underlining misspelt words is something that isn't typically usefully done using an HTML element in static markup (it's usually done from script, and doesn't use the same style as <u>'s default style).

The main problem with this proposal is simply lack of use cases. We can already achieve an underline effect using CSS; HTML is a media-independent semantic markup language and no realistic media-independent semantic use case has been proposed for the U element.

Further counter-arguments to some arguments given in response to this poll are listed here and included by reference:
Theresa O'Connor

2. Objections to the Change Proposal for no change there are no new use cases

We have a Change Proposal to make no change because there are no new use cases that require the "u" element to be conforming.

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 for no change there are no new use cases
Silvia Pfeiffer I feel we are being overly pure in our design approach when removing the "u" element. "u" is always mentioned in one breath with "i" and "b" - and italics, bold and underline have for centuries been different means to express emphasis for type setting. We've tried artificially to put a semantic meaning to them and in a Web environment the underline certainly often indicates a hyperlink. But it doesn't always. It feels arbitrary to try to control this situation and "hand-wrestle" the author into not using underlines for other purposes by removing this element.
John Foliot I object to this Change Proposal on the following grounds:

* Removing the <u> breaks backward compatibility, allegedly one of the key design principles of HTML5:
"We don’t need to predict the future. When the future comes, we can just fix HTML again. It’s more important that HTML caters to the present than to the future." - Ian Hickson

* This Change Proposal has no factual evidence provided to support any of it's assertions - it simply presumes that a majority are in agreement with the editor's assertions. No proof has been offered to show that removing the <u> element will benefit users, authors or implementors.

* This Change Proposal asserts: "Inconsistent application of rationales leads to very poor language design" - yet HTML5 continues to support both <b> and <i> (both also presentational elements). If <b> and <i>, why not <u>?

* This Change Proposal does nothing to address the real concerns and points raised in the alternative Change Proposal to this issue, simply dismissing them as "too edge-case". The fact that they have been raised by others at this time serves to counter that claim - the issues are significant enough that they must be resolved somehow. This Change Proposal provides no relief here.

* Transitioning authors away from using <u> for purely presentational effects should be an educational effort; evolution not revolution - http://www.w3.org/TR/html-design-principles/#evolution-not-revolution
Laura Carlson
Tab Atkins Jr.
Aryeh Gregor Because the system rejected my objection due to length, I've posted it to www-archive instead:

Leif Halvard Silli I object to making <u> non-conforming.

Regarding the confusement argument.
* If a underlined text which is not a hyperlink confuses the user, then we also need to remove the text-decoration:underline property of CSS.
* if we investigate the claimed usability problem, then links are usully colored blue, thus users usually do not mix anything unless they are colorblind or use a user agent without color support. But no-one has suggested to remove the ability to use the color blue for other things than links either ... But even blind users are also able to separate a link from a non-link, despite that they don't see whether color or underline. This is because of a link interactively changes featurs when the pointing device hovers or click a link. In contrast a <u> is completely dead, unles the author actively adds u:hover{style:foo}.
* <u> is permitted today, in HTML4, and there is no reason to think there will be a halleluia and a rush to use <u> just because HTML5 permits it.

Regarding the "if we do this, then we also need to do that" argument.
* I agree that if we accept <u>, then we have less reason to not accept <tt> too. However, I have no problem with accepting the <center>, <tt>, aliign="" etc. I'd prefer that we did. And there seems to be usecases. For instance, www.google.com does use <center>, despite having switched to the HTML5 doctype. Don't know their justificaiton, but this allows my text browser to perceive their homepage as centered text. Brilliant.
* I have never heard arguments against stylistic markup and stylistic attributes when it comes to SVG. But when it comes to HTML, then there are all kinds of purity arguments with regard to which elements to use.
* <u> is just a synonym to <span>. That's all. The <center> element is a synonym of <div>. Heck, even <table role="presentation"> is a kind of synonym to <div> ... If we see <u> and <tt> simply as synonyms of <span>, then what reasons is there to avoid <u> other than not wanting underline text as the styling default? This is a clear route for allowing many of the features Ian mentions: just define those features as synonyms of more general features. One must of course look at each element and attribute case by case, but this makes full sense to me.

Regarding this CP's lack of consideration of the author practicality argument:
* <u>U</u> is quicker to use than even <span class="u">u</span>. What's wrong with being easy to use? What's wrong with being able to see the purpose of the element from its name rather than having to look at how one, in one's CSS, has styled the .u class?
* I can see that while CSS was in its infancy, then it made sense to push authors to use CSS. But these days authors know that they can, if needed, style away the underline style of the <u>, if we don't need it.
* I also remember from, precisely CSS's infancy that I read the homepage of a Web developer who proudly said that his page worked in both CSS-supporting user agent as well as those that do not support CSS. There may be less need to cater for CSS-less user agents today, however Ian Hickson nevertheless often do point to those useragents!

Regarding legacy user agents etc.
* Precicely UAs not supporting CSS is a reason to keep <u> as valid as this allow such user agents to display underline even without CSS support
* <u> also allows authors to use underline as a "fallback styling" for CSS-less useragents. Here is an example of this:
<u style="text-decoration:none;color:green">Ian Hickson</u>
A GUI browser would display that in green color but without undeline text, while the less capatble text browser might display it with underline.

Regarding "consistently applied rationale" and what HTMLwg members are willing to do:
* The CP states:
]] yet nobody is making such a case,
suggesting that this rationale is not being consistently applied.
Inconsistent application of rationales leads to very poor language design,
confusing authors ("why is X possible but not the almost identical Y?"
is a common question in such cases). [[
However, some would claim that this confusement is already present in the spec. For example why is it permitted to use @name every place HTML4 allows it but not in <a name>?
Further more, several *are* actually open to allowing many more socalled "non-semantic" (more correctly: style-semantic) elements. If someone would produce a list of all these legacy features, then I would have allowed most of those that were permitted in HTML4, and there is much evidence suggesting that I am not alone.
Fundamentally, I think having <b>, <i> but not <u> is a better inconsistency then the inconsistency of where use cases are strong or not (it gives normal Web authors a big surprise), so I don't think any argument based on consistency applies.

I strongly object to the positive effect section. Deprecating <u> won't help Web authors migrate <u>s to other semantic markup as text-level semantic elements are very hard to choose from (what's the difference between <em> and <strong>?), while deprecating <center> has a value because the section can be main content (no markup), or <section>/<header>/<footer>/etc.

The first paragraph of Ian Hickson's objection is far from accurate as (even theoretically) the solution with minimum length is <i class="u"> because in a contemporary Chinese page, italic text representing alternative voice or whatever and proper noun marks can be used in the same paragraph and there needs to be a way to distinguish between the two. Practically, it is hard to imagine an authoring UA outputting <i> for the use cases of proper nouns as this is not backward compatible with non-CSS user agents and it is too arbitrary to decide on <i> when both <b> and <i> have the rather broad "stylistic offset" semantics. See [1] for an example of using <b> for this use case. (Also, <i> was defined in HTML4 as a presentational element and using the new semantics will break backward compatibility of a semantic user agent, if ever exists).

I'll let the working group read [1] and decide if we should address the use cases of proper noun marks in HTML5.

I have certain sympathy about the readability argument, but please note that the proper noun mark was introduced a long time before Web was invented.

Response to paragraph 3 in Ian Hickson's objection:

I don't know what {{du}} is there for, but the Chinese entry uses a normal <u>. I agree that using <u> to address this use case has no consensus, although <u> seems to be the most natural if it is conforming of course.

<small>Side comments: the working group should try to collect data on whether <b>, <i> are already recognized as semantic elements and whether they are really styled differently in existing pages. Otherwise, the working group should consider the suggestion 3 of [2].</small>

[1] http://www.w3.org/html/wg/wiki/UseCasesOfUElement
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12178
Ian Hickson
Theresa O'Connor WYSIWYG HTML editors often have bold, italic, and underline buttons. Such UI elements should generate <b>, <i>, and <u>, and indeeed WebCore Editing generates such markup in these cases.

The fact that underlining is confusing on the Web due to default link styling is not an argument against the <u> element, it's an argument against underlining. Making <u> invalid doesn't prevent Web authors from underlining things; they can use text-decoration for that.

More details on responses

  • Silvia Pfeiffer: last responded on 27, March 2011 at 15:11 (UTC)
  • John Foliot: last responded on 27, March 2011 at 18:55 (UTC)
  • Laura Carlson: last responded on 29, March 2011 at 12:02 (UTC)
  • Tab Atkins Jr.: last responded on 31, March 2011 at 20:36 (UTC)
  • Aryeh Gregor: last responded on 1, April 2011 at 22:16 (UTC)
  • Leif Halvard Silli: last responded on 2, April 2011 at 02:40 (UTC)
  • : last responded on 3, April 2011 at 21:44 (UTC)
  • Ian Hickson: last responded on 4, April 2011 at 05:53 (UTC)
  • Theresa O'Connor: last responded on 4, April 2011 at 23:08 (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. 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. Henri Sivonen <hsivonen@hsivonen.fi>
  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. 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. Shefik Macauley <allknightaccess@gmail.com>
  86. Joe Steele <steele@adobe.com>
  87. John Vernaleo <john@netpurgatory.com>
  88. Jeremy Keith <jeremy@adactio.com>
  89. Jedi Lin <JediLin@Gmail.com>
  90. Jon Hughes <jon@phazm.com>
  91. Samuel Santos <samaxes@gmail.com>
  92. Dean Jackson <dino@apple.com>
  93. Mohammed DADAS <mohammed.dadas@orange.com>
  94. Sally Cain <sally.cain@rnib.org.uk>
  95. David Bolter <dbolter@mozilla.com>
  96. James Craig <jcraig@apple.com>
  97. Leonard Rosenthol <lrosenth@adobe.com>
  98. Jean-Pierre EVAIN <evain@ebu.ch>
  99. Mark Pilgrim <pilgrim@google.com>
  100. Matt Lee <mattl@cnuk.org>
  101. Magnus Olsson <magnus.olsson@ericsson.com>
  102. Chris Pearce <cpearce@mozilla.com>
  103. Andrew Wilson <atwilson@google.com>
  104. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  105. Ojan Vafai <ojan@chromium.org>
  106. Martin McEvoy <martin@weborganics.co.uk>
  107. Anders Bondehagen <anders@bondehagen.com>
  108. Steven Pemberton <Steven.Pemberton@cwi.nl>
  109. Raul Hudea <rhudea@adobe.com>
  110. Raghavan Gurumurthy <raghavan@adobe.com>
  111. Mayank Kumar <mayankk@adobe.com>
  112. Dragos Georgita <dgeorgit@adobe.com>
  113. Christopher Bank <cbank@adobe.com>
  114. Ole Riesenberg <or@oleriesenberg.com>
  115. Takuya Oikawa <takuya@google.com>
  116. Jatinder Mann <jmann@microsoft.com>
  117. Robert Stern <rstern@gmail.com>
  118. Eihab Ibrahim <eihabibrahim@gmail.com>
  119. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  120. Jer Noble <jer.noble@apple.com>
  121. Masatomo Kobayashi <mstm@jp.ibm.com>
  122. Peter Beverloo <beverloo@google.com>
  123. Andrew Scherkus <scherkus@google.com>
  124. Greg Johnson <greg.johnson@gmail.com>
  125. Martijn Croonen <martijn@martijnc.be>
  126. Stanley Manoski <manoski@mitre.org>
  127. Mounir Lamouri <mlamouri@google.com>
  128. Tony Gentilcore <tonyg@google.com>
  129. Joseph Pecoraro <pecoraro@apple.com>
  130. Bob Lund <b.lund@cablelabs.com>
  131. Tatsuya Igarashi <Tatsuya.Igarashi@sony.com>
  132. John Simmons <johnsim@microsoft.com>
  133. Mark Watson <watsonm@netflix.com>
  134. Clarke Stevens <c.stevens@cablelabs.com>
  135. Mark Vickers <mark_vickers@comcast.com>
  136. Jeremy LaCivita <jeremy.lacivita@comcast.com>
  137. Denis Ah-Kang <denis@w3.org>
  138. Alvar Laigna <laigna@gmail.com>
  139. Kunio Ito <kunio.ito@mail.rakuten.com>
  140. David Mays <david_mays@comcast.com>
  141. Michael Chen <michael_chen@comcast.com>
  142. jongyoul Park <jongyoul@etri.re.kr>
  143. Reinaldo Ferraz <reinaldo@nic.br>
  144. Eva Lingyun Jing <jinglingyun@baidu.com>
  145. GANG LIANG <gang.liang@huawei.com>
  146. Ryosuke Niwa <rniwa@apple.com>
  147. Gian Luca Marroni <gmarroni@libero.it>
  148. Ian Devlin <ian@iandevlin.com>
  149. Xingrong Guo <guoxingrong@baidu.com>
  150. Jet Villegas <w3c@junglecode.net>
  151. Alexander Surkov <surkov.alexander@gmail.com>
  152. Hasan Savran <hsavran@kent.edu>
  153. Eric VonColln <eric.voncolln@navy.mil>
  154. Rayi Lei <leiyi@baidu.com>
  155. David Dorwin <ddorwin@google.com>
  156. jiexuan gao <gaojiexuan@baidu.com>
  157. Xiaoqing Yang <yangxiaoqing@baidu.com>
  158. Aaron Colwell <acolwell@google.com>
  159. Alex Giladi <alex.giladi@huawei.com>
  160. Motomasa Futagami <mares@paoz.net>
  161. Kevin Streeter <kstreete@adobe.com>
  162. Christian Kaiser <kaiserc@google.com>
  163. Xuejian Li <lixuejian@baidu.com>
  164. Zuncheng Yang <yangzuncheng@baidu.com>
  165. Qianglong Zheng <zhengqianglong@baidu.com>
  166. Zhou Shen <shenzhou@baidu.com>
  167. Duoyi Wu <wuduoyi@baidu.com>
  168. Zheng Jia <jiazheng@baidu.com>
  169. Weifeng Feng <fengweifeng@baidu.com>
  170. Damin Hu <hudamin@baidu.com>
  171. Yang Liu <liuyang12@baidu.com>
  172. Zhixing Lei <leizhixing@baidu.com>
  173. Honggang Tang <tanghonggang@baidu.com>
  174. Kefeng Li <buaadallas@gmail.com>
  175. Xu Ma <maxu@baidu.com>
  176. Junzhong Liu <liujunzhong@baidu.com>
  177. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  178. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  179. Ami Fischman <fischman@google.com>
  180. Arnaud Braud <arnaud.braud@orange.com>
  181. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  182. Bram Tullemans <tullemans@ebu.ch>
  183. Petr Peterka <ppeterka@verimatrix.com>
  184. lei wang <wanglei03@baidu.com>
  185. Milan Patel <Milan.Patel@huawei.com>
  186. Yiling Gu <guyiling@baidu.com>
  187. Zefa Xiong <xiongzefa@baidu.com>
  188. shanglin chen <chenshanglin@baidu.com>
  189. Ping Wu <wuping02@baidu.com>
  190. Bin Chen <chenbin01@baidu.com>
  191. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  192. Patrick Ladd <Pat_Ladd2@comcast.com>
  193. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  194. Hao Jing <jh.jinghao@huawei.com>
  195. Glenn Deen <glenn.deen@nbcuni.com>
  196. Lei Wang <wanglei@baidu.com>
  197. Tom Handal <thandal@verimatrix.com>
  198. Pengcheng Guo <guopengcheng@baidu.com>
  199. Tom Wiltzius <wiltzius@google.com>
  200. Pierre-Anthony Lemieux <pal@sandflow.com>
  201. Xie Jianhui <xiejianhui@baidu.com>
  202. Yujie Jiang <jiangyujie@baidu.com>
  203. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  204. Brady Eidson <beidson@apple.com>
  205. Michael Thornburgh <mthornbu@adobe.com>
  206. Mick Hakobyan <mhakobyan@netflix.com>
  207. Vladimir Sinelnikov <sinelnikov@gmail.com>
  208. Chris Wong <huanghoujin@baidu.com>
  209. Yiliang LIU <liuyiliang@baidu.com>
  210. mingqiang zhang <imcnan@gmail.com>
  211. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  212. Grzegorz Babula <gbabula@gmail.com>
  213. Brian Kardell <hitchjs@gmail.com>
  214. xueliang fan <fanxueliang@baidu.com>
  215. Niels Thorwirth <nthorwirth@verimatrix.com>
  216. David Evans <david.evans@rd.bbc.co.uk>
  217. Joseph Karr O'Connor <josephoconnor@mac.com>
  218. Yusuke Kagiwada <block.rxckin.beats@gmail.com>
  219. smallni ding <smallniding@tencent.com>
  220. Jim Walsh <jim@jwalshcreative.com>
  221. Greg Davis <greg.davis@pearson.com>
  222. Gabino Alonso <gabinovincent@gmail.com>
  223. Sam Langdon <sam.langdon@hachette.co.uk>
  224. Michael Kelly <mkelly@mozilla.com>
  225. Xiaoqian Wu <xiaoqian@w3.org>
  226. Yue Min <minyue@baidu.com>
  227. Min Li <limin04@baidu.com>
  228. Joanmarie Diggs <jdiggs@igalia.com>
  229. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  230. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  231. So Vang <svang@nab.org>
  232. Nathalia Sautchuk Patrício <nathalia@nic.br>
  233. Vicente García Díaz <vicegd@live.com>
  234. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  235. Yusuke Yokosuka <Yokosuka.Yusuke@bx.MitsubishiElectric.co.jp>
  236. John Riviello <john_riviello@comcast.com>
  237. yaolong wang <wangyaolong@baidu.com>
  238. Tao Liang <liangtao01@baidu.com>
  239. Glenn Eguchi <geguchi@adobe.com>
  240. Lukáš Čihák <lukas.cihak@mensa.cz>
  241. WOOGLAE KIM <wlkim@inswave.com>
  242. Min Ren <minren@tencent.com>
  243. Jason White <jjwhite@ets.org>
  244. Hyejin Lee <hjlee@html5forum.or.kr>
  245. Richard Grzeczkowski <richard_grzeczkowski@comcast.com>
  246. Pascal Perrot <pascal.perrot@orange.com>
  247. Dapeng Liu <max.ldp@alibaba-inc.com>
  248. Matthew Wolenetz <wolenetz@google.com>
  249. Cory Heslip <cory_heslip@comcast.com>
  250. Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  251. Seiji Okumura <Okumura.Seiji@bc.MitsubishiElectric.co.jp>
  252. Eiji Yamamoto <Yamamoto.Eiji@db.MitsubishiElectric.co.jp>
  253. Ali C. Begen <ali_begen@comcast.com>
  254. 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.