Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trigger functionality in direction = up vs direction = down #54

Open
andrewpbray opened this issue Jul 27, 2024 · 2 comments
Open

Trigger functionality in direction = up vs direction = down #54

andrewpbray opened this issue Jul 27, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@andrewpbray
Copy link
Contributor

Conversation continued from #47 . . .

But if we have, say:

  1. enter red sticky
  2. discuss red
  3. discuss red
  4. discuss red
  5. enter blue sticky
    What happens if someone scrolls down past blue sticky, then back up? If you scroll back up through 4/3/2, aren't you still looking at blue until 1 enters again? Are we backtracking to find the last focus-on, or do users just need to repeat focus-on for 2/3/4? (I think the latter is a good solution, I just want to make sure I understand)

Hmm, great question. You're right about the expected behavior. If 1 and 5 are the triggers, on direction=up, there will be a mismatch between narrative blocks and sticky.

I think it's a question about what the best defaults are. Different options would include:

  1. remove all .cr-active on exit. (requiring the user to re-add the focus for blocks where they're still talking about the same sticky).
  2. use what we have but by default use the filter to propagate the focus meta down blank narrative blocks. this would lead to cleaner source docs, which I value.

I think most authors will compose their stories top to bottom and most readers will read them that way, which I guess is why I favor a more minimal source that privileges that direction. But we could built in exceptions that allows for directional symmetry. You can imagine that we:

A. introduce a whole slate of what are essentially on-exit behaviors that could be added to trigger like 1. This actually starts dovetailing with the use-case presented by the Permutation Test Demo #46.

B. introduce a .cr-clear class that can be added to triggers like 2 that, on entrance, clear all cr-active (and override the behavior of 2 until it hits another trigger)

Thoughts?

@andrewpbray
Copy link
Contributor Author

Follow-up based on zoom call: we're going to go ahead with 2!

@andrewpbray andrewpbray self-assigned this Aug 2, 2024
@andrewpbray andrewpbray added this to the positconf-24 milestone Aug 5, 2024
@andrewpbray andrewpbray added the enhancement New feature or request label Aug 5, 2024
@andrewpbray
Copy link
Contributor Author

Note to future self: once this is complete, consider adding in a space block feature.

@andrewpbray andrewpbray removed this from the positconf-24 milestone Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant