Ben’s Techy Musings

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.

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.

Today I’ve been working on a very long form which needs client-side validation (as well as server-side validation, of course) and tooltips for most of the fields. For users without JavaScript, the tooltips are all shown next to each field. When JavaScript is enabled, however, the tooltips are all hidden at onload and then appear when a field gains focus. When a field loses focus, its value is validated with JavaScript and if this fails, an error message is shown next to that field.

I started doing this the way I usually do events, by putting onfocus and onblur events in the HTML on each field. It worked, but there are so many fields and it became a pain to put this in every field. I find that lots of JavaScript often decreases the readability of HTML, too.

I thought, “there must be a way to use JavaScript itself to add these events to each field”. It turns out that there is:

fields = document.getElementsByTagName('input');
for (i=0; i<fields.length; i++) {
 fields[i].onfocus = function() { … };
 fields[i].onblur = function() { … };
}

Now the events code is unobtrusive in the HTML. Users without JavaScript don’t have to download the events code, the HTML is more readable and I need to do a lot less copying and pasting!