Re: [motion-1] On path syntax

Logically, I like the idea of moving the fill-rule/clip-rule outside of the
shape function. It keeps separate concepts separate, and provides
flexibility to use shape functions in different contexts.

However, *polygon() with fill-rule is already shipping* in multiple
implementations for clip-path (and also shape-outside, though it has no
effect in that case).

Shapes for clip-path have been working in Chrome (& WebKit?) with prefixes
for over a year (based on the date when I posted this demo [1]), and have
just recently shipped, without prefixes, in Firefox Nightly.

So if there is a desire to make a change, it needs to be made soon, before
these properties are available, unprefixed, in stable builds.  And that
means pulling CSS Shapes 1 back from candidate recommendation status to
change the function definition [2], and pulling CSS Masking 1, also a CR
spec, to add the new clip-rule parameter to `clip-path` [3].

If the rest of you want to champion these changes with the relevant spec
editors, implementers, and the dev community, I will happily help get the
word out.  But it has to happen fast and furious, with clear justification
for the change, or you'll have a lot of eager developers annoyed by broken
content.

[1]: http://codepen.io/AmeliaBR/pen/GgWBOy?editors=0100
[2]: https://www.w3.org/TR/css-shapes/#funcdef-polygon
[3]: https://www.w3.org/TR/css-masking/#the-clip-path

On 17 February 2016 at 10:52, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Feb 16, 2016 at 6:25 PM, Alan Stearns <stearns@adobe.com> wrote:
> > On 2/16/16, 1:56 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> >>After some discussion with Shane, we have a new proposal:
> >>
> >>1. Drop fill-rule from path() and polygon().  This keeps all the shape
> >>functions as just specifying the path geometry, so they're usable
> >>everywhere without confusion.
> >>2. In properties that need to know the shape's fill, just accompany
> >>those functions with an optional fill-rule in the property grammar,
> >>like "even-odd path(...)".  This allows just the specific instances
> >>that require fill information to receive it.
> >>
> >>This avoids all the confusing situations.  We don't have the potential
> >>of useless fill-rules in motion-path, and we don't have confusing
> >>conflicts between the path() specified fill-rule and the 'fill-rule'
> >>specified one in <path> elements.  You still get to supply the
> >>fill-rule in the situations where it's relevant, like shape-inside.
> >>
> >>I think this should have minimal or zero compat impact?
> >
> > I’d be OK with this change (if the compat impact is minimal). It’s
> certainly better than having two functions for each that only differed in
> whether they accepted a fill-rule parameter.
> >
> > I’d also be OK with leaving fill-rule in the functions, even for
> properties that ignore it. I don’t find it that confusing or
> author-hostile. An optional parameter seems like a good fit to me for a
> sometimes-relevant value.
>
> Yeah, as Shane elaborates, this is author-hostile.  We have three
> contexts for paths:
>
> 1. Using the path as a path (fill-rule is meaningless).
> 2. Using the path as a shape (fill-rule is necessary).
> 3. Using the path as a shape, but fill-rule is specified elsewhere.
>
> In #1, allowing fill-rule in the function is confusing.  In #3, it's
> *really* confusing.  Only in #2 is it useful and non-confusing.
>
> ~TJ
>