w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
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:
- HTML5 Last Call Working Draft
- HTML+RDFa Last Call Working Draft
- HTML Microdata Last Call Working Draft
- HTML Canvas 2D Context Last Call Working Draft
- HTML/XHTML Compatibility Authoring Guidelines Last Call Working Draft
- 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
| Choice | All responders |
|---|---|
| Results | |
| Yes | 95 |
| No | 9 |
| Abstain | 6 |
| Formally Object |
Details
| Responder | HTML5 Last Call Working Draft | Rationale |
|---|---|---|
| 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 Oliver 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 | |
| Theresa 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 Hegaret | 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. |
| Chaals 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
| Choice | All responders |
|---|---|
| Results | |
| Yes | 71 |
| No | 11 |
| Abstain | 25 |
| Formally Object |
Details
| Responder | HTML+RDFa Last Call Working Draft | Rationale |
|---|---|---|
| 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 Oliver 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. |
| Theresa 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 Hegaret | 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 | ||
| Chaals 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
| Choice | All responders |
|---|---|
| Results | |
| Yes | 68 |
| No | 6 |
| Abstain | 33 |
| Formally Object |
Details
| Responder | HTML Microdata Last Call Working Draft | Rationale |
|---|---|---|
| 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 Oliver 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 | |
| Theresa 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 Hegaret | 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 | ||
| Chaals 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
| Choice | All responders |
|---|---|
| Results | |
| Yes | 95 |
| No | |
| Abstain | 12 |
| Formally Object |
Details
| Responder | HTML Canvas 2D Context Last Call Working Draft | Rationale |
|---|---|---|
| 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 Oliver 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 | |
| Theresa 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 Hegaret | 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 | ||
| Chaals 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
| Choice | All responders |
|---|---|
| Results | |
| Yes | 68 |
| No | 16 |
| Abstain | 23 |
| Formally Object | 1 |
Details
| Responder | HTML/XHTML Compatibility Authoring Guidelines Last Call Working Draft | Rationale |
|---|---|---|
| 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 Oliver 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. |
| Theresa 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 Hegaret | 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 | ||
| Chaals 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
| Choice | All responders |
|---|---|
| Results | |
| Yes | 73 |
| No | 15 |
| Abstain | 18 |
| Formally Object | 2 |
Details
| Responder | HTML5: Techniques for providing useful text alternatives Last Call Working Draft | Rationale |
|---|---|---|
| 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 Oliver 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. |
| Theresa 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 Hegaret | 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 | ||
| Chaals 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
- Arthur Jennings: last responded on 15, May 2011 at 21:11 (UTC)
- Masataka Yakura: last responded on 16, May 2011 at 00:28 (UTC)
- Doug Jones: last responded on 16, May 2011 at 00:43 (UTC)
- Sam Ruby: last responded on 16, May 2011 at 20:52 (UTC)
- Dzung Tran: last responded on 16, May 2011 at 21:03 (UTC)
- Adrian Bateman: last responded on 17, May 2011 at 00:05 (UTC)
- Eliot Graff: last responded on 17, May 2011 at 00:16 (UTC)
- Frank Olivier: last responded on 17, May 2011 at 05:41 (UTC)
- Travis Leithead: last responded on 17, May 2011 at 05:46 (UTC)
- Jacob Rossi: last responded on 17, May 2011 at 05:52 (UTC)
- Michael[tm] Smith: last responded on 17, May 2011 at 08:22 (UTC)
- Emilio Garcia: last responded on 17, May 2011 at 09:27 (UTC)
- Antonio Tapiador: last responded on 17, May 2011 at 09:48 (UTC)
- Sandra Aguirrre Herrera: last responded on 17, May 2011 at 10:18 (UTC)
- Kangchan Lee: last responded on 17, May 2011 at 10:22 (UTC)
- Javier Cerviño: last responded on 17, May 2011 at 10:25 (UTC)
- Enrique Barra: last responded on 17, May 2011 at 10:28 (UTC)
- Channy Yun: last responded on 17, May 2011 at 10:36 (UTC)
- Ohad Assulin: last responded on 17, May 2011 at 10:42 (UTC)
- Michael Whitley: last responded on 17, May 2011 at 14:25 (UTC)
- Lawrence Rosen: last responded on 17, May 2011 at 15:42 (UTC)
- Jens Oliver Meiert: last responded on 17, May 2011 at 15:55 (UTC)
- Sean Hayes: last responded on 17, May 2011 at 16:11 (UTC)
- Dean Jackson: last responded on 17, May 2011 at 17:21 (UTC)
- Adam Roben: last responded on 17, May 2011 at 17:26 (UTC)
- Tony Ross: last responded on 17, May 2011 at 17:29 (UTC)
- Gavin Sharp: last responded on 17, May 2011 at 17:34 (UTC)
- Kris Krueger: last responded on 17, May 2011 at 18:11 (UTC)
- Kimberly Blessing: last responded on 17, May 2011 at 20:52 (UTC)
- Lee Kowalkowski: last responded on 17, May 2011 at 20:55 (UTC)
- Cynthia Shelly: last responded on 17, May 2011 at 20:58 (UTC)
- Julian Reschke: last responded on 18, May 2011 at 07:12 (UTC)
- Samuel Santos: last responded on 18, May 2011 at 11:52 (UTC)
- David Corvoysier: last responded on 18, May 2011 at 12:25 (UTC)
- Matthew Turvey: last responded on 18, May 2011 at 12:39 (UTC)
- Christophe Eyrignoux: last responded on 18, May 2011 at 14:59 (UTC)
- Raghavan Gurumurthy: last responded on 18, May 2011 at 20:35 (UTC)
- Mayank Kumar: last responded on 18, May 2011 at 21:16 (UTC)
- Aryeh Gregor: last responded on 18, May 2011 at 23:42 (UTC)
- Alexey Proskuryakov: last responded on 19, May 2011 at 00:40 (UTC)
- Stanley Manoski: last responded on 19, May 2011 at 04:36 (UTC)
- Maciej Stachowiak: last responded on 19, May 2011 at 05:50 (UTC)
- Mathias Bynens: last responded on 19, May 2011 at 07:08 (UTC)
- Kai Scheppe: last responded on 19, May 2011 at 10:38 (UTC)
- Simon Pieters: last responded on 19, May 2011 at 10:47 (UTC)
- James Graham: last responded on 19, May 2011 at 10:47 (UTC)
- David Baron: last responded on 19, May 2011 at 11:40 (UTC)
- Henri Sivonen: last responded on 19, May 2011 at 11:55 (UTC)
- Paul Bakaus: last responded on 19, May 2011 at 12:03 (UTC)
- Pasquale Popolizio: last responded on 19, May 2011 at 12:20 (UTC)
- Matthew MacKenzie: last responded on 19, May 2011 at 12:53 (UTC)
- Daniel Burnett: last responded on 19, May 2011 at 13:09 (UTC)
- Arthur Barstow: last responded on 19, May 2011 at 13:17 (UTC)
- Boris Zbarsky: last responded on 19, May 2011 at 13:42 (UTC)
- Sorin Sbarnea: last responded on 19, May 2011 at 13:49 (UTC)
- Danny Ayers: last responded on 19, May 2011 at 15:27 (UTC)
- Karl Dubost: last responded on 19, May 2011 at 15:50 (UTC)
- Shawn Medero: last responded on 19, May 2011 at 16:20 (UTC)
- Theresa O'Connor: last responded on 19, May 2011 at 16:27 (UTC)
- Ben Adida: last responded on 19, May 2011 at 16:29 (UTC)
- Tab Atkins Jr.: last responded on 19, May 2011 at 16:38 (UTC)
- John Drinkwater: last responded on 19, May 2011 at 16:47 (UTC)
- Gavin Carothers: last responded on 19, May 2011 at 16:59 (UTC)
- David Singer: last responded on 19, May 2011 at 17:52 (UTC)
- Li Li: last responded on 19, May 2011 at 20:12 (UTC)
- Cameron McCormack: last responded on 19, May 2011 at 21:50 (UTC)
- Kornel Lesinski: last responded on 19, May 2011 at 22:54 (UTC)
- Dominik Tomaszuk: last responded on 20, May 2011 at 08:04 (UTC)
- Philippe Le Hegaret: last responded on 20, May 2011 at 08:06 (UTC)
- Daniel Glazman: last responded on 20, May 2011 at 08:39 (UTC)
- Jack Jansen: last responded on 20, May 2011 at 08:44 (UTC)
- Dan Brickley: last responded on 20, May 2011 at 08:50 (UTC)
- Lachlan Hunt: last responded on 20, May 2011 at 11:23 (UTC)
- Mark Birbeck: last responded on 20, May 2011 at 13:05 (UTC)
- Graham Klyne: last responded on 20, May 2011 at 13:33 (UTC)
- Martin McEvoy: last responded on 20, May 2011 at 15:37 (UTC)
- Richard Schwerdtfeger: last responded on 20, May 2011 at 15:55 (UTC)
- Gez Lemon: last responded on 20, May 2011 at 17:17 (UTC)
- Per-Erik Brodin: last responded on 20, May 2011 at 17:24 (UTC)
- Bob Lund: last responded on 20, May 2011 at 19:53 (UTC)
- Toby Inkster: last responded on 20, May 2011 at 21:31 (UTC)
- Vincent Hardy: last responded on 20, May 2011 at 21:37 (UTC)
- John Foliot: last responded on 21, May 2011 at 02:44 (UTC)
- Wayne Carr: last responded on 21, May 2011 at 04:28 (UTC)
- Scott Vesey: last responded on 21, May 2011 at 04:28 (UTC)
- Bryan Sullivan: last responded on 21, May 2011 at 04:41 (UTC)
- Diego Moreno: last responded on 21, May 2011 at 12:54 (UTC)
- Soonbo Han: last responded on 21, May 2011 at 16:51 (UTC)
- Cameron Jones: last responded on 21, May 2011 at 17:01 (UTC)
- Benoit Piette: last responded on 21, May 2011 at 17:03 (UTC)
- Laura Carlson: last responded on 21, May 2011 at 18:48 (UTC)
- Eric Carlson: last responded on 21, May 2011 at 19:57 (UTC)
- Leif Halvard Silli: last responded on 21, May 2011 at 23:56 (UTC)
- Joshue O'Connor: last responded on 22, May 2011 at 07:51 (UTC)
- Anand Samuel Edwin: last responded on 22, May 2011 at 09:45 (UTC)
- Steve Faulkner: last responded on 22, May 2011 at 20:08 (UTC)
- Sally Cain: last responded on 22, May 2011 at 20:20 (UTC)
- Geoff Freed: last responded on 22, May 2011 at 20:30 (UTC)
- Chaals Nevile: last responded on 22, May 2011 at 20:49 (UTC)
- Marco Ranon: last responded on 22, May 2011 at 22:43 (UTC)
- Judy Brewer: last responded on 22, May 2011 at 22:50 (UTC)
- Kensaku KOMATSU: last responded on 23, May 2011 at 01:19 (UTC)
- Mike Taylor: last responded on 23, May 2011 at 01:43 (UTC)
- Manu Sporny: last responded on 23, May 2011 at 02:06 (UTC)
- Janina Sajka: last responded on 23, May 2011 at 02:24 (UTC)
- Hidetaka Kimura: last responded on 23, May 2011 at 02:50 (UTC)
- Monika Trebo: last responded on 23, May 2011 at 03:27 (UTC)
- Simon Myers: last responded on 23, May 2011 at 07:44 (UTC)
- Doug Wright: last responded on 23, May 2011 at 08:33 (UTC)
- Lynn Holdsworth: last responded on 23, May 2011 at 17:25 (UTC)
Everybody has responded to this questionnaire.
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