We Keep Coding

Rearranging table rows through jQuery giving undesired results in IE

I am trying to rearrange the table rows in the preformatted HTML table.The HTML table is being displayed as in the below fiddle.. My total HTML is given in this fiddle.
Initial Look of the table
I am trying to rearrange the <td> with texts containing texts "One" and "Two".I am identifying those "One" and "Two" rows using "rowspan" attribute. If you see the below fiddle in non IE browser you can have a clear picture on what i am trying to do..
After rearranging
But the problem is, This Code is working fine in browsers other than IE(I have tested in Chrome and Firefox). I am unable to find where the problem is...
Please help me to correct my code to have cross browser compatibility.

Thanks for your answers, I found the problem.. IE is assigning the index from 1 to the elements. So giving
find('td.mrGridCategoryText:eq(0)')
is giving undesired results, If i change it to 1 then i am getting correct result in IE but not in others.Check this fiddle http://jsfiddle.net/J7WPb/23/
So
i need to give eq(0) if other browsers and eq(1) if IE :-(
Thanks again.

If you can, use IE9 (Windows 7+ only) and press "F12" for the console and debugging abilities.
You can then even use the javascript debugger to refresh the page and have it break on javascript errors
Personally, I don't support IE, not till they start supporting the "internet" the way every other "way better browser" does
UPDATE
I found a problem! When IE8 loads the page there is an error on line 195 of file LayoutCM.js
In other words, I don't think the error is in your code as much as it is a jFiddle issue!
Suffice it to say, IE8 doesn't support "getStyle" on the object it's being called upon (variable "win" expected as "window").
This is just another shining example of IE not supporting the "internet" as I put it earlier.
Hope this information helps!

Why is this jQuery animation so SLOW on Firefox 4/5?

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.

Annoying IE8 dropdown issue in XP but not windows 7

I have an annoying issue with a select html element that cuts off the text in the dropdown when it is longer then the set width of the select html element.
The select elements need to be a set width to stop the page misalinging, Every browser seems to work except for IE8 running on XP. why? so random and bad compatibility.
please let me know if you need more infomation.
Thanks!

It's a how IE interprets it should render the drop downs ... Unfortunately,there's no easy fix, what you can do is create a replacement for drop downs that handles this in a different way, that can work consistently across browsers ...
Here's a solution I came up with
http://weblogs.asp.net/jaimedelpalacio/archive/2008/11/22/custom-html-dropdown-control-part-1.aspx

i'm not sure of the differences between OS, but just use conditional comments to style the select in IE. style the as well.

IE8 simple alert is failing?

Why isn't the following piece of code working in IE8?
<select>
<option onclick="javascript: alert('test');">5</option>
Quite bizarre - no alert is shown in IE8. I do not see the error icon in the left corner as well. Of course it works in FF and Opera. Any ideas?

Putting an onclick handler on an <option> element seems.... weird to me. You might want to switch that to the more common onchange event of the <select>. You can still do whatever you want to do from there, and this is the "accepted" way of doing whatever you want to do to the select. That being said, you might want to try removing the javascript: part of it. That is only needed when you are executing Javascript in a link href for example. An onclick handler expects javascript.

Have you tried just:
onclick="alert('test');"
Pretty sure you don't need the javascript: prefix.

All versions of IE (6,7,8) do not support ANY event handlers on the option elements.
This is a (fairly) well known bug that the IE team has indicated they are in no rush to fix. :-(
Then again Opera, Safari & Chrome all have limited or no support for event handlers on options too.
Lack of events on options: bug 280
(related) Lack of styles on options: bug 281
It should be noted that "Edge" (think IE12 on Windows 10) is currently showing that this issue is fixed in preview releases.

iframe shimming or ie6 (and below) select z-index bug

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();
}
});