Review of caret and selection proposal in current canvas API draft

Reviewing:

http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0035/HTML_Canvas_2DContext101711.html

+ Suggestion 1: Provide normative definitions of terms used in conformance
requirements

We must provide normative text clearly defining the vague terms "caret
position" and "selection position", since conformance requirements are imposed
that use those terms. We should provide something along the lines of
the text in the informative section, which suggests a caret position is the
leftmost point of the drawn caret and the uppermost point of the font height
and that a selection position is the leftmost point of the last character
selected and the uppermost point of the font height. The text should be
reworked to be independent of whether the last selection was a character or a
graphic.

+ Suggestion 2: Define effects of non-canvas transformations on
setCaretSelectionRect()

The draft says:

"If the user agent supports a platform accessibility API the user agent must
use the element and (transformed) coordinate on the canvas and compute a caret
or selection position (or rectangle) in screen coordinates and provide it to an
assistive technology through the supported accessibility API implementation
including notifications to the assistive technology when the coordinates of the
caret or selection position change."

Canvas transformation matrices are unaffected by transforms to the canvas
element as a whole.

But if transforms to the canvas element are ignored when computing the screen
coordinates, then magnifiers will focus the wrong location on the screen.

We should define how user agents must compute positions/rectangles under the
effects of non-canvas transforms, such as CSS, SVG, and arbitrary XML dialects.

An example of the subtleties here would be when a canvas element is
subjected to warping using CSS 3D transforms:

http://webkit.org/blog/386/3d-transforms/

How must user agents compute a "rectangle" in such a case? For example, must
they compute the rectangle within the canvas context, then compute the
(transformed) pixel coordinates on the screen, then compute a rectangle that
embraces all four corners?

+ Suggestion 3: Define caretBlinkRate() on a canvas-independent interface

The caretBlinkRate method would be as relevant to a user interface built using
non-canvas technologies such as SVG.

It should therefore be introduced on a global, independent interface such as
Window, Navigator, or Accessibility.

Compare James Craig's window.navigator.accessibility.screenreader.active
proposal in:

http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html

+ Suggestion 4: Allow privacy exemption to caretBlinkRate()

caretBlinkRate() could be used for profiling users, so UAs must be allowed not
to share this data if the user does not want to be profiled.

For example, James Craig's window.navigator.accessibility.screenreader.active
uses the following rubric:

"The user agent must return true if a screen reader is running, or false
otherwise. User agents may return false if the user has chosen to disallow
sharing this information with the requesting domain."

+ Suggestion 5: caretBlinkRate() should return default value of 500

Using a default value inhibits profiling and avoids authors having to hard
code the number 500 into their code to use when caretBlinkRate() returns -1.

+ Suggestion 6: Make caretBlinkRate() a property

Given caretBlinkRate takes no arguments, it would be more consistent with
DOM and BOM APIs if it was a property not a method.

+ Suggestion 7: Update the example code

The example code should be updated to demonstrate setCaretSelectionRect() and
caretBlinkRate().

--
Benjamin Hawkes-Lewis

Received on Sunday, 30 January 2011 12:48:57 UTC