W3C home > Mailing lists > Public > public-canvas-api@w3.org > April to June 2010

Re: Alternative Canvas proposal from Charles

From: James Craig <jcraig@apple.com>
Date: Mon, 21 Jun 2010 14:29:46 -0700
Message-Id: <C1245FA8-2FF1-41D5-B876-9711523E63E8@apple.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>, David Bolter <david.bolter@gmail.com>, Michael Cooper <cooper@w3.org>, Janina Sajka <janina@rednote.net>, Charles McCathieNevile <chaals@opera.com>, Cynthia Shelly <cyns@exchange.microsoft.com>, Steven Faulkner <faulkner.steve@gmail.com>, Frank Olivier <franko@microsoft.com>, public-canvas-api@w3.org, HTML Accessibility Task Force <public-html-a11y@w3.org>
Discussion was off list for a little while. Bringing back to the list with Charles' permission. 

Note: I'm not subbed to the HTML ATF list, so this may or may not make it to that list. I'm only following public-canvas-api regarding this subject.


On Jun 21, 2010, at 1:48 PM, Charles McCathieNevile wrote:

> …feel free to re-post as much/little as you like to the group...
> 
> On Mon, 21 Jun 2010 13:00:24 -0700, James Craig <jcraig@apple.com> wrote:
> 
>> 
>> On Jun 18, 2010, at 11:26 PM, Charles McCathieNevile wrote:
>> 
>>> On Fri, 18 Jun 2010 22:59:10 +0200, James Craig <jcraig@apple.com> wrote:
>>> 
>>>> However, I do not believe image   maps are sufficient for complex
>>>> examples of applications rendered in canvas, because there is no concept
>>>> of DOM hierarchy between image map areas.
>>> 
>>> It sounds like you haven't read the proposal completely in its most recent version, because it includes extending image maps along the lines of HTML 4.01 precisely for this reason. (It is sort of possible to get a structure using HTML 4.01 - or the HTML5 model except that as far as I can see that doesn't work in any software. But making it easier would make more sense).
>> 
>> <!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image map -->
>> http://www.w3.org/TR/REC-html40/sgml/dtd.html
>> 
>> I must admit I had never noticed that HTML 4.01 allowed block content in MAP.
> 
> In HTML 4.01 only area elements or a elements can have shapes/coords attributes, which is why the change proposal now adds them to every element. As noted, that is slightly overkill, but if they are not inside a map they simply have no effect so I don't *think* it is problematic, and it seems simpler than listing them for "almost every element...".

This sounds to me like the idea is to keep the "shadow DOM" idea, but have the accessible tree as a descendant of the MAP element rather than inside the CANVAS element directly. Is that correct? If so, I like it. Simple cases could use plain old AREA siblings, but more complex examples could have as deep a DOM tree as needed.

> So in HTML 4.01 you would have to use a elements for a lot of stuff, which still lets you do things like make
> 
> <p contenteditable><a href=# onclick="foo()" shape="rect" coords="...">This is a fake form


Why an anchor and not this?

<map …>
<p contenteditable tabindex="0" role="textbox" onfocus="foo()" shape="rect" coords="...">This is a fake textfield
</map>

James

PS. I also appreciate that this will allow polygons, which were dropped from the previous proposal.
Received on Monday, 21 June 2010 21:30:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:50 UTC