Closed svgeesus closed 2 weeks ago
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.
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.
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?
The person being confused by it was myself, in the course of adding WPT annotations to Easing 1 and Easing 2 because
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:
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.
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?
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.
Yeah, I've been meaning to rewrite the algos a bit, when the pending Agenda+ issues about parsing are resolved.
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 functionlinear()
, 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 thelinear
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:
@birtles @grorg