Re: Discussion on ISSUE-201: canvas-fallback

I've yet to see anyone respond to the use of touch/ink (such as from a Wacom tablet) in relation to entering content into an input field.

Further, input type=text is the fallback for unsupported input types. Consider input type=search and how that falls back to text.

We should not single out nor blacklist textarea, input type=text nor other input fields.

I'd rather have DOM/window focus on an HTML input field with appropriate semantics. The alternative is to use ARIA on div/span: that does work, but it seems a disabling limitation to codify into the HTML spec.

-Charles



On Aug 8, 2012, at 1:29 PM, Frank Olivier <Frank.Olivier@microsoft.com> wrote:

> "it seems like quite a few other elements are reasonable candidates for hit targets."
> 
> I agree - I don't think the whitelist is a good idea either. With the exception of <input type='text'>,  most DOM elements would be a valid choice. 
> 
> From: Maciej Stachowiak [mailto:mjs@apple.com] 
> Sent: Monday, July 30, 2012 12:43 AM
> To: Charles Pritchard
> Cc: Richard Schwerdtfeger; Edward O'Connor; Steven Faulkner (faulkner.steve@gmail.com); Frank Olivier; Michael(tm) Smith (mike@w3.org); Paul Cotton; Philippe Le Hegaret (plh@w3.org); Sam Ruby (rubys@intertwingly.net); www-archive@w3.org; public-html@w3.org; public-html-a11y@w3.org
> Subject: Re: Discussion on ISSUE-201: canvas-fallback
> 
> 
> On Jul 26, 2012, at 3:22 PM, Charles Pritchard <chuck@jumis.com> wrote:
> 
> 
> On Jul 26, 2012, at 11:56 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> 
> This text needs to be changed to:
> 
> "The arguments object's control member references an element with a valid id."
> To add some context to Rich's point (which I did not understand until I read the full diff text), it appears that hit regions backed by elements are limited to hyperlinks, buttons, checkboxes and radio buttons. If you specify any other element, the method will throw an exception. It's not clear to me why other elements are categorically excluded from backing a hit region.
> 
> 
> The HTML editor was quite vocal in his opposition to other uses of Canvas in user interface authoring. The text as available in the CP simply reinstates the editors changes.
> 
> As a group, the Canvas attendees decided against such restrictions. The HTML5 Editor did not attend any of these discussions.
> 
> That may explain why in the historical sense, but it does not explain why in the rationale sense. What I'm suggesting is that the CP should provide rationale for this restriction if it is maintained, or else drop it.
> 
> To me at least, it seems like quite a few other elements are reasonable candidates for hit targets. Here are a few use cases that go beyond the CP but which I expect are uncontroversial:
> 
> <input type=range>: using canvas to make a dial-type range control, to match the UI idiom of an audio synthezier
> <td>: an interactive bar graph where the fallback is a table, and clicking a column should active code associated with the corresponding table cell
> <input type=color>: color picker in a canvas-based paint program
> <summary>: for an expandable section of canvas-rendered controls that has the behavior of <details>; this would need to be clickable and focusable
> 
> The whitelisting of a very limited set of native controls also stands at odds with allowing any ARIA role whatsoever.
> 
> Those are some reasons why I find this aspect of the CP puzzling.
> 
> Regards,
> Maciej
> 
> 
>

Received on Wednesday, 8 August 2012 21:32:05 UTC