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
