W3C WBS Home

Results of Questionnaire Details element as a replacement for the summary attribute

The results of this questionnaire are available to anybody.

This questionnaire was open from 2010-02-22 to 2010-02-25.

16 answers have been received.

Jump to results for question:

  1. Summary vs details
  2. Position of details
  3. Replacing summary in details with button
  4. @noflow
  5. Change proposal for summary and details

1. Summary vs details

Do you support replacing @summary with <details>?

Summary

ChoiceAll responders
Results
yes 7
no 7

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

Details

Responder Summary vs detailsComments
Ian Hickson I support making summary="" non-conforming and suggesting many alternatives, including but not limited to using <details>.
Steve Faulkner yes
Martin Kliehm no I support Laura's rationale. The main point was that @summary is not visible, and that's a good thing. People will not use <details> if it results in a button to appear on hover. We don't want another broken Microsoft @alt/tooltip implementation to repeat, so this feature will not encourage, but discourage authors to use it.

What people outside the TF criticized was that the attribute value is not visible, so authors would ignore it. But I think that's not true, as it's not an issue of client software, it's an issue of authoring tools. Authoring tools must be required to allow editing of the summary attribute, then it will be available to users.
Denis Boudreau no I agree with Laura's and Martin's rationale above. @summary needs to remain an attribute, usable only by those who actually need it. I believe <details> could be a good idea, but I fail to understand why it would ever be relevant for a sighted user.
Gez Lemon no I agree that it's generally better to use elements than attributes to provide text, but not in the case of the summary for a table. The purpose is provide a concise overview of the structure, and I think an attribute is more appropriate.
Matthew May no I think the proposal is overly complicated for authors, which leads me to believe it won't be used. It requires additional effort on the part of authoring tools and AT, and reeducation on the part of authors. It also presents discoverability issues to users.

Frankly, this looks more like the kind of hack we'd implement after the spec has shipped than something that fits cleanly within the scope of HTML5. We should not resign ourselves to this level of contortion at this phase of the development of the spec.
Gregory Rosmaita i could not select an option because i support replacing the summary attribute with the summary element, and i would have liked the first question of this survey to have been a chioce between summary as an attribute and summary as an element;

if authors and developers are used to the concept of using the summary attribute for the TABLE element in HTML4, why not simply change summary from an attribute to an element (regardless of what that element is named)? as an element, summary provides those who have actually used the summary attribute, with capabilities which were not possible when summary was an attribute; one of the internationalization issues authors have faced when using the summary attribute is how to provide multi-lingual versions of information which is limited to an attribute value, without the possibility of programmatically indicating natural language switches, through the use of the lang attribute;

if authors are as ignorant of the HTML4 attribute summary as some have claimed, then they won't be confused by an HTML5 element named summary which is the child of CAPTION;

bottom line: in order for a summarization of a table's contents to be of real utility, the summary's delivery mechanism needs to be able to support "rich content" -- that is, markup, such as use of the lang attribute to programatically indicate a natural language switch where multi-lingual versions of the summarizing information is required); ideally, such information should, therefore, be contained in an element, to ensure that an author can use standard markup to annotate/describe the table (such as ABBR, DFN, etc.), although i would NOT allow anchors or other interactive elements to be used in the summary/summarization element;
John Foliot yes I am beginning to think that this 'pattern' could also be used w.r.t./ to replace @longdesc: <img ...><details></details></img>
Cynthia Shelly yes
Sally Cain no I support Laura's comment in her feedback
Joshue O Connor yes However, I am perfectly happy to support Laura Carlsons' proposal re: the summary attribute still being valid and conforming. However, due to the the current status of @summary in the spec and the history of the issue.

* Requires user agents to make the summary attribute visible on demand
with some type of a preference or switch in the user agent/browser.

* Replaces current spec text with suggested text.

