Re: [motion-1] On path syntax

On Tue, Feb 16, 2016 at 6:25 PM, Alan Stearns <> wrote:
> On 2/16/16, 1:56 PM, "Tab Atkins Jr." <> 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.


Received on Wednesday, 17 February 2016 17:52:57 UTC