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

[scroll-animations-1] Where is the range of threshold values checked? #5203

Closed
birtles opened this issue Jun 12, 2020 · 9 comments
Closed

[scroll-animations-1] Where is the range of threshold values checked? #5203

birtles opened this issue Jun 12, 2020 · 9 comments
Labels
Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. scroll-animations-1 Current Work

Comments

@birtles
Copy link
Contributor

birtles commented Jun 12, 2020

For element-based offsets, the threshold member has the following description:

A double in the range of [0.0, 1.0] that represent the precentage[sic] of the target that is expected to be visible in source's scrollport at the intersection offset.

But we don't seem to validate anywhere that that is the case. Should be check it in the constructor for ScrollTimeline?

@birtles birtles added the scroll-animations-1 Current Work label Jun 12, 2020
@birtles
Copy link
Contributor Author

birtles commented Jun 12, 2020

That said, I'm not sure if we want to enforce that range or not. Maybe -0.1 is a useful measure? If so, we should probably say that.

@bramus
Copy link
Contributor

bramus commented Mar 3, 2021

Having the ability to — for example — set end 1.2 as the from-offset sure comes in handy, as it allows you to add some “breathing room” to all of your animations.

A from-offset of selector(#element) end 1.2 basically translates to “the element is 1/5th over the bottom edge”. In that case the animation will not start when #element is stuck against the bottom, but only after it's "120%" into the scrollport.

Also see #6068, where taking scroll-padding into account is suggested.

Both these use-cases could be allowed I guess:

  • Over/undershooting the threshold is calculated in relation to block-size of the #element
  • scroll-padding (if expressed as a percentage) is calculated in relation to the block-size of the scrollport

@MattWilcox
Copy link

I'd prefer it to not clamp to a "valid range" when that "valid range" is entirely arbitrary and restricts design possibilities.

@flackr
Copy link
Contributor

flackr commented Oct 7, 2022

I suspect this may still be applicable for View Timelines, i.e. a desire to be able to extend the effective element size for the purpose of its fit to the view timeline. In scroll snap terms this would be scroll-margin. Note that scroll-margin does not seem to accept a percentage currently so view-timeline-inset seems at least as flexible as what you can do with scroll snap as you can simply add / subtract what the offset relative to the element should be from the inset.

@fantasai
Copy link
Collaborator

fantasai commented Dec 7, 2022

@flackr Isn't this exactly what view-timeline-inset is for? Or am I missing something?

@flackr
Copy link
Contributor

flackr commented Jan 26, 2023

Right, the gap between view-timeline-inset and end: 1.2 is if you specify view-timeline-inset: 20% my understanding is it will be 20% of the scroll range rather than 20% of the element. I don't think this will be significant and imagine we don't need to worry about this.

The percentages we have in the spec don't seem to have precise limits so I'd propose we close this one.

@fantasai
Copy link
Collaborator

fantasai commented Mar 7, 2023

@birtles @bramus Can you confirm if you're ok to close based on @flackr's comment above?

@birtles
Copy link
Contributor Author

birtles commented Mar 9, 2023

It looks like the threshold member no longer exists so it seems fine to close this.

@bramus
Copy link
Contributor

bramus commented Mar 9, 2023

The thresholds are now gone indeed. To mimic what used to be possible, one could set the timeline range percentages to a value lower than 0% or greater than 100%. This however, is not allowed. The keyframe block will be dropped in that case, and I’m perfectly fine with that.

Closing issue. Adjusting labels.

@bramus bramus closed this as completed Mar 9, 2023
Scroll linked animations [scroll-animations] automation moved this from Non-blocking to Done Mar 9, 2023
@bramus bramus added Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. and removed Commenter Response Pending labels Mar 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. scroll-animations-1 Current Work
Development

No branches or pull requests

5 participants