Search code examples
cssvendor-prefix

Do vendor-prefixed CSS properties get updated when non-prefixed parent gets updated?

I was recently re-reading the W3C CSS Timing Functions module when I noticed that the definition of a single-timing-function has been updated to include the frames() timing function (see this section):

<single-timing-function> = linear | <cubic-bezier-timing-function> | <step-timing-function> | <frames-timing-function>

I JSFiddled to see if frames() currently works when using the animation property but it seems this function is not currently supported on the browsers I use (but cubic-bezier() as shown here of course does work for -moz-animation, as the fiddle shows).

Are currently-supported vendor-prefixed properties (e.g. -moz-animation, as in the above JSFiddle) updated to support changes in the parent (non-prefixed) property? That is, when e.g. frames() is supported by browsers for the animation property, will it be supported for e.g. -moz/-webkit-animation properties, or can this not be generalized? (i.e., it depends)

Solution

  • Most vendor-prefixed features do seem to be updated to match the standardized implementations, because generally the prefixes are reimplemented as aliases of their unprefixed counterparts by the time the latter is shipped in production. But I don't think this can be generalized — well, I guess I just did that, so I'll say instead that this cannot be relied on. Gradients are a well-known example of prefixed features not being updated to match the latest standard.

    Actually, that statement isn't even 100% correct — because Mozilla did actually update their -moz-linear-gradient() function to accept the same to <side-or-corner> syntax along with the old <side-or-corner> syntax (both of which have completely opposite meanings), whereas WebKit-based browsers as well as IE11 still do not accept the new to <side-or-corner> syntax for their -webkit-linear-gradient() and -ms-linear-gradient() functions (and -ms-linear-gradient() is completely gone from Microsoft Edge).

    But every browser correctly implements the standardized grammar for linear gradients: the to keyword is required when specifying a <side-or-corner> keyword; using such a keyword without the to in a linear-gradient() expression is invalid in every browser.

    In other words:

    1. -moz-linear-gradient(top, #FF0000, #FFFF00) works in Firefox;
    2. and -moz-linear-gradient(to bottom, #FF0000, #FFFF00) also works in Firefox;
    3. -webkit-linear-gradient(top, #FF0000, #FFFF00) works in Safari and Chrome;
    4. but -webkit-linear-gradient(to bottom, #FF0000, #FFFF00) does not work in Safari or Chrome;
    5. -ms-linear-gradient(top, #FF0000, #FFFF00) works in IE10 and IE11;
    6. but -ms-linear-gradient(to bottom, #FF0000, #FFFF00) does not work in IE10 and IE11;
    7. linear-gradient(top, #FF0000, #FFFF00) does not work in any browser;
    8. and linear-gradient(to bottom, #FF0000, #FFFF00) works in all browsers.

    So, given the mess that is prefixed gradients, I would highly recommend not relying on prefixed implementations to work like the standard all the time. Even if one browser reimplements a prefix as an alias of the unprefixed version of the feature once the implementation becomes stable, not all browsers may do so.

    Having said that, it's very likely that all browsers alias their prefixed -*-animation and -*-transition properties to their unprefixed counterparts, and so it's equally likely that the prefixed properties will be automatically updated to support new timing functions as a side effect of their unprefixed counterparts being updated to do so.