Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-transitions-2] Start transitions on discrete animation types #4441

Closed
flackr opened this issue Oct 22, 2019 · 13 comments
Closed

[css-transitions-2] Start transitions on discrete animation types #4441

flackr opened this issue Oct 22, 2019 · 13 comments

Comments

@flackr
Copy link
Contributor

flackr commented Oct 22, 2019

One of the goals of web-animations is to allow developers to define custom transitions. In theory, this would let a developer define a transition for property types which are animation type Discrete, however css-transitions-1 defines discrete animations as not transitionable:

https://drafts.csswg.org/css-transitions-1/#starting

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.

This issue is to explore the possibility of allowing developers to create custom transitions for such properties. Since a lot of content today likely relies on the current behavior (transition-property: all is a very common pattern), any solution would likely have to preserve the existing visual behavior

Option 1 - Use custom easing on discrete transitions

We could define transitions on discrete properties to create a transition using an easing type which immediately assumes the end value. This would preserve the existing visual behavior while allowing developers to listen for and modify the transition.

However, if we assume that a lot of existing comment has transition: all >0 duration, doing all of the work to create and run these transitions may be prohibitively expensive.

Option 2 - Start and cancel discrete transitions

Start the transition animation, and immediately cancel it, such that a developer could access it and play it / modify it from a transitionstart event?

@birtles
Copy link
Contributor

birtles commented Oct 22, 2019

Yes, it would be nice to support this.

Apart from perf considerations, I'm a bit concerned about compatibility with option 1. If scripts are, for example, waiting for transitionend events and then asserting their propertyName is such-and-such, then firing transitions for other events could lead to breakage.

Option 2 would still result in extra transitionrun and transitioncancel events but I expect far less content is actually listening to them so they are less likely to produce breakage.

What about not allowing all or any shorthand to ever match discrete properties but still creating transitions for them (using the behavior from option 1) if they are explicitly listed? e.g. transition-property: all, overflow-x?

I suppose that runs the risk that if a longhand is promoted to a shorthand we might need to special case it so it keeps working (depending on how we define a discrete property). Then again, any content listening for transitionrun events on the (now) shorthand name, would already break since the UA would start firing events on the corresponding longhand names instead.

The other option that comes to mind is simply to add extra syntax for this, be it an extra property (transition-property-set: discrete-too) or extra syntax attached to property names.

@TheBigApple
Copy link

Flackr,
I think your on to something. I am running into a problem with using the 'background-image' in an SVG transition [i.e. css: background-image: url (xyz)]

Once I have 'encode' in-line and apply it to the css as a background-image: url ... I loose the transition ability.
This is because 'background-image' is "Animation type - DISCRETE".

If you have a work-around for this that would be great!

Here is where I'm stuck, I have an Accordion which uses the [+/-] svg as a toggle button.

I've got it working the way I want, but want to remove the HTML's in-line ,
and place it into the CSS, Or at least have it as a <style> in the Header.
[see working: 1.0 default [current ver - no mod].html]

Placing it in the Header <style> works BUT I loose the animation.
[not working: 2.0 default [in header].html]

Ultimately I really want it in the CSS file, to get it completely out of the HTML.
[not working: 3.0 default [in css main2].html]

It could be that the 'encoding' will not allow the 'evenodd' method to work,
or I have it placed wrong, The animation/transitioning does not work.

The Button's CSS starts at line: 1495

Example DL here: http://msgr.info/In-Line_SVG_to_CSS.zip - 152 KB (155,648 bytes)

