[css-easing] `linear` keyword is described as a function in level 1, inconsistent with level 2

[svgeesus]

CSS Easing 2 defines 2.2. The linear easing keyword: linear] as a linear easing function with two points, [0,0] and [1.1]. It also fully defines the linear easing function linear(), with syntax, serialization, etc.

CSS Easing 1 briefly defines 2.1. The linear easing function: linear but describes it as a function (despite the lack of ()), and then later on says that it is "simply the linear keyword".

I guess the definition in CSS Easing 1 is an earlier attempt, but now that the definition in CSS Easing 2 is well developed it seems that CSS Easing 1 should be aligned with it. I can see two ways:

1. Define it as a keyword, which it is, but without reference to an undefined (in that level) linear easing function
2. Remove the definition, and just let CSS Easing 2 fully define it.

@birtles @grorg

[birtles]

I think part of the confusion is the reference to "function" in level 1 is not referring to a CSS function but rather an easing function.

I don't quite understand the second proposal. The linear easing function needs to existing in level 1.

I think @tabatkins has been tweaking the definitions in level 2 recently so maybe he has thoughts on this.

[svgeesus]

I think part of the confusion is the reference to "function" in level 1 is not referring to a CSS function but rather an easing function.

I agree that is confusing.

[tabatkins]

Yeah, "easing function" is just existing terminology that's getting an unfortunate semantic conflict here. (It is a function semantically, as it maps an input to an output.)

Have you encountered anyone actually getting confused by this, @svgeesus, or is it just something you noticed?

[svgeesus]

The person being confused by it was myself, in the course of adding WPT annotations to Easing 1 and Easing 2 because

• [css-easing-2] Time for FPWD #10688

[svgeesus]

I still find the definition of the linear keyword in Easing 2 to be simpler to understand:

The linear keyword produces a linear easing function with two points:

input 0
output 0

input 1
output 1

I was thinking the same definition (but without the link around "linear easing function" would be better in Easing 1. But if everyone else thinks it is perfectly clear as-is, then we can close this issue.

[fantasai]

How about splitting the difference and having the definition be

The linear keyword produces a linear easing function whose output progress value is equal to the input progress value for all inputs[, i.e. the same function as ''linear(0, 1)''].

with the bracketed part only in L2?

p.s. Level 2 is really hard to read. Can we write specs for humans rather than compilers, please?

[svgeesus]

I think that is better, although the bracketed part is not strictly true:

Although this produces a linear easing function, uses of the keyword linear always serialize as-is, to linear. Whereas the function equivalent linear(0, 1) will serialize to linear(0 0%, 1 100%). These rules are in Serialization.

So it produces the same effect.

Can we write specs for humans rather than compilers, please?

I can see both sides of this. Some think this pseudocode algorithmic style is clearer. I don't, because it uses awkward constructs like "continue these steps" and so on that I would rather see expressed as sample code in a real language, so I can run it as well as read it.

I also see the POV where specifications should describe the result and not over-constrain the way it is implemented. This is the "reference implementations considered harmful" POV.

[tabatkins]

Yeah, I've been meaning to rewrite the algos a bit, when the pending Agenda+ issues about parsing are resolved.