Re: [csswg-drafts] [scroll-animations-1] Allow named ranges to be used with math functions (#8852)

The CSS Working Group just discussed `[scroll-animations-1] Allow named ranges to be used with math functions`, and agreed to the following:

* `RESOLVED: Add mechanism so that you can use values from animation ranges in math functions, details at editor’s discretion, in L2`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> ydaniv: there's a desire to use animation ranges with math functions, but currently not allowed by the syntax<br>
&lt;emilio> ... this requires new syntax<br>
&lt;emilio> ... there are other proposals in other issue<br>
&lt;emilio> ... wrapping the entire range with another function that allows you to resolve to a &lt;length-percentage><br>
&lt;emilio> ... defer this to L2 is the proposal<br>
&lt;emilio> ... fine for me<br>
&lt;bramus> q+<br>
&lt;astearns> ack bramus<br>
&lt;bramus> https://github.com/w3c/csswg-drafts/issues/8852#issuecomment-1588794640<br>
&lt;emilio> bramus: an example where this is needed is...<br>
&lt;emilio> ... where you have view timelines and you scroll all the way to the bottom of the page<br>
&lt;emilio> ... ?? until it gets to the middle of the scrollport<br>
&lt;emilio> ... but it can never reach that position<br>
&lt;emilio> ... so you scroll down and the image is mid-way the animation<br>
&lt;emilio> ... you can hack around this by adding block padding at the bottom<br>
&lt;emilio> ... allowing the ranges in math functions would solve this<br>
&lt;emilio> ... you'd be able to do something like animation-range: end min(scroll 100%, cover 50%)<br>
&lt;emilio> ... that way you take the min of those<br>
&lt;emilio> ... the animation would be a bit fast because you target smaller scroll distance<br>
&lt;emilio> ... but content will be fully visible<br>
&lt;emilio> ... which is better for users<br>
&lt;bramus> s/animation-range: end min(scroll 100%, cover 50%)/animation-range-end: min(scroll 100%, cover 50%)<br>
&lt;emilio> PROPOSED: Put this in scroll animations L1<br>
&lt;emilio> s/L1/L2<br>
&lt;emilio> emilio: we do something similar for colors already<br>
&lt;emilio> astearns: so proposal is figuring out the syntax<br>
&lt;emilio> bramus: syntax is there right?<br>
&lt;emilio> astearns: so why L2?<br>
&lt;emilio> ydaniv: Maybe flackr remembers issues<br>
&lt;astearns> s/why L2/what goes in L2/<br>
&lt;emilio> bramus: more like making min() take view-timeline-range<br>
&lt;emilio> ydaniv: there was another proposal<br>
&lt;emilio> flackr: not sure if there's a reason not to have the original proposal, not sure if adding the names everywhere they need to will have ambiguity or something<br>
&lt;ydaniv> like `offset(cover 50%)`<br>
&lt;emilio> bramus: we could bring this back if we need to add something else<br>
&lt;emilio> astearns: so we need to add anything to the spec?<br>
&lt;emilio> flackr: this isn't in the spec<br>
&lt;emilio> ... probably affects values-5<br>
&lt;emilio> astearns: perhaps we add an example to the spec<br>
&lt;emilio> ... to point out that we have the intent that they should work?<br>
&lt;emilio> q+<br>
&lt;emilio> astearns: if we come up with issues in the examples we figure out if we need ??<br>
&lt;emilio> astearns: have a hard time figuring out which change is being asked for<br>
&lt;bramus> emilio: change that is being asked for putting this to the spec<br>
&lt;bramus> … proably needs to got into values<br>
&lt;bramus> … this is definitely possible. do the same for anchor()<br>
&lt;bramus> … adding these keywords seems fine<br>
&lt;bramus> … definitely more work than a syntax like the one ydaniv suggested<br>
&lt;bramus> … so depending on the extent of this whole calc stuff<br>
&lt;bramus> q+<br>
&lt;astearns> ack emilio<br>
&lt;bramus> … offset() imple wise is simpler<br>
&lt;flackr> Maybe wrapping it in a function like range(&lt;name>, %) would simplify parsing it?<br>
&lt;bramus> … but that’s not an objection<br>
&lt;bramus> … because all calc() is generally more generic for this stuff<br>
&lt;astearns> ack bramus<br>
&lt;emilio> bramus: was gonna suggest to support `offset()`<br>
&lt;emilio> ... adding a function that returns back the computed pixel value for the range you give it<br>
&lt;emilio> ... and we circumvent the whole complication<br>
&lt;emilio> q+<br>
&lt;astearns> ack emilio<br>
&lt;bramus> emilio: dont think that ??<br>
&lt;bramus> … you dont want this conversion to happen at computed value time<br>
&lt;bramus> … it does not matter if you rpeserve it aas keywords when you resolve them<br>
&lt;bramus> ; the idea is to use this offset fn inside calc and it returns the px value … that is more complicated …<br>
&lt;bramus> … amount of effort you need is similar<br>
&lt;bramus> … dont see a reason to do that, unless the identifiers are unambiguous<br>
&lt;kizu> q+<br>
&lt;bramus> … e.g. all color component stuff<br>
&lt;bramus> … can do something like this much like we do color component stuff<br>
&lt;flackr> q+<br>
&lt;bramus> … just need to … thought the proposal was some standalone fn that would offset the thing when you do offset(50%)<br>
&lt;bramus> … for the case you gave it seems like what you want ti to<br>
&lt;bramus> … supporting identifiers in calc is fine and less complicated<br>
&lt;bramus> … you”re suppporting an identifier that resolves to a ???<br>
&lt;astearns> ack kizu<br>
&lt;emilio> kizu: +1 to emilio<br>
&lt;emilio> ... mostly because if we add it as an offset() it'd work only inside these ranges<br>
&lt;emilio> ... having stuff like this can be confusing or frustrating, you'd want to use it in other places<br>
&lt;emilio> ... I think you want to use it in the ?? function<br>
&lt;emilio> q+<br>
&lt;emilio> qq+ to reply<br>
&lt;emilio> kizu: in anchor-positioning you already need to be careful of where anchor() is allowed<br>
&lt;emilio> ... it'd be nice to avoid that complexity<br>
&lt;emilio> ack emilio<br>
&lt;Zakim> emilio, you wanted to react to kizu to reply<br>
&lt;bramus> emilio: to be clear, i still we think we need to limit where this applies to<br>
&lt;bramus> … cant add it random length-percentages<br>
&lt;bramus> … bc you dont know the scroll ranges when computing the widdth<br>
&lt;bramus> … can prolly add to more things as needed, but would be mostly about the range properties initially<br>
&lt;astearns> ack flackr<br>
&lt;emilio> q'<br>
&lt;emilio> q-<br>
&lt;emilio> flackr: probably range props and keyframe offsets<br>
&lt;emilio> ... a range is 2 values, start and end<br>
&lt;emilio> ... that might complicate it being a single keyword<br>
&lt;emilio> ... but I'm sure we can work that out<br>
&lt;emilio> q+<br>
&lt;astearns> ack emilio<br>
&lt;bramus> emilio: i dont see why that would be an issue<br>
&lt;bramus> … these keywords would only appear inside calc or on their own<br>
&lt;bramus> flackr: yes, we only have a single keyword for contain for example<br>
&lt;bramus> … but contain 0% and contain 100% are both values that authors might need to reference<br>
&lt;bramus> emilio: oh, i see<br>
&lt;bramus> … so you dont want just … i thought the scroll keyword would do the whole range<br>
&lt;bramus> … and then you multiply<br>
&lt;bramus> … it would have a keywrod that resolves the px value of the offset<br>
&lt;bramus> … if you need to ref the keyword %, then you need some syntax … then maybe yeah you need a fn<br>
&lt;bramus> … can figure out the details<br>
&lt;bramus> flackr: or a pair of keywords<br>
&lt;bramus> … no strong feelings<br>
&lt;bramus> emilio: can figure out the details<br>
&lt;bramus> … proposal would be to add something that you can use in match functions for animation ranges that eventually resolves to pixels<br>
&lt;bramus> … details tbd<br>
&lt;bramus> astearns: and this will go into L2<br>
&lt;bramus> PROPOSED: Add mechanism so that you can use values from animation ranges in match functions, details at editor’s discretion, in L2<br>
&lt;bramus> s/match/math<br>
&lt;bramus> RESOLVED: Add mechanism so that you can use values from animation ranges in math functions, details at editor’s discretion, in L2<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8852#issuecomment-2628561767 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 31 January 2025 23:27:01 UTC