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

Re: Discussion on ISSUE-201: canvas-fallback

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 17 Aug 2012 23:31:10 -0700
Message-ID: <502F36AE.10605@jumis.com>
To: Steve Faulkner <faulkner.steve@gmail.com>
CC: Maciej Stachowiak <mjs@apple.com>, Frank Olivier <Frank.Olivier@microsoft.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>
As I understand things, Ted co-opted Ian's proposal without modification.

If that's the case, I think some revision and/or reflection might help.

Between the WebKit patches supporting Canvas and some patches supporting 
a simple measureText and beginPath(Path)/createPath() semantic, I think 
there's reason for the original author to revisit the Eoconnor CP.


On 8/17/2012 4:17 AM, Steve Faulkner 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 
> <mailto:mjs@apple.com>> wrote:
>
>
>     On Aug 9, 2012, at 10:34 PM, Steve Faulkner
>     <faulkner.steve@gmail.com <mailto: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
>>     <mailto: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
>>         <mailto: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
>>         <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 <mailto:faulkner.steve@gmail.com>);
>>         Frank Olivier; Michael(tm) Smith (mike@w3.org
>>         <mailto:mike@w3.org>); Paul Cotton; Philippe Le Hegaret
>>         (plh@w3.org <mailto:plh@w3.org>); Sam Ruby
>>         (rubys@intertwingly.net <mailto:rubys@intertwingly.net>);
>>         www-archive@w3.org <mailto:www-archive@w3.org>;
>>         public-html@w3.org <mailto:public-html@w3.org>;
>>         public-html-a11y@w3.org <mailto: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 <mailto:chuck@jumis.com>> wrote:
>>         >
>>         >
>>         > On Jul 26, 2012, at 11:56 AM, Maciej Stachowiak
>>         <mjs@apple.com <mailto: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 <http://www.paciellogroup.com/> |
>>     www.HTML5accessibility.com <http://www.html5accessibility.com/> |
>>     www.twitter.com/stevefaulkner <http://www.twitter.com/stevefaulkner>
>>     HTML5: Techniques for providing useful text alternatives -
>>     dev.w3.org/html5/alt-techniques/
>>     <http://dev.w3.org/html5/alt-techniques/>
>>     Web Accessibility Toolbar -
>>     www.paciellogroup.com/resources/wat-ie-about.html
>>     <http://www.paciellogroup.com/resources/wat-ie-about.html>
>
>
>
>
> -- 
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com <http://www.paciellogroup.com> | 
> www.HTML5accessibility.com <http://www.HTML5accessibility.com> | 
> www.twitter.com/stevefaulkner <http://www.twitter.com/stevefaulkner>
> HTML5: Techniques for providing useful text alternatives - 
> dev.w3.org/html5/alt-techniques/ <http://dev.w3.org/html5/alt-techniques/>
> Web Accessibility Toolbar - 
> www.paciellogroup.com/resources/wat-ie-about.html
> <http://www.paciellogroup.com/resources/wat-ie-about.html>
Received on Saturday, 18 August 2012 06:31:35 GMT

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