[Note this 'example' is stripped down from the Original Site to lessen the load, it's a bit dirty-code - the best I could do to make an example]

Thank you for your help!

@flackr
Copy link
Contributor Author

flackr commented Nov 20, 2022

What about not allowing all or any shorthand to ever match discrete properties but still creating transitions for them (using the behavior from option 1) if they are explicitly listed? e.g. transition-property: all, overflow-x?

@birtles I like the idea of having transition: all match everything that is animatable and not discrete, and allowing developers to explicitly specify discrete properties if they want them to participate in transitions.

The other option that comes to mind is simply to add extra syntax for this, be it an extra property (transition-property-set: discrete-too) or extra syntax attached to property names.

I think that having discrete as something that could be specified in addition to all would be nice.

Thinking about this I'm realizing developers could also use transition events as a way to detect style changes. Not sure if this is an explicit use case we should support but it's interesting to think about what people might do with that.

@flackr
Copy link
Contributor Author

flackr commented Nov 28, 2022

So to be specific, the proposal here is:

  1. Properties explicitly listed in transition will transition even if discrete.
  2. (Optionally) add a keyword similar to all which includes discrete properties too, or optionally is just for discrete properties.

@birtles
Copy link
Contributor

birtles commented Nov 29, 2022

Yes, I agree with that summary, assuming we want to go ahead with this (personally I'm not familiar with the use cases).

@andruud
Copy link
Member

andruud commented Dec 12, 2022

@flackr I think I would phrase (1) as follows:

1a. Properties with discrete animation types do transition (generally), however:
1b. The all keyword does not represent such properties.

That way there is nothing particularly special about certain properties being "explicitly specified". They transition because they are specified, end of story. Then (2) also becomes non-special, since it's just a keyword which represents a certain set of properties.

@graouts
Copy link
Contributor

graouts commented Dec 14, 2022

Yes, I agree with that summary, assuming we want to go ahead with this (personally I'm not familiar with the use cases).

I also follow the general thrust of this issue but am uncertain what the use cases are. Being able to transition properties with a discrete animation type would mean that they would no longer switch value immediately but rather halfway through the transition duration. What is foreseen as benefits from transitioning a discrete property in that way?

Or would we envision a different mode where the value change is performed at the end of the transition?

@mfreed7
Copy link
Contributor

mfreed7 commented Dec 14, 2022

I also follow the general thrust of this issue but am uncertain what the use cases are. Being able to transition properties with a discrete animation type would mean that they would no longer switch value immediately but rather halfway through the transition duration. What is foreseen as benefits from transitioning a discrete property in that way?

One important use case is transitioning the display property (see #6429 (comment)). Since interpolation for display is done like visibility, it prefers the non-none state. So transition: display 200ms is immediate for the "showing" transition, and delayed until the end for the "hiding" transition.

@flackr
Copy link
Contributor Author

flackr commented Dec 14, 2022

What is foreseen as benefits from transitioning a discrete property in that way?

There two main benefits to transitioning discrete properties:

I get that you're calling out the 50% flip and I agree in general most people will want the transition of these at the end if declared as a transition-property because switching immediately doesn't require any transition, however this isn't true if the developer is customizing the transition and perhaps there are cases where they want the composite order of the transition animation?

Or would we envision a different mode where the value change is performed at the end of the transition?

So, developers could use transition-timing-function setting step-start or step-end to choose whether to hold the beginning or ending keyframe. We do define for particular properties where certain values may not be useful interpolations - e.g. display: none is useful to avoid in the same way that visibility interpolation avoids hidden: https://drafts.csswg.org/web-animations-1/#animating-visibility. I could see defaulting the timing function to step-end for discrete properties but it would be weird if you couldn't choose a different timing function, and if the developer is customizing the transition it would be nice for them to be able to use the regular animateable timing function.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-transitions-2] Start transitions on discrete animation types, and agreed to the following:

  • RESOLVED: if a discretely animatable property is listed in a transition it will. by default the all keyword will not transition
The full IRC log of that discussion <bramus> astearns: thanks oriol
<bramus> flackr: in current spec we explicitly dont transition discrete aniamtions types. we skip
<bramus> flackr: with resoltuion to animate display it would be useful for devs to transition discrete properties
<bramus> flackr: example in linked issue
<bramus> flackr: proposal is that we allow transitioniong discrete props but to preserve compat the all keyword would only match animatable types
<smfr> q+
<bramus> flackr: only if dev lists explicitly lists a discrete property it would transition
<astearns> ack smfr
<bramus> smfr: … timing function? steps timing to contorl when the value flips?
<bramus> flackr: sure you can
<bramus> flackr: step and step-start
<bramus> smfr: is there [missed] … the animation? wondering if timing function> .5 that is where discrete things flip
<bramus> flackr: my proposal is not to do something special here
<bramus> flackr: means that you can use any fn that crosses .5 treshold
<dbaron> You can also use a different transition-delay for the discrete property if you want to.
<bramus> smfr: trying to underrstand implications
<bramus> flackr: all would only include animatable props
<bramus> smfr: mech for keyframes?
<bramus> flackr: already the case. not building any new anim behavior here
<bramus> smfr: havent quite got in my head yet. is there a dif between props that animate discretely and those not at all?
<bramus> flackr: yes. you cant animate aninaton-name for example
<bramus> smfr: what about display?
<fantasai> well, we resolved to draft such a proposal into the css-display-4 draft
<bramus> flackr: we resolved on display last week
<bramus> smfr: doesnt this already work by virtue of .5 behavior?
<bramus> flackr: there is line in spec that limits to only animatable and not discrete
<bramus> tabatkins: you can animate a discrete prop but not transition one
<bramus> flackr: with waapi, devs can listen to transitionstart
<bramus> flackr: they could use this to enable transitions we do not support yet
<bramus> astearns: easier acces
<bramus> flackr: possible to acces. before no transitionstart ( = custonization point)
<masonf> q?
<bramus> plinss: some props are discrete because they are difficult to animate
<bramus> plinss: if an engine figures out how to make a discrete prop animate: is that allowed and would it then be treated as normal animated property?
<bramus> flackr: yes and yes
<fantasai> plinss++
<bramus> flackr: and would then be picked by up by `transition: all`
<bramus> plinss: can we detect this?
<astearns> ack fantasai
<bramus> fantasai: example: animate between 2 background imgs.
<bramus> fantasai: tarnsitionable with easing curbe
<bramus> fantasai: what would happen if it became animatable? compat problems? might be fine
<bramus> flackr: cases for waapi and css anims. they dont have a mechanism to know when the become animatable
<bramus> flackr: you could use this to feature detect if property is discrete or not
<fantasai> s/tarnsitionable with easing curbe/if author transitions with a particular easing curve assuming discrete/
<bramus> plinss: we may want to consider an `@supports` for this
<bramus> astearns: yes
<masonf> q?
<bramus> astearns: do we add ability to tell sth is discrete or animatable?
<masonf> q+
<astearns> ack masonf
<bramus> masonf: point out that there is an optional part 2 to add a new keyword
<bramus> astearns: lets discuss after
<astearns> ack fantasai
<bramus> fantasai: proposal is that you explicitly list a property that is discrete it will transition. whe you provide an easing curve it will flip at 50%?
<bramus> flackr: yes. latter part already implied by how animations work
<bramus> fantasai: seems reasonable
<bramus> astearns: proposed resolution: if a discretely animateable property is listed in a trantion it will. by default the all keyword will not transition
<bramus> flackr: anders said it better there, but effect is the same
<bramus> RESOLVED: if a discretely animatable property is listed in a transition it will. by default the all keyword will not transition
<bramus> astearns: 2nd part: can we have all opt in to this behavior?
<bramus> flackr: 2 options: other type of all keyword that is actually all, or a keyword to target discrete
<astearns> ack fantasai
<masonf> q+
<bramus> fantasai: i think if there is no demand we should not add it. idea to add discrete makes more sense.
<bramus> fantasai: you can then use it to apply a certain curve to only the discrete ones
<flackr> E.g. transition: all 1s ease, discrete step-end 1s;
<astearns> ack masonf
<bramus> flackr: example in irc is sth devs might do
<dholbert> q+
<bramus> masonf: +1 on discrete keyword
<bramus> astearns: i can see value in this
<astearns> ack dholbert
<bramus> astearns: but I might want to see actual real tarnsitions with particular groups of discrete props taht would be solved by this keyword before we resolve to add it
<astearns> s/see value/see theoretical value/
<bramus> dholbert: concern where prop changes from discrete to not discrete
<bramus> dholbert: could be problem for minor content
<bramus> dholbert: also curious for use cases
<bramus> flackr: first part already problem bc all matches [missed]
<bramus> flackr: second part less defined right now
<bramus> astearns: you can do custiomzation now by having discrete property explicitly listed, separetely from all
<bramus> flackr: yes
<bramus> flackr: do see value in discrete keyword
<bramus> flackr: but also fine with exploring use cases first
<bramus> astearns: what about a note in the spec that we consider this keyword and ask authors for use cases (or if we come up with some)?
<masonf> +1
<bramus> flackr: sure
<bramus> astearns: thats it we are at time
<argyle> 👋🏻

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 7, 2023
This isn't part of the landed spec [1], and will be replaced by
a combination of these five CSSWG issues:

- w3c/csswg-drafts#4441
- w3c/csswg-drafts#6429
- w3c/csswg-drafts#8174
- w3c/csswg-drafts#8189
- w3c/csswg-drafts#8389

After this CL, you will no longer be able to animate your
popover like this:

```
  [popover] {
    opacity: 0;
    transition: opacity 0.2s;
  }
  [popover]:open {
    opacity: 1;
  }
```

Instead you'll need to use CSS animations or (eventually) transitions
and you'll have to explicitly declare the `display` and `top-layer`
properties:

```
  transition: opacity 0.2s, display 0.2s, top-layer 0.2s;
```

[1] https://html.spec.whatwg.org/multipage/popover.html

Bug: 1307772,1413556
Change-Id: I4877dd69a06f2624bdb463b065b2e2b66cbf1154
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 7, 2023
… properties.

This feature enables transitioning discrete properties.

This is based on the resolved CSSWG issue:
- Transition discrete properties: w3c/csswg-drafts#4441

You can test display transitions with this CL on:
https://output.jsbin.com/buquher/quiet

Original patch: http://crrev.com/c/4182089

Bug: 1399631, 1413556
Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 8, 2023
… properties.

This feature enables transitioning discrete properties.

This is based on the resolved CSSWG issue:
- Transition discrete properties: w3c/csswg-drafts#4441

You can test display transitions with this CL on:
https://output.jsbin.com/buquher/quiet

Original patch: http://crrev.com/c/4182089

Bug: 1399631, 1413556
Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 10, 2023
This isn't part of the landed spec [1], and will be replaced by
a combination of these five CSSWG issues:

- w3c/csswg-drafts#4441
- w3c/csswg-drafts#6429
- w3c/csswg-drafts#8174
- w3c/csswg-drafts#8189
- w3c/csswg-drafts#8389

After this CL, you will no longer be able to animate your
popover like this:

```
  [popover] {
    opacity: 0;
    transition: opacity 0.2s;
  }
  [popover]:open {
    opacity: 1;
  }
```

Instead you'll need to use CSS animations or (eventually) transitions
and you'll have to explicitly declare the `display` and `top-layer`
properties:

```
  transition: opacity 0.2s, display 0.2s, top-layer 0.2s;
```

[1] https://html.spec.whatwg.org/multipage/popover.html

Bug: 1307772,1413556
Change-Id: I4877dd69a06f2624bdb463b065b2e2b66cbf1154
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 10, 2023
… properties.

This feature enables transitioning discrete properties.

This is based on the resolved CSSWG issue:
- Transition discrete properties: w3c/csswg-drafts#4441

You can test display transitions with this CL on:
https://output.jsbin.com/buquher/quiet

Original patch: http://crrev.com/c/4182089

Bug: 1399631, 1413556
Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 13, 2023
This isn't part of the landed spec [1], and will be replaced by
a combination of these five CSSWG issues:

- w3c/csswg-drafts#4441
- w3c/csswg-drafts#6429
- w3c/csswg-drafts#8174
- w3c/csswg-drafts#8189
- w3c/csswg-drafts#8389

After this CL, you will no longer be able to animate your
popover like this:

```
  [popover] {
    opacity: 0;
    transition: opacity 0.2s;
  }
  [popover]:open {
    opacity: 1;
  }
```

Instead you'll need to use CSS animations or (eventually) transitions
and you'll have to explicitly declare the `display` and `top-layer`
properties:

```
  transition: opacity 0.2s, display 0.2s, top-layer 0.2s;
```

[1] https://html.spec.whatwg.org/multipage/popover.html

Bug: 1307772,1413556
Change-Id: I4877dd69a06f2624bdb463b065b2e2b66cbf1154
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 14, 2023
This isn't part of the landed spec [1], and will be replaced by
a combination of these five CSSWG issues:

- w3c/csswg-drafts#4441
- w3c/csswg-drafts#6429
- w3c/csswg-drafts#8174
- w3c/csswg-drafts#8189
- w3c/csswg-drafts#8389

After this CL, you will no longer be able to animate your
popover like this:

```
  [popover] {
    opacity: 0;
    transition: opacity 0.2s;
  }
  [popover]:open {
    opacity: 1;
  }
```

Instead you'll need to use CSS animations or (eventually) transitions
and you'll have to explicitly declare the `display` and `top-layer`
properties:

```
  transition: opacity 0.2s, display 0.2s, top-layer 0.2s;
```

[1] https://html.spec.whatwg.org/multipage/popover.html

Bug: 1307772,1413556
Change-Id: I4877dd69a06f2624bdb463b065b2e2b66cbf1154
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 14, 2023
… properties.

This feature enables transitioning discrete properties.

This is based on the resolved CSSWG issue:
- Transition discrete properties: w3c/csswg-drafts#4441

You can test display transitions with this CL on:
https://output.jsbin.com/buquher/quiet

Original patch: http://crrev.com/c/4182089

Bug: 1399631, 1413556
Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 14, 2023
… properties.

This feature enables transitioning discrete properties.

This is based on the resolved CSSWG issue:
- Transition discrete properties: w3c/csswg-drafts#4441

You can test display transitions with this CL on:
https://output.jsbin.com/buquher/quiet

Original patch: http://crrev.com/c/4182089

Bug: 1399631, 1413556
Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Feb 16, 2023
… properties.

This feature enables transitioning discrete properties.

This is based on the resolved CSSWG issue:
- Transition discrete properties: w3c/csswg-drafts#4441

You can test display transitions with this CL on:
https://output.jsbin.com/buquher/quiet

Original patch: http://crrev.com/c/4182089

Bug: 1399631, 1413556
Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Mar 3, 2023
…discrete properties."

This reverts commit 367c58094d184ff90ef132789985bd4fc53c721a.

Reason for revert: Causing failures in blink-web-tests on many bots, for example: https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Tests/127213/overview

Original change's description:
> Implement CSSTransitionDiscrete which enables transitions on discrete properties.
>
> This feature enables transitioning discrete properties.
>
> This is based on the resolved CSSWG issue:
> - Transition discrete properties: w3c/csswg-drafts#4441
>
> You can test display transitions with this CL on:
> https://output.jsbin.com/buquher/quiet
>
> Original patch: http://crrev.com/c/4182089
>
> Bug: 1399631, 1413556
> Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Joey Arhar <jarhar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1112645}

Bug: 1399631, 1413556
Change-Id: I45cbf126b16402a88c7105d8204b342a79ded3d5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
aarongable pushed a commit to chromium/chromium that referenced this issue Mar 3, 2023
…discrete properties."

This reverts commit 367c580.

Reason for revert: Causing failures in blink-web-tests on many bots, for example: https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Tests/127213/overview

Original change's description:
> Implement CSSTransitionDiscrete which enables transitions on discrete properties.
>
> This feature enables transitioning discrete properties.
>
> This is based on the resolved CSSWG issue:
> - Transition discrete properties: w3c/csswg-drafts#4441
>
> You can test display transitions with this CL on:
> https://output.jsbin.com/buquher/quiet
>
> Original patch: http://crrev.com/c/4182089
>
> Bug: 1399631, 1413556
> Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Joey Arhar <jarhar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1112645}

Bug: 1399631, 1413556
Change-Id: I45cbf126b16402a88c7105d8204b342a79ded3d5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4305045
Commit-Queue: Adam Rice <ricea@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Adam Rice <ricea@google.com>
Cr-Commit-Position: refs/heads/main@{#1112668}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Mar 3, 2023
…discrete properties."

This reverts commit 367c58094d184ff90ef132789985bd4fc53c721a.

Reason for revert: Causing failures in blink-web-tests on many bots, for example: https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Tests/127213/overview

Original change's description:
> Implement CSSTransitionDiscrete which enables transitions on discrete properties.
>
> This feature enables transitioning discrete properties.
>
> This is based on the resolved CSSWG issue:
> - Transition discrete properties: w3c/csswg-drafts#4441
>
> You can test display transitions with this CL on:
> https://output.jsbin.com/buquher/quiet
>
> Original patch: http://crrev.com/c/4182089
>
> Bug: 1399631, 1413556
> Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Joey Arhar <jarhar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1112645}

Bug: 1399631, 1413556
Change-Id: I45cbf126b16402a88c7105d8204b342a79ded3d5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4305045
Commit-Queue: Adam Rice <ricea@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Adam Rice <ricea@google.com>
Cr-Commit-Position: refs/heads/main@{#1112668}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Mar 3, 2023
…discrete properties."

This reverts commit 367c58094d184ff90ef132789985bd4fc53c721a.

Reason for revert: Causing failures in blink-web-tests on many bots, for example: https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Tests/127213/overview

Original change's description:
> Implement CSSTransitionDiscrete which enables transitions on discrete properties.
>
> This feature enables transitioning discrete properties.
>
> This is based on the resolved CSSWG issue:
> - Transition discrete properties: w3c/csswg-drafts#4441
>
> You can test display transitions with this CL on:
> https://output.jsbin.com/buquher/quiet
>
> Original patch: http://crrev.com/c/4182089
>
> Bug: 1399631, 1413556
> Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Joey Arhar <jarhar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1112645}

Bug: 1399631, 1413556
Change-Id: I45cbf126b16402a88c7105d8204b342a79ded3d5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4305045
Commit-Queue: Adam Rice <ricea@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Adam Rice <ricea@google.com>
Cr-Commit-Position: refs/heads/main@{#1112668}
fantasai added a commit to fantasai/csswg-drafts that referenced this issue Mar 3, 2023
fantasai added a commit to fantasai/csswg-drafts that referenced this issue Mar 3, 2023
fantasai added a commit that referenced this issue Mar 3, 2023
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Mar 7, 2023
…ables transitions on discrete properties., a=testonly

Automatic update from web-platform-tests
Implement CSSTransitionDiscrete which enables transitions on discrete properties.

This feature enables transitioning discrete properties.

This is based on the resolved CSSWG issue:
- Transition discrete properties: w3c/csswg-drafts#4441

You can test display transitions with this CL on:
https://output.jsbin.com/buquher/quiet

Original patch: http://crrev.com/c/4182089

Bug: 1399631, 1413556
Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1112645}

--

wpt-commits: 005d050d16040db8bf64832d2d22e589e8c81b40
wpt-pr: 38399
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Mar 7, 2023
…which enables transitions on discrete properties.", a=testonly

Automatic update from web-platform-tests
Revert "Implement CSSTransitionDiscrete which enables transitions on discrete properties."

This reverts commit 367c58094d184ff90ef132789985bd4fc53c721a.

Reason for revert: Causing failures in blink-web-tests on many bots, for example: https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Tests/127213/overview

Original change's description:
> Implement CSSTransitionDiscrete which enables transitions on discrete properties.
>
> This feature enables transitioning discrete properties.
>
> This is based on the resolved CSSWG issue:
> - Transition discrete properties: w3c/csswg-drafts#4441
>
> You can test display transitions with this CL on:
> https://output.jsbin.com/buquher/quiet
>
> Original patch: http://crrev.com/c/4182089
>
> Bug: 1399631, 1413556
> Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Joey Arhar <jarhar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1112645}

Bug: 1399631, 1413556
Change-Id: I45cbf126b16402a88c7105d8204b342a79ded3d5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4305045
Commit-Queue: Adam Rice <ricea@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Adam Rice <ricea@google.com>
Cr-Commit-Position: refs/heads/main@{#1112668}

--

wpt-commits: ee989e5d26141612b5ecd4236ebad21a217449b6
wpt-pr: 38802
@hober
Copy link
Member

hober commented Mar 9, 2023

Seems like this resolution doesn't match the interoperable behavior of all three engines? web-platform-tests/wpt#38904

@flackr
Copy link
Contributor Author

flackr commented Mar 9, 2023

Yes, there are many wpt tests which explicitly define transitions on discrete properties and test that they don't transition which will be changed by this, but in practice there is no reason for developers to explicitly have discrete properties in their transition list. This is similar to new properties which previously had no effect but could have been used by developers now having an effect when they are defined.

@fantasai
Copy link
Collaborator

This landed in 69f4ac7 via #8520 ; I don't know why GitHub isn't recording it.

marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this issue Mar 28, 2023
This isn't part of the landed spec [1], and will be replaced by
a combination of these five CSSWG issues:

- w3c/csswg-drafts#4441
- w3c/csswg-drafts#6429
- w3c/csswg-drafts#8174
- w3c/csswg-drafts#8189
- w3c/csswg-drafts#8389

After this CL, you will no longer be able to animate your
popover like this:

```
  [popover] {
    opacity: 0;
    transition: opacity 0.2s;
  }
  [popover]:open {
    opacity: 1;
  }
```

Instead you'll need to use CSS animations or (eventually) transitions
and you'll have to explicitly declare the `display` and `top-layer`
properties:

```
  transition: opacity 0.2s, display 0.2s, top-layer 0.2s;
```

[1] https://html.spec.whatwg.org/multipage/popover.html

Bug: 1307772,1413556
Change-Id: I4877dd69a06f2624bdb463b065b2e2b66cbf1154
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4225730
Reviewed-by: David Baron <dbaron@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1107048}
marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this issue Mar 28, 2023
… properties.

This feature enables transitioning discrete properties.

This is based on the resolved CSSWG issue:
- Transition discrete properties: w3c/csswg-drafts#4441

You can test display transitions with this CL on:
https://output.jsbin.com/buquher/quiet

Original patch: http://crrev.com/c/4182089

Bug: 1399631, 1413556
Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1112645}
marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this issue Mar 28, 2023
…discrete properties."

