I feel like I'm missing something, Compass provides mixins for everything else that requires browser prefixes. I understand that calc() is widely supported in modern browsers but I can't be the only one that wants to maximize compatibility?
Searching the docs returns nothing:
http://compass-style.org/search/?q=calc
Bourbon has a calc() mixin that only adds -webkit- but it's deprecated and I can't seem to find out why?
http://bourbon.io/docs/#calc
Any help would be appreciated, why is there no calc() mixin in Compass?
If your goal is to include more prefixes to support very old browsers, you should be able to just use calc() in your stylesheet (without the use of a mixin) and Compass will prefix it for you. If you're not getting the prefixes that you want, you need to adjust your desired browser support settings to include the older browsers you wish to support.
Compass Docs - Tuning vendor prefixes:
http://compass-style.org/help/documentation/tuning-vendor-prefixes/
I haven't seen any evidence that Compass ever supported a calc() mixin in the past but if they did, I would assume they removed it due to browser support getting so good for unprefixed native calc(). I'm pretty sure this is why Bourbon removed it from their library.
Have you considered preprocessing your values instead of using calc() at all? That would truly ensure the most compatibility by avoiding situations where either the browser's support for navtive calc() is buggy or totally non-existent.
Related
Looks like both -webkit-animation and -webkit-transition are deprecated.
What's the modern standard for things like a CSS fade-out?
You can't deprecate something that was never part of the standard.
Non-standard: This feature is non-standard and is not on a standards
track. Do not use it on production sites facing the Web: it will not
work for every user. There may also be large incompatibilities between
implementations and the behavior may change in the future.
Vendor prefixes allow you to use experimental features before they are part of the standard (if ever). What you probably want to do is use just animation and transition which are part of the CSS standard now.
Is there any converters (similar to Babel convert ES6 to older ES versions) that can convert CSS3 (e.g. grid, attribute selectors) to older versions of CSS so that development efficiency won't be sacrificed to trade for browser compatibility?
No, because that would require a tool to understand your design intent and then fix it. If it was so easy to create cross browser compatible css by just using a magic tool we would all be using it. Usually I see this done the other way around. Get it to work in all browsers and then hack in fixes for older browsers.
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
Are there any tools out there that can process a CSS file, inserting -webkit equivalents for styles that aren't 100% supported across the board?
I'm using calc() in my CSS which isn't supported across all browsers. Instead I have to use -webkit-calc() for safari etc.
I'd like a tool that will insert -webkit into the CSS for styles that aren't supported 100% across the board, or to be able to specify the target browsers/versions and have the tool work out whether it needs to be inserted or not. Presumably the tool would have to know what styles were supported in which version of which browsers.
You're looking for -prefix-free.
Are you looking for http://lesscss.org/?
The dynamic stylesheet language.
LESS extends CSS with dynamic behavior such as variables, mixins, operations and functions.
LESS runs on both the server-side (with Node.js and Rhino) or client-side (modern browsers only).
[EDIT]
After answering, i found this website http://prefixr.com/index.php where they use a script to reformat css declarations. Maybe you could study this one.
Do we still need to use the browser prefixes for css3 properties, for example -moz-box-shadow, -moz-transition: all 0.3s ease-out; etc?
An important thing to take into consideration is that if you are using Vendor Prefixes, then you are clearly using an experimental feature - not only will this property not work in older versions of the browsers you're targeting, and should thus not be used for anything essential, but they are also subject to change. You really shouldn't use experimental features in a production environment.
To answer your question, if you want to target a browser that only supports a vendor-prefixed version of the CSS property, then yes, you do need to do that. However, if you include a non-vendor-prefixed version of it as well, then all browsers will support that declaration eventually.
Found the entry on someone's blog here on SO and I think it's useful. You can use Javascript to make it compatible for all browsers without writing CSS properties for every single browser
For now, yes. Some properties are not supported by all browsers or in different ways since not all properties are set in the standard.
Css3 info
Yes (at this moment). Since modern browsers do not support the same set of CSS3 effects yet, prefixes are still needed.
If you only want to support the latest browsers, then no. Many companies are still using older versions of Firefox or IE, however. So by dropping the extensions you won't have those features, even if the browser supports them.
One important thing is to make sure you use the 'proper' CSS3 rule after the other rules, in this way the browser will use this rule if and when it becomes available. e.g.:
webkit-border-radius: 6px;
-moz-border-radius:6px;
border-radius:6px;