[thelist] Submitting a form with javascript

[Jeff Howden]

hershel,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Hershel Robinson
>
> > i have done this in the past -- styled a button to
> > look like a hyperlink -- at the client's request in
> > a closed intranet... i found it was faster, easier,
> > and offered more flexibility to use CSS...
>
> Faster and easier? But then I would have to write JS to
> create a rollover effect. :)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

surely the "cost" of writing a simple color swapping mouseover script is far
less.

what's more, if the browser you have to support is mozilla, it supports the
:hover pseudo-protocol making scripting pointless.  on the other hand, if
it's ie/win you have to support, then just use a behavior attached to the
class you use for your submit buttons.  that behavior can be built to mimic
the :hover pseudo-protocol very nicely.

now the forms aren't potentially broken and they're usable by users without
javascript, even if the intranet *mandates* it (now).

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > 1) some browsers break forms that don't have an actual
> >    submit button meaning you can't use the enter key
> >    to submit the form.  some claim this as a good
> >    thing, but it's not.  it's a disruption of
> >    expected behavior for those users accustomed to it.
>
> But I wrote about a NON-cross browser site, so this is
> not a problem if the ONE browser allows the button.
> (furthermore you could also write JS to handle this)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

great, throw more scripting at a problem that wouldn't exist if you didn't
insist in mangling the ui with javascript to begin with.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > 2) look all around you at data collection forms.  in
> >    practically all the cases a button is used to
> >    submit the data, not a link.  using a link is a
> >    departure from normal ui conventions and will be
> >    nothing but a confusion for your users.
>
> I disagree. Many sites use an image as a submit 'button'
> (especially for searches) and for the casual user, that
> looks more like a link than a button.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

did i say site?  no, i was far more general than that.  i said "data
collection forms".  these could just as easily be preferences/options/input
dialogs.  i suspect that many users interact with these sorts of dialogs far
more than they do with data collection forms on websites.  the fact that
people use graphical submit buttons simply muddies the usability in general,
but doesn't support your claim.

furthermore, *very* few will actually make the image look like a text link.
most sites that use a graphical submit button still use an image that
resembles a button.  so, in the users mind, they consider it a button
because of the form field it sits next to, rather than a link.

[aside: many of the people who use graphical submit buttons are doing so in
a manner that goes against the original intent of the graphical submit
button.  it's not meant to be used to "prettify" a form, but to give the
user a mechanism to send mouse-click coordinates to the server for one
purpose or another (most useful with mapping).]

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > 3) can you really mandate that non-sighted users use
> >    ie as well?  or, are you going to have to succumb
> >    to their need to use a screenreader (which may or
> >    may not be based on the ie web browser control)?
>
> Again, I'm talking about a NON-cross browser site. If
> the site only supports one browser, then YES all users
> would have to use THAT browser. :)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

then what is the visually impaired user supposed to do?

and suppose they do find a way to use the intranet using the mandated
browser along with a screenreader.  which makes more sense (read them
aloud)?

 -Data Entry Form -
 - text - -List Box-
 -Link: Submit
 -End of Data Entry Form -

or

 -Data Entry Form -
 - text - -List Box-
 - submit -
 -End of Data Entry Form -

which one is more apparent how to submit the form?

now, i gave your example a slight improvement by using text in the link, but
the fact that it's a link makes it really confusing.  sure, with time the
user can get past the fact that it says "Link: ".  however, forms *should*
be slightly more intuitive than that.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > 4) what do you do if the company gets a wild hair up
> >    their bum and changes their browser standard
> >    internally?
>
> Now you have come to your singular interesting point.
> If that were to happen, then I would just explain to
> them (as they already know) that it will take me X days
> to deal with converting their site to a new browser. :)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

ah yes, job security through vendor lockdown.

sorry, but i still fail to see a reason to use javascript and a link to
submit the form.  it just causes way too many problems.  better to leave the
submit buttons alone or force them into your (or your client's) idea of a
good-looking ui with css.

.jeff

------------------------------------------------------
Jeff Howden - Web Application Specialist
Resume - http://jeffhowden.com/about/resume/
Code Library - http://evolt.jeffhowden.com/jeff/code/