w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody.
This questionnaire was open from 2010-05-12 to 2010-05-19.
5 answers have been received.
Jump to results for question:
We have a Change Proposal to remove the meter element. If you have strong objections to adopting this Change Proposal, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Responder | Objections to the Change Proposal to Remove the meter Element |
---|---|
Larry Masinter | |
Cynthia Shelly | See my comment on <details>. These behavioral user interface elements are one of the key advances of HTML 5 and should not be removed. |
David Singer | -Level indicators (or gauges) are a common and useful UI idiom in a wide range of native applications. HTML5 should serve this idiom directly. - Level indicators are one of the basic control types supported on Mac OS X. They are part of a complete modern UI toolkit. HTML5 should serve applications by providing a complete set of controls. - Some operating systems have a very specific platform-native look for level indicators. While some content authors want to make web applications with custom-looking controls for everything, others want to match the platform native look. Often they try to do this by building controls out of image pieces in the hopes of targeting a single platform, causing a mismatch on other platforms or when the original target platform changes. The <meter> element is the only proposed way to get a level indicator with a truly native look and feel. - While level indicators are not as common as some other control types, the lack of a control for a level indicator may lead authors to abuse progress indicators for this purpose. That would be harmful to UI consistency and accessibility. - Semantic elements lead to improved accessibility. The HTML WG Accessibility Task Force has endorsed the <meter> element and opposed the call to remove it. - Implementors of multiple browser engines, including WebKit, Gecko and Presto, have expressed interest in implementing this element. There is an initial implementation in WebKt. Given the interest from authors, implementors and the accessibility community in keeping it, the <meter> element should not be removed. |
Jonas Sicking | I object to removing the <progress> element as it would result in missing out of the positive effects listed in http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements#Positive_Effects My experience working with web authors for several years is that they tend to do what is easy, whereas accessibility often ends up coming second due to time constraints and unawareness. By including the semantic <meter> element, we both make it easier for developers to do what they want, since they'll need to use less markup and script, while automatically getting a good accessibility story. The change proposal to remove <meter> seems to have no solution for what HTML editors like nvu or dreamweaver should do, making it impossible for such tools to properly support the functionality that <meter>s supplies. At least without resorting to hacks that don't work in a cross-editor manner. Finally, I think it's very unlikely that as many people would add proper ARIA attributes, as would use the <meter> element. I think this is the reason that the WAI-ARIA specification encourages developers of markup languages to add semantic elements and explicitly declares ARIA as a bridge technology. I also think this is why the HTML Accessibility TF has endorsed the <meter> element. While I don't like the name 'meter' at all, I also can't think of a better name. And I feel that removing a useful element just because we can't come up with a perfect name, would be having the wrong priorities. |
Laura Carlson |
We have a Change Proposal to keep several newly-introduced semantic elements, attributes, and controls. If you have strong objections to adopting this Change Proposal specifically with respect to the meter element, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Responder | Objections to the Change Proposal to Keep New Elements and Attributes |
---|---|
Larry Masinter | (see objection on ISSUE-90; lack of transition plan and unambiguous support at this point => remove to allow HTML5 to reach rec realistically). |
Cynthia Shelly | |
David Singer | |
Jonas Sicking | |
Laura Carlson | Rationale is at: http://lists.w3.org/Archives/Public/www-archive/2010May/att-0023/meter.txt |
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
w3c/wbs-design
or
by mail to sysreq
.