selectable - strange event philosophy?
I recently picked up "selectable" for the first time and struggle to understand the event logic (*). Why is it that events are fired at the container (the thing that was made .selectable)? This imposes on the user an outside-in approach of managing selectees from the container-level. I have populated my container with tons of selectees which all maintain state within their own functional closure. I need my selectees to receive that event. I am thinking of logging an enhancement request to that effect. I figure that if the logic was changed so that these events are fired at the children, then this shouldn't break any existing code since the events will bubble up to the container if not caught, and outside-in management will continue to be an option? Or was the intention of selectable that there need not be a child-parent relationship between ui-selectee and ui-selectable?
(*) Other widgets usually explain the event logic under the Overview tab of the documentation. It would be good if selectable did so, too. Explaining the structure of "ui" etc.