Re: [fxtf-drafts] [motion-1] offset-position + circle() (#504)

Okay, looking into this more, the "offset-position affects circle()/ellipse()" behavior was committed in <https://github.com/w3c/fxtf-drafts/commit/a1faed1aee67b2acd5f49c17ad782b029bcb800f>, claiming to fix #78. However, #78 ended without any resolutions, and just some topics we needed to address:

> (1) paths can't be specified relative to the container. One suggestion for fixing this was to define a CSS path syntax.

Done now, via shape().

> (2) there's no simple rectangle or polygon shape that can be positioned relative to the element. CSS path syntax somewhat fixes this, but for rectangles we thought that adding a new rect() type that included a position and width/height information would be useful.

Done now, via xywh().

> (3) we need to specify the fallback behavior for circle and ellipse

After rereading the issue a few times, still not sure what this is referring to.

> (4) we need to specify path() positioning and make sure it makes sense

I *think* this was about the "path relative to element's current position" thing.

---------

So I think the edits ended up doing the one thing we agreed to punt on (making offset-position interact with basic shapes) and failed to add the one thing we seemed to agree needed doing (allowing path() to be specified relative to the element's current position).

If we added the ability for path() to respond to offset-position, we have an issue - ray() pays attention to offset-position by default, but path *doesn't* pay attention by default. We need to resolve this somehow.

My proposal, then:

1. Add an `at <position>` argument to ray(), path(), and shape(), following circle()/ellipse().
 * For ray(), it sets the starting point of the ray. It defaults to `center` by default.
 * For path()/shape(), it sets the origin of the coordinate system (but does not affect the unit size; it's just a shift). It defaults to `left top` by default.
2. Add a new `none` value to offset-position, and make it the initial value. When `none`, it does nothing.
3. When non-none, offset-position is used as the default for any `at ...` positions in the offset-path functions. `auto`, as it does now, effectively gives you element-relative positioning. A `<position>` lets you provide a separately-cascaded/animated starting position.

Hopefully this minimizes the chance of breakage, since rays will default to coming from the center if the author didn't touch offset-position, identical to what is *probably* the common case today where the element is abspos'd with `left:50%; top:50%` and `offset-position:auto` is used by default. But it gives us a more consistent approach to positioning shapes in general, and gives some useful new functionality to path() and shape(). (Today you could only achieve that if you wrote your path entirely with relative coordinates; with the new functionality you can use absolute coords if that's easier to understand, and they'll all effectively shift for you.)

This requires an edit to Shapes 1 as well, so /cc @astearns .

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


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

Received on Tuesday, 7 March 2023 20:32:03 UTC