There are some eye-candy experimental CSS like border-radius (rounded corners) and gradients that I wish to use on my page. Unfortunately Internet Explorer does not support any of that yet. At least border-radius is coming on IE9, no word on gradients yet.
So would you recommend just leaving IE alone (most of my users will be on FF or Chrome anyways) or use images to "fix" the presentation for IE? Is it even worth it? Because I know that not only is a pain in the behind but might also break styling on other browsers.
So, to hack or not to hack?
Although this question is a bit subjective, my answer would be not to hack. CSS3 was made to be backwards compatible, and that means it will degrade gracefully if a browser doesn't support it. That for me is the way it should be. I mean, why use CSS3 if you're still planning to hack it anyway? In that case just use the plain old CSS2 tricks like javascript rounded corners or images so you do't have to hack per se.
Terminology quibble: using images to imitate CSS3 features in IE isn’t really hacking. Any visual effect that isn’t directly supported in CSS will need to be implemented in images.
But to answer your question, it depends:
If few enough of your audience use IE, then you can ignore it. Figuring out how few is few enough is up to you/the site owners.
If not:
If the border-radius effects aren’t a key part of the site’s branding, then I’d suggest you just let IE ignore them and use square corners. No-one browses the web with two browsers simultaneously, and no-one cares if your site looks a little bit different in IE 6, as long as the buttons are in the same place and everything works.
If they are a key part of the site’s branding, or your client insists on the site looking the same in IE 6, then you’ve got to achieve the look in IE 6. So, either:
use border-radius, and use conditional comments to include a stylesheet for IE 8 and below with code to imitate the features
don’t bother with border-radius — use the code that works in IE for all browsers. This will avoid you having to maintain two sets of code, but it will mean that all browsers have to download the images you’re using for IE, thus making them perform slightly less well.
I don't think its ever a choice between 'hacking' and not implementing it at all across all browsers, and I'm surprised nobody has mentioned one of the real life-saving 'feature' (I won't consider it a hack, since it is a brilliant method for backward compatibility): Conditional Comments
Not only does it help with annoying IE bugs, it also allows you to define less desirable, but still 100% valid methods for getting certain effects to work, like image gradients with repeat-y instead of CSS3 gradients, or tiled semi-transparent pngs for IE7 and 8. Really, if you want to, IE shouldn't be the one single factor that will limit your ability to experiment with CSS3.
if you do not want images, IE hacks or a seperate stylesheet you could always check out CSS3Pie: http://css3pie.com/. It's not perfect, especially not when you want some gradients & shadows but it can deal with rounded corners pretty easily. There are similar IE behaviors out there but I think this one has the most active development at the moment.
There are hacks and then there are hacks. I interpret a "hack" as being something that exploits a flaw in the browser, such as the descendant selector hack in IE (using >). Those types of things break when the browser is updated.
I don't consider using images to create nice drop shadows or gradients to be a hack. It may not satisfy the requirements that you are doing everything semantically, and you may feel queasy about resorting to using an image for something that an image should not be required for, but the reality is that there's simply no choice - no way to do everything the clean, no-images way - if you want pretty gradients and shadows on the majority of people's browsers (Internet Explorer being that majority).
If you consider the rounded borders or gradients to be just optional eye-candy then by all means don't worry about IE. But if you consider that it actually does make your design look good and you don't want the majority of your users* to miss out, then go for it.
*Depending on your audience, IE may or may not make up a majority of your audience I guess.
That really depends on how important those features are to the look and feel of the site, or rather how important the client and design team feel they are. Additionally its a quation of how much is this going to bloat your markup and CSS - ie. depending on how the effects need to be built in the context of the design how much of a hassle is it going to be?
Normally in this case im in favor of progressive enhancment, ie. come up with something suitable but it doesnt need to be a 1-to-1 to the composite art. Again though, this is a decision you as a developer will ever really be in a position to make on your own (well, unless youre also the designer).
Related
My colleague and I are having a tough time deciding on a best practices approach for ie6, ie7 support for a site we're building. The site is for an older crowd, so not supporting these browsers is out of the question.
At the same time, we're trying to start incorporating modern coding practices into our work so we can get practice and fully understand capabilities. A specific area I want to touch on with you guys is handling fall backs for CSS3 backgrounds.
We have 2 choices here, if we're to use CSS3 backgrounds and not add extraneous wrapping tags for backgrounds:
Use :after, :before etc. pseudo elements for adding multiple backgrounds to elements. (this is the choice we've made for now)
Use CSS3 multiple background specifications
This produces more elegant markup and is certainly a step in the right direction. But what about browsers that don't support these features?
Modernizr.js tells us to check for specific support and then write fallbacks:
Modernizr.load({
test: Modernizr.geolocation,
yep : 'geo.js',
nope: 'geo-polyfill.js'
});
However, we're not given much guidance on the actual fallbacks for specific features. So, in the case of something like CSS3 backgrounds, what would be an effective fallback strategy?
Would we (for example) use jQuery to wrap those extra tags we need (ie btn-container, nav-container, etc.) around nav items, buttons and containers in order to have extra elements to add style attributes to?
About the CSS3 multiple backgounds and/or background gradients I think there is an approach better than those you proposed: CSS3 Pie.
This way you will be able to use all those nice effects also in IE6, 7 and 8 (including also border-radious) without any JavaScript intervention.
1. Fail gracefully. Certain complex elements can be hidden with CSS and revealed upon page-load with JavaScript depending on the browser as one example.
2. Conditional style-sheets or JavaScript fixes. Spend a lot of time fixing each problem in each browser and write a style-sheet just for it. Also, you could try various JavaScripts that claim to bring older browsers into compliance. I've tried this JavaScript but it seemed to conflict with jQuery. CSS Pie is another option to bring rounded corners to older browsers.
3. Ignore older browsers. Do nothing special for older browsers. People on IE6/7 already see the world differently than everyone else. Alternatively, do nothing special for older browsers but actively avoid overly complex functions & features. Optionally, you can add a nifty "upgrade notification" message with little effort.
Would we (for example) use jQuery to wrap those extra tags we need (ie btn-container, nav-container, etc.) around nav items, buttons and containers in order to have extra elements to add style attributes to?
That is certainly one valid fallback approach. Depending on the design and the elements in question, though, you might find that simply supplying the primary background is enough to yield a decent-looking and perfectly functional, though not visually identical, component.
"Supporting" older browsers shouldn't always mean "taking great pains/writing tons of extra code to insure a near visual match." It is difficult but not impossible to ramp up a QA team so that they understand the concept of Progressive Enhancement as it can be applied to aspects of pure visual presentation.
There is, what I think is one of the best uses of CSS over images (the calendar icon) located at: http://chat.meta.stackoverflow.com/chats/transcripts/139?offset=120
But it doesn't work in IE8. Is it possible to convert this to work with IE?
I suppose we could use this jQuery code at: http://www.methvin.com/jquery/jq-corner-demo.html
I guess to summarize, there's no equivalent in IE of the -moz-border-radius property, eh?
You could look into PIE, it claims to bring CSS3 to the IEs:
CSS Level 3 brings with it some
incredibly powerful styling features.
Rounded corners, soft drop shadows,
gradient fills, and so on. These are
the kinds of elements our designer
friends love to use because they make
for attractive sites, but are
difficult and time-consuming to
implement, involving complex sprite
images, extra non-semantic markup,
large JavaScript libraries, and other
lovely hacks.
CSS3 promises to do away with all
that! But as we all know, due to
Internet Explorer’s lack of support
for any of these features, we must
be patient and refrain from using
them, and make do with the same old
tedious techniques for the foreseeable
future.
Or must we?
I'm looking at using it when it's time for my impending IE bugfix marathon.
Microsoft provides a list of links for Rounded Corners Solutions. The links includes great solutions for ie (not so great as border-radius of css3). I am sure you will find something for your needs.
With lots of talk and bickering among developers about how IE breaks standards, is it worth supporting mozilla and webkit CSS?
Examples
-moz-border-radius
-webkit-border-radius
Of course there are many more, but I just want to know everyone's thoughts.
Thanks
For IE, we were (are?) using proprietary features in order to eliminate rendering bugs. At least, in the case of FF and WebKit, we're using them to improve the design. It's progressive enhancement in this case. No one suffers if they have no border-radius feature, but we as developers get more satisfaction for using some CSS3 features. Our designs are more pleasing and W3C gets the feedback it needs in order to improve and then approve the CSS3 draft.
Rounded corners are proposed in the W3C CSS3 working draft. The proprietary extensions in Gecko and WebKit are already likely to conform to the working draft.
Given that rounded corners are purely aesthetic, there's no disadvantage to users with browsers who do not support rounded corners.
When the standard becomes final, it's a simple matter of replacing these proprietary rules with the standardised ones.
If you define -moz-border-radius and -webkit-border-radius, make sure and define -khtml-border-radius (Konqueror), -opera-border-radius, and plain old border-radius as well (for future-proofing purposes).
We tend to use the proprietary methods followed by the CSS3 spec version for when the method becomes more widley supported.
http://www.w3.org/TR/css3-background/#the-border-radius
If necessary (which isn't often) we use JQuery + IE conditional tags to render the same for IE.
http://malsup.com/jquery/corner/
http://www.quirksmode.org/css/condcom.html
It really all depends on your target audience, we wouldn't generally use unsupported CSS on a public facing site as 89% of our users are still using IE 6/7 so it would be useless to most of them.
We currently use it on a few admin systems and some internal systems; mostly to give the design team exposure to the new techniques.
Consider your target audience, browser specs based on analytic's and how necessary it really is first.
I'd support both, IE still has a big chunk of the user space, with Firefox and others (opera, safari etc..) occupying a smaller percentage of the browser market.
using mozilla only stuff might be ok if you can control what your clients are using, by recommending it in some way (if you're writing a web app. with a fixed user base) and even then someone will still insist on using IE.
I know its a pain in the backside supporting both, but I don't think web developers have much choice in the matter :(
In the case of border-radius, I'd say use the Mozilla/Webkit syntax if you don't mind IE/Opera users having squared corners.
If you need everyone to see the same thing, it's best to stick with the old techniques for now. Similarly, any non-universal CSS (say, using #font-face to download a custom symbol font) which is going to break the site for some people should stay out.
There's no harm in implementing CSS3 features so long as they degrade gracefully. So long as rounded corners, or what have you, aren't critical to your layout there's no harm having them there for the people who are running bleeding edge web browsers.
I know from personal experience that having those properties(specifically the corner radius ones) are very much a time-saver. Now of course it would be nice if css would just implement it into itself but right now I think that those properties are very helpful. I see no reason why we shouldn't support them. Mozilla's and Safari/Chrome's engines are just trying to make life a little easier.
I don't think this is a good practice. However you'd like that the site you're working on appears the same on every browser. That's why that's not a solution. It's not professional to have different layouts on different browser.
But if you don't care about that, or your application is based on only that browser - so it's completely fine!
I just noticed that Stack Overflow employs Firefox only CSS to round the corners of the user badges on the front page. It's an interesting idea but what would be the pitfalls and advantages of using Firefox only CSS (aside from the blatantly obvious ones)?
-moz-border-radius:6px;
-webkit-border-radius:6px;
Above: The CSS used to round corners on the Stack Overflow front page.
The main problem would be, as I see it, that your css wouldn't validate. Other than that I see no reason why not to use this type of platform specific features as they don't cause any harm to users whose browsers don't support the features.
The advantages are that it's much easier than using corner images or other tricks. The obvious disadvantage is that your page doesn't render as intended on IE, which is still used by more than half the world's web users.
Overall it's situational; I imagine SO gets a higher than usual proportion of people using Firefox, so the IE issue is not as relevant. And rounded corners are a minor visual improvement, so if some people see it and some don't, it's not that big a deal.
I agree with BeefTurkey.
I might even go further and call it a case of Progressive Enhancement with CSS. To borrow liberally from Understanding Progressive Enhancement, I'd consider rounded corners to be part of the colorful candy coating around the chocolate-covered peanut.
And eventually CSS3 will be ratified and border-radius will be standardized. -moz, -webkit and -ms prefixed styles can be removed and replaced with their standard equivalents. Your CSS will validate and people using browsers that don't support CSS3 will still have a completely acceptable experience with people using browsers that do support CSS3 will get an enhanced experience.
Alternatively you could continue to use the proprietary CSS in addition to any standards to give an enhanced experience to an even larger audience. It would really depend on how much effort maintaining all that CSS requires and how important you feel the enhanced experience is to your audience.
It works in Firefox and the Webkit-based browsers (notably Safari and Chrome). There are no alternatives for IE or Opera.
The main reason to use it is when you want to give rounded corners to elements that display on top of patterned or unpredictable backgrounds, which is not possible otherwise. Normal CSS and images can take care of other situations.
It's also ridiculously easy to implement and surely works for more than half the people on this site.
Pitfalls are of course that it's not supported in other browsers and its not in the W3C specification.
The current implementation is bad (both in firefox and webkit) since they do not share the syntax.
I'm having major rendering issues in Safari with the web application I'm working on. Most of the design is done with divs using absolute positioning. This renders fine on Internet Explorer, Firefox, Chrome, Opera, Netscape, and konqueror. In Safari, it's just a jumbled mess.
Does Safari lack support for absolute positioning of div elements?
What is the best way to trouble shoot and find out what is going on with the safari browser?
UPDATE: I'd like to note I did find the issue, and I would like to thank everyone that gave suggestions. It was the WebKit's "Inspect Element" that gave the most useful information. It appears that their were conflicts with inline styles and styles from the CSS. While safari grabed the styles from the .css file, the rest of the browsers were using the inline styles. i was able to see those conflicts with the information in the tool that was suggested.
The problem may lie somewhere in your JavaScript; one of the most noticeable things about Safari is that it likes to stop executing JavaScript after any errors.
CSS is likely not the issue, since Safari has better standards and CSS support than any other browser out there (alright, I said it.)
Use the built-in Web Inspector in a recent nightly build of WebKit to track down your issues.
1. Safari's support?
Safari is actually a decent browser. If it has its flaws, they aren't any worse than those of any other browser, and they aren't of the class of the old IE browsers, which had very serious problems and lacked even basic support for web standards. To answer you question specifically, yes, it does support absolute positioning.
Safari can certainly render modern X/HTML CSS designs, and since your audience is largely using Safari anyway, you may as well forget the notion of dismissing the browser. It's a good browser, and in any case we're powerless to change it. We simply need to take care of these bugs, whatever they are.
2. How to go about debugging?
Without having a specific example, it's not something anyone can really help you to do. It seems fair to say that you're having some issues controlling css-based layouts. You may have some invalid markup, which in some cases could produce the kind of extreme browser-specific abnormalities you've described.
Start with the basics. Validate your markup and CSS.
Markup Validator
CSS Validator
Make sure you're rendering in standards mode.
Seek out answers to specific questions
If everything validates and you're still having problems, you'll have to track them down one by one. Even if you rebuild the page, piece by piece in Safari in order to see where things begin to unwind, it will be worth it to do. If during this process you really don't understand why a certain behavior exists, you'll at least have a specific question that you can use to poke around for answers. It may be answered already on SO, and if it isn't, you can ask it.