[css-shapes-2] Order of points and control points in shape()

[smfr]

In #5841 we resolved that the points and the control points could be specified in any order, e.g. these are equivalent:

curve using 10px 30px by 20px 20px
curve by 20px 20px using 10px 30px

I'm having second thoughts. The by or to affect the interpretation of the control point coordinate pairs; they are either absolute (relative to the reference box), or relative to (the current point). So it's odd to specify the control points before you've given the by or to.

I think we should revert this part of the change.

[smfr]

@noamr

[noamr]

@smfr I think I've reached a similar but slightly different conclusion.
I think it's important to have by or to before the control points, but also it makes more sense to have the control points before the final point.

What do you think of #10644 (comment)?
Basically it's ordered, but the control points come first, and you can swap from by to to at any point.

clip-path: shape(from top left,
  hline by 100px,
  curve by 100px 50px / to right bottom,
  curve by 50px 50px / 10% 20% / var(--x) var(--y),
  curve by 50px 50px / 10% 20% / to bottom 50%,
  smooth to bottom left / 0 0,
)

We can play with the exact syntax/separators.
This also allows using position in control points without losing the flexibility of by.

[css-meeting-bot]

The CSS Working Group just discussed [css-shapes-2] Order of points and control points in `shape()` , and agreed to the following:

• RESOLVED: Make the order strict: endpoints before control points.

The full IRC log of that discussion

<dbaron> noamr: This is a very related issue.
<dbaron> noamr: We resolved on allowing any order -- either control points first or end points first.
<dbaron> noamr: With verbosity it seems like it's making things unnecessarily complex
<dbaron> noamr: Maybe endpoints should always go first and control points second?
<dbaron> Rossen9: any reason we can't do it? Implementations that need to change?
<dbaron> noamr: Not shipped yet anywhere.
<dbaron> Rossen9: any objections to making the order strict with the endpoints first?
<dbaron> RESOLVED: Make the order strict: endpoints before control points.
<dbaron> chrishtr: did you resolve to use the adjustment approach in the issue or what simon said in the beginning?
<dbaron> TabAtkins: I think the opposite.
<dbaron> noamr: yeah, what Simon was suggesting that the endpoints go firs.t
<TabAtkins> (noam's comment has the endpoints last; we resolved (correctly) on Simon's preference for endpoints first)

[dholbert]

@smfr, question for you, just to be explicit about where things stand:

The resolution here was "Make the order strict: endpoints before control points", but if I understood the discussion in #10649 (comment) , we're relaxing that now and not requiring that strict order anymore. Is that correct?

[noamr]

@smfr, question for you, just to be explicit about where things stand:

The resolution here was "Make the order strict: endpoints before control points", but if I understood the discussion in #10649 (comment) , we're relaxing that now and not requiring that strict order anymore. Is that correct?

That's correct. Now that we have the with keyword we don't need the strict order.

[smfr]

I want to re-open this for further discussion. The allowed control point values depend on the command affinity (the to/by), so if the control points come first, you have to parse the control points in a relaxed way, and then go back and validate them after you hit the to or by. This doesn't feel great implementation-wise, but it also feels odd as an author to write out control points before you've written the to or by that determines how those control points are interpreted.

I thus propose that we go back to strict ordering of points and control points in curve commands.

[noamr]

I want to re-open this for further discussion. The allowed control point values depend on the command affinity (the to/by), so if the control points come first, you have to parse the control points in a relaxed way, and then go back and validate them after you hit the to or by. This doesn't feel great implementation-wise, but it also feels odd as an author to write out control points before you've written the to or by that determines how those control points are interpreted.

I thus propose that we go back to strict ordering of points and control points in curve commands.

To be clear, you're proposing that the strict ordering would be to have the end point first, correct?
I'm OK with this

[smfr]

Yes, the to or by would have to come first. This would apply to curve, smooth and arc commands.

[css-meeting-bot]

The CSS Working Group just discussed [css-shapes-2] Order of points and control points in `shape()` , and agreed to the following:

• RESOLVED: restrict ordering such that `to` or `by` would need to come first

The full IRC log of that discussion

<kbabbitt> smfr: previously we decided you could specify dest point and control points in any order
<kbabbitt> ... later we added ability to specify control points in a way that depended on relative/absolute to/by on dest point
<kbabbitt> ... possible to write segments where control points come first but there's ambiguity on how to get to dest point
<kbabbitt> ... curve using top left by 10% 10%
<kbabbitt> ... which is invalid
<fantasai> s/using/with/
<kbabbitt> ... you cannot read left to right, you cannot parse left to right, have to maintain state to resolve `to` keyword
<TabAtkins> q+
<kbabbitt> ... do we have a desire in CSS to make things valid when read left to right?
<astearns> ack TabAtkins
<fantasai> curve with 10px 30px by 20px 20px
<fantasai> curve by 20px 20px with 10px 30px
<kbabbitt> TabAtkins: I'm fine with smfr's suggestoin
<kbabbitt> ... being able to know what coordinate space you're working in early seems reasonable
<kbabbitt> fantasai: prefer to keep it reorderable but not a big deal
<kbabbitt> Proposed: restrict ordering such that `to` or `by` would need to come first
<kbabbitt> fantasai: could decide later that it can be reorderable
<kbabbitt> RESOLVED: restrict ordering such that `to` or `by` would need to come first