- From: Charles McCathieNevile <chaals@opera.com>
- Date: Mon, 30 Jan 2012 10:34:56 +0100
- To: "Charles Pritchard" <chuck@jumis.com>, "Jonas Sicking" <jonas@sicking.cc>, "Frank Olivier" <Frank.Olivier@microsoft.com>
- Cc: "Richard Schwerdtfeger" <schwer@us.ibm.com>, "Cynthia Shelly" <cyns@microsoft.com>, "david bolter" <david.bolter@gmail.com>, "dbolter@mozilla.com" <dbolter@mozilla.com>, "Maciej Stachowiak" <mjs@apple.com>, "Paul Cotton" <Paul.Cotton@microsoft.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "Sam Ruby" <rubys@intertwingly.net>, "Steve Faulkner" <faulkner.steve@gmail.com>
On Fri, 27 Jan 2012 18:41:20 +0100, Frank Olivier
<Frank.Olivier@microsoft.com> wrote:
> Ah - I see.
>
> I think that reusing the canvas path concept in canvas is a more
> 'natural' way to define a region of interest on a canvas bitmap. An
> added bonus (useful when debugging) is that you can draw the path that
> you defined for setElementPath() quite easily with other canvas methods.
Sure. I was really trying to anchor that approach in markup that people
already knew how to handle, since I thought for many cases taht would be
simpler than having to create the entire shadow through js. But I think we
are basically using the same approach to solve the same problem, and I am
not too fussed about the finer syntactic details.
cheers
Chaals
> -----Original Message-----
> From: Charles McCathieNevile [mailto:chaals@opera.com]
> Sent: Friday, January 27, 2012 2:22 AM
> To: Charles Pritchard; Jonas Sicking; Frank Olivier
> Cc: Richard Schwerdtfeger; Cynthia Shelly; david bolter;
> dbolter@mozilla.com; Maciej Stachowiak; Paul Cotton;
> public-canvas-api@w3.org; public-html@w3.org; public-html-a11y@w3.org;
> Sam Ruby; Steve Faulkner
> Subject: Re: Fw: Request to re-open issue 131 -USE CASES, USE CASES, USE
> CASES
>
> On Fri, 27 Jan 2012 03:35:18 +0100, Frank Olivier
> <Frank.Olivier@microsoft.com> wrote:
>
>> Ages ago we had some discussions around using image maps for canvas.
>> For the record, I'm against this idea, as the HTML5 specification
>> already has the (sensible) requirement of mapping canvas UI elements
>> to elements in the DOM, and wiring up event/state synchronization
>> between a canvas image map and the underlying DOM elements seems like
>> even more work for the author.
>
> Hmm. The rationale was the other way around. If you have an element in
> the DOM, and you can name it as part of a map, then the manipulation of
> where it is on the canvas is exactly what you need to specify the
> coordinates that identify what it corresponds to on the canvas.
>
> This took the full HTML4.01 image map specification including things
> like putting shape/coords elements on block elements, and added a path
> syntax to clearly match what you can do on canvas (so your coordinates
> for canvas can be used directly in updating the coords attribute of your
> map element).
>
> It seems that we are doing functionally the same thing, and frankly I
> don't care about the syntax, but I had thought it would be easier to
> build on the image map concept that people already know.
>
> cheers
>
> Chaals
>
> --
> Charles 'chaals' McCathieNevile Opera Software, Standards Group
> je parle français -- hablo español -- jeg kan litt norsk
> http://my.opera.com/chaals Try Opera: http://www.opera.com
>
--
Charles 'chaals' McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Monday, 30 January 2012 09:36:15 UTC