Re: [csswg-drafts] [css-shapes] CSS flexibility for `path()`s (and let’s fix paths while we’re at it?) (#9889)

> My proposal completely removes the move and close commands and introduces a separate function to combine shapes (for more motivation around that, read the proposal)

Your proposed ability to merge shapes-as-paths into larger paths is a good idea! I don't see why it would negate the use of move and close commands, tho. Sometimes it's easier and more straightforward to design things as a single path.

> Instead of line-specific commands for horizontal and vertical lines, in my proposal all endpoints have a horizontal/vertical only syntax. Then all that's needed for h/v lines is the line command.

I'm not really a fan of this approach. I'm open to being convinced otherwise, but I'd prefer single-axis lines to be specific about whether they're horizontal or vertical, rather than defaulting to one.

> My proposal introduces an alternative arc syntax that follows author intent more closely by allowing them to specify the center and angle rather than the endpoint.

I am *absolutely* in favor of adding more ways to specify arcs; I understand *why* SVG chose the representation it did (it lets them continue the "start point -> end point" theme all the other commands use, which makes their "you can omit command names" feature flow a little better), but I also think it's genuinely the worst way to specify arcs out of all the common reasonable ways.

But again, I don't see why we wouldn't expose SVG's exact arcs as well.

> In my proposal, smooth curves are not a separate command, it's just curve [bezier | quadratic] without control points.

I can see either design as reasonable. I do prefer the current spec design, though: it doesn't require people to spell `bezier` or `quadratic`; I like the `via <points>` syntax slightly better than `control-points(<points>)`; in general I think splitting the curves by "smooth" vs "not" is a more meaningful distinction than by "cubic" vs "quadratic" (SVG, of course, splits them by both axises, because they can't do optional values under their design constraints, but we can.)

Note, too, that you can't omit the control points in a smooth cubic; you get the *first* for free, but still need to specify the second. But that's just a grammar bug, not a substantive comment.

> Do we even need that kind of fine grained control? In most cases a shape is either entirely absolute, or entirely relative (with an absolute start point). Perhaps absolute vs relative could be part of the preamble? Or even the function name?

In my personal experience writing SVG by hand, that "most cases" is definitely wrong. I mix absolute vs relative all the time, depending entirely on what's more convenient both for authoring in the moment and editting in the future. It indeed needs to be a per-command thing. (Sometimes it would be useful to be able to split it even finer, and do per-coordinate, but I think the syntax design needed for that to work would be terrible.)

> cw and ccw violate the [TAG principle against abbreviations](https://w3ctag.github.io/design-principles/#css-naming)

Sure, but `clockwise` and `counter-clockwise` are terribly long. We shouldn't *optimize* for length, but given the size that path data can sometimes get (even when hand-written), making sure it's not *overly* long is still important.

> I’m worried <arc-size> being small | large makes no sense when you see something like arc to 1em 1em of 1em large.

It certainly make more sense than `0` or `1`. ^_^ The SVG arc syntax *is* confusing, but there's not a lot we can do about that. I think `small`/`large` are the best way to spell this piece of functionality. Like I said earlier, introducing *more* ways to do arcs that aren't as confusing would be nice, but exposing all of the SVG path commands directly is useful in its own right.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9889#issuecomment-1922418491 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 1 February 2024 22:44:23 UTC