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

Re: Discussion on ISSUE-201: canvas-fallback

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Fri, 10 Aug 2012 06:34:18 +0100
Message-ID: <CA+ri+Vn1b71q08Z_2kE3Y-Yg-4Ge0yn8pZtuuLiWoz5+q0B9ng@mail.gmail.com>
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>
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 GMT

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