href value for javascript link anchor

If you create a link with javascript handler, and href attribute doesn't matter for you, do not use # as the value of the attribute. This results in page scrolling to the top of the page in MSIE.

Instead, use value like javascript:// - this is safe and most browsers will ignore it. And this is what you want when you have an onclick handler, isn't it?

Update: I was pointed out, that if javascript click event was cancelled in onclick handler (like Event.stop(e) in prototype), you can safely put # to the href, because default click behaviour will be disabled in this case. This works, but I still prefer to put javascript:// to the link href - IMO this reveals intentions more explicit.

Internet Explorer rendering problems or how to repaint Web-page

A short prelude.

I'm developing a small checklist application, to study ruby/rails and to play with various Web 2.0 UI patterns. And to get a tool which will help me to organize all my todos.

On the checklist screen I have, guess what - list of tasks, the checklist is comprised of. On some actions (like completing a task) the tasks are updated incrementally (with plain Javascript), on some actions (like undo) the list is reloaded as a whole.

Now the story.

To avoid task rendering in two places (on the server-side, when tasks are loaded from the server and on the client-side when they are updated in-place) I've used an approach when all rendering is performed by Javascript, even on the full page reload. This implies generation of the HTML on the browser-side and inserting the resulting HTML into the page in window.onload hook.

The problem was that in IE the inserted HTML was rendered like a total mess. Elements were painted one upon another, lost their position, styles.

As I found out later, the page resize fixes the rendering.

So I had to force a repaint of the inserted elements to fix the rendering.

The solution was simple. All I had to do was to add a fake CSS class to the inserted element and remove it afterwards (in fact, there is no strict need to remove the class). This operation forces an element restyling in IE and fixes its rendering. Looks like a hack, and it is.

By the way, moving task list rendering from the server side to browser gave me performance gain of 200% on the server.

Problem with offsetTop and element position location in IE

This is just a small note for someone looking into a similar problem.

I was implementing keyboard navigation with explicit scrolling using scrollTo method, and found out that in IE I cannot get correct values for element position on the page. I use Prototype and it's Position.cumulativeOffset method (which, in turn, uses offetTop/offsetParent properties of the element). Position calculation worked fine in FF, Safari and Opera, but sometimes failed in IE.

The DOM tree I was operating with consisted of several nested UL, LI, SPAN elements (SPAN inside LI).

I added some debug code and found out, that SPAN elements sometimes got huge offset relative to LI, though it should be simply 0 (FF showed value of -1).

The solution to the problem was to add position:relative style to the SPAN, after that the problem disappears.

Unfortunately, I was unable to reproduce the problem with a simple test case to give the example here.


css javascript ie