an advantage of using the <details> element as a child of <caption> is that it allows the author to provide additional information to the user (that may be needed) that goes beyond /just/ the description of the table. Also would <details> have the ability to hold semantically rich data (eg. Structured content)?
Wendy Chisholm yes People with learning and reading disabilities will also find this information helpful. We will get more mileage out of proposals based on universal design principles and thinking about how accessibility features can be more like curbcuts--what are the unexpected uses? Using an element instead of an attribute also puts us in sync with internationalization best practices.
aurélien levy yes as long as summary is obsolete but conforming
Shelley Powers no The details element is a declarative animation replacement for a well known packaged set of JavaScript behaviors known as an 'expando' section, or accordion. By its nature, the label for the details element, defined using the summary element, is visible by default, and the body is visible once the label is clicked. What you're suggesting is counter to the behavior of both the element, and the well known widget-like object details is supposedly replacing.

It doesn't make sense to take an element supposedly representing a well known behavior, and change its behavior just because it becomes part of an HTML table. This will cause a great deal of confusion for authors and web designers -- so much so that I find it highly unlikely anyone would use it for the purpose this proposal sees it being used.

In addition, I favor Laura Carlson's proposal, especially in light of Gez Lemon's note about the benefits of using an attribute to describe the table structure. We don't want a structured element response. All we want is a simple text string that provides a brief overview of the table structure. No one has shown that more than this is needed.
Laura Carlson no This is a well-intentioned proposal that fails to address what the summary attribute is currently intended to do. For something like a table summary, it seems to make more sense to be an attribute; the purpose of the summary attribute is to provide a *concise* overview of the structure of the table.
http://juicystudio.com/article/purpose-of-the-summary-attribute.php

Encouraging people to use markup to provide a long description/details for the table is counter to the purpose of a summary. WAI-ARIA already has a mechanism to describe long descriptions that can be used with any object.

A sighted person would rarely if ever find a table summary useful. The summary attribute is akin to the alt attribute for an image. A text alternative for an image is not rendered with the image. Text alternatives are there for people who cannot perceive the image. The same principle applies to the summary attribute.

While summary information could be provided in visible text it is highly doubtful that authors would generally provide it because it is redundant.

Moreover, making it visible by default would actively encourage people not to provide an overview of the structure. If a table summary was visually rendered by default with visible text, or a button that's revealed on focus, designers and marketers will not use it for it's intended purpose. Designers and marketers will not want their visual designs changed/ruined; whether that's with visible text, or a button that's revealed on focus. A button would most probably be abused and used for other purposes. Many times tables need to be "aesthetically pleasing" to any stakeholders who may have issues with the table being explained in a way that is visible to all users.

User agents providing an option to reveal the content of the summary attribute provides a practical method for developers who want a tool to check summary text and keep it up to date. It would also allow the summary attribute to keep it's purpose in aiding those with disabilities. User agents should be encouraged to make summary visible on demand (not by default) by providing a preference or switch in the browser or user agent. This is discussed in the user agent list Toggle Metadata visibility.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2009OctDec/0103.html

Access for people with disabilities is essential. Features should not be made obsolete if not all users can fully make use of them but rather alternative/equivalent mechanisms must be provided when needed. Including the summary attribute in the specification as a valid option provides an equitable solution and reasonable accommodation as its use allows users of screen readers the opportunity to hear summary information for complex tables.

As Gez mentioned the summary attribute works. If it's been misused in the past, the solution is to provide better guidance on its usage, perhaps along the lines of Steve's "Techniques for providing useful text alternatives".
http://dev.w3.org/html5/alt-techniques/
Maybe consider expanding that primer to include sections on accessibility techniques for summary, canvas, media, etc.

Also as Gez said in an article comment it would be good to find out if a text summary is in fact useful for sighted people with learning disabilities. Anything Wendy, or anyone, could provide to explain how people with learning difficulties find text descriptions aid understanding for things that are visually evident would be very helpful. Would the summary text actually hinder sighted people with learning difficulties, as it describes what is visually evident? The work Gez has done seems to indicate that it would hinder rather than help. But this is an under-researched area. Perhaps a user agent visibility option would be of use to them.
http://juicystudio.com/article/purpose-of-the-summary-attribute.php#comment10

Making the summary attribute valid and conforming should happen NOW as PF previously recommended.
http://lists.w3.org/Archives/Public/public-html/2008Aug/0213.html
http://lists.w3.org/Archives/Public/www-archive/2009Jun/0026.html

Please reference my alternate table summary proposal for further rationale.
http://www.w3.org/html/wg/wiki/ChangeProposals/SummaryAttribute20100222
Maciej Stachowiak yes <All answers on this survey are with HTML WG co-chair hat off.>

