- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 Jan 2025 14:40:43 +0000
- To: public-css-archive@w3.org
I don't think there was any reason for this not to be allowed so this seems reasonable. Resolving the calculation depends on the particular target being animated though technically so do the range names in general so I think this should be fine. For the WAAPI api, [rangeStart](https://drafts.csswg.org/web-animations-2/#dom-animation-rangestart) and [rangeEnd](https://drafts.csswg.org/web-animations-2/#dom-animation-rangeend) accept a [TimelineRangeOffset](https://drafts.csswg.org/web-animations-2/#dictdef-timelinerangeoffset) as well as a DOMString. Presumably we would accept the same for keyframe offsets so as not to require string parsing, and when reading back the value from calling [getKeyframes](https://drafts.csswg.org/web-animations-1/#dom-keyframeeffect-getkeyframes) you would presumably get the TimelineRangeOffset type. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10000#issuecomment-2580424855 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 9 January 2025 14:40:44 UTC