W3C home > Mailing lists > Public > public-html@w3.org > January 2012

RE: Fw: Request to re-open issue 131 -USE CASES, USE CASES, USE CASES

From: Frank Olivier <Frank.Olivier@microsoft.com>
Date: Fri, 27 Jan 2012 17:41:20 +0000
To: Charles McCathieNevile <chaals@opera.com>, Charles Pritchard <chuck@jumis.com>, Jonas Sicking <jonas@sicking.cc>
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>
Message-ID: <91175A762AB48840AF1473514B26B47551749E09@TK5EX14MBXC262.redmond.corp.microsoft.com>
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.

-----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


Received on Friday, 27 January 2012 17:42:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:29 UTC