I believe that overall, this change is a positive step for accessibility. I see three benefits:

1) A properly attached <details> element is visible by default, and can be made conditionally visible on hover or focus. This is a good default, because it makes it more likely that it will hold good data.

2) An element (as opposed to an attribute) can hold markup, not just plain text.

3) The <details> proposal can provide beneficial explanatory information to other disability groups besides the blind, such as the cognitively disabled, and low-vision users relying on magnification and high-contrast displays. (Information can still be targeted more selectively using CSS media queries.)

2. Position of details

Should <details> be a child of <caption> or <table>?

Summary

ChoiceAll responders
Results
&lt;details&gt; should be a child of &lt;caption&gt;. 3
&lt;details&gt; should be a child of &lt;table&gt;. 3
Both approaches should be supported. 2

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

Details

Responder Position of detailsComments
Ian Hickson It can't be a child of <table> in text/html, due to parsing issues, and it is probably unwise to have different content models for <table> in XHTML and HTML (we already have a problem with <tr>). Whether it's a child of <caption> or <figcaption> or just near the table, though, should be up to the author, IMHO.
Steve Faulkner i don't have an opinion on this
Martin Kliehm &lt;details&gt; should be a child of &lt;table&gt;.
Denis Boudreau Where's my "Neither options are acceptable" radio button?
Gez Lemon There should have been a neither option for those who don't support details at all. Ian's response indicates that having it as a child of table isn't feasible, and it's not a child of caption - the summary is a summary of the table, not a summary of the caption element.
Matthew May
Gregory Rosmaita &lt;details&gt; should be a child of &lt;caption&gt;. whatever the summary element's name, it should be a child of CAPTION, and should be considered a strong "hint" by the author, which is NOT rendered by default, thereby making it possible for multiple non-mutually exclusive alternative renderings of the summary's contents through user agent configuration; any "button" type mechanism could be one option offered by a user agent, just as user agents should allow users to flag FORM controls without explicit "submit" mechanisms and provide a UA user interface control for any FORM control that lacks an explicit "submit" mechanism;
John Foliot Both approaches should be supported.
Cynthia Shelly Both approaches should be supported. I can live with any of these options
Sally Cain None of the above
Joshue O Connor &lt;details&gt; should be a child of &lt;caption&gt;. I would be happy for <details> to be a child of <caption> but think it may not be suitable for <table> as @summary already performs this function. However, does the use of <details> element either as a child of <caption> etc really improve the functionality? If so the it is a good idea, if not then @summary should suffice and the spec should just retain it and promote its usage.
Wendy Chisholm &lt;details&gt; should be a child of &lt;table&gt;.
aurélien levy &lt;details&gt; should be a child of &lt;table&gt;.
Shelley Powers I don't support either option.
Laura Carlson None of the above.
Maciej Stachowiak &lt;details&gt; should be a child of &lt;caption&gt;. <All answers on this survey are with HTML WG co-chair hat off.>

<details> as a direct child of <table>. Henri Sivonen reports that is incompatible with legacy HTML parsing; the <details> would end up popping out of the table and appearing above it. It would be quite challenging to fix this in the HTML5 parsing algorithm, and even if it gets fixed, it will be a showstopper for deployment to the current generation of browsers until all of them update to the new parsing algorithm.

I think the much increased barriers to deployment are not worth the potential semantic benefit of putting <details> directly under <table>.

To address a concern I saw elsewhere in the comments: it's definitely possible to have <details> inside <caption> without having a visible caption at all. This demo I made shows how: http://webkit.org/demos/hover-summary/example2.html

3. Replacing summary in details with button

Do you support replacing <summary> in <details> with <button>?

This would require re-opening issue 83, and will be moved to a separate change request if it gains consensus.

Summary

ChoiceAll responders
Results
yes 3
no 12

