Results of Questionnaire ISSUE-4 & ISSUE-84: HTML5 versioning and doctypes - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2010-07-22 to 2010-07-30.

12 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal to Allow much more general DOCTYPE syntax to be conforming, possibly including optional version information.
  2. Objections to the Change Proposal to Not Put a Version Indicator in the DOCTYPE.

1. Objections to the Change Proposal to Allow much more general DOCTYPE syntax to be conforming, possibly including optional version information.

We have a Change Proposal to allow much more general DOCTYPE syntax to be conforming, possibly including optional version information. This Change Proposal would also affect the set of legacy doctypes that are considered 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 Allow much more general DOCTYPE syntax to be conforming, possibly including optional version information.
Grant Simpson
David Baron Making varying DOCTYPE syntax conforming will make it more likely that browsers to use variations in DOCTYPE decarations to trigger new mode changes, even if the specification declares this to be nonconforming. I believe authors would be more willing to use apparently-non-proprietary mode changing syntax than clearly proprietary markup or clearly-proprietary comment syntax. Having more modes makes it harder for new entrants in the browser market, as I described in http://dbaron.org/log/2007-03#e20070325a , http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html , and http://lists.w3.org/Archives/Public/www-tag/2009Aug/0054.html .

Allowing variations in syntax that are conforming, but do nothing, seems likely to encourage authors to believe that those variations will do something. (Witness, for example, the large numbers of authors who change the "EN" within the HTML 4.0 FPI to their own language code.)

Allowing DOCTYPE declarations that can be connected to DTD-based validators encourages people to use inferior DTD-based validation tools rather than a conformant HTML5 conformance checker.
Boris Zbarsky Fundamentally, if UAs treat all HTML versions as the same there is no need for versioning information.

So a proposal to create such information presupposes that UAs will NOT treat versions the same. We have this to a small extent now in terms of quirks mode, and even that is a significant maintenance burden. So in effect, a proposal that we introduce versioning is a proposal that favors big players over small ones in the HTML space: the next obvious course of action is to make sure several incompatible versions of HTML are created and that all need to be supported. This raises barriers to entry into the field, and while it may be good for certain W3C member companies I believe it's very bad for HTML and HTML consumers as a whole.

