On Vendor Prefixes

There is a lot of chatter about Mozilla considering implementing some webkit specific prefixes - I encourage everyone to read "Platform/Layout/CSS compatibility"

My personal take on this is "great" and I am glad they have the guts to start the conversation, but in my eyes it should only happen IFF the vendor is going to choose to stop supporting their existing prefix and start supporting the other parties prefix as what they agree to be the way they want the standard to move.

I know a lot of people who targeted mobile saw that the audience they needed to target were using almost exclusively a WebKit based browser and thus chose that as the platform to target. If the mobile device you want to target or your customers want you to target is pretty much a single choice then web developers naturally gravitate to the browser that is most popular and for a long time in the case of iPhone etc, WebKit was (up until recently) your only web platform you had to develop for.

Remy Sharp's blog post is a good summary of the situation, but I don't agree with most of the proposed browser solutions.

To Quote:

Browsers need to:

Fucking drop experimental prefixes. It's unacceptable and a disservice to the developers working with your browser. You need to give timelines to dropping these things.

Non-production ready browsers should support experimental prefixes, production ready releases should not. If it's Chrome 16 - the stable version - experimental support should not be baked in. The properties should be full available without the prefix.

On dropping vendor prefixes, yes but only if they commit to move to another one. The whole gradient syntax winded me up no end - if at this point WebKit had chosen to name it consistently with the -moz implementation and prefixed it so then we could have started to completely drop the old syntax that IMO would have been better. At the same time though we should be educating developers about the tooling available to make the vendor prefixing become a non-story (in most cases).

I had a little chuckle about "production ready browsers" - I don't think this is sensible or feasible given the update cycles of browser and that developers want what they have chosen to implement to look ace in the browsers that they have chosen to make it look awesome in. If you have platform features that no other browser is going to support either now in the near future then we need to have a way to not have them in the base "namespace" - putting them in there is going to cause more problems.

Anyway, these are my thoughts and can be and sometimes are hogwash - my motto is "don't hate, advocate" - and as Remy says "As developers we need to better educate." to which I whole heartedly agree.

View Source | Make a correction | Correction history

I lead the Chrome Developer Relations team at Google.

We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.

Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.

I love to learn about what you are building, and how I can help with Chrome or Web development in general, so if you want to chat with me directly, please feel free to book a consultation.

I'm trialing a newsletter, you can subscribe below (thank you!)

Mastodon Book a consultation