Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 8 years ago.
Improve this question
What is
-moz-border-radius:
I really have no idea what it is, and I can't find answers on stackoverflow, google, or anywhere. I'm new to web dev and I tried using this and opened up firefox, and there is no real difference. Nor if I open anything else. Also what about
-webkit-border-radius or anything that begins with -webkit
They are vendor prefixed properties, a type of vendor specific extension
They are used to implement experimental versions of features before they are standardised.
An initial dash or underscore is guaranteed never to be used in a
property or keyword by any current or future level of CSS. Thus
typical CSS implementations may not recognize such properties and may
ignore them according to the rules for handling parsing errors.
However, because the initial dash or underscore is part of the
grammar, CSS 2.1 implementers should always be able to use a
CSS-conforming parser, whether or not they support any vendor-specific
extensions.
Authors should avoid vendor-specific extensions
Well anything starting with a - prefix is for a specific browser.
-moz is for firefox
-webkit is for chrome and safari
-o is for opera
-ms is for internet explorer
Border radius is simply just to round the corners of an element. You can set the value to 5px and you will see the difference. Here is a fiddle to show the property: http://jsfiddle.net/Ps4mN/
border-radius: 5px;
It is important to realize browser compatibility, and most import backwards compatibility. Mozilla, in it's past used it's own unique methods of parsing CSS. They also, because of this, were a little behind on new standards in CSS and had to add them later down the road. Adding prefix's to these attributes gave them a way to highlight their 'new' implementation of already released CSS as a 'new and improved' vision of whats already out. See branding.
Because of this, however, it caused a lot of issues with compatibility between developers. Deciding what browsers to develop for, or how to optimize for one specific brand. Which furthered it notoriety as well as it's revenues.
Only recently has some browsers caved into following standards of CSS, such as border-radius:
However, do to this war, which is still being raged, you need to keep in mind a lot of people don't use the browsers you are using. In fact some 25% of all computers online still run Windows XP as well as Internet Exploder (I'm sorry, Internet Explorer or something like that)! And there is no easy way of supporting rounded corners there besides fun workarounds.
Take a look at this article about cross compatible borders for new and old browsers right here. Mind you border-radius: will work in newer version of Mozilla, but not older ones. It will also run on current version of most web standard browsers. Just it's always good to keep some legacy code in for older browsers.
Related
I've been using -webkit and -moz for quite a few times now until this struck me. Aside from defining specific properties based on browsers and certain properties such as break-inside which are not widely supported,
Wouldn't
border-radius: 5px;
makes it shorter for
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px;
There are lots of other features which have been standardized but several examples still utilize the vendor prefixes and what are their purposes for doing so?
The former is supported by latest browsers but can we not assume almost everybody is using almost-latest browsers (especially NOT older versions of IE which certain rules apply)? (Even if people do not update their browsers, they are only left behind by just a few versions considering no one takes out a Nokia-old phone from a chest and started browsing)
Why should we use them? Why should we specify older IE specific rules or just older browser rules?
How much diving into older version would be enough? IE8?
Here are my thoughts - before going into detail I have to say that I am a freak when it comes to browser support.
Up until a couple of years back I was trying to support from IE8 and upwards. The reason behind this logic was that people where "trapped" with Windows XP and IE8 was the latest version supported by Windows XP. By trapped I mean that they were cases like government pcs that were too costly to upgrade.
After Windows 7 has matured enough and Windows XP usage dropped, I tried to support IE9 and upwards. This essentially meant that even after useful properties came out (like flexbox) it took me a long time to migrate - so I was building layouts with tables for best browser support, etc.
However, Javascript Frameworks started dropping support for older browsers (including IE9), then CSS frameworks started dropping support. If you consider it for a while, MS itself has dropped support quite some time back. Major mobile companies drop support for their 2-year devices, so why should we support older browsers? As stated in in other answers, it depends on the audience - imagine the CEO of your best client-company having a laptop with Windows XP or other outdated device - wouldn't matter if anyone else used modern browsers..
So, it came down to a point a couple of years back that you have to select between following the stream and being modern or supporting older devices. I am all up for consistency and uniformity of content, so supporting modern features for a few select browsers and dropping them for others would be a no go for me. Flexbox was one of those properties that pushed me to skip older browser support - it vastly helped me reduced markup - thus making maintenance easier. At the same time, even Bootstrap decided to drop support for older browsers, so, must upgrade to keep pace with the competition.
Needless to say, the problem isn't just IE, but was also Android which took up to v4.4 in order for the stock browser to support specific properties - vh, flexbox wrapping, etc
These said, let me give you a straight answer:
Don't bother with support for IE9 - not even 10. IE10 could be upgraded to 11 on the same OS, so it should be upgraded anyway for security reasons. IE9 is not supported by JS frameworks (eg Ember), lacks CSS3 transitions and other useful properties, like flexbox. Without these your designs would have to take many steps back if you were aiming for design consistency.
As a sidenote IE10 started supporting their own interpretation of flexbox (sorry about all this persistence with flexbox, but it's one of the most useful properties). This means, that in order to support it properly, you would have to write a lot of CSS. Imagine adding 30kb of minified CSS to support just one browser that is fairly uncommon. Is it worth it?
Some webkit browsers (like Opera) might still require vendor-specific prefixes for browser versions released 4 years ago -eg for CSS3 transforms. Tbh more important things are broken on such browsers (Opera included) that I would worry about other stuff more. Personally I only use the -webkit- prefix in select cases (eg flexbox properties that have matured quite lately).
There might be some cases where browser-specific prefixes might come handy even in modern browsers, eg styling a range input or a scrollbar where you have to mess with browser-specific properties to achieve consistency. In such cases specific CSS hacks with vendor prefixes might be required.
As a final note, I would avoid any bleeding-edge properties, eg grid; learn what it does and how it works, but don't use it just yet. You should give a look at https://caniuse.com/ in order to have an idea about CSS properties and browser support.
However, it is up to you to decide and you should make your selection based on the requirements of your project. Two years back I would tell you to support as old as you can... back then you would be able to achieve the same things with different effort, but this is not the case any more. From a point onwards... older browsers can't keep pace.
Well... This is a really big topic so its hard to answer all of it but there are best practices that you should/could follow.
First - Everything is based on YOUR SPECIFIC Audience. Look at your analytics and see what browsers are being used. The data might surprise you especially if you have US Health care or government users. Tools like Stylelint will help you find unsupported rules in your CSS.
Next, It's best practice to utilize feature detection instead of targeting specific browsers. You can implement that by using #supports in conditional code that works like a media query. This way your code is only being applied if the browser can use it. You can do similar detection in javascript using Modernizr.
Finally, I personally recommend using a CSS post processor or build script so you can stop worrying about prefixing (plus it will speed up your development with optional plugins). I tend to like a combo of PostCSS and Prefixfree (several Webpack customizations come with those included) but there are many similar options.
The main benefit is that the library tracks what needs prefixes and what doesn't so you write the non-prefixed version and the rest is taken care of.
There are no hard and fast rules but you should try to support your users' devices instead of pushing for upgrades. The nice thing about the above practices is that your resulting code will be easier to maintain, future proof and targeted to your users.
You should not worry about browsers older than IE 8. These browsers are barely used anymore and they do not support a lot of things. Please, refer to these to websites:
https://imagebox.com/industry/why-your-website-doesnt-look-the-same-in-every-browser/
http://dowebsitesneedtolookexactlythesameineverybrowser.com/.
In terms of the various border-radius commands, make sure to use them all. I've found that if you don't include webkit and mozilla, you lose a lot of traffic. In my website, I usually include every variation of a command so I know for sure my website works. Better to have a large and ugly CSS code than a broken website.
Feel free to comment on this answer if you need more clarification.
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)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 9 years ago.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Improve this question
Can some one provide me some good css example to create breadcrumbs for my asp.net application. Which should support IE 8.
I was trying this link http://www.red-team-design.com/css3-breadcrumbs but it is working in Crome not in IE8. Please someone help me.
Thanks
Gulrej
The code you're trying to use contains several features that are not supported by IE8.
border-radius
If you need rounded corners, this can be made to work using CSS3Pie
box-shadow
Also use CSS3Pie for this.
text-shadow
There is no good way to get this working in IE8. Sorry.
linear-gradient
Also use CSS3Pie for this.
rgba() colours
And again, CSS3Pie for this too, although there are some quirks to watch out for.
::before and ::after
Actually, :before and :after are supported in IE8, but need a single colon, not a double colon.
As you can see from my comments above, most of these features can be made to work with a bit of effort and a few hacks, but by default they are not supported by the browser.
In addition, some other browsers may need vendor prefixes for some of these features. In particular, the gradient styles should be provided with prefixes if you want to support all common browsers.
Your options:
Write your CSS in a way that allow sensible fall-backs -- eg a sensible plain colour background for IE8 that is overridden by the gradient for browsers that support it.
Use a library like CSS3Pie, which attempts to make IE8 more compatible with modern standards. But be aware that if you use it a lot, it has been known to slow IE8 down quite badly.
I am new to web design and I have some problems in my website.
First, it is not a cross-browser compatible website. I want to make it so, but I don't know how to do this. I have read some articles about this, but they have not been any help. Please tell me how I can design a cross-browser website.
Second, I have validated my website's CSS file and gotten these errors:
218 .box Property border-radius doesn't exist in CSS level 2.1 but exists in : 6px 6px
219 .box Property -moz-border-radius doesn't exist : 6px 6px
220 .box Property -webkit-border-radius doesn't exist : 6px 6px.
But I don't know how to solve this either.
http://www.harvestcreativemedia.com
border-radius is a CSS3 property, so if you're validating as CSS2, it will report errors.
-moz-border-radius and -webkit-border-radius are "vendor prefixed" versions of the same property. Vendor prefixes are given by the browser makers to features which they have implemented, but which either are not yet standardised or else their implementation of it is not yet complete. Either way, it allows a site designer to use the feature before it is officially ready.
If you're designing a cross-browser site, you need to consider which browsers to include. For example, do you want to take time making it work in very old versions of browsers (which perhaps no-one is using any more)? You need to decide which older versions to support.
This is relevant to border-radius because current versions of Firefox, Chrome and Safari all support border-radius without the vendor prefix. In fact, the vendor prefix hasn't been required for several versions, particularly for the Webkit browsers. So you may be perfectly justified in dropping those prefixed declarations. You need to check which versions of which browsers require them, and decide whether you want to support those browsers.
Another factor to consider is that until very recently, IE did not support border-radius at all, not even with a vendor prefix. IE9 does support it, but most IE users are still running IE8.
If you want border-radius to work for IE, you will need to do some hacks. The best option at the moment for this is CSS3Pie. Your other option is just to ignore it and leave IE users with square corners. Since this won't affect the usability of your site, you may decide this is the easiest option.
All the browsers and browser versions have their own combination of features which they support. A site like CanIUse.com is invaluable for helping you determine whether or not to use any given feature: it shows which browsers and versions support it, allowing you make an informed decision about whether to use it or not.
Finally, the most important piece of advice I can give you for making a site cross-browser: Test it in all browsers, and all browser versions that you want to support. (don't just assume that if it works in one version of a browser it'll work in other versions - you need to test them all).
To fix a website website cross browser the best way is to start it with this in mind and step by step in development to check each browser for any difference and try to find a cross browser solution. You can achieve it with a finished website also but of course it is much more difficult. If you have specific question you can use stackoverflow.com for help in any programming issue you have.
About the errors you get is because you try to validate a css 3 file with css 2.1 standards. Go at http://jigsaw.w3.org/css-validator/#validate_by_uri+with_options and select at profile level 3 css to validate for css 3.
A good thing to look into is jquery rounded corners. it's rather simple and does almost everything that css3 border-radius does. The downside is creating a border,if you want a 1px border you would have to wrap your target div in another div and set the outer to a padding of 1 px.
here is the site: http://plugins.jquery.com/project/corners
download the zip package to view the demo.
This works on all browsers and IE6+, it also adapts correct css properties if they exist for that browser.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm not talking about tools that let one view a page in combinations of operating systems and browsers like crossbrowsertesting.com but in creating or figuring out the actual CSS.
Use a css reset to level the field across browsers. YUI and Eric Meyer have good ones.
If you guys are still coding for IE6, you're making a mistake.
I use IE7.js to get IE6 to render pages like IE7. IE7 is not perfect, but at least it has some semblance of standards. Since I only have to code for IE7 and FF it makes me 33% more efficient in terms of testing against browsers, something I think makes good business sense.
Link: IE7.js
I write to the standards and both Firefox and IE7 follow a pretty good set in common.
IE6 is dead as far as I am concerned but if I get back into professional web dev I'll probably have to revise that ;)
I try to make a standards-compliant page and do all my testing in Firefox (since it has some excellent development extensions such as Web Developer and Firebug). Then when I'm finished I test the site in IE, then make whatever small changes are necessary. I find that I need to make very few changes, since I don't do anything extraordinarily complex with CSS.
I used to have more problems with Javascript differences, but after I started using Javascript libraries (such as jQuery) I stopped having any serious problems with that.
Padding.
IE6 can get a little hinky when using margin to place elements horizontally on a page. If you size your elements and space the content within using padding, you can make many layouts work great in IE6/7, FF, Safari, and Opera without any hacks. IE5.5 makes things a little stickier because of the broken box model, but I think we can pretty much count it out in most circumstances now.
I try to make a standards-compliant page and do all my testing in Firefox (since it has some excellent development extensions such as Web Developer and Firebug). Then when I'm finished I test the site in IE, then make whatever small changes are necessary. I find that I need to make very few changes, since I don't do anything extraordinarily complex with CSS.
The same here, except I don't tend to need to use Firebug and such. I've only had problems with IE6 recently however - which are solved by simple CSS bypasses:
/* All browsers read: */
html body {
margin: 10px;
}
/* FF, IE7, Op etc. read: */
html > body {
margin: 0;
}
I'm with Eli. Writing against firefox (with firebug installed) makes you have to write "more compatible" code to begin with and then its less of a job later down the line when you come to make it compatible with IE.
Use the site QuirksMode to help you find answers to compatbility information
If it's a brand new project I make it a point to test all html+css changes on all browsers I'm targeting as I make the changes. In the past I tended to focus on my favorite browser and then test with the others after I was done to find that one or more small quirks were present and it was very tedious to pin-point the actual cause. Now I have all browsers open and just go through refreshing each one after each html/css change to make sure the display meets my expectation. When something goes wrong, I know exactly what caused it.
It might seem time-consuming to test on all browsers at once, but in the long-run it actually saves time as you catch the problems at once.