Consider removing the `.css()` behavior of detecting vendor-prefixed versions of props

Description

Since jQuery 1.8.0, jQuery automatically finds a properly prefixed version of a CSS property, provided that the unprefixed version is not supported.

Over time, browsers decided to no longer expose experimental properties under prefixed names and previously prefixed versions have largely become unprefixed.

One important property where this hasn't happened yet is user-select which is still prefixed in Safari: https://bugs.webkit.org/show_bug.cgi?id=208677

More context in this comment & the following ones: https://github.com/jquery/jquery/pull/5583#issuecomment-2489672895

Link to test case

Nov 20 '24 23:11 mgol

Interesting trivia: in the jQuery 1.8.0 release blog post, the property used to show the auto-prefixing feature was exactly user-select: https://blog.jquery.com/2012/08/09/jquery-1-8-released/.

Nov 20 '24 23:11 mgol

I did a quick test with a few scripts:

'use strict';

var prop;
var style = document.createElement('div').style;

var properties = [];

for (prop in style) {
    if (!prop.includes('-')) {
        properties.push(prop);
    }
}

console.log('["' + properties.join('","') + '"]');

'use strict';

const chromeProps = [/* ... */];
const firefoxProps = [/* ... */];
const safariProps = [/* ... */];
const ie11Props = [/* ... */];
const allProps = [/* ... */];chromeProps.concat(firefoxProps).concat(safariProps).concat(ie11Props);

const cssPrefixes = ['webkit', 'Moz', 'ms'];
const emptyStyle = document.createElement('div').style;

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

function addPrefix(prefix, prop) {
    return prefix + prop[0].toUpperCase() + prop.slice(1);
}

for (const prop of allProps) {
    for (const prefix of cssPrefixes) {
        const prefixedProp = addPrefix(prefix, prop);
        if (!(prop in emptyStyle) && prefixedProp in emptyStyle) {
            prefixedProps.get(prefix).add(
                prefixedProp
                    .replace(/[A-Z]/g, letter => `-${ letter.toLowerCase() }`)
                    .replace(/^webkit/, '-webkit')
            );
        }
    }
}

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

Results, sorted alphabetically:

Chrome 131.0.6778.86:

• -webkit-mask-position-x
• -webkit-mask-position-y
• -webkit-perspective-origin-x
• -webkit-perspective-origin-y
• -webkit-print-color-adjust
• -webkit-transform-origin-x
• -webkit-transform-origin-y
• -webkit-transform-origin-z

Firefox 132.0.2:

• -moz-text-size-adjust
• -webkit-text-size-adjust

Safari 18.1.1:

• -webkit-box-decoration-break
• -webkit-initial-letter
• -webkit-mask-position-x
• -webkit-mask-position-y
• -webkit-ruby-position
• -webkit-user-select

IE 11:

• -ms-grid-column
• -ms-grid-row
• -ms-hyphenate-limit-chars
• -ms-hyphens
• -ms-scroll-snap-type
• -ms-text-size-adjust
• -ms-user-select

Nov 26 '24 00:11 mgol

TBH, looking at the above lists, if it weren't for user-select, I'd be for removing the prefixing mechanism even for 4.0.0.

Nov 26 '24 00:11 mgol

Today I learned that Safari attempted to unprefix the property in 2022, but it had to be reverted due to resulting issues. Details can be found at https://bugs.webkit.org/show_bug.cgi?id=242006.

Essentially, Safari's implementation of user-select differs from the standard one, prompting the outlook.com website to implement a workaround. However, unprefixing the property in Safari broke the workaround.

Nevertheless, even after Safari unprefixes the property, we'll have to wait many years before removing the prefixed one in jQuery. So, I would say the sooner Safari is fixed, the better.

Dec 08 '24 15:12 vlakoff

@vlakoff Safari and Apple is ALL OK; its openjs foundation thats to blame! Dissolve it. All problems will disappear.

Jan 13 '25 11:01 MrSuddenJoy

Can I Use for user-select: https://caniuse.com/mdn-css_properties_user-select

Oct 24 '25 16:10 mgol

See also https://github.com/whatwg/compat/issues/135.

It's such a shame that we have this situation just because of one specific case: the Outlook website + Safari. If Safari weren't such a widespread browser, handling of that would have been ditched a long time ago.

Maybe the Outlook website has changed since 2022—I can't tell. It would be great if someone could confirm whether the issue still exists on the site. Looking at how this is still stalled, maybe the Outlook staff could do something to move the needle.

Oct 25 '25 15:10 vlakoff