Ian Lewis' Blog

So the last few days I've been playing around with MochiKit and working with Javascript. Until now I have done some Javascript here and there but not too much. MochiKit seems to make it a lot easier by providing you with lots of useful functions for things you do often. In fact it's so popular that I have a hard time explaining to myself why I hadn't tried to use it up until now. I'm certainly not on the bleeding edge here.

Anyway, like I said, MochiKit makes JavaScript less painful. I have a little mockup for a page that defers going to the server until the user has stopped entering data for 3 seconds. That cuts down on a lot of back and forth between the server and client. It's easy in MochiKit. Just use the callLater function.

In this example the callLater is used to call another function, deferredupdate, after 3 seconds. However, if the user enters data a second time before the three seconds are up then the deferred object will be cancelled and a new deferred object will be created. This has the effect of not calling the update function until a user is really done entering data.

The request object is created in the deferredupdate function.

The deferredupdate function calls loadJSONDoc which creates a deferred object as well however this deferred object doesn't wait for any time it simply does it's work in a separate thread and executes a callback when it's done. In this case I set the callback to be the pageupdate function. The pageupdate function does the work of putting the resulting data into a table and adding that table to the html DOM.

If you are wondering what the bind function does, it always ensures that the 'this' reference works. I'll leave the full explanation for another post.

Most people who program in JavaScript already know about MochiKit but if you are interested in it check out the screencast at http://www.mochikit.com/

In the same vein as my first post bashing Internet Explorer I wanted to point out a few CSS bugs/unsupported features that are notable in Internet Explorer. For those who are not familiar, CSS is a stylesheet language which helps you to layout your forms. It's used on basically every major website on the internet. But Internet Explorer, even though it is the most widely used browser, does not support many of the features of CSS and when it does, sometimes the layout appears differently than in other browsers because Internet Explorer doesn't follow the rules for how the CSS should work. This post will cover those issues where Internet Explorer simply doesn't work at all.

PNG Transparency

The first issue affects this website and actually causes the CSS used by this site at the time of this writing to be non-standard (shh!! don't tell anyone! I'll fix it sooner or later). That issue is that Internet Explorer doesn't support PNG transparency. PNG files have in them a transparency level which allows translucent images. When you click on an image on this site like below it pops up an image and the background is darkened by another translucent png image. This doesn't normally work in Internet Explorer.

Normally you should be able to just set the background image like the following and the png will be displayed with it's inherent transparency.

But Internet Explorer displays it as completely opaque.

Instead, for Internet Explorer's sake you have to do some wierd hack that is Internet Explorer friendly.

Notice the wierd call to some Microsoft method for displaying images with alpha. This is totally non-standard and broken but necessary in Internet Explorer to display a png with transparency (there are other ways to achieve the desired effect in javascript however).

Button Hover

The second issue is that Internet Explorer doesn't support the button:hover attribute in CSS. Normally you can make a particular piece of a page such as a link or button behave differently if you add the "hover" attribute to it in CSS. This has been used a lot with normal links. Indeed this site uses a:hover to show different color links when you hover over them. Try it. The link goes nowhere but you can see that it changes when you hover over it. The same should be true for buttons. You should be able to change a buttons properties when the user hovers over it using only CSS.

button:hover {
  /*Your CSS here */
}

In fact you can use this hover effect with pretty much anything, such as table cells and rows. However IE only recognises the hover for links so it requires javascript. Check out this test page. Hovering over the button does nothing in IE. In order replicate this functionality in Internet Explorer you have to write some wierd javascript that sets the behavior of the button when the page is loaded. There are a number of ways to do this but the most straitforward is to use the whatever:hover script so you can make use of the hover attribute in css. It has some important limitations however so be sure to read the limitations section. Essentially the scripts adds a onMouseOver and onMouseOut events to the button which change it's stylesheet class.

Both of these problems have added difficulty to my life. The first stemming from this website and the second stemming from work. While web browsers have become a quite complicated piece of software, time spent fixing bugs because of broken implementations of standards is a huge waste of time. This is somewhat true for Safari and Firefox but especially true for Internet Explorer. No argument could counter that it is a steaming pile of dung and that you shouldn't use it. PLEASE STOP. The world will be a better place if you do.

Basically the title says it all. Since I started doing web development I've lost count of the number of bugs that I've found in Internet Explorer but I want to highlight a couple that were especially annoying to me.

1.) The <button> tag doesn't work. The button tag has a value attribute which is supposed to be sent as the value of the post when I submit a form but it's not. The display value of the button is sent instead. So if you have a form like so:

<button name='time' value='1030'>Click here</button>

and you submit the form that the button is contained in, the post value of time is set to "Click here" instead of "1030" like it's supposed to. Basically in IE you can't have a button submit a form and post a value different from the displayed value. This makes it very hard to have an array of buttons and post a different value based on what button you push.

2.) For e-mail links that contain Japanese characters you have to change the characters to the %0000; equivalent value. So if you have a mailto with a subject line in Japanese you can't write:

<a href='mailto:myperson@mymail.com?subject=おはようございます'>e-mail me</a>

and expect it to work. Internet Explorer simply does nothing. No error message. No e-mail client. You have to url encode the link to something look something like:

<a href='mailto:myperson@mymail.com?subject=%E3%81%8A%E3%81%AF%E3%82%88%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%26'>e-mail me</a>

which if you are using php is not so bad since you just call urlencode() but it's just plain annoying to get stuff like this to work when there isn't really a good reason why you need to encode it (at least I haven't heard one so far).

That's just the 2 most annoying bugs/issues. I can't imagine how the button bug got though the testing phase for IE but probably there are too many applications that depend on the bug working as is for Microsoft to ever change it to work the way it's supposed to.

I realize I shouldn't hold my breath, but the sooner everyone stops using IE the better.