- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Feb 2025 17:49:26 +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()` ``, and agreed to the following: * `RESOLVED: shape() remains as-is, spec subset that is more tightly tied to SVG <path> for a path() overload` <details><summary>The full IRC log of that discussion</summary> <lea> on it<br> <noamr> yay<br> <TabAtkins> lea: there's been dsicussion around making paths easier in CSS<br> <TabAtkins> lea: so far it's still very closely mapped to SVG paths<br> <TabAtkins> lea: taking the design of paths, with its concepts, segments, commands, args, and supporting a CSS syntax for them<br> <TabAtkins> lea: that's what we've done with the other shapes already too<br> <TabAtkins> lea: polygon(), circle(), etc<br> <noamr> q+<br> <kbabbitt> q-<br> <Rossen6> ack kbabbitt<br> <TabAtkins> lea: so it seems weird that we leave path() as this weird function that just takes a string of SVG, and make a different shape() function for the cssy one<br> <TabAtkins> lea: less discoverable and inconsistent<br> <TabAtkins> lea: when i filed this issue, thought we might leave shape() for another feature<br> <TabAtkins> lea: but now I think overloading path() is better even disregarding that<br> <Rossen6> ack noamr<br> <TabAtkins> noamr: shape() does already ahve a few features that SVG doesn't, or does it differently<br> <TabAtkins> noamr: order of control points, you can combine rel/abs in the same shape<br> <TabAtkins> noamr: now adding corner shapes, that'll probably get added to shape()<br> <lea> q+ You can combine relative and absolute in the same shape in `<path>` too? Also, the idea was that we'd eventually backport corner rounding to `<path>` too<br> <TabAtkins> noamr: but also, I think path() can still be extended to make it actually usable, by giving it viewbox and fit<br> <lea> q_<br> <lea> q+<br> <TabAtkins> (lea, he meant combining in one command)<br> <TabAtkins> noamr: i don't have a strong opposition to calling this path(), but I do think they're a bit different<br> <TabAtkins> noamr: shape() is a recipe to create a shape<br> <TabAtkins> noamr: once you combine the shape with a reference box, the path you get can be vastly different from what svg coudl make<br> <TabAtkins> noamr: so i think keeping shape() separate makes sense as it's a recipe to create paths rather than the path itself<br> <TabAtkins> noamr: also the mental model fo path() is closely related to SVG, and if it's extended as I propose it'll stay close to SVG<br> <TabAtkins> lea: you mention rounding<br> <Rossen6> ack lea<br> <TabAtkins> lea: i think we eventually want to backport some of these improvement to path, at least those that are feasible<br> <TabAtkins> lea: but in general i think a better shape function is useful, it just worries me that we're leaving this gap<br> <TabAtkins> lea: authors will expect a CSS syntax for <path> like the other functions/elements have, and they'll find path() and shape() is a different thing<br> <noamr> q+<br> <Rossen6> ack noamr<br> <TabAtkins> noamr: we dont' have proposals to backport the new stuff to SVG, or filling in gaps<br> <smfr> +1<br> <TabAtkins> noamr: so right now, is this better to give a new name with the intention that it'll continue growing, or should we name it path() and say it's a CSS-ified <path> but with extensions<br> <lea> q+<br> <TabAtkins> noamr: I think it ends up just being a name thing<br> <TabAtkins> noamr: No strong opinion, but weak pref for shape()<br> <lea> q?<br> <smfr> q+<br> <Rossen6> acl lea<br> <TabAtkins> lea: replying to "no proposals for backport"<br> <Rossen6> ack lea<br> <TabAtkins> lea: when designing syntax, it's not just about what proposals exist now, bute what future direciton the language might go to<br> <TabAtkins> lea: that's the challenge with standards<br> <TabAtkins> lea: things like backporting rounding to <path> is a low-hanging fruit I think we could end up with<br> <TabAtkins> lea: so we shoudl plan around it<br> <TabAtkins> q+<br> <TabAtkins> smfr: I feel more strongly than Noam that shape() is right<br> <TabAtkins> smfr: it's more discoverable, search for "css shape function" you'll find it<br> <TabAtkins> smfr: I see it being used a lot with future border-shape, so shape() seems natural<br> <TabAtkins> smfr: i sympathize with lea that we shoudl design for the future, but we can choose a different name in the feuture if needed<br> <Rossen6> ack smfr<br> <Rossen6> ack TabAtkins<br> <noamr> TabAtkins: re any backporting/future extensions of path(), to the extent we want to backport anything into SVG, we'll still be spelling it in the SVG way and would probably want to maintain this in-string capability<br> <lea> q+<br> <noamr> TabAtkins: if we don't backport to SVG, but just add to the string that SVG defines, it would look quite different from what shape is doing, because you can't drop things as easily into a command because of the parsing<br> <noamr> TabAtkins: anything we add to SVG would probably not make it into the path itsself. I'm not hopeful<br> <noamr> lea: another benefit is that it's convertable<br> <noamr> lea: I'm convinced that the current design is good enough. I wonder how much can be backported to path?<br> <noamr> TabAtkins: what kind of improvements?<br> <noamr> lea: same segments with CSSified names, length-percentage etc<br> <Rossen6> ack lea<br> <noamr> smfr: a more restricted grammar of this<br> <noamr> lea: sounds perfect<br> <TabAtkins> noamr: i'm also okay with taht possibility, think it's doable to take the subset of shape() be ported back to path()<br> <lea> PROPOSED RESOLUTION: shape() remains as-is, spec subset that is more tightly tied to SVG <path> for a path() overload<br> <TabAtkins> Rossen6: so I'm hearing keep shape() as is... [basically restates lea's proposed resolution]<br> <noamr> +1<br> <TabAtkins> +1<br> <smfr> +1<br> <chrishtr> +1<br> <TabAtkins> RESOLVED: shape() remains as-is, spec subset that is more tightly tied to SVG <path> for a path() overload<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-2654446913 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 February 2025 17:49:27 UTC