If you’re reading this, and it looks pretty, that’s because I overhauled my entire blog design for this Hack Friday.

There were a few problems with my old blog, the most glaring of which was the fact that its style was based off of my landing page. While the layout and colors of the landing page are, I think, fairly interesting and effective, they do not lend themselves well to reading large blocks of text. The green on green is hard to read, the lines are too long, and a bunch of useless Wordpress crap appears in every post (unless you tell it not to).

I went with Wordpress when I decided to start an actual blog a few months ago mainly because I had never used it before - I wanted to learn how. That purpose has been served - I now feel confident that I could code up a dynamic site in Wordpress just fine (and in fact I have). However, there are a lot of problems with it logistically that I would rather not deal with.

Why should I have to compose blog posts in the Wordpress web interface? Why is it inserting <br>s everywhere, even when I’m in the HTML editing view? Why does everything need to be stored in a database - it’s complicated to set up and slow. Why do I need to conform to Wordpress’s format when coding - shouldn’t the blog be a natural expression of my web design ability and creativity?

As such, I’m done with Wordpress as a personal blogging platform for now. Instead, I’m switching to Jekyll.

There have been many people talking recently about making the switch from Wordpress to Jekyll, and for good reason. Jekyll is not a CMS (content management system), but it is an easy way to modularize and compile your website while giving you complete control over, well, everything. And everything is incredibly simple.

To download Jekyll on Mac OSX, it was simply

gem install jekyll

from the command line. After creating the directories _layouts and _posts manually, it was a snap to compile my LESS to CSS, run jekyll from a terminal to compile everything into the _site directory, and then open the page up in Chrome.

The jekyll --server can usually serve up your site locally for development purposes, but mine wouldn’t work for some reason related to the fact that I’m on a university wireless network (if you know why this would affect the jekyll server, tell me). This meant that I had to specify the full path to all of my CSS files in order for the post pages to be styled (because all my CSS is in the root directory, while the posts are not). Luckily this was incredibly easy to do by specifying a url attribute in _config.yml.

The best thing of all is that there’s no dependence on my webhost - everything is hosted on github pages and you can check out the repository here.

Northside Cafe BLT was awesome, by the way.

While developing Berkeleytime, a project I’m working on to help UC Berkeley students browse courses and plan their schedule effectively, we ran into one of the most interesting bugs I’ve ever encountered. The page would load, but the password field on the login form would occasionally stop working - when you removed all the text from the password field Chrome would slow to a halt and crash.

The odd thing was that the same bug happened in Safari, but not in Firefox. We knew it must be something to do with webkit, but we had no idea what was causing it - and since our deadline to launch was coming up, we puzzled over it all night.

Check out this example. It seems that whenever Webkit detects that a password field (i.e. <input type='password'>) has been made empty, it iterates through every DOM node present on the page BEFORE that password node.

If the password input is at the top of the page, it hardly iterates through anything, but if the password node is the final element, it iterates through all the nodes in the tree. We were loading a page with about 5000 lis for all the Berkeley courses, plus 700+ lis for all the departments, plus maybe 1000+ more for the user interface. We had the login form in a popup with colorbox, which automatically appends the popup content to the end of the page. So every time we deleted all the characters in the password, field, all the nodes got iterated through.

We eventually fixed the problem by modifying the colorbox code to prepend the popup HTML rather then appending it.

This is presumably a security measure, though I can’t think of a reason why Webkit would look through every single DOM node. It’s worth it to note that DOM trees of greater depth seem to make the “checking” algorithm even slower. For the record, this is Chrome 22.0.1229.79 and the bug has been posted for a while (6 months) here.

Moral of the story: make sure you don’t have an inane number of elements before a password input in your HTML. If you really need to, consider using a dropdown menu jQuery plugin for your form, or anything you can use to provide your password field at the top of the HTML and display it later using javascript. Please let me know if you’re more knowledgeable about this than I am and you have an idea of why this might happen!