Hi Sebastian, Thanks for clarifying all that. It sounds as though manipulating the x/y coordinates of an event triggered on the main surface does, in essence, achieve what traditional delegation would: a single event handler for each event type that's managed in just one place.
You're right in saying that the hit-surface needs to be larger than the visible dots. The trick that I've used at the moment in lieu of adding invisible elements is to use a largish stroke for the points. This way, their hit surface is significantly larger, and it looks quite stylish, too! (In my opinion, anyway. :P) I'd be interested in finding out more about this charting API that you mention... What are the goals of this? To actually provide a charting system (similar to what I'm doing now), or just to simplify the process of creating a charting system? Protovis is (as far as I can tell) a little too low-level to make charting a really simple exercise. You have to specify much more than you'd have to in, say, Excel or Gnumeric. My personal goal is to make a charting system that I can basically just throw numbers at and get something usable and pretty from. It sounds almost as though I've been unknowingly duplicating a lot of the work you're talking about in this API in the lower-level bits and pieces of my own charting system... http://barryvan.com.au/ [email protected] On Sat, Jan 29, 2011 at 10:12 AM, Sebastian Markbåge <[email protected]>wrote: > ART won't support delegation using the classic style. Supporting it would > require a reference from the DOM element to the ART class instance which we > want to avoid. > > The current ART modes support a DOM model which means that you can use the > underlying DOM Elements in any MooTools function. So you can use event > delegation. $(myShape).addEvent('path, shape', ...); Just make sure your > selector covers both the SVG and VML tag names. > > However, there are other ART modes available as plugins. Such as > ART-Canvas. While they will support bubbling they won't support any > underlying DOM Elements (except maybe for some accessibility stuff). > > Even if we had event delegation, a chart typically wants to have a > hit-surface that's bigger than the visual lines or dots. The trick is to use > an invisible element on top. Right now you can use a transparent > fill: shape.fill('rgba(0,0,0,0)') > > On a chart, you don't need this. You can just add a listener on the bottom > surface. Then you use the x/y coordinates of the event to directly infer > what data column you need to address. I'm working on an API to simplify > extracting the x/y calculations from the event. > > There is also a charting helper API in the works. Much like Protovis. That > will allow you to easier work with large sets of elements as a single unit. >
