[css-transitions-2] Add transition-behavior property #9101
Conversation
This was resolved here: w3c#8857
css-transitions-2/Overview.bs
Outdated
| <em>unless</em> they have an [=animation type=] that is [=not animatable=]. | ||
| Values with a [=discrete=] [=animation type=] <em>are</em> [=transitionable=], | ||
| and flip at 50% progress (<var>p</var> = 0.5). | ||
| and flip at 50% progress (<var>p</var> = 0.5) if the 'transition-behavior' is |
There was a problem hiding this comment.
To match the terminology for the correct item in the list in css-transforms-1, this should probably refer to the "matching transition behavior".
There was a problem hiding this comment.
It might be simpler to leave out the "and flip at 50% progress" as this is already defined in web-animations-1. The important part is whether they are transitionable.
If you look at the definition from css-transitions-1:
When comparing the before-change style and after-change style for a given property, the property values are transitionable if they have an animation type that is neither not animatable nor discrete.
We could update this to something like:
When comparing the before-change style and after-change style for a given property, the property values are transitionable if:
- They have an animation type that is neither not animatable nor discrete, or
- The transition-behavior is allow-discrete and they have an animation type that is discrete.
There was a problem hiding this comment.
Thanks rob! I replaced this paragraph with your text
css-transitions-2/Overview.bs
Outdated
| The syntax for specifying 'transition' is as follows: | ||
|
|
||
| <div class="prod"> | ||
| <dfn type id="single-transition"><single-transition></dfn> = <<transition-behavior-value>> || [ ''transition-property/none'' | <<single-transition-property>> ] || <<time>> || <<easing-function>> || <<time>> |
There was a problem hiding this comment.
I think it's probably best to put the <<transition-behavior-value>> last; the order does affect the order of serialization that the spec requires.
There was a problem hiding this comment.
We might want to leave the normal value out of the shorthand - it is the initial value so unnecessary to be specified, and it would prevents its specification in other longhands in the future.
There was a problem hiding this comment.
I think leaving normal out of the shorthand is an interesting idea -- but I also think it's not something the WG has done before for any shorthand, so if we think it's worth doing, I think we should bring it up explicitly to the WG to see if other folks have feedback on the idea.
There was a problem hiding this comment.
I realize that transition-property takes <custom-ident> values, which means that the spec should probably also have wording excluding the two new keywords from that <custom-ident> as described in https://drafts.csswg.org/css-values-4/#identifier-value , although that change does have (low, I think) compatibility risk.
Or, alternatively, we could choose not to follow that advice and exclude the keywords, in which case we probably do want to leave this in the first position.
There was a problem hiding this comment.
I think it's probably best to put the <> last; the order does affect the order of serialization that the spec requires.
So instead of doing transition: allow-discrete display 2s it should be transition: display 2s allow-discrete? Now that the value is called "allow-discrete" I'm more ok with this. When it was just "discrete" or "animatable" I felt more strongly that it should come first. What do you think rob?
the spec should probably also have wording excluding the two new keywords from that
<custom-ident>
If we put the keyword at the end, then this wouldn't be needed right?
There was a problem hiding this comment.
I don't think the ordering is relevant. This affects the parsing rules -- and effectively without that exclusion the spec would need prose rules for how to distinguish the values, given that https://drafts.csswg.org/css-values-4/#component-combinators explicitly says that the ordering around || does not matter. (This implies, I think, that it doesn't imply any rule about breaking ties during parsing when more than one option of an || matches. Though maybe that implication wasn't intended. But I think it does imply that it's a specification error if more than one option around an || matches and the spec doesn't say how to resolve the conflict.)
There was a problem hiding this comment.
given that https://drafts.csswg.org/css-values-4/#component-combinators explicitly says that the ordering around || does not matter
Oh wow, so transition: 2s color works the same as transition: color 2s!? It looks like this is true after I tried a basic test in chrome.
I moved it to the end of the list
dbaron
left a comment
There was a problem hiding this comment.
This basically looks good, just a few comments:
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
|
In my last commit ce5d6d3 I removed a note about transition:all which is no longer true based on the way I implemented the new CSS property: https://chromium-review.googlesource.com/c/chromium/src/+/4616155/14/third_party/blink/web_tests/external/wpt/css/css-transitions/all-with-discrete.tentative.html @dbaron do you think this is ok? |
dbaron
left a comment
There was a problem hiding this comment.
Good catch. I agree that all combined with allow-discrete should actually allow discrete transitions!
Fixes #8857