Re: [csswg-drafts] [css-shapes][motion][svg] CSS shapes functions with/without fill-rule parameters (#3468)

The CSS Working Group just discussed `Motion - Final approach for shapes`, and agreed to the following:

* `RESOLVED: make an optional keyword with just the two values, and default to even-odd or "lookup depending on context"`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Motion - Final approach for shapes<br>
&lt;myles> ScribeNick: myles<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/3468<br>
&lt;myles> AmeliaBR: for the various properties that use shape(), some only care about the outline of the shape. Others care about the actual fill area of the shape<br>
&lt;myles> AmeliaBR: So for motion-path, you only care about the outline, but for clip-path, you care about which parts are inside and outside. This is an issue when you have polygons or paths with cris-crossing lines and inside/outside isn't so clear<br>
&lt;myles> AmeliaBR: Enter fill-rule. even-odd and nonzero.<br>
&lt;myles> AmeliaBR: It was originally defined as polygon(keyword, ...)<br>
&lt;myles> AmeliaBR: path() was defined in motion-path, and didn't include the keyword<br>
&lt;myles> AmeliaBR: Things get complicated with &lt;path> because this had 2 separate properties for the fill rule. Filling vs what's the effect when it's in a clip-path.<br>
&lt;myles> AmeliaBR: How do we deal with this conflict between having a keyword as part of the shape function vs having a separate property which doesn't make sense for &lt;clipPath><br>
&lt;myles> AmeliaBR: I came up with a couple options. The one that seemed to have people most support is that the keyword within the shape function includes "auto" as the default, and the default would look up the other SVG properties. But if you set the value otherwise, it would override the old SVG properties and we maybe eventually deprecate the SVG properties.<br>
&lt;myles> AmeliaBR: If you specify a fill-rule keyword in motion-path, it's ignored, but that's not a problem. The only place where it's a problem with &lt;shape> where it gets filled. We're specifying where if you set a fill rule in the function, it overrules the fill-rule property.<br>
&lt;myles> AmeliaBR: The default behavior is defined in all other cases to match the current behavior.<br>
&lt;myles> heycam: I like that. I'm not sure we need an explicit "auto" as opposed to just its absence.<br>
&lt;myles> TabAtkins: We do, for ... some case. There is a case related to &lt;path><br>
&lt;myles> TabAtkins: If path() takes a keyword, where the winding rule is determined by context, you need to be able to say "go grab from the other property explicitly"<br>
&lt;fantasai> +1 to heycam<br>
&lt;myles> heycam: This is a component of one value, and it's optional, can we just use its optionality?<br>
&lt;myles> AmeliaBR: So the auto behavior is the "no keyword specified" behavior<br>
&lt;myles> TabAtkins: That would work. It just runs into my dislike of having omitted values being unwritable<br>
&lt;myles> heycam: There are a lot of properties that have optional keywords<br>
&lt;astearns> q?<br>
&lt;myles> fantasai: &lt;lists them><br>
&lt;myles> TabAtkins: I get touchy<br>
&lt;myles> TabAtkins: I won't fight it<br>
&lt;TabAtkins> s/touchy/tetchy/<br>
&lt;fantasai> s/I get/Most of them are booleans, but when more than one value<br>
&lt;myles> AmeliaBR: The benefit of heycam's approach is that shipping for shapes in clip-path and shape-outside, we don't need to change anything, because the change would only come in paths where the author behavior is different from the current default behavior<br>
&lt;myles> heycam: Are their other elements other than &lt;path> where we might want to have a default value that's not "go and look at the fill-rule property"?<br>
&lt;myles> AmeliaBR: All the other cases the default value will be to just use one of the existing keywords.<br>
&lt;myles> TabAtkins: even-odd is the default<br>
&lt;myles> heycam: There's no value in adding an explicit auto keyword to say "look at the fill-rule property" for these other cases?<br>
&lt;myles> TabAtkins: Those other cases don't have a property.<br>
&lt;myles> AmeliaBR: It wouldn't make sense to have a div with both a clip-path and a shape-outside and also set a fill-rule in another property. That would be confusing<br>
&lt;myles> TabAtkins: There's only the two things that have the information defined by another property, and there isn't a use case to have arbitrary things rely on those two, it's just due to SVG's existing behavior to rely on those two<br>
&lt;myles> TabAtkins: and that's it.<br>
&lt;myles> astearns: The proposed resolution is to make this an optional keyword with just the two values, and default to even-odd or "lookup depending on context"<br>
&lt;myles> AmeliaBR: Withing the context of d= then not specifying the keyword would the the SVG legacy beahvior. Specifying the keyword behavior would mean "ignore the fill-rule and clip-rule properties"<br>
&lt;myles> astearns: Any objections?<br>
&lt;myles> RESOLVED: make an optional keyword with just the two values, and default to even-odd or "lookup depending on context"<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3468#issuecomment-577783297 using your GitHub account

Received on Thursday, 23 January 2020 17:23:42 UTC