Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote on 12/18/2011
12:03:45 PM:
> From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
> Cc: Steve Faulkner <faulkner.steve@gmail.com>, chuck@jumis.com,
> Cynthia Shelly <cyns@microsoft.com>, david bolter
> <david.bolter@gmail.com>, dbolter@mozilla.com, franko@microsoft.com,
> Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>,
> Paul Cotton <Paul.Cotton@microsoft.com>, public-canvas-api@w3.org,
> public-html@w3.org, public-html-a11y@w3.org, Sam Ruby
<rubys@intertwingly.net>
> Date: 12/18/2011 12:04 PM
> Subject: Re: Request to re-open issue 131 -USE CASES, USE CASES, USE
CASES
>
> On Sun, Dec 18, 2011 at 4:25 PM, Richard Schwerdtfeger
> <schwer@us.ibm.com> wrote:
> > USE CASE: Regarding hit testing, it is very, very simple. In ALL
> operating systems that support an accessibility API it is ESSENTIAL
> that a magnifier be able to determine the location of an accessible
> object on the screen so that a user may zoom to it. It has
> absolutely nothing to do with rich text editing
>
> Note Jonas mentioned text editors not rich text editing. They aren't
> quite the same thing.
>
That is fine but my point still applies to basic text editing (a text box).
If I create a checkbox on canvas I need its bounds or if I draw a label for
a text field I need to know its bounds.
> > USE CASE: Regardless of whether you are doing rich text or not
> canvas supports the ability to draw text on the screen. If you are
> creating a drawing object you will want the user to give it a label.
> To do that you have to provide them the ability to enter text. The
> user experience would be dreadful if you had to launch an HTML
> dialog box to enter it so authors will want to be able enter text
> using canvas for this basic purpose. The magnifier MUST be able to
> follow along.
>
> This use case does involve text editing, albeit not necessarily rich,
> and not necessarily as an app that is a text editor - could be some
> sort of diagram or map editor. Jonas, would editing labels on map
> count as a "text editor" in your book?
>
> > USE CASE: Expanding on the above, people will want to select text
> at times to replace text with new text on canvas even if it means
> pointing, highlighting as you drag your finger over the text, and
> typing over the text (we have no clipboard support in canvas).
>
> Again this use case does involve text editing.
>
> > 3. USE CASE for text baseline: As Steve indicated, the use cases
> for text baseline are in my change proposal. I will not repeat them here.
>
> "compute drawing rings bounds, bounds for highlighted text, and text
> caret position", if I've got it right.
>
> http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline
>
> e.g. If you render multiline text in canvas, some screen magnifiers
> will need to highlight the line of text under consideration.
>
> > Does anyone not understand these use cases?
>
> I would add that caret navigation through canvas content and partial
> selection of text in canvas content for copying are not strictly text
> editing, but could make use of features meeting these use caes. I'm
> not sure whether these activities fall under Jonas's rubric of "text
> editor" or not.
>
I do not either.
> --
> Benjamin Hawkes-Lewis
>