- From: <bugzilla@jessica.w3.org>
- Date: Mon, 10 Jan 2011 23:38:50 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11240 Ian 'Hixie' Hickson <ian@hixie.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |ian@hixie.ch Resolution| |WONTFIX --- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-01-10 23:38:50 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I've rejected this proposal on the following multiple independent grounds: * I couldn't come up with an API that enough people would use correctly to justify having the feature. If we have this feature, we need to have some sort of API that essentially acts like a trojan horse, providing a feature for authors to use while surreptitiously providing the a11y feature. In other words, it needs to not be bolt-on accessibility. This is, for example, the reasoning behind the design of <nav>, of <input type=date>, of drawFocusRing(), and so on: they provide legitimate features that authors will want to use and will likely use correctly, with which we can _also_ provide accessibility features (e.g. skipping navigation, native accessible date controls, magnification following, etc). Historically, APIs designed exclusively for accessibility have been a disaster, with most authors ignoring them, and the remaining authors trying to use them but failing due to lack of testing or understanding, with the end result being a net harm to accessibility. * Editing text is not something that we should encourage authors to do using <canvas>. This is true regardless of accessibility concerns — many native features get lost in such an implementation. * Selections are not points, they are non-rectangular disjoint regions, and their precise rendering varies from platform to platform in ways that would make such an API difficult to provide. (e.g. on Mac a selection of two lines each containing one character spans the width of the container, whereas on Windows it only spans the width of the characters) * No user agent vendor has indicated an interest in implementing this feature. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Monday, 10 January 2011 23:38:52 UTC