W3C home > Mailing lists > Public > public-html@w3.org > April 2011

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

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Fri, 29 Apr 2011 07:54:44 +0100
Message-ID: <BANLkTi=Y4WHNp_nwQwarow5XwHcxL1YhqQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Maciej Stachowiak <mjs@apple.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, HTMLWG WG <public-html@w3.org>
On Fri, Apr 29, 2011 at 3:47 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

Don't follow this comment.

setCaretSelectionRect is intended for carets and selection. It does not
specify focus.

Carets and selection are relevant to scenarios beyond editable text.

If you have caret navigation turned on, then you have a caret when
you're just moving through text.

You can select text, either with that caret or with the mouse (then
further adjustment with the keyboard), without being able to edit it.

Consider a scenario where the Canvas sub-DOM ("fallback content")
contains only a "p" with text, which is re-rendered as part of the
canvas. Selection can take place within that "p" element. Authors can
make the caret and selection required for this visible in the canvas.

Note that in this scenario, the author needs to know:

   1. When the caret position/selection changes in the sub-DOM.
(They can check this after key events.)
   2. What the caret position/selection is. (They can use the DOM
selection API).
   3. How the text in the "p" element maps to coordinates in the
canvas, and vice versa. (They can use the canvas text metrics API.)

And the author needs to:

   1. Draw the navigation caret with the expected blink rate.
   2. Draw the selection on the canvas.
   3. Map mouse click and drag events on rendered text in the canvas
      back to the sub-dom.

All non-visual aspects of textiness, such as copying to the clipboard,
are delegated to the sub-DOM.

But the user /sees/ the canvas, so in order to zoom the selection or
highlight the navigation caret, magnifiers need to know the caret
position or the selection bounding rectangle.

Note that if none of this happens, then the text is still selectable
through the keyboard, but the magnifier will draw the keyboard
navigation caret and the extent of any selection in the wrong
place.

--
Benjamin Hawkes-Lewis
Received on Friday, 29 April 2011 06:55:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:28 GMT