[css-easing] Resolving curves not available at parse time

[sesse]

https://drafts.csswg.org/css-easing/#funcdef-linear specifies:

“If an argument lacks a <percentage>, its input progress value is initially empty, but that is immediately corrected by linear() canonicalization after parsing.”

However, it is not always possible to canonicalize at parse time. For instance, if any of the stops' x values is calc(0.5 + 0.2 * sign(1em - 1px)), we may need to wait until the style is computed before we know if it needs to be clamped to the previous point or not. How do we handle this? What if some of the stops may be resolvable but not all of them?

[sesse]

@tabatkins

[css-meeting-bot]

The CSS Working Group just discussed [css-easing] Resolving curves not available at parse time, and agreed to the following:

• RESOLVED: Copy linear gradients timing details into the linear function

The full IRC log of that discussion

<JoshT> TabAtkins: Spec text for linear easing function has canonical ???
<JoshT> ... steps for filling in steps that have empty inputs like gradients
<astearns> s/canonical/canonicalization/
<dholbert> s/canonical ???/canonicalization/ (I think)
<JoshT> ... but it lacks the timing details that linear gradients put in for values that can't be resolved until computed value time
<JoshT> ... spec bug? I recommend we copy details from linear gradients because it's close to a colour stop list
<JoshT> weinig: can we abstract it into something more general?
<JoshT> TabAtkins: my policy is to wait for a third thing? but I'll see if it makes sense
<TabAtkins> WET code - write everything thrice
<JoshT> weinig: when I implemented this in WebKit, did at computed value time, but i don't expect this to be a compat issue
<JoshT> TabAtkins: proposed resolution is to copy linear gradients into the ??? function
<JoshT> RESOLVED: Copy linear gradients timing details into the linear function