- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 21 Aug 2025 13:27:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[pointer-animations-1] Use padding edges as timeline range for pointer timelines`, and agreed to the following: * `RESOLVED: Pointer progress timeline uses the border box extent` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> scribe+ kbabbitt<br> <kbabbitt> ydaniv: pointer animations is now an ED<br> <ydaniv> https://drafts.csswg.org/pointer-animations-1/<br> <kbabbitt> ... link ^<br> <kbabbitt> ... basically the gist is that it adds pointer timelines<br> <kbabbitt> ... biulding on top of existing idea of view timeline for scroll animations<br> <kbabbitt> ... but making ranges and other ideas more relevant for effects specific to pointer animatinos<br> <kbabbitt> ... so the 3 issues we have here are<br> <kbabbitt> ... around creating the timeline, the ranges, and the interpolation for the timeline<br> <kbabbitt> ... basically properties which help you specify and control these aspects<br> <kbabbitt> ... the spec is there, everything is there, but I wanted to flesh out the most concrete issues from the spec<br> <kbabbitt> ... and have them discussed in the group<br> <kbabbitt> ... could just present and have people comment on issues so we can resolve or reach better design<br> <kbabbitt> .... and move forward to WD<br> <kbabbitt> ... first issue is about how we define the timeline<br> <kbabbitt> ... for scroll animations your full timeline is always the full sroll of your scroll container<br> <kbabbitt> ... with pointer timelines your timeline can be either an element, in this case the issue is about using padding edges<br> <kbabbitt> ... of the principal box of that element<br> <kbabbitt> ... so if the timeline could be either an element or the root<br> <kbabbitt> ... root means entire viewport<br> <kbabbitt> ... if it's an element then use the principal box of that element<br> <kbabbitt> ... using same concept as pointer events<br> <kbabbitt> ... as in offset x and offset y of pointer events<br> <kbabbitt> ... specified in cssom view 1<br> <flackr> q+<br> <kbabbitt> ... using the padding edge, start, and end for entire timeline<br> <kbabbitt> ... this is alrady in the spec, this is the formal proposal<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <kbabbitt> flackr: why do we use the padding edges?<br> <kbabbitt> ... isnt' it typical to give offsets from border box edges?<br> <kbabbitt> ydaniv: this is to be consistent wuith pointer events<br> <astearns> https://www.w3.org/TR/cssom-view-1/#dom-mouseevent-offsetx uses padding edge<br> <kbabbitt> flackr: ok<br> <kbabbitt> ydaniv: pointer-events also use padding edges, we use same model<br> <SebastianZ> q+<br> <kbabbitt> ... I have it in the issue, I think it's offset-x and offset-y<br> <kbabbitt> flackr: looking at it now<br> <kbabbitt> ydaniv: if someone needs to polyfill this, for example WIX is doing now, this just keeps working as is<br> <kbabbitt> ... of course there are some discrepanciew there because I think webkit ignore borders<br> <kbabbitt> ... I think other browsers .. there's some discrepancies but this is in the spec<br> <kbabbitt> flackr: what about on the root? would it be relative to viewport or document origin which would be way above the otp of viewport?<br> <kbabbitt> ydaniv: root uses the viewport<br> <kbabbitt> flackr: or both<br> <kbabbitt> ... for pointer events and pointer animations<br> <kbabbitt> s/or both/for both/<br> <kbabbitt> ydaniv: for pointer-events, if you take from the event<br> <kbabbitt> .... you also have an ability to take viewport from event<br> <kbabbitt> ... x and y relative to viewport<br> <kbabbitt> flackr: yes but that's a different property<br> <kbabbitt> ydaniv: yes, in case of using root as subject of the timeline, it uses<br> <kbabbitt> flackr: I think screen x and screen y<br> <kbabbitt> ydaniv: could be<br> <kbabbitt> ... again going exactly with what pointer-events do today<br> <kbabbitt> astearns: screen x and screen y is relative to screen<br> <kbabbitt> ... client x and client y are relative to viewport<br> <kbabbitt> ydaniv: yeah so client x and client y i this case<br> <kbabbitt> ... either that or offset also is aliased by x and y<br> <kbabbitt> astearns: client is aliased by x and y<br> <kbabbitt> astearns: flackr, any follow up?<br> <kbabbitt> flackr: no that's fine<br> <astearns> ack SebastianZ<br> <kbabbitt> SebastianZ: I see it's in the issue but want to iterate on that<br> <kbabbitt> ... I think it makes sense to have them applying to pdding edges<br> <kbabbitt> ... but we could extend to other edges if necessary via new prop<br> <kbabbitt> ydaniv: yes idea is to default to same as pointer-events, could also add another property if you want to choose another box<br> <kbabbitt> ... that can be separate issue to extend spec<br> <kbabbitt> astearns: lacking particular use cases it wouldn't have to be in first version<br> <kbabbitt> ydaniv: yeah<br> <kbabbitt> SebastianZ: sounds like we could resolve on that?<br> <kbabbitt> astearns: Proposed resolution is that the pointer-event timeline uses the padding edges by default to match pointer events<br> <kbabbitt> flackr: Is the implication here that 0-100% for the range of animation is the padding box?<br> <kbabbitt> ... when you make a pointer animation for an element, this decision we're making implies that top left position of animation is the padding box edge<br> <kbabbitt> ... is the idea that by default pointer animation maps to padding box?<br> <kbabbitt> SebastianZ: padding box is frame for pointer animation timeline<br> <kbabbitt> flackr: ok, just wantd to clarify<br> <kbabbitt> ... numbers themselves don't matter much once you get through timeline conversion<br> <kbabbitt> ... this is about basically pointer animation<br> <kbabbitt> ydaniv: thi sis the full timeline<br> <kbabbitt> flackr: one thing that's confusing about this is it doesn't match hover by default<br> <kbabbitt> astearns: ah<br> <kbabbitt> ... what box does hover use?<br> <kbabbitt> flackr: border box I believe<br> <kbabbitt> ydaniv: I think that's okay because hover is used for completely different effects<br> <kbabbitt> ... more important to be consistent with pointer events<br> <kbabbitt> flackr: don't know if iI'd say that's true<br> <kbabbitt> ... you still get pointer events even over border box<br> <kbabbitt> ... they would just have negative offset X and Y<br> <kbabbitt> ... but it's still the target of the event so a dev handling those events would still see them<br> <kbabbitt> ydaniv: ok<br> <bramus> can confirm that :hover uses the border-box<br> <kbabbitt> astearns: can you handle negative and more than 100 values in pointer animation?<br> <kbabbitt> flackr: we do this in view timeline already<br> <kbabbitt> ... default range of view timeline is cover range<br> <kbabbitt> ... but you can create animations that extend beyond element's cover range<br> <kbabbitt> ydaniv: ranges yes but full timeline<br> <kbabbitt> flackr: it's still active outside cover trange<br> <kbabbitt> ... so it has negatives in view timeline<br> <kbabbitt> SebastianZ: just tested it is the border box for hovering<br> <kbabbitt> bramus: for view time line you can indeed go outside cover range<br> <kbabbitt> ... for scroll time do we allow?<br> <kbabbitt> flackr: there is no such thing as negative scroll offset<br> <kbabbitt> bramus: in blink yes but in webkit?<br> <kbabbitt> flackr: it wouldn't be exposed but we would still want timeline to be active in that case<br> <kbabbitt> ... I think there's more of a dev expectation for this to match event targeting and hover than offset x and offset y<br> <kbabbitt> ... I could be mistaken<br> <kbabbitt> ydaniv: very different family of effects<br> <kbabbitt> ... like micro interactions and full blown pointer animations<br> <kbabbitt> ... usually for hover you have just simple translations<br> <kbabbitt> flackr: what I'm worred about is dev adding effect on hover and assuming that when hover is active pointer animation is also active<br> <kbabbitt> bramus: I would also expect pointer timing to be active when I start hovering element from border<br> <kbabbitt> astearns: you had mentioned ydaniv that one of your considerations was that you would want to be able to polyfill this using mouse events<br> <kbabbitt> ydaniv: yes<br> <kbabbitt> astearns: if we decided timeline range was over border box, it would still have mouse events you could handle, would just have negative and >100 values you would have to adjust to fit this other extent<br> <kbabbitt> ydaniv: yes<br> <kbabbitt> ... there's a bunch of inconsistencies and bugs between browsers regarding pointer events<br> <kbabbitt> ... most of them only surface when you use synthetic events for pointer events<br> <kbabbitt> ... some in chrome some in webkit<br> <kbabbitt> ... I guess that I can surface all of those maybe we can also try to fix them as we start to ship this<br> <kbabbitt> ... so once people try to polyfill this, they also have more consistent way to polyfill this<br> <kbabbitt> astearns: just wanted to make sure it would be possible, author expectations trump polyfill expectations<br> <kbabbitt> ydaniv: maybe this requires more research to see if it can be properly polyfilled<br> <kbabbitt> astearns: we could resolve that pointer progress timeline usees border box<br> <kbabbitt> ... and then you could do that research<br> <kbabbitt> ... or we could leave this wihtout resolution until you've done that research<br> <kbabbitt> ydaniv: I'm good either way, this is still early stage<br> <kbabbitt> SebastianZ: I would vote for border box<br> <kbabbitt> ydaniv: we can start with border box and if I find there's a big issue with polyfilling we can raise discussion again<br> <kbabbitt> astearns: I would expect research to include both polyfilling and working through use cases to show author expectation for this or that effect is satisfied or not by using border box<br> <kbabbitt> ... so we have a proposed resolution to define the pointer progress timeline to use the border box extent<br> <kbabbitt> ... objections?<br> <kbabbitt> RESOLVED: Pointer progress timeline uses the border box extent<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12396#issuecomment-3210606096 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 August 2025 13:27:29 UTC