- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 10 Aug 2012 06:34:18 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Frank Olivier <Frank.Olivier@microsoft.com>, Charles Pritchard <chuck@jumis.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, "Edward O'Connor" <eoconnor@apple.com>, "Michael(tm) Smith (mike@w3.org)" <mike@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, "Philippe Le Hegaret (plh@w3.org)" <plh@w3.org>, "Sam Ruby (rubys@intertwingly.net)" <rubys@intertwingly.net>, "www-archive@w3.org" <www-archive@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
- Message-ID: <CA+ri+Vn1b71q08Z_2kE3Y-Yg-4Ge0yn8pZtuuLiWoz5+q0B9ng@mail.gmail.com>
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> ? 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
Received on Friday, 10 August 2012 05:35:36 UTC