- 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:16 UTC