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