I can see various scenarios where a producer might want to keep internal versioning information, but I believe this can be put in a comment as well as in a doctype, and in any case ideally should be removed before publishing the content (so that conformance issues don't arise even is such tools want to put the information in the doctype).

While I agree that it's possible that in the future a situation will arise where HTML documents from that point on need to be differentiated from all preceding ones, such a situation has not arisen in practice in the nearly 20 years of HTML's existence. In the unlikely event that it does arise, that would be the right time to consider adding a version indicator. Clearly this would not be done lightly at that point, but neither should changes to HTML that are backwards-incompatible to the extent envisioned in this scenario be undertaken lightly.
Henri Sivonen I strongly object to this change proposal.

A WBS bug prevented me from posting my objections here, so I posted them to http://lists.w3.org/Archives/Public/www-archive/2010Jul/0124.html as advised by the Team Contact. Please consider that message as if the objections in it were stated here.
Toby Inkster
Anne van Kesteren I have the same objections to this proposal as I have had to the ISSUE-88 change proposal to allow something without any observable effect. This will only lead to confusion for authors.


In addition, this would give the opportunity for Web browsers to fragment HTML which would be a very bad thing for the Web. If we ever need versioning for HTML (and we have not since HTML was invented) we can add it at that point. Designing for a theoretical future is not at all necessary here and only complicates matters.
James Graham I strongly object to the proposal to add versioning information
in HTML. In general terms, versioning on the UA side is bad for
the web, significantly increasing the burden of complexity in new
implementations, and therefore reducing competition in the
browser space.

Versioning is also bad for authors because it means they have to learn
magic incantations to opt into the behaviour they expect, leading
to confusion when things go wrong due to picking the wrong
version. These problems can be seen today with quirks vs limited
quirks vs standards modes.

Given that switching behaviour based on versions is bad for both
end users and authors, we should be designing the language to
make it difficult for UAs to version switch, even if it is in their
interests to do so, because it is not in the interests of the web as a

Although the change proposal makes some attempt to limit the scope of
when versioning information is permitted and how UAs may react to it,
it seems foolish to rely on both authors and vendors following such a
complex set of rules when the downsides of breaking them is so
great. In particular if UA vendors break the rules. costs are mostly
in the form of externalities incurred by other vendors, authors and
ultimately end users. We should be working to avoid such things, not
encouraging them by making them easy.

The suggested rules continually refer to "controlled
environments". This implies that the change proposal is mainly
concerned with non-web use cases. I do not believe we should give
priority to non-web use cases particularly when they directly conflict
with the requirements for the web.

I also note that were these rules to be followed, and versioning only
used in non-web applications, several of the supposed benefits of
versioning could not actually occur in the manner described, unless we
believe the argument that an unused syntactic construct is materially
different from one that does not exist. However it is not clear why
this is so; for example one suggested benefit of versioning is
continuity of conformance for existing documents in the face of
changes to the conformance requirements of the language. It is hard to
see how this is realised in the case where there is a versioning
mechanism that a document is not permitted to use, but not in the case
where there is no versioning mechanism. In this sense I believe that
the proposal is internally inconsistent.

This inconsistency would be more troubling if the purported benefits
of versioning were real. However I believe they are not, and agree
with the criticisms that Henri made in his response.

It has been suggested that non-browser UAs, in particular editors (or
"editing workflows"), may benefit from versioning information. However
it is not clear why this would be uniquely important, or even
necessary, metadata for an editor. Such a UA may also want to store
information such as the current cursor position, or details of the
allowed features according to a specific set of browsers that the
author wished to target. I do not think such UAs benefit substantially
from a version indicator and certainly I see no need to raise it to a
privileged position above all other possible metadata.
Jeremy Orlow Backwards compatibility is central to HTML. If your HTML needs to target specific versions of the spec, then we've failed. Adding the notion of versions to the DOCTYPE will simply confuse authors and provides no real benefit as far as I can tell.

If we do for some reason, in the future, do need to break backwards compatibility, we should then consider adding a mechanism for citing versions. Until then, the version number will just be noise/overhead/confusing.
Aryeh Gregor First, point #11 of the Rationale suggests that if an incompatible change to HTML is ever needed, adding support for version indicators now will help to avert the cost of switching to the new and incompatible version. But according to the proposal, browsers will treat a versioned doctype the same as an unversioned one, so why not just use the latter exclusively? If versioning ever needs to be added in the future, add it then. Pages with plain <!doctype html> can then be treated as "old" pages, while ones with the new versioning syntax (whatever it is) will be "new" ones.

Indeed, this is exactly what HTTP did. HTTP 0.9 <http://www.w3.org/Protocols/HTTP/AsImplemented.html> had no explicit versioning, and when HTTP 1.0 <http://tools.ietf.org/html/rfc1945#page-12> added versioning, it provided that "If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format." This scheme proved successful in practice, obviously.

It is not explained why permitting versioning now makes later incompatible changes easier. As far as I can tell, this eliminates the rationale for the entire proposal, because it leaves no reason to actually permit explicit versioning now.

Second, the Change Proposal (also in point #11 of the Rationale) states:

In the history of computer languages, there are no languages that have not evolved, been extended, or otherwise "versioned" as long as the language has been in use. This applies to network protocols, character encoding standards, programming languages, and certainly to every known technology found on the web. There are no known cases where a language hasn't gone through some at least minor incompatible change. The standards process is established as a way of evolving specifications and implementations in a way to reduce the likelihood of complete failure to interoperate, but certainly not to guarantee that no incompatible changes will be needed in the future.

I believe this is materially very wrong. HTML, CSS, and JavaScript are all languages that have maintained an extremely high degree of backward compatibility, and in particular have not ever used explicit versioning to date (that is, none that authors or UAs respected in practice, formal talismans notwithstanding).

There are many other languages and interfaces that try to maintain this level of compatibility as well. The Linux system call API, the X Window System, and the Windows system call interface have all kept changes down to a level where they do not require programs or operating systems to advertise particular versions. I cannot think of a single programming language that requires programs to explicitly state what version of the language they're written in. (Perhaps this just shows my limited knowledge of programming languages, but then the original Change Proposal should have given supporting evidence for the claim in the first place.)

Indeed, it's difficult to think of successful technologies that really rely on explicit versioning in practice. HTTP and XML have explicit versions, but in practice they're stuck at 1.1 and 1.0 respectively, and any new features that are adopted in practice are added backwards-compatibly, without incrementing the version number. So although they technically have version numbers, they're not good support for this Change Proposal.

It's true that all languages sometimes need to break backward compatibility a bit, but version indicators are rarely necessary or helpful in doing this. In most cases, such breakage is kept as minimal as possible, so incrementing a version number would be excessive. In some cases, such as Python, there are large-scale backward compatibility breaks, but version indicators are still not used -- because they impose a permanent cost on the language to moderately ease a temporary transition period.

On top of that, even if a few other languages do use explicit version indicators in the real world, they are not in the same position as web technologies. HTML is used by billions of people every day, and there are trillions of web pages in existence, under the control of countless different authors. Browser implementers have consistently emphasized that in order for people to use their browsers, they *cannot* break significant numbers of web pages. It is not a question of whether we want to change HTML incompatibly; it is impossible whether we want to or not, because market forces prohibit it. No reason is given for why this situation would ever change, as long as HTML remains widely deployed.

Thus adding explicit version indicators is not only useless in the event of an incompatible change, as I explain in my first point. It also exemplifies one of the cardinal problems with pursuing long-term theoretical purity over short- to mid-term pragmatism: it burdens the language with extra syntax to avoid a problem that will very likely never exist, so that the cure is worse than the disease.

In summary, the proposal seeks to address a nonexistent problem, and fails to do even that.

On a final and more minor note, I also specifically object to the suggestion that the wording "mostly useless" be changed. It's good to use clear and forceful wording to help get the message out to authors that doctypes have no real purpose on the web, since they don't control browser processing (except by avoiding quirks mode). Weaker wording like "of limited utility" would reduce the effectiveness of this message. We do not need to write the spec in an overly formal fashion if that reduces the effectiveness of its phrasing.
Tab Atkins Jr. Robin Berjon addressed the issue of a version indicator eloquently in his series on "XML Bad Practices", based on his experiences developing the SVG specification: http://berjon.com/blog/2009/12/xmlbp-naive-versioning.html.

If content is expected to be rejected across version boundaries, then "versions" are actually different languages entirely. Pretending that they're just different versions helps no one, and so a versioning indicator is not needed. Luckily, HTML has never and likely will never fall into this category - the next category is the relevant one here.

If content is expected to be accepted across version boundaries, then good "versioning" behavior must be relatively complex and subtle to correctly handle unknown (read: newly introduced) content. The versioning indicator itself doesn't help in any way with this - what happens if the author says the content is version 2, but uses a construct from version 1 that's obsolete in version 2, and a construct from version 3 that hadn't been thought of at the time version 2 was created? Proper error-handling (for the version1 construct) and forward-compatible design (for the version3 construct) needs to be designed into the language in the first place, and an additional version indicator provides precisely zero help here.

Thus, a versioning indicator is never needed. As this appears to be the primary justification for this change proposal, then, I strongly object to changing the language in this way.
It is a key necessity for the World Wide Web to operate on a basis which does not require version-specific syntax with DOCTYPE for HTML in order to avoid confusion among platforms. Allowing such syntax may break the universal standards of HTML if many different DOCTYPE documents are produced.
David Singer
- HTML and other core specifications of the Web platform are processed in an unversioned way in practice. Having an in-band version indicator is misleading to authors, who expect it to have a material effect, and creates a great deal of misunderstanding.
- It may be tempting for some implementors to use a standard version indicator as an implementation version indicator. For reasons well-explained by Adam Barth, David Baron and others, this would have an anti-competitive effect on the browser market; content would end up locked in to specific bug profiles.
- The proposal not only allows versioning in the doctype but also allows creation of ad-hoc custom doctypes. Profiling the language this way is likely to lead to interoperability problems.
- If versioning is to be supported, versioning the doctype is inferior to versioning via an attribute; other specs use an attribute, XML documents generally would not use a doctype, and the doctype is not viable for compound documents such as Atom that embeds XHTML.
- The change proposal argues that versioning in the doctype may be useful for controlled environments, but on the other hand argues that versioning must be ignored by implementations. If it has an effect, it creates an interoperability problem; if it has no effect, then it is unclear how it helps controlled environments.

2. Objections to the Change Proposal to Not Put a Version Indicator in the DOCTYPE.

We have a Change Proposal to not put a version indicator in the DOCTYPE. This Change Proposal would also leave the set of legacy doctypes that are considered conforming unchanged from the current draft. 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 Not Put a Version Indicator in the DOCTYPE.
Grant Simpson In my academic capacity, I often deal with historical electronic documents. While the DOCTYPE stated in the document is not an ironclad indication of which DOCTYPE the author meant to use (or even that the author knew what a DOCTYPE is), it limits the likely age of the document to at least as old as the DOCTYPE. The existing HTML DOCTYPES are versioned, which makes this task much easier than if we adopt a non-versioned DOCTYPE. Essentially, if we go with simply <!DOCTYPE html> and continue to do the same for iterations of HTML after 5 (as is implied by the lack of a version number), we greatly increase the complexity of attempting to date HTML documents according to internal criteria. We would merely be saying that this document is HTML 5+, period. Similarly, if we allow HTML 5 documents to use legacy DOCTYPES, we exacerbate the problem to a higher degree. I realize, first of all, that my concerns are not of primary concern to matters of conformance checking and document parsing and, second of all, that due to the fact that people regularly select the wrong DOCTYPE -- or it is selected for them by WYSIWYG editors -- and thus one would have to look to more internal criteria to determine age (and, more helpfully, to external criteria). However, I do think this is an important concern for people working with historical HTML documents. Heretofore, DOCTYPE has been a serviceable first stab at determining date.
David Baron
Boris Zbarsky
Henri Sivonen
Toby Inkster The proposal confuses version indicators with rendering pragmas.

Allowing authors to include a DOCTYPE of their choice would not require people working on HTML rendering engines and other HTML processors to pay any special attention to them.
Anne van Kesteren
James Graham
Jeremy Orlow
Aryeh Gregor
Tab Atkins Jr.
David Singer

More details on responses

  • Grant Simpson: last responded on 22, July 2010 at 18:31 (UTC)
  • David Baron: last responded on 22, July 2010 at 20:16 (UTC)
  • Boris Zbarsky: last responded on 23, July 2010 at 05:07 (UTC)
  • Henri Sivonen: last responded on 23, July 2010 at 12:19 (UTC)
  • Toby Inkster: last responded on 26, July 2010 at 21:14 (UTC)
  • Anne van Kesteren: last responded on 27, July 2010 at 08:17 (UTC)
  • James Graham: last responded on 27, July 2010 at 11:43 (UTC)
  • Jeremy Orlow: last responded on 27, July 2010 at 14:00 (UTC)
  • Aryeh Gregor: last responded on 27, July 2010 at 18:20 (UTC)
  • Tab Atkins Jr.: last responded on 27, July 2010 at 19:41 (UTC)
  • : last responded on 29, July 2010 at 18:11 (UTC)
  • David Singer: last responded on 30, July 2010 at 10:11 (UTC)


The following persons have not answered the questionnaire:

  1. Tantek Çelik <tantek@cs.stanford.edu>
  2. Patrick D F Ion <pion@umich.edu>
  3. Judy Brewer <jbrewer@w3.org>
  4. Liam Quin <liam@w3.org>
  5. Richard Ishida <ishida@w3.org>
  6. Chris Wilson <cwilso@google.com>
  7. David Carlisle <davidc@nag.co.uk>
  8. James Helman <jhelman@movielabs.com>
  9. Jim Allan <jimallan@tsbvi.edu>
  10. Chris Marrin <cmarrin@apple.com>
  11. Charles McCathie Nevile <chaals@yandex.ru>
  12. Philippe Le Hégaret <plh@w3.org>
  13. Don Brutzman <brutzman@nps.edu>
  14. T.V. Raman <raman@google.com>
  15. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  16. Karl Dubost <karl@la-grange.net>
  17. Ian Hickson <ian@hixie.ch>
  18. Wu Chou <wu.chou@huawei.com>
  19. Katsuhiko Momoi <momoi@google.com>
  20. Kangchan Lee <chan@w3.org>
  21. Roy Fielding <fielding@gbiv.com>
  22. Deborah Dahl <dahl@conversational-technologies.com>
  23. Michael Cooper <cooper@w3.org>
  24. Glenn Adams <glenn@skynav.com>
  25. Jonathan Jeon <hollobit@etri.re.kr>
  26. David Hyatt <hyatt@apple.com>
  27. WonSuk Lee <wonsuk.lee@etri.re.kr>
  28. Maciej Stachowiak <mjs@apple.com>
  29. Robert Accettura <robert@accettura.com>
  30. Jonathan Watt <jwatt@jwatt.org>
  31. Steve Faulkner <faulkner.steve@gmail.com>
  32. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  33. Patrick Lauke <redux@splintered.co.uk>
  34. David MacDonald <David100@sympatico.ca>
  35. Jack Jansen <jack@cwi.nl>
  36. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  37. Markku Hakkinen <mhakkinen@ets.org>
  38. Jens Oliver Meiert <jens@meiert.com>
  39. Kazuyuki Ashimura <ashimura@w3.org>
  40. Han Xu <collin@w3china.org>
  41. Sam Ruby <rubys@intertwingly.net>
  42. Mark Crawford <mark.crawford@sap.com>
  43. Preety Kumar <preety.kumar@deque.com>
  44. Ian Fette <ifette@google.com>
  45. Cameron McCormack <cam@mcc.id.au>
  46. Stefan Schnabel <stefan.schnabel@sap.com>
  47. Jirka Kosek <jirka@kosek.cz>
  48. Travis Leithead <Travis.Leithead@microsoft.com>
  49. Youngsun Ryu <ysryu@samsung.com>
  50. Sierk Bornemann <sierkb@gmail.com>
  51. Krijn Hoetmer <w3c@qontent.nl>
  52. Channy Yun <channy@gmail.com>
  53. Shane Thacker <shanethacker@gmail.com>
  54. Vilem Malek <murphy@malek.cz>
  55. Zhihong Mao <zhihong.mao@gmail.com>
  56. Benoit Piette <benoit.piette@gmail.com>
  57. Erik van Kempen <erikvankempen@gmail.com>
  58. Dimitri Glazkov <dglazkov@google.com>
  59. Nick Fitzsimons <w3@nickfitz.co.uk>
  60. Josh Lawton <w3c@joshlawton.com>
  61. S Emerson <w3c@accretewebsolutions.ca>
  62. Theresa O'Connor <eoconnor@apple.com>
  63. Justin Anthony Knapp <justinkoavf@gmail.com>
  64. Simon Myers <Smylers@stripey.com>
  65. Samuel Weinig <weinig@apple.com>
  66. Alexey Proskuryakov <ap@webkit.org>
  67. Alejandro Fernandez <alejandro@mediadvanced.com>
  68. Doug Jones <doug_b_jones@me.com>
  69. Marc Drumm <mdrumm@wcupa.edu>
  70. Danny Liang <danny.glue@gmail.com>
  71. Michael Puls II <shadow2531@gmail.com>
  72. Ron Reisor <ron@udel.edu>
  73. Craig Buckler <craigbuckler@gmail.com>
  74. Dale Hudjik <dale.hudjik@gmail.com>
  75. James Cassell <w3c@cyberpear.com>
  76. Joseph D'Andrea <jdandrea@gmail.com>
  77. Eric Carlson <eric.carlson@apple.com>
  78. Don Kiely <donkiely@computer.org>
  79. David Child <dave@addedbytes.com>
  80. Mark DuBois <Mark@webprofessionals.org>
  81. David Bills <w3@dfbills.com>
  82. Nik Thierry <me@thisemail.ca>
  83. Andrew Ramsden <andrew@irama.org>
  84. John Foliot <john.foliot@deque.com>
  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.