Consider supporting existing CSS Property parsings about css-houdini-drafts HOT 9 OPEN

Decided that this was reasonable, incorporated.

from css-houdini-drafts.

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?

from css-houdini-drafts.

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.

from css-houdini-drafts.

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)).

from css-houdini-drafts.

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

from css-houdini-drafts.

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)

from css-houdini-drafts.

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 :(

from css-houdini-drafts.

Right. After some discussion, even supporting this for animation is gonna be a little janky. I'd prefer deferring this to level 2, when our "apply hook" can manually produce a value suitable for interpolating, regardless of what the specified grammar is. Level 1 is intentionally a little feature-weak to keep it reasonable to review and implement.

from css-houdini-drafts.

I'm fine putting this on Level2 backlog.

from css-houdini-drafts.