(1 response didn't contain an answer to this question)

Details

Responder Replacing summary in details with buttonComments
Ian Hickson no Using a form-associated element in <details> would conflict with the form submission algorithm.
Steve Faulkner i don't have an opinion on this
Martin Kliehm no
Denis Boudreau no Again, I'm 100% with Laura's rationale on this.
Gez Lemon no Same reasons as Laura and Ian.
Matthew May no
Gregory Rosmaita no this strikes me as: 1) illogical (reuse of a FORM element in TABLE) and 2) D-link-2010
John Foliot yes
Cynthia Shelly yes If we move @summary to <details>, having the <summary> child of details will be very confusing to authors. I could live with something other than <button>, though I think it's the best semantic match.
Sally Cain no
Joshue O Connor no I don't really like the idea, on examination. It may be in line with current WG thinking etc but in reality could cause usability issues etc.
Wendy Chisholm yes The functionality of the open/close is a button.
aurélien levy no make summary render like button
Shelley Powers no Oh goodness no.
Laura Carlson no This is a well-intentioned proposal that fails to address what the summary attribute is currently intended to do. For something like a table summary, it seems to make more sense to be an attribute; the purpose of the summary attribute is to provide a *concise* overview of the structure of the table.
http://juicystudio.com/article/purpose-of-the-summary-attribute.php

Encouraging people to use markup to provide a long description/details for the table is counter to the purpose of a summary. WAI-ARIA already has a mechanism to describe long descriptions that can be used with any object.

A sighted person would rarely if ever find a table summary useful. The summary attribute is akin to the alt attribute for an image. A text alternative for an image is not rendered with the image. Text alternatives are there for people who cannot perceive the image. The same principle applies to the summary attribute.

While summary information could be provided in visible text it is highly doubtful that authors would generally provide it because it is redundant.

Moreover, making it visible by default would actively encourage people not to provide an overview of the structure. If a table summary was visually rendered by default with visible text, or a button that's revealed on focus, designers and marketers will not use it for it's intended purpose. Designers and marketers will not want their visual designs changed/ruined; whether that's with visible text, or a button that's revealed on focus. A button would most probably be abused and used for other purposes. Many times tables need to be "aesthetically pleasing" to any stakeholders who may have issues with the table being explained in a way that is visible to all users.

User agents providing an option to reveal the content of the summary attribute provides a practical method for developers who want a tool to check summary text and keep it up to date. It would also allow the summary attribute to keep it's purpose in aiding those with disabilities. User agents should be encouraged to make summary visible on demand (not by default) by providing a preference or switch in the browser or user agent. This is discussed in the user agent list Toggle Metadata visibility.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2009OctDec/0103.html

Access for people with disabilities is essential. Features should not be made obsolete if not all users can fully make use of them but rather alternative/equivalent mechanisms must be provided when needed. Including the summary attribute in the specification as a valid option provides an equitable solution and reasonable accommodation as its use allows users of screen readers the opportunity to hear summary information for complex tables.

As Gez mentioned the summary attribute works. If it's been misused in the past, the solution is to provide better guidance on its usage, perhaps along the lines of Steve's "Techniques for providing useful text alternatives".
http://dev.w3.org/html5/alt-techniques/
Maybe consider expanding that primer to include sections on accessibility techniques for summary, canvas, media, etc.

Also as Gez said in an article comment it would be good to find out if a text summary is in fact useful for sighted people with learning disabilities. Would the summary text actually hinder sighted people with learning difficulties, as it describes what is visually evident? The work Gez has done seems to indicate that it would hinder rather than help. But this is an under-researched area. Perhaps a user agent visibility option would be of use to them.
http://juicystudio.com/article/purpose-of-the-summary-attribute.php#comment10

Making the summary attribute valid and conforming should happen NOW as PF previously recommended.
http://lists.w3.org/Archives/Public/public-html/2008Aug/0213.html
http://lists.w3.org/Archives/Public/www-archive/2009Jun/0026.html

Please reference my alternate table summary proposal for further rationale.
http://www.w3.org/html/wg/wiki/ChangeProposals/SummaryAttribute20100222
Maciej Stachowiak no <All answers on this survey are with HTML WG co-chair hat off.>

It was a bunch of work to settle issue 83, and I would prefer not to re-open it.

I also suspect that this change will be controversial, because a specific concern with the elements used to label a <details> element was that it should *not* be the same as any pre-existing HTML element, to avoid compatibility problems.

4. @noflow

Do you support the @noflow attribute for <details>?

Summary

ChoiceAll responders
Results
yes 5
no 11

Details

