I would prefer to keep the cache, but if you go this way instead, you could go even further and inline the vendorPropName() function into finalPropName().

Just be aware the name parameter is overwritten in vendorPropName(), so a new variable has to be introduced to preserve the original name.

// Returns a potentially-mapped vendor-prefixed property
export function finalPropName( name ) {
    // Check for unprefixed property names
    if ( name in emptyStyle ) {
        return name;
    }

    // Check for vendor-prefixed property names
    var capName = name[ 0 ].toUpperCase() + name.slice( 1 ),
        i = cssPrefixes.length;
    while ( i-- ) {
        var prefixedName = cssPrefixes[ i ] + capName;
        if ( prefixedName in emptyStyle ) {
            return prefixedName;
        }
    }

    // If no matching property is found, return the original name
    return name;
}

Fun fact: I discussed the above function with an AI, and it proposed adding exactly the same cache we're talking about here, even though I hadn't asked for it. It even provided a flawless code for it.

The cache no longer provides much value (I'm not 100% sure it ever did). Ironically, the suggestion you got from AI could very well be from training on previous versions of jQuery. But, I like your suggestion to inline vendorPropName.

I have the whole context of the conversation with the AI, and the code it generated has a distinctive coding style.

I'm certain the result doesn't derive from past jQuery code; instead, the AI figured out that the results could be cached and generated code that perfectly accomplishes it.

There's no way to be certain of that, even if the code formatting is different. The AI was likely trained on at least some jQuery code given its ubiquity, but that's just an educated guess. Still, it's irrelevant to question of the usefulness of the cache.

Inlining the vendorPropName function causes an increase in size:

drop-finalPropName-cache @d426bda80dd8d460c070b8d70969a81602609477
   raw     gz Filename
    +2     +3 dist/jquery.min.js
    +2     +5 dist/jquery.slim.min.js
    +2     +4 dist-module/jquery.module.min.js
    +2     +6 dist-module/jquery.slim.module.min.js

Ah, no, this was because the dirty state has a different version string with .dirty at the end and that inflates the size... I thought we were handling this somehow, @timmywil? 🤔

The final size difference is in favor:

last run
   raw     gz Filename
   -10     -3 dist/jquery.min.js
   -10     -1 dist/jquery.slim.min.js
   -10     -2 dist-module/jquery.module.min.js
   -10      0 dist-module/jquery.slim.module.min.js

I updated the PR.

@vlakoff Caching is not always beneficial. We have two possible outcomes:

1. The final property is unprefixed. With the new implementation, we'll just invoke the name in emptyStyle check and return name. With the old one, we'd first check in the cache and return if present. Otherwise, we'd do the name in emptyStyle check and return name. So at the first time we have two checks and then only one - no better than when cache is missing!
2. The final property is prefixed. With the new implementation, we'll do up to a few checks for each call. I doubt this will be on any way expensive - those are very simple checks. Also, the number of properties requiring a prefix gets smaller & smaller over time as new vendor-prefixed properties are no longer being introduced.

For these reasons, we felt 4.0.0 is a good version to drop this cache. We'll keep it in 3.x just in case it matters more for older browsers.

Caution: The PR is currently erroneous.

As I wrote above:

Just be aware the name parameter is overwritten in vendorPropName(), so a new variable has to be introduced to preserve the original name.

Currently, the name parameter is altered in the while loop. Therefore, when returning it as a fallback (no property found, whether unprefixed or prefixed), it contains the last tried prefixed name, instead of the supplied input value.

Why do we need to preserve the original name?

1. The final property is unprefixed. With the new implementation, we'll just invoke the name in emptyStyle check and return name. With the old one, we'd first check in the cache and return if present. Otherwise, we'd do the name in emptyStyle check and return name. So at the first time we have two checks and then only one - no better than when cache is missing!

Lookup is faster on a plain object than on the style property (instance of CSSStyleDeclaration). Both are fast, but the former is significantly faster (sorry, already deleted my local benchmarks). I suppose the function may be called a lot, and gains add up.

2. The final property is prefixed. With the new implementation, we'll do up to a few checks for each call. I doubt this will be on any way expensive - those are very simple checks. Also, the number of properties requiring a prefix gets smaller & smaller over time as new vendor-prefixed properties are no longer being introduced.

Agree that prefixed properties are becoming increasingly rare. Actually, I didn't even consider them when thinking about performance. What we care about are the unprefixed names, which make up 99% of the cases.

Why do we need to preserve the original name?

Fallback if the supplied value is not a recognized property name. I don't know where this happens in real situations, but I certainly would not risk removing this fallback.

It’d be good to see some benchmarks to see what numbers we’re talking about.

You’re right about the fallback; I need to check if there are any measurable consequences of this and if the answer’s yes, add a test for this.

.dirty at the end and that inflates the size... I thought we were handling this somehow

I thought so too.

Lookup is faster on a plain object than on the style property

I suspect you're right about this, and probably by a lot. But, the question isn't, which is faster? The question is, is it fast enough without the cache, which might just take up space? Considering we've been without the cache for most properties (i.e. the ones that don't have a vendor prefix) since 3.4.0 and haven't seen evidence that it affects real world use cases, I doubt adding back the cache is necessary.

