W3C WBS Home

Results of Questionnaire HTML5 Last Call: Should the HTML5 specifications be published at Last Call Working Drafts?

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-05-15 to 2011-05-22.

110 answers have been received.

Jump to results for question:

  1. HTML5 Last Call Working Draft
  2. HTML+RDFa Last Call Working Draft
  3. HTML Microdata Last Call Working Draft
  4. HTML Canvas 2D Context Last Call Working Draft
  5. HTML/XHTML Compatibility Authoring Guidelines Last Call Working Draft
  6. HTML5: Techniques for providing useful text alternatives Last Call Working Draft

1. HTML5 Last Call Working Draft

The HTML5 specification is ready for progression to Last Call Working Draft status. Please provide your preference with respect to this specification by choosing ONE of the options below.

If you Formally Object to publishing this specification as a Last Call Working Draft, please state your objections below.

Keep in mind that you must actually state an objection, not merely cite someone else.

Summary

ChoiceAll responders
Results
Yes 95
No 9
Abstain 6
Formally Object

Details

Responder HTML5 Last Call Working DraftRationale
Arthur Jennings Yes
Masataka Yakura Yes
Doug Jones Yes
Sam Ruby Yes
Dzung Tran Yes
Adrian Bateman Yes
Eliot Graff Yes
Frank Olivier Yes
Travis Leithead Yes
Jacob Rossi Yes
Michael[tm] Smith Yes
Emilio Garcia Yes
Antonio Tapiador Abstain
Sandra Aguirrre Herrera Yes
Kangchan Lee Yes
Javier Cerviño Yes
Enrique Barra Yes
Channy Yun Yes
Ohad Assulin Yes
Michael Whitley Yes
Lawrence Rosen Yes
Jens Meiert Yes
Sean Hayes Yes
Dean Jackson Yes
Adam Roben Yes
Tony Ross Yes
Gavin Sharp Yes
Kris Krueger Yes
Kimberly Blessing Yes
Lee Kowalkowski Yes
Cynthia Shelly Yes
Julian Reschke No The referenced spec is changing while the poll is running. There's no sane way to review it.

