On Aug 9, 2012, at 10:34 PM, Steve Faulkner <[email protected]> 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 <[email protected]> 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 <[email protected]> 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:[email protected]] > > Sent: Monday, July 30, 2012 12:43 AM > > To: Charles Pritchard > > Cc: Richard Schwerdtfeger; Edward O'Connor; Steven Faulkner > > ([email protected]); Frank Olivier; Michael(tm) Smith ([email protected]); > > Paul Cotton; Philippe Le Hegaret ([email protected]); Sam Ruby > > ([email protected]); [email protected]; [email protected]; > > [email protected] > > Subject: Re: Discussion on ISSUE-201: canvas-fallback > > > > > > On Jul 26, 2012, at 3:22 PM, Charles Pritchard <[email protected]> wrote: > > > > > > On Jul 26, 2012, at 11:56 AM, Maciej Stachowiak <[email protected]> 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 >
