[css-shapes] Overload `path()` for CSS-y SVG path syntax instead of taking up `shape()`

[LeaVerou]

Apparently WebKit is implementing shape() so this is somewhat urgent.

SVG paths don't have the best ergonomics, and there have been long discussions about how to improve on the ergonomics as well, not just expose the existing model with CSS syntax. See #9889 for one discussion on this

Can we perhaps overload path() for the API that is mapped closely to SVG paths so that shape() is free to host something better without having to worry about disambiguation?

The current signature of path() is very weird anyway, so it would be good to make it sensible.

[smfr]

Do you thoughts for what a future shape() might be used for?

I think we'll be able to map SVG paths to the new shape syntax losslessly, but will not be able to map in the other direction.

[css-meeting-bot]

The CSS Working Group just discussed [css-shapes] Overload `path()` for CSS-y SVG path syntax instead of taking up `shape()` .

The full IRC log of that discussion

<dbaron> lea: As mentioned many times, SVG paths don't have the best ergonomics.
<dbaron> lea: Have been long discussions about improving.
<dbaron> lea: And not just expose the exsiting model with CSS syntax. Though there's value in exposing existing model in CSS syntax.
<TabAtkins> q+
<dbaron> lea: Seems like we're trying to do both with shape() function.
<dbaron> lea: But we already have a path() function which has a very strange syntax for CSS.
<dbaron> lea: It seems reasonable to me that we should overload that function to harmonize with rest of CSS functions
<dbaron> lea: That frees up shape() to do what we want, we don't have to be consistent with SVG.
<dbaron> lea: We don't have to be consistent with SVG at all without being bound by legacy/baggage of SVG.
<dbaron> lea: Seems like it's 2 birdds with one stone. Make path() a reasonable function and free up shape() to do something more reasonable without baggage().
<dbaron> lea: Lea is that path() is CSS specification of SVG paths whose model stays close to SVG aths, and shape() can be whatever.
<dbaron> TabAtkins: I don't agree with this.
<dbaron> TabAtkins: I don't think we need to do more reinvention while keeping close to SVG.
<dbaron> TabAtkins: I don't think the SVG starting point is particularly holding us back.
<dbaron> TabAtkins: what SVG does is mostly fine.
<lea> q?
<noamr> q+
<lea> q+
<dbaron> TabAtkins: We can engineer around the awkward bits. curve sucks but we can do better curvens.
<Rossen9> ack TabAtkins
<dbaron> TabAtkins: I don't think we're limited in a meaningful way.
<dbaron> TabAtkins: I don't like when functions have significantly divergent grammar paths.
<dbaron> TabAtkins: It's clearer when path() is the SVG syntax and shape() is the CSS nytax, more teachable.
<dbaron> TabAtkins: I like the current approach and think we shouldn't change.
<Rossen9> ack noamr
<dbaron> noamr: I t hink most useful thing about path() is that you can paste in strings from an SVG authoring tool.
<dbaron> noamr: It's a feature that can stay the way it is
<dbaron> noamr: Let sleeping dogs lie.
<Rossen9> ack lea
<dbaron> lea: I'm not proposing we drop the string argument of path(), just overload it.
<dbaron> lea: If you don't think the current shape() is a sigificant departure from SVG, then maybe we should just stick with path().
<dbaron> lea: All the other SVG shapes have CSS functions, path() is the odd one out that only takes a string.
<dbaron> lea: We should fix path to have a better design. Then question of if we need a new function. But I think we do -- fix how we specify control points, how we ??, fix arcs.
<dbaron> lea: We've discussing many improvements, many of which we can't backport.
<dbaron> TabAtkins: 2 things to repsond to -- all other SVG shapes are just elemnts with attributes, there's no data format to port over to CSS.
<dbaron> TabAtkins: path is the execption where the data are in a string
<dbaron> lea: polygon!
<dbaron> TabAtkins: Aside from the whitespace rules it's identical to CSS grammar.
<dbaron> TabAtkins: path() has nontrivial syntax that can be dropped into other contexts. Taking that is still useful.
<lea> q?
<lea> q+
<dbaron> TabAtkins: but also useful to take advantage of CSS and its gfull abilities.
<dbaron> TabAtkins: Second, I don't understand how points about gradually making shape better than what SVG can do suggest putting it into path(). If anyhting, I think shows separate function is better to underline that it's different.
<Rossen9> ack lea
<dbaron> lea: That's not what I was suggesting. If was saying that if we're significantly different it should be a separate function, but there's still value in a CSS serialization of path.
<dbaron> lea: I think you could do a CSS-if-ication of path syntax and allow that in path().
<dbaron> lea: Having to reach for a different function that has nothing to do with paths makes it difficult to learn.
<dbaron> TabAtkins: I don't see great value to users in a direct cssification of the path syntax.
<dbaron> TabAtkins: if people are using path syntax, they want to ureuse it, just take te string and go.
<dbaron> TabAtkins: If they're rewriting then rewriting into shape syntax which gives substantially more ???.
<dbaron> lea: I don't think it should be mapped that closely, but I'd take thit af itis' the only way.
<dbaron> lea: ???
<dbaron> lea: Taking a path from SVG and sticking it into CSS has limited utility because SVG paths are fixed sizes... current path odesn't deal with percentages, units.
<dbaron> TabAtkins: it's well defined
<dbaron> lea: It's well defined but not useful.
<dbaron> TabAtkins: are you asking to drop path() entirely?
<dbaron> lea: no
<dbaron> lea: I'm saying what either what we have now in shape() in which case it should be in the path() function, or it's far enough and we should improve the path() function and have the shape() function separately.
<dbaron> TabAtkins: I agree with second point except I don't think there's value with improving path syntax and I think we should stick with current approach.
<dbaron> Rossen9: I think we should take this back to the issue. Two contrasting opinions here.
<noamr> I think this proposal should be a bit more specific
<dbaron> Rossen9: Sounds like we should get closer together on the issue before trying to resolve.

[ydaniv]

I think it's good that path() and <path> are interchangeable. If anything, I'd prefer that in the future we would get a <shape> in SVG (setting aside how realistic that is for now).

[jyasskin]

I don't know anything about the need to improve the shape language in the future, but I'm concerned about the sentence in the spec that "The shape() function defines a path". shape() should define a shape, and path() should define a path.

These naming issues are sometimes inevitable, but it seems like this one isn't.

[noamr]

I don't know anything about the need to improve the shape language in the future, but I'm concerned about the sentence in the spec that "The shape() function defines a path". shape() should define a shape, and path() should define a path.

Sure, we can change the wording.

[noamr]

#9889 is closed and we have no specific proposals being discussed around doing something different with path(). We've implemented shape() in chromium as well and almost ready to ship. @LeaVerou do you still want to pursue this? If not, can we close this issue?

[LeaVerou]

Well, I still think path() only supporting a <string> argument is inconsistent with all other shape functions, so no, I'm not in favor of closing this with no WG resolution.