W3C WBS Home

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.

Details

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
Kang-Hao (Kenny) Lu 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:
http://lists.w3.org/Archives/Public/www-archive/2011Apr/0039.html
Edward 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.

Details

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
http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44691

* 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:

http://lists.w3.org/Archives/Public/www-archive/2011Apr/0006.html
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.
Kang-Hao (Kenny) Lu 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
Edward 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

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. Jason White <jason@jasonjgw.net>
  7. Liam Quin <liam@w3.org>
  8. Richard Ishida <ishida@w3.org>
  9. Chris Wilson <cwilso@google.com>
  10. Wendy Chisholm <wendc@microsoft.com>
  11. David Carlisle <davidc@nag.co.uk>
  12. James Helman <jhelman@movielabs.com>
  13. Jim Allan <jimallan@tsbvi.edu>
  14. Chris Marrin <cmarrin@apple.com>
  15. Charles McCathie Nevile <chaals@yandex-team.ru>
  16. Philippe Le Hégaret <plh@w3.org>
  17. Arthur Barstow <art.barstow@gmail.com>
  18. T.V. Raman <raman@google.com>
  19. David Singer <singer@apple.com>
  20. Cynthia Shelly <cyns@microsoft.com>
  21. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  22. Sean Hayes <sean.hayes@microsoft.com>
  23. Karl Dubost <karl@la-grange.net>
  24. Larry Masinter <masinter@adobe.com>
  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. Johnny Stenback <jst@mozilla.com>
  34. Janina Sajka <janina@rednote.net>
  35. Deborah Dahl <dahl@conversational-technologies.com>
  36. Frederick Hirsch <w3c@fjhirsch.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 <wonsuk11.lee@samsung.com>
  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. Boris Zbarsky <bzbarsky@mit.edu>
  52. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  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. Mark Crawford <mark.crawford@sap.com>
  68. Doug Schepers <schepers@w3.org>
  69. Ian Fette <ifette@google.com>
  70. Michael[tm] Smith <mike@w3.org>
  71. Julian Reschke <julian.reschke@gmx.de>
  72. Kelly Ford <kelly.ford@microsoft.com>
  73. Cameron McCormack <cam@mcc.id.au>
  74. Jirka Kosek <jirka@kosek.cz>
  75. Robert O'Callahan <robert@ocallahan.org>
  76. Travis Leithead <Travis.Leithead@microsoft.com>
  77. Youngsun Ryu <ysryu@samsung.com>
  78. Sierk Bornemann <sierkb@gmail.com>
  79. Martijn Wargers <martijn.martijn@gmail.com>
  80. Simon Pieters <simonp@opera.com>
  81. James Graham <james@hoppipolla.co.uk>
  82. Henri Sivonen <hsivonen@hsivonen.fi>
  83. Lachlan Hunt <lachlan.hunt@lachy.id.au>
  84. Krijn Hoetmer <w3c@qontent.nl>
  85. Markus Fischer <markus@fischer.name>
  86. Dean Edridge <dean@dean.kiwi>
  87. Channy Yun <channy@gmail.com>
  88. Shane Thacker <shanethacker@gmail.com>
  89. Bill Mason <billm@accessibleinter.net>
  90. Vilem Malek <murphy@malek.cz>
  91. Zhihong Mao <zhihong.mao@gmail.com>
  92. Benoit Piette <benoit.piette@gmail.com>
  93. Erik van Kempen <erikvankempen@gmail.com>
  94. Jude Robinson <dotcode+w3@gmail.com>
  95. Dimitri Glazkov <dglazkov@chromium.org>
  96. Diego La Monica <d.lamonica@webprofession.com>
  97. Nick Fitzsimons <w3@nickfitz.co.uk>
  98. Josh Lawton <w3c@joshlawton.com>
  99. Giovanni Gentili <giovanni.gentili@gmail.com>
  100. Adele Peterson <adele@apple.com>
  101. Mateo Yadarola <teodalton@gmail.com>
  102. S Emerson <w3c@accretewebsolutions.ca>
  103. Andrew Fedoniouk <a.fedoniouk@gmail.com>
  104. Morten Tollefsen <morten@medialt.no>
  105. Daniel Schattenkirchner <schattenkirchner.daniel@gmx.de>
  106. Justin Anthony Knapp <justinkoavf@gmail.com>
  107. Simon Myers <Smylers@stripey.com>
  108. Samuel Weinig <weinig@apple.com>
  109. Alexey Proskuryakov <ap@webkit.org>
  110. Alejandro Fernandez <alejandro@mediadvanced.com>
  111. Doug Jones <doug_b_jones@me.com>
  112. Marc Drumm <mdrumm@wcupa.edu>
  113. Danny Liang <danny.glue@gmail.com>
  114. Arne Johannessen <arne@thaw.de>
  115. Michael Puls II <shadow2531@gmail.com>
  116. Clair Dunn <cadunn@vt2000.com>
  117. Ron Reisor <ron@udel.edu>
  118. Marat Tanalin <mtanalin@yandex.ru>
  119. Andrew Norman <idonothaveacat@gmail.com>
  120. Craig Buckler <craigbuckler@gmail.com>
  121. Brian Peppler <bpeppler@gmail.com>
  122. Matthew Turvey <mcturvey@gmail.com>
  123. Dale Hudjik <dale.hudjik@gmail.com>
  124. James Cassell <w3c@cyberpear.com>
  125. Joseph D'Andrea <jdandrea@gmail.com>
  126. Pietro Russo <p.russo@webprofession.com>
  127. Moto Ishizawa <summerwind.jp+w3c@gmail.com>
  128. Chris Adams <chris@tuesdaybegins.com>
  129. Eric Carlson <eric.carlson@apple.com>
  130. Michael Turnwall <w3c@turnwall.net>
  131. Don Kiely <donkiely@computer.org>
  132. Robert Marshall <rdm@rdmsoft.com>
  133. Jane Lee <applegoddess@gmail.com>
  134. David Child <dave@addedbytes.com>
  135. Mark DuBois <Mark@webprofessionals.org>
  136. David Choi <daaave@gmail.com>
  137. David Bills <w3@dfbills.com>
  138. Nik Thierry <me@thisemail.ca>
  139. Andrew Ramsden <andrew@irama.org>
  140. Shefik Macauley <allknightaccess@gmail.com>
  141. Joe Steele <steele@adobe.com>
  142. John Vernaleo <john@netpurgatory.com>
  143. Jeremy Keith <jeremy@adactio.com>
  144. Jedi Lin <JediLin@Gmail.com>
  145. Manu Sporny <msporny@digitalbazaar.com>
  146. Kenny Johar <kensingh@microsoft.com>
  147. Jon Hughes <jon@phazm.com>
  148. Anssi Kostiainen <anssi.kostiainen@intel.com>
  149. Samuel Santos <samaxes@gmail.com>
  150. Dean Jackson <dino@apple.com>
  151. Mohammed DADAS <mohammed.dadas@orange.com>
  152. Sally Cain <sally.cain@rnib.org.uk>
  153. Dan Romascanu <dromasca@avaya.com>
  154. David Bolter <dbolter@mozilla.com>
  155. Chris Double <cdouble@mozilla.com>
  156. Jeanne F Spellman <jeanne@w3.org>
  157. James Craig <jcraig@apple.com>
  158. MING JIN <ming.jin.web@gmail.com>
  159. Leonard Rosenthol <lrosenth@adobe.com>
  160. Philip Jägenstedt <philipj@opera.com>
  161. Adrian Bateman <adrianba@microsoft.com>
  162. Dionysios Synodinos <synodinos@gmail.com>
  163. Jean-Pierre EVAIN <evain@ebu.ch>
  164. Mark Pilgrim <pilgrim@google.com>
  165. Matt Lee <mattl@cnuk.org>
  166. Magnus Olsson <magnus.olsson@ericsson.com>
  167. Carlos Cecconi <cecconi@nic.br>
  168. Chris Pearce <cpearce@mozilla.com>
  169. Dzung Tran <dzung.d.tran@intel.com>
  170. Mark Miller <erights@google.com>
  171. Andrew Wilson <atwilson@google.com>
  172. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  173. Ojan Vafai <ojan@chromium.org>
  174. Martin Kliehm <w3c@kliehm.com>
  175. Martin McEvoy <martin@weborganics.co.uk>
  176. Gavin Carothers <gavin@carothers.name>
  177. Eliot Graff <eliotgra@microsoft.com>
  178. Frank Olivier <frank.olivier@microsoft.com>
  179. Jonathan Griffin <jgriffin@mozilla.com>
  180. Kris Krueger <krisk@microsoft.com>
  181. Erik Isaksen <erik_isaksen@hotmail.com>
  182. Anders Bondehagen <anders@bondehagen.com>
  183. Steven Pemberton <Steven.Pemberton@cwi.nl>
  184. Raul Hudea <rhudea@adobe.com>
  185. Raghavan Gurumurthy <raghavan@adobe.com>
  186. Mayank Kumar <mayankk@adobe.com>
  187. Monikandan S <smonikan@adobe.com>
  188. Dragos Georgita <dgeorgit@adobe.com>
  189. Christopher Bank <cbank@adobe.com>
  190. Dominik Tomaszuk <ddooss@wp.pl>
  191. Ole Riesenberg <or@oleriesenberg.com>
  192. Takuya Oikawa <takuya@google.com>
  193. Jatinder Mann <jmann@microsoft.com>
  194. Robert Stern <rstern@gmail.com>
  195. Dean Leigh <dean.leigh@deanleigh.co.uk>
  196. Eihab Ibrahim <eihabibrahim@gmail.com>
  197. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  198. Ian Pouncey <w3c@ipouncey.co.uk>
  199. Jer Noble <jer.noble@apple.com>
  200. Léonie Watson <lwatson@paciellogroup.com>
  201. Masatomo Kobayashi <mstm@jp.ibm.com>
  202. Peter Beverloo <beverloo@google.com>
  203. Andrew Scherkus <scherkus@google.com>
  204. Greg Johnson <greg.johnson@gmail.com>
  205. Martijn Croonen <martijn@martijnc.be>
  206. John Jansen <johnjan@microsoft.com>
  207. Stanley Manoski <manoski@mitre.org>
  208. Jonas Schneider <js.sokrates@gmail.com>
  209. Yosuke Funahashi <yosuke@funahashi.cc>
  210. Mounir Lamouri <mlamouri@google.com>
  211. Mike Amundsen <mamund@yahoo.com>
  212. Tony Gentilcore <tonyg@google.com>
  213. Jacob Rossi <Jacob.Rossi@microsoft.com>
  214. Joseph Pecoraro <pecoraro@apple.com>
  215. Othmane Benyoucef <othmane_benyoucef@hotmail.com>
  216. Shoko Okuma <okuma@tomo-digi.co.jp>
  217. Fumitaka Watanabe <fwtnb@tomo-digi.co.jp>
  218. Yoshimitsu Tsurimaki <tsurimaki@tomo-digi.co.jp>
  219. Juhani Huttunen <juhani.huttunen@nokia.com>
  220. Bob Lund <b.lund@cablelabs.com>
  221. Tatsuya Igarashi <Tatsuya.Igarashi@jp.sony.com>
  222. John Simmons <johnsim@microsoft.com>
  223. Mathias Bynens <mathias@qiwi.be>
  224. Mark Watson <watsonm@netflix.com>
  225. Clarke Stevens <c.stevens@cablelabs.com>
  226. Mark Vickers <mark_vickers@cable.comcast.com>
  227. Sree Kotay <Sree_Kotay@cable.comcast.com>
  228. Cameron Jones <cmhjones@gmail.com>
  229. Rik Cabanier <Cabanier@adobe.com>
  230. Denis Ah-Kang <denis@w3.org>
  231. Alvar Laigna <laigna@gmail.com>
  232. Kunio Ito <kunio.ito@mail.rakuten.com>
  233. David Mays <david_mays@comcast.com>
  234. Michael Chen <michael_chen@cable.comcast.com>
  235. jongyoul Park <jongyoul@etri.re.kr>
  236. Adrian Roselli <roselli@algonquinstudios.com>
  237. Colin Ihrig <cjihrig@gmail.com>
  238. Kilroy Hughes <kilroy.hughes@microsoft.com>
  239. Reinaldo Ferraz <reinaldo@nic.br>
  240. Bill Mandel <bill.mandel@nbcuni.com>
  241. Jonas Jacek <w3c@jonas.me>
  242. Eva Lingyun Jing <jinglingyun@baidu.com>
  243. GANG LIANG <gang.liang@huawei.com>
  244. Ryosuke Niwa <rniwa@apple.com>
  245. Jason Kiss <jason@accessibleculture.org>
  246. Gian Luca Marroni <gmarroni@libero.it>
  247. Ian Devlin <ian@iandevlin.com>
  248. Greg Billock <gbillock@google.com>
  249. Xingrong Guo <guoxingrong@baidu.com>
  250. Jet Villegas <w3c@junglecode.net>
  251. Anas R. <anas.ram@gmail.com>
  252. Alexander Surkov <surkov.alexander@gmail.com>
  253. wilfred nas <wilfred@wnas.nl>
  254. Hasan Savran <hsavran@kent.edu>
  255. Ben Dalton <bendalton@gmail.com>
  256. Alessandro Bassi <apbassi89@gmail.com>
  257. Marco Kotrotsos <Marco@mlabs.nl>
  258. Brian Blakely <anewpage.media@gmail.com>
  259. Eric VonColln <eric.voncolln@navy.mil>
  260. Jason Boyd <jason@pixelboxdesign.co.uk>
  261. Jerry Jiang <jerry@ucweb.com>
  262. Arun Patole <arun.patole@motorola.com>
  263. Jungkee Song <jungkee.song@samsung.com>
  264. Huan Ren <renhuan@360.cn>
  265. Songnan Ran <ransn@ucweb.com>
  266. Rayi Lei <leiyi@baidu.com>
  267. Daniel Austin <daniel@thestarsmydestination.com>
  268. David Dorwin <ddorwin@google.com>
  269. jiexuan gao <gaojiexuan@baidu.com>
  270. Mathew Marquis <mat@matmarquis.com>
  271. Xiaoqing Yang <yangxiaoqing@baidu.com>
  272. Aaron Colwell <acolwell@google.com>
  273. Alex Giladi <alex.giladi@huawei.com>
  274. Motomasa Futagami <Motomasa.Futagami@jp.sony.com>
  275. Kevin Streeter <kstreete@adobe.com>
  276. jean-baptiste henry <j.henry.ext@viaccess.com>
  277. Christian Kaiser <kaiserc@google.com>
  278. Ptah Dunbar <ptah@piratedunbar.com>
  279. François REMY <francois.remy.dev@outlook.com>
  280. Xuejian Li <lixuejian@baidu.com>
  281. Zuncheng Yang <yangzuncheng@baidu.com>
  282. Qianglong Zheng <zhengqianglong@baidu.com>
  283. Zhou Shen <shenzhou@baidu.com>
  284. Duoyi Wu <wuduoyi@baidu.com>
  285. Zheng Jia <jiazheng@baidu.com>
  286. Weifeng Feng <fengweifeng@baidu.com>
  287. Damin Hu <hudamin@baidu.com>
  288. Yang Liu <liuyang12@baidu.com>
  289. Zhixing Lei <leizhixing@baidu.com>
  290. Honggang Tang <tanghonggang@baidu.com>
  291. Kefeng Li <buaadallas@gmail.com>
  292. Manyoung Cho <manyoung@w3labs.kr>
  293. Xu Ma <maxu@baidu.com>
  294. Junzhong Liu <liujunzhong@baidu.com>
  295. Yusuke Maehama <maehama@tomo-digi.co.jp>
  296. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  297. Sheau Ng <Sheau.ng@nbcuni.com>
  298. Wei Wu <wuwei@w3.org>
  299. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  300. Ami Fischman <fischman@google.com>
  301. Arnaud Braud <arnaud.braud@orange.com>
  302. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  303. Bram Tullemans <tullemans@ebu.ch>
  304. Petr Peterka <ppeterka@verimatrix.com>
  305. lei wang <wanglei03@baidu.com>
  306. Milan Patel <Milan.Patel@huawei.com>
  307. Yiling Gu <guyiling@baidu.com>
  308. Yehuda Katz <wycats@gmail.com>
  309. Jay Munro <jaymunro@microsoft.com>
  310. Xueqing Huang <huangxueqing@baidu.com>
  311. Zefa Xiong <xiongzefa@baidu.com>
  312. shanglin chen <chenshanglin@baidu.com>
  313. Yaso Córdova <yaso@nic.br>
  314. Dongsheng Zhang <zhangdongsheng@baidu.com>
  315. Ping Wu <wuping02@baidu.com>
  316. Yao Tong <tongyao@baidu.com>
  317. Bin Chen <chenbin01@baidu.com>
  318. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  319. Patrick Ladd <Pat_Ladd2@cable.comcast.com>
  320. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  321. Billy Gregory <bgregory@paciellogroup.com>
  322. Hanrui Gao <gaohanrui@360.cn>
  323. Hao Jing <jh.jinghao@huawei.com>
  324. Glenn Deen <glenn.deen@nbcuni.com>
  325. Lei Wang <wanglei@baidu.com>
  326. Tom Handal <thandal@verimatrix.com>
  327. Tsutomu Ogasawara <tsutomu.ogasawara@mail.rakuten.com>
  328. Jose Segura <jose.segura@mail.rakuten.com>
  329. Pengcheng Guo <guopengcheng@baidu.com>
  330. Erika Doyle Navara <erika.doyle@microsoft.com>
  331. Tom Wiltzius <wiltzius@google.com>
  332. Pierre-Anthony Lemieux <pal@sandflow.com>
  333. Eric Whyne <ericwhyne@gmail.com>
  334. Xie Jianhui <xiejianhui@baidu.com>
  335. Guillermo Salazar <gsalazar1407@hotmail.com>
  336. Yujie Jiang <jiangyujie@baidu.com>
  337. Lauren O'Donovan <lauren.odonovan@gmail.com>
  338. Leslie Sikos <sikos@sikoswebconsulting.com.au>
  339. David Newton <david@davidnewton.ca>
  340. Mark Sadecki <mark.sadecki@gmail.com>
  341. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  342. Brady Eidson <beidson@apple.com>
  343. Reimundo Garcia <reimundo.garcia@hbo.com>
  344. Jerry Smith <jdsmith@microsoft.com>
  345. Michael Thornburgh <mthornbu@adobe.com>
  346. Cyril Rickelton-Abdi <cyril.rickelton-abdi@turner.com>
  347. Andrew Davis <papyromancer@gmail.com>
  348. Mick Hakobyan <mhakobyan@netflix.com>
  349. Angela Ricci <contact@thecodeplayground.net>
  350. Mallory van Achterberg <stommepoes@stommepoes.nl>
  351. Vladimir Sinelnikov <sinelnikov@gmail.com>
  352. Chris Wong <huanghoujin@baidu.com>
  353. Yiliang LIU <liuyiliang@baidu.com>
  354. David Sleight <hello@stuntbox.com>
  355. Hernan Beati <hernanbeati@gmail.com>
  356. mingqiang zhang <imcnan@gmail.com>
  357. yubo zhou <zhouyubo@360.cn>
  358. Ben Barber <barberboy@gmail.com>
  359. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  360. Grzegorz Babula <gbabula@gmail.com>
  361. xueliang fan <fanxueliang@baidu.com>
  362. Mikio Sasaki <Sasaki.Mikio@bc.MitsubishiElectric.co.jp>
  363. Niels Thorwirth <nthorwirth@verimatrix.com>
  364. David Evans <david.evans@rd.bbc.co.uk>
  365. Danny O'Brien <danny@eff.org>
  366. Joseph Karr O'Connor <josephoconnor@mac.com>
  367. Vanessa Me Tonini <vanessa@nic.br>
  368. Seth Schoen <schoen@eff.org>
  369. Jamil Ellis <jamil.ellis@hbo.com>
  370. Jim Walsh <jim@jwalshcreative.com>
  371. Jasper Valero <contact@jaspervalero.com>
  372. Greg Davis <greg.davis@pearson.com>
  373. Julio Cesar Serrano <mhysterio@gmail.com>
  374. Gabino Alonso <gabinovincent@gmail.com>
  375. Sam Langdon <sam.langdon@hachette.co.uk>
  376. Michael Kelly <mkelly@mozilla.com>
  377. Xiaoqian Wu <xiaoqian@w3.org>
  378. Yue Min <minyue@baidu.com>
  379. Min Li <limin04@baidu.com>
  380. Mark Boyle <boyle.mr@gmail.com>
  381. Sunghoon Moon <sunghoon@w3labs.kr>
  382. A.S. Krishnakumar <ask@avaya.com>
  383. Shijun Sun <shijuns@microsoft.com>
  384. Jonathan Neal <jonathantneal@gmail.com>
  385. Kei Gomita <Gomita.Kei@db.MitsubishiElectric.co.jp>
  386. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  387. diyar naozary <diyar.naozary@yahoo.com>
  388. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  389. Tetsushi Matsuda <Matsuda.Tetsushi@dh.MitsubishiElectric.co.jp>
  390. So Vang <svang@nab.org>
  391. Flavio Yanai <yanai@nic.br>
  392. Ben Peters <ben.peters@microsoft.com>
  393. Amy Brown <hello@amybrowndesign.com>
  394. Nathalia Sautchuk Patrício <nathalia@nic.br>
  395. Deblyn prado <deblyn@nic.br>
  396. Vicente García Díaz <vicegd@gmail.com>
  397. Nan Jiang <ayajiang@hotmail.com>
  398. Nolan Butcher <nolan.butcher@hbo.com>
  399. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  400. RAVI CHANDRA RAVULAPATI <ravichandra480@gmail.com>
  401. Yusuke Yokosuka <Yokosuka.Yusuke@bx.MitsubishiElectric.co.jp>
  402. John Riviello <john_riviello@comcast.com>
  403. Shun-ichi Sekiguchi <Sekiguchi.Shunichi@eb.MitsubishiElectric.co.jp>
  404. Glenn Eguchi <geguchi@adobe.com>
  405. Hirofumi Nishikawa <Nishikawa.Hirofumi@cs.MitsubishiElectric.co.jp>
  406. Hiroyuki Yamada <Yamada.Hiroyuki@dn.MitsubishiElectric.co.jp>
  407. Chockalingam Muthian <chockam@gmail.com>
  408. Michelangelo De Simone <michelangelo.de-simone@nokia.com>
  409. Lukáš Čihák <lukas.cihak@mensa.cz>

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


Completed and maintained by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.123 2013-09-26 09:46:56 dom Exp $. Please send bug reports and request for enhancements to dom@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)