W3C home > Mailing lists > Public > www-archive@w3.org > August 2012

Re: Discussion on ISSUE-201: canvas-fallback

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 17 Aug 2012 10:04:55 -0700
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: <B9295FB6-5692-4DB5-B722-9B8C6473E694@apple.com>
To: Steve Faulkner <faulkner.steve@gmail.com>

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 <faulkner.steve@gmail.com> 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 <mjs@apple.com> wrote:
> 
> 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 
>> 
> 
> 
> 
> 
> -- 
> 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, 17 August 2012 17:04:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:55 GMT