Re: Request to re-open issue 131 -USE CASES, USE CASES, USE CASES

On Thu, 02 Feb 2012 19:36:03 +0100, Charles Pritchard <>  

>> On Thu, Feb 2, 2012 at 1:35 AM, Charles Pritchard<>   
>> wrote:
>>> As for the relatedTarget, I don't know that it's necessary to include  
>>> it.
>>> The author already knows which canvas they used when they bound to the
>>> sub-element.
>> How do they know that?
> When they wire up the event handlers, they have specific data at hand.
> If it's absolutely necessary,  they can setup an object to help them  
> track it.
> var myObj = {};
> ctx.setElementPath(myObj[] = subElement);
> Again, though, you have items like onclick, where it's plausible that  
> the click was triggered by keyboard.
>> What happens if different canvas paths, perhaps in different canvases,
>> are bound to the same element?
> The latest canvas to bind wins the prize.
> I don't think the DOM+CSS model is ready to handle multiple boxes  
> pointing to one element.

But web page design is well past ready for that, and there are lots of  
ways to do it...

> This binding is really more about CSS and the browser's internal  
> implementation of a light shadow dom than it is about canvas.
> It's the DOM we're updating. The canvas implementation should not be  
> keeping track of things. It's the DOM+CSS implementation that should be  
> doing the work.

Agreed. But we should design for reality not theory, and my sense tells me  
that far too many people *do* use the canvas to keep track of what is  
happening instead of a nice clean architecture...

> DOM does support multiple rectangles in getClientRects, I don't think  
> it's something we need to aspire to.
> If an author has several paths, they can easily run them before a single  
> binding call.



Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk       Try Opera:

Received on Monday, 6 February 2012 08:28:59 UTC