This reverts commit 367c58094d184ff90ef132789985bd4fc53c721a.

Reason for revert: Causing failures in blink-web-tests on many bots, for example: https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Tests/127213/overview

Original change's description:
> Implement CSSTransitionDiscrete which enables transitions on discrete properties.
>
> This feature enables transitioning discrete properties.
>
> This is based on the resolved CSSWG issue:
> - Transition discrete properties: w3c/csswg-drafts#4441
>
> You can test display transitions with this CL on:
> https://output.jsbin.com/buquher/quiet
>
> Original patch: http://crrev.com/c/4182089
>
> Bug: 1399631, 1413556
> Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Joey Arhar <jarhar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1112645}

Bug: 1399631, 1413556
Change-Id: I45cbf126b16402a88c7105d8204b342a79ded3d5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4305045
Commit-Queue: Adam Rice <ricea@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Adam Rice <ricea@google.com>
Cr-Commit-Position: refs/heads/main@{#1112668}
aosmond pushed a commit to aosmond/gecko that referenced this issue May 18, 2023
…ables transitions on discrete properties., a=testonly

Automatic update from web-platform-tests
Implement CSSTransitionDiscrete which enables transitions on discrete properties.

This feature enables transitioning discrete properties.

This is based on the resolved CSSWG issue:
- Transition discrete properties: w3c/csswg-drafts#4441

You can test display transitions with this CL on:
https://output.jsbin.com/buquher/quiet

Original patch: http://crrev.com/c/4182089

Bug: 1399631, 1413556
Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1112645}

