- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Aug 2024 07:42:34 +0000
- To: public-css-archive@w3.org
I think that is better, although the bracketed part is not strictly true: > Although this produces a [linear easing function](https://drafts.csswg.org/css-easing-2/#linear-easing-function), uses of the keyword [linear](https://drafts.csswg.org/css-easing-2/#valdef-easing-function-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](https://drafts.csswg.org/css-easing-2/#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. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10734#issuecomment-2290828484 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 August 2024 07:42:35 UTC