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

> Again, as a design principle, we don't add things for completeness

The thing is, tho, we *do* add things for completeness sometimes, when their lack would be a surprise to authors. Strict adherence to "use-case or gtfo" can result in weird holes in APIs, and gratuitous differences between things that are intended to be very similar or even identical otherwise. Predictability is one aspect of usefulness in an API.

That's my feeling here. SVG paths have Move and Close, and these can be expressed in `path()`. `shape()` is intended to be a friendlier `path()` that adds additional powers without us being bound by the legacy restrictions of the SVG syntax. This implies that it should be able to do everything that a `path()` can already do; otherwise, you'll force people who just want to rewrite a path (to gain access to CSS units, for example) to *much more substantially* change their code, turning it instead into multiple shapes in a `shape-combine()`.

Having the ability to write simple shapes using the existing shape functions, and merge them with a path or other shapes, is great. But forcing people to write it in that way, when the existing functionality to do it all in one path is *right there*, isn't.

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

The most obvious use-case is any time a relative move-to is convenient or meaningful. A fresh shape is effectively an absolute move-to, which might be annoying vs just saying "and then start the circle 10px to the side of this". (And I suspect it's not worthwhile to add syntax to allow shifting the coordinate space of another shape function.)

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

No, I understood what you were referring to here, it's the idea that there's a meaningful default direction for a single length to be pointing in that I disagree with. I don't believe it's very readable to assume that `line by 5px` means "5px to the right". I prefer `hline by 5px` and `vline by 5px` much better, as they say right away that this'll be a horizontal or vertical line, so you know exactly what the length/coord is referring to. And for any *other* commands my belief about "single value meaning horizontal only" being non-obvious is even stronger.

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

I agree the SVG path syntax suffers from this (see C/S/Q/T, for example), but I don't think that "minimal command set" should be a goal in and of itself. The command set should be the "right" size, using optionality and control parameters when it helps readability, but feeling free to introduce multiple commands when it helps instead.

> [current `curve via ...` being 4 lengths in a row for cubic curves]

Yeah, that's not the best, but I also don't know what to do about it. I don't think `control-points()` makes it *meaningfully* better, tho, and it's so verbose to boot. I think 2 points in a row (4 lengths) is probably the most we should ever allow, tho.

Hm, a possibility - what if the coord-pair grammar was `<len-per>{2} | point( <len-per>{2} )`? That is, you could write `via 1px 2px 3px 4px` *or* `via point(1px 2px) point(3px 4px)`, if that grouping makes it more readable. That's a similar length to `control-points(1px 2px, 3px 4px)`, but makes it optional to use when the author decides it helps readability, without requiring the verbosity when you only have a single control point (as in quadratic curves, or smooth cubics). This would also let you use `point()` elsewhere in the commands when it makes things more readable there, too. (I'm unsure if I like this, fwiw. We'd also have to decide whether to serialize with or without it.)

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

I'm not opposed to this. `curve smooth ...` isn't offensive, it's just a little longer, when part of the appeal of smooth curves is they're even shorter to write than non-smooth ones. ^_^ Then the number of control points still serves to distinguish cubic vs quadratic: without `smooth` you have to give two or one control points, with `smooth` you have to give one or zero (omitting the `via` entirely).

(Or maybe the curve command's name is `[curve || smooth]`, so you can specify *just* `smooth` if you want, or both if you want to be explicit? `smooth curve to ...` would also then be allowed, which reads nicely too.)

> Perhaps something similar? arc-longer? angle-longer?

We're already in the context of the `arc` command here. The entire *concept* of choosing between the four possible arcs is already confusing as hell; I don't think making the name longer makes it any easier to understand or place in context.

I think it might be reasonable to make the size keyword non-optional, in fact; while CSS *does* have a preference for cw/ccw direction, it doesn't generally have a preference for large vs small things. Forcing it to be always be present ensures that people will have some idea of what it does in order to even write the command.

> FWIW in my proposal I used flip for this, which does satisfy both.

If we default to the clockwise arc pair, in accordance with CSS's general preference for clockwise angles, then using `flip` to mean the counter-clockwise seems reasonable to me, and does avoid both the length issues of `clockwise`/`counter-clockwise` and the abbreviation issues of `cw`/`ccw`.

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


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

Received on Wednesday, 7 February 2024 00:45:10 UTC