Bikeshed: activation event naming.
vmpstr opened this issue · 12 comments
We would like to extract the activation event from the render-subtree spec, making it a separate event that is fired in one of three situations:
- find-in-page active match results.
- fragment link navigation.
- scroll to text navigation.
We don't currently have a good name for this. One idea is to have an interest event (credit: @flackr)
Also from @flackr:
Activation is already a defined term for :active and I don't think it's synonymous with this kind of activation.
Any other ideas? We'd like to get this resolved by EOW
/cc @josepharhar
What would the event contain and which nodes will it fire to? (esp. for find-in-page and scroll to text) That might help the naming
It will fire on the active-match or anchor target element.
(to get good enough performance, it'd have to be rate-limited as well in some way)
OK, so all elements that contain the matches? (beforeactivate is sent to all locked ancestors of all elements that contain the matches)
Yes.
Or via bubbling up from such elements.
Also, accessibility features may be integrated into the user agent, traverse the DOM, and fire such events if desired. In the future, maybe other new algorithms could be integrated.
I suggest beforematch for the event. The "match" is the element that the UA has decided to focus on on behalf of the user. The scroll to text fragment spec also uses the name "match" in its algorithm, in addition to Chromium's find-in-page code.
This event is not cancellable, and happens at render timing.
I don't think it is clear to developers what is being "matches" and that that links to find-in-page etc.
"before" is also a bit confusing, like when before is it? a few render frames before?
It feels a bit like something being "focused/highlighted" in a way
I don't think it is clear to developers what is being "matches" and that that links to find-in-page etc.
"before" is also a bit confusing, like when before is it? a few render frames before?
The intent is for it to be at at render timing (just before rAF, during the same event loop task) in the same rendering update that would apply a scroll to the matched element.
It feels a bit like something being "focused/highlighted" in a way
Reasonable ideas - maybe beforehighlight?
beforematch seems to be sticking as the name for now. Let's keep this issue open in case we need other choices though.