[css-shapes-2] In `shape()` It should be possible to specify control points relative to their point on the curve

[smfr]

In CSS Basic Shapes 2, the [shape()](https://drafts.csswg.org/css-shapes-2/#shape-function) function allows you specify points with to or by which indicates whether the point, and its control points, are specified in "absolute" terms relative to the bounding box, or in "relative" terms from the current path point.

However, in many cases I think authors will want to specify control points relative to the path point that they are attached to. I should be able to say something like curve to 120px 140px with -12px -10px / 15px 20px to say that the first control point is at -12px -10px relative to the start of the segment, and the second one is at 15px 20px relative to the end point.

We'd need some reasonable behavior for quadratic segments, and smooth segments.

[smfr]

Another enhancement is to allow authors to specify control point positions as percentages of their path segment, which means we have two ways to resolve percentages on control points: relative to the reference box, and relative to the "segment box" (a box enclosing the two end points of the segment).

[smfr]

If we allow segment-relative percentages, authors will need to be able to mix and match for the two axes on a control point (say, using segment-% for the horizontal component, and box-% for the vertical), since a segment's start and end point can be at the same X or Y position.

[smfr]

@noamr

[noamr]

For the latter point, perhaps it can be a type of unit? 20segh
It can also work for arc radius.
Nice idea!

[noamr]

Perhaps:
curve to 120px 140px with -12px -10px from start / 15px 20px from end

This can also allow mixing relative/absolute:
curve by 200px 200px with -20px 20px from top left
smooth to bottom right with 30px 30px from segment-start

[tabatkins]

or the latter point, perhaps it can be a type of unit? 20segh

Yeah, if we do this it needs to be a new unit. It's not a referencing mode at all; it can be meaningful to use in either absolute or relative positioning, and mixed with normal %s.

[smfr]

I like segh, segv, where 100segh is 100% of the horizontal distance between the segment start and end points.

[smfr]

I think we could also simplify things by collapsing the different segment types by using auto. For example, hline could
be:

line to auto, 30px

and vline could be:

line to 50px, auto

We could also collapse smooth into curve:

The smooth cubic curve smooth to 120px 140px with 150px 200px could be:

curve to 120px 140px with auto / 150px 200px

and the smooth quadratic curve smooth to 120px 140px could be:

curve to 120px 140px with auto

[noamr]

I think we could also simplify things by collapsing the different segment types by using auto. For example, hline could be:

line to auto, 30px

and vline could be:

line to 50px, auto
`

It was like this in the original shape() proposal, I think vline and hline are more readable.

[css-meeting-bot]

The CSS Working Group just discussed [css-shapes-2] In `shape()` It should be possible to specify control points relative to their point on the curve, and agreed to the following:

• RESOLVED: Add a from-start keyword that goes after the value and latches the coordinate to the beginning of the segment.

The full IRC log of that discussion

<dbaron> noamr: This is about the shape syntax.
<dbaron> noamr: Mostly saw ??? a bit complex to define shape syntax with bezier curves, cubic and quadratic.
<dbaron> noamr: When we define those curves we first define end points and then control points.
<dbaron> noamr: sometimes we want control points relative to start rather than to what we just defined which is the end
<dbaron> noamr: this can be boggling
<dbaron> noamr: In SVG control points go in order. They always end in the end.
<dbaron> noamr: Here we can have either order.
<dbaron> noamr: With keyword where you can specify 2 or specify ????
<dbaron> noamr: Simon added another issue that I think we should open separately.
<dbaron> noamr: Proposal here that I raised that we can discuss is that you can add the word "from" after specify point, can say "From start"
<dbaron> noamr: It's getting less and less similar to SVG, for better or for worse.
<TabAtkins> q+
<dbaron> noamr: Do we want to keep it similar-ish to SVG, with same mental model, or do we want to break free from that.
<dbaron> noamr: We were breaking away a bit, but piecemeal.
<dbaron> noamr: I think it needs a higher decision about that.
<astearns> my vote is to break free if there is good justification
<dbaron> noamr: Specifically here because we changed the order of endpoints earlier, it makes it difficult to have points relative to start, and we need another keyword for that.
<dbaron> noamr: This becomes quite wordy.
<dbaron> noamr: I think with the property syntax, people sometimes avoid it because it adds a lot of CSS.
<dbaron> noamr: We need to be careful about not being too verbose.
<dbaron> noamr: The SVG ordering allows being a bit more terse.
<dbaron> noamr: I think switching the order and allowing using keywords is more verbose.
<lea> This issue seems to be related to #10647 (overloading path() for the path syntax that is closer to SVG)
<Rossen9> ack TabAtkins
<dbaron> I don't have an opinion on exactly ???, but it's complicated... but for the more general case of close to SVG or break free. I don't think we should pay attention to what SVG can do right now. We should continue expanding what's useful regardless of what we can port back to SVG syntax.
<ydaniv> +1 to TabAtkins
<dbaron> noamr: For now, proposed resolution would be that you can add from keywords that latches the next coordinate to the beginning of the sequence.
<dbaron> noamr: you can say from-start, latches the previous coordinate to the start of the segment
<dbaron> s/sequence/segment/
<TabAtkins> Fine with this for now; I'll review more closely when I get back.
<dbaron> RESOLVED: Add a from-start keyword that goes after the value and latches the coordinate to the beginning of the segment.