Every time you issue a proprietary feature for CSS3 - a kitten dies

From the translator: Continuing the topic of proprietaryity (translations of articles one and two times ), Lea Verou wrote her article on A list apart , in which she gives advice for web developers. On the translation led to the title of the article :)

Official statement: every time you rank a proprietary feature for CSS3, a kitten dies. Any -webkit- fich that is not present in the specifications (at least in the drafts) does not belong to CSS3 . Yes, some features are issued for CSS3, but they are not at all part of CSS3. And this is not nagging . This is a very important point, because such a situation encourages certain companies (* khe * Apple * khe *) to ignore the standardization process, realizing what they came up with in WebKit, and popularizing it among developers as the best invention after the wheel. New shiny toys dazzle us and we also begin to spin them, contributing to the widespread use.

In our quest to use new trinkets, we often forget how many people have struggled in the past decade to allow us to write code without branches and hacks, and expect it to work the same everywhere. If you’ve been in web development for more than a couple of years, you should definitely remember that this was not always the case. The main reason for what is now is web standards, a tough victory in the browser war .

You might be surprised, but web standards existed during the browser war . W3C was founded in 1994 . However, at that time, browser developers did not care about standards, and they introduced innovations of their own accord. As a result, browsers had little to do with web standards. Does it remind you of anything? Today's proprietary features are no better than the same ActiveX and IE filters (note the filter property in Internet Explorer) . The only difference is that today's PR is better, but this is all so far we have not faced the consequences. Believe it or not, the features of IE6, too, were once perceived with great enthusiasm .

Yes, sometimes browsers offer good things that standardize over time (XMLHttpRequest, Drag & Drop API, contentEditable, Web fonts are only a part of them). Nevertheless, nothing prevents to make innovations and follow the process of standardization. How does it prevent them from coming up with something cool to the appropriate W3C working group, to make a proposal and improve it through collective discussion before rushing to embed it. If Microsoft had done this for the Drag & Drop API, then today there would not be a tambourine in order to use this API.
')
Proprietary features that have not passed the standardization process usually have a bad design, even when the idea was good. For example, CSS gradients were a good idea, but -webkit-gradient () was redundant and had errors. Web fonts were a good idea, but using .eot files for this is not. The standardization process not only helps with compatibility, but also helps to improve the design of each feature, due to the large variety of opinions.

Here are some notorious CSS properties that are also very popular:

• -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 property is proprietary. Some of them are just an experimental implementation of the feature included in the standards. This leads us to the next question.

How can I determine that the feature is proprietary?

I have this way: in the Google search bar, I write the name of the feature (in quotes) and add at the end site: w3.org, so that the search is only within the w3.org domain. A couple of examples:

• "Box-shadow" site: w3.org
• Box-reflect site: w3.org

If you look at the results, then for the first feature, the first option is a link to the W3C specification. For the second, the results refer only to the mailing list, and this is a sign that there is no specification for it yet.

What I can?

For a start, do not use proprietary features at all. Do not use them, do not promote them, and definitely do not rely on them. But I understand that it is easier said than done. If you cannot completely abandon the proprietary properties, then here are some tips. I am sure you can follow them:

• Make sure that the use of the feature is consistent with the principles of progressive enhancement .
• Do not tell about such features, and if you still tell, be sure to report that they are proprietary and what this means.
• If you use this feature in your code, add a comment, something like / * Caution: non-standard property * / . Many people learn by studying existing sites. Even if you do not give lectures or write educational articles, you still indirectly learn the rest with each line of your code.
• Criticize articles, reports, demonstrations, etc., that popularize such features without warning, or those that use only one vendor prefix (which is also a very serious problem ). Or, better, fix it , if possible.

How can I help standardize the feature?

If you find yourself using a proprietary feature too often, take part in its standardization. I can recommend a few steps, which, however, can be applied to any proposals in general:

1. Explore alternatives that offer standards.
   
   First of all, examine the alternatives that are in the specifications. They can be bad or without proper browser support, but you will at least know what to expect in the future. You can also add support for future features, thus you will not leave other browsers behind when the corresponding support appears in them.
   You can also speed up the implementation of features by creating a ticket in the browser tracker that does not support it, and if the ticket is already running, leave a comment, show how important it is for you. Browser developers take this into account when determining the priority for new features.
   
   
2. Check if the feature is already being discussed.
   
   The W3C discusses features and brings them to perfection using mailing lists . Each working group has its own list. Sometimes groups come together when a feature is developed that affects several technologies. For example, the CSS working group uses the www-style mailing list, and the SVG working group uses the www-svg mailing list. However, public-fx distribution is used for features that affect both CSS and SVG.
   If you have found the discussion of features, but this discussion has come to nothing, you can try to resume the discussion. But first, study all the correspondence and make sure that your arguments have not yet been brought up in the discussion and you have something to add.
   
   
3. Offer a feature
   
   Try to include as much relevant information as possible in your proposal. You can specify:
   
   • Situations when the feature can be used. It is very important. No one is interested in the standardization of new opportunities that are used in rare cases. Show that the proposed feature solves and how it can be used.
   • Your experience of use. What do you like, what would you like to change, how can this be generalized for a wider range of tasks, etc.
   Determine which specification your offer belongs to (a full list of CSS specifications can be found here ). After this, add the specification identifier to the beginning of the discussion heading . For example, for discussions of the Values ​​& Units module (values ​​and values) you need to add [css3-values] (identifiers for each specification can be found in its URL). This ensures that the editors of the specification will be easier to find your proposal, as well as allow everyone interested in a specific specification to follow the discussion.
   It should also be remembered that new features are not added to the specifications that have already reached the status of Candidate Recommendation (candidate for recommendation), and of course this is also true for all subsequent statuses, that is, Proposed Recommendation and Recommendation (in fact approved specification). For example, if you propose to add a new selector, do not offer to add it to the Selectors Level 3 module, which has the recommendation status. However, you can offer to add it to the Selectors Level 4 module.
   If you want to learn more about the standardization process, read the wonderful series of articles Inside the CSS WG by fantasai.
   

This is all difficult and boring!

The same can be said about any environmental problem. Yes, it is definitely more difficult than just using proprietary features, solving today's tasks. But in the long run, it is in everyone’s interest not to do it.

Apart Magazine and the author [s].