What do you need Javascript for

huh

The implementation of website designs from Photoshop in HTML and CSS has reached a much more convenient level in some areas thanks to CSS3. A web developer is no longer reliant on creating pixel-perfect graphics for rounded corners and drop shadows. Similar to how a layer effect is applied in Photoshop, the HTML element is simply given a CSS property and the browser, for example, renders the desired shadow.

Beautiful new world. However, one thing must be observed: such properties do not conform to the standard, more precisely: they do not appear in any adopted specification. The browsers only set the current specificationsdrafts around.

Good for us web developers, because we don't have to wait until the final completion of the standard (planned for 2022) to play around with the new, fancy features of CSS3. The price for that? The biggest absurdity since Internet Explorer 6: Vendor prefixes.

What are vendor prefixes?

For those who don't know: the browser-specific implementation is addressed with a prefix in front of the actual CSS property. For rounded corners in Firefox e.g. for Safari / Chrome, etc. This means that you have to write up to 5 lines of code for a cross-browser implementation of a CSS property, here is an example of rounded corners:

-webkit-border-radius: 8px; -moz-border-radius: 8px; -ms-border-radius: 8px; -o-border-radius: 8px; border-radius: 8px;

Why exactly do we need that again?

In theory it works like this: a browser can build in its own implementation of a new CSS property. But because it is possible that Safari and Firefox, for example, want to implement the same property but with different syntax at the same time, vendor prefixes were introduced. Each browser implementation can be addressed individually using a prefixed abbreviation in order to achieve the desired result across browsers using the currently valid syntax.

I emphasize: in theory. I'll pick 3 scenarios and hopefully use them to show how unnecessary vendor prefixes actually are.

Scenario 1: Webkit vs. Firefox

An actually quite prominent example: the syntax of a linear course:

