Thanks, Steve. So all that remains is for the other contributors to the Change 
Proposal to review this.

 - Maciej

On Aug 17, 2012, at 4:17 AM, Steve Faulkner <[email protected]> wrote:

> Hi Maciej,
> 
> from reading yesterdays HTML WG minutes I noted your statement in regards to 
> issue 201
> 
> mjs: the other open point was the restriction on elements; we need 
> confirmation from the person who brought it up that they want this addressed
> 
> Both Rich and I raised this issue and made it clear we want addressed, as  
> communicated on the 26th [1]  and 28th of July[2]. I  made changes to teds 
> proposal on 2nd of august with the spec text change [3] to address this 
> issue:  and requested feedback on that date [4].
> 
> [1] http://lists.w3.org/Archives/Public/public-html/2012Jul/0204.html
> [2] http://lists.w3.org/Archives/Public/public-html/2012Jul/0235.html
> [3] 
> http://www.w3.org/html/wg/wiki/index.php?title=User:Eoconnor/ISSUE-201&diff=13386&oldid=13385
> [4] http://lists.w3.org/Archives/Public/public-html/2012Aug/0062.html
> 
> regards
> SteveF
> 
> On 13 August 2012 04:31, Maciej Stachowiak <[email protected]> wrote:
> 
> 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 
>> 
> 
> 
> 
> 
> -- 
> 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 
> 

Reply via email to