[Bug 11240] Canvas support accessible selection position tracking independent of Focus Ring tracking

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 the QA contact for the bug.

Received on Monday, 10 January 2011 23:38:52 UTC