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 <[email protected]
<mailto:[email protected]>> wrote:
On Aug 9, 2012, at 10:34 PM, Steve Faulkner
<[email protected] <mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>]
> Sent: Monday, July 30, 2012 12:43 AM
> To: Charles Pritchard
> Cc: Richard Schwerdtfeger; Edward O'Connor; Steven Faulkner
([email protected] <mailto:[email protected]>);
Frank Olivier; Michael(tm) Smith ([email protected]
<mailto:[email protected]>); Paul Cotton; Philippe Le Hegaret
([email protected] <mailto:[email protected]>); Sam Ruby
([email protected] <mailto:[email protected]>);
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
> Subject: Re: Discussion on ISSUE-201: canvas-fallback
>
>
> On Jul 26, 2012, at 3:22 PM, Charles Pritchard
<[email protected] <mailto:[email protected]>> wrote:
>
>
> On Jul 26, 2012, at 11:56 AM, Maciej Stachowiak
<[email protected] <mailto:[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 <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>
