supersonic feet

At Gottabet we’re looking for a ‘web application designer’ to join the team. The job entails a range of web dev, from helping design various sections/features of the website to implementing them in HTML and CSS.

There’s a full job spec on the website, so if you’re a developer who’s big on web standards looking for an exciting, fast-paced job working on a big social website, check out the job spec and get in touch with Wim and Bertrand (email addresses on the linked page).

Just spotted (via Simon Willison’s blog) that Yahoo! has released an extension for Firebug, called YSlow.

The extension adds more performance data to Firebug, grading various speed issues A-F like a school exam. It seems rather cool on a brief test, though one bit did immediately stand out as potentially bad advice: YSlow suggests you should move as much Javascript as possible to the bottom of your document (to stop it slowing down your page load times).

This is good advice looking purely from the angle of increasing page load times, but goes against the web standards approach of trying to keep JS out of your body code (the whole unobtrusive Javascript thing).

It’s not a major thing to have JS include tags in the body of your document compared to actual inline JS, but it might have been nice to see a note somewhere providing the other angle to just speed.

The most useful developer tool for Firefox has just hit it’s first version 1.0 beta and has added some great new features.

Firebug gives you all kinds of javascript and CSS debugging tools that help you track down where errors are coming from. For example, you can inspect a single HTML element and see the CSS that’s being applied to it, as well as where that CSS is coming from (filename and line number). With 1.0 beta it even shows you any CSS that would have been applied, but is getting overridden by other style definitions.

If you develop websites, you need this plugin.

My previous post mentioned FireBug and how handy it is in tracking/debugging AJAX requests and code. This was particularly important as the problem I’m having is with Sortable lists (in tree form) and child elements not being serialized when they’re added via AJAX. To explain a bit further, I’m using the technique to list the pages of a site, with sub-levels loaded in via AJAX so that you don’t get loaded with a few hundred pages listed all at once when you only want to get to the home page. That bit’s fine though - works perfectly. The problem is with the sortable part - here I’ve had no end of troubles.

My first problem is that I’m no JavaScript god. I can generally figure out just about what’s going on and write my own simple code, but I’m at no kind of level to be doing clever debugging. Doing sortable lists with a tree requires much clever debugging.

Problem two lay in my use of semantic XHTML markup and the result that the sortable list items also include lists that shouldn’t be sortable (lists of options). This initially breaks Sortable.serialize as the non-sortable list items don’t have IDs in the form tag_x for serialization, which in turn makes the serialize function skip anything below that level. Not good.

I tried adding in code to the serialize function to make it ignore the non-sortable lists, but this is where my JS skills hit a wall and in the end I’ve had to assign the option list items unfeasibly high ID numbers based on the page they’re associated to (something along the lines of page_pageID000000000x).

With that done (still working on the list starting showing two levels deep), the serialize function would get the whole lot and briefly I was happy. Alas, I then tried to add the code to load in sub-levels of pages via AJAX and of course the serialize function didn’t see the ‘new’ list items as the Sortable had been created before them. A quick search of Google and a common sense approach of re-creating the Sortable at the time the new list items are inserted seemed the way to go. I found someone claiming it worked to just re-declare the Sortable.create but no luck for me.

I’m still working on it

I spent part of my weekend doing a bit more work on my super-semi-secret Rails CMS, especially on part of the admin area that involved some nice AJAX effects that of course caused more trouble than is immediately worth it. One of the main problems is that it’s very awkward to debug AJAX code without writing in code to display errors, etc. in the interface which you might not want to do.

In trying to learn a bit more about Rails’ RJS templates for my AJAXing, I bought the O’Reilly PDF book on the subject (along with a couple of others on web services and SEO - 3 for 2 offers are sometimes hard to pass on). One of the most useful tips it contains is a link to FireBug, a JavaScript plugin for Firefox that among other things allows you to track AJAX requests. Just go to its console, options and enable XMLHTTPRequests tracking and you can see exactly what’s being sent via AJAX and what comes back.

I’ll separate my JavaScript woes into another post so you can just take this one as a recommendation to check out FireBug.