Is it necessary to add prefixes to some CSS properties?

Asked

Viewed 1,879 times

30

In many codes the browser compatibility prefixes are added in CSS attributes. Example:

.exemplo {
  -webkit-background-size: 50% 50%;
  -moz-background-size: 50% 50%;
  -o-background-size: 50% 50%;
  background-size: 50% 50%;
}

But if you leave only the attribute, without a prefix, it works normally. Example:

.exemplo-2 {
  background-size: 50% 50%;
}

That prefix (-webkit-, -moz-, -o-) are important? Should I still put them?

  • 1

    @Evando these prefix selectors are considered "experimental", ie are not "standards" according to standards, but in several modern browser engines they are already supported in "standard" so it is not necessary to prefix.

4 answers

31


The prefixes -webkit-, -moz- etc are called vendor prefixes. Are adopted by the browser with these prefixes properties still in trial period.

Generally, the rationale for this type of support is the implementation of an unfinished specification, or the implementation of a feature that is not yet part of a formal specification (-webkit-, for example, has many specific experimental properties), simply. When the property has a stable behavior, the prefixes become unnecessary.

How to keep up to date

The Can I Use? is a source essential to check the support status of the properties in different versions of different browsers. Indicates browser versions where the property is prefix dependent or simply not supported in any way.

"Prefixes are great"

Contrary to what has been said, the "use of the prefix" is not, in no way, a good practice - not bad. In fact, this kind of statement does not make sense. There are different views on vendor prefixes under discussion. Therefore, it is better to see it as something just needed at the moment.

There are recommendations, but there’s no way define whether the use is necessary or not.

It all depends on how compatible your project should be.

Say that text-shadow or border-radius It no longer needs prefixes, it is a coherent recommendation and I make it myself, but that is all. The most important thing of all is to be aware that, while keeping an eye on the support of properties** to avoid incompatibilities, one should also avoid vendor prefixes when its use is unnecessary.

8

When the browser is implementing a new standard property, it makes it available with the prefix at first. This prefix (called prefix vendor) is removed only when the property’s behavior is exactly the same as specified. In several cases there will be differences between the "official" behavior and the one displayed by the prefixed property. But often you have no option.

Include a variation of the property for each browser only when you want to use a new CSS feature that does not exist in the unadjusted version in the versions you plan to support. And never forget to put the prefixed version underneath it all to ensure that it takes precedence where it is supported.

There is no need to prefix in all properties however. Gone is the time when border-radius needed them.

2

The use of prefixes is necessary if you want to support the attribute for versions of the browsers in which this attribute was still being implemented. To better understand this you can observe the compatibility of the property background-size and others at this link. Where it is possible to see the prefix in the cell next to the browser version means that it is necessary to support the attribute.

2

Some prefixes are already fully implemented as elements of css 3, but not all are supported or fully defined, so it is important to use prefixes that depending on the browser version may not be implemented as a css attribute.

To solve this problem it is also possible to use Prefix free, in it you write only in a single way while the prefix free code is responsible for maintaining compatibility between other browsers.

Link: Prefix Free

And a demonstration can be seen in:

Link: Test Drive - Prefix Free

Browser other questions tagged

You are not signed in. Login or sign up in order to post.