Currently the spec for values allowed as <event-trigger-event> is practically placeholder:
<event-trigger-event> = activate | interest | click | touch | dblclick | keypress(<string>) | ...
We should formalize the values for this type.
Options to consider:
- Start with all events? Or start with a limited list and expand as we go?
- Some events could benefit from a functional form with modifier args, as already implied in the spec, such as
key for keyboard , and button for mouse/pointer, etc. Should we allow functional? Allow both functional and keyword? Only functional?
- If we do allow functional form, which args for each event?
- It's already suggested to add
activate and interest (which IMO is great), but do we need activatein/activateout/interest/loseinterest? Or do we leave these to be automatically decided based on usage, i.e. event-trigger: --t interest / interest automatically becomes interest / loseinterest. Or perhaps interest(in|out)?
Proposal
- Start with a limited list and expand. Probably after there's a first prototype deployed in the wild. I think starting with keyboard/mouse/pointer/
interest/activate as suggested is a good start.
- I think both are good (if it's not a problem).
- I guess starting with the suggested
key for keyboard events is fine as a starting point. Probably as a space delimited list? And if so, probably needs a special case for " " to be handled as Space.
- I think starting with just
interest/loseintereset, and activate being decided automatically based on usage should be a good start.
cc @flackr @DavMila
Currently the spec for values allowed as
<event-trigger-event>is practically placeholder:We should formalize the values for this type.
Options to consider:
keyfor keyboard , andbuttonfor mouse/pointer, etc. Should we allow functional? Allow both functional and keyword? Only functional?activateandinterest(which IMO is great), but do we needactivatein/activateout/interest/loseinterest? Or do we leave these to be automatically decided based on usage, i.e.event-trigger: --t interest / interestautomatically becomesinterest / loseinterest. Or perhapsinterest(in|out)?Proposal
interest/activateas suggested is a good start.keyfor keyboard events is fine as a starting point. Probably as a space delimited list? And if so, probably needs a special case for" "to be handled asSpace.interest/loseintereset, andactivatebeing decided automatically based on usage should be a good start.cc @flackr @DavMila