Re: Discussion on ISSUE-201: canvas-fallback

I think "any element that is a child of canvas" would be a reasonable choice for a programmatically enforced limitation. Text fields are not currently allowed as children of canvas (at the validation level) but authors who choose to ignore validation could work around it. Many of the other cases I cited would be fully allowed by permitting children of canvas.

 - Maciej

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 Friday, 10 August 2012 03:05:51 UTC