- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Mon, 6 Feb 2012 22:07:12 +0000
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Frank Olivier <Frank.Olivier@microsoft.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Steve Faulkner <faulkner.steve@gmail.com>, Cynthia Shelly <cyns@microsoft.com>, david bolter <david.bolter@gmail.com>, David Bolter <dbolter@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, 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>
On Thu, Feb 2, 2012 at 6:36 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> On Thu, Feb 2, 2012 at 1:35 AM, Charles Pritchard<chuck@jumis.com> 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[ctx.canvas.id] = subElement);
Assuming that access to the appropriate canvas when an event is
triggered is useful - for example to mutate the appropriate canvas in
response to user interaction - I disagree that we should force authors
to introduce additional global state or to use multiple event
listeners to access this information.
It's a common pattern to listen for events on a root element and use
the event properties to dispatch appropriate behavior (see JQuery
delegation for example). This pattern will not be usable if you cannot
determine the appropriate canvas from the event.
> Again, though, you have items like onclick, where it's plausible that the
> click was triggered by keyboard.
Yes. But why do you mention this?
>> What happens if different canvas paths, perhaps in different canvases,
>> are bound to the same element?
>>
>
> The latest canvas to bind wins the prize.
Needs to be in the proposed spec text.
> I don't think the DOM+CSS model is ready to handle multiple boxes pointing
> to one element.
What do you think is missing from the model?
> 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.
I don't understand the distinction you're making or its relevance to
the discussion.
> 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.
What do you mean?
--
Benjamin Hawkes-Lewis
Received on Monday, 6 February 2012 22:11:51 UTC