Looing for feedback: Behavior API Proposal V2

[John Hendrikx]

Hi List,

I've written down a new Behavior API proposal which has some interesting 
changes to even better separate behavior from skins.

Skins currently already determine much of the behavior by only 
installing specific event handlers, or only calling behaviors in 
specific instances (they effectively are already doing some 
interpretation or filtering of events). This proposal aims to do away 
with all that, allowing behaviors to be in full control on what events 
they wish to listen to, even for events triggered on the skins children 
or substructure.

An example is SpinnerSkin, which currently dictates without the behavior 
being able to intervene that ALL mouse buttons will trigger the spinner 
buttons (this is most likely a bug, but shows that skins have too much 
control here).  The behavior once triggered lacks the necessary 
information to filter this to only the primary button as the event was 
already interpreted by the skin.

This proposal changes this by letting all relevant substructure events 
bubble up to the control level, where the behavior is free to install 
any event listeners it wants to do anything it wants. All that is needed 
to make this work is a way for the behavior to know on which part of the 
substructure an event was triggered. This can be determined by examining 
the event target, and together with already public information about the 
skins substructure (available for CSS) this is enough to allow behaviors 
to respond to any possible event performed on a specific piece of 
substructure, and not just events sanctioned by the skin.

This will make it possible for behaviors to be a really powerful API to 
radically alter how visuals react to mouse movements, keyboard events, 
drags, gestures, etc, without being limited by the skin designer's 
imagination.  An example would be to have Spinners react to the scroll 
wheel, which currently is not possible without the skin's cooperation.

This proposal leaves out the semantic event concept for now as something 
that can be added later.  Since they're not needed anymore for skins to 
communicate with behaviors, they can wait a bit.

The proposal also includes ways of dealing with Behaviors that require 
knowledge of the exact visual layout a skin provides (TextAreaBehavior) 
that I think is not an unsatisfactory solution.

https://gist.github.com/hjohn/c7b1bf9d4a4770b1b3ae854b20fbaa94

Looking forward to hearing your feedback!

--John