--

wpt-commits: 005d050d16040db8bf64832d2d22e589e8c81b40
wpt-pr: 38399
aosmond pushed a commit to aosmond/gecko that referenced this issue May 18, 2023
…which enables transitions on discrete properties.", a=testonly

Automatic update from web-platform-tests
Revert "Implement CSSTransitionDiscrete which enables transitions on discrete properties."

This reverts commit 367c58094d184ff90ef132789985bd4fc53c721a.

Reason for revert: Causing failures in blink-web-tests on many bots, for example: https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Tests/127213/overview

Original change's description:
> Implement CSSTransitionDiscrete which enables transitions on discrete properties.
>
> This feature enables transitioning discrete properties.
>
> This is based on the resolved CSSWG issue:
> - Transition discrete properties: w3c/csswg-drafts#4441
>
> You can test display transitions with this CL on:
> https://output.jsbin.com/buquher/quiet
>
> Original patch: http://crrev.com/c/4182089
>
> Bug: 1399631, 1413556
> Change-Id: Icf5364b970233186794fa9faaa016e0e6542ec2b
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4219315
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Joey Arhar <jarhar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1112645}

Bug: 1399631, 1413556
Change-Id: I45cbf126b16402a88c7105d8204b342a79ded3d5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4305045
Commit-Queue: Adam Rice <ricea@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Adam Rice <ricea@google.com>
Cr-Commit-Position: refs/heads/main@{#1112668}

--

wpt-commits: ee989e5d26141612b5ecd4236ebad21a217449b6
wpt-pr: 38802
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests