Consider supporting existing CSS Property parsings

[shans]

For example, being able to specify "<width>" or "<background-color>" as a syntax string.

Issue 1: this gates on the Typed OM specifying object representations of the values.

Issue 2: what should we do with "<width>|<font-size>"? "<font-size>|<width>"? Options:

• don't allow this
• allow this but try in-order parsing, so the first one would always return a width

[shans]

Decided that this was reasonable, incorporated.

[FremyCompany]

Hi there!

I discovered by chance that as part of the big post-F2F rewrite, this feature had been removed.

According to the F2F notes, this is based on feedback from Apple that a list of things would be somewhat easier for them to implement than to reuse what native properties already support. I guess that every browser will find it easier or harder to support either of which, though, and not necessarily the same one.

  shane: To go back... want to ask one question about issue #99
  shane: Specifically, dino and smfr, which is better for you?
         Better to have a list of things or to reference property
         names?
  smfr: I prefer explicit list; referencing properties is harder for
        us.

I didn't spot that discussion during last f2f, but the outcome makes me a bit sad. If people still feel this is the way forward for a faster L1 (ping @smfr), I guess I can live with that, but could we agree on this being a desired L2 feature, at the very least? This would enable every single thing expressible in css to be also expressible and animatable for custom properties (shapes, clip rects, background-position, etc...) which is something I'm really looking forward to.

Any opinion?

[tabatkins]

Problem is that that locks our parsing down. People will depend on a particular property's parsing rules for things that don't necessarily track with what we intend with a property in the future, particularly if this allows them to express things that they can't express manually in a grammar.

[FremyCompany]

I don't believe this will be a very frequent concern, but this remains a valid argument.

How about this would act like * for parsing purposes, but would animate/transition as the property would? If the value is not a valid value of the property, then it just acts like a normal pair of non-interpolable values. If you really care about parsing, you can always nest inside at-supports statements.

My use case is mainly to have transitions and animations to work.

I have multiple use cases but one we already aim to support is similar to how 'translate/rotate/scale' make it possible to have different transitions functions/timing for different subsections of the 'transform' property; I would want to mimick this for 'background' lists, by animating --background-list-1 and --background-list-2 independently (and merging with unanimated background: var(--...1) var(--...2)).

[tabatkins]

That's probably fine. It'll fail in a friendly way.

[FremyCompany]

To avoid confusion, we could probably add this as another optional parameter (interpolateAs). This is more self-explaining. After all, some properties might animate differently the same two pairs of values, so the type isn't the only think influencing interpolation (thinking about visibility and other exceptions, here)

[shans]

To clarify the problem: someone might use <box-shadow> because they want a couple of lengths and a color for a different purpose. Then the CSSWG finds it harder to change the grammar of box-shadow :(