- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 17:34:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-shapes] Overload `path()` for CSS-y SVG path syntax instead of taking up `shape()` ``. <details><summary>The full IRC log of that discussion</summary> <dbaron> lea: As mentioned many times, SVG paths don't have the best ergonomics.<br> <dbaron> lea: Have been long discussions about improving.<br> <dbaron> lea: And not just expose the exsiting model with CSS syntax. Though there's value in exposing existing model in CSS syntax.<br> <TabAtkins> q+<br> <dbaron> lea: Seems like we're trying to do both with shape() function.<br> <dbaron> lea: But we already have a path() function which has a very strange syntax for CSS.<br> <dbaron> lea: It seems reasonable to me that we should overload that function to harmonize with rest of CSS functions<br> <dbaron> lea: That frees up shape() to do what we want, we don't have to be consistent with SVG.<br> <dbaron> lea: We don't have to be consistent with SVG at all without being bound by legacy/baggage of SVG.<br> <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().<br> <dbaron> lea: Lea is that path() is CSS specification of SVG paths whose model stays close to SVG aths, and shape() can be whatever.<br> <dbaron> TabAtkins: I don't agree with this.<br> <dbaron> TabAtkins: I don't think we need to do more reinvention while keeping close to SVG.<br> <dbaron> TabAtkins: I don't think the SVG starting point is particularly holding us back.<br> <dbaron> TabAtkins: what SVG does is mostly fine.<br> <lea> q?<br> <noamr> q+<br> <lea> q+<br> <dbaron> TabAtkins: We can engineer around the awkward bits. curve sucks but we can do better curvens.<br> <Rossen9> ack TabAtkins<br> <dbaron> TabAtkins: I don't think we're limited in a meaningful way.<br> <dbaron> TabAtkins: I don't like when functions have significantly divergent grammar paths.<br> <dbaron> TabAtkins: It's clearer when path() is the SVG syntax and shape() is the CSS nytax, more teachable.<br> <dbaron> TabAtkins: I like the current approach and think we shouldn't change.<br> <Rossen9> ack noamr<br> <dbaron> noamr: I t hink most useful thing about path() is that you can paste in strings from an SVG authoring tool.<br> <dbaron> noamr: It's a feature that can stay the way it is<br> <dbaron> noamr: Let sleeping dogs lie.<br> <Rossen9> ack lea<br> <dbaron> lea: I'm not proposing we drop the string argument of path(), just overload it.<br> <dbaron> lea: If you don't think the current shape() is a sigificant departure from SVG, then maybe we should just stick with path().<br> <dbaron> lea: All the other SVG shapes have CSS functions, path() is the odd one out that only takes a string.<br> <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.<br> <dbaron> lea: We've discussing many improvements, many of which we can't backport.<br> <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.<br> <dbaron> TabAtkins: path is the execption where the data are in a string<br> <dbaron> lea: polygon!<br> <dbaron> TabAtkins: Aside from the whitespace rules it's identical to CSS grammar.<br> <dbaron> TabAtkins: path() has nontrivial syntax that can be dropped into other contexts. Taking that is still useful.<br> <lea> q?<br> <lea> q+<br> <dbaron> TabAtkins: but also useful to take advantage of CSS and its gfull abilities.<br> <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.<br> <Rossen9> ack lea<br> <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.<br> <dbaron> lea: I think you could do a CSS-if-ication of path syntax and allow that in path().<br> <dbaron> lea: Having to reach for a different function that has nothing to do with paths makes it difficult to learn.<br> <dbaron> TabAtkins: I don't see great value to users in a direct cssification of the path syntax.<br> <dbaron> TabAtkins: if people are using path syntax, they want to ureuse it, just take te string and go.<br> <dbaron> TabAtkins: If they're rewriting then rewriting into shape syntax which gives substantially more ???.<br> <dbaron> lea: I don't think it should be mapped that closely, but I'd take thit af itis' the only way.<br> <dbaron> lea: ???<br> <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.<br> <dbaron> TabAtkins: it's well defined<br> <dbaron> lea: It's well defined but not useful.<br> <dbaron> TabAtkins: are you asking to drop path() entirely?<br> <dbaron> lea: no<br> <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.<br> <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.<br> <dbaron> Rossen9: I think we should take this back to the issue. Two contrasting opinions here.<br> <noamr> I think this proposal should be a bit more specific<br> <dbaron> Rossen9: Sounds like we should get closer together on the issue before trying to resolve.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10647#issuecomment-2379758630 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 17:34:58 UTC