Ben’s Techy Musings

I’ve decided that I don’t post enough photos and pictures on this blog.

Over the bank holiday weekend just passed, I took my girlfriend to stay in Liverpool at my parents’ place. We visited the Formby coast where in the “attractive pine woods” there are “playful red squirrels, often brave enough to scamper up close”. Red squirrels are a rare sight in Britain where they suffer from competition from the grey squirrel.

Can you spot the red squirrels?

Neither could we.

Recently I wrote about using an image as a form submit button. Essentially I described some basic CSS which most browsers will accept to style an <input type="submit" ... /> as an alternative to using <input type="image" ... />.

What I wrote is anything but groundbreaking and is widely used. And I’ve just found an even better way to do it, by using a button element instead of an input.

What prompted me to look for something better was noticing that Camino, the native OS X Gecko browser, lacks the depth of CSS support for input elements that the more popular browsers, namely Firefox, IE and Safari, have. This means that the many sites which use the technique I described in that post can be unusable in Camino, as form submit buttons appear grey and empty.

But apparently (and I did not realise this until today), using <button type="submit">Submit</button> is a valid and functional replacement for a form input element. And a button is more flexible, allowing you to put an image inside it instead of text, for example. Best of all, though, a button accepts styles more readily in most browsers.

I fixed my form submit button in Camino by changing it to a button and applying exactly the same styles that I had applied to my input. Rather than link you to the post again, here’s the code with the “input” prefix to the class name, just to help you avoid making the same mistake I made.

.customSubmit {
 width : 76px;
 height : 36px;
 overflow : hidden;
 padding : 36px 0 0 0;
 background : url('/images/custom_submit.png') no-repeat;
 border : 0;
}

And the button code, for good measure:

<button type="submit" class="customSubmit">Submit</button>

Again, this probably isn’t groundbreaking stuff but many sites could do with using this alternative to increase their browser support.

I’m excited about the potential of the budding SwitchABit platform.

It shows promise of breaking the monopoly that various social tools hold over certain types of social content. It will also help to mitigate one of the causes of these monopolies—the network effect; the runaway success of a particular service once its user base reaches a certain fraction of its market.

We already have services and tools which ease our simultaneous use of the many discrete social tools by helping us to post the same stuff to more than one place. A very simple example is the Twitter Facebook application, which solves the problem of many people using Twitter and their Facebook status for the same purpose by automatically updating their Facebook statuses whenever they tweet.

Most of these existing tools, as far as I’ve seen, require us to feed our data into the helper tool first in order that it can distribute it for us, or that the helper tool (e.g. the Twitter Facebook app) be controlled by the service from which we want to set free content (in that example, Twitter). If I understand it correctly, the paradigm shift in SwitchABit is that the helper tool becomes a transparent intermediate layer, distributing our social content without us needing to know how, or from where, it works.

I recently started using Dave Winer’s TwitterGram: Flickr-to-Twitter service, which has just been ported to become one of the first applications on the beta SwitchABit platform. Flickr-to-Twitter scans my Flickr photostream for me and finds photos which I’ve tagged with a ‘twitterthis’ tag. It creates a tweet-friendly TinyURL for the full Flickr URL of a photo, then tweets the photo’s title and the URL from my Twitter account. Simple steps, but ones which are tedious to perform myself at best, and downright awkward if I’m using a mobile device. Now I can email a freshly snapped photo from my iPhone to Flickr and see it tweeted to my friends very shortly afterwards.

I can’t wait to see more transparent helper tools like this come together to form a pervasive medium for the diffusion all sorts of social content.

Yesterday, during my daily read of Dave Winer’s own RSS feed, I discovered that it was RSS Awareness Day. I really wanted to blog it there and then but hadn’t the time because, ironically, I was working hard at the coalface, hacking away (I like this metaphor) at a client’s RSS-driven microsite.

So in lieu I now declare today “RSS Awareness Day” Awareness Day, because I’m very aware that yesterday was RSS Awareness Day.

During yesterday’s frenzied session I was reminded poignantly that not all of the data in an RSS feed is as reliably parseable as the XML itself. In this case, I was extracting tags from a comma-separated list and putting them into a database.

In my infinite wisdom I put an index on the table which forbade duplicate tags within an item. While parsing 50 items in a test feed nothing went awry but, of course, the very first item on the client’s real feed contained sloppy repetition of tags, exposing my lack of foresight with a nasty SQL duplicate key error.

I live and I learn.