[css-shapes-2] The new definition of '<basic-shape>' should include 'path()'

[BorisChiou]

The definition of <basic-shape> for shape-inside in [css-shapes-2] doesn't include path() now. We define path() as a delta of supported basic shapes in [css-shapes-2], and it seems no other places mention it.
IIRC, at least four properties use <basic-shape>:

1. shape-outside: The link of <basic-shape> in its value definition links to the definition of <basic-shape> in [css-shapes]
2. shape-inside: The link of <basic-shape> in its value definition links to its own definition of <basic-shape> in [css-shapes-2].
3. clip-path: The same as that of shape-inside.
4. offset-path: The same as clip-path and shape-inside. However, it also defines a different syntax of path() because fill-rule doesn't make sense on offset-path.

IMO, the link of the value definition of <basic-shape> for shape-outside, shape-inside, and clip-path should link to the same place, and it'd be better to mention path() together, to avoid confusing people. Or make all four links of <basic-shape> in the value definitions of these properties link to the same place, but add a note for offset-path which doesn't use the syntax of path() defined in [css-shapes-2].

Thanks.

[ewilligers]

I would be ideal if these properties and d all used the same path function. I would like to be able to animate a number of these properties through one custom property animation - w3c/css-houdini-drafts#820 .

Among the options are

1. Simply noting in the definition that fill-rule is not permitted in d and offset-path

2. an explicit fill-rule in d overrides the fill-rule property for that path

3. fill-rule is not permitted in d, and has no effect in offset-path

4. fill-rule has no effect in d and offset-path, and is omitted during their serialization.

[BorisChiou]

Sounds great. Linking these properties and d to the same path() function and adding some restrictions or notes for some properties make sense.

[dirkschulze]

@ewilligers IMO we should discuss path() for d attribute/property independent of the decision to back port path() to basic-shapes-1. Right now, <basic-shape>s are only used by the CSS properties shape-outside (shape-inside level 2), clip-path and offset-path.

[css-meeting-bot]

The CSS Working Group just discussed Define path() in Shapes 1 or 2, and agreed to the following:

• RESOLVED: Move path() down to Shapes 1, adding it to <basic-shape>.

The full IRC log of that discussion

