Sending Form data to the server can be achieved in several ways, all of them with their pros and cons. It is especially tricky to create a form that has to be accessible, look great and allow for internationalisation (i18n). This post discusses the different options and offers a JavaScript that works around most issues.

The most accessible and least pretty way to submit a form is via a submit button.

Pros:

• they resize with the font settings
• their text content is determined by the value attribute, therefore it is is easy to localise them

Contras:

• You cannot style them consistently across browsers, and they cannot get rollover states ¹

The other option is to use an input element with the type “image”, which enables you to use any image to submit the form

Pros:

• You have total control over the look and feel

Contras:

• Whilst applying a proper alternative text makes the images accessible to blind visitors, images don’t scale when the font size gets changed, which means they are not 100% accessible.
• i18n can become a maintenance issue, as you need to create (or automatically generate via the backend) images for each language.

Together with JavaScript, text links can be used to submit a form.

Pros:

• You have total control over the look and feel
• Text links scale with the font settings
• i18n is dead easy, as it is text content of the page, not even alternative text in attributes

Contras:

• requires JavaScript to work

Putting them all together

If you use a small JavaScript to check the document for submit buttons and dynamically replacing them with text links, you’ll get the best of both worlds:

• users without JavaScript will get normal submit buttons
• users with JavaScript styled text links.

See the demonstration page and try it alternately with JavaScript on and off.

The script that replaces the submit buttons uses Unobtrusive JavaScript and allows you to define a special class to add to each of the replacement links. The links will also have the same ID as the original submit button and their value as text content.

Feel free to use it and report any issues/problems here.²

¹ It is debateable if you should design your own form controls anyways, after all the users knows how forms looks in their environment and some browsers/operating systems offer rollover states for submit buttons.

² One issue is that if you don’t have any submit or image button in the form you won’t be able to send the form by hitting the enter button on the keyboard. To counterwork this you might want to add another image button or alter the script to hide the submit buttons instead of replacing them.

This question pops up almost weekly on message boards, mailing lists and in chat sessions:

How can I remove the ugly border around an image when it is linked?

I am amazed that this is still a question that needs to be asked, but the trick to remember is that when you put an image inside a link, like:

Then the browser puts a border around the image in the colour of the link. Therefore, changing the link border setting will not have any effect:

a {border:none; }

Instead, you need to set the image border to “*none*”:

 a img {border:none; }

It might be a good idea to define this as a preset in the beginning of your style sheet, to avoid the need to repeat it over and over again.

Also notice that the setting is “border:none”, which tells the user agent that there should not be a border – if you use “border:0” you expect the User Agent to know how to display a border with a width of 0, which might not be possible.

I hope that this is going to be a post to show up high in google sooner or later, much like the ugly yellow form fields one.

Right now I am working on a project that will be a paypal-esque financial application, and of course security is a big issue with this one.

We had a great meeting talking about security measures that could be added to the forms to ensure that only real users will be able to log-in.

I collected the ones I could think of based on the W3C whitepaper and own experiences and this is the list with pro and contra for each of them: (more…)

I just looked through some of my older scripts and other people’s code and realised that a lot of time we bloat our methods by repeating the same functionality.

This is especially true when it comes to generating a lot of HTML via the DOM.

We keep repeating the same document.createElement and setAttribute lines over and over. Wouldn’t it be more efficient to create those once when initialising our script and then cloning them? (more…)

Back in October, Andy Budd wanted to have min- and max-padding in CSS3, so it seems only fair that for my 200th post here I can also give my $.02 and ask (and maybe stomp my little feet) for something in CSS3 (after all we can celebrate together in well, roughly 2010 when all browsers support it – that is if we still use browsers then):

I want nested declaration blocks!

I basically want them as I hate repeating myself, and I hate repeating code when it is not needed. (more…)