I've read the css framework of jquery ui:
http://jqueryui.com/docs/Theming/API
And find some of the css settings is not valid in IE:
.ui-corner-all {
-moz-border-radius-bottomleft:4px;
-moz-border-radius-bottomright:4px;
-moz-border-radius-topleft:4px;
-moz-border-radius-topright:4px;
}
Is there some way to fix this kind of situation?
border-radius just isn't valid IE. You have two options:
Accept that better browsers will give a better result
Forget about modern CSS and use background images to create rounded corners.
See the Wikipedia pages on Progressive enhancement and Graceful degradation.
I find this interesting. I just finished reading a design blog the other day that pointed out that there is definately a false bit of logic going on in web design circles.
That falsehood is that web sites should look the same in all browsers. Let's be honest, IE 6 was released in, what, 2001? It is nearly a decade old. It seems pretty absurd for clients to expect support for a 9 year old system that was deficient and buggy upon release.
I no longer support IE6 on my personal web projects, and this is not at all an uncommon posture to take nowadays. Check any Gawker media blog, you can't even comment if you don't have higher than IE6.
Now, some clients have the need for IE6 compatability. For instance, my workplace is locked to IE6 for enterprisey reasons, and until certain vendors upgrade and allow IE7+, then 6 is what we must use. However, I would not obsess over eye candy for IE6 users. I would encourage them to upgrade if possible, or else just tell them certain features cannot be supported. Especially if we're just talking about cosmetics.
That said, Curvy Corners is a JQuery plugin that looks for those proprietary CSS declarations, and will create image free curved corners in IE6. Be warned that there is a significant ammount of DOM manipulation going on, so it will slow down pages that have a lot of rounded corners.
There are some ways to fake IE into using some of the fancy new CSS3 properties.
This site explains how to do it, if you're only interested in rounded corners, per your example.
This css is not valid for the IE, you will have to use images to create rounded corners instead.
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.
It doesn't take long to realise when using css that certain things are not cross-browser friendly.
For example, when I wanted a semi-transparent png I had to give IE something ridiculous like: filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(...);
I've had problems with positioning and pseudo-selectors etc. as anyone who has played around with css for more than 20 minutes will have encountered.
To solve problems sometimes I start out deciding that I will only do what all the browsers support and support in the same (or at least a fairly similar) way.
Other times I just chuck in conditional comments and give IE it's own stylesheet.
And then on other occasions I simply use css hacks to exclude certain browsers from reading particular bits (like the old "* html {}" or "html>/**/body {}")
So my question is, which is the best option. The first is pretty limiting and you end up developing for what IE6 is capable of doing but the other two feel a bit mucky. So which is the bets in terms of programming practices, rendering efficiency etc.?
Short answer:
Do your best to adhere to standards
Be creative
Stop using hacks and start using conditional comments
In the long run, CSS hacks are just going to pollute your stylesheets and make them more difficult to maintain. Avoid them wherever you can, and use conditional comments with IE-specific stylesheets instead (since most hacks cater to IE). I can guarantee that CCs are much less mucky than hacks, if mucky at all.
You do not have to be limited by IE all the time. There's a concept called progressive enhancement, which means you can make your pages look slightly prettier in modern browsers that support advanced styling, and so on. There's nothing wrong with using CSS3 properties like border-radius today, since browser vendors are working (relatively) quickly to bring support for these to their products.
But then there are clients, which would be a different topic of discussion. I would say, though, strike a balance: educate your clients and be creative, but don't try to do anything too smart or fancy. And please, just avoid CSS hacks unless it's half past 4 in the morning and you're downing can after can of beer and just want to get something done in whatever circumstance.
I always prefer conditional comments with IE fixes. The hacks are not consistent with IE fixing the parsing so the hack doesn't work anymore but then not fixing the thing the hack was compensating. Also, they could mess with other CSS parsers.
I know this could boil down to a philosophical issue, so I don't mean to start a discussion on the topic. But I'm looking for the (or a couple of them) best way to resolve most issues of CSS styling in Internet Explorer 6.
I'm aware of this article on forabeautifulweb.com, and it's recommendation to just feed IE6 users a universal plain IE6 stylesheet with just some basic styling better than the browser defaults. For my application this is not the best.
I'm also aware of the concept of "fixing" IE6's CSS support via Javascript, and I'm sort of a fan of this idea. But I don't know what (if any) the best one is - I know there's several floating around in the wild. This article by Eric Meyer mentions one, but this was written almost 2 years ago, so is there a more standard script to use for this purpose now?
Can anybody point me to one or two such scripts that have been proven to be effective for updating some of IE6's handling of CSS to behave more like a modern browser?
UPDATE: to all the people answering who are trying to convince me not to use JS to fix the problem - I am plugging my ears and humming. :)
Seriously, I'm not asking whether or not to use JS for this. We've already decided we don't need to support IE6 and it is not worth the time for us to try to "debug" our stylesheets just for IE6. This decision is based on our audience and on our site stats for IE6 usage.
As far as all the comments about "what if the user doesn't have JS enabled?" Well in that case a lot of stuff on our site is not going to look right anyway, so that is somewhat of a mute point.
I've already implemented the IE7.js that Gordon suggested, and that is quite sufficient for us to get by in IE6, with very little drawback.
Thank you all just the same for your input.
You can use this library if you want to do it with JavaScript:
IE7.js is a JavaScript library to make Microsoft Internet Explorer behave like a standards-compliant browser. It fixes many HTML and CSS issues and makes transparent PNG work correctly under IE5 and IE6.
There is also CSS3Pie, which adds CSS3 support to browsers:
PIE makes Internet Explorer 6-8 capable of rendering several of the most useful CSS3 decoration features.
Also have a look at Progressive Enhancement and Graceful Degradation for a design philosophy.
Please don't use JavaScript to fix the problem, just add some rules to a stylesheet to fix them...
<link rel="stylesheet" type="text/css" href="normal.css" />
<!--[if IE 6]>
<link rel="stylesheet" type="text/css" href="ie6.css" />
<![endif]-->
In the ie6.css, you just have rules that fudge the styles to work in IE6, you still use your normal stylesheet alongside it, so your site looks the same in IE6 and normal world.
From personal experiance, ie6 can be fixed within a few lines of CSS and a fair bit of inspecting with firebug/developers toolbar.. without the need for conditional comments.
majority of the problems I come accross are padding / margin based and it is down to me not using the best method first time round.
I also find that overflow:hidden fixes its fair share of ie6 bugs too.
i suggest, get ie6 open with the developers toolbar and try and find where the problem lies, and think of a better way to code that section.
Thats just me personally, I use conditional comments as a LAST resort.
Dean Edwards’ ie7.js script (linked by Gordon) is still the state of the art in this area.
As to what’s the best approach, it depends. Dean Edwards’ script fixes a lot of IE CSS bugs, and allows you to use selectors like the multiple class selector and the child selector that aren’t supported at all in IE 6.
If you’re happy that the IE 6 users in your target audience tend to have JavaScript turned on, a library like Dean’s can save you a bunch of time, and allow you to trim down your code by using the selectors that IE 6 doesn’t support.
However, you’ll likely still need an IE 6 stylesheet to deal with issues that Dean’s library doesn’t fix.
The best solution may be to wait for Microsoft to stop supporting IE 6 (like they did with Mac IE 5), because if Microsoft don’t support it, it’s hardly fair for people to expect you to. We‘re currently hoping for 2014 on that score.
Generally, you don't need javascript. You can use plain old CSS. It helps to have a good knowledge of hasLayout though.
More often than not, you can fix IE6 and 7's issues by giving the problem element layout. To do that, give it a fixed height or width, or use the proprietary zoom.
My favoured method of targeting specific versions of IE browser is to use conditional comments to add a <div> as a direct child of <body> which lets me know which version of IE I'm in (like so). That way, I can target IE6 directly:
.IE6 div.fubar {
zoom: 1;
}
The other thing to remember is that it's almost impossible to achieve pixel parity across IE6/7/8/Firefox/Safari/Chrome/Opera, so if some things don't look quite right in a browser that's nearly ten years old, you don't always need to worry about it.
Position is everything has some useful tips on IE bugs, too.
Don't use javascript if you can avoid it - you are not guaranteed that your users have JS activated (as already mentioned) and you actually don't need it.
To get rid of many problems of different interpretations from browsers (not just IE) user a css-reset stylesheet. There are many floating around.
Even better yet, use a CSS framework which will remove many many problems between different browsers and will come with many helpful classes to solve standard issues.
I for one love YAML (http://www.yaml.de/en/home.html), then there's Blueprint (http://www.blueprintcss.org/) and probably a few others. Believe me - once you used a CSS Framework you will never want to go back.
jQuery and its plugins work best for IE6 issues. Give it a try!
Like every web developer, I usually curse the creators of IE6 with foul and untimely deaths at least once a week. Yet my company requires me to keep supporting that most-hated of browsers.
My problem today has been wanting to first use a wildcard in my CSS and then trying to use the "inherit" property instead. Neither of which are supported by IE7-.
I really, REALLY want to have good, well-structured, properly-inheriting CSS (object-oriented CSS, if you like that buzzword) but I have that sinking feeling in the pit of my stomach that sooner or later, it's going to have to be custom-purpose and location-based classes.
This poses the question: given how utterly awful IE is at handling many CSS concepts, is it impossible to adequately support this browser at the same time as having a well-structured CSS document?
Just to clarify: I'm aware that there are plenty of ways (some legitimate, some less so) to get around the bugs and shortcomings found in IE6 and 7. What I'm really asking is "if you want to have a single, well-written stylesheet that inherits correctly, must you choose between that and having a consistent look across all browsers?". Hope that makes sense.
In other words, should I stick to my principles and code a good style sheet or should I accept that IE6 still enjoys a horribly high (20% on last count) market share and bring myself to support it? Or is there some happy medium that allows me to minimise the frankenstein surgery on my HTML and CSS while still achieving some respectable results in IE?
To be fair, you can't blame it all on IE (though Microsoft certainly is by far the worst transgressor). Part of the problem with such large & rapidly-evolving standards is that it's too much of a moving target to be perfectly implemented in a timely fashion. Unfortunately, the release cycles of web browsers do not coincide with the release of new web specifications. So all browser developers can do is try to implement as many features as they can from the latest W3C recommendations, selecting what they think will be the most commonly used features to implement first.
However, things are clearly improving, and it is possible to support IE6/7 and still use proper CSS design. It's just... difficult. Take a look at this comparison of layout engines & CSS support. If you look at the overall trend, you'll see that most browsers (even IE) do tend to comply with established standards in the long-run, it just takes some browsers longer than others to implement a standard after its introduction.
And sometimes it's not that one browser is "less" standards-compliant than another. With new standards the problem is often that different development teams chose to adopt different parts of the new specification. So even though CSS3 is already beginning to be implemented by most browsers, we'll probably have to wait until CSS4 is published before seeing consistent support across all major rendering engines. And if you try to use the latest CSS3 features right now, you'll have a hard time establishing compatibility across all major browsers. But if you're using features introduced in CSS1, it's no problem at all.
Therefore, the only option--aside from using ugly CSS hacks--is to stick with well-established older specifications. Then the problem is no longer trying to conform to web standards while supporting a particular browser. Instead the problem simply becomes trying to resist the urge to use the latest & greatest CSS features.
Aside from that, the only permanent solution I see to this recurring situation is for the W3C to prioritize different parts of newly introduced specifications so that the new features can be implemented in discrete phases synchronized across all the major browsers. So, for instance, grammar rules might be given the highest priority along with a set deadline for its implementation. After that would come the second phase, which could be element & attribute selectors, and so on and so forth.
This would require a tremendous level of cooperation between the W3C and development teams, but it would be worth it. After all, it does users and web developers no good for IE to implement one subset of features from CSS3 while Firefox implements a different subset and the Webkit browsers yet another subset. A "standard" is no good until it's actually standardized across all the major rendering platforms. It's better for each browser to support fewer new features but have them all be the same features, than for them to separately introduce a ton of their own features that aren't universally supported.
Not at all - you can compensate for IE's shortcomings with conditional comments and an IE specific stylesheet, while serving your 'nice' stylesheet to other browsers.
Something else which I find helps is to use a CSS reset. While this isn't going to resolve all of IE's issues, it does give you a good baseline to work from.
The most anoying IE6 feature is it's box model handling. You should stick to margin instead when positioning boxes, and try to use relative font sizes to allow font resizing on IE. The rest of the quirks are well documented.
Using conditional comments is the cleanest way of having both a clean style sheet for well behaving browsers, and still using being beautiful on IE. This is what I use, only needing 1 css file of a few lines to repair my sites look and feel.
The dark path of crossbrowser consistent look & feel are css hacks, but I strongly discourage it's use, specialy now that for some time we'll have to target three different IE (6, 7 & 8)
Normally, if you get the style to work in both FF and Chrome/Safari, IE is only a few corrections away of being correct.
There is a great site Position Is Everything that details how FF, IE and Safari conform to standard CSS. At the site you will find most of the workarounds / cures for IE that will alleviate the need for you to write so much conditional code for your CSS.
You'll also want to check out A List Apart for more on CSS and IE. There are also great articles on tableless layout with CSS, handling the height bug in IE, etc. Good luck - IE 6 really sucks when it comes CSS.
Certainly not. If you ensure that they render the page in "standards" mode as opposed to "quirks" mode many of the common IE CSS issues are resolved. To do this you must provide a valid doctype statement at the top of the page, such as
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
As others have pointed out, another good idea is to start off your stylesheet with a snippet that removes all paddings and margins like so:
*,html {
margin: 0;
padding: 0;
}
Finally, one common problem with CSS based layouts in IE is that clearing of floats doesn't happen when you'd expect. This is to do with a hidden object property in IE called "hasLayout"; only objects that "have layout" will correctly wrap around and enclose floated child objects. It is easy to ensure that your containers "have layout" simply by specifying at least one dimension for them:
height: 1%;
width: 100%;
zoom: 1;
I do not personally use conditional IE stylesheets except for one single thing: to replace PNG backgrounds with GIFs in IE < 7 - there is nothing wrong with using them, I just find it unnescessarily complicates things when you have to define the appearance of the same object in two different places. With the three tips above and a bit of patience you should be able to create CSS based layouts using a single stylesheet that render just as well in IE 6/7 as they do in Mozilla/Webkit.
Happy coding!
IE 6 really does limit what we can do.
It’s the lack of support for advanced selectors (and inherit — IE 7 doesn’t support that either) that gets me. Just having the child selector and attribute selectors would be nice, that’d really cut down the amount of code we have to write and maintain. You can only work around the lack of support for them by duplicating your styles, so you just end up having to code as if they didn’t exist.
Sigh.
Only follow online CSS tutorials that is rendered correctly with IE6 and Chrome (or Webkit). If it looks right in both, it likely looks right in (almost) all browsers.
As of right now I believe only Firefox support -moz-border-radius property. I am surprised that twitter uses it.
Are any other browsers planning on supporting this or does CSS3 have something like this in the works?
Edit: I also found -webkit-border-top-left-radius and then the CSS3 version
So when is CSS3 coming out?
CSS3 has border-radius.
For now, Mozilla- and WebKit-based browsers have experimental support, -moz-border-radius and -webkit-border-radius. It's not bad to use them now, as long as you understand they are temporary measures until they are properly implemented. I would expect it's not too long before you see full support for border-radius in Mozilla, Firefox and IE. (Well, hopefully IE.)
Update: as of August 2016, with border-radius being natively available in all native desktop browsers (and most mobile browsers, not to mention), the stringency of using -moz-border-radius, -webkit-border-radius and similar is being slowly relaxed.
Because the CSS3 spec hasn't been finalised, Mozilla and Webkit decided to implement their own method of rounded corners, doing it in the correct way, by adding the vendor-specific tag at the front.
This is done so that when the CSS3 is FINALLY released, should they change how border-radius is supposed to work (eg: the order of the parameters), then none of the sites using the vendor-specific methods will be broken. Mozilla and WebKit can just go ahead and implement the W3C style and developers can slowly move over to that.
It's not too surprising that you're seeing some websites using it, especially for something like rounded corners where it's not going to make a massive difference to the user experience. And I mean, it's just IE users who are missing out, and they deserve everything they get.
It bugs me when people talk about CSS3 coming out. It's not a complete spec like the previous ones. It has been broken up into separate modules that may increment their versions independently.
So Selectors Level 4 may make Recommendation before CSS Backgrounds and Borders Level 3 does.
So, will CSS3 arrive? Eventually, but not all a once. So don't wait for it, start using it now (where applicable).
CSS3 has something like this in the works.
According to this, IE 8 will not support border-radius.
Any CSS property that starts with a dash (e.g. -moz, -webkit) is a browser-specific property.
This allows browser vendors to experiment with new CSS properties. Doing so is a common part of the process for writing new CSS specs, to allow web developers to see how the properties work and raise issues.
Hence you’ll find a lot of CSS 3 properties, like border-radius currently implemented in some browsers with vendor-specific extensions.
There’s nothing particularly wrong with using these on production sites, as long as you’re aware they’ll only work in the one browser.
CSS 3 should be out any decade now :)
Browser-based properties are only meant for interim fixes for that particular browser, and are supposed to be deprecated when either the W3C adopts them into CSS, or not. I wouldn't rely on them to be cross-browser or even be kept for the particular browser.