Re: [fxtf-drafts] [motion-1] the description of contain flag in ray() function (#363)

Reopening because I'm trying to fix the spec text and I'm still not 100% clear on what this is trying to say.

Okay so, first, it looks like it doesn't actually change the length of the offset path - `100%` is still, technically, at the same distance regardless of whether `contain` is specified or not. We'll just automatically adjust the *actual* offset-distance to satisfy the `contain` constraint, so some portion of the possible offset-distance space near the end all maps to the same actual position.

Then, at positioning time, we look at where the 100% point on the ray is, and possibly adjust the actual offset-distance so that the furthest side/corner (along the specified angle) of the transformed element's (border box?) bounds are further from the initial position than the 100% point.

I think this explains the second example in <https://drafts.fxtf.org/motion-1/#example-ray> - the red box is pulled inward so that its furthest point from the initial position (its top-right corner) is exactly at the 100% point, while the blue box is pulled in so that its furthest points (the entire bottom edge) are exactly at the 100% point. (Notably, the blue box overflow the "100% shape" slightly, but we only actually care about the precise point along the ray, and distances along lines parallel to the ray.)

Tho, hm, this quote from Eric:

> At offset-distance 100%, we move the box backwards slightly more than 50px so that the entire box (all 4 corners, not just the center points of edges) fits within the circle. For example, using a 5-12-13 triangle, if the path length was 130px, we would move the box backwards 60px.

suggests that we *do* need to actually contain it within the "100% shape", so the corners don't overflow the shape at all. This means the example is wrong.

------

I'm completely confused by what's supposed to happen when the transformed box overflows the "100% shape" even at offset-distance 0%. The third example trying to show this off is impossible to parse - the code indicates a ray pointing west, but there's a dotted line pointing east, and then the box itself is positioned to the south for some reason.

Hm, I guess the weird `offset-anchor: 200% -300%;` is relevant here? Like, the end of the dotted line happens to be the offset-anchor of the transformed element, and it's positioned *there*, at a negative offset-distance, because that places the transformed element's bounds within the smallest possible expansion of the "100% shape"?

I'm confused by Eric's assertion that we'd have different behavior at offset-distance:0% and 100%. It seems like, given the transformed element's size and offset-anchor, it's outside the 100% shape in both cases. Wouldn't we do the same thing in both cases, then?

--------

I'm also not sure if this is meant to take border-radius into account?

--------

Also, while the side/corner keywords have a reasonably straightforward notion of what it means to "extend" them (increase the radius of the 100% circle they define), it's not clear to me what extending the `sides` keyword means. Is the rectangle expanded a fixed distance in each direction? Something % based? Something else?

---------

Overall I don't understand what the `contain` keyword is trying to accomplish here. I believe it's *intended* to solve the use-case of "put some elements around the inner edge of a circle, aka the numbers around clock face", without requiring the author to do some trig to know how far in from 100% they should position things. It does it in such an odd way, however, and seems like it'll result in slightly bad behavior even for the most straightforward cases, since the actual "max distance" varies depending on angle.

The way it's defined, it'll also result in funky animation behavior for animating from 0% to 100% - depending on the angle, it'll reach its "max distance" at varying %s, so a bunch of elements all animating from the center to the edge at once will "hit the edge" at different points in their animations. Similarly, an animation from the edge to the center will look like it's delayed for an unpredictable amount of time (while it's still past its "max distance"), and then depending on angle will start moving at different times.

I feel like the entire feature needs to be rethought slightly.  Thoughts, @BorisChiou @ericwilligers ?

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/363#issuecomment-1419931054 using your GitHub account


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

Received on Monday, 6 February 2023 23:24:44 UTC