I have just finished a new feature for my family homepages (www.glover.gen.nz) to allow members of the family to maintain their own set of links in a side bar off the main screen This involves them logging in, and seeing a list of links or people, with the option of adding or editing new links or people.
There are three non JS ways to submit a form that I know of.
1. <input type=”submit” name=”xyz” value = “Edit”> produces a button with the word Edit on it, and when the form is posted, the server script gets a pair of fields, the named and the value. As I need a number of identical buttons, each to do a different thing, this will not work for me.
2. <input type=”image” name=”xyz” value = “key=n” alt=”Edit> produces a button with either an image on it, or the alt text ‘Edit’ on it. The server sees three pairs of fields, the name and value, and the name_x and name_y fields and values. This is great, as the button can look identical for each edit button, but the value returned is unique to the button. Problem is, Microsoft have not implemented this correctly in any browser up to IE7 (and I think IE8). Firefox gets the three pairs of fields, Microsoft only gives the x and y co-ordinates. The normal workarounds for this bug don’t work, as I need those identical buttons and unique values.
3. <button type=”submit” name=”xyz” value = “key=n”>Edit</button> again produces a button with the text Edit on it, but the pair of fields returned are the name and value. The additional bonus with this format is that the button button can be styled using style sheets, so in my case, I removed the borders padding and margins, changed the background colour to the same as the page, and right justified the text. This sounds perfect, how can they get this one wrong? Well, Microsoft managed it! FireFox returns the name/value pair as expected, Microsoft ignore the W3 recommendations, and return the name, and the inner html of the button, i.e the bit between the <button> and the </button>! This of course means that it is as useless as the second option!
So, what to do? I didn’t want to rewrite the control logic of the page, which depends on the presence of various submit buttons within a form to decide which server side script to run. Last night, while lying awake thinking it through, it came to me. Not the prettiest solution, not even elegant, but quick and effective. What I did looks a bit like this:
<button class=”famnetimgbut” type = “submit” name = “editperson” alt=”Edit” value=”$key”>
What the browser sees is a button with Thiskey=1,Edit, but the user only sees Edit, and the Thiskey=1, is not displayed. What FireFox sees is the name/value pair (editperson => 1). What IE sees is the pair (editperson =>Thiskey=1,Edit) – actually it sees all the <span style=”display:none;”></span> stuff too but thats not relevant. When the edit person function is called in response to the editperson field being present, the code checks for the occurrence of Thiskey=, removes it, and everything after the comma and puts it in the key field,if Thiskey= is not present, it uses the field as is. Like I said, not elegant or pretty, but gets around the MS bugs.
In case you think MS is useless and FireFox is great, the other issue I dealt with is the clumsy way that FireFox populates password fields if you have auto-population of passwords switched on on the browser. It looks for the first field which is <input type=”password”> and populates it with the password value remembered for the site! When the application is adding new users, it asks for a password and a verification of password for the new user, and FireFox kindly fills in the incorrect password! As there is functionality to add new users, and to allow users to change passwords, this is not a desired outcome! Especially as only one of the two password fields present is populated!
<input style=”display:none;” type = “password”>
That did the trick. So FireFox 1, Microsoft 2!