Re: Alternative Canvas proposal from Charles

Please continue reading Charles' reply. His idea appears to combine both ideas, including the shadow DOM approach, but contained within the MAP element rather than in the CANVAS element. Simple image maps will suffice in most cases, and the shadow DOM inside the image map looks like it will cover everything else.


On Jun 21, 2010, at 10:29 PM, Frank Olivier wrote:

> James Craig: "I support the idea of image maps on canvas as an addition to, but not as a replacement of, the shadow DOM idea."

I did say that, but it was before I understood that the image map proposal can incorporate a shadow DOM. 

> IE team agrees.
> 
> 
> -----Original Message-----
> From: James Craig [mailto:jcraig@apple.com] 
> Sent: Monday, June 21, 2010 2:30 PM
> To: Richard Schwerdtfeger; David Bolter; Michael Cooper; Janina Sajka; Charles McCathieNevile; Cynthia Shelly; Steven Faulkner; Frank Olivier; public-canvas-api@w3.org; HTML Accessibility Task Force
> Subject: Re: Alternative Canvas proposal from Charles
> 
> 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 Tuesday, 22 June 2010 17:13:28 UTC