-prefix-free: an elegant and miniature “crutch” in JavaScript, eliminating the need to remember and list CSS3 prefixes for different browsers

Every such author of the site, who has ever supplied his child with CSS3 styles, has of course been faced with the need to repeatedly repeat the same CSS3 property and give it the same value, but pointing to the different prefixes of browser developers before the property name (vendor prefixes ).

These prefixes are necessary to ensure that CSS3 properties that are not fully standardized work in browsers: it is believed that a separate setting of the property for each of the current browsers will help to further circumvent the possible difference between the current implementation of the property in each specific browser and the final requirements of the standard . Mozilla Firefox uses the prefix “ -moz- ” for this purpose, Google Chrome and Apple Safari (and other Webkit- based browsers ) the prefix “ -webkit- ”, in Opera, the prefix “ -o- ", in IE is the “ -ms- ” prefix , and in Konqueror (and in the earliest versions of Safari), the -khtml- prefix .

In practice, however, the author of the site most often uses a kind of “common denominator” of the capabilities of several browsers - the values ​​of CSS3 properties that work the same (or almost the same) in all modern browsers. Yes, and they all recorded the same way. Specifying prefixes is therefore reduced to multiple repetition of properties. For example, in order to give a few ColorBox jQuery plugin buttons rounded edges and make them cast a shadow, one must inevitably have to write this in the CSS:

#cboxPrevious, #cboxNext, #cboxClose { -webkit-box-shadow: 0 0 6px #000; -moz-box-shadow: 0 0 6px #000; box-shadow: 0 0 6px #000; -webkit-border-radius: 6px; -moz-border-radius: 6px; border-radius: 6px; } 

Firstly, it is a problem.
')
Secondly, it is uneconomical.

Thirdly, there is always a risk to forget about the need to specify one or another prefix. (In the “ How to avoid common CSS3 mistakes ” list, this mistake comes first.)

Therefore, sooner or later , some means should have appeared that allowed the author of the CSS code to specify only the prefix-free forms of CSS properties and CSS values ​​— and the automation would take care of adapting them to each particular browser.

And such a tool appeared - thanks to Lea Verou. Here it is:



The “ -prefix-free ” script , which takes only 2 Kb in compressed form , processes CSS3 properties and adapts them to browsers.

This is JavaScript, it works on the side of the reader. Obviously, therefore, the script will not work if the reader has javascript disabled; on the other hand, it is possible to check and understand directly in the browser which prefixes the browser needs, rather than relying on sniffing the “User-Agent” header , and not depending on the finished (possibly outdated) list of unsupported properties, as it would be on the server .

The script processes the styles specified inside the <style> elements and in the style = "..." attributes , as well as external styles connected by <link> elements (but not from other domains). An example is the style of the site “-prefix-free”. However, "-prefix-free" does not know how to handle the styles connected by the @import directive.

Opera and Google Chrome browsers do not support the processing of styles that are connected from local files by default (it requires manual configuration of the browser ). In IE browser (as well as in Mozilla Firefox version 3.6 and earlier), the prefix - free property values in the style = "..." attributes do not work , and in these old Firefoxes, not only the values , but also the property names .

A couple of plug-ins are attached to the “-prefix-free” script: the smaller one allows the jQuery library (using the .css (...) method) to read and set CSS3 properties without prefixes, and another plugin watches for the appearance of new <style> and <link > , for changes in the attributes style = "..." , for calls to the CSSOM methods ( CSS object model) - and quickly prefix the necessary properties with prefixes.

However, such tracking again has limitations: changes in the style = "..." attributes (performed by the setAttribute () method ) cannot be traced in Webkit, and in Google Chrome, the task of unprefixed properties via CSSOM will not work (for example, element. style.transform = 'rotate (5deg)' ), although the read will work.

As a result of reading the documentation (the main excerpts from which I just retold), I got the impression that “-prefix-free” might be suitable for designing such a site, the readers of which usually include JavaScript, and the dynamic change of styles comes down to managing classes, rather than directly by the properties of the elements. As for the need to store these values ​​not in the style = "..." attributes , but in style elements and files, this has always been considered a good tone for separating the presentation from the content.

On the other hand, of course, we must not forget that the prefixes did not appear from scratch - they have their own purpose in life: to overcome the mutual incompatibility of browsers (including the old and the new versions of the same browser). Eric Meyer told more about this in the article “ Prefix or Posthack ” (“A List Apart”, July 6, 2010). Supporting the crutch’s CSS3 properties should be abandoned when it can create such incompatibility.

On the third hand, the use of prefixes should not be brought to fanaticism: when it becomes meaningless, a good “crutch” only saves the time of the author of the site, without being able to lead to compatibility problems. The same Eric Meyer on Twitter praised the “-prefix-free” script and thanked Lea Verou.