Monthly archives for "November 2007"

‘Tis the season—to get ready for fabulous gift-giving, of course. From the Ship of Fools, here’s the Walled Nativity Set:

Thank you, Dan Sack, for the best Christmas ever.

This video seems to illustrate something that was mentioned briefly in the last episode of BBC Three’s Singing with the Enemy, where the lead singer of death metal group Amputated (and didn’t he look exactly like a young Murray from Flight of the Conchords?) mentions that sometimes he makes “oinking” sounds while singing. Very metal.

Recently I mentioned that I use Safari Tidy—a plugin for Apple’s Safari browser. I thought I’d shed a little light on why I think it’s so great.

For years now individuals—Jeffrey Zeldman most prominent among them—have been evangelising the use of standards-based (X)HTML. There are vague reasons for supporting standards, like getting the warm & fuzzies for doing so; there are abstract reasons, such as preparing work properly to be handed over to a successor; but a very real & immediate reason is that you have a very firm basis upon which to work. It’s all too easy to make mistakes in the semantic properties of HTML, which can yield disastrous rendering results in browsers. And it’s all too easy to not see the problem until late in your design process.

Safari Tidy is unobtrusive & always on: you’ll see that an error has arisen immediately, so you can go fix it. Other implementations of Tidy aren’t so automatic—you have to physically check your markup’s validity, which often means that you don’t check—this is what makes Safari Tidy so fantastic.

I’ll illustrate with a real-world example (one upon which I’m currently working, in fact):

Many out there will be aware of the generating capabilities of Ruby on Rails. A good explanation of this is beyond the scope of this article, but suffice to say you can build the general building-blocks of a web application very quickly, such as setting up a new user in a system. Here’s a rudimentary example of a ready-built form (linked to the users controller). It’s to be rendered in XHTML:

  <% form_for(@user) do |f| %>

    <p>
      Login:<br />
      <%= f.text_field :login %>
    </p>

    <p>
      Email:<br />
      <%= f.text_field :email %>
    </p>

    <p>
      Password:<br />
      <%= f.text_field :password %>
    </p>

    <p>
      <%= submit_tag %>
    </p>

  <% end %>

The result of all that <%= f.text_field :foo %> is to create form tags, such as input. Here’s what the above gets with the Login example:

  <p>
    Login:<br />
    <input id="user_login" name="user[login]" size="30" />
  </p>

So far, so good. But what if the user hasn’t filled out a field & you have to display associated errors? Simple in Ruby on Rails. Assuming validation has been set up in your users controller, just add the following bit in front of your form:

  <%= error_messages_for :users %>

With this in place, if your user doesn’t enter a required field, or enters a required field incorrectly, then Rails will automatically inform the user of what was wrong (in the location of the <%= error_messages_for :users %>). Moreover, it’ll wrap the offending field to highlight the user’s attention to it. It will look like this:

  <p>
    Login:<br />
    <div class="fieldWithErrors">
      <input id="user_login" name="user[login]" size="30" />
    </div>
  </p>

And now we have a problem. A div can contain a p, but cannot be contained within it. This is where Safari Tidy comes in really handy. When you test your error message (as above) by viewing it in Safari, Safari Tidy will inform you of an error in your markup. The error it makes is somewhat cryptic:

  <p>
    Login:<br />
    <div class="fieldWithErrors">
      <input id="user_login" name="user[login]" size="30" type="text" value="" />
    </div>
  </p>
  -----
  Line 85  Warning: inserting implicit <p>
  Line 89  Warning: trimming empty  <p>

What’s going on here? Since a p can’t contain a div, Tidy thinks you’ve not closed your p tag before you started your div. In addition, it thinks you haven’t opened your p after you’ve closed your div tag. Certainly, knowing your XHTML helps in this situation, since the error it throws is otherwise cryptic; but Tidy gives the clue where to find the error. On a form with a lots of fields, this is really helpful.

Safari Tidy helped me note there was a problem before I even realised that there was a problem—and there really was, the error screwed up my pretty design horribly.

Update: What a wally—I got so wrapped up in Safari Tidy that I didn’t explain how to fix the error! There’s a simple solution: convert your p tags to divs throughout. I don’t know why Rails screws this up in the first place—Rails seems to have been designed pretty well & this is a glaring oversight. It’s really bothersome to have to fix every automatically-generated form.

A business blog may not be the best forum for this, but I don’t have another outlet.

A dear friend from my days at New College, Craig Allen, died on Saturday, 17 November 2007. There will not be a funeral, at the behest of his family.

Craig was an extraordinarily gifted individual, painfully intelligent with an incredibly caustic wit—best when turned on someone else. He greatly enjoyed music & movies, but his dearest loves were his two children, whom he idolised.

He worked as a lawyer for the National Science Foundation investigating fraud & criminal activity. While working there he developed two rare illnesses, neurosarcoidosis & pulmonary sarcoidosis. The struggle against these put an intolerable strain on him & his marriage, more so because he was inaccurately diagnosed for a considerable period of time. While fighting the pain of these illnesses, he became addicted to a cocktail of drugs.

He was fighting his addiction & was trying to pick up the pieces of his life in Florida when he lost his battle. My last message from him was written the day before he died. He was upbeat, more so than I have heard in a long time.

He leaves behind his two children, Gabriel & Jackson. He was 36 years old. He was a dear friend.

Craig Allen (right), in happier days

If you’re running the newly-released Mac OS X 10.4.11 update & are having lots of crashes in Safari, then the likely culprit is going to be items in your ~/Library/InputManagers/ path. Some popular Input Managers include:

• Application enhancer SIMBL
• Safari enhancer Saft
• X/HTML validator SafariTidy
• TextMate bundle “Edit in TextMate”
• The Safari plugin for the password manager 1Password

SafariTidy was the culprit for me. The developer, Kasper Nauwelaerts, has upgraded this to 0.2.4. I’ve not yet been able to successfully install the update, however—Safari just isn’t recognising its existence.

Input Managers act as a patch to the applications for which they’re intended, and as such are unsupported—even actively discouraged—by Apple, because they can patch applications in dangerous ways. Those of us who rely upon such items—as I am to Safari Tidy, so I can validate my work on-the-fly—are in something of a quandary. As Daring Fireball’s John Gruber implied regarding input managers and unsupported software, this situation isn’t going to get better but worse as time passes.

SafariTidy’s useful validation features: how can it be made a better OS X citizen?

Because the use of the InputManager system is so bad, I’m left wondering what’s the best recourse. Tidy is really useful & there are extensions for Firefox, but none are to my mind as elegant as SafariTidy. I’m left hoping that Kasper will port his plugin to a different architecture…

Update: I just got some tips from Kasper & some very good news:

…You should put [SafariTidy] in the SIMBL plugins folder, which usually resides in ~/Library/Application Support/SIMBL/Plugins/.
Please remove all traces in any InputManagers folder you put the bundle, as this plugin isn’t technically an InputManager (anymore).

Three cheers for Kasper! I’ll be donating to him right now.

Update 2 (03/03/09): for those using the new Safari 4 beta, you’ll want to upgrade to the latest SafariTidy.