Re: [motion-1] On path syntax

I don't think there is a conflict. There are other cases in CSS where a
functional notation encompasses multiple values that would otherwise be set
in separate properties.  For example, the filter() function which combines
an image value with a filter operation to create a filtered background (or
other) image.

In other words, the `d` property of an SVG <path> element wouldn't use the
full `path([fill-rule]?, path-string)` function, it would just use the
path-string.  The fill of the shape would still be determined by the
separate fill-rule property.

Having a fill-rule control within the path function is essential for the
path function to be used in the clip-path property.

So there are two reference specifications:

- The definition of what makes a valid path string. I think this should
continue to be defined in SVG for now, but in future would likely be
separated out into its own module that could be referenced by SVG, CSS, and
Canvas 2D Context specs.

- The definition of the path() CSS function, which references the path
string definition but builds upon it to create a complete CSS shapes
definition. This natural place for this is CSS Shapes, though it could be
introduced in which ever spec needs it that gets to CR first.

~Amelia

On 3 February 2016 at 15:17, Shane Stephens <shans@google.com> wrote:

> Hi list,
>
> Cameron pointed out today that the path() function in motion-1 takes a
> fill rule. It looks like dschulze added this late in 2014 so that other
> specifications (some of which need a fill rule) could reference the path
> syntax too.
>
> Cameron pointed this out because he wanted to reference this specification
> for the property version of the 'd' attribute, but having a fill rule there
> is awkward because <path> elements also accept fill-rule properties.
>
> Additionally, fill-rule has absolutely no effect on motion, so it doesn't
> really make sense to accept one in the motion spec.
>
> My suggestion is this:
> (1) remove fill-rule from motion-1
> (2) for now, each specification should separately reference SVG1.1 when
> defining a path syntax.
> (3) we should get two variants of path included in the next level of
> values and units, one with and one without fill-rule
> (4) gradually we can switch specifications across to reference these.
>
> Thoughts?
>
> Cheers,
>     -Shane
>