search

w3c / fxtf-drafts

Mirror of https://hg.fxtf.org/drafts
https://drafts.fxtf.org/
Other
68 stars 49 forks source link

[motion-1] Initial position of a path() #505

Open tabatkins opened 1 year ago

tabatkins commented 1 year ago

Currently, 'offset-path' defines that the "initial position" of a path() function is given by the first move-to in the path().

This makes complete sense to me when there is an initial move-to in the path string. But this is pretty limiting; you can't use any of the CSS units or percentages there.

Do we want to distinguish between a path that has an explicitly given initial move-to, and let ones without such a move-to use the 'offset-position' as their initial position? Or should we just let shape() cover this use-case instead, since it can specify its initial move-to using CSS units?

tabatkins commented 1 year ago

I have a proposal to fix this in https://github.com/w3c/fxtf-drafts/issues/504#issuecomment-1458831844

BorisChiou commented 11 months ago

Letting shape() cover this use-case is also OK to me, so we don't have to change anything to path() (e.g. add at <position> to its syntax).

Note that shape() always has the starting point (i.e, initial position), per its current spec.

Do we want to distinguish between a path that has an explicitly given initial move-to, and let ones without such a move-to use the 'offset-position' as their initial position?

Per SVG1 (https://www.w3.org/TR/SVG11/paths.html#PathDataBNF), and SVG2 (https://www.w3.org/TR/SVG/paths.html#PathDataBNF), it seems the syntax of svg path should always have the initial move_to command (if it's not an empty string).

So I expect path() should always specify the initial position, by the initial move_to command. That means it should be fine to let path() just ignore offset-position because the initial position should always be there, per its syntax. (This may be the same as url() because I expect the SVG geometry elements always provide the initial position.)