Re: [motion-1] On path syntax

The -webkit- version frankly doesn't matter. It can continue to support
legacy syntax - vendors explicitly accept the risk of specifications
changing when they ship prefixed implementations. I suspect we will simply
deprecate and remove the -webkit- syntax, though (not sure about Safari).

In terms of usage of the -webkit- prefixed and unprefixed versions of
clip-path:
* -webkit-clip-path has a shade over 1% usage
* clip-path has about 0.1% usage
(numbers from chromestatus.com)

This tells us two things:
(1) authors are not generally practicing "future-friendly" syntax.
(2) factoring in the putative percentage of cases where this actually
matters (self-intersecting polygons specified in -webkit-clip-path) I'm
confident suggesting that usage is very tiny indeed - almost all clip paths
I've seen in the wild have been simple convex hulls. Note that Chrome can
continue to parse, but ignore, fill rules inside polygon() functions
specified on -webkit-clip-path if we feel that not doing so would be a
breaking change.

All this means we basically have zero genuine shipping implementations, so
we're fine.

Cheers,
    -Shane

On Thu, Feb 18, 2016 at 1:26 PM Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> Sorry, one quick clarification: the new Firefox Nightly implementation of
> clip-path and CSS shapes is still behind a flag. So not* quite* as close
> to being in a stable build as I thought. Should have tested.
>
> The -webkit- version is out in the wild, though, and content that was
> developed in a "future-friendly" manner with unprefixed properties to match
> will not be so friendly if the future syntax is changed.
>
> ABR
>
>
> On 17 February 2016 at 19:13, Amelia Bellamy-Royds <
> amelia.bellamy.royds@gmail.com> wrote:
>
>> 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
>>
>>