Responder @noflowComments
Ian Hickson no This seems like a presentational issue, which is best handled by CSS.
Steve Faulkner yes
Martin Kliehm no
Denis Boudreau no Ian's point is valid: this is more a presentational issue than anythng else, but as I don't support <details>, there's no point in supporting @nofollow either.
Gez Lemon no
Matthew May no
Gregory Rosmaita no as i indicated in my comments on question 3, any explicit exposure mechanism to render summarization information should be a user agent configuration option, just as
John Foliot yes
Cynthia Shelly yes having a simple attribute for this significant behavior change is far preferable to requiring authors to use CSS and script to acheive it.
Sally Cain no
Joshue O Connor no Agree with GJR regarding how it is rendered as a user agent configuration issue.
Wendy Chisholm yes
aurélien levy yes
Shelley Powers no By the time we've manipulated Details with all of the changes in the proposal, Details wouldn't be details anymore. Again, what happens if someone uses this attribute in Details outside of an HTML table?
Laura Carlson no
Maciej Stachowiak no <All answers on this survey are with HTML WG co-chair hat off.>

I think the proposed function of this attribute is purely presentational. Presentational effects are better handled by CSS. CSS also gives authors much more control over the details of the presentation, and authors are more likely to buy into features where they have full styling control.

I made some demos showing how this effect is possible using pure CSS, and how this gives authors good control over the appearance (works in Safari/Chrome/Opera, a bit buggy in Firefox).

http://webkit.org/demos/hover-summary/example1.html
http://webkit.org/demos/hover-summary/example2.html

5. Change proposal for summary and details

Please review the draft change proposal on details element as a replacement for summary attribute. You may also want to review discussion notes and frequently asked questions for this proposal.

Do you support taking this change proposal to the HTML WG as a decision of the HTML Accessibility Task Force?

Summary

ChoiceAll responders
Results
Submit this proposal to the HTML WG as a decision of the task force. 5
Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. 1
Do not submit this proposal to the HTML WG for the following reasons. 9

