Re: [motion-1] On path syntax

That all sounds like a good argument that the impact will be small.  (I
certainly know I had to really work to come up with a good demo of the
fill-rule effects!)

I'd still suggest getting the ball rolling sooner rather than later.
Probably starting with a dedicated thread that includes the [css-masking]
and [css-shapes] tags, so anyone else with strong opinions can join in.

I would say, though: if CSS Shapes and CSS Masking will need to be modified
from their current CR versions to make the change for polygon(), it would
be nice to also include the path() function at the same time, so they are
all defined in the same place.

~ABR



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

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