- From: <bugzilla@jessica.w3.org>
- Date: Sat, 25 Sep 2010 18:27:14 +0000
- To: public-html-bugzilla@w3.org
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