[css-images-4] Gradient interpolation doesn't specify how to handle positionless stops at computed-value time

[tabatkins]

The gradient-line "fixup" rules https://drafts.csswg.org/css-images-4/#color-stop-fixup do two things:

1. Supply default positions for any stops that don't have them
2. Shift stops that are positioned before earlier stops to instead coincide with them.

(2) needs to happen at used-value time since it might need to resolve percentages dependent on layout, so the entire process is defined as happening at used-value time. This means, tho, that position-less stops don't have positions at computed-value time, when they want to interpolate.

There's no reason to not fill in the positions at computed-value time; they're purely syntactic (either 0%, or 100%, or a naive interpolation between the nearest stops that do have a size). This just needs to be separated out.

(While we're at it, we should fix the other interpolation issue https://drafts.csswg.org/css-images-4/#interpolating-gradients about the length of the gradient line.)

[svgeesus]

So, concretely, in this example

div {
  width: 600px;
  height: 200px;
  background: linear-gradient(to right, red 10%, yellow, white, blue calc(300px + 50%))
}

what are the positions of the yellow and white stops at computed value time? They are independent of the size of the div, yes, but the algorithm hasn't calculated them to determine that yet. Or is the value an expression like calc(calc(calc(300px + 50%) + (10%)) * 0.333)) ?

[css-meeting-bot]

The CSS Working Group just discussed [css-images-4] Gradient interpolation doesn't specify how to handle positionless stops at computed-value time, and agreed to the following:

• RESOLVED: move the missing position fixup to computed value time

The full IRC log of that discussion

<emilio> TabAtkins: Right now images defines fixup steps to supply default positions and shift stops that are mis-ordered
<emilio> ... The second one requires layout-time information
<emilio> ... so that step has to happen at used value time
<emilio> ... for simplicity at the time I put all the fixups over there
<emilio> ... But that means that stops without a position don't have a position at computed value time when interpolating
<emilio> ... And there's no reason for doing that, can be done at computed-value time
<emilio> ... Proposal is to split the fix-up between computed-value and used-value time fixup
<ChrisL> q+ to wonder what the syntax is for the interpolated value
<emilio> ... where computed fixup would assign positions
<astearns> ack ChrisL
<Zakim> ChrisL, you wanted to wonder what the syntax is for the interpolated value
<emilio> ... and used would reorder fixups
<emilio> ChrisL: what do you actually get?
<emilio> TabAtkins: just calc()s
<emilio> ... just evenly spacing the missing values
<emilio> astearns: So proposal is moving the missing position fixup to computed value time
<emilio> q+
<astearns> ack emilio
<TabAtkins> emilio: my concern is - to be clear, i think every browser does this at used-value time righ tnow
<TabAtkins> emilio: this changes the computed value serialization in a somewhat non-trivial way, hope this isn't an issue
<ChrisL> q+ to mention missing values and one-stop gradients
<TabAtkins> emilio: this is potentially a concern
<emilio> TabAtkins: I haven't done a test to see if browsers currently interpolate missing positions or not
<emilio> ... I think the gradient interpolation text doesn't take that into account
<emilio> ... The serialization one is a meaningful change, we can fix that if it becomes a problem
<emilio> emilio: at that point you could just change the interpolation algorithm right?
<emilio> TabAtkins: yeah that'd probably be better
<astearns> ack ChrisL
<Zakim> ChrisL, you wanted to mention missing values and one-stop gradients
<emilio> ChrisL: If we're fixing this this, I think a one-stop gradient would go to a 50% rather than 0 or 100%
<emilio> TabAtkins: happy to take that up but let's do this resolution first
<emilio> RESOLVED: move the missing position fixup to computed value time
<ChrisL> OK, the other issue is #10092
<ChrisL> https://github.com//issues/10092#issuecomment-2230892477
<emilio> emilio: does this _need_ to happen at computed value time? Could be done at parse time right?
<emilio> TabAtkins: yeah, but we usually don't do this at parse time
<emilio> emilio: yeah just wanted to clarify whether it could be done or I was missing anything
<emilio> ChrisL: just wanted to make sure we didn't stomp on the other resolution
<emilio> TabAtkins: Yeah it doesn't matter very much