Use proper CSS practices for functional notations in scroll()

[tabatkins]

In general, @fantasai and I push for functional notations to just be a way of naming and isolating a chunk of CSS syntax. This isn't JS or C++, comma-separating individual arguments isn't necessary or helpful. It also makes the grammar harder to both read/write as a spec author, and use as a page author; as written, you can leave things off of the end, but if you want to specify one of the final arguments, you must supply all of the preceding ones, duplicating the default values.

Here's my suggestion for a better scroll() grammar:

scroll( <element-ref> || <scroll-direction> || [ <scroll-offset> <scroll-offset>? ] || <time> || <single-animation-fill-mode> )

It's basically identical, but with no commas, and you can provide whatever arguments you want in whatever order you want. (Only exception is that if you want to provide both scroll-offsets, they have to be in the proper order, and together.)

Only ambiguity is that both <scroll-direction> and <scroll-offset> allow auto as a value. There's two ways to handle this:

1. We do have rules already for how to handle this sort of thing - ambiguous values get taken by whatever constructions aren't already assigned, with grammar-order determining the winner when there's a tie. So scroll(auto 50px vertical) would give a start-offset of auto, end-offset of 50px, and direction of vertical, but scroll(auto 50px) would give a start-offset of 50px, an end-offset of auto (because unspecified) and a direction of auto.
2. Probably better, we can just remove the auto value from one of the constructions. In particular, a start-offset of auto is equivalent to 0%, and an end-offset is equivalent to 100% (right?), so we don't actually need those; now that you don't need to specify offsets just to specify a time or fill-mode, you can just omit the offsets and be fine. (Alternately we could remove it from <scroll-direction>, but there the auto behavior actually is distinct from the other values, so it has some worth.)

[fantasai]

Further info at https://wiki.csswg.org/ideas/functional-notation#general-principles

[majido]

Per #4338 we dropped function notation in favor of @timeline rule. So closing this issue since it is no longer applies.