Re: [motion-1] On path syntax

On Wed, Feb 17, 2016 at 1: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.
>

In this world, what would the effect of this be?

.my-path {
  d: path(evenodd, '.....');
}

Or this?

.my-path {
  d: path(nonzero, '.....');
  fill-rule: evenodd;
}

What I was getting at by 'author hostile' is that we probably have to
explicitly ignore a value that is relevant and was specified by the user,
due to there being a separate property available to specify that value.

Tab pointed out to me that there is an alternative, though it's also not
wonderful - we can make the computed value of fill-rule depend on the
computed value of d (and define fill-rule to take precedence if the value
isn't auto). I'd be mildly opposed to this on implementation grounds though
(the existing list of property dependencies is a major wart on at least our
style engine implementation, and adding to that list is not something we
particularly want to do).

Cheers,
    -Shane


> Thanks,
>
> Alan
>
>