[css-border][css-animation][css-transition] Animations/Transitions of border-width after change of computed value definition in issue #11494

[weinig]

In issue #11494, the computed value (but not the resolved or used value) for the border-width properties was changed to no longer take the associated border-style into account.

This new definition leads to a change in behavior for animations and transitions of border widths that I don't think is expected. (At least, I think that is the case. There is a lot to the animation specs, so I might have missed something, but it seems like computed values, not resolved or used values, are what are used in making animation decisions).

For example, an animation like:

    @keyframes test {
      from {
        border-width: 3px;
        border-style: none;
      }
      to {
        border-style: solid;
        border-width: 0px;
      }
    }

previously would have been a no-op, but now should now cause a 1.5px border to pop-in half way through the animation (when the style transitions from none to solid), which gradually then animates down to 0px. (3px and none are picked as the initial state, since they are the default values).

Similarly, a CSS transition like:

    .test {
      transition: 1s ease-in-out;
    }

    .test:hover {
      border-style: solid;
      border-width: 0px;
    }

would previously have done nothing, but now will have the 1.5px border pop in half way through.

This has caused at least one regression reported to WebKit, https://bugs.webkit.org/show_bug.cgi?id=307933. (My plan is to use the resolved/used value of border-width for checking to see if a transition should trigger, to work around the issue for now. This appears to be what Firefox is doing, though I have not looked at the code to confirm).

My suggestion would be that we specify that border-width (and perhaps outline-width and column-rule-width) uses the resolved/used values for all animation and transition determinations,

[emilio]

@weinig I don't think that's what's going on, at least in your reduced test-case (https://bug-307933-attachments.webkit.org/attachment.cgi?id=478378).

We use computed values to trigger transitions. It just so happens that the initial value of border-*-width is medium, so your reduced test-case doesn't change border-width at all?

[emilio]

@weinig FWIW the issue reported in that WebKit bug also repros in Firefox, or what am I missing? I think this is technically a chrome bug.

[weinig]

@weinig I don't think that's what's going on, at least in your reduced test-case (https://bug-307933-attachments.webkit.org/attachment.cgi?id=478378).

We use computed values to trigger transitions. It just so happens that the initial value of border-*-width is medium, so your reduced test-case doesn't change border-width at all?

That test case is indeed slightly different from what I described here, but I am still seeing something in Firefox than I would expect if only computed value was being observed.

• In Firefox (and in older WebKit), I see it smoothly animating the border and background color.
• In tip-of-tree WebKit, and what I would expect if only computed value was being observed, I see it smoothly animating the background color, and then popping in a border at the 50% mark (when border style changes from none to solid).

I just uploaded a second test case, https://bug-307933-attachments.webkit.org/attachment.cgi?id=478391, which is more like the described scenario, and in Firefox I see it only animating the background color.

[weinig]

Oh, :(. My Firefox install was a bit out of date. Updating it changes it so that it matches tip-of-tree WebKit. Apologies @emilio.

[emilio]

@kbabbitt would you agree this is a Chrome bug? I don't think we should start transitioning properties based off used values tbh...

[weinig]

@kbabbitt would you agree this is a Chrome bug? I don't think we should start transitioning properties based off used values tbh...

@emilio, to be clear (and I am not sure this is what you were saying, but just to be clear) I was suggesting we only start transitioning properties based off used values for border-width (and maybe outline-width and column-rule-width).

[kbabbitt]

I agree that for https://bug-307933-attachments.webkit.org/attachment.cgi?id=478391, the expected effect after the change to border computed value should be that a solid border pops in at 50% of the way through the transition, then shrinks to 0px over the rest of the duration.

In Chrome Canary I don't see the border animate at all, which seems like a bug. Tagging in @oSamDavis who did the implementation in Chromium.

In Firefox and Nightly I see the border pop in at the start of the transition rather than at 50%, but that's probably a separate issue.

If this is a significant enough web compat issue that we want to address it, I would rather undo the decoupling change with respect to the border properties than special-case border-width to transition off of used values.

[kbabbitt]

More comprehensive test page: https://codepen.io/kevinbcmu/pen/yyayeMr
Curiously, this only seems to be affecting border-width, not the other properties that were decoupled.

Blink bug: https://issues.chromium.org/issues/487755326