W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2016

Re: [motion-1] On path syntax

From: Shane Stephens <shans@google.com>
Date: Thu, 18 Feb 2016 03:05:09 +0000
Message-ID: <CAGTfzwQek7XEghdh8QQVSHwsD=TH1bGjsA1BQ-Dh2oyTOODOPw@mail.gmail.com>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Alan Stearns <stearns@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
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
* -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.


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.
> 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
Received on Thursday, 18 February 2016 03:05:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 18 February 2016 03:05:50 UTC