Re: reset-button + "validate by direct input"

Jukka K. Korpela wrote:

> The common design of putting a submit button on the left or
> (!) on the right of a destruction button greatly promotes
> misclicking.

The most common design is "Submit" on the left, if there is a
"reset" at all.  In other words I've never seen it the other
way around (that is on Latin pages).

> Get another browser, then, if this bothers you and the matter
> is relevant to you.
[...]
> Besides, if each software _has_ a "soft reset", then you
> won't need a "reset button", do you?

The "reset"-button _is_ the required soft reset for HTML-forms,
that's how it used to be implemented.  CSS-fans can hide it if
they don't like it, and their browsers don't need it.

> As I wrote, if you want a wipeout functionality, get a
> browser that has it

I'm perfectly happy with my browsers as long as I can disable
JavaScript and CSS for those which (only) claim to support it.

> Using a class attribute is guaranteed to not guarantee
> anything; remember that CSS is just optional presentational
> suggestions.

Users tending to click on every wrong button will also use a
browser where CSS makes sense.  It's old browers and / or dumb
devices without CSS where a reset button can be useful.

> It is far more common to want to type in something and have
> it validated, then do other things, than to use the feature
> repeatedly.  Hence the argument does not apply.

Now I've never before used it, after all it's almost the same
as file upload.  Using this form without clipboard would be a
royal PITA, nobody wants to type in the DOCTYPE and head.

When the initial input is in the clipboard it's a matter of
taste how to continue after an error, edit the source followed
by another round of copy and paste, or edit the text in the
form.  I used the former approach, because I wanted to check
the edited source also locally with Netscape and Lynx.  And
therefore I had to "clear" / "reset" the erroneous form input.

> Even if it did, the destruction button should not be close
> to the submit button.

If there is a "reset" button at all it has to be where users
expect it, right after the "submit", because that's the common
design.  Putting this button elsewhere is a bad plan:  The law
of least astonishment.

Any "oops, now all my input is lost again" button MUST NOT be
offered at unusual places (if it's offered at all).

> Again, if your browser does not do things that you regard as
> essential, consider getting another browser.

Whenever web "masters" are lost they tell their users to get
a new browser.  "This site best viewed with" (whatever).  Or
they spamvertize "Web standards" on their pages, asking users
to upgrade their browsers, because they are unable to create
simple backwards compatible pages.

> The more complex a form is, the more damage a destruction
> button will do.

This is no destruction, it simply resets the defaults.  All
those funny selected="selected", value="whatever", etc.

> If "reset" is important for a particular form, then _make_
> it a decent reset. This means, with the present technology,
> a button created with JavaScript and working via JavaScript,
> resetting all the fields or selected fields, _after_
> prompting for confirmation.

Now I've no problem with this, add some onclick confirm (TBD)
to the reset button, it won't disturb me with disabled JS 1.1.

For links I sometimes use this onclick-approach:
"return confirm('JavaScript 1.1 won'+unescape('%27')+'t work')"

Not yet tested for reset (nowhere on my pages do I need reset),
but maybe a similar idea could do this trick also for "reset".

 [remove "validate by direct input" form from the main page]
> Regarding the main page of the validator, I tend to agree
> with the idea. It does not need the direct input field but
> links to pages with such a feature.

In the spirit of "form follows function":  Apparently we still
agree on the form, if not the function.

 [missing extended form features]
> the page  could contain some JavaScript-generated buttons for
> inserting some "standard" document skeletons

ACK, see above.  Maybe two skeletons, HTML 4 transitional and
XHTML 1.1.  The choices could be:  "input a complete document"
(as is), "input HTML body", "input XHTML body" (where the
latter would generate the prologue from <?xml... up to <body>,
plus the </body></html> epilogue).

> Perhaps, actually, best with links to versions of the page
> with such stuff prefilled in the textarea elements, so that
> we don't need client-side scripting at all.

Sure, client-side scripting is optional at best, like CSS.

> Only geeks are interested in "recent updates".

No.  When pages that used to be "valid" are suddenly "invalid"
(those quotes used intentinoally) I was as _upset_ as the TAOP
author, that hit me a few days before or after 911 when a new
validator decreed that I have to learn what's wrong with &#128;
(all geeks of course know this).

It's the _main_ page, it must offer the most important links,
essential services, recent news, and any required legalese.

                           Bye, Frank

Received on Wednesday, 28 September 2005 22:45:01 UTC