Public service announcement: Every time you call a proprietary feature “CSS3,” a kitten dies. Any -webkit- feature that doesn’t exist in a specification (not even an Editor’s draft) is not CSS3. Yes, they are commonly evangelized as such, but they are not part of CSS at all.

Article Continues Below

This distinction is not nitpicking. It’s important because it encourages certain vendors (*cough* Apple *cough*) to circumvent the standards process, implement whatever they come up with in WebKit, then evangelize it to developers as the best thing since sliced bread. The shiny new toys dazzle us and we start promoting them too, contributing to the echo chamber.

In our eagerness to use the new bling, we often forget how many people fought in the past decade to enable us to write code without forks and hacks and expect it to work interoperably. If you have been in this field more than a few years, you surely remember that it wasn’t always like this. The reason we now have this convenience is web standards, hard won in the Browser Wars.

You might be surprised to hear that web standards did exist during the Browser Wars too. The W3C was founded in 1994. However, authors didn’t care, and were perfectly willing to embrace proprietary extensions. As a result, browsers didn’t bother much with web standards. Does this remind you of something? The proprietary features of today are no better than ActiveX and IE filters. Their only difference is better PR, as we haven’t faced the consequences yet. Believe it or not, those features were also welcomed with excitement back in the day.

Yes, sometimes browsers come up with good stuff that does get standardized eventually (XMLHttpRequest, Drag and Drop API, contentEditable, Web fonts, to mention a few). However, nothing prevents them from innovating and following the standards process. Nothing prevents them from coming up with something cool, proposing it to the appropriate W3C Working Group, and improving it through collective feedback before rushing to implement it. If Microsoft had done this for the Drag & Drop API, it wouldn’t be such a PITA to use.

Proprietary features that haven’t been through the standards process usually suffer from poor design, even when the general idea is good. For instance, CSS gradients were a great idea, but -webkit-gradient() was a verbose, error-prone mess. Web fonts were a great idea, but requiring .eot files was not. The standards process doesn’t only help with interoperability, it also helps improve the design of every feature, due to the greater number and diversity of opinions.

So, which are these infamous features? In CSS, some of the most popular ones are:

-webkit-box-reflect

-webkit-text-stroke

-webkit-mask

-webkit-background-clip: text;

-webkit-text-size-adjust

-webkit-tap-highlight-color

-webkit-text-fill-color

Not every prefixed feature is proprietary. Some of them are just experimental implementations of features included in draft specifications. Which brings us to your next question.

“How do I detect whether a certain feature is proprietary?”#section2

A way that works for me is to search in Google for the feature (in quotes) and append site:w3.org to the search term, in order to only search within the w3.org domain. Two examples:

As you can see, one of the very first results for the first feature is a W3C specification. The results for the second one are merely discussions on mailing lists, which indicates there is no specification for it yet.

“How can I help?”#section3

The easy rule of thumb is to avoid proprietary features altogether. Don’t use them, don’t evangelize them, and most certainly, don’t depend on them. However, I understand that this might be more easily said than done. If you can’t completely shut proprietary stuff out of your life, here are a few guidelines I’m sure you can follow:

Make sure their usage complies with the principles of progressive enhancement so that the design works fine without them.

Don’t evangelize them or, if you have to, make sure to explain that these features are proprietary and what that means.

If you have to use them in your code, add a comment about this. Something like /* Warning: Non-standard */ would suffice. Many people learn front-end coding by viewing the source of existing websites. Even if you don’t give talks or write tutorials, you are probably indirectly teaching folks with every piece of code you put out there.

would suffice. Many people learn front-end coding by viewing the source of existing websites. Even if you don’t give talks or write tutorials, you are probably indirectly teaching folks with every piece of code you put out there. Call out articles, talks, demos, etc. that evangelize these features with no warnings, or that only use a single vendor’s prefix (which is also a very serious problem). Or, even better, fix them yourself, if possible.

“How can I help standardize a feature?”#section4

If you find yourself needing a proprietary feature too frequently, take action to standardize something similar. A series of steps I’d recommend is the following, most of which can be applied to new proposals in general:

Step 1: Research standards-compliant alternatives#section5

First of all, research standards-compliant alternatives. They might have worse or non-existent browser support, but at least you will know what to push for. You can even add it as a fallback, so that you don’t shut other vendors out even after they implement this feature.

You can even help to speed up implementation, by filing a bug in the browsers that don’t support it. Make sure to search for existing bug reports first. If it’s reported, you can still show that it’s important to you, by writing a comment (be polite!). Browsers take author demand into account when prioritizing which features to implement. Show them that a certain feature matters to you.

Step 2: See if the feature is already proposed#section6

The W3C discusses which features to add and how to tweak them to perfection in their mailing lists. There is one per Working Group (WG), and sometimes more, as Working Groups can collaborate in developing features that affect multiple technologies. For example, the CSS WG uses the www-style mailing list and the SVG WG uses the www-svg mailing list. However, for features that affect both CSS and SVG, there is the public-fx mailing list.

Before you post in any of these lists, please search for prior discussion of the issue. Every minute a WG member spends responding to duplicate suggestions is one less minute spent developing web standards. To search the archives, you can again use ol’ mighty Google. Type your keywords as you normally would and append site:lists.w3.org to your search query.

If you see that the feature is already suggested, but the discussion has stalled with no resolution, you can reply (once!) to bring it up. Please avoid coming off as impatient or irritated in your email. Keep reading the discussion for ideas on what to add that someone hasn’t covered already.

Step 3: Propose the feature#section7

Try to include as many relevant data as possible.

Some kinds of information that you could include are:

Use cases the feature is useful for. This is very important. No WG wants to standardize things that are going to be used in edge cases only. Show that what you’re suggesting is common. A useful technique to gather such use cases is to google for the proprietary feature and see what people are using it for.

Your experience from using that feature. What you like, what you’d change in the way it works, how could it be generalized, etc.

Also, decide which specification it’s for. You can find a list of the CSS specifications here. Then prepend the title of your thread with that specification’s ID in brackets. For example, if it’s for Values & Units, prepend it with [css3-values]. (The ID of each specification can be found in its URL.) This ensures that the editors of that specification will notice your thread more easily, and tagging helps everyone to follow the development of certain specs they’re interested in.

Another thing to keep in mind is that new features don’t get added to specifications that have reached, or are about to reach Candidate Recommendation status. Of course this applies to every status that comes after that, i.e. Proposed Recommendation and Recommendation. For example, if your suggestion is about adding a new selector, don’t suggest it for Selectors Level 3 (ID: css3-selectors), which is in Recommendation status, but for Selectors Level 4.

If you want to know more about how the standards process works, you can read fantasai’s excellent article series “Inside the CSS WG.”

“All this is hard and boring!”#section8

The same can be said for recycling vs. throwing everything in the same bin. Yes, it surely is harder than just using proprietary features and calling it a day. However, in the long run it’s in everyone’s best interests, including your future self.

Thanks a lot to David Storey, Sylvain Galineau, and Eric Meyer for their feedback.