Transform with duration and delay

[MattPostlethwaite]

Transform breaks after compilying when set up like this:

div {
     transition-property: top, transform, width;
     transition-duration: 0.3s, 0.3s, 0.3s;
     transition-delay: 0.3s, 0s, 0.5s;
}

As it outputs like this:

div {
     -webkit-transition-property: top, width, -webkit-transform;
     transition-property: top, width, -webkit-transform;
     transition-property: top, transform, width;
     transition-property: top, transform, width, -webkit-transform;

    -webkit-transition-duration: 0.3s, 0.3s, 0.3s;
    transition-duration: 0.3s, 0.3s, 0.3s;

     -webkit-transition-delay: 0.3s, 0s, 0.5s;
     transition-delay: 0.3s, 0s, 0.5s;
}

There is no fourth duration/delay setting for the -webkit-transform

Once I've added the fourth setting to the sass and compiled it the transition works as it should.

Note: I'm viewing the site in Chrome.

[ai]

Safari makes everything really complicated.

I will try to fix it, but not soon. Maybe only after next week.

As quick solution, you should use transition shortcut.

[MattPostlethwaite]

Thanks for the reply. I have changed it to use transition now.

[stratboy]

Hi, I think I've got a similar issue. Here's sample code from inside an outer element:

    &::before,
    &::after {
      transition-duration: 0.3s, 0.3s;
      transition-delay: 0.3s, 0s;
    }

    &::before{
      transition-property: top, transform;
    }

    &::after{
      transition-property: bottom, transform;
    }

Well, the output for transition property of (for ex.) the ::after pseudo will be:

    -webkit-transition-property: top, -webkit-transform;
    transition-property: top, -webkit-transform;
    transition-property: top, transform;
    transition-property: top, transform, -webkit-transform; // this will cause issues

So that in chrome it will cause wrong and sluggish animations.

[jackw]

I've just run into this too. Took me a little while to track down why some transitions were doing weird things. Thought I'd put together a codepen as an example... only codepen's autoprefixer doesn't appear to have this bug!?

http://codepen.io/jackw/pen/xZxJVg

[ai]

@jackw because we change transition behaviour in 6.1 to close a bug with Safari (it miss entire transition on any unknown property).

[ai]

Hm. I still can’t find solution.

Right now on transition: filter 1s input Autoprefixer is forced to generate so complicated output:

a {
    -webkit-transition: -webkit-filter 1s;    /* UC and old Safari */
    transition: -webkit-filter 1s;            /* Safari */
    transition: filter 1s;                    /* Future version of Safari */
    transition: filter 1s, -webkit-filter 1s; /* Blink and other browsers */
}

Say hello to Safari, new IE (It miss entire transition on any unknown property).

The problem is we have 3 different transition for different versions of browsers. This is why we can’t generate correct transition-delay.

Possible way:

1. On this week I will add warning about it to 6.2 release. Step 2 is too complicated and it can take month.
2. Automatically compress transition-property and transition-delay. But we can do it only if they are in one rule. Many cases will be miss. And it is soo uncool to spend for many working time (it looks not like easy task) just for partial solution :'(.

What do you think, guys?

[yisibl]

This is a serious problem. I think it should be to let WebKit fix this bug.

[yisibl]

After the WebKit and Blink separately, to bring more inconvenience to the developer. Blink no longer adds a new prefix property, but WebKit continues.

If one day no longer need to Autoprefixer, the world is so beautiful.

[ai]

I added a warning 9df3d77

[ai]

Released in 6.2 version