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.

We’re planning on using Cufón to a larger extent than we have before on our build for Gregory, which has to be localized in a number of languages.  Using a text replacer for the designed text will allow us to localize text without rendering out new gifs and pngs for every language and whenever copy changes.  Not knowing how fast Cufón could render when given a lot of text, I put a test together.  PHP renders out a bunch of random text in blocks ranging from 10 characters to 1,000,000 characters.  Then Cufón goes to task on each, in sequence.  JS tells  you how long it takes.  Try it out here, but be advised it can crash your browser.

Here are the results of my very non-scientific test:

At 100,000 characters, FF3 threw “A script is running slow, blah blah” messages.  IE7 just crashed.  Safari 4 hung in there till 1,000,000 but then it gave up.  It looks like Apple’s claims about Safari 4’s speed have some truth.  I didn’t test any of the past generation of browsers, I may go back and add them later.

It looks like Cufón works perfectly fine on a page where it’s converting a thousand characters or less.  But it shouldn’t be used to convert the majority of the body copy of a page.  That’s perfectly acceptable to me.

Lets say, you are making a site, were everything is AJAX, and you rely on event handlers to know when people double click on this element, drag the image across the site, etc. Normally you would start listening to things once the DOM fires (when the page loads), but problem is, it only fires once.

Here is an example of a normal “onload” listener in Prototype.js:

Event.observe(window, 'load', function () {
$$('tr[rel="file"]').each(function(element) {
element.observe('click', function(event) {

new Ajax.Request('file_info.php', {
asynchronous: true,
method: 'get',
parameters: 'ajax=true',
onComplete: function(t) {
$('files').update(t.responseText);
}
});
event.stop();
});
});
});

So, once the window loads, tell every table row with the rel attribute named “file” to some things once its clicked (in this case, gets the file info). Problem is, with all the new table rows coming in, Prototype wasn’t told to listen to the new table rows, only the previous ones that are gone.
Read the rest of this entry »

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

After working with Mootools a bunch on a project (2K), I think I’ll be sticking with Script.aculo.us for GC. The main reason for me comes to down to documentation, but there are some peripheral reasons.

For it’s DOM stuff, Script.aculo.us uses Prototype out of the box and I think Prototype has AWESOME documentation, the pillar of what everything should aspire to documentation wise. For it’s effects, Script.aculo.us uses a wiki. Now I don’t think this is great (I don’t love the wiki look), but the way the pages are written up do make them more approachable than Mootools. With Mootools, there aren’t a whole lot of examples and I got the sense to really get good with it, you had to use undocumented properties and methods. It felt like a class I would make Plus, many of the wiki pages include functioning examples inline, which Mootools relegates to another non-exhaustive section.

I’m also gonna use Script.aculo.us because I like how it’s effects have a delay property, which is super handy. And it uses the existing CSS properties as it’s starting point for animations. And it has more (and more useful) built in effects.

The main reasons I would recommend Mootools over Script.aculo.us is that their download page is the sickest thing ever and it’s domain isn’t a pain in the ass to type. I HATE the name. I hate having to use command-v over and over again to insert it into this blog. Also the Mootools site is more slick looking. But these aren’t really reasons to use it over Script.aculo.us.