Prefixr is no more. Here we look at what it served for and how it worked

CCS3Every web developer faces the need to craft websites so that they are correctly displayed for the widest possible amount of users. With version three of the Cascading Style Sheets standard (CSS3) came a significant expansion of possibilities for creating visually attractive websites, but this also gave rise to new problems, namely the need to adapt CSS code to specific browsers. This is where Prefixr provided a solution that took care of nearly everything for web developers.

Prefixr: a CSS prefix generator

CSS3 represented a huge set of new features that significantly changed how we write code and style websites. From its first draft version in 1999 to this day, the CSS3 standard has seen constant development, bringing e.g. new modules that replace the animations once possible only through use of Adobe Flash or JavaScript. Such dramatic progress also meant that browser engines needed to adopt the new CSS features. While practically every new browser was able to handle the new official CSS properties, older browser versions that went without updates had problems displaying this code correctly. Moreover, there was the problem of experimental CSS properties that were widely used by webdevs, yet were not officially supported. A solution to this problem was found in prefixes which could be specified before properties or values within CSS code. Prefixes were used by individual browser makers to display new, usually experimental CSS features and they became a de rigueur element of CSS code.

Prefixr was based on a simple solution allowing one to paste ready-made CSS code, without prefixes, into a text field and generate – with a single click – new code that contained all the needed prefixes. Thanks to this, users did not have to remember to manually enter the prefixes, because Prefixr did the whole job for them. The only requirement on the user’s end was that the CSS code be valid, because Prefixr could only generate prefixes for properly formatted values and properties. If an error appeared in the code, then that property would be skipped.

Prefixr’s great popularity

Because CSS3 was undergoing rapid development, and there were a large number of web browsers that each existed in different versions, people in theory had to remember which CSS properties were already official, which ones were experimental, and moreover what each browser version regarded as official or still experimental. In practice, this could not actually be done manually, because the amount of things to keep track of was simply too large. Web applications like Prefixr turned out to be a godsend, because they did all that work for the web developer.

Prefixr enjoyed enormous popularity, particularly among novice webdevs, because it was a fine tool for testing new CSS3 properties. Among more experienced web developers, it was initially a pinned tab in their browsers, but over time, new solutions were sought that would be even more convenient and ideal from the viewpoint of the code itself.

Why doesn’t Prefixr do it any more?

Initially, Prefixr’s greatest advantage was its ease of use. Simply copying your code, pasting it into the browser window, and clicking a single button allowed you to get ready-made code useful for all browsers. But over time, the most popular CSS properties no longer required prefixes, because they were officially recognized by the CSS3 standard, and those prefixes were only needed for a minuscule set of browsers that had not been updated for years – about one percent of all Internet users. The other ninety-nine percent were perfectly capable of handling the CSS3 code written by webdevs. Since specifying those prefixes was no longer obligatory, in most cases they were simply abandoned, and in the vast majority of cases without any negative consequences.

Another reason for moving away from prefixes – and using Prefixr to generate them – was that adding a prefix to a value or property was not actually guaranteed to produce the expected effect. Ever newer and more advanced, but still experimental features meant that browser engine developers had to focus much more on compiling new code, and they often altered support for those CSS features over time. In situations like that, even prefixes were no help, because the browser simply did not know what code it was dealing with.

One final reason for Prefixr’s decline is the constant pursuit of progress in the IT industry at large. Since most of those prefixes were no longer needed, a website could be served more efficiently by limiting superfluous lines of code and shaving a few fractions of a second off load times. Moreover, scripts exist that, as style sheets are loaded, check which browser we are dealing with and then dynamically generate a .css file with only the prefixes that browser supports. This proved a perfect balance that allowed one to reduce the amount of extraneous code, while maximizing the effect of compiling the code as its author expected.

Various extensions to the most popular code editors were another alternative. Using them, the programmer does not have to remember to manually specify the prefixes, because the entire code could be generated with all necessary prefixes at the press of a keyboard shortcut.

Can we already forget about prefixes?

There is no one clear answer to this question. If we rely on standard CSS3 and do not employ new, experimental properties, leaving the prefixes out will probably have no consequences. If, however, you are writing CSS code and you come across a new property that you have not used before, it is worth making sure that no prefix is required in this case. Those programmers who readily employ all experimental features will certainly have this in mind, because it is easy to see during testing how the website may behave differently across different browsers. Inserting the prefixes is therefore the first step to consider in troubleshooting.