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

Received on Monday, 19 December 2011 11:45:32 UTC