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

Silly enough, one of the most frustrating technical problems with 
launching an <input> is alignment.

Even with a full CSS reset and strict font detection, we still had 
issues with margin/padding of the native control.

Text decoration is another issue, though it's substantially improved 
over the last two years.

The pdf.js demonstrates small alignment quirks. They'd have better 
selection support if they coded it into Canvas; but it works well enough 
without, and the oncopy/onpaste patches in FF are still under review.




On 12/19/11 6:46 AM, Richard Schwerdtfeger wrote:
>
> 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
>
> Inactive hide details for Frank Olivier ---12/19/2011 05:27:41 AM---I 
> agree with Jonas that the last use case (' people will waFrank Olivier 
> ---12/19/2011 05:27:41 AM---I agree with Jonas that the last use case 
> (' people will want to select text at times to replace tex
>
> 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
>
>