On Tue, Feb 16, 2016 at 6: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.
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. ~TJ
