On Wed, Feb 17, 2016 at 1:25 PM Alan Stearns <[email protected]> wrote:
> On 2/16/16, 1:56 PM, "Tab Atkins Jr." <[email protected]> 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 > >
