Re: Discussion on ISSUE-201: canvas-fallback

On Aug 9, 2012, at 10:34 PM, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> Hi Maciej,
> 
> 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.
> 
> The content model for canvas in HTML5 [1]  is 'transparent' , which i believe means there is no specific limitations on allowed children. The content model for canvas in HTML LS differs somewhat [2]
> 
> So I guess you are suggesting we modify the content model from transparent to transparent minus <input type=text> ?

My mistake. I do not propose changing the content model. I still think that any element which is a descendant of the canvas element should be allowed as the backing element for a hit region, rather than throwing an exception based on the type of element.

 - Maciej

> 
> regards
> SteveF
> 
> 
> [1] http://dev.w3.org/html5/spec/the-canvas-element.html#the-canvas-element
> [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element
> 
> On 10 August 2012 04:05, Maciej Stachowiak <mjs@apple.com> wrote:
> 
> 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
> >
> >
> >
> 
> 
> 
> 
> -- 
> with regards
> 
> Steve Faulkner
> Technical Director - TPG
> 
> www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html 
>