Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Support 'transition-delay' on non-animatable properties

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
--
enhancement
8 years ago
a year ago

People

(Reporter: d, Unassigned)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.3a1pre) Gecko/20091205 Minefield/3.7a1pre
Build Identifier: 

Based on:

http://lists.w3.org/Archives/Public/www-style/2009Dec/0027.html

I think we should do a "test implementation" of this with several properties, although the one I can see as most useful is the display property.

Reproducible: Always
(Reporter)

Updated

8 years ago
Blocks: 521890
If we did a test implementation, it would be for all properties, based on the idea in bug 529934 comment 2, plus changes to the transition manager to handle transition-delay even when interpolation is not possible.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 537142
Keywords: dev-doc-needed

Comment 2

7 years ago
I just wanted to chime in real quick with a user's perspective... I've been playing with transitions for the past week or so (for the Game On competition), and it would be very useful to be able to specify whether all-or-nothing, non-animatable changes (e.g. display:none <-> display:block) happen before or after other transitions take effect. Re-using the existing transition syntax makes sense -- I actually tried to use the transition-delay as proposed before digging into the MDC and W3C docs to find that this wasn't supported. You can see the sorts of hacks that are cropping up to work around this limitation here: http://stackoverflow.com/questions/3331353/css-3-transitions-on-the-display-property
You need to log in before you can comment on or make changes to this bug.