Key Takeaways
- There are two new proposals to solve the CSS3 vendor prefix crisis. The first, proposed by Opera’s W3C representative, suggests that when a browser vendor implements a new CSS feature, it should support it, both prefixed and unprefixed, from day one. The second, proposed by François Remy, introduces the “!vendor-draft” value modifier, which allows unprefixed properties from the start with a token explaining which version of the property the CSS was built for.
- The first proposal is a simple solution that would be easy to implement and would ensure most existing stylesheets continue to work. However, it could cause issues if a vendor changes their implementation of a feature, as developers would need to fix their stylesheets accordingly.
- The second proposal is more flexible and addresses the issue of properties evolving over time, but it is more difficult to implement and could take months to appear in browsers. It might also cause confusion in the short term, as vendors would likely support both prefixes and value modifiers.
- Vendors implement experimental CSS3 properties using their own prefix, e.g. -webkit-transform, -moz-transform, -ms-transform, -o-transform.
- Developers can use the technologies today without breaking cross-browser compatibility. Properties can be listed with their prefixed and unprefixed names to ensure they work everywhere.
- Once a property becomes a W3C recommendation, all browser vendors can provide a stable unprefixed property, e.g. transform.
- Optionally, developers can remove the prefixed properties from their stylesheets. However, it’s not strictly necessary if the unprefixed property is defined last and CSS cascade rules apply.
- Vendors implement experimental CSS3 properties using their own prefix. In some cases, vendors promote them as an HTML5 “standard” even if they’re device-specific or never submitted to the W3C.
- Some developers use the proprietary property from a single vendor, e.g. only -webkit-transform. This might be owing to ignorance, laziness or because they’re testing a limited number of devices.
- Once a property becomes a W3C recommendation, all browser vendors can provide a stable unprefixed property, e.g. transform…
- but developers neglect to change their stylesheets. The site looks good in some browsers but worse in others even when they support the standard W3C specification.
- The vendors become concerned and add support for other prefixes into their browser, i.e. Opera implements the -webkit prefix for some properties. The prefix process is broken and, while it’s too early to predict the outcome, the majority of developers consider it to be a bad move.
Option 1: Unprefixed Properties are Supported From Day One
The first proposal comes from Florian Rivoal, Opera’s W3C representative:When a browser vendor implements a new CSS feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade. Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser. If a large amount of content accumulates using the a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.For example, you could use the following transform code in your CSS:
transform: rotate(30deg);
The property would be ignored by all browsers which had not implemented transforms. If there were a difference between two or more implementations, e.g. webkit browsers rotated anti-clockwise by default, you could override the property accordingly, e.g.
transform: rotate(30deg);
-webkit-transform: rotate(-30deg);
It’s a simple solution and easy to implement. Most existing stylesheets would continue to work and prefixed properties would rarely be necessary. In most cases, you would never need to update your CSS again.
However, what would happen if webkit changed rotation to the W3C-approved clockwise direction? Developers would need to fix their stylesheets by removing or rearranging the -webkit-transform: rotate(-30deg);
property. Unfortunately, not everyone uses the same version of the webkit engine at the same time. You could encounter a situation where your site works in Chrome but not in Safari for several months.
Option 2: A New Vendor-Draft Modifier
The second proposal comes from François Remy:
Let’s introduce the “!vendor-draft” value modifier. I propose we use unprefixed properties from start, but with a token explaining which version of the property we built our CSS for:
border-radius: 3px !webkit-draft;
Any browser which is not webkit but implemented border-radius in a way that is compatible with the “webkit draft” can support the declaration. This is different from vendor prefixes: other browsers don’t impersonate webkit, they just acknowledge they support one specific property the way the webkit draft defines it. Browsers which are not compatible with that draft will just ignore the declaration. Browsers that change their implementation of a property are encouraged to iterate their “!vendor-draft” flag (using a version number, if appropriate).
This solves the issue by changing the property value rather than its name (in a similar way to the !important
modifier). Again, the following transform code could be used:
transform: rotate(30deg);
But a default anti-clockwise rotation could be fixed in any browser adhering to a webkit specification:
transform: rotate(30deg);
transform: rotate(-30deg) !webkit-draft;
If a browser subsequently supported the W3C specification, the second property would be ignored.
It would also be possible to implement draft versioning, e.g.
transform: rotate(30deg);
transform: rotate(-30degrees) !webkit-draft;
transform: rotate(-30deg) !webkit-draft-2;
It’s a flexible solution which finally addresses the issue of properties evolving over time.
Unfortunately, it’s more difficult to implement and could take months to appear in browsers even if all vendors agreed today. It may be technically better, but it’s a fundamentally different approach which could break existing stylesheets. In the short term, vendors would probably support both prefixes and value modifiers — and that would lead to confusion.
I like both solutions. From a coding perspective, vendor-draft modifiers seems the most logical option but I doubt it can be considered until vendors “complete” CSS3 and begin work on CSS4.
Supporting unprefixed properties is more practical but will certainly cause versioning issues which couldn’t be fixed in CSS alone. But perhaps that’s the price you pay for using experimental technology?
Do you have a preference for either of these options? Or is it too late to prevent a vendor prefix catastrophe?
Frequently Asked Questions (FAQs) about CSS3 Vendor Prefixes
What is the purpose of CSS3 vendor prefixes?
CSS3 vendor prefixes are used by browser vendors to add new CSS features in a way that won’t affect other browsers that don’t support the new feature yet. They allow developers to use new features before they become standardized, while ensuring that their code will still work in browsers that don’t support the feature. This is particularly useful in the fast-paced world of web development, where new features are constantly being introduced and adopted.
Why am I getting a warning to define the standard property for compatibility?
This warning is usually displayed when you use a vendor-specific CSS property without also defining the standard property. The standard property is used by browsers that don’t recognize the vendor-specific property. By defining both, you ensure that your CSS will work in as many browsers as possible.
How can I fix the warning to define the standard property for compatibility?
To fix this warning, you need to define the standard property alongside the vendor-specific property in your CSS. The standard property should be defined after the vendor-specific property. This ensures that browsers that recognize the standard property will use it, even if they also recognize the vendor-specific property.
What is the ‘appearance’ property in CSS?
The ‘appearance’ property in CSS is used to display an element using a platform-native styling based on the users’ operating system’s theme. It’s often used to style form controls like buttons and input fields.
How can I use the ‘appearance’ property in CSS?
To use the ‘appearance’ property in CSS, you simply define it in your CSS rule set like any other property. However, because it’s not fully standardized, you may need to use vendor prefixes to ensure compatibility with all browsers.
What is the ‘compat.spec.whatwg.org’?
The ‘compat.spec.whatwg.org’ is a website that provides a specification for web compatibility issues, including those related to CSS. It’s a useful resource for web developers who want to ensure their websites work correctly in all browsers.
What is the issue with Microsoft’s Visual Studio Code?
Some users have reported issues with Microsoft’s Visual Studio Code related to CSS vendor prefixes. These issues typically involve the software not recognizing certain vendor prefixes, which can cause problems when writing and testing CSS.
How can I resolve issues with Microsoft’s Visual Studio Code?
To resolve issues with Microsoft’s Visual Studio Code, you may need to update your software to the latest version, or check your settings to ensure that CSS validation is enabled. If you’re still having problems, you may need to contact Microsoft support for further assistance.
What are some common CSS3 vendor prefixes?
Some common CSS3 vendor prefixes include ‘-webkit-‘ for Chrome and Safari, ‘-moz-‘ for Firefox, ‘-o-‘ for Opera, and ‘-ms-‘ for Internet Explorer and Microsoft Edge. These prefixes are used to enable specific CSS features in these browsers.
How can I stay updated on new CSS features and vendor prefixes?
Staying updated on new CSS features and vendor prefixes can be challenging due to the fast-paced nature of web development. However, there are several resources available that can help, including the Mozilla Developer Network (MDN), CSS-Tricks, and various web development blogs and forums.
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.