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

On 2/6/12 12:27 AM, Charles McCathieNevile wrote:
> On Thu, 02 Feb 2012 19:36:03 +0100, 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);
>>
>> 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...

Has it been used in practice? Authors are certainly ready for event 
delegation and conditional statements.
My focus is simply on supporting current APIs.

I understand and appreciate vendors are reaching further than that. I'd 
think things swell if vendors simply supported existing APIs for 
third-parties.


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

As far as I understand, they may use DOM to track what's happening, in 
terms of x/y and object; they may even use Canvas pixel colors mapped to 
an associative array. But that's it. That's all I've ever seen used and 
usually it's simply x/y coordinates.


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

I'm open to ideas. I hope I've expressed my focus. I'd like to support 
what exists in Windows and Mac, in iOS and Android, so third party apps 
and web apps can interop. The concept is laid out in WCAG. At this 
point, I'm not trying to invent, I merely want to expose what has 
existed for decades.

I certainly want to go further, but I hope to cover these basics first. 
I know the basics can be covered elegantly, with existing code bases. I 
know this because I've worked with the system APIs, I've implemented 
Canvas several times, and I've browsed Mozilla and WebKit code bases.

On the particular topic of multiple destinations and elements: there is 
a convergence of need. -webkit-element; moz-element; WebGL in css; these 
all bring up a similar issue. That issue, though, has not been solved. 
SVG2 is where my focus is, for future APIs. I'm still pushing hard to 
see <replicate> make it into the SVG2 feature-set. It similarly brings 
up the concept of an element being in multiple places. I need it for a 
reason completely removed from the intent of the author of the 
<replicate> proposal. I need it for reasons that have come up while 
using Canvas.


-Charles

Received on Monday, 6 February 2012 11:31:08 UTC