[css-easing] `linear` keyword is described as a function in level 1, inconsistent with level 2 about csswg-drafts HOT 8 OPEN

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.

from csswg-drafts.

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.

from csswg-drafts.

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?

from csswg-drafts.

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

• #10688

from csswg-drafts.

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.

from csswg-drafts.

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?

from csswg-drafts.

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.

from csswg-drafts.

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

from csswg-drafts.