RE: Request to re-open issue 131 -USE CASES, USE CASES, USE CASES

I doubt developers will launch an HTML text box every time they want the
user to enter text:

- editable combobox
- grid cell
- text box

If they were going to do this the author (the lucidart example) would have
done it in that example I last posted. It is really not visibly pleasing to
have to launch a dialog box to enter text into an editable combobox and
definitely not intuitive.

Also, there is a technical problem with overlaying a textbox on a flow
diagram drawing object. I mean in something like Visio you will want to
zoom in and out to focus on a drawing object. You may want the text to
magnify accordingly.

Rich



From:	Frank Olivier <Frank.Olivier@microsoft.com>
To:	Jonas Sicking <jonas@sicking.cc>, Richard
            Schwerdtfeger/Austin/IBM@IBMUS,
Cc:	Steve Faulkner <faulkner.steve@gmail.com>, "chuck@jumis.com"
            <chuck@jumis.com>, Cynthia Shelly <cyns@microsoft.com>, david
            bolter <david.bolter@gmail.com>, "dbolter@mozilla.com"
            <dbolter@mozilla.com>, Maciej Stachowiak <mjs@apple.com>, Paul
            Cotton <Paul.Cotton@microsoft.com>, "public-canvas-api@w3.org"
            <public-canvas-api@w3.org>, "public-html@w3.org"
            <public-html@w3.org>, "public-html-a11y@w3.org"
            <public-html-a11y@w3.org>, Sam Ruby <rubys@intertwingly.net>
Date:	12/19/2011 05:27 AM
Subject:	RE: Request to re-open issue 131 -USE CASES, USE CASES, USE
            CASES



I agree with Jonas that the last use case (' people will want to select
text at times to replace text with new text on canvas') seems reasonable;
think of a pdf / document viewer written with canvas as the rendering
surface.

"Note that it's very possible to overlay a text box on top of a canvas such
that it renders just like any other part of the canvas. No need to "launch
an HTML dialog box". The UI can be indistinguishable to if the text was
drawn with canvas APIs."
I also agree that this would be the most optimal way to do text entry when
you use canvas; instead of trying to recreate built-in functionality with
thousands of lines of code, you can just use the actual platform
capabilities.



From: Jonas Sicking [mailto:jonas@sicking.cc]
Sent: Monday, December 19, 2011 1:21 PM
To: Richard Schwerdtfeger
Cc: Steve Faulkner; chuck@jumis.com; Cynthia Shelly; david bolter;
dbolter@mozilla.com; Frank Olivier; Maciej Stachowiak; Paul Cotton;
public-canvas-api@w3.org; public-html@w3.org; public-html-a11y@w3.org; Sam
Ruby
Subject: Re: Request to re-open issue 131 -USE CASES, USE CASES, USE CASES

On Sun, Dec 18, 2011 at 8:25 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
2. Caret and Selection Tracking

USE CASE: If you are a magnifier you must be able to follow the location on
the screen where you are typing a piece of text or you are pointing to
select content. Remember, a magnifier's view of the screen may be VERY
SMALL. The magnifier needs to follow along as you type. That is why we
submitted the change request before and why it was approved and why I had
agreement from David Bolter, Microsoft, Steve Faulkner, etc. to submit the
first proposal that was accepted.

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.

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

So the last use case seems reasonable to me to solve. But the first two
appear to be only for text editing and so falls into the category that *I*
am not interested in solving at this time. At least not until someone has
shown that a proper editor can be built for them.

Note that it's very possible to overlay a text box on top of a canvas such
that it renders just like any other part of the canvas. No need to "launch
an HTML dialog box". The UI can be indistinguishable to if the text was
drawn with canvas APIs.
4. USE CASE for exposing a caret blink rate:

OS platforms allow the configuration of a blink rate by a user. User's
configure blink rates to avoid epileptic seizures. The blinking problem is
not limited to text carets. We need to expose this information so that a
canvas author can avoid having a problem.
This too only seems useful for text editing based on the use case you've
presented here.

I also don't buy the argument that people don't need IME any more than I
buy the argument that people don't need accessibility.

/ Jonas