I am running through CSS3 tutorials and I have come across these new requirements. Obviously each browser has different implementations, so you must tell your style sheets to use them. How do you know when a certain browser requires a certain prefix? Is there a single resource that tells you? Is there some sort of magical ultimate include in CSS that will take take of it for you?
On http://caniuse.com it's reported if a CSS property needs the prefix.
Example: http://caniuse.com/#feat=border-radius you can see that old versions of Safari and Android need the -webkit- prefix.
Remember also to place the prefixed properties before the unprefixed one.
Related
How can i know when to use the prefix -webkit-, -moz-, -ms-, -o- in css properties? I see a lot of "inconsistency" in some attributes, in some properties the programmer only puts -moz-, in the other he puts the all 4. Is there a reason for that?
To know what prefixes to use is based on what browsers you want to support. A good place to find out what browser versions require a prefix is caniuse.com.
The variation is due to what browsers other developers have decided to support. If you see more prefixes then the developers (site owner) of the site have decided on a higher/deeper level of support for older browsers. Fewer prefixes will support fewer browsers. As to why? There could be a lot of reasons some are target audience and feature requirements (Web APIs).
You can go the manual route but a lot of developers will use tools like Autoprefixer or a CSS preprocessor like SASS or LESS. These tools give you different ways of defining what prefixes to use.
With something like AutoPrefixer there's an option to list what browsers you want to support and it figures out what prefixes etc. are required to support those browsers based on the non-prefixed version.
With a CSS preprocessor like SASS or LESS you can create a mixin (basically a function) that will add the prefixes you've defined.
I apply a simple rule of thumb: never put a vendor prefix (let user update their browser instead, and avoid non-official/non-yet-finalized CSS rules).
See http://shouldiprefix.com/ if you still want to know which prefixes are "required" (or "worth worrying about").
Last, CSS preprocessors can handle these, but it's often a useless pain to add to your development and release stack (except if you're using other stuff that vendor prefixes, or if you have to deal with old browsers like in companies intranets).
awesome question.
A lot of Programmers use CanIUse to determine if a particular CSS property is supported in all of the browsers they would like to support. If it's not fully-supported in all of the browsers they wish to support, the programmer should use the vendor prefix (i.e. -webkit-).
Example Scenario
Say the programmer wanted to use the Transform property (CanIUse#Transform). See how Android Browser 4.4 & 4.4.4 have yellow warnings in the top right? Hover over them and notice it says 'Supported with -webkit'? This is exactly. when you would add the -webkit- vendor prefix.
I disagree that you have to add them all (although, it really doesn't hurt anything). If you just do a bit of research before you use newer CSS properties, you will have cleaner CSS/SASS/LESS/etc while supporting all of the browser your heart desires. :P
I do think there are awesome tools out there to do this automatically. Xenos mentioned a few.
Best of luck in your CSS endeavors.
These different properties are termed as "vendor prefixes":
-moz- = used for Mozilla Firefox
-ms- = used for Microsoft Internet Explorer
-o- = used for Opera
-webkit- = used for Google Chrome and Apple Safari browsers.
It's always a good approach to use all the vendor prefixes for the css you're applying, in order to address to the browser compatibility of the webpage you're developing.
However, css preprocessors like LESS can handle this thing, if you happen to use them. I personally use LESS to handle all this vendor prefixing stuff and it's really simple. If I weren't using preprocessors, I would still have considered writing vendor prefix css along with the default property name.
It's always a good thing to keep addressing about the compatibility issues well in advance than to run into some and fixing them later.
Try using vendor prefixer tools like:
https://github.com/less/less-plugin-autoprefix
If you want ensure that will work on each browser you need add all of them, some websites dont support old browsers so there is no need to care about browsers which you decide to not support :)
Here is the solution I found, if you are using Visual studio code go to extension and search for css-auto-prefix
For a mobile site, do I really need to specify both prefixed and non-prefixed CSS property names?
For example:
-webkit-background-size:1em; /* absolutely mandatory */
background-size:1em; /* a useless redundancy */
Is there any mobile browser whatsoever that will ignore -webkit properties and only consider the non-prefixed ones? I want to get rid of all non-prefixed attributes to shorten and clear the CSS code.
PS: most phones in third world countries sold with Android 4.1 don't even parse the non-prefixed properties, they still require the -webkit prefix. Another reason to remove the non-prefixed ones.
I don’t know of any resource that tracks support of CSS properties in all mobile browsers (there are a lot of mobile browsers), so it’s difficult to confirm whether there’s any browser that no longer supports the prefixed versions.
I would note that, specifically regarding background-size, it looks like support for the non-prefixed versions came in pretty quickly, and that there aren’t many browsers that required the prefix: http://caniuse.com/#search=background-size.
The current idea is that at some point in the future, support for the prefixed versions of the properties will be dropped. See, for example, this WebKit mailing list post from May 2013:
We will continue to support the prefixed properties for some amount of time, decided on a case-by-case basis.
https://lists.webkit.org/pipermail/webkit-dev/2013-May/024850.html
It may be a long time before this happens, or it may never happen. But as time goes on, the probability of it happening increases, and the number of people still using browsers that require the prefixed versions goes down.
Given that by removing the *non-*prefixed versions you’ll only be removing one line, it doesn’t seem to me like a big gain in shortness or clarity in exchange for the potential future breakage.
I’d suggest initially writing your CSS without the prefixed versions, then looking at the browser stats for your site to see which prefixed versions you really need. For some prefixed features (e.g. gradients), maybe older browsers can live without them.
The redundancy in this case is not useless. Older mobile browsers that don't support the standard background-size but that do support -webkit-background-size will still render. Newer versions of the browser will likely deprecate the -webkit prefixed property but will support both the prefixed property value -webkit-background-size and the non-prefixed standardized property background-size. In this case, the last value specified will be the value used so yes the mobile browser will ignore the -webkit prefixed property in favor of the standardized property.
Be mindful that future browsers will probably remove deprecated values. In this case the prefixed property would no longer be supported and the site's styles would break. To ensure, current and future functionality it is a good idea to use both versions for now. When you no longer need to support older versions of the browser, you should drop the prefixed version in favor of the non-prefixed standardized version. The non-prefixed property is the CSS standard and should never be dropped in favor of the vendor specific prefixed property.
I have a website which I support as far as IE8, no further.
When I first launched the site, I decided to use CSS vendor prefixes for CSSs elements such as border-radius, box-shadow etc. I did this from a complete noob standpoint.
However, is a better approach not to use them and simply let browsers catch up rather than patch up for the sake of uniformity?
No, you shouldn't remove all of them, however you may as well remove the ones which are no longer required.
How can I find out which prefixes are no longer required?
Can I use... is a great resource for checking browser support for various CSS, HTML and JavaScript features. If you perform a search for box-sizing, for instance, it will tell you that all modern browsers have partial support for this and that Firefox requires the -moz- prefix. You can also view all of the CSS support tables on just one page here.
How can I clarify that the prefixes are no longer required?
There are a couple of online resources which display information about browser usage. An example of this is StatCounter. StatCounter offers browser version statistics which can be filtered on time. If we look at the last 3 months, we can guestimate that we should still aim to support Firefox 20+, Chrome 25+, IE 8+ and Safari 5.1+.
Personally, I would just keep your vendor prefixes for now - this still remains professional practice - those browsers who don't need them, will simply ignore them anyway.
Our approach is to drop those which aren't needed.
border-radius
box-shadow
box-sizing (soon? firefox still uses it. Noted by #James Donnelly)
opacity (not a prefix, but no need for the ms-filter thingie)
inline-block (same here, no need for inline+zoom fix)
If you really want to get rid of prefixes, one of the solutions you can try is -prefix-free. It's a javascript plugin which loops through your stylesheets and, according to current browser removes the unused ones.
Although I didn't test it, I think it will definetely lower the performance.
You can also remove prefixes for properties which doesn't have a signifact meaning for functionality and/or user experience, like border-radius, box-shadow etc. You would have to test each element how it behaves without these properties. E.g. you have a button with border-radius: 4px. In a browser which doesn't support border-radius it will simply have rough corners. You must only consider if its worth sacrificing.
Why don't browsers autocorrect CSS3 transitions? The only difference between the Safari/Chrome and Firefox CSS transition is "moz" and "webkit". Surely firefox could just add an autocorrect feature to change every instance of "webkit" in the css to "moz" and the problem would be solved. Or is there something more?
Normally the -moz and -webkit are for CSS selctors are properties that are are specific to the the browser engine. The selector could be unstable, or act differently in each browser as they refine the behavior.
They don't want to "autocorrect" to the other implementation because the other browsers interpretation of the CSS property could be different. It could cause problems about what CSS property should "win" in the event of a conflict. Lastly, it could increase development time for each browser since they would need to figure out what the other browser engine is doing.
In the end what you want is to not use any -* prefixes at all. For that to be possible there needs to be a standard syntax and behavior defined by the, wait for it, CSS standard. Then instead of repeating *-opacity: ... several times with different prefixes, you just write opacity: ... once, like any other CSS declaration.
Vendor specific prefixes are there to allow browser specific behavior regardless of what the current standard says. It allows vendors to implement new features for which no standard exists yet, or to test the implementation of features before committing to it. The end goal is always to implement all features defined by the standard in the way the standard defines it; but you won't get there over night. New features need to be tested as widely as possible to find problems with their implementation or possible problems in the standard itself. This testing happens by making features available through vendor specific prefixes.
When you use a documented standard feature like opacity, it's pretty sure that it works consistently across browsers (*cough*letsforgetabout*cough*IE*cough*forasecond*cough*). When using a vendor specific prefix feature, it means you're using a feature at your own risk which is subject to change and/or may not work consistently (yet). Browser vendors don't touch each others prefixes for a reason, they work towards the standard and eventually make the feature available without prefix.
I have two issues I have ignored so far, but I will really appreciate some light shed onto them.
First: how can I solve differences between Safari, Chrome and Firefox and the various tags that their engines render differently? Should I just write down the right attribute for each in the same css rule? Is there no better way?
Is there a way to separate the CSS sheets for these browsers as I am doing for IE? Is this recommended?
Second: What about CSS3 attributes? Should I just write them again in the same rule after the CSS2 attributes?
Will this cause problems validating the CSS with WC3?
Welcome :)
If you start without the prefixes, you should write the code, generally, with all the semantically appropriate tags, first.
Then, you can decide what your goals are.
If you want W3C compliant CSS files, then you'd need to strip out the vendor specific prefixes by default. This would then allow the latest browsers to pick up the standardised CSS properties if they support them.
This will target less of your market than you might wish, so then you should ask if progressive enhancement is a possibility. If you can reasonably enhance the visuals by using css applied after the page has loaded, such as applying styles with jQuery, MooTools or Prototype libraries AND these libraries are already serving a purpose in your website, then you could apply additional styles with those libraries (and possibly use them in conjunction with Modernizr to determine which elements you may want to additionally support.
However, it's likely that a browser will skip a property it doesn't understand and will render the ones that it does, so I'd suggest that if you code it to W3C Standards first and then add in your additional vendor prefixes 'before' the final (correct) one, then you'll likely have satisfied reasonable measures to be compliant and meet design needs.
Edit:
There is a little bit of confusion between validation results from:
http://validator.w3.org/
and writing valid code related to vendor prefixes to get CSS effects cross-browser:
List of CSS vendor prefixes?
for working on some cross-browser CSS, you might find http://csspie.com, for IE compatibility with some CSS3 properties, useful along with http://www.colorzilla.com/gradient-editor/ for cross-browser gradients and http://cssplease.com for code that gives you alternative vendor prefixes, including different versions of IE support for many different properties.
In terms of validation, here's what W3C says about it: (see comments here: W3 VALID cross browser css gradient,) and official docs here: http://www.w3.org/TR/css3-syntax/#vendor-specific
If you code according to the specifications first and test your code out against that and then add in your vendor prefixes to get the same effects on the browsers you want to support (see progressive enhancement: What is Progressive Enhancement?) then you can be more confident that your code is supporting the appropriate standards, adding value to those with more advanced browsers and still useful for those without additional features (see also WAI III compliance, 508 compliance and others if you want to write a more inclusive site).
Caveat: Web Apps may not always be inclusive or follow these guidelines depending on who the audience is.
If you are using jquery on the site you may want to look into PrefixFree. It's a script that adds the vendor prefixes for you, so for example your put border-radius:6px; in yor css and it reads the browser and adds the appropriate vendor prefix for you via js. I like it cause it keeps my css docs more readable.