- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 08 Oct 2010 03:08:08 -0700
- To: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
- CC: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Ian Hickson <ian@hixie.ch>
On 10/7/2010 11:44 PM, Benjamin Hawkes-Lewis wrote: > On 8 Oct 2010, at 04:14, Ian Hickson wrote: >> if someone can come up with a way to >> make an API for these features that addresses the needs I listed (which, >> based on past experience with accessibility APIs, would likely be the >> minimum necessary to actually improve accessibility on the Web for pages >> whose authors write their own editors), and assuming that browsers would >> be willing to support them, then there's no question that we'd add them to >> the spec. > Does anyone have any specific API proposals to put on the table to resolve Bugs 10248 and 10249? Let's go back to requirements for those APIs, and a road map. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10248 Ian's requirements are that a new API: (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. I've an objection to item (c). The point here is not to replace hand-rolled carets, it's to agree on a standard API, to communicate information about the caret position on the screen. This is mirrored by Richard's sentiments: "For now I am perfectly willing to have an API that drives magnification". As an implementer, I'd like an API that I can use in addition to my hand-rolled caret painter. We've established [correct me if I'm wrong] that this is not restricted to text editing, and that the following statement is incorrect: "This thread started [with] APIs only useful for canvas-based text editor implementations: a way to report the caret position, and a way to report the selection area". http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/0028.html What we're looking at, is "caret browsing", or "caret navigation": http://en.wikipedia.org/wiki/Caret_navigation Currently, Firefox and Internet Explorer implement caret browsing, but do not expose that fact to the scripting environment. If there are objections to the prior statements, please refer to the above as "Section 1". Let's continue this as Section 2. At present, it seems that IE will check system settings for the caret width, where Firefox does not. It's reasonable to expect Firefox to support this as well: I am testing with FF 3.6, and have not tried their current development builds. Regardless, "caret navigation" semantics should be discussed more broadly: WebKit developers could use some help via the specs process. https://bugs.webkit.org/show_bug.cgi?id=25526 Within the context of this forum, spatial navigation is even more complex, as it's not restricted to css line boxes. The current drawFocusRing API is a good model for future work, as it provides "relevant native accessibility needs [and] non-accessibility needs". It addresses most of the issues brought up by Richard and by Ian, in these conversations. So lets look at what's lacking: It seems to me that system rate blinking, caret width, and high contrast accessibility settings should be exposed to the scripting environment, perhaps through an extension to "window.navigator". Does this sound reasonable to everyone else? It would be nice to make those settings mutable, for the current page, so that the scripting environment may alter those settings as well as accessing them, under its local scope. If we can agree that this is handled outside of the canvas API, we know that hand-rolled canvas painters will be access such features. Mouse cursors are handled via CSS, it seems reasonable that a caret could be controlled via CSS semantics as well. Thoughts here? Should the system caret be handled via CSS and its properties accessible by the scripting environment, hand-rolled painters will be able to match current OS settings and be adapted for content. I realize that this is a CSS proposal: canvas has a level of interoperation requirements with CSS already, it's a good relationship, and relevant to our discussion here. style="caret: none" would disable the caret. CSS Semantics: caret: none|url|auto width height blink-rate. DOM: window.navigator.caretRate = 400; element.style.caretRate = 200; drawFocusRing has opened up focus control, and the canvas sub-dom. It's fantastic. Other than semantic value, I don't know that it needs to be extended. These could follow a similar structure; though the use of "element" as a parameter is questionable: drawCaret, drawSelectionStart, drawSelectionEnd, drawFocusSelection. drawCaret should accept directionality as a parameter. The usefulness of Start and End points for selection is clearly illustrated by touch-based selection mechanisms. Are four options are useful, could use the existing path (with clipping), and could use x/y coordinate hints, for magnification/focus. They don't necessarily need an element parameter, and there would be issues with magnification, as we don't want a magnification window moving around as each method is called. Magnification positions should be calculation at the end of the event loop. drawFocusSelection would simply outline the area we'd like selected, make our decision whether to use the canvas sub-dom or dataTransfer. Let's call that the end of Section 2. Is this a reasonable step forward? Are we in agreement about the items in Section 1? As for Section 2: CSS / DOM support for caret management seems long over-due. I've shown that two vendors are actively supporting caret browsing, and that WebKit is struggling, but trying. This is obviously something to take up with the style list. I'd like consensus here before I bring it there. Have we advanced at all from drawFocusRing with the draw* family I've proposed? I'd be happy to continue working on that family API, for focus management, but I want to know that my time is being well spent before I work out more details. I feel that I've engaged the CSS / DOM environment, as well as the browser event loop, in this proposal, and I hope that's sufficient for a nod, in continuing the work. If there are ideas for different method names, let me know. -Charles
Received on Friday, 8 October 2010 10:08:19 UTC