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

The CSS Working Group just discussed `[motion-1] offset-position + circle()`, and agreed to the following:

* `RESOLVED: Add "at <position>" to path(), shape(), and ray()`
* `RESOLVED: Add 'normal' keyword to 'offset-position'`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> s/Topic/Subtopic/<br>
&lt;fantasai> TabAtkins: About the interaction of offset-position and circle() etc.<br>
&lt;fantasai> TabAtkins: originally offset-position was replacement for left/top<br>
&lt;fantasai> TabAtkins: could use polar<br>
&lt;fantasai> TabAtkins: When we changed to transforms, it got weird<br>
&lt;fantasai> TabAtkins: After discussion years ago, we came to some moderate conclusions that we wanted offset-position to apply to the ray() function and path() and probably nothing else?<br>
&lt;fantasai> TabAtkins: benefit was offset-position has a way to say "use my current position" which seemed useful for thngs like SVG path, which are in global coordinate space<br>
&lt;fantasai> TabAtkins: starting a path from "right here" was useful<br>
&lt;fantasai> TabAtkins: that wasn't edited in<br>
&lt;fantasai> TabAtkins: it ended up affecting circle() and ellipse(), to set the center<br>
&lt;fantasai> TabAtkins: rather than defaulting to center like css-shapes<br>
&lt;fantasai> TabAtkins: My proposal is to pursue the original intent in the thread to allow path() to also be relative as well<br>
&lt;fantasai> TabAtkins: making things consistent, taking ray/path/shape and giving them all an "at &lt;position>" syntax that sets the starting point<br>
&lt;fantasai> TabAtkins: for path start at 0,0, for ray at center<br>
&lt;fantasai> TabAtkins: if you omit, will take value from offset-position<br>
&lt;fantasai> TabAtkins: paired with this, since we want shapes to default differently, we'd add a new 'none' value to offset-position<br>
&lt;fantasai> TabAtkins: so by default won't affect the default behavior<br>
&lt;fantasai> TabAtkins: if you do nothing special, your ray will come out of the center<br>
&lt;fantasai> TabAtkins: which is generally what people want?<br>
&lt;fantasai> TabAtkins: it keeps these two things consistent<br>
&lt;fantasai> TabAtkins: So 1) add "at &lt;position>" to all things<br>
&lt;fantasai> TabAtkins: 2) add 'none' value to offset-position to not affect shape functions<br>
&lt;fantasai> TabAtkins: 3) ???<br>
&lt;fantasai> TabAtkins: Other functions don't affect<br>
&lt;fantasai> TabAtkins: but for ray/path/circle/ellipse, seems to make sense<br>
&lt;fantasai> TabAtkins: Note this spec is very inconsistently written<br>
&lt;fantasai> TabAtkins: and very little interop<br>
&lt;fantasai> TabAtkins: part of reason why under interop 2023<br>
&lt;fantasai> TabAtkins: very hard to do anything consistently<br>
&lt;fantasai> TabAtkins: anything we do will break stuff<br>
&lt;fantasai> dbaron: I tried to use Motion Path to cause an element to maintain its own position, couldn't do it interoperably<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: I don't ahve the history of all this loaded up<br>
&lt;TabAtkins> fantasai: Not 100% sure I want to sign off because I'm not sure what we were trying to do.<br>
&lt;fantasai> TabAtkins: auto is the box's current position<br>
&lt;TabAtkins> fantasai: So you're proposing a none value, which uses the default position for each function<br>
&lt;dbaron> (the test I was working on was https://dbaron.org/css/test/2018/stacking-context-z-order )<br>
&lt;TabAtkins> fantasai: And what's the default value? still auto?<br>
&lt;fantasai> TabAtkins: no, it's none<br>
&lt;fantasai> TabAtkins: path starts at 0,0, but ray looks at offset-position<br>
&lt;fantasai> TabAtkins: if we default to auto, paths will change, if we default to none, rays will change<br>
&lt;fantasai> TabAtkins: for rays defaulting to center is almost always what you want<br>
&lt;fantasai> TabAtkins: so that's the core use case for ray()<br>
&lt;fantasai> TabAtkins: so I think that would be the most sensible behavior going forward<br>
&lt;fantasai> TabAtkins: and might be reasonably compatible with the content out there<br>
&lt;florian> fantasai: first comment if none is supposed to mean the default, then maybe it should be called normal instead<br>
&lt;florian> fantasai: currently, if you don't specify anything for path, it'll be auto<br>
&lt;florian> TabAtkins: path has no way to specify a position, so it goes by the containing block's origin<br>
&lt;florian> fantasai: and that's interoperable?<br>
&lt;florian> TabAtkins: probably, no change in spec in a long time<br>
&lt;florian> fantasai: for ray?<br>
&lt;florian> TabAtkins: it pays attention to offset position<br>
&lt;fantasai> TabAtkins: no way to set the position otherwise<br>
&lt;florian> fantasai: you want to make them consistent by making them start at a default value<br>
&lt;florian> fantasai: the alternative would be for both to start at the element's own position<br>
&lt;florian> TabAtkins: yes. I think the common case for path will not like that<br>
&lt;florian> TabAtkins: ray will want to center<br>
&lt;florian> TabAtkins: so usecases are probably better served by a default value than the element's own position<br>
&lt;florian> fantasai: not 100% sure…<br>
&lt;fantasai> PROPOSED: Add "at &lt;position>" to path(), shape(), and ray()<br>
&lt;fantasai> PROPOSED: Add 'normal' keyword to 'offset-position'<br>
&lt;florian> astearns: that matches what's already in circle and ellipse?<br>
&lt;florian> TabAtkins: yes<br>
&lt;florian> RESOLVED: Add "at &lt;position>" to path(), shape(), and ray()<br>
&lt;florian> astearns: any question on the second resolution?<br>
&lt;florian> RESOLVED: Add 'normal' keyword to 'offset-position'<br>
</details>


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


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

Received on Monday, 13 March 2023 14:24:32 UTC