This question already has answers here:
List of CSS vendor prefixes?
(3 answers)
Closed 7 years ago.
I have a stylesheet that I made 2 or 3 years ago, when CSS was full of these horrible vendor prefixes for flexbox. I used flexboxes as needed, with the -webkit- prefix for Chrome & Safari.
I just saw on caniuse that flexboxes are now working without prefix on every browsers. Do you know an up-to-date list of CSS properties that still need prefixes?
At that time, vendor prefixes were needed for things like gradients or animations. I wonder if I can remove everything safely, or if some of them are still used.
I was looking for the same a while ago, and ran into this useful website: Should I prefix?. It lists the CSS properties and whether a prefix is still necessary or not.
Next to that, you can always check Can I Use for more info and detail.
+1 to caniuse.com as the best place to see browser prefix info. But your flexbox use case is unique.
Flexbox's implementation has changed a lot of the years, far more than almost any other CSS standard I am aware of. The best way to check which version you are using is to check the display value in your stylesheet.
display: box is the oldest implementation, you probably didn't use this one.
display: flexbox was the transitional state between the old and new flexbox standard. If you are 2-3 years out, you might have used this and will have to change your code to match the new implementation.
display: flex is the modern implementation that has good cross browser support. If you used the prefix version of this, you should be able to safely drop prefixes and get the same results.
CSS Tricks has one of the best shorthands for the modern approach to flexbox: https://css-tricks.com/snippets/css/a-guide-to-flexbox/
Related
This question already has answers here:
Do we have to use non-standard/browser specific CSS vendor prefixes anymore?
(3 answers)
Closed 8 years ago.
I was just wondering to what extent is it still necessary to specify vendor prefixes like 'webkit', 'moz', 'ms' or 'o' in CSS these days.
If I understand correctly, opera switched to webkit, so that drops '-o-', right? IE dropped the need for '-ms-' in IE10, but do you still need it for older versions? And I'm not sure what the story is with '-moz-' right now.
Basically all my CSS3 seems to work just fine across all (up to date) browsers without specifying any prefix, so I was just wondering what is necessary and what isn't necessary as of mid 2014.
EDIT: Basically I'm just wondering does anyone have an up-to-date list of what prefixes are necessary and under what conditions are they necessary.
You can build a filtered list on this web page and show all of the required prefixes.
http://caniuse.com/#comparison
for the most part, you may find things work great in the latest browsers without vendor prefixes. BUT I will point out 3 reasons why you might want to keep using them at least some of the time and then you decide for yourself when you think it is appropriate.
(as was mentioned already) Not everyone is using the most up to date browser.
You won't break anything by using vendor prefixes even in cases when you don't need to, so it can only improve your site and not harm it.
If your using prefixes (etc) from a service like http://www.colorzilla.com/gradient-editor/ then it's a trivial copy-paste and you gain nothing by not using it (except perhaps a smidgen of file space)
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.
This question already has answers here:
Detecting IE version using CSS Capability/Feature Detection
(18 answers)
Closed 5 months ago.
So in my interweb travels of evaluating other programmer's CSS I've noticed a bunch of people using the underscore or asterisk hack that is vendor specific to IE browsers for debugging purposes though W3C does not parse this as valid CSS.
I personally prefer comment conditionals where you can at least defer to IE specific CSS that is valid but I guess the only issue with that would be addition of extra CSS.
So I'm curious about a consensus of what you prefer and the positive or negative implications of each method.
Comment conditonals or IE vendor specific hacks?
PS - Honestly this should be titled do you support IE layout or not :-)
Conditional style sheets are the way to go. The word hack itself implies that you're doing something that you shouldn't. But a few short words on both:
Conditional style sheets
(+) Cleaner CSS code
(+) Easier to manage
(+)Easiey to understand for other developers
(+) CSS validates
(-)More CSS files (thus more server load)
Hacks
(+) Faster (possibly)
(-) Messes up your CSS
(-) CSS doesn't validate
(-) Very unclear for other developers (especially non-experienced one's)
(-) Could cause problems with newer versions of IE
I prefer the conditional comments, because it makes your page still validate. I could imagine, however, that you use the vendor hacks, because you won't need an extra css file, saving a request per page loaded (if not for caching, of course). Then again, the css files are cached, and if you use your conditionals wisely, you can make a separate file per IE version, copying hacks if they are needed for more than one version. That way, you need at most one extra css per page, which is then cached as well, thus minimizing the extra load.
This question already has answers here:
Detecting IE version using CSS Capability/Feature Detection
(18 answers)
Closed 5 months ago.
input,textarea,select{font-family:inherit;font-size:inherit;font-weight:inherit;}
input,textarea,select{*font-size:100%;}
This is from the YUI reset css. What does the * before font-size:100% do?
This is an IE hack. The second line is only correctly parsed and executed by IE 7 and below. See http://www.webdevout.net/css-hacks#unrecommended-asterisk_prefix for more information.
Edit: One remark on using such (invalid!) CSS: please don't. There are plenty of ways of keeping your CSS clean of such mess. You'll never know what behavior IE9 might bring. Better to put these kind of hacks in a separate CSS file which can then be included through conditional comments.
To be more precise: IE6/7 doesn't support font-size: inherit. This hack is supposed to achieve the goal anyway.
I think it's a hack to make that definition only apply to IE 7 or less while being ignored by other browser as an asterisk is not a legal character before an attribute name.
As already told, those are hack to target specific browsers. Marc's suggestion is quiet right, and here's a link to give you an kick start:
http://www.webdevout.net/css-hacks
This question already has answers here:
Detecting IE version using CSS Capability/Feature Detection
(18 answers)
Closed 5 months ago.
I have been looking at a hack to solve a CSS problem I have. I have used one to create a custom rule for Internet Explorer.
margin-top:45px;
*margin-top:0px;
Does this hack apply to all IE browsers? Does this hack appear in any versions of Firefox or Safari?
This applies to IE7 and below. But be aware that this is not valid CSS, and it could break at any time. See here for a more comprehensive list of the various CSS hacks and which browsers they affect.
Although Internet Explorer 7 corrected its behavior when a property name is prefixed with an underscore or a hyphen, other non-alphanumeric character prefixes are treated as they were in IE6. Therefore, if you add a non-alphanumeric character such as an asterisk (*) immediately before a property name, the property will be applied in IE and not in other browsers. Unlike with the hyphen and underscore method, the CSS specification makes no reservations for the asterisk as a prefix, so use of this hack could result in unexpected behavior as the CSS specifications evolve.
I'd strongly recommend reconsidering whether you really need this hack, and if there isn't a better way to do what you want.