<TabAtkins> Topic: Define path() in Shapes 1 or 2
<TabAtkins> astearns: A number of specs are using <basic-shape>, which has several functions in Shapes 1, but not path().
<TabAtkins> astearns: But path() is being implemented for *some* of the <basic-shape> properties.
<TabAtkins> astearns: It's weird to have them linking to a definition in Shapes 2 that's just a diff.
<TabAtkins> astearns: One option is to flesh out Shapes 2 into an actual spec, with a proper definition for <basic-shape> including path()
<TabAtkins> astearns: Another option is to pull path() back into Shapes 1, which implies we should implement it for shape-outside
<TabAtkins> astearns: I don't much care which one we do.
<TabAtkins> astearns: But would like to resolve on which way to o.
<TabAtkins> TabAtkins: My preference is whatever gets all the props using the same set of shape functions; all the props use a different subset right now and it's terrible.
<TabAtkins> TabAtkins: Spec's easy, I'm fine with it in level 1.
<TabAtkins> astearns: I think Ian said it woudln't be trivial, but seems plausible to do.
<TabAtkins> eae: Yes.
<TabAtkins> s/it/doing path() in shape-outside/
<TabAtkins> astearns: So I propose adding path() to Shapes 1. There's other things that need to be done in the spec, we can get a draft out that everyone can refer to with all the functions.
<TabAtkins> astearns: Can deal with how that slows down Shapes 1 from PR as we find impls to try it out.
<TabAtkins> astearns: Objections?
<AmeliaBR> The problem with adding path() to shapes 1 is that, as currently defined, it can't be used everywhere a shape is. It only defines the outline, not the fill area.
<TabAtkins> heycam: Any objection to shipping path() in things like offset-path - do they need to ship together?
<TabAtkins> TabAtkins: [reads Amelia's IRC comment]
<TabAtkins> astearns: Yeah that's a bit of th eproblem, some properties don't need fill-rule at all.
<TabAtkins> astearns: So I'm imagining it's an optional param to the function. But I haven't thought about how it's specified yet.
<TabAtkins> heycam: Would that block Motion Path?
<TabAtkins> astearns: My proposal is just to put it in Shapes 1. It shoudl improve the Process situation for Motion Path; it can then refer to a CR-level spec instead of a FPWD diff spec.
<AmeliaBR> Motion path would just ignore the fill rule. But for the SVG `d` property, allowing fill-rule in the path() function is possibly confusing, since there's a separate fill-rule property that applies.
<TabAtkins> astearns: This is really all about Process.
<TabAtkins> astearns: Tab, you mentioned Chris Coyier's annoyance with the shapes being different everywhere.
<TabAtkins> astearns: There's the path attribute in SVG; it's possible we won't get all the way to SVG syntax in CSS.
<TabAtkins> [discussion about CSS tokenization not being compatible with SVG]
<TabAtkins> myles: Does that mean you can't build up paths from varia les?
<TabAtkins> TabAtkins: Not without defining a new syntax that's CSS compatible.
<TabAtkins> AmeliaBR: Or doing the string-concat function.
<TabAtkins> myles: Didn't we resolve to add that?
<TabAtkins> AmeliaBR: Yeah, but no one's written it yet.
<TabAtkins> AmeliaBR: wrt it being a Process issue; if we want to put path() in Shapes 1, we have to figure out these issues before Shapes 1 can move forward in the process.
<TabAtkins> AmeliaBR: I'm not sure who's responsible for Shapes's progress, I think Alan; at this point is it best ot clean up and stabilize, or are we fine to take on this new work? Becaus eit's also abuot impls.
<TabAtkins> astearns: I think my strat will be to add it to the spec as an at-risk feature, so that we can punt it if we need to move Shapes 1 forward, but I'm perfectly happy with it sitting at CR for a while, or even going back ot WD if there are enough changes.
<TabAtkins> astearns: I'm not that concerned with getting it to Rec real quick.
<TabAtkins> AmeliaBR: Does adding path() mean we have to cycle back to WD, as a significant new feature?
<TabAtkins> florian: Nah it's fine.
<TabAtkins> florian: Patent Policy will handle it fine; as long as you've got wide review and what not is fine.
<TabAtkins> AmeliaBR: It's been reviewed in Motion Path, but review there...
<TabAtkins> florian: The easier it is to demonstrate review, the easier time you'll have.
<TabAtkins> astearns: And if we have to bounce to WD, that's fine.
<TabAtkins> AmeliaBR: So long term, is our goal that shapes should be shapes, and you should be able to specify motion-path with circle(), etc?
<TabAtkins> TabAtkins: Yeah, a circle is a path, whatever.
<TabAtkins> astearns: So any objection to adding path() to Shapes 1?
<TabAtkins> RESOLVED: Move path() down to Shapes 1, adding it to <basic-shape>.
<TabAtkins> krit: I missed - are impls willing to support path() in shape-outside?
<TabAtkins> astearns: Missing a few people that would answer that.
<TabAtkins> TabAtkins: Ian says it's non-trivial, but doable.
<TabAtkins> astearns: So yeah that might slow us down, but getting things consistent and well-explained is more useful than a quick Rec for Shapes.
<TabAtkins> krit: Would it be good to add a note about precision in paths? A very complex path might get transformed to a polygon, maybe have a lot of points, etc. So can we add a note that impls can decide on how precise it wants to be?
<TabAtkins> astearns: I don't know if we currently have text to that effect with polygons...
<TabAtkins> s/astearns/AmeliaBR/
<TabAtkins> astearns: We do have text for some degenerate/difficult situations, saying you do have to do the difficult stuff.
<TabAtkins> astearns: I'm not sure we need to define that; precision's going to be an impl detail. Tests will have to be fairly coarse anyway to avoid being flaky.
<TabAtkins> astearns: So I think it's just a QoI detail they can live with.
<TabAtkins> krit: So if we agree it's just QoI, it's probably fine.
<TabAtkins> AmeliaBR: There's already a lot of flexibility for, say, *drawing* SVG paths.
<TabAtkins> krit: Ok.
<astearns> github: https://github.com//issues/4270

[astearns]

I've moved the definition of path() back to shapes level 1 with a2e5fe5

I added some text about implicitly closing an open path for shape-outside and clip-path. I assume that's not desired for offset-path