Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

Bikeshed: activation event naming. #115

Closed
vmpstr opened this issue Feb 18, 2020 · 12 comments
Closed

Bikeshed: activation event naming. #115

vmpstr opened this issue Feb 18, 2020 · 12 comments
Assignees

Comments

@vmpstr
Copy link
Collaborator

vmpstr commented Feb 18, 2020

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 @chrishtr @rakina @fergald @flackr

@chrishtr
Copy link
Collaborator

/cc @josepharhar

@rakina
Copy link
Member

rakina commented Feb 19, 2020

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

@chrishtr
Copy link
Collaborator

It will fire on the active-match or anchor target element.

@chrishtr
Copy link
Collaborator

(to get good enough performance, it'd have to be rate-limited as well in some way)

@rakina
Copy link
Member

rakina commented Feb 19, 2020

OK, so all elements that contain the matches? (beforeactivate is sent to all locked ancestors of all elements that contain the matches)

@chrishtr
Copy link
Collaborator

Yes.

@chrishtr
Copy link
Collaborator

Or via bubbling up from such elements.

@chrishtr
Copy link
Collaborator

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.

@chrishtr
Copy link
Collaborator

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.

@kenchris
Copy link

kenchris commented Mar 3, 2020

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

@dbaron

@chrishtr
Copy link
Collaborator

chrishtr commented Mar 4, 2020

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?

@chrishtr chrishtr self-assigned this Mar 5, 2020
@vmpstr
Copy link
Collaborator Author

vmpstr commented May 4, 2020

beforematch seems to be sticking as the name for now. Let's keep this issue open in case we need other choices though.

@vmpstr vmpstr closed this as completed Sep 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants