search

w3c / fxtf-drafts

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

[motion-1] What should we do for <fill-rule> in path() function #512

Closed BorisChiou closed 1 year ago

BorisChiou commented 1 year ago

Per the current spec, the definition of offset-path is none | <offset-path> || <coord-box>. And <offset-path> could be <ray>, <url>, <basic-shape>.

The syntax of path() in <basic-shape> is path([<fill-rule>]? [<string>]). <fill-rule> is useful only for clip-path and shape-outside.

For motion, we didn't have <fill-rule> in the spec before (at least when I worked on this 4 years ago). However, now we use <basic-shape> to include all kinds of shapes. So perhaps it's worth to note that <fill-rule> is ignored and we don't have to serialize it even if the users specify it? Or should we still serialize it if it is not the default value?

SebastianZ commented 1 year ago

This was previously mentioned by @cdoublev in https://github.com/w3c/csswg-drafts/issues/7390#issuecomment-1357175930 and later again in https://github.com/w3c/fxtf-drafts/issues/493#issuecomment-1447613235. It was also mentioned there that this applies to polygon(), as well.

I'd say, if web compatible, the syntaxes for path() and polygon() should be adjusted for offset-path to exclude <fill-rule> entirely. As it doesn't have any effect there, the chances are high that its usage is small enough in that context to be removed.

I think there was also a discussion somewhere to split path shapes completely from filled shapes. Though I can't find it at the moment.

Sebastian

tabatkins commented 1 year ago

I'd rather not split the grammar purely for this purpose. The keyword is only relevant for the functions when interpreted as shapes, not as paths; I think it's fine to just ignore it when you're using them as a path.

I'm fine with specifying that it's ignored (and thus will be omitted from serialization per shortest-serialization principle).

BorisChiou commented 1 year ago

Thanks. I'd let Gecko ignore the fill-rule at the parse time and serialization.

(Note: deleted my previous comment because it seems I misread the context.)

Updated: and also ignore it when doing interpolation.

BorisChiou commented 1 year ago

I noticed there is a spec issue related to this one as well: https://github.com/w3c/csswg-drafts/issues/3468. So I'd like to close this one because it's clear to me to ignore fill-rule for outline shape, e.g. offset-path.