Re: Discussion on ISSUE-201: canvas-fallback

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<http://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