Re: Review of caret and selection proposal in current canvas API draft

Rich Schwerdtfeger
CTO Accessibility Software Group

public-canvas-api-request@w3.org wrote on 01/30/2011 06:47:20 AM:

> From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
> To: public-canvas-api@w3.org, public-html-a11y@w3.org
> Date: 01/30/2011 06:50 AM
> Subject: Review of caret and selection proposal in current canvas API
draft
> Sent by: public-canvas-api-request@w3.org
>
> 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.
>
I will look into that.

> + 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.
>
This was more a statement of what must be supplied through the
accessibility APIs. I will work to reword this similar to what we have for
focusRing which reflects your points.

> 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:
>
This API is targeted at Canvas and not CSS and SVG. It sounds like you want
to extract this API and put it elsewhere.

> 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?
>
You use the drawing path relative to the canvas upper left position. You
then add the coordinates of the upper left corner of the upper left hand
corner of the canvas. The coordinates of the rectangle are a best fit:

Assuming coordinates are relative to the top left of a device context (Only
OS/2 did it cartesian coordinate based)

- minium top, left coordinate   = top left
- max bottom, minumum left coordinate  = bottom left
- max bottom, max right  = bottom right
- minimum top, maxium right - top right

There's your rectangle.

> + 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.
>

I don't see how a blink rate could be used to profile a user. People may
just not like a high blink rate.

> 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."
>
Like you I have an issue exposing the use of a screen reader. That is a
privacy issue.

> + 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.
>
I will discuss this with the group.

> + Suggestion 7: Update the example code
>
> The example code should be updated to demonstrate setCaretSelectionRect()
and
> caretBlinkRate().
>
> --
> Benjamin Hawkes-Lewis
>