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

On this topic, I'm fine with the current specification and its 
scrollPathIntoView method. The method was authored shortly after the 
setCaretSelectionRect proposal, and though there may be some defects in 
the scroll into view mechanisms, those are something to be taken up with 
CSSOM.

As I understood it, CSSOM is in need of volunteers. Several other issues 
exist, such as carrying forward the MS proposal for window.screen pixel 
ratios, and defining the existing practice of resize events. But, like 
scroll into view, these are CSSOM issues, not Canvas issues nor HTML issues.

It seems that we will not see a caret blink rate at this time. I greatly 
appreciate the documentation that some authors have added to the lists 
about caret blink rates.

We still have the issue of focus management. It seems there's consensus 
that elements within the sub-tree should be able to receive focus. It 
seems there is consensus that Canvas authors should be able to provide 
the current path to the system, and bind that path to an element in the 
sub-tree.

It'd be nice to develop consensus around that. Issue 131 asked, in part, 
if the current focus API is sufficient. It's provably not sufficient for 
several ATs. scrollPathIntoView addresses some of the issues around 
magnification, but it does not address element.scrollIntoView() nor 
document.elementFromPoint(x,y), which both ATs and the JS scripting 
environment need to function to their fullest.



-Charles


On 12/19/11 3:27 AM, Frank Olivier wrote:
> 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 20:56:24 UTC