css.properties.transition-behavior - allow-discrete does not transition display in Firefox

[rviscomi]

What type of issue is this?

Incorrect support data (example: BrowserX says "86" but support was added in "40")

What information was incorrect, unhelpful, or incomplete?

MDN is showing that Firefox has full support for transition-behavior:

However, the display compat table shows that Firefox does not support transitioning the property when transition-behavior: allow-discrete is set:

It's also broken out on caniuse under the "CSS property: display: Transitionable when setting transition-behavior: allow-discrete" feature:

What browsers does this problem apply to, if applicable?

Firefox

What did you expect to see?

I'd expect to see Firefox have partial support for css.properties.transition-behavior, with a note about the transitionable display issue.

I'd also expect this to affect transition-bahavior's Baseline status to limited availability, because it seems like it doesn't fully work in Firefox.

It probably makes sense to keep the compatibility note on display because the issue affects Firefox's ability to transition that property, but I would have also expected to see a corresponding note on transition-behavior.

Did you test this? If so, how?

No

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

https://developer.mozilla.org/en-US/docs/Web/CSS/transition-behavior#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/CSS/display#browser_compatibility https://caniuse.com/mdn-css_properties_display_is_transitionable

Do you have anything more you want to share?

I found out about the support issue in Firefox through https://youtu.be/VA975GOUFmM?si=WvtQxcksDbT_H6m0&t=844. I'm impressed that they knew about it despite the transition-behavior docs suggesting that the feature is Baseline and fully supported in Firefox.

MDN URL

https://developer.mozilla.org/en-US/docs/Web/CSS/transition-behavior

MDN metadata

MDN page report details

• Query: css.properties.transition-behavior
• Report started: 2025-03-09T14:41:23.194Z

[caugner]

Given the number of upvotes, I think it would make sense to move these subfeatures under transition-behavior (see https://github.com/mdn/browser-compat-data/pull/26507), but we will discuss this in one of our next BCD meetings.

[caugner]

We discussed this in the BCD meeting on 2025-04-15, and decided to add corresponding subfeatures under transition-behavior, rather than moving the is_transitionable subfeatures.

@ddbeck Can you share the rationale for why we want to add separate subfeatures?

[dphlin]

Bugzilla defect cross-reference bugzilla:1834877

[ddbeck]

Can you share the rationale for why we want to add separate subfeatures?

If I remember correctly, the discussion went something like this: if we understand the feature properly, transition-behavior changes the way other properties transition (i.e., it's a backwards-compatible way to opt-in to new behavior on existing properties). So we end up recording a few distinct pieces of information:

• Does the browser parse, handle, cascade, etc. the transition-behavior property?
• If transition-behavior: allow-discrete has been opted into, then does it apply to…
  • display?
  • content-visibility?

The first one is given by css.properties.transition-behavior, while the rest are given by is_transitionable features. I think the original issue is strictly correct that compatibility here is closely related to transition-behavior. But we've run into a problem (primarily for MDN), where if you're a developer and you want to know why a given property is transitioning in a certain way, then you're likely to start by looking at the docs for the property you're trying to transition, not the transition-behavior property.

In an ideal world, MDN would do something like consume a web-features feature and show all the relevant features (no matter where they are in the BCD tree). In a non-ideal world, we have the unhappy compromise options of:

• Duplicating is_transitionable data in specific transitionable properties and css.properties.transition-behavior
• Centralizing the data in css.properties.transition-behavior.*
• The status quo

Duplicating is probably the nicest for MDN readers. 🤷

[jakearchibald]

I feel pretty strongly that we should mark this as a partial implementation in Firefox. It's confusing developers.

[lukewarlow]

I just want to echo what Jake has said. We need to make a change that makes it clear to developers that this does not work for display in Firefox yet. There's lots of technicalities but ultimately that is the single biggest use case Devs have and currently it doesn't work.

[jakearchibald]

PR https://github.com/mdn/browser-compat-data/pull/27921

[caugner]

Apologies, I missed to pick this up earlier.

Note that the consensus in the April 15th BCD meeting was to duplicate the features (not move them), so that developers can find out about this limitation both on the affected CSS properties pages, and on the transition-behavior page. I opened https://github.com/mdn/browser-compat-data/pull/27922 now to do this (without noticing that Jake opened another PR just minutes before).

As for marking transition-behavior as partial in Firefox, that probably makes sense if transitioning display (and content-visibility) is de facto the primary use case.

Generally, when two features interact, there's often ambiguity about which feature is to "blame" (here: the display or the transition-behavior property). In doubt it would also make sense to not mark transition-behavior as partially implemented, and let the subfeatures speak for themselves. This makes sense if allow-discrete does transition (all?) other CSS properties with a discrete animation type in Firefox.

Note that if these duplicated subfeatures get added to the transition-behavior web feature, it should effectively reset its Baseline status.

[jakearchibald]

Animating display is one of the main use-cases here, but I think with the duplication it's clear without also setting it as a partial implementation.

[rviscomi]

Marking the transition-behavior key itself as partially implemented has a couple of side-effects to note:

1. The Baseline status at the top of the MDN doc will change from Newly available to Limited availability.
2. Developer tools like IDEs and linters also use the property's primary BCD key when looking up its Baseline status, so they will report transition-behavior as Limited availability.

Otherwise, if the compat issue is denoted as a subfeature:

1. The Baseline status on MDN will continue appear as Newly available, with the addition of an asterisk to indicate that support for subfeatures will vary.
2. Downstream tools will also continue showing the feature as Baseline Newly available.

In both scenarios, the WebDX transition-behavior feature will regress to Limited availability, because it does take the status of subfeatures into consideration.

While I don't think decisions should be made based on side-effects alone, marking this as a partial implementation does much more clearly communicate that the feature is not fully interoperable, which seems appropriate given how animating display is considered to be one of the primary use cases for it.

[jakearchibald]

1. The Baseline status on MDN will continue appear as Newly available

Yeah, I don't think that's desirable whilst display isn't supported. I didn't realise that would be the case.

Having it partial until the display parts are implemented sounds good.

[rviscomi]

Looks like this was resolved by taking the subfeature approach. Is it worth reopening?

[jakearchibald]

Yeah I think it should be reopened