i have built a beautiful website that works very fast in all of the latest browsers but many of the users are forced to use ie6. If i can't get around this problem. Is there anything to do to optimize some of the inefficiencies of ie6 when building my site to lessen the pain.? its an asp.net mvc site with heavy use of jquery.
You don't mention any specific issues with the site, but you can pass scripts, styles, even content just to IE6 by using conditional comments.
<!--[if IE 6]>
IE6 only stuff goes here
<![endif]-->
Apart from that, learn the many, many quirks of IE6 and the fixes for these problems. There is certainly plenty of resources on this out there, we've had to deal with it for quite some time!
If you need help with something specific, perhaps edit your question with further details.
Retroactively, i don't know if there's an exact answer other than troubleshooting the problems one at a time. The correct way would be to code proactively for all browsers until IE6 is finally put to rest as it should be :)
jQuery works pretty well with IE6, so you should be ok on that front. You will most likely run into some CSS quirks, but once you learn what to avoid it's really not bad coding for IE6. The main thing I keep running into is when you float something, you always need to put a display type of relative or absolute on it otherwise it will just disappear from the screen in many cases.
First of all, it should be considered in the beginning of a project whether IE6 needs to be supported or not. Designing for it requires a bit different approach - some things just tend to break down. My advice is you should probably make the experience on IE6 only "sufficient" and just make sure the site can be used as intended. Making it look flashy is just not going to work with any reasonable amount of effort.
Is Chrome frame an option? It could be positioned as a something similar to java which less people have a problem with.
http://code.google.com/chrome/chromeframe/
Related
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Cross-browser CSS
Ok, so the question might be somehow a little confusing.
I'm gonna try to put it in a much simpler way so "you" can understand my
point of view.
All browsers are different. Every browser interprets the CSS rules
diferent, which drives to different results. Some times the results are good
other times and much often results are totaly unexpected. The case of IE can lead to the worst scenario possible!
Many often, developers are forced to detect the browser to apply a
specific css style!
This can be achieved with javascript support. Anyhow, some people say
that this method it's not enough to prevent disasters... others
think that the best way to deal with this problem it's to rely on
Object detection instead.
Well, I don't know which one is best...
Please feel free to give you opinion based on examples.
As always, thank you.
UPDATE
The case of IE can be very simple to deal with conditional statments but, safari can't be treated the same way! So I leave this link: http://quirksmode.org/js/support.html to clarify my point of view...
I personally don't believe in browsers sensing for CSS. In my opinion, it's a waste of time. It takes extra time to code, extra time to change, and creates an extra layer of headaches. Plus, when do you stop? AOL browser? Some random flavor of the day for a 15 year old version of linux used by 12 people in Iceland?
I also don't do hacks. Some will make their way in via Jquery's CSS or outside code I incorporate, but I don't personally write them. They don't validate, so they weren't meant to be in my mind. Javascript tricks are nice, but for styling I don't rely on them because they're not 100% reliable. If it's not gracefully degradable, it's not an option.
So, to combat the issues I do the following:
Clean, valid CSS
Reset (some of the time)
Grids (often, via Blueprint or 960.gs)
Dead reckoning of elements. This means avoiding the graphic designer mentality of 100% pixel perfection and designing for elements that can change as the web often does. Forget box model for a minute, fonts render differently too, and that will never change.
I avoid absolute elements like the plague. 99.5% of everything can be done relative if you try.
Cutting Edge...not bleeding edge. The cool new hacks are nice, but they aren't supported yet. So, they are last case scenario for me. It HAS to be this way for my large (well paying) corporate clients.
Intelligent design. Let's face it folks, if you design FOR THE WEB, you'll have an easier time making it so. If a designer converts a print design for the web, it's nearly always going to have --issues--. Can they be worked through? Sure, and it's profitable for us. But intelligent design in the first place solves all sorts of issues.
The name of the game is progressive enhancement, folks. If IE doesn't support rounded corners, they get square corners. After all, the standard rounded corners are valid HTML. If they have a problem with it, they can upgrade or change. Sound harsh? Sure it is. But we have a very clear standard (set by w3c) to maintain, and it's our job to do it. It's the only way to hit the mark on this moving target.
Two things. First, make sure you include a DOCTYPE. If you don't, browsers will default to quirks mode, and their interpretation of styles will be different. This way, you can minimize the different CSS interpretations of your page.
Second, I'll point out that IE (the big offender, in my experience) supports conditional comments, so you can include styles for specific IE versions like this:
<!--[if lt IE 8]>
<link rel="stylesheet" href="iehacks.css" type="text/css" />
<![endif]-->
All browsers are different. Every
browser interprets the CSS rules
diferent, which drives to different
results. Some times the results are
good other times and much often
results are totaly unexpected. The
case of IE can lead to the worst
scenario possible!
You should be able provide the exact same CSS to all browsers (I'm talking about CSS 2.1 here) and get consistent display, with the exception of IE6 and IE7 (and that's because they have too many bugs).
For those browsers, a common practise is to include a new stylesheet using conditional comments with specific fixes:
<link href="forAllBrowers.css" rel="stylesheet" type="text/css" />
<!--[if IE 7]><link href="ie7.css" rel="stylesheet" type="text/css" /><![endif]-->
<!--[if IE 6]><link href="ie6.css" rel="stylesheet" type="text/css" /><![endif]-->
The other scenario is when you're willingly using things that are only available in newer browsers.
In those cases, it's a good idea to use Modernizr to detect support for the shiny new feature you're using.
That way, you can provide a sane fallback for browsers which do not support the feature.
For singling out IE, particularly IE7 and 6 you can use conditional comments to load IE specific styles and or stylesheets.
Most bugs do have viable workarounds. Well formed and standards compliant html/css should display properly in all modern browsers.
IE Conditional Styles can help you work around imperfections in Internet Explorer.
Excluding JavaScript, there's basically two solutions to this problem. You can mix and match both.
The first solution is to determine the user's browser based on the header in the HTTP request. (Different platforms will allow you to do this in different ways - for example in ASP.NET, the Request object contains this information). You can then serve different physical CSS files depending on the user's browser.
The second way is to use a single CSS file that contains different rules for different browsers. The right rules are applied to the right browsers using various browser-specific hacks. Effectively, this means using CSS rules that only certain browsers understand. More information on this technique can be found here.
Well, for inline CSS, you can do specific hacks such as:
.myclass {
height: 100px; /* all browsers */
#height: 100px; /* MSIE browsers */
_height: 100px; /* MSIE >= v6.0 */
}
Alternatively, you can use comment style conditions within the page and include optional style sheets:
<!--[if gt IE 5]>
<style type="text/css">
.mystyle { height: 100px; }
</style>
<![endif]-->
Actually all current, modern browsers interpret CSS very similarly based on the standards. It's usally only IE (6, 7, 8) that make problems, especially if your HTML documents don't trigger Standards-Mode, thus:
Write your pages based on current HTML and CSS standards with a DOCTYPE.
For support of older IE, give them separate style sheets using Conditional Comments.
If there are differences between other browsers, there are usually workarounds. Ask abotu specific problems here or in your favorite CSS forum/group/list.
Just one word: Modernizr.
You should never change the styles based on user's browser, but based on the browser's resource allowed or not.
I recently encountered a printing issue in Firefox that eventually turned out to be a problem with the fieldset tag we wrapped the entire page in. (Bugzilla: Bug 471015) All browsers have their own rendering quirks and issues, but it can be very hard to know what's causing different behaviors. Sure, you can Google, but that's often taking a shot in the dark about what you think is causing the problem. It also doesn't stop you from having to sort through multiple complains about the same behavior before you find someone who has the issue your looking for. Are there any websites out there that let you search for rendering behavior issues by browser version, browser function, css tag, or html tag?
I've seen this SO Question, Wanted: Resource for documented Cross-Browser differences, but I'd like to find something more detailed that includes browser bugs.
http://www.positioniseverything.net/explorer.html
http://www.positioniseverything.net/
http://css-discuss.incutio.com/wiki/Main_Page#Bugs
http://www.webdevout.net/browser-support-css
http://www.webdevout.net/
http://caniuse.com/
Internet Explorer CSS Bugs
Try http://www.quirksmode.org/
Is there any particular reason that it isn't in any of the the specs?
It seems to be supported in all browsers, (although I'll admit it doesn't work right in all of them...since you have to use libraries like innerXHTML to get it to work right thanks to Internet Explorer.
Is innerHTML in danger of disappearing from forthcoming versions of browsers? If not shouldn't they just add it already?
I'm marking this community wiki as I know I'm gonna take a beating on my rep for this...but I just wondered why...
http://dev.w3.org/html5/spec/Overview.html#innerhtml
There's absolutely no way it's in danger, thousands of applications rely on it and doing so would be a horrible idea.
I'll admit it doesn't work right in all of them...since you have to use libraries like innerXHTML to get it to work right thanks to Internet Explorer.
IE invented innerHTML; you can't really expect it to work any better than it does there.
Is there any particular reason that it isn't in any of the the specs?
It's proposed for HTML5, for what it's worth. There is certainly no danger of it disappearing in the future, though you should continue to use it only for the simple cases where you are writing straight ‘block’ or ‘inline’ element content. Special cases like tables and selects are going to continue to be troublesome.
IE, being the inventor of dynamically modifying the content has gone with it all the way - other browsers didn't!
Passing the string as innerHTML means that the string will get through a normalization process before it gets passed to the element. Meaning it will get transformed fom a string into a proper html parsing content.
Firefox implemented it wrongly. It doesn't distinguish between html:innerHTML and html:innerText and plain string:text. The difference is literally obvious for IE, but not for FF. Hence the difference in handling situations and the confusion of FF only coders when they go back to the master.
I just found out about ie7-js ;
IE7 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.
http://code.google.com/p/ie7-js/
It looks like it's really good, but is it really working (the current issue list looks quite scary)? Have you already worked using this with success?
Another question is how slow the script will make the website in IE ?
In static pages it works pretty well. If you designed a couple of static html pages using modern browsers and standards and want it to be shown correctly in IE6 and 7 this script is gonna help you.
But, and it's a big but, if you add a little javascript to the recipe, this method shows its weaknesses. Anything added later to them DOM or any event triggered afterwards will NOT be affected by this script.
That's it. my one line recommendation is if you have simple and light pages use it. otherwise try solve your problems by looking at the roots!
I think the best answer is: try it on your website and see if it works for your particular code. If it works, and doesn't impact the speed, great, you're done. If it doesn't work, then you're going to have to spend the time to make your site work in IE.
I'm trying to create web applications that use JavaScript. I'd like to be able to use animation in these applications. I've tried to use basic JavaScript, but I've decided that the best thing to do is to use a library (such as YUI or jQuery).
I'm running into a problem. On Safari, when I run animation scripts, the animation is very chunky, very blocky. This happens with YUI as well as basic JavaScript. Why does this happen? Are there any good libraries that don't create this problem in Safari, but are also good for Internet Explorer and Firefox (and, hopefully, Opera)?
I have found MooTools to be pretty slick for animations, just a little smoother than jQuery.
I generally prefer jQuery, which I find to be a little more intuitive (in my head anyway), but I would use MooTools if slick animation is the most important requirement.
JQuery has animation, but I don't know what it is like on a Mac (I don't have a mac). If things are going slow, then you are probably making the animations too complicated. Remember, JavaScript is a slow language, and DOM is not designed for animation, so try to limit yourself with respect to the number of animations at the same time. Always ask if the animation is really necessary.
Well, for starters you could use CSS Transformations if the application is Safari-specific. Otherwise JQuery got some built in animations and a big community behind it (and thus, a large plugin repository).
You can download some sample code and check locally to make sure that things are supposed to work. For example, you can get the source code for B&K's jQuery book at http://www.manning.com/bibeault/ (check out the source link) and try out the samples for Chapter 5. If those pages work (locally) for you on Safari, then at least you know your basic environment is sane.
I'm having similar problems, and I suspect there are Safari bugs that jQuery is tripping over. But I haven't yet figured out whether it's me writing sloppy code (with FF perhaps being more forgiving than Safari), or if it's Safari, or if it's jQuery. I'll post more if I get any wiser.
Strange, WebKit (the JavaScript engine that Safari uses) is supposed to be pretty fast. Make sure that you have the latest version, there have been great progress for the JavaScript engines in the Safari and Firefox releases in recent time. Also, I think Dojo and MooTools have faster animations than jQuery, at least in my experience.