On a project we’re working on now, we need to place “pins” on a map. There are some advantages for us not implementing the map with Flash. Namely, the project has a Facebook app component and Facebook requires users to click to activate Flash on profile tabs. I was curious to see how many pins I could instantiate in the DOM before there was noticeable chug. I made a test script that creates a bunch of img elements in the DOM. You can try it out here: DOM Capacity Test.

Through some not very scientific testing, I found that 100-300 DOM elements is my sweet spot (though IE really needs it towards the low end of that range). Any higher and the browser noticeably chugs during rendering. I was surprised that once rendered, the browser didn’t seem to perform any worse during scrolling or resizing. Another thing I noticed was that Firefox visually added each element to the page iteratively (taking much more time), whereas all other browsers immediately showed all of them after the initial CPU churn.

I was wrapping up on a project, and the time came where the color on the lists (1, 2, 3) needed to be different colors than the actual <li> inside needed to be. The only solution is to wrap any content inside the <li> with some sort of tag to target the text to change the color. Although that has no problem at all, what if this needs to be site wide? It will be very cumbersome to remember, let alone do it to every list you create.

I decided to use JavaScript to search for every <ol> and for every <li> inside of it, then it goes ahead and wraps it in the selector that changes it back to default color. In this case its a <span>.

This is what it does, this will be the before HTML:

<ol>
   <li>Item text goes here</li>
   <li>Item text goes here</li>
   <li>Item text goes here</li>
   <li>Item text goes here</li>
</ol>

And, after the JavaScript does its thing:

<ol>
   <li><span>Item text goes here</span></li>
   <li><span>Item text goes here</span></li>
   <li><span>Item text goes here</span></li>
   <li><span>Item text goes here</span></li>
</ol>

Here is the JavaScript:

window.onload = function () {
   var li = document.getElementsByTagName('ol');
   for(i=0;i<li.length;i++) {
      if(li[i].childNodes[1].nodeName == 'LI') {
         var li_count = li[i].childNodes.length;
         for(b=0;b<li_count;b++) {
            li[i].childNodes[b].innerHTML = '<span>'+li[i].childNodes[b].innerHTML+'</span>';
         }
      }
   }
};

Here is the CSS:

.container ol {
	padding: 8px 10px 8px 25px;
	list-style-type: decimal;
	color: #c19203;
	font-weight: bold;
	}
	.container li {
		padding: 4px 0;
		}
	.container ol span {
		font-weight: normal;
		color: #333;
		}

I did say that I wasn’t going to bother with IE6 fixes on my new site. In fact, I was planning on insulting IE6 users with a special graphic overlay. I remembered however that this would include people like

a) 50% of our clients (guessing)
b) 66% of my family (my brother introduced me to firefox)
c) 30% of everybody (according to current stats)

So, that’s a lot. So, I spent the whole day (literally) fixing the site for 6 (argh) + 7 (which was admittedly easy). Anyway, for the IE6 users, I’m using a little script from this site:

http://savethedevelopers.com/

It’s cool, it animates in a pretty image at the top of the page saying how you should upgrade and provides links to current/modern browsers. So, while not an affront to each users’ browsing sensibilities, it does provide a nice recommendation that is rather obvious.

I didn’t have time to pass this around over the holiday break, but the IE team announced a few weeks ago that they got IE8 to pass the ACID2 test!

[UPDATE] Garrett pointed out the IE team interview video linked page on the page. I thought it might be nice to link directly to it for you non-reader types.

H