Off topic, but the compare size version regex wasn't accounting for the .2 in the beta.2 version string. See #5584

Good news, I found back my benchmark:

( function () {
    const nb = 100000;

    const emptyStyle = document.createElement( "div" ).style;
    const finalProps = {};
    finalProps.color = "color";

    const T1 = new Date();
    for ( let i = nb; i--; ) {
        if ( "color" in finalProps ) {}
    }
    const T2 = new Date();
    for ( let i = nb; i--; ) {
        if ( "color" in emptyStyle ) {}
    }
    const T3 = new Date();

    console.log( T2 - T1 );
    console.log( T3 - T2 );
} )();

Results for 10,000,000 iterations (in ms, lower is better) on Chrome:

6
949

The number of iterations is quite high. Although the former is significantly faster, both are very fast.
For perspective, 10,000 accesses take about 1 ms.

Same benchmark (10,000,000 iterations) on Firefox:

215
362

… Agree the cache can be removed.

Regarding the benchmark, it's even better - we don't expose these APIs publicly so their raw execution doesn't matter - it only matters how it influences public APIs. The real difference would be even lower.

I started wondering - do we need to auto-add vendor prefixes in 4.x at all? In the past, this was a godsend - instead of calling the border-radius getter or setter 5 times, only one was required. Since that time, browser makes agreed to not introduce new vendor prefixes and the old ones gradually disappeared.

I run a small script in supported browsers to detect prefixed CSS props that don't have the identically named unprefixed version and I got the following:

If you look closer, e.g. at Chrome, you'll notice lots of these properties fall into one of the following buckets:

• like -webkit-border-before: the unprefixed version is border-block-start - calling the setter with border-block-start won't pick up prefixed values and calling it with border-before would look invalid as there's no such property and there are no plans for it. Also, only the -webkit-prefixed version is supported anywhere and other versions are not likely to show up.
• like -webkit-box-align: legacy API; unprefixed versions use different names & syntax
• like -webkit-line-clamp: uses the -webkit prefix everywhere, including in Firefox - it should just be used directly as prefixed as there's no unprefixed version - and even if one arrives, it will work differently

There's also user-select which requires the -webkit- prefix in Safari & -ms- in IE, but those APIs seem quite uncommon on those lists.

More details in a separate comment, so that it's easier to skip it:

(() => {
'use strict';

const cssPrefixes = ['webkit', 'Moz', 'ms'];

const prefixedProps = new Map();

const emptyStyle = document.createElement('div').style;

function unprefix(prop, prefix) {
    const withoutPrefix = prop.slice(prefix.length);
    return withoutPrefix[ 0 ].toLowerCase() + withoutPrefix.slice( 1 );
}

for (const prefix of cssPrefixes) {
    prefixedProps.set(prefix, new Set());
}

for (const prop in emptyStyle) {
    for (const prefix of cssPrefixes) {
        if (prop.startsWith(prefix)
                && !(unprefix(prop, prefix) in emptyStyle)) {
            prefixedProps.get(prefix).add(prop);
        }
    }
}

for (const [prefix, propsForPrefix] of prefixedProps) {
    console.log(`props for prefix ${prefix}`, propsForPrefix);
}

})();

I have an infamous example: user-select on Safari.

• Chrome:
  • supported -webkit- prefixed since 2008-12-11
  • supported unprefixed since 2016-10-12
• Firefox:
  • supported -moz- prefixed since 2004-11-09
  • supported -webkit- prefixed since 2016-09-20
  • supported unprefixed since 2019-09-03
• Safari:
  • supported -webkit- prefixed since 2007-10-26
  • still not supported unprefixed 🤡

Refs:

• https://developer.mozilla.org/en-US/docs/Web/CSS/user-select
• https://developer.mozilla.org/en-US/docs/Web/CSS/user-select#browser_compatibility
• https://caniuse.com/mdn-css_properties_user-select

I just noticed you already mentioned that one specifically:

There's also user-select which requires the -webkit- prefix in Safari & -ms- in IE, but those APIs seem quite uncommon on those lists.

Personally, I use this property quite often, and without jQuery, I have to handle both the unprefixed and -webkit- prefixed properties, because of Safari. I have tried reporting this issue to the developers a few times.

Yeah, user-select is a bummer. It's possible we'll have to wait with this for 5.0.0. I still created an issue and marked it for the team discussion: #5585.

I reverted locally to the main implementation with cache removed, i.e. with the vendorPropName function still existed and then to one with a single function. The latter showed the following size comparison (after applying PR #5586):

drop-finalPropName-cache
   raw     gz     br Filename
    -5     +1    +11 dist/jquery.min.js
    -5     +1    +13 dist/jquery.slim.min.js
    -5     +2    -60 dist-module/jquery.module.min.js
    -5     +1     -3 dist-module/jquery.slim.module.min.js

Fluctuations in Brotli sizes are pretty interesting. But the more popular no-module builds are larger, so using two functions makes sense, I think.

PR updated.