Posts about crossbrowser

Multiple Class Selectors Don't Work in IE6

toby ho — Wed, 31 Mar 2010 15:53:31 -0500

This is well-known knowledge, but I since it was not to me, I'll still catalogue it here. When you use a CSS selector with multiple class names on the same element, i.e.:

.class1.class2{

...

IE 6 will interpret this as:

.class2{

...

That's right, the first class will get ignored.

JSON with Special Characters fails in IE

toby ho — Wed, 27 May 2009 00:09:10 -0500

If you try to eval a JSON string that has special characters in it(non-ascii, or chr > 127), it will error out. The other browsers work fine.

Trying to Index Strings in IE

toby ho — Tue, 26 May 2009 13:57:00 -0500

'abc'[0]

gets you undefined in IE. The correct way is to do 'abc'.charAt(0).

IE Woes: One

toby ho — Tue, 09 Dec 2008 21:09:28 -0600

Man! Have I been at war with IE lately. I have been holding back a lot of blog posts related to debug IE problems, and I going to start spewing them out now one by one. For the first installment I'll talk about one I encountered these couple of days...

Ever get this IE error?
When you click "Ok", this is what you see:

Ouch! Can this be any more catastrophic?(Yeah, that's my Chandler impression.)

According to this forum post, this happens if you have script tags in your document that's modifying other parts of the dom before the document finishes loading. Umm, okay, but I still had a hard time finding out the exact point this caused the problem. I used the comment-out-code-and-see-if-it-still-breaks-binary-search methodology, and came up with some work arounds which involved delaying the execution of some setup code. But, this catastrophic error came back to haunt be time and time again. Clearly I didn't find the root cause of this error or I wouldn't be committing it repeatedly.

But finally, I found it(I think, well at least one of the root causes). I am using firebug lite in development, which creates iframes and panels in the pages that pops out and in just like firebug. When you call console.log with firebug lite, guess what happens? Yeah, it modifies the console output window - a part of the dom that is outside of where the script tag is. Got rid of those console.log statements and fixed it.

In conclusion, do not do what I did!

IE getElementById looks up "name"

toby ho — Tue, 09 Dec 2008 16:29:00 -0600

IE, are you kidding me?

Radio button change event firing

toby ho — Mon, 10 Nov 2008 10:54:29 -0600

If you register the change event for a radio button, they fire at different times between IE and FF. FF fires the event immediately when you click on the radio button to change its value. IE does not, it fires changed only when you blur the element.

IE bug: input endtags show up as nodes

toby ho — Mon, 10 Nov 2008 10:50:44 -0600

If you write an input element like this:

<input type="text" id="name" name="name" value="></input>

In IE, if you try to traverse the dom, you will get the end-tag as a separate element /input. Ex. with prototype: $('name').next() should get you /input.

button's value attribute

toby ho — Mon, 29 Sep 2008 16:50:38 -0500

If you use a button element as a submit button in a form, like:
<button id="mybutton">My Button</button>
$('mybutton').value in FF will get you an empty string whereas in IE you would get "My Button"

Making justtodolist work for chrome and safari

toby ho — Tue, 02 Sep 2008 23:01:32 -0500

Since Chrome is so great, I wanted to use it for all my browser needs. But the apps I've been working on myself have not been targeted for WebKit - the rendering engine used by chrome, and also used my Safari. This is mostly due to laziness on my part - having to handle two browsers at a time is chaos enough. But Safari compatibility is on my todo list for more than one of my projects, and chrome is a good push for this cause. And so I went in today and made just todo list. compatible with Chrome and Safari. The differences I encountered were:

This is really prototype specific - prototype adds an empty underscore parameter for all Ajax request for WebKit browsers. Because apparently, Safari errors out when you try to post with an empty body on XHR calls. And, who knows, this might already be fixed in WebKit. I happened to have code that was not handling this fact on the server side. This was no biggy.
This is an error on my part really, but I had a form with a text input inside. But also registered for the key events on the text input so that when enter is pressed I called form.submit(). The key event code is really unnecessary because an enter on the text input triggers the form submit on both FF and IE. So, although on the other 2 browsers this was no problem, in WebKit this triggers 2 posts. So... just DON'T do this.

function dot toString()

toby ho — Tue, 15 Jul 2008 13:53:38 -0500

function.toString() has different behavior between IE and FF. FF collapses the parameter list onto one line, while IE leaves it untouched. Ex:

function f(

  param1,

  param2,

  param3){

...


f.toString();

In FF you would get something like:

function(param1, param2, param3){

...

in IE:

function f(

  param1,

  param2,

  param3){

...

In IE, this breaks function.argumentNames() in prototype.js, so don't break the parameter list into multiple lines if you are using prototype.js, or until they fix it. Also, notice that FF removes the name of the function in the toString() output.

button element in IE - set type

toby ho — Mon, 30 Jun 2008 14:58:27 -0500

If you use the button element, make sure you set the type attribute:
<button type="submit">Submit</button>

Otherwise, it won't submit it's parent form when clicked in IE.

prototype descendantsOf works different in FF than IE

toby ho — Mon, 30 Jun 2008 12:23:00 -0500

I haven't dug down to the bottom of this but basically Element.descendantOf(elm, ans) gives different results from IE vs FF.