background: -webkit-gradient (linear, lefttop, leftbottom, from (# 000), to (#fff)); / * for webkit browsers like Chrome * /
background: -moz-linear-gradient (top, # 000, # fff); / * for Gecko browsers like Firefox * /

Here you can see an application par excellence. Obvious, right? But let's imagine what it would be like without prefixes. Then we would take advantage of the fact that CSS statements that are not understood by the interpreter are simply ignored. In our example this means: the wrong syntax is ignored, the correct one is used. If notated it would look something like this:

background: gradient (linear, left top, left bottom, from (# 000), to (#fff)); background: linear-gradient (top, # 000, #fff);

Advantage: a few bytes saved, and more legible.
Disadvantage:?

Scenario 2: Webkit vs. Webkit

Vendor prefixes are only responsible for the different implementations of two browser manufacturers. However, in the event of differences in favor of standardization, a compromise inevitably occurs, in which at least one browser manufacturer adapts its syntax ... that far was probably not thought.

This is what happens with the said syntax for the linear course. The Webkit syntax was only adapted to the Firefox syntax in mid-January. This results in the problem that newer Webkit releases understand the new syntax (and also the old one), but older releases do just the old.

Here, too, the same โ€œhackโ€ is used: unexpected syntax forms are ignored by the respective interpreter. With vendor prefixes:

background: -webkit-gradient (linear, left top, left bottom, from (# 000), to (#fff)); / * Webkit - old syntax * / background: -webkit-linear-gradient (top, # 000, #fff); / * Webkit - new syntax * /

Without prefixes:

background: gradient (linear, left top, left bottom, from (# 000), to (#fff)); background: linear-gradient (top, # 000, #fff);

Advantage: a few bytes saved, and more legible.
Disadvantage:?

Scenario 3: Webkit vs. Firefox vs. Microsoft

Let's assume the admittedly very unlikely event that 3 browser manufacturers implement competing syntax forms at the same time. Opera would adapt one of the three, and it is also common for future-proof pages to write down the pure form without a prefix:

background: -webkit-gradient (linear, left top, left bottom, from (# 000), to (#fff)); / * Webkit: Syntax 1 * / background: -moz-linear-gradient (top, # 000, #fff); / * Firefox: Syntax 2 * / background: -ms-linear-gradient (top, from (# 000), to (#fff)); / * IE: Syntax 3 * / background: -o-linear-gradient (top, from (# 000), to (#fff)); / * Opera: Syntax 3 * / background: linear-gradient (top, from (# 000), to (#fff)); / * Prefix-free: Syntax 3 * /

Without prefixes one would simply assume that a CSS interpreter picks out the correct syntax. Duplications like in the Opera case would be avoided:

background: gradient (linear, left top, left bottom, from (# 000), to (#fff)); background: linear-gradient (top, # 000, #fff); background: linear-gradient (top, from (# 000), to (#fff));

Advantage: a little more bytes saved, and much more legible.
Disadvantage:?

Summary

Vendor prefixes were created to catch any incompatibilities. Instead of looking for a more universal solution, however, it was limited to the incompatibilities between different browser manufacturers. The idea that two versions of a browser implement a new feature differently, apparently, did not occur with the W3C.

This is inevitably necessary. If Firefox implements a different syntax than Opera, a long-term compromise will have to be made. One of the two will change its syntax in the next release and thus make it incompatible with the previous version. This process is necessary on the way to the standard-compliant implementation of CSS3 properties. So why didn't anyone there think far enough?

Ultimately, one way or another, downward compatibility has to be considered, but absolutely no vendor prefixes are required.

When do vendor prefixes die out?

I hope I was able to make it clear why I think that vendor prefixes are a good idea in principle, but not the ultimate answer. But there is light at the end of the tunnel. If you look at the current implementations for and, it becomes quite clear what is possible, what is not and what you should pay attention to.

Cross-browser support for box-shadow and border-radius

(stolen from electrictoolbox, status: 05/2011)

You can see: the progress towards prefix-free is satisfactory. In my opinion, you can take a few findings from this table, which certainly cannot be applied 1: 1 to all CSS3 properties, but can certainly be viewed as rules of thumb:

  • With Google Chrome, only the current version needs to be viewed thanks to the auto-update function
  • You have to be careful with Safari, although it is also Webkit-based (Steve Jobs held the flag for HTML5 so high ...)
  • IE is mostly ok from version 9 onwards, but a fallback should always be implemented for the 7 and 8 series, the 6 series can (!) be ignored in the best case, since its market shares are gradually (finally) dwindling (not even Facebook and Google support more the 6)
  • Version 3.6 is very used in Firefox, as nothing came after that for a long time (they had won the browser war Part II), so you should keep an eye on this, but from version 4 you can assume that the user updates reasonably regularly, so that I am responsible for I usually only pay attention to the current version
If you disagree, please let me know. I am happy to be taught ๐Ÿ˜‰

How can I make the world a better place? What can I do to prevent vendor prefixes from becoming extinct?

In principle, it helps to ensure that as many people as possible are using an up-to-date browser. In the diagram above you can see that an up-to-date browser is the simplest solution against the continued existence of vendor prefixes. The lower the proportion of a certain version, the easier it is for the web developer to downplay its relevance when talking to customers, the easier it is to dispense with vendor prefixes, the more time the developer has to improve the user experience, the better the web will be, etc. . pp. I had already written some time ago why an up-to-date browser is also important. Here is a quick shorthand argumentation aid as an example

  1. Security: gaps are closed, but only with regular updates
  2. Performance: more speed = shorter waiting times = more time for Facebook and cat pictures ๐Ÿ˜‰
  3. Progress: the latest browser reflects the latest technology, so why not get this one for free?

And so I go over to the end fluently (but already: D).

The mother of all solutions: auto updates

What problems do we actually have? We're getting new CSS3 features, that's good. However, due to the status of the standard, which has not yet been adopted, syntax forms are adapted from time to time. This gives you different implementations for different browsers and (above all) versions.

The easiest solution? Auto-updates of all browsers like Google Chrome.

An alternative way? Conditional Comments for all Browser. Not only

<!--[if lt IE 9]> Anweisungen <![endif]-->

but also

<!--[if gt FF 3.6]> Anweisungen <![endif]-->

Thus, the web developer would be given a powerful - if not particularly noble - tool for the purpose of downward compatibility.

Another alternative based on feature unlocking including versioning can be found here. Also a very interesting and clever approach.

how do you see it?

tl; dr

Vendor prefixes have no right to exist and create new problems (keyword: downward compatibility). Auto-updates of all browsers are needed more and more urgently; alternatively, conditional comments would also be a suitable interim solution for non-IEs.

Tags: CSS3