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