If I'm already using Dean Edwards's IE7.js for IE6 then do i need to use Whatever:Hover htc and javascript(which we use only for IE6 hover) for Son of Suckerfish menu
Well according to the feature list, IE7.js adds support for the :hover pseudo-selector for all elements in IE6. This means that Whatever:Hover htc is not needed since it provides the same type of functionality.
As far is whether you'll need too keep the Suckerfish JavaScript for your CSS menus or not, I don't know. However, since all of the features needed for CSS menus to work are included with IE7.js, I don't think it would be necessary.
Your best option would be to remove those 2 scripts from your site and see what happens.
There are so many edge cases that eventually these scripts designed to pick up the slack for IE6 will miss some small area that was somehow missed. You'll need to do good QA no matter what option you go with. If you use just IE7.js, at least it will be easy to narrow down bugs to 1 JavaScript file, rather than 2-3.
Related
I'm using turn.js for a page-flip effect, and it doesn't seem to work very well on IE7/IE8 (load up the website in IE7 mode and you can see for yourself).
What's the best way to support old browsers, while keeping the cool page-flip on modern browsers? (Note: I don't need the hot corners at all on IE, as I also have dedicated arrow links which flip the page via Javascript, similar to the turn.js demo.)
Do you have a sample of how you're applying turn.js? As in, do you have a link or how is your page structured? These are a good place to start.
More the the point of gracefully failing when you detect an older browser: There are multiple options, some make more sense than others depending on how much of the site is already done. First off, how does the site look with Javascript disabled completely? I know this isn't the case for IE7/8, but start there. Can it be used with no JS whatsoever? If the answer is "no," think of ways to make that answer "yes" if you can. This is always a good question when thinking about how to handle older browsers.
If you're early in the site's programming, or the content is laid out in a clear way, then you can work around the limitations of older browsers. A practice I try to follow is designing the site without JS or with as little as absolutely possible, and then program in functionality for "whizzing and banging" afterwards.
In your case, I would suggest something along the lines of: if you detect IE7/8 (or mobile browsers that may not be up to snuff, etc) then load in a secondary stylesheet with rules that give your content as much of the feel of the "original" as you can. Next, have the JS for the older browsers show/hide the pages of content instead of page-flipping them - this can be achieved with some divs on the left and right that move the page and then track the current page vs possible pages (are there any before this page? after this page?) in order to show/hide the navigation divs. turn.js just looks like fancy animations for the same thing, so you should be able to say "Hey, this browser is IE 7 or IE 8 - so, let's not initialize turn.js and just turn control over to the page previous and page next divs."
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 need to know what can be the main reasons (apart from the basics like grouping CSS selectors, reducing image size, using image sprite etc.) which makes a website slow on Internet Explorer, because my website works fine on the others like FF, chrome etc.
Is it the huge use of Javascript framework (ie. jQuery, extjs, prototype)?
Is it because of the use of plugins based on JS framework?
Should I use core javascript and remove the use of any js framework?
Should I try to avoid using jQuery(document).ready()? in case of jQuery framework?
Above some of the questions which I know and please answer the questions which I couldn't ask because of lesser knowledge about these.
I need to make my website perform well on IE (6,7,8) also please suggest.
Thanks
It has nothing to do with jQuery. The plugins however are hit or miss, and may not be well tested in IE. I'd use at your own risk.
DOM manipulation is very slow in IE. using appendChild (or insertRow) to add multiple nodes (say, 100+ for a long list) is much slower than building a string and doing one innerHTML.
You also want to be careful how you access nodes. Devs tend to rely upon jQuery too much and search for nodes via their class names, like:
$(".evenRows").hover(doSomething);
IE doesn't have a native way of getting a node by class name, so JQ is looping through the entire document and every single element and checking its class name... which needs to be checked via RegExp because it may look like:
class="evenRows yellow foo bar"
Finally, in spite of its improvements, IE8 is still using an old rendering engine - the same as IE6. Don't go crazy with the animations, and don't expect miracles.
As MSIE has a default-limit of 2 simultaneous connections you should minimize the number of requests that are required for building the page(use css-sprites, merge js-and css-files into a single file)
While you need to speed things up in IE, you can still use Firebug to look for places, that consume resources.
Install Yslow and see what it tells you
Run the site under profiler (Yslow or Firebug have one) and look for a bottleneck
It is very difficult to answer general questions like this, but jQuery is unlikely to be the one slowing everything down, just remember to
Use IDs as selectors wherever possible — they are the fastest, i.e. $('#myid')
Avoid using .class selectors without tagname, i.e. $('div.myclass') can be ten times faster than $('.myclass').
and so on
More tips for using jQuery to achieve better performance.
Earlier versions of IE will, in general, run JavaScript slower than later versions of IE, because there have been advances in JavaScript compilation speed since then.
I'd like to use CSS2 selectors ( parent > child, element:first-child, etc) in my stylesheet but IE6 doesn't seem to recognize those. Is there any plugin (jQuery preferably) that would allow me to use pseudo-selectors freely without worrying about the damned IE6?
UPDATED:
The Super Selectors jQuery plugin scans the page's styles for selectors which aren't supported by all browsers and then adds apropriate classes to elements that those CSS3 selectors are targeting.
You can also look at this CSS3 selectors for IE5/IE8 called ie-css3.js
I'd recommend against using javascript to fix those kind of problems.
The best approach I've found is using conditional comments and create a IE only CSS file, optimized for that hellish browser.
In the long run, the small duplication of work is compensated by the smaller amount of incompatibilities that you'd have to correct between sane browsers and IE.
As a rule, I go with adding classNames to the body tag via conditional comments as my preferred method to deal with cross-browser difficulties.
However, if that's out and if performance is not a concern, you can always give Dean Edwards's excellent IE7.js a try. It will parse and grok your stylesheet, picking out and implementing those unsupported selectors.
Beware that, as your stylesheets increase and size and complexity, the script's (and your site's) performance will suffer in IE6. However, in a lot of cases things should run just fine. Make sure to conditionally comment it in for IE6 and below and you'll be set.
Uhm I'm not sure if anyone has encountered this problem
a brief description is on IE6 any <select> objects get displayed over any other item, even div's... meaning if you have a fancy javascript effect that displays a div that's supposed to be on top of everything (e.g: lightbox, multibox etc..) onclick of a certain element and that div overlaps a <select> your div get's to be displayed as if it's under the <select> [on this case a max and minimum z-index doesn't work ]
I've tried googling and found the iframe shim solution
but I wanted some pretty clean alternatives
or better yet has anyone found a better solution?
since the method using iframes uses around 130mb of ram might slow down poor people's machines
You don't have to hide every select using a loop. All you need is a CSS rule like:
* html .hideSelects select { visibility: hidden; }
And the following JavaScript:
//hide:
document.body.className +=' hideSelects'
//show:
document.body.className = document.body.className.replace(' hideSelects', '');
(Or, you can use your favourite addClass / removeClass implementation).
There is a plugin for jquery called bgiframe that makes the iframe method quite easy to implement.
Personally, as a web developer, I'm to the point where I no longer care about the user experience in IE6. I'll make it render as close to "correct" as possible, and make sure it's functional, but as far as speed goes, too bad. They can upgrade. IE7 (though still quite slow, compared to every other browser) has been out for 2 years (almost to the day!). IE8 is going to be out shortly. Firefox is available for every platform. Safari is also an option (and super fast). Opera is available for most/every platform.
IE6 was released in over 7 years ago. IMHO, there is no reason to still be using it, other than lazy users and incompetent IT departments (or if you're a web developer).
in case anyone is interested, here's some IE shimming code.
* html .shimmed {
_azimuth: expression(
this.shimmed = this.shimmed || 'shimmed:'+this.insertAdjacentHTML('beforeBegin','<iframe style="filter:progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=0);position:absolute;top:0px;left:0px;width:100%;height:100%" frameBorder=0 scrolling=no src="javascript:false;document.write('+"''"+');"></iframe>'),
'inherit');
}
ref: this gist by subtleGradient and this post by Zach Leatherman
Prior to IE7 the drop down list was a "windowed" control meaning that it was rendered as a control directly by Windows rather than the browser synthesizing it. As such, it wasn't possible for it to support z-indexing against other synthesized controls.
In order to appear over a DDL, you must use another windowed control, like IFRAME. You can also use a little known IE-only feature called window.createPopup() which essentially makes a chromeless popup. It has limitations, like unstoppable click-out, but they are actually kinda helpful if you are building a hover menu system.
The simplest and most elegant solution to that annoying IE bug is found at: http://docs.jquery.com/Plugins/bgiframe using jQuery.
I reached that conclusion after trying for 2 days to make it work with WebSphere Portal / Portal Applications where everything is dynamic, including the fly-over menu.
There's also the activex method, which I'm starting to explore. It requires creating conditional code to use an activex control instead of a select box for ie6. There's a demo script showing the technique, which is discussed in more detail here.
Update: it appears that MS Office is required for the active-x control to be on the user's machine. In theory, it might be possible to include that somewhere, somehow, but that's getting a lot messier.
I know many people suggested their own tips, but in my case, I just simply hide select using jquery like the below.
$(':date').dateinput({
format: 'dd/mm/yyyy',
onBeforeShow: function(event) {
$('select').hide();
},
onHide: function(event) {
$('select').show();
}
});