[Bug 10248] Canvas requires a Caret Drawing call method

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10248


Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ian@hixie.ch
         Resolution|                            |NEEDSINFO




--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch>  2010-09-25 18:27:14 ---
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: Partially Accepted
Change Description: no spec change
Rationale:

To do this, we need to first come up with an API that would be used enough for
this to be worth the cost, and would be used correctly more often than used
incorrectly. Since purely accessibility-driven APIs are generally ignored by
authors, we need a stalking horse to get authors to use this API (much as the
focus ring drawing API is a stalking horse for getting the bounding box of the
control in the first place). The obvious stalking horse here is "draw a caret".
Unfortunately, I have not been able to come up with an API that (a) satisfies
the accessibility use cases (blinks according to the system rate, draws the
caret at the OS-set caret width, etc), (b) is sanely usable (handles clipping
around the edge of a control, handles scrolling of a long text control in a
small field, etc), and (c) is easier than just hand-rolling a custom caret
painter.

Without something that satisfies all three of these requirements, I don't think
it makes sense to make an API available — it would actually be a net
_negative_ to accessibility since people would likely use it wrong more often
than they use it right, if they used it at all.

So I am marking this NEEDSINFO: the need is for an API that satisfies these
constraints.

In practice it may make more sense to stop people from wasting their time
writing editors in <canvas>, which is not what <canvas> was for, and indeed
makes little to no sense. Trying to provide a caret API just justifies people
doing this. It would be like providing a way for people to say what the
semantic of a <blockquote> was, so that they could keep using it to indent
text, while still in theory being able to make ATs act correctly.

Note also that on some platforms, in particular Windows, many ATs actually do
caret tracking by doing image analysis of the display to find where the
blinking caret is, because so many applications hand-roll their own carets in
an inaccessible fashion. So this might not be a huge problem in many cases.

-- 
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 Saturday, 25 September 2010 18:27:16 UTC