Adakah Prefixing Vendor Mati?

Let‘s take a quick stroll down memory-lane to revisit how vendor prefixing CSS properties came to be. I hope I don’t trigger PTSD for anyone!

It‘s not clear who started prefixing, or when it began exactly. What is clear, is that by 2006, prefixed features were in Internet Explorer and Firefox. The raison d’être of prefixes was to specify browser-specific features. It was seen as a way to implement non-standard features and offer previews of new standard features.

By 2012, the W3C CSS Working Group was issuing guidance on the use of vendor prefixes:

In CSS we use vendor prefixes for properties, values, @-rules that are: – vendor specific extensions (per CSS 2.1), or – experimental implementations (per CSS Snapshot 2010) (e.g. in Working Drafts)

It became an industry norm. The number of prefixes grew, and with it, things grew confusing. It led to partial implementations of CSS features, introduced bugs, and ultimately created a fracture in the browser ecosystem, which disgruntled developers. Developers responded by making tools to automate the problem away.

Browser vendors slowly began to move away from prefixing, favoring feature flags inside the browser settings instead. It appeared that the problems created by vendor prefixes would fade away in time. The question is: has that time come yet?

I did some analysis on the caniuse dataset and Mozilla Developer Network Compat dataset to answer this question.

Adoption trends

You can see the trend of the implementation of prefixed features across the major browsers in the chart above. I have excluded Chrome for Android because of insufficient data.

From 2007 until 2011, there was a steady increase in the numbers of prefixed features in all browsers. Internet Explorer only saw an uptick in 2011. Then, in 2012, Mozilla began to remove prefixed features — such as -moz-border-radius* and -moz-box-shadow — from Firefox. Thereafter, they consistently removed prefixed properties once the standard version of that property was fully implemented.

In 2013, Mozilla started to make features available behind feature flags (pref flags). That same year, Chrome switched its rendering engine from WebKit to Blink (part of the Chromium project). This was a big turning point in removing some prefixed features.

It was only in April 2016 that WebKit announced that it would no longer release experimental features with prefixes:

Over time this strategy has turned out not to work so well. Many websites came to depend on prefixed properties. They often used every prefixed variant of a feature, which makes CSS less maintainable and JavaScript programs trickier to write. Sites frequently used just the prefixed version of a feature, which made it hard for browsers to drop support for the prefixed variant when adding support for the unprefixed, standard version. Ultimately, browsers felt pressured by compatibility concerns to implement each other’s prefixes.

Because Safari and iOS browsers have always used the WebKit rendering engine, a consistent reduction in the number of prefixes came later to these browsers.

Microsoft was never “gung ho” on prefixing and consistently had the fewest prefixed features. In 2019, Edge switched from its own rendering engine to Blink. In a funny twist, the change actually increased the number of prefixed properties in Edge!

Feature trends

The table below contrasts the prefixed features in 2013 (the zenith of prefixing) with 2021.

It may be surprising to see the raw numbers. The number of features that require prefixing fell by ~33% between 2013 and 2021. That number sounds quite modest to me.

Of course, it could be misleading to focus just on numbers. The impact varies. It could be a family of properties that all require prefixing, such as animation; or it could be a feature that only has one property or value that requires a prefix, such as user-select: none. Let’s explore the actual features to understand the circumstances better, beginning by looking at what changed in that intervening period.

Twenty features were unprefixed (fully implemented across the major browsers) and three prefixed features were introduced (backdrop-filter, CSS text-orientation, and CSS initial-letter).

In my opinion, the most notable features that are unprefixed now, which were significant pain points are:

1. CSS Flexible Box Layout Module
2. CSS3 Box Sizing
3. CSS Animation
4. CSS3 2D Transforms
5. CSS3 3D Transforms
6. CSS Filter Effects

The other 14 features are less prominent:

1. :any-link
2. ::placeholder
3. ::selection
4. :focus-visible
5. :is()
6. :read-only
7. :read-write
8. font-feature-settings
9. text-align-last
10. writing-mode
11. CSS grab and grabbing cursors
12. CSS Logical Properties (will be used a lot more in the future, now that support is better)
13. CSS3 zoom-in and zoom-out cursors
14. CSS3 Multiple Column Layout

If you choose not to support Internet Explorer 11 in 2021, then an additional seven features no longer require prefixing. That reduces the number of features that require prefixing in 2021 to 28, which is a 46% reduction since 2013.

Prefixing in 2021

Let‘s look at the properties that require prefixing. It’s a motley group!

After putting this list together, my initial impression was that these aren’t things that I would bump into very often. Some properties have not been — and probably will not be — fully implemented. I’d say the element() function and CSS Canvas Drawings fall into that category. Safari recently dropped prefixing for position: sticky, so that will likely drop off the list very soon.

You can winnow the list down and steer away from certain situations if you want to. You can dismiss it and say it’s not important, so why bother? The reality is that the list is still long enough that manually managing prefixes in your code is not something you want to take on. A pertinent question to answer is: do you want to improve cross-browser support to a high level? If the answer is yes, then you should consider this as part of your development effort.

It is also important to remember that it is not just about these properties and current browsers. There are still people out there using older devices with older browsers, which do not support the unprefixed versions of some features. Take the animation property, for example. Chrome was the last browser to unprefix it in 2015. Yet, today, 1.3% of the users worldwide are still using a browser that does not support the unprefixed version.

I have bumped into a couple of situations recently that required prefixed properties. For example, I was making a reading progress bar for a blog and needed to use -webkit-appearance: none; and -moz-appearance: none; to reset the default styling for the progress element. It also needed sticky positioning, so I had to prefix position: sticky to support sticky positioning in Safari.

Another example? I wanted to use a PNG image as a mask image for a Christmas-themed design and found that -webkit-mask-image is the only property that works properly. Masking is generally a bit erratic because most browsers only partially support the spec.

Here’s yet another: Flavio Copes, in “How to apply padding to multiple lines in CSS,” wrote about how he wanted to have the same padding on each line of a multi-line heading. The solution was to use box-decoration-break: clone. Most browsers require the -webkit prefixed version of this property, so you need to use this.

Tools

Some of the tools that were created to solve issues with prefixing and browser support have fallen by the wayside. I would recommend checking first to see if a tool is up-to-date before using it.

Certainly, Autoprefixer (a PostCSS plugin) is maintained and it uses data straight from caniuse to stay current.

Emmet also has great prefixing capabilities. Specifically, it has a css.autoInsertVendorPrefixes preference to automatically insert prefixes for you. I haven’t verified if it is current or not, but it is worth considering as part of your development environment.

Since most code editors support Emmet, it makes editing prefixed properties a lot easier. Emmet has a CSS reflect value command that updates the value of all prefixed versions of the same property in a rule. You can read the Emmet docs for more info about the prefixing capabilities.

Conclusion

Vendor prefixing is not dead, unfortunately. We are still living with the legacy. At the same time, we can be grateful that prefixed features are on a steady decline. Some good work has been done by browser vendors to implement unprefixed features in lieu of prefixed features. This has removed the brunt of the burden from developers.

However, you may bump into scenarios that require prefixes still from time to time. And if you want to support as many browsers as possible, you should continue with an auto-prefixing strategy.

Atas ialah kandungan terperinci Adakah Prefixing Vendor Mati?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!