(1 response didn't contain an answer to this question)

Details

Responder Change proposal for summary and detailsComments
Ian Hickson The parts of the change proposal other than the noflow and <button> parts appear non-controversial and should IMHO be suggested using bugs, not via the change proposal process.
Steve Faulkner Submit this proposal to the HTML WG as a decision of the task force.
Martin Kliehm Do not submit this proposal to the HTML WG for the following reasons. See my comment on #2
Denis Boudreau Do not submit this proposal to the HTML WG for the following reasons. This proposal is NOT an appropriate replacement for @summary.

Please refer to http://www.w3.org/html/wg/wiki/ChangeProposals/SummaryAttribute20100222 for what we actually demand.

The attribute works, we just need to put more efforts into making authors use it in an appropriate way. Any misuse of @summary by authors around the world is first and foremost our responsability as a group. Let's work at providing good guidance to correct the general misunderstanding, instead of simply replacing what's already there. @summary is adequately implemented in ATs. It works today. We cannot take the risk of replacing it by something else that may not be supported correctly for a while and for which we have no guarantee authors will use adequately anyway... Seems like a no win situation.

Education and outreach is the key here, not a shiny new HTML element.
Gez Lemon Do not submit this proposal to the HTML WG for the following reasons. I don't think the proposal is an appropriate replacement for summary. The summary attribute works. If it's been misused in the past, the solution would be to provide good guidance on its usage.
Matthew May Do not submit this proposal to the HTML WG for the following reasons. See #2.
Gregory Rosmaita Do not submit this proposal to the HTML WG for the following reasons. the task force needs to:

1. ascertain the position of working group members on summary as an attribute versus summary as an element;

2. if the task force agrees on a summarizing element, then the various proposals for the specific name and mechanics of the summarization element would be the next deliverable of the task force in regards the TF's feedback on the summary 1ssue;

3. i'm not opposed to DETAILS as an element name, but wonder if the change in nomenclature is necessary -- what authors and users have been asking for is the ability to use a limited set of markup tags within the summarizing text, so as to indicate natural language switches, the expansion for an abbreviation/abbreviated form, emphasis markers, but NO interactive elements
John Foliot Submit this proposal to the HTML WG as a decision of the task force.
Cynthia Shelly Submit this proposal to the HTML WG as a decision of the task force. I'm also ok with separating out the issue-83 change
Sally Cain Do not submit this proposal to the HTML WG for the following reasons. I still support using @summary. The rationale for moving to details is not convincing enough for me at present.
Joshue O Connor Do not submit this proposal to the HTML WG for the following reasons. I would like us to work out the details of this proposal in light of Laura Carlson's request to maintain the @summary (which has also been the stance of the PF for some time). Also in light of any potential drawbacks of using an element over an attribute in this instance.

I also really want to properly ascertain just what is the positive attainment of the addition of the <details> element - and if it is not just change for changes sake.
Wendy Chisholm Submit this proposal to the HTML WG as a decision of the task force.
aurélien levy Submit this proposal to the HTML WG as a decision of the task force.
Shelley Powers Do not submit this proposal to the HTML WG for the following reasons. The proposal does not address the fundamental questions about what is perceived to be wrong with the summary attribute, and why this approach would fix these perceived problems. Web authors are not going to become magically more capable of writing the table structure annotation because the attribute has suddenly become an element.

Visibility of an item in a browser or not, or whether an item is an element or an attribute, does not transform indifference into caring responsibility, or ignorance into awareness.
Laura Carlson Do not submit this proposal to the HTML WG for the following reasons. I have drafted an alternate proposal. Please reference it for details.
http://www.w3.org/html/wg/wiki/ChangeProposals/SummaryAttribute20100222
Also see question 2 above.
Maciej Stachowiak Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. I suggest that we make the three changes implied by comments for the above questions:

(1) Do not allow or recommend <details> as a direct child of <table.
(2) Remove the noflow attribute; instead, recommend achieving this effect with CSS, and give examples.
(3) Do not include a rename of <summary> to <button> in this proposal.

I understand the TF is also consider a different proposal, to simply bring @summary back as conforming. I think if the TF cannot come to consensus on a single proposal, then a possibility wroth considering is to submit both.

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Richard Schwerdtfeger <schwer@us.ibm.com>
  2. Judy Brewer <jbrewer@w3.org>
  3. Liam Quin <liam@w3.org>
  4. Jim Allan <jimallan@tsbvi.edu>
  5. Charles McCathie Nevile <chaals@yandex-team.ru>
  6. Philippe Le Hégaret <plh@w3.org>
  7. Sean Hayes <sean.hayes@microsoft.com>
  8. Paul Cotton <Paul.Cotton@microsoft.com>
  9. Shane McCarron <shane@aptest.com>
  10. Silvia Pfeiffer <silviapfeiffer1@gmail.com>
  11. Janina Sajka <janina@rednote.net>
  12. Michael Cooper <cooper@w3.org>
  13. David MacDonald <David100@sympatico.ca>
  14. Sam Ruby <rubys@intertwingly.net>
  15. Michael[tm] Smith <mike@w3.org>
  16. Kelly Ford <kelly.ford@microsoft.com>
  17. Stefan Schnabel <stefan.schnabel@sap.com>
  18. Matthew Turvey <mcturvey@gmail.com>
  19. Kenny Johar <kensingh@microsoft.com>
  20. David Bolter <dbolter@mozilla.com>
  21. Jeanne F Spellman <jeanne@w3.org>
  22. Jean-Pierre EVAIN <evain@ebu.ch>
  23. Frank Olivier <frank.olivier@microsoft.com>
  24. Jatinder Mann <jmann@microsoft.com>
  25. Ian Pouncey <w3c@ipouncey.co.uk>
  26. Léonie Watson <lwatson@paciellogroup.com>
  27. Masatomo Kobayashi <mstm@jp.ibm.com>
  28. Bob Lund <b.lund@cablelabs.com>
  29. Mark Watson <watsonm@netflix.com>
  30. Adrian Roselli <roselli@algonquinstudios.com>
  31. Jason Kiss <jason@accessibleculture.org>
  32. Billy Gregory <bgregory@paciellogroup.com>
  33. Mark Sadecki <mark.sadecki+w3c@gmail.com>
  34. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  35. Brian Kardell <hitchjs@gmail.com>
  36. Joseph Karr O'Connor <josephoconnor@mac.com>
  37. Joanmarie Diggs <jdiggs@igalia.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.127 2015-02-04 08:52:34 carcone 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)