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