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.
Related
This may be a very basic question, but is it possible to post a jsfiddle that captures a Rails environment, the js, css, and HTML that is generating a nagging problem? I posted another SO question here: Unable to float a twitter bootstrap navbar item right with either class=pull-right or float:right
... and it was suggested I post something to jsfiddle. Honestly, I'm just completely in the dark as to how I might gather the css, js, and HTML in a way that can be copy-pasted into jsfiddle. Is there some slick way to pull the 4 necessary components together?
I am mostly interested in being being able to share and debug code that pertains to display and layout.
Many thanks in advance.
Sites like jsfiddle and jsbin are useful as testbeds for various issues involving HTML, CSS, and JavaScript. A good workflow for using them might be as follows:
Before going to one of those sites, use a browser debugger (Firebug, the Chrome debugger, or even the debugger in modern versions of IE if you must) to figure out the mechanics of the issue. Are you seeing unexpected JavaScript behavior? Weird layout? Whatever the problem, see if you can narrow the focus as much as possible.
Now, go to one of the workbench sites (make an account for yourself too; it helps to be able to find old experiments) and start trying to reproduce the problem. Start as simply as possible and work up. It can be hard and frustrating, but in my experience even the process of trying to figure out an isolating test case can itself lead to enlightenment :-)
If you do manage to isolate a behavior that you don't understand or can't explain or whatever, you can then save the test case (jsfiddle has "Save" and "Update" buttons; jsbin seems to magically save things automatically) and then post the URL here (or anyplace else). If you do post here, it's a good idea to copy the relevant code from your test case directly into your question.
I use both of those sites (and there may be more of them out there). The jsbin site gives you a little more control over your page, and provides a way to see your page outside of an <iframe>. That's kind-of important if you're testing for mobile applications. Otherwise they're both great resources.
Oh, and both sites let you import various popular libraries via simple configuration tools. That's really handy for tracking bugs that you think may have been introduced by a library version change (rare, but really freaky when it happens).
I have created lots of buttons for a large number of pages (usually 5-10 in a row at the bottom of each page inside a table cell) using input type="button" name="..." value="..." onclick="some javascript event handler" etc, basically to link to other pages of the same group. All these pages are ultimately linked from an iframe tag on a single page. The buttons are working fine offline on my PC at least. But, now I've suddenly realized that I haven't used any 'form' tag for these buttons.
So my question is, is this 'form' tag really necessary? Will there by any problem after I upload? I would prefer not to add the form tag now to so many pages if it's not really necessary, because that's going to be a real drag. But, I don't want to suffer afterwards either.
No it is not necessary as long as you are not doing any Get/Post and grouping form elements together. They should work completely fine without a form tag.
There are two issues to be concerened with:
Is it valid HTML?
Turns out that it is valid HTML (see Is <input> well formed without a <form>?), so you are on the safe side here.
Will all common browsers accept it?
After googling around I haven't seen any information on problems wih this use of Input tags. That suggests that all common browsers accept this valid HTML (as they should). When developing any website that is accessible to the general public I would always do a manual cross-browser check to discover any abnormalities certain browsers may habe with my site.
Problem is that you most likely won't be able to tell from looking at your server logs whether certain browsers have a problem with your HTML. It may just not work on IE 6 and you would never be able to find unless a disgruntled customer calls up and informs you.
If this is a generally accessible website get some stats on the most commonly used browsers, decide which ones you want to support, and verify that the website is behaving properly on thiee browsers. This is a pain in the ass, but there is no way I know of to get around that. Browsers may not react to valid HTML properly.
As a rule of thumb, Firefox, Chrome, and Safari unsually behave well, and because of auto-updates most people will have a very recent version installed. If the latest version of the browser works I wouldn't be too concerned that users with some older version will have trouble.
The real test is always Internet Explorer. While version 8 and 9 are pretty standards-compliant, IE 7 certainly needs checking. IE 6 is the worst offender for unusual behavior. It was introduced in 2002, but today still 6% of the population use it! Most of this comes from cracked copies of Windows XP in China, but it is also used quite a lot in corporate networks, where OS and browsers are centrally deployed, and administrators have not managed to progress since early 2000.
In conclusion: Your code is unusual but ok, test it manually on the browsers you expect.
EDIT by Phrogz: This appears to be a problem with the framerate of jQuery animation when this particular complex CSS is applied. See the video at the bottom for an example of the problem.
I think is hard to copy and paste the whole code here. So I've create a fiddle for this.
To be honest, CSS is not so important on this (I putted it for have a decent grid). I also removed many functions from my original version, in fact they aren't so important.
The only one that works is by clicking on the buttons + Tracks (which call addTrack()) that adds a new track/line in the grid. Tested on Chrome, IE, and Firefox < 4 version. There isn't much problem. It's really rapid and fluid.
The problem is on Firefox 4 or 5. It's really slow to add the new track/line. It's fast like a turtle.
What the function done is to clone (copy with handler) an element trackOn, which is already written in a hidden field (tracklistOff) and add it (insertAfter) applying a fade effect. (thats means a new line in the grid).
Why this behaviour on Firefox? Too many elements to browse on the DOM I suppose. I need to get rid about this slow attitude... so what can I do?
EDIT
You can hear the difference about Chrome and Firefox (5, last version) on this video. Try to hear/see the difference between clicking on mouse and add new line (with the effect). It's too frozen (also when I try to add more tracks quicly).
Still a problem for me, any suggestion will be appreciate :)
This is not very slow for me. On my computer running Firefox 5 I can add many tracks in less than a second. What performance are you seeing? ("Fast like a turtle" is not a very quantitative measurement. :)
When you have trouble with JavaScript speed, profile it, using the Developer tools for Chrome/Safari/IE or Firebug for Firefox. Here's what I see when I run the profiler on your JSFiddle and click on the +Track button twice:
From this we can see that most of the time is spent in some set function from a mootools library. Since I don't see this library included in your code, I'm assuming the profile is tainted by JSFiddle.
So, we create a standalone test case without the unnecessary CSS and profile that. Now we see this (for several presses of the +Track button):
Almost all of your time is spent in the clone() function.
So what can you do about it? You could try pre-creating the HTML string (in JS) for a template row, and instead of using 'clone' try creating that with:
$(templateString).hide().insertAfter(...).fadeIn(600);
would it be ok if you get just the last element?
something like:
$('.tracklistOff div:last-of-type')
.clone()
.hide()
.insertAfter(($(param).parents('.trackOn')))
.fadeIn(600);
or you could addClass(last) to the last element to get only one
I just tested your fiddle on the following browsers and they all worked well: FireFox 5, Opera, Google Chrome, Safari & IE9.
There were no speed issues but each browser handled the fade slightly differently however everything else seemed to work fine. Not sure what the problem is here. It could be your computer speed but as you're on this site I presume it's decent.
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/
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.