Re: Working Group Decision on ISSUE-131 caret-location-api

Hi again,

Sending this as a separate note as this is of a different nature. This
isn't new information regarding the decision, but a hope of reaching a
proposal that is good for the web and that everyone is happy with.
Also, a word of warning is that I still haven't had time to dig into
this discussion to any great extent, so it's possible that i'm way off
track or repeating things that have been previously raised. If that's
the case, please let me know and I'll butt out.

It appears that the main request for a change here is the ability to
drive user focus separate from drawing the focus ring.

My main concern (and I think the concern of some others) is that if we
*force* people to use a separate API to drive user focus, many people
will forget or will opt out out of lazyness or lack of time.

But this doesn't have to be an either-or question. One solution that
would satisfy both would be to add another boolean argument to the
function which would indicate if drawing should drive focus or not. So
the resulting API would be something like this:

context.drawFocusRing(element, x, y, [ canDrawCustom ], [ driveUserSelection ]);
context.setCaretSelectionRect(element, x, y, w, h);

The most normal mode of operation would then be to simply write code like this:
cx.beginPath();
cx.moveTo(10, 10);
cx.drawFocusRing(elem, 10, 20);
cx.drawFocusRing(elem, 20, 20);
cx.drawFocusRing(elem, 20, 10);
cx.drawFocusRing(elem, 10, 10);
cx.closePath();

code like the above would focus the rectangle [10, 10]-[20,20], i.e.
the bounding box of the coordinates included in the drawFocusRing
calls.

However, if the page wants, or needs, to drive focus separately, it
can do that using the following calls

cx.beginPath();
cx.moveTo(10, 10);
cx.drawFocusRing(elem, 10, 20, false, false);
cx.drawFocusRing(elem, 20, 20, false, false);
cx.drawFocusRing(elem, 20, 10, false, false);
cx.drawFocusRing(elem, 10, 10, false, false);
cx.setCaretSelectionRect(elem, x, y, w, h);
cx.closePath();


An alternative solution would be to not introduce a new argument, but
simply say that a call to setCaretSelectionRect would replace the
current focus box calculated using the calls to drawFocusRing, with
the coordinates passed to setCaretSelectionRect. The more I think
about it, the more I like this proposal even better.


Further, I would call the function setFocusRect rather than
setCaretSelectionRect. First off I think this will be used in
situations other than driving focus towards a draw caret. Second, I
think people tend to think of 'selection' in the context of
copy-paste, rather than where the user is currently focusing
attention. But given that this is a naming issue, I'm guessing it's
been debated to death already! :)


My experience is that all too few authors pay attention to
accessibility concerns. Solutions that provide accessibility
automatically without taking further action on the part of the author
seems to work orders of magnitude better than ones that require the
author to specifically take action. The above proposals were written
in that spirit.

/ Jonas

Received on Friday, 29 April 2011 02:48:41 UTC