Improvements to form script

November 13th, 2005

I have made various improvements to the way the form enhancement script works. On the advice of Mark Wubbenthe event handlers are now set with proper event model methods and not with the setAttribute property. I kind of see your point, Mark.

More importantly, the script is now much more generic and should work on just about any page you plug it in to. It now works by getting the id of the input element that is currently in focus and searching for a label element with a matching for attribute. This means we are not relying on any other feature of the markup to make the script work.


id = this.getAttribute('id');
label = document.getElementsByTagName('label');
for (k = 0 ; k < label.length ; k++) {
if (label[k].getAttribute('for') == id) {
label[k].style.color = '#a00';
}

One issue I’m having is being able to concatenate two HTML Object collections. I have an array of inputs and an array of textareas, so my question is, why can I not concatenate them as follows.


input = document.getElementsByTagName('input');
textarea = document.getElementsByTagName('textarea');
both = input.concat(text);

At the moment I am using the DOM Level 0 method of getting form elements; which works, but I’d rather do it the previous way, and build my own arrays. Any ideas?

Highlighting form labels

November 11th, 2005

Here’s a nice little UI enhancement for forms that I knocked up today. I don’t know if you have seen anything like it before? If so, let me know where, and I can see about improving my scripts.

Talking of improving the script, I’ve realised there is a far better way of achieving this than how I have done it, which I will explain in a minute. First of all, go down to the comment form at the end of this post and fill in a few fields. Notice the labels become highlighted as each form field gets focus. Here’s how it’s done.

First of all, get every input element in the page with a type attribute of text. Loop through these and add the onsubmit and onblur event handlers required to trigger the functions which do the real business. This is done with the prepareLabels function shown below, although now I think about it, prepareInputs might have been more appropriate.


function prepareLabels () {
if (!document.getElementsByTagName('input')) exit;
input = document.getElementsByTagName('input');
for (i = 0 ; i < input.length ; i++) {
if (input[i].type == 'text') {
input[i].setAttribute("onfocus","on(this)");
input[i].setAttribute("onblur","off(this)");
}
}
}

Next up I have two functions. One that changes the style.color property to the highlight color onfocus, and the other that reverts the property onblur. I realise that I could combine these into one function with a simple if statement, and I will do in the next version of this. The two functions are shown below.


function on(field) {
temp = field.parentNode;
dl = temp.previousSibling;
label = dl.firstChild;
label.style.color = '#a00';
}
function off(field) {
temp = field.parentNode;
dl = temp.previousSibling;
label = dl.firstChild;
label.style.color = '';
}

In a nutshell, these navigate their way throught the DOM tree of dd and dl, finish up on the label element and apply the new color through the style.color property.

And that’s pretty much it. Simon Willison’s addLoadEventfinishes the job by attaching the prepareLabels function to the onload event.

But what about the textarea your thinking, right? Well, at the moment I actually have a third function which duplicate’s the prepareLabels function but gets the textareas instead.

function prepareText () {
if (!document.getElementsByTagName('textarea')) exit;
input = document.getElementsByTagName('textarea');
for (j = 0 ; j < input.length ; j++) {
input[j].setAttribute("onfocus","on(this)");
input[j].setAttribute("onblur","off(this)");
}
}

I know this is not a nice way of doing things, and it will be improved.

The next stage I want to think about now is making this much more generic. A better solution would be to use the for attribute of the label and match it with the id value of the input that is currently in focus. That way, we are not relying on our form being layed out with definition lists as I currently am.

Anyway, that’s something to think about while I’m on my way down to d.constructbright and early tomorrow morning.

A few design tweaks

November 7th, 2005

Regulars will notice the slight change to the layout and feel that I’ve just made. This site is back to what it always used to be — a blog. Pure and simple.

Actually, the reason this completely unscheduled change has just been made, is probably worth mentioning. In short, while doing a little bit of server tidying, I came across the first mock-up I ever made of this ‘Audi inspired’ design. It looked pretty much like what you’re looking at now.

I took one look at it and thought, hmm… that’s rather nice, why the hell did I spoil that by adding the side bar and all the extras? This is particularly relevant due to the fact that I never even used the side bar. The external links where all “Lorem ipsum’, and for some reason the ‘latest post’ loop wasn’t populating. Basically, it was a complete waste of space.

So, it’s gone – and I’m back to a similar concept as in the previous design, dubbed ‘Industrial Minimalist’ by John Oxton. Anyway, I like minimalist — if you’ve got fuck all content it really is the way to go.

Am I a spammer?

November 7th, 2005

Just a quick question. Over at Artist LogsI have a form that allows people to email blog posts to friends that they think will find them interesting. Over the last few days I’ve started to get a lot of “Mail delivery failed” messages from unknown severs to my email account, and it looks very much like my scripts are being used to send unsolicited email from my server.

Is this a common problem, and what can I do to get around it? Do I have to resort to checking for human interaction with the form (ie, ‘What colour is an orange?’) or perhaps use some javscript to keep out bots?

Any advice?

Mac OS X 10.4.3: Tiger roars ahead

November 2nd, 2005

Apple released the 2nd major upgrade to the OS X Tiger operating system on Tuesay, and after reading reports of generally good install experiences and excellent performance gains I took some time out to install it this evening.

After the 93MB download, I can report one more smooth installation and a rather nice performance boost. The first thing I checked out was Safari passing the Acid 2 Test. Not only does Safari pass that web standards mile stone in this latest version, but it definitely feels snappier than it has in the past—which is no mean feat.

The application I was most worred about was Mail.app. I’m very picky about the way my mail is recieved and stored, probably because—after BBEdit—it’s the app I spend the most time using on a day-to-day basis. All my plugins, inlcuding Mail.appetizer, Mail Tagsare still working perfectly.

Everything is Rosy with the world, so if you’ve been waiting for a few glowing endorsements of this upgrade then here’s another one you can add to the list.

View archives