- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Mar 2023 23:50:59 +0000
- To: public-css-archive@w3.org
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-shapes-1] Define equivalent paths == [Shapes 1](https://drafts.csswg.org/css-shapes-1/#supported-basic-shapes) currently defines all the shapes functions as, well, shapes, which is pretty reasonable for what it was designed for. Over time we've expanded on these functions and their use-cases; notably, we added path() and shape() (declaring that they auto-close to form a closed shape if necessary), but also referenced the functions in places that want to use them *as a path*, like in ['offset-path'](https://drafts.fxtf.org/motion-1/#offset-path-property). When used as a path, rather than as a shape, we need to define what exactly the path is - where it starts, and how it continues. Currently 'offset-path' does that explicitly (for the set of shape functions it knew about; it's missing a few newer ones), but (a) it seems better to define this alongside the shapes, so lists can't get out-of-date, and (b) I expect that any other uses of shape-as-path would want to use the same definitions. All the starting-point definitions in offset-path make sense to me; should we move those to the function definitions in Shapes? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8524 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 March 2023 23:51:01 UTC