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

Thanks for the extensive response @tabatkins!

> > 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. 

I addressed this in the proposal, and just edited it a bit for clarity:

> SVG paths have commands to close and move, so that one can combine multiple shapes into a single path. I think this is an unfortunate coupling of unrelated concepts and we would never consider it today if it weren't so established already.
> 
> [snip]
> 
> First, I hope we all agree that as a design principle, we want to [make common things easy and complex things possible](https://w3ctag.github.io/design-principles/#simplicity). The simple case is by far more frequently a single closed shape, especially once we consider how CSS shapes are currently used. Subpaths add complexity to that simple case (since you now have to remember to close your paths), and make the syntax more error-prone (since you get unexpected results if you forget to close your paths).
> 
> But even worse, even when you _do_ need multiple shapes, this forces you to now express _all_ of them as paths, even when literally all but one are simpler shapes like circles and rects, introducing an [ease of use to power cliff](https://w3ctag.github.io/design-principles/#high-level-low-level). I question whether subpaths _ever_ reflect user intent. I hypothesize that in nearly every case they are [a workaround to a different problem](https://en.wikipedia.org/wiki/XY_problem), which is to combine multiple existing shapes into a single shape.
> 
> Lastly, being able to assume that every CSS basic shape is a single, closed, contiguous shape involves fewer restrictions around what _we_ can use shapes in CSS for.
> 
> Again, as a design principle, we don't add things for completeness or because they look cool, but because they are justified by use cases which are common and pervasive. I think we should first prove that subpaths pass that bar before we bake them into `path()` simply because they exist in SVG.

> Sometimes it's easier and more straightforward to design things as a single path.

I would love a few use cases where this is true!

> 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.

I think you may have misunderstood, it’s not about lines defaulting to one, it's about *endpoints* having a single coord syntax for when they are only a horizontal/vertical offset. Lines just take an endpoint.

Horizontal and vertical lines are still lines. There is no reason for them to live under a separate command just so we could provide defaults to one of their parameters. I think it should be an explicit goal to keep the number of distinct commands small and easily memorable, and avoid having many different commands for similar but slightly different things, which the original SVG path syntax severely suffers from.

> > 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.

Yes, I see the rationale too, and agreed the ergonomics are terrible for human use.

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

I think you may have missed that my proposal includes syntax for both. :)

> > 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.

Agreed on most of this.
- I’m not a huge fan of `control-points()`, but note that the current syntax has the points specified as basically a series of `<length-percentage>` with no distinction of what is x and what is y, which will be quite hard to read (try it: `via 1em 2em 300px 30vmin` vs `control-points(1em 2em, 300px 30vmin)`). If we can find a non-functional syntax to distinguish the two points, that would be the best of both worlds (e.g. separate keywords? slash?).
- Agreed that not requiring people to spell out `bezier` or `quadratic` is generally a good thing.

My most substantive objection to the current syntax would be that I think `curve` should be a single command (for the same reasoning as v/h lines above), and everything drawing curves should live under it. 

> > 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.)

Fair enough.

> > 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.

Agreed that ideally you want both terseness and readability, but when they conflict, readability is more important than length. Again, code is written once but read many times. Also remember that we only need the keyword to override the default. FWIW in my proposal I used `flip` for this, which does satisfy both.

> > I’m worried  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.

Sure, but these are not the only options. Again, we only need one keyword really, to override the default. In CSS color interpolation we use `hue-longer`. Perhaps something similar? `arc-longer`? `angle-longer`?





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


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

Received on Friday, 2 February 2024 18:45:07 UTC