Re: [motion-1] On path syntax

Hi Amelia,

It's confusing for CSS that configures path syntax to reference a fill-rule
in the 'd' property that will never be used, *while at the same time*
allowing a fill-rule property. This isn't a conflict per se, I guess? But
it is definitely author-hostile.

A simple fix is to introduce two variants of the path function, which is
what I had proposed. If we're doing this anyway, then each specification
should reference the most appropriate variant. As fill-rule is unused for
motion-path, it should reference the variant without a fill rule.

I'm agnostic as to whether the path() functions belong in values and units
or in shapes, and would like to defer to the CSSWG here.

Sincerely,
    -Shane Stephens

On Thu, Feb 4, 2016 at 9:32 AM Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> 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
>>
>
>