This spec is big, and would need a long period of stability, at least with respect to normative changes, to make it possible to answer this question with some confidence.
Samuel Santos Yes
David Corvoysier Yes
Matthew Turvey Yes
Christophe Eyrignoux Yes
Raghavan Gurumurthy Yes
Mayank Kumar Yes
Aryeh Gregor Yes
Alexey Proskuryakov Yes
Stanley Manoski Yes
Maciej Stachowiak Yes (speaking for no one but myself and with chair hat off) HTML5 has had a long road to get to the point where it is ready for Last Call. While there is more polishing to do, at this point, the best thing to do is to advance to the next W3C Process milestone and solicit review from the wider community.
Mathias Bynens Yes
Kai Scheppe Yes I believe it is time to get full consideration of all stakeholders for this draft of the specification, which will only occur in last call status.
Simon Pieters Yes
James Graham Yes
David Baron Yes
Henri Sivonen Yes
Paul Bakaus Yes
Pasquale Popolizio Yes
Matthew MacKenzie Yes
Daniel Burnett Yes
Arthur Barstow Yes
Boris Zbarsky Yes
Sorin Sbarnea Yes
Danny Ayers Abstain I'm not convinced the spec is really stable enough to move to the next level, but I don't personally feel strongly about any of the individual issues in flux.
Karl Dubost Abstain (This opinion doesn't represent the official position of Opera)

I'm 50-50 on this one between publishing and not publishing. There is a conflict which is wider than the specification itself on the way we work the technology.

There are issues which still remains to be solved and have impact for developers. Last Call should not be an opportunity to be sure to have comments. At the same time will there be any time in the current iteration of this format with a stable version is yet to be seen.


Shawn Medero Yes
Edward O'Connor Yes
Ben Adida Yes
Tab Atkins Jr. Yes I don't think that the existing W3C process is actually useful for HTML, but if we're playing this game, then it's better for it to be published than not.
John Drinkwater Yes
Gavin Carothers Yes
David Singer Yes
Li Li Yes
Cameron McCormack Yes
Kornel Lesinski Abstain
Dominik Tomaszuk Yes
Philippe Le Hégaret Yes It is important to get a wider review of the specification.

It is also important for the status section to indicate the following:
[[
* Fulfill the relevant requirements of the Working Group charter and those of any accompanying requirements documents, or report which relevant requirements have not been fulfilled.
* Indicate which dependencies with other groups the Working Group believes it has satisfied, and report which dependencies have not been satisfied.
]]
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call


Daniel Glazman No (modified 20-may-2011)

The longdesc discussion is not reflected in this document. The lack of longdesc itself it enough for me to refuse this document to move to LCWD. FWIW, there's is proposal from the HTML-A11Y Task Force dated 16-may... Longdesc should be in. I don't think this is reasonable to move to LC before this is resolved and fixed.

http://lists.w3.org/Archives/Public/public-html/2011May/0170.html

The ins and del elements are still living at both block and inline levels, and that is a serious problem for wysiwyg content editors. I said it multiple times in the past. Attributes should be used here instead of elements. First example of Section 4.7.5 is a perfect illustration of the problem: since <ins> and <del> cannot be children of <ol> (as in a SGML inclusion), it's impossible to mark a whole list item as inserted or deleted and only the textual content can be marked as such. This is a *BLOCKER* for wysiwyg editing of lists with versioning marks.
Again, this problem was reported to W3C multiple times between 2001 and now. If the current HTML WG has not added to its issues list all the potential errata material carefully agregated between 2001 and now, that's a deep mistake.

The scoped attribute on style elements is defined by html5 but the exact behaviour of that in the CSS Cascade remains undefined by CSS at this time. Scoping poses serious issues to wysiwyg content editors. I do agree scoping is super-important but how it works is underdefined here and relies on a non-existing CSS specification at this time. Same thing as above, the HTML4 errata has apparently never been observed by the current HTML WG.

<a name> is still not explicitely allowed, please see bug 12334 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12334

The spec defines CSS pseudo-classes in section 4.14.2; some of them, like :rtl and :ltr are not even extensively discussed at this time. More generally, the document makes normative CSS references to documents (like CSS OM) that are Editor drafts, unstable, undiscussed, and that should not be normatively referenced at this time.

The disabled DOM attribute on style and link elements are still not reflected in the attribute space of those elements. This inconsistency between Object Model and attributes was reported back to the HTML WG, for the first time back in **2001** and it is still not fixed. Without a disabled attribute on the elements, it's impossible for a content editor to save the disabled status of a stylesheet linked to the document.

Sections 10.3.2.3.1 and 10.3.2.3.2 define new CSS pseudo-elements that were *never* submitted to the CSS WG for discussion and approval.

I can list tons of problems like that in that document that is clearly not ready to go to Last Call. In my mind, a LCWD is clean and stable enough so there is a large expectation that the document can move to CR with minor modifications. A LCWD is also a document that is the result of cross-WG discussions and formal approval if it contains things that are clearly in the domain of another WG. For instance the SVG WG is constantly talking to the CSS WG when it deals with CSS. The HTML WG has _never_ done it.

The dependencies to other WGs described at section 7.4.2 of the Process for Last Call announcement are then not satisfied:

- the Working Group HAS NOT satisfied significant dependencies with other groups
- the Working Group HAS NOT worked with all other groups prior to a Last Call announcement to reduce the risk of surprise at Last Call

I think it is very clear reading my comments above that CSS should be a dependency here. But the HTML WG Charter says in section 3.2 about Liaisons only "CSS WG and XSL WG: The work of the HTML Working Group will be coordinated with these groups on presentation issues". According to that Charter, CSS is NOT a dependency but a liaison. And CSS syntax and selectors are NOT in the scope or list of deliverables of this WG. According to the Charter, the HTML5 spec then cannot define CSS selectors w/o the CSS WG, right?

Hence my negative vote on a move to LCWD for this document. Not only this document does not meet the quality level of other LCWDs in the Consortium, but the WG did not satisfy the minimal dependencies to other WGs the W3C strongly requires from its other WGs.
Jack Jansen Abstain
Dan Brickley Yes
Lachlan Hunt Yes
Mark Birbeck Yes
Graham Klyne Yes My formal objection is withdrawn on the understanding that on publication the given "This version" link will dereference to the same version of the document currently accessible using the above link.

The dated link given for "this version" (i.e. http://www.w3.org/TR/2011/WD-html5-20110524/) is broken, so there is no stable URI reference to this specific version for discussion or later reference.
Martin McEvoy Yes
Richard Schwerdtfeger Yes Although, there are numerous outstanding accessibility bugs that will need to be addressed, before the spec. leaves last call, such as:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11893, I do believe the spec. needs to receive comments from industry. Unfortunately, most developers will not provide those comments while the spec. is moving. Consequently, we typically have more than one last call draft in the W3C. So, to get industry feedback I voted yes.
Gez Lemon No There are still significant accessibility issues with the current specification. The longdesc attribute should be reinstated, as there is no other mechanism for providing a detailed semantic description of complicated non-text objects. I also strongly object to the alt attribute validation decisions: missing alt with title attribute conforming; role="presentation" and missing alt non-conforming; <meta name="generator"> and missing alt conforming: these decisions do not make sense.
Per-Erik Brodin Yes
Bob Lund Yes
Toby Inkster Yes
Vincent Hardy Yes
John Foliot Yes As an active member of this Working Group, and one who is deeply committed to ensuring that the web is, and will remain accessible to all users, I struggled hard with my decision; we clearly and most certainly are not at a point where HTML5 – the Draft we are being asked to comment on here – satisfies that goal. There remains numerous and serious holes in this document that if left unattended present real and significant barriers to various users with disabilities. HTML5 is not done. In fact, it’s not even close.

I respect however that progress must continue, and I understand that artificially stalling progress on process grounds alone hurts rather than helps the cause of accessibility, and of achieving the real goal I have committed to pursuing.

With my vote however I also admonish the Chairs for not clearly calling this request what it actually is – a Request For Public Comment (RFPC). I acknowledge that currently the W3C Process does not include such a mechanism, but when the Chairs laid out their process (http://dev.w3.org/html5/decision-policy/decision-policy.html) and timeline (http://lists.w3.org/Archives/Public/public-html/2010Sep/0074.html), they introduced a number of mechanisms and procedures new to the W3C Standards Process. They had the opportunity then to introduce a RFC milestone into their time-line, and they failed to do so (instead choosing to now refer to the oxymoron of “First Last Call”). Such is history, and the W3C should collectively learn from this failure. But that was then, this is now.

Given that an RFPC essentially represents a Feature freeze, while at the same time acknowledging that issues and bugs remain, then I can accept that the Draft document we are looking at today is at that state.

For this reason I conclude that we are all better served by admitting this fact, and seeking the wider public review that an RFPC would deliver. We can call it an RFPC, a “First” Last Call, or we can call it Fred – what is important is that we all understand what it is we are talking about, and where we are today.

There are some real problems with the Draft we are being asked to move forward today. The 3 most significant problems I see are:

• The document located at http://dev.w3.org/html5/spec-LC/ - the document we are being asked to move forward to Last Call - continues to contain the advisory “This is a Work in Progress! For the latest updates from the HTML WW, possibly including important bug fixes, please look at the editor’s draft instead.” This can only lead to confusion and a lack of clarity to the wider public now being invited to comment.

As a condition of my approval, this advisory must be removed.

• This Draft DOES NOT “document which relevant requirements they have not fulfilled” (http://www.w3.org/Consortium/Process-20010208/tr.html#last-call). Specifically to the issue of @longdesc, it does not indicated that a final decision on the fate of @longdesc is currently an open issue (http://dev.w3.org/html5/spec-LC/obsolete.html#non-conforming-features), nor does it reference any of the other open Issues (http://www.w3.org/html/wg/tracker/issues/open), or newly raised issues (http://www.w3.org/html/wg/tracker/issues/raised) not yet addressed in this Draft.

As a condition of my approval, this omission must be rectified, and these links must be clearly and prominently included in any document put forward for wider public comment.

• As part of the request to move this Draft forward into last Call, no further time-line has been articulated or defined. If the Working Group truly wants to solicit further and wider feedback on this Draft, and the Chairs are seeking this Working Group’s approval to do so, then as a member of this Working Group I want to know how long the public feedback period will be.

As a condition of my approval I expect that this Working Group has the answer to that question prior to releasing the Draft to Public Comment.

*IF* these issues are addressed prior to the public call for comment, then I can endorse moving forward at this time. Although I only have one vote I none-the-less challenge the Chairs to meet these 3 requirements, to better ensure that not only does this Working Group clearly and fully understand where we are in the Standards Process, so too will the wider public.

While I continue to have my own personal reservations and frustrations about how current outstanding accessibility issues are being handled within this Working Group, I also believe that the best thing the accessibility community can do is work pro-actively with our fellow Working Group members, rather than reactively against them. Seeking to block forward movement turns potential allies into possible enemies.

Therefore I lend my support to moving forward at this time.
Wayne Carr Yes Please consider changing the following. The status section says "The W3C HTML working group actively pursues convergence with the WHATWG, as required by the W3C HTML working group charter." The word "required" is not in the charter related to this and could be read as implying there is some kind of obligation to incorporate WHATWG features. If this must be in the status section at all, please change it to copy what the charter actually says: "The HTML Working Group will actively pursue convergence with WHATWG, encouraging open participation within the bounds of the W3C patent policy and available resources."
Scott Vesey Yes
Bryan Sullivan Yes
Diego Moreno Yes
Soonbo Han Yes
Cameron Jones Yes
Benoit Piette Yes
Laura Carlson No While I agree with Philippe that it is important to get a wider review of the specification, the HTML5 Working Group should satisfy relevant technical accessibility requirements and dependencies first. Last Call is different from a Request For Public Comment.

Some people with disabilities may be locked out of the HTML5 review process. This bug is currently marked INVALID:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10525
Eric Carlson Yes
Leif Halvard Silli No A number of authoring conformance issues, including accessibility related attribute issues, ought to be solved before moving to Last Call Working Draft status.
Joshue O Connor No Some accessibility issues are still not satisfactorily resolved. FOr example, the longdesc issue is still unresolved [http://www.w3.org/html/wg/tracker/issues/30], alt attribute validation rules are still in flux etc, the status of some useful useful HTML 4 attributes like @summary are less than satisfactory [http://www.w3.org/html/wg/tracker/issues/32] to me if nobody else.

While I agree that an attempt for industry feedback is useful (and needed) it should be via a Request for Public Comment, not by pressing 'print' on a spec still in flux.
Anand Samuel Edwin Yes
Steve Faulkner Yes
Sally Cain Yes I am happy to vote yes because of the statement in the email from Judy Brewer (Sunday 22 May 19.28) :
"we understand that if Last Call
Working Draft publication of HTML5 proceeds, there will not be a
claim of feature completeness; remaining concerns will be flagged in
the draft; it will be accompanied by messaging addressing the
importance of resolving accessibility support in HTML5; improvements
in subsequent working drafts will be noted; and improvements in
coordination, in advance opportunities for clarification, and in
timing of decisions will be pursued."
Geoff Freed No Would prefer that important accessibility-related conflicts, such as @longdesc and the issues around @alt, be settled before LC draft is published.
Charles McCathie Nevile Yes This is Opera's formal position.
Marco Ranon Yes Yes on the basis of Judy Brewer's message to the HTML Accessibility Task Force: http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0504.html.
Judy Brewer Abstain The purpose of Last Call Working Draft (LCWD) is to indicate that a working group (WG) believes that technical requirements and significant dependencies have been met, which this document has not. It has multiple unmet technical requirements that are necessary to support the needs of web users with disabilities, and unmet dependencies with Web Accessibility Initiative (WAI) groups. As some commenters have noted, W3C might benefit from a "request for public comment" document stage that does not imply readiness for "last call," and this question may be valuable to explore; however, W3C Process does not prevent a WG from issuing a call for review of a working draft.

Moving a document that has multiple unmet requirements and dependencies to LCWD status can create the perception that a document is feature complete even when it is not. Nevertheless, the entrance criteria under W3C Process permit a WG to move a document into LCWD if unmet technical requirements and dependencies are clearly documented. If this document is published as a LCWD, these unmet requirements and dependencies must be documented; the document must not be claimed as feature-complete; and W3C should clarify that a specification must fully support accessibility to become a W3C Recommendation.

Moving a document to LCWD status may bring additional review from people outside of a working group. This may be helpful in documenting rationales including additional use cases, and in providing further opportunities to improve change proposals and developing broader consensus around these. However, if application of the HTML WG decision process were to remain unchanged moving forward, with long delays between submission of accessibility change proposals and rendering of decisions only weeks before a vote for transition to the next document stage is taken, the HTML WG decision process would again disadvantage rather than facilitate effective resolution of technical requirements and dependencies. The HTML WG decision process needs and will get additional scrutiny.
Kensaku KOMATSU Yes
Mike Taylor Yes
Manu Sporny Yes
Janina Sajka Yes But only because we are agreed to indicate that there is likely to be yet another "last call," in other
words, this isn't really anything close to "last," because it isn't near finished, at least with respect to accessibility.
I am also agreeing because we are flagging the a11y items still missing, incomplete, or otherwise unconsensed.
I support the wish to garner additional review, and hope this brings us additional people
to work on a11y issues because so many of them remain porrly addressed and even unaddressed--especially issues that
have long been considered settled a11y features.
Hidetaka Kimura Yes
Monika Trebo No I would prefer to have outstanding issues, especially “ISSUE-30: Should HTML 5 include a longdesc attribute for images” be resolved before this document is published at Last Call Working Drafts.
Please note, that there is a Request to Reconsider ISSUE-30 Decision from Janina Sajka at http://lists.w3.org/Archives/Public/public-html/2011May/0170.html.
Simon Myers Yes It's what we've been working on, and it's already far more useful and relevant than HTML4.
Doug Wright Yes
Lynn Holdsworth No The spec feels as though it's at an RfPC stage rather than being stable enough for last call. If this spec were to be ratified in its current form, there would arguably be scope for perfectly valid but radically less accessible mark-up than was possible using HTML4, given the removal of longdesc and the uncertainty around use of summary and alt attributes.

2. HTML+RDFa Last Call Working Draft

The HTML+RDFa specification is ready for progression to Last Call Working Draft status. Please provide your preference with respect to this specification by choosing ONE of the options below.

If you Formally Object to publishing this specification as a Last Call Working Draft, please state your objections below.

Keep in mind that you must actually state an objection, not merely cite someone else.

Summary

ChoiceAll responders
Results
Yes 71
No 11
Abstain 25
Formally Object

(3 responses didn't contain an answer to this question)

Details

Responder HTML+RDFa Last Call Working DraftRationale
Arthur Jennings Yes
Masataka Yakura Yes
Doug Jones Yes
Sam Ruby Yes
Dzung Tran Yes
Adrian Bateman Yes
Eliot Graff Yes
Frank Olivier Yes
Travis Leithead Yes
Jacob Rossi Yes
Michael[tm] Smith Yes
Emilio Garcia Yes
Antonio Tapiador Abstain
Sandra Aguirrre Herrera Yes
Kangchan Lee Yes
Javier Cerviño Yes
Enrique Barra Yes
Channy Yun Abstain
Ohad Assulin Abstain
Michael Whitley Yes
Lawrence Rosen Yes
Jens Meiert Yes
Sean Hayes Yes
Dean Jackson Abstain
Adam Roben Abstain
Tony Ross Yes
Gavin Sharp Abstain
Kris Krueger Yes
Kimberly Blessing Yes
Lee Kowalkowski Yes
Cynthia Shelly Yes
Julian Reschke Abstain
Samuel Santos Yes
David Corvoysier Abstain
Matthew Turvey Yes
Christophe Eyrignoux Abstain
Raghavan Gurumurthy Yes The relationship between RDFa and Microdata (based on possible use cases) needs to be resolved.
Mayank Kumar Yes
Aryeh Gregor Yes
Alexey Proskuryakov Abstain
Stanley Manoski Abstain
Maciej Stachowiak Yes
Mathias Bynens Abstain
Kai Scheppe Yes I believe it is time to get full consideration of all stakeholders for this draft of the specification, which will only occur in last call status.
Simon Pieters No I think this specification fails the Avoid Needless Complexity and DOM Consistency design principles because it uses prefix-based indirection (which has caused confusion for Namespaces in XML) and xmlns-named attributes (which are parsed differently in text/html and XML).
James Graham No This spec imports a great deal of complexity into HTML from RDFa core. Existing implementations often forego implementing this complexity and instead make a simpler approximation. That alone suggests that there are fundamental problems with the spec that should be resolved before it goes to LC.

It seems likely that, in the future, web browsers will be expected to implement the complexity in this spec via an RDFa DOM API. I think this is the right time to fix the complexity problem rather than letting this spec progress along the Rec. track on the basis that it doesn't yet impose requirements on browsers only to find later that people are unwilling to implement the APIs due to the complexity in the data format with the spec difficult to change for Process reasons.
David Baron Abstain
Henri Sivonen No I think the differences between what the spec says and what software cited as implementation successes do have not been satisfactorily addressed. Also, I think the kind of prefix-based indirection used in this spec is inappropriate for a Web spec in the light of experience from Namespaces in XML.
Paul Bakaus Yes
Pasquale Popolizio Yes
Matthew MacKenzie Yes but.... the relationship between RDFa and Microdata (based on possible use cases) needs to be resolved.
Daniel Burnett Yes
Arthur Barstow Yes
Boris Zbarsky No I think this spec is heading in the wrong direction, and data showing that the premises that it's based on are incorrect has repeatedly been ignored.
Sorin Sbarnea Yes
Danny Ayers Yes
Karl Dubost Yes (This opinion doesn't represent the official position of Opera)

yes. It seems that it doesn't have any impact on browsers. Aka the language could be deployed and extensions be developed to cater for RDFa.

It has impact on authoring tools, and then there opinions seem to be more important, valuable. It has also impact for parsers who would do meaningful processing of this markup.

WARNING: RDFa DOM API might have consequences on browsers and the state of this specification is not yet satisfactory for browser implementers it seems. It will certainly create arguments and will not push to more consensus.
Shawn Medero No This document is lacking the support of the majority implementors probably because of the complexity (DOM consistency, prefix-indirection) it heaves upon them.
Edward O'Connor No (Speaking for myself only.) Web authors and RDFa processor implementors would be better served by an RDFa spec that described how to process in-the-wild Web content which purports to be RDFa, such as Open Graph Protocol, etc. Such Web content typically fails to define prefixes, or makes other authoring errors related to prefix indirection.
Ben Adida Yes
Tab Atkins Jr. No RDFa is too complex for the web, as evidenced by the fact that virtually every use of it on the web has errors. Successful RDFa parsers have to reverse-engineer existing content and figure out what the author intended, rather than following the spec. This is unarguably a disaster.
John Drinkwater Yes
Gavin Carothers Yes
David Singer Abstain
Li Li Yes
Cameron McCormack Abstain
Kornel Lesinski No
Dominik Tomaszuk Yes
Philippe Le Hégaret Yes
Daniel Glazman No This is one of surviving blurbs from the XHTML2 WG (not saying this is made for XHTML2). I don't see any browser vendor ever implement it or even have a use case for it.
Jack Jansen Yes
Dan Brickley Yes
Lachlan Hunt No I do not support the use of RDFa within HTML.
Mark Birbeck Yes
Graham Klyne Yes My formal objection is withdrawn on the understanding that on publication the given "This version" link will dereference to the same version of the document currently accessible using the above link.

The dated link given for "this version" (i.e. http://www.w3.org/TR/2011/WD-rdfa-in-html-20110524/) is broken, so there is no stable URI reference to this specific version for discussion or later reference.
Martin McEvoy Yes
Richard Schwerdtfeger Yes
Gez Lemon Yes
Per-Erik Brodin Yes
Bob Lund Yes
Toby Inkster Yes
Vincent Hardy Yes The relationship between RDFa and Microdata (based on possible use cases) needs to be resolved.
John Foliot Yes
Wayne Carr Yes
Scott Vesey Yes
Bryan Sullivan
Diego Moreno Yes
Soonbo Han Yes
Cameron Jones Yes
Benoit Piette Yes
Laura Carlson
Eric Carlson Abstain
Leif Halvard Silli Yes
Joshue O Connor Yes
Anand Samuel Edwin Yes The relationship between RDFa and Microdata (based on possible use cases) needs to be resolved.
Steve Faulkner Yes
Sally Cain Abstain
Geoff Freed
Charles McCathie Nevile Abstain This spec seems to have very little to do with browser makers. Implementation in browsers seems to be feasible with extensions (and we hope it remains that way), and usage does not appear to depend on implementation by browsers anyway.

This is Opera's formal position
Marco Ranon Abstain
Judy Brewer Abstain
Kensaku KOMATSU Yes
Mike Taylor Abstain
Manu Sporny Yes
Janina Sajka Abstain
Hidetaka Kimura Yes
Monika Trebo Abstain
Simon Myers No It's misguided, in its attempts to specify restrictions and processing that don't match how RDFa-like data is actually deployed in practice.
Doug Wright Abstain
Lynn Holdsworth Abstain

3. HTML Microdata Last Call Working Draft

The HTML Microdata is ready for progression to Last Call Working Draft status. Please provide your preference with respect to this specification by choosing ONE of the options below.

If you Formally Object to publishing this specification as a Last Call Working Draft, please state your objections below.

Keep in mind that you must actually state an objection, not merely cite someone else.

Summary

ChoiceAll responders
Results
Yes 68
No 6
Abstain 33
Formally Object

(3 responses didn't contain an answer to this question)

Details

Responder HTML Microdata Last Call Working DraftRationale
Arthur Jennings Yes
Masataka Yakura Yes
Doug Jones Yes
Sam Ruby Yes
Dzung Tran Yes
Adrian Bateman Yes
Eliot Graff Yes
Frank Olivier Yes
Travis Leithead Yes
Jacob Rossi Yes
Michael[tm] Smith Yes
Emilio Garcia No
Antonio Tapiador Abstain
Sandra Aguirrre Herrera Abstain
Kangchan Lee Yes
Javier Cerviño Yes
Enrique Barra Yes
Channy Yun Yes
Ohad Assulin Yes
Michael Whitley Yes
Lawrence Rosen Yes
Jens Meiert Yes
Sean Hayes Yes
Dean Jackson Abstain
Adam Roben Abstain
Tony Ross Yes
Gavin Sharp Yes
Kris Krueger Yes
Kimberly Blessing Yes
Lee Kowalkowski Yes
Cynthia Shelly Yes
Julian Reschke Abstain
Samuel Santos Abstain
David Corvoysier Abstain
Matthew Turvey Yes
Christophe Eyrignoux Abstain
Raghavan Gurumurthy Yes The relationship between RDFa and Microdata (based on possible use cases) needs to be resolved.
Mayank Kumar Yes
Aryeh Gregor Yes
Alexey Proskuryakov Abstain
Stanley Manoski Abstain
Maciej Stachowiak Yes
Mathias Bynens Yes
Kai Scheppe Yes I believe it is time to get full consideration of all stakeholders for this draft of the specification, which will only occur in last call status.
Simon Pieters Yes
James Graham Yes
David Baron Abstain
Henri Sivonen Yes
Paul Bakaus Yes
Pasquale Popolizio Yes
Matthew MacKenzie Yes but.... the relationship between RDFa and Microdata (based on possible use cases) needs to be resolved.
Daniel Burnett Yes
Arthur Barstow Yes
Boris Zbarsky Abstain
Sorin Sbarnea Yes
Danny Ayers Yes
Karl Dubost Abstain
Shawn Medero Yes
Edward O'Connor Yes
Ben Adida No
Tab Atkins Jr. Yes Given that this is part of HTML, and is only split out for obscure political reasons, I support publishing this.
John Drinkwater No
Gavin Carothers Abstain
David Singer Abstain
Li Li Yes
Cameron McCormack Abstain
Kornel Lesinski Abstain
Dominik Tomaszuk Abstain
Philippe Le Hégaret Yes
Daniel Glazman No I think this specification is not needed at all. The same effects could be achieved with a combination of existing attributes (title, aria, href, ...) and elements (title, link, ...). I don't understand the existence of this document.
Jack Jansen Abstain
Dan Brickley Abstain Some of Microdata's innovations could be folded into RDFa - eg. URI scheme for reverse domain name property naming. Suggest republishing as a discussion Note.
Lachlan Hunt Yes
Mark Birbeck No
Graham Klyne Abstain My formal objection is withdrawn on the understanding that on publication the given "This version" link will dereference to the same version of the document currently accessible using the above link.

The dated link given for "this version" (i.e. http://www.w3.org/TR/2011/WD-microdata-20110524/) is broken, so there is no stable URI reference to this specific version for discussion or later reference.


Martin McEvoy Abstain
Richard Schwerdtfeger Abstain
Gez Lemon Yes
Per-Erik Brodin Yes
Bob Lund Yes
Toby Inkster No
Vincent Hardy Yes The relationship between RDFa and Microdata (based on possible use cases) needs to be resolved.
John Foliot Abstain
Wayne Carr Yes same comment as for the html5 draft regarding the status section
Scott Vesey Yes
Bryan Sullivan
Diego Moreno Yes
Soonbo Han Yes
Cameron Jones Yes
Benoit Piette Yes
Laura Carlson
Eric Carlson Abstain
Leif Halvard Silli Yes
Joshue O Connor Abstain
Anand Samuel Edwin Yes The relationship between RDFa and Microdata (based on possible use cases) needs to be resolved.
Steve Faulkner Yes
Sally Cain Abstain
Geoff Freed
Charles McCathie Nevile Yes We're implementing this.

This is Opera's formal position
Marco Ranon Abstain
Judy Brewer Abstain
Kensaku KOMATSU Yes
Mike Taylor Yes
Manu Sporny Abstain
Janina Sajka Abstain
Hidetaka Kimura Yes
Monika Trebo Abstain
Simon Myers Yes This may not take off and gain popular support, but as a specification it is fine, and doesn't mislead people or cause problems with anything else. Either it's useful (in which case let's publish it) or it's harmless (in which case it doesn't matter, so publishing it is still OK).
Doug Wright Yes
Lynn Holdsworth Abstain

4. HTML Canvas 2D Context Last Call Working Draft

The HTML Canvas 2D Context specification is ready for progression to Last Call Working Draft status. Please provide your preference with respect to this specification by choosing ONE of the options below.

If you have strong objections to publishing this specification as a Last Call Working Draft, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else.

Summary

ChoiceAll responders
Results
Yes 95
No
Abstain 12
Formally Object

(3 responses didn't contain an answer to this question)

Details

Responder HTML Canvas 2D Context Last Call Working DraftRationale
Arthur Jennings Yes
Masataka Yakura Yes
Doug Jones Yes
Sam Ruby Yes
Dzung Tran Yes
Adrian Bateman Yes
Eliot Graff Yes
Frank Olivier Yes
Travis Leithead Yes
Jacob Rossi Yes
Michael[tm] Smith Yes
Emilio Garcia Yes
Antonio Tapiador Abstain
Sandra Aguirrre Herrera Abstain
Kangchan Lee Yes
Javier Cerviño Yes
Enrique Barra Yes
Channy Yun Yes
Ohad Assulin Yes
Michael Whitley Yes
Lawrence Rosen Yes
Jens Meiert Yes
Sean Hayes Yes
Dean Jackson Yes
Adam Roben Yes
Tony Ross Yes
Gavin Sharp Yes
Kris Krueger Yes
Kimberly Blessing Yes
Lee Kowalkowski Yes
Cynthia Shelly Yes
Julian Reschke Abstain
Samuel Santos Yes
David Corvoysier Yes
Matthew Turvey Yes
Christophe Eyrignoux Yes
Raghavan Gurumurthy Yes There are use cases for both an imperative and a declarative model for 2D graphics. The Canvas API addresses the former and the SVG specification addresses the later. These are complementary. However, they should explicitly share a common model for rendering.

While the Canvas and SVG specifications have very similar rendering models, there are some inconsistencies.

Cross-references
Where the specifications are consistent, the Canvas API should reference the SVG specification. For example, the Canvas specification should reference the SVG specification for the line style rendering model (since it pre-dates the Canvas specification), as is common in W3C specifications which typically normatively reference pre-existing specifications as appropriate.

Inconsistencies
There are differences between various aspects of the Canvas specification and the SVG specification. A simple example is the set of path commands that differs between the Canvas API (http://dev.w3.org/html5/2dcontext/#complex-shapes-paths) and the SVG markup (http://www.w3.org/TR/SVG/paths.html#PathData). Notably, the arc commands are different. The two specifications' rendering models and features should be more aligned in this area and others (transform methods and gradients are other examples).
Mayank Kumar Yes Canvas API and SVG specification are complimentary. The former addresses an imperative model for 2D graphics while the latter allowed for a declarative model. It would actually be great for the two to share a common rendering model. While they have very similar rendering models, at this point the two seem to have some inconsistencies.

Where the specifications are consistent, the Canvas API should reference the SVG specification. For example, the Canvas specification should reference the SVG specification for the line style rendering model (since it pre-dates the Canvas specification), as is common in W3C specifications which typically normatively reference pre-existing specifications as appropriate.

There are differences between various aspects of the Canvas specification and the SVG specification. A simple example is the set of path commands that differs between the Canvas API (http://dev.w3.org/html5/2dcontext/#complex-shapes-paths) and the SVG markup (http://www.w3.org/TR/SVG/paths.html#PathData). Notably, the arc commands are different. The two specifications' rendering models and features should be more aligned in this area and others (transform methods and gradients are other examples).
Aryeh Gregor Yes
Alexey Proskuryakov Yes
Stanley Manoski Yes
Maciej Stachowiak Yes
Mathias Bynens Yes
Kai Scheppe Yes I believe it is time to get full consideration of all stakeholders for this draft of the specification, which will only occur in last call status.
Simon Pieters Yes I support publication, but I have reservations about caretBlinkRate. I think caretBlinkRate is not useful enough to warrant implementation in browsers.
James Graham Yes
David Baron Yes
Henri Sivonen Yes
Paul Bakaus Yes
Pasquale Popolizio Yes
Matthew MacKenzie Yes There are use cases for both an imperative and a declarative model for 2D graphics. The Canvas API addresses the former and the SVG specification addresses the later. These are complementary. However, they should explicitly share a common model for rendering.

While the Canvas and SVG specifications have very similar rendering models, there are some inconsistencies.
Cross-references
Where the specifications are consistent, the Canvas API should reference the SVG specification. For example, the Canvas specification should reference the SVG specification for the line style rendering model (since it pre-dates the Canvas specification), as is common in W3C specifications which typically normatively reference pre-existing specifications as appropriate.

Inconsistencies
There are differences between various aspects of the Canvas specification and the SVG specification. A simple example is the set of path commands that differs between the Canvas API (http://dev.w3.org/html5/2dcontext/#complex-shapes-paths) and the SVG markup (http://www.w3.org/TR/SVG/paths.html#PathData). Notably, the arc commands are different. The two specifications' rendering models and features should be more aligned in this area and others (transform methods and gradients are other examples).
Daniel Burnett Yes
Arthur Barstow Yes
Boris Zbarsky Yes
Sorin Sbarnea Yes
Danny Ayers Yes
Karl Dubost Yes
Shawn Medero Yes
Edward O'Connor Yes (Speaking for myself only.) We need to fix the damage caused to this API by the ISSUE-131 decision, but I believe we can do so during this first Last Call period.
Ben Adida Yes
Tab Atkins Jr. Yes Given that this is part of HTML, and is only split out for obscure political reasons, I support publishing this.
John Drinkwater Yes While canvas isn’t the declarative system I would prefer to be used for the Web (it’s no SVG), this is complementary to it.
Gavin Carothers Yes
David Singer Yes
Li Li Yes
Cameron McCormack Yes
Kornel Lesinski Yes
Dominik Tomaszuk Yes
Philippe Le Hégaret Yes
Daniel Glazman Yes
Jack Jansen Yes
Dan Brickley Yes
Lachlan Hunt Yes
Mark Birbeck Yes
Graham Klyne Yes My formal objection is withdrawn on the understanding that on publication the given "This version" link will dereference to the same version of the document currently accessible using the above link.

The dated link given for "this version" (i.e. http://www.w3.org/TR/2011/LC-2dcontext-20110524/) is broken, so there is no stable URI reference to this specific version for discussion or later reference.
Martin McEvoy Yes
Richard Schwerdtfeger Yes Although, there are numerous accessibility issues/bugs that will need to be addressed, before the spec. leaves last call (http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0457.html), I do believe the spec. needs to receive comments from industry. Unfortunately, most developers will not provide those comments while the spec. is moving. Consequently, we typically have more than one last call draft in the W3C. So, to get industry feedback I voted yes.
Gez Lemon Yes
Per-Erik Brodin Yes
Bob Lund Yes
Toby Inkster Abstain
Vincent Hardy Yes There are use cases for both an imperative and a declarative model for 2D graphics. The Canvas API addresses the former and the SVG specification addresses the later. These are complementary. However, they should explicitly share a common model for rendering. 

While the Canvas and SVG specifications have very similar rendering models, there are some inconsistencies.

Where the specifications are consistent, the Canvas API should reference the SVG specification. For example, the Canvas specification should reference the SVG specification for the line style rendering model (since it pre-dates the Canvas specification), as is common in W3C specifications which typically normatively reference pre-existing specifications as appropriate. 

There are differences between various aspects of the Canvas specification and the SVG specification. A simple example is the set of path commands that differs between the Canvas API (http://dev.w3.org/html5/2dcontext/#complex-shapes-paths) and the SVG markup (http://www.w3.org/TR/SVG/paths.html#PathData). Notably, the arc commands are different. The two specifications' rendering models and features should be more aligned in this area and others (transform methods and gradients are other examples).
John Foliot Abstain
Wayne Carr Yes same comment as for the html5 draft regarding the status section
Scott Vesey Yes
Bryan Sullivan
Diego Moreno Yes
Soonbo Han Yes
Cameron Jones Yes
Benoit Piette Yes
Laura Carlson
Eric Carlson Yes
Leif Halvard Silli Yes
Joshue O Connor Yes
Anand Samuel Edwin Yes There are use cases for both an imperative and a declarative model for 2D graphics. The Canvas API addresses the former and the SVG specification addresses the later. These are complementary. However, they should explicitly share a common model for rendering.

While the Canvas and SVG specifications have very similar rendering models, there are some inconsistencies.

Cross-references
Where the specifications are consistent, the Canvas API should reference the SVG specification. For example, the Canvas specification should reference the SVG specification for the line style rendering model (since it pre-dates the Canvas specification), as is common in W3C specifications which typically normatively reference pre-existing specifications as appropriate.

Inconsistencies
There are differences between various aspects of the Canvas specification and the SVG specification. A simple example is the set of path commands that differs between the Canvas API (http://dev.w3.org/html5/2dcontext/#complex-shapes-paths) and the SVG markup (http://www.w3.org/TR/SVG/paths.html#PathData). Notably, the arc commands are different. The two specifications' rendering models and features should be more aligned in this area and others (transform methods and gradients are other examples).
Steve Faulkner Yes
Sally Cain Abstain
Geoff Freed
Charles McCathie Nevile Yes We may raise bugs/issues in last call - there are some areas we are not sure are a good idea. But it should go to further review.

This is Opera's formal position
Marco Ranon Abstain
Judy Brewer Abstain
Kensaku KOMATSU Yes
Mike Taylor Yes
Manu Sporny Abstain
Janina Sajka Yes Though there are significant a11y issues here as well.
Hidetaka Kimura Yes
Monika Trebo Abstain
Simon Myers Abstain
Doug Wright Yes
Lynn Holdsworth Abstain

5. HTML/XHTML Compatibility Authoring Guidelines Last Call Working Draft

The HTML/XHTML Compatibility Authoring Guidelines specification is ready for progression to Last Call Working Draft status. Please provide your preference with respect to this specification by choosing ONE of the options below.

If you Formally Object to publishing this specification as a Last Call Working Draft, please state your objections below.

Keep in mind that you must actually state an objection, not merely cite someone else.

Summary

ChoiceAll responders
Results
Yes 68
No 16
Abstain 23
Formally Object 1

(2 responses didn't contain an answer to this question)

Details

Responder HTML/XHTML Compatibility Authoring Guidelines Last Call Working DraftRationale
Arthur Jennings Yes
Masataka Yakura Yes
Doug Jones Yes
Sam Ruby Yes
Dzung Tran Yes
Adrian Bateman Yes
Eliot Graff Yes
Frank Olivier Yes
Travis Leithead Yes
Jacob Rossi Yes
Michael[tm] Smith Yes
Emilio Garcia Yes
Antonio Tapiador Abstain
Sandra Aguirrre Herrera Yes
Kangchan Lee Yes
Javier Cerviño Yes
Enrique Barra Abstain
Channy Yun Yes
Ohad Assulin Abstain
Michael Whitley Yes
Lawrence Rosen Yes
Jens Meiert Yes
Sean Hayes Yes
Dean Jackson Abstain
Adam Roben Abstain
Tony Ross Yes
Gavin Sharp Abstain
Kris Krueger Yes
Kimberly Blessing Yes
Lee Kowalkowski Yes
Cynthia Shelly Yes
Julian Reschke Abstain
Samuel Santos Yes
David Corvoysier Abstain
Matthew Turvey Yes
Christophe Eyrignoux Abstain
Raghavan Gurumurthy Yes
Mayank Kumar Yes
Aryeh Gregor Yes
Alexey Proskuryakov Abstain
Stanley Manoski Abstain
Maciej Stachowiak Yes
Mathias Bynens Yes
Kai Scheppe Yes I believe it is time to get full consideration of all stakeholders for this draft of the specification, which will only occur in last call status.
Simon Pieters No I think this document should be a Note-track WD instead of Rec-track LC, because it is in nature a support document with "guidelines" where all requirements are already stated in HTML5 and XML. Having this document as Rec-track will cause confusion and differences in the requirements.

I would support publication as a Note-track WD.
James Graham No This document should be a description of the intersection of existing drafts. It should not itself contain normative content and so should not be on the Rec. track.
David Baron No I don't think this document should be on the REC track.
Henri Sivonen No I think this document doesn't belong on the REC track, because it is supposed to document logical inferences from other REC-track documents. Also, I think publishing this document on the REC track sends the message that the W3C encourages Web authors to use polyglot markup and I think such implied encouragement would be bad due to the cost/benefit characteristics of using polyglot markup to solve problems compared to alternative solutions that have been identified.
Paul Bakaus Yes
Pasquale Popolizio Yes
Matthew MacKenzie Yes
Daniel Burnett Yes
Arthur Barstow Yes
Boris Zbarsky No I don't believe an informative note (which is what this is, in the end) should be on the REC track.
Sorin Sbarnea Yes
Danny Ayers Yes
Karl Dubost No (This opinion doesn't represent the official position of Opera)

The question is to move to Last Call for becoming a Recommendation. This document should not be a Rec but a Note. It is very helpful but should not be a mandatory document for content producers.
Shawn Medero No This should be published a "Note" because it is supporting material.
Edward O'Connor No (Speaking for myself only.) I don't think this document should be on the REC track, and would prefer it to end up as a Note. It only describs the logical implications of applying the normative requirements of HTML5 and XML to a document, and so shouldn't have any normative statements of its own.
Ben Adida Yes
Tab Atkins Jr. No This document should not contain any normative requirements (if it does, they should be part of HTML instead). Thus, it's silly to publish it on the Rec track. This is clearly intended to be a Note.
John Drinkwater No This should be an informative ‘Note’ instead.
Gavin Carothers Abstain
David Singer No I don't believe that a document that has no normative requirements should be on REC track.
Li Li Yes
Cameron McCormack Abstain
Kornel Lesinski Yes
Dominik Tomaszuk Yes
Philippe Le Hégaret Yes
Daniel Glazman No Implementing myself a content editor for html5 (both serializations), I am still uncertain about the usefulness of this document, in other terms I doubt implementors will refer to this document and really implement tools conformant to it. I think then this document should leave the REC track and become a Note.
Jack Jansen Abstain
Dan Brickley Yes
Lachlan Hunt Formally Object I object to this document being on the Rec-track. These are guidelines, and as such, they should be non-normative descriptions referring to the normative requirements in the HTML specification itself. If this document is to be published, it should instead be on the Note-track.

I will repeal this formal objection on the condition that this document is no longer indended to be published as a Recommendation.
Mark Birbeck Yes
Graham Klyne Yes My formal objection is withdrawn on the understanding that on publication the given "This version" link will dereference to the same version of the document currently accessible using the above link.

The link given for "this version" (i.e. http://dev.w3.org/html5/html-xhtml-author-guide/) is the same as the "editors latest draft" link, so the document cannot reasonably be expected to remain stable for discussion and later reference.
Martin McEvoy Yes
Richard Schwerdtfeger Abstain This is orthogonal to what I work on.
Gez Lemon Yes
Per-Erik Brodin Yes
Bob Lund Yes
Toby Inkster Yes
Vincent Hardy Yes
John Foliot Abstain
Wayne Carr Yes Most of the negative comments seem to oppose publishing guidelines as a W3C Recommendation. From the W3C Process Document: "A W3C Recommendation is a specification or set of guidelines". Best Practice Recs are one example of guidelines. This draft is important to us. We want it on the REC track, not a Note.

There are a lot of divergent views and we need to try to make this satisfactory for everyone. That's a better way to keep the wider community happy than forking.
Scott Vesey Yes
Bryan Sullivan
Diego Moreno Yes
Soonbo Han Yes
Cameron Jones Yes
Benoit Piette Abstain
Laura Carlson Yes
Eric Carlson No (Speaking only for myself) I do not think an informative note should be on the REC track.
Leif Halvard Silli Yes Note that the official name of this document is 'Polyglot Markup: HTML-Compatible XHTML Documents': http://lists.w3.org/Archives/Public/public-html/2011May/0260 As this name shows, the document is not only a "guidline". And the initial comments from TBL to the wg was that this was going to be a spec: http://lists.w3.org/Archives/Public/public-html/2010Jun/0225

The document mainly does two things:

1) It *describes* the common DOM subset of HTML and XHTML. Which should not be used against it. Even HTML5 itself is in many instances only a descriptions of facts that are indpedent of the spec itself, making HTML5 - in those respects - as subset.
2) It *defines* what the accepted and - more or less - *necessary* DOM deviations are. For example with regard to attributes such as xml:lang="", which has no effect in HTML.

Meanwhile:
* The specification process for this document has also impacted on HTML5 itself: this document had a correct description of what is required for @srcdoc in XML documents before HTML5 got it. So the document is not a pure subset, from a procedural point of view of how the document has become a reality. The creation of this document has also helped creating understanding, within the HTMLwg, and thus busting a few myths about HTML as well as XML, and could thus help doing the same outside the WG as well, if it is gets a proper publication.
* The specification process of this document revealed - and documented - many gotchas. (Though, it has to be said that much of what is in the document has been documented earlier on too, before it found its way to the document.) The World Wide Web needs to take part in the knowledge gathered in this document.
* With reference to a comment from Richard, Polyglot Markup is *not* orthogonal accessibility, and in particular not orthogonal to ARIA: The meaning of ARIA attributes can potentially be affected if a HTML document is served as XHTML without being made polyglot first: http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0502
In fact, the PF refused to make ARIA attributes less "XML-centric":
http://www.w3.org/WAI/PF/comments/details?comment_id=18
A decision which was confirmed by the Director: http://www.w3.org/2011/01/aria-lexical-processing
Which in turn lead to bug 11892 against HTML5: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11892

Authors/Tools coming from HTML: In general, this document is relevant not only to those who want to publish a document that can be served with different MIME types, but also to anyone accustomed to the auto-generated DOM of HTML and, for some reason, wants to publish HTML as XML.

Authors: A tool which implements Polyglot Markup would allow authors to ignore the irritating syntax difference and let them rather focus content and matter and browser compatibility.

Authoring tools coming from XML: for some authoring tools that are mainly focused on XML publishing, but which also want to be able to publish HTML, Polyglot Markup represents a profile they could implement. Like Boris hinted, there is no real need to support "pure" HTML syntax if the editing tool supports polyglot markup: " When would an editor that has a polyglot mode not want to use it?"
http://lists.w3.org/Archives/Public/public-html/2010May/0244

In many ways, this document presents the essense of HTML5: HTML5 itself is specced to be XML 1.0-compatible. Further more: many of the consequences drawn from the attempt to define the subset of HTML and XML, can also be found in HTML5 - but with different justification. For instance, Polyglot Markup bans the use of <[CDATA[]]> within <style> and <script>. Not because it is invalid in XML, it isn't even invalid in HTML5. It bans it because it is impossible to create a XML DOM and a HTML DOM that is equal when CDATA is present. This, in turn, leads to certain consequences w.r.t. what <script> and <style> can contain, which in turn favours keeping CSS and Javascript in external documents. The resulting separation of CSS and markup is an authoring styled that is favored by HTML5 and its editor too. So, on an edge: what in the HTML5 appear as overly purist attitude from the editor, in Polyglot Markup gets at least a tiny technical justification.

Publishing Polyglot Markup as a note instead, as some has sugged, could risks that it isn't taken seriously enough - just like the former Appendix C guidelines. Polyglot markup was not as simply defined as some of the no votes seem to suggest. Authors are *not* aware of the differences between XML and HTML. Therefore a properly wetted document should define this, in a specification like way. True Appendix C tools never emerged, and its status became disputed. One of the reasons being that there were no proper documentation - or authority - for it.

Polyglot Markup itself points out that "All web content need not be authored in polyglot markup. [snip] ". Thus the risk that authors think they "have" to make polyglot markup is low. Note as well that Appendix C being non-normative, did not cause authors to stop thinking that they "had" produce Appendix C XHTML (they failed to do it, but thought they did). A much better "prevention" against "unneccessary" use of the Polyglot Markkup format is the strict subset rules that the document defines.
Joshue O Connor Yes
Anand Samuel Edwin Yes
Steve Faulkner Yes
Sally Cain Abstain
Geoff Freed
Charles McCathie Nevile Yes We may object to this document becoming a Recommendation and instead suggest it become a Note.

This is Opera's formal position
Marco Ranon Abstain
Judy Brewer Abstain
Kensaku KOMATSU Yes
Mike Taylor No I support publication as a Note, not a REC-bound LC.
Manu Sporny Yes
Janina Sajka Abstain
Hidetaka Kimura Yes
Monika Trebo Abstain
Simon Myers No It makes no sense for this document to be normative. Given the normative nature of the HTML5 and XML specs, this document can helpfully describe the intersection of syntax valid in both, but its attempting to be a normative definition puts in it conflict with those other specs, thereby undermining its whole purpose.
Doug Wright No Should be Note
Lynn Holdsworth Abstain

6. HTML5: Techniques for providing useful text alternatives Last Call Working Draft

The HTML5: Techniques for providing useful text alternatives is ready for progression to Last Call Working Draft status. Please provide your preference with respect to this specification by choosing ONE of the options below.

If you Formally Object to publishing this specification as a Last Call Working Draft, please state your objections below.

Keep in mind that you must actually state an objection, not merely cite someone else.

Summary

ChoiceAll responders
Results
Yes 73
No 15
Abstain 18
Formally Object 2

(2 responses didn't contain an answer to this question)

Details

Responder HTML5: Techniques for providing useful text alternatives Last Call Working DraftRationale
Arthur Jennings Yes
Masataka Yakura Yes
Doug Jones Yes
Sam Ruby Yes
Dzung Tran Yes
Adrian Bateman Yes
Eliot Graff Yes
Frank Olivier Yes
Travis Leithead Yes
Jacob Rossi Yes
Michael[tm] Smith Yes
Emilio Garcia Yes
Antonio Tapiador Abstain
Sandra Aguirrre Herrera Yes
Kangchan Lee Yes
Javier Cerviño Yes
Enrique Barra Yes
Channy Yun Yes
Ohad Assulin Yes
Michael Whitley Yes
Lawrence Rosen Yes
Jens Meiert Yes
Sean Hayes Yes
Dean Jackson Abstain
Adam Roben Abstain
Tony Ross Yes
Gavin Sharp Abstain
Kris Krueger Yes
Kimberly Blessing Yes
Lee Kowalkowski Yes
Cynthia Shelly Yes
Julian Reschke Abstain
Samuel Santos Yes
David Corvoysier Abstain
Matthew Turvey Yes
Christophe Eyrignoux Abstain
Raghavan Gurumurthy Yes
Mayank Kumar Yes
Aryeh Gregor Yes
Alexey Proskuryakov Abstain
Stanley Manoski Yes
Maciej Stachowiak Yes
Mathias Bynens Yes
Kai Scheppe Yes I believe it is time to get full consideration of all stakeholders for this draft of the specification, which will only occur in last call status.
Simon Pieters No I think this document should be a Note-track WD instead of Rec-track LC, because it is in nature a support document with "techniques" where all requirements are supposed to be stated in HTML5. Having this document as Rec-track will cause confusion and differences in the requirements.

I would support publication as a Note-track WD.
James Graham No I think this document contains much that is good and helpful to authors and I fully support it being published by the WG. However I don't think that a "techniques" document should contain normative requirements and therefore I don't think it should be on the Rec. track. Anything normative currently in this document should instead be in the HTML5 spec. Any other approach leaves open the real possibility of conflicting normative documents.
David Baron Abstain
Henri Sivonen No This document says it normatively replaces sections in another deliverable of this WG that is also subject to this poll. I think Web authors aren't well served by the WG making its internal differences Someone Else's Problem by publishing contradictory REC-track documents and leaving it for readers to figure out.
Paul Bakaus Yes
Pasquale Popolizio Yes
Matthew MacKenzie Yes
Daniel Burnett Yes
Arthur Barstow Yes
Boris Zbarsky No This does not seem to be a REC-track topic; this should be a Note.
Sorin Sbarnea Yes
Danny Ayers No I believe it would be better to merge this document into the main spec, resolving any conflicts in the process.
Karl Dubost No (This opinion doesn't represent the official position of Opera)

Answering to the question entering Last Call to become a REC. Same rational than the question 6. This is an helpful document but not a mandatory document.
Shawn Medero No This should be published a "Note" because it is supporting material.
Edward O'Connor No (Speaking for myself only.) I don't think this document should be on the REC track, and would prefer it to end up as a Note. It is disingenuous for this WG to publish multiple documents on the REC track which contain contradictory normative requirements.
Ben Adida Yes
Tab Atkins Jr. No This document should not contain any normative requirements (if it does, they should be part of HTML instead). Thus, it's silly to publish it on the Rec track. This is clearly intended to be a Note.
John Drinkwater No
Gavin Carothers Yes
David Singer Yes
Li Li Yes
Cameron McCormack Abstain
Kornel Lesinski Yes
Dominik Tomaszuk Abstain
Philippe Le Hégaret Yes
Daniel Glazman No Conformance to this document is just impossible to enforce and I don't see a content editing environment provide guidelines or even control on how to fill a @alt attribute textfield. In my opinion, this does not deserve a technical WD and it should be an informative Note of the HTML WG, or better a Guideline discussed edited and released by the accessibility groups of the W3C, not the HTML WG.
Jack Jansen Abstain
Dan Brickley Yes
Lachlan Hunt Formally Object I object to this document being on the Rec-track. These are guidelines, and as such, they should be non-normative descriptions referring to the normative requirements in the HTML specification itself. If this document is to be published, it should instead be on the Note-track.

I also object to this document claiming to replace sections of HTML5. The WG should not publish or endorse specifications that directly contradict another specification from the same WG. Instead, any reasonable portions of this document should ultimately be merged with the HTML specification and unreasonable portions should be dropped.
Mark Birbeck Abstain
Graham Klyne Yes My formal objection is withdrawn on the understanding that on publication the given "This version" link will dereference to the same version of the document currently accessible using the above link.

The dated link given for "this version" (i.e. http://www.w3.org/TR/2011/WD-alt-techniques-20110524/) is broken, so there is no stable URI reference to this specific version for discussion or later reference.
Martin McEvoy Yes
Richard Schwerdtfeger Yes
Gez Lemon Yes
Per-Erik Brodin Yes
Bob Lund Yes
Toby Inkster Abstain
Vincent Hardy Yes
John Foliot Yes
Wayne Carr Yes
Scott Vesey Yes
Bryan Sullivan
Diego Moreno Yes
Soonbo Han Yes
Cameron Jones Yes
Benoit Piette Abstain
Laura Carlson Yes
Eric Carlson No (Speaking only for myself) While this document has useful information, I believe that publishing it as Rec track will be confusing as it contradicts normative text in the HTML5 spec. Differences between the two documents should be reconciled and this document should be published as a Note.
Leif Halvard Silli Yes
Joshue O Connor Yes
Anand Samuel Edwin Yes
Steve Faulkner Yes
Sally Cain Abstain
Geoff Freed
Charles McCathie Nevile Yes We are likely to object to this document becoming a recommendation. Normative requirements should be adopted into the HTML5 specification, and the informative techniques, which we consider valuable, should be in a NOTE, analagous to the WCAG techniques notes and similar material.

This is Opera's formal position
Marco Ranon Yes
Judy Brewer Yes The guidance in this document should be non-normative, and should be Note track rather than Rec track. Additionally, this document contains useful information that is relevant to more than HTML5 alone. The further development of this guidance should be coordinated with the WCAG WG: some of the guidance in this document is appropriate for WCAG 2.0 implementation techniques, which have Note status and are periodically updated to incorporate new information.
Kensaku KOMATSU Yes
Mike Taylor No I support publication as a Note, not a REC-bound LC.
Manu Sporny Abstain
Janina Sajka Formally Object This document was created to teach this WG about alt--because earlier HTML spec
drafts were so woefully wrong in how alt was being specified. And, now this
group is to be the expert on what constitutes appropriate alternative text representations?
This is not the proper WG for this document, niehter at the current time nor
in the future as maintanance on it will be needed.
Hidetaka Kimura Yes
Monika Trebo Yes This document contains very valuable information. I would however, prefer this to be merged with the HTML5 spec. It is confusing to have text alternatives described in the HTML spec and a second document potentially replacing, contradicting etc. the HTML5 specification. We cannot leave it up to web authors/designers to compare if any and which parts of these 2 documents are redundant, complement or contradict each other and figure out what to do.

@longdesc is missing. I am not convinced that aria-describedby will be more widely accepted and used as @longdesc. It cannot point off-page, therefore forces web authors to put alternative text for images, graphs,.. they wish to use repeatedly within their web site into every single page rather than pointing to one HTML file containing the long description(s).
Screen readers seem to give the user a choice as to whether they want to hear the long description, whereas aria-describedby is read aloud every time the screen reader comes across it (http://lists.w3.org/Archives/Public/public-html/2010Aug/0262.html).
Aria-describedby is not backwards-compatible.

Other options, like including a text link with the image may not be accepted by designers for aesthetic reasons.
Simon Myers No <img alt="..."> is a core part of HTML5, so any normative requirements on it should be in the main HTML5 spec, having equal status along with the requirements on all other elements.
Doug Wright No Should be Note
Lynn Holdsworth Abstain

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

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.128 2015/07/01 13:26:14 kahan Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)