[thelist] Form Submittal on Enter

[.jeff]

andrew,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Andrew Clover
>
> > furthermore, if you know the first is going to be the
> > default, that's easy to account for in the html,
> > whether or not the default one appears to be the last
> > on the rendered page.
>
> It's not easy in every case. Vertical positioning is
> very tricky to hack this way. For example a common
> scenario is a shopping cart:
>
>   Product1   qty: [ 1      ]  < Change >
>   Product2   qty: [ 2      ]  < Change >
>
>   Address: [ blah blah                 ]
>
>                               < Submit >
>
> Should one enter an address and press enter, the
> default-button selected is the first 'Change', of
> course.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

it wouldn't be in the form if i designed it.  that's because i'd likely have
one form up top for controlling the quantities and another below for the
address.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> It's not really practical to reposition the buttons in
> this case, as you won't know how long (in pixels) the
> form is going to be.(*)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

if you really must make it one form, it's still possible to make the
"submit" button be the default.  you don't even need to know how big the
rest of the form will be to pull it off either.  you just need to extend the
same table hack i used.  it's not elegant, but it's certainly possible.

while i see the merits of having one form (ie, the user updates *any* info
and clicking *any* of the buttons updates it on the server), i'd argue the
use of a single form for this.  changing the quantity and pressing the
"enter" key should not click the "submit" button, but rather the "change"
button.  clicking the "submit" button would/should trigger the client-side
validation for the address information if javascript is enabled and then the
server-side validation.  if you're simply changing the quantity, this sort
of validation shouldn't occur yet.  this could almost be considered rude as
you're subtly telling the user they can't update quantities in their basket
without providing personal information, which isn't really what's going on
at all.  what's really going on is the form is poorly designed and should
really be split into two distinct forms, at the least.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> And also it's a hideous hack of course. ;-)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i've seen my share of hideous hacks, this certainly does *not* qualify as
one.  it'd be a hack if it was to make it work for several problematic
browsers.  however, since this technique is supported by any browser that
supports tables, i don't find it to be a hack.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Still, it's not explicitly documented, and little-known,
> that the first button is going to be the default.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

true.  it's also not very common for the casual web developer to build forms
with more than one submit button and therefore have no need of this
knowledge.  ;p

it's fairly easy to figure out though.  ie even gives you an indication of
which one is the default by placing a thin, single-pixel black outline
around the default button when any form elements have focus (including
labels or fieldsets).

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > the server-side script or the client-side script?  if
> > it's the server-side, how would it know which one was
> > default unless you implicitly coded the default in?
>
> That's the idea. At least that way you do get a choice
> which button to consider the default.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

actually, there's nothing stopping you from doing that now -- though getting
the browser to comply by not sending name/value pairs for the active button,
according to the html spec, is going to be difficult.  there are rules to
follow when defining which controls are successful.  if a control is
successful, the browser has to send the name/value pair.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> It might be easier to put that information at the
> client-side, but neither HTML nor IE's extensions to
> it currently give us that ability. (Short of nasty hacks
> like a hidden first submit button to swallow enter
> keypresses.)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

now *that* i consider a nasty hack.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > > This would also have matched the established
> > > behaviour of passing no pair when submitting a
> > > single-text-field form with enter.
> >
> > without a submit button of any kind?  or just one
> > single-line text input?
>
> With just one single-line text input and one submit
> button.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i'd actually rather the browser would send the name/value pair of the
default button.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > let's just say i'd rather not cloud the issue with any
> > anti-ms rhetoric.  ;p
>
> MS smell slightly of cabbage! :-p
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

no, that'd be me.  i had corned beef and cabbage last night for dinner.
mmmmmmmmmmmm!

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/