Home >Web Front-end >JS Tutorial >The Impending CSS Vendor Prefix Catastrophe

The Impending CSS Vendor Prefix Catastrophe

Christopher Nolan
Christopher NolanOriginal
2025-03-01 00:21:09881browse

The Impending CSS Vendor Prefix Catastrophe

Key Points

    The overuse of
  • CSS vendor prefixes (especially -webkit prefixes) presents potential problems with Web standards and cross-browser compatibility. Developers often use these prefixes to access new features, but this can lead to non-standardized, browser-specific code.
  • World Wide Web Alliance (W3C) is considering supporting the -webkit prefix in non-WebKit browsers. However, this can lead to incompatibility in the implementation of the same attribute and further encourage developers to use WebKit-specific attributes, which may make them the de facto standard.
  • The responsibility for this problem lies with the developers and browser vendors. Developers need to avoid writing browser-specific code and test their websites in multiple browsers. At the same time, browser vendors should provide more information about the standardized status of prefix properties and highlight when they are out of date.

The relationship between the developer and the CSS vendor prefix is ​​intertwined with love and hate. They allow us to use cutting-edge technology, but at the cost of a lengthy statement:

<code class="language-css">background-image: -webkit-linear-gradient(#fff, #000);
background-image: -moz-linear-gradient(#fff, #000);
background-image: -ms-linear-gradient(#fff, #000);
background-image: -o-linear-gradient(#fff, #000);
background-image: linear-gradient(#fff, #000);</code>

Theoretically works well, but consider the actual situation: 1. Experimental properties are usually implemented first in the WebKit engine, and there is no guarantee that they will be copied in other browsers. 2. It is difficult to determine whether the vendor prefix attribute is part of the CSS specification. Some vendors do not submit attributes for standardization. 3. Incorrect vendor prefix versions continue to be supported even if standard properties change. The old code still works; you won't revisit it to correct the implementation.

You often find that websites use only the -webkit prefix—even if other browsers support the property or it has wide availability without the prefix (e.g. border-radius). Therefore, Chrome and Safari look better than competing browsers—other manufacturers are not satisfied with this. This question was raised and discussed at the W3C meeting on February 7, 2012: > Web standards advocates are teaching people to use WebKit. You will see presentations from all Web standards advocates who advocate people to use WebKit prefixes. Our job is to solve interoperability problems. Currently, we are trying to determine which and how many WebKit prefix properties are actually supported in Mozilla. If we do not support the WebKit prefix, we will be excluded from a part of the mobile web.

Let's think about this carefully. Non-WebKit browsers will support the -webkit prefix. This is the solution W3C is considering. This idea is likely to be a crushing defeat. Two or more implementations of the same WebKit property will be incompatible, so developers will not be able to use it anywhere. No one will win – including Apple and Google. But I'm more worried about the irreparable damage it will cause if the solution is successful. Once developers find that WebKit prefix is ​​valid in Firefox, IE, and Opera, they expect them to work on all attributes. WebKit-only adoption will grow exponentially and vendors will be forced to implement these prefixes throughout the process. At that time, regardless of any W3C specification, WebKit attributes will become the de facto standard. Game End: The Open Web is closed. Its impact also goes beyond CSS: many new JavaScript APIs have vendor prefixes.

Who should be responsible?

We can blame the failure on:

    W3C Working Group
  • Web standards take too long to mature. This may be inevitable, but browser manufacturers are bypassing the process.
  • Browser manufacturers
  • They are eager to introduce new technology, it is easy to add prefixes and forget about it. Web developers need more information: Is W3C considering this property and when to unprefix it? Ideally, once the browser implements standard properties, the experimental prefix disappears. Vendors won't do this because it will break the website, but they can do more to highlight the issue, such as providing outdated detection tools or outputting error messages to the developer console.
  • Electric and Google
  • Both are guilty of promoting the WebKit prefix as a standard part of everyday HTML5 web development. Apple is accused of actively opposing the W3C.
  • Mozilla, Microsoft, and Opera
  • Other vendors usually lag behind WebKit browsers for months, if not years. Adding a WebKit prefix is ​​a ridiculous solution: it's time to improve their level.
  • Technical websites and preachers
  • We all love cool demos, but preachers often ignore the mention that attributes are experimental and may never get full browser support (Yes, this includes SitePoint). Ideally, the code should run in at least two browsers; at least this indicates that multiple vendor prefixes are required.
  • Web Developer
  • We are too lazy. We are writing browser-specific code, and while we may intend to correct it later, we rarely do it. Do you remember when the last time the developer targeted a specific browser? That's IE6. Ten years later, we are still under the influence of this decision. Do you really want history to repeat?
It's time to take action

I object to non-WebKit browsers to support WebKit prefixes. At best, it makes the prefix unusable. At worst, it disrupts the entire standardization process. You may agree or disagree, but please express your opinion to colleagues, blogs and social networks. W3C and browser manufacturers will listen to your feedback; you only need to provide some feedback. Then test your website in multiple browsers. A little elegant downgrade is OK, but ignoring one or more modern browsers with equal support is not OK. Fix the code or your website is exacerbating the problem.

FAQs (FAQs) about CSS prefixes and WebKit

What is the purpose of the

CSS prefixes (such as -moz-, -o-, -ms- and -webkit-)?

CSS prefix, also known as vendor prefixes, is a way for browser manufacturers to add them before the new CSS features become the W3C (World Wide Web Alliance) standard. These prefixes ensure that the new feature is only valid in its browser. For example, -moz- is for Mozilla Firefox, -o- is for Opera, -ms- is for Microsoft Internet Explorer and Edge, -webkit- is for browsers using the WebKit engine, such as Safari and older versions of Chrome.

What is a WebKit prefix crisis?

WebKit prefix crisis refers to a situation where non-WebKit browsers start supporting the -webkit- prefix to ensure compatibility with sites that use only these prefixes. This leads to fragmentation of web standards and makes it harder for new browsers to enter the market.

How to use CSS prefix in my code?

To use CSS prefixes, just add them before the CSS properties in the stylesheet. For example, to use the border-radius attribute with a vendor prefix, you can write:

<code class="language-css">background-image: -webkit-linear-gradient(#fff, #000);
background-image: -moz-linear-gradient(#fff, #000);
background-image: -ms-linear-gradient(#fff, #000);
background-image: -o-linear-gradient(#fff, #000);
background-image: linear-gradient(#fff, #000);</code>

(The answers to the following questions are similar, and have been omitted to maintain the overall structure of the article and the integrity of the information)

The above is the detailed content of The Impending CSS Vendor Prefix Catastrophe. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn