[css-easing-2] linear() custom easing

[jakearchibald]

This PR defines linear(), a way to create custom easings, as discussed in #229 (comment).

In addition, I tweaked the diagrams so they respect dark mode.

Due to various issues, this PR existed in other forms previously:

• [css-easing-1] Some ideas for linear() easing #6533 - initial PR and discussion against level 1 spec
• [css-easing-2] Adding multi-step linear-interpolated easing function #7414 - PR for level 2 spec, closed as it was causing issues with the build bot
• [css-easing-2] Adding multi-step linear-interpolated easing function jakearchibald/csswg-drafts#1 - forked PR to avoid the build bot issues

I think this is ready to land. Once it does, I'll ensure issues are filed with Firefox/Safari/Chrome.

[tabatkins]

Would you mind moving this normative text to the top of the section, and having all the examples below?

[jakearchibald]

How much of it do you want above the examples? Everything from here until ### Syntax ###?

[tabatkins]

Do we want a literal linear(0, 1) to serialize as linear? I think that would be surprising. I'd prefer to not collapse the keyword and function together; just saying that linear acts the same as linear(0, 1) should be fine imo.

[tabatkins]

While you converted some of the SVGs to have opaque backgrounds, others you've newly added are still transparent, so this is actually making them less readable than the default background: white would do. I think you either want to remove this or make all the SVGs opaque.

[jakearchibald]

My intention was to remove the backgrounds so the graphs could be placed in notes/examples without being in their own visual 'box'.

As in, render like this:

Rather than this:

But you would prefer the latter? (my preference isn't strong here so I'm happy to change it)

[jakearchibald]

@tabatkins ping. This is the last bit I'm unsure about.

[tabatkins]

Your screenshot shows them against the lightmode note styling. Have you checked it against the darkmode note styling to confirm that it's actually readable? I suspect it's not. (I'm fine with removing the background in lightmode, since they're authored to be readable against a light background.) I'm mostly just confused why you decided you needed to add an opaque background to some images, but explicitly remove an opaque background from others, when they look fairly similar in color usage to me.

[jakearchibald]

I use dark mode by default so I checked it there too (part of this PR is making those images work well in dark mode). The lack of consistency in the backgrounds is an error on my part, I'll fix them so they're all transparent.

[jakearchibald]

Here it is against darkmode styling. Seems readable to me.

[birtles]

Looks good to me with Tab's suggestions incorporated.

I agree that we probably want linear(0, 1) to serialize as linear(0, 1).

[jakearchibald]

@tabatkins @birtles In terms of serialization, I think the normative text is correct.

• The keyword values ''ease'', ''linear'', ''ease-in'', ''ease-out'', and ''ease-in-out'' are serialized as-is, that is, they are not converted to the equivalent ''cubic-bezier()'' or ''linear()'' function before serializing.

• Step easing functions, (…clipped for brevity…)

• A linear easing function created via ''linear()'' is serialized by getting its serialized computed value.

It explicitly says that linear should serialize as-is, and not be converted to the equivalent linear() function. Only functions created via linear() are serialised to the function form.

So:

• linear serializes as linear
• linear(0, 1) serializes as linear(0 0%, 1 100%)

I think that's the behaviour we're agreeing on, so I guess the note is misleading?

[birtles]

So:

* `linear` serializes as `linear`

* `linear(0, 1)` serializes as `linear(0 0%, 1 100%)`

I think that's the behaviour we're agreeing on, so I guess the note is misleading?

Yes, looks good to me.

[jakearchibald]

I've tried to make the note a bit clearer:

Note: 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.

[jakearchibald]

Implementation bugs:

• Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1345090
• Gecko https://bugzilla.mozilla.org/show_bug.cgi?id=1764126 (they've been implementing as I've been drafting)
• WebKit https://bugs.webkit.org/show_bug.cgi?id=240061

[cdoublev]

<easing-function> = linear | linear() | <cubic-bezier-easing-function> | <step-easing-function>

I think linear() should be <linear()> or linear(<linear-stop-list>) otherwise a grammar parser will see it as a function named linear with no arguments.

[jakearchibald]

@cdoublev I think this is fixed in b5cf7d9. Let me know if it still isn't right – I don't have a lot of experience with this particular syntax.

[cdoublev]

I think it is fixed, thanks. I do not really know when a CSS type or an inline value definition should be used, or if it matters at all. <color> is defined with <rgb()> | <rgba()> | <hsl()> | .... The value definition of a CSS type (production) should be unique whereas inline definitions are free to use different function arguments in different places.

A workaround for me could be to assume that a function with no argument is a CSS type reference that is not wrapped in angled brackets, but I would rather not do that, even if there is currently no CSS function that takes no argument (I think).