Not Having a Control in the taborder

[Gene Wirchenko]

Dear HTMLers:

I am writing a form handler. One of my co-workers suggested that
I remove the form reset button from the taborder so that it does not
accidentally get invoked.

From a Web search, I see that I can do this with
taborder=-1
but this is contrary to the HTML 4.01 standard which specifies that
the taborder value must be in the range of 0 to 32767.

I want my pages to be as stand-compliant as possible.

Is there a standard-compliant way of doing what I want in HTML?
Or JavaScript?

Sincerely,

Gene Wirchenko

 

[Norman Peelman]

Dear HTMLers:

I am writing a form handler. One of my co-workers suggested that
I remove the form reset button from the taborder so that it does not
accidentally get invoked.

From a Web search, I see that I can do this with
taborder=-1
but this is contrary to the HTML 4.01 standard which specifies that
the taborder value must be in the range of 0 to 32767.

I want my pages to be as stand-compliant as possible.

Is there a standard-compliant way of doing what I want in HTML?
Or JavaScript?

Sincerely,

Gene Wirchenko

http://webcheatsheet.com/HTML/controll_tab_order.php

 

[Gene Wirchenko]

^^^^^^^^
Oops: I meant "tabindex" above and below.

^^^^^^^^

http://webcheatsheet.com/HTML/controll_tab_order.php

That does not work. The page states that 0 means that those
controls will be last in the tab order for getting focus. I do not
want the form reset button to be tabbed to at all.

Sincerely,

Gene Wirchenko

 

[Jukka K. Korpela]

One of my co-workers suggested that
I remove the form reset button

Great idea! The destruction button, misnamed as "reset button", is one
of the most harmful ingredients of HTML forms, see e.g.
http://www.useit.com/alertbox/20000416.html

from the taborder so that it does not
accidentally get invoked.

Oh... then I suppose you have analyzed that your form is one of the rare
cases where the destruction button can actually be useful. Typically,
this would be a data entry form used by a person repeatedly, in manual
input of a set of entries, so that it is actually useful to destroy the
data irrevocably (as it has already been submitted, and you need to
start from a clean form).

Even then, it is almost always better to make the server-side form
handler return a new page to the client.

But assuming that a destruction button is present, consider adding a
confirmation dialog: an onclick event handler that asks for confirmation
("Do you really want to erase all input?"). It should not have "yes" as
the default answer, since people hit Enter all too routinely without
even reading the text. So you probably need something different from the
common confirm().

From a Web search, I see that I can do this with
taborder=-1
but this is contrary to the HTML 4.01 standard which specifies that
the taborder value must be in the range of 0 to 32767.

I want my pages to be as stand-compliant as possible.

Using a negative number for tabindex complies with the "Living HTML
Standard":
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#attr-tabindex

More importantly, it works. If you need to stick to the HTML 4.01
recommendation of the W3C, then I'm afraid you are out of luck. But I
would not take HTML 4.01 too seriously; the W3C doesn't - they have
effectively abandoned it. It's still relevant (it reasonably well
reflects what browsers do, though some parts are unimplemented, and
there is a lot more that browsers do), but it is not being maintained,
and the W3C works in close cooperation with the WHATWG though not in
complete harmony.

If Company Police/Policy or some other authority requires HTML 4.01
conformance, you might cheat a bit and set the "forbidden" tabindex
value in JavaScript. But tabindex = -1 won't get caught by markup
validators anyway (they don't check the value).

 

[Gene Wirchenko]

Great idea! The destruction button, misnamed as "reset button", is one
of the most harmful ingredients of HTML forms, see e.g.
http://www.useit.com/alertbox/20000416.html


Oh... then I suppose you have analyzed that your form is one of the rare
cases where the destruction button can actually be useful. Typically,
this would be a data entry form used by a person repeatedly, in manual
input of a set of entries, so that it is actually useful to destroy the
data irrevocably (as it has already been submitted, and you need to
start from a clean form).

Ah, no. I will use it to reset to default values. If a database
row is being edited and the form is reset, the field values will
revert to what was read.

Even then, it is almost always better to make the server-side form
handler return a new page to the client.
Why?

But assuming that a destruction button is present, consider adding a
confirmation dialog: an onclick event handler that asks for confirmation
("Do you really want to erase all input?"). It should not have "yes" as
the default answer, since people hit Enter all too routinely without
even reading the text. So you probably need something different from the
common confirm().

I already have a confirmation dialog. It does use confirm()
though.

I suppose I will come up with something later.

Using a negative number for tabindex complies with the "Living HTML
Standard":
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#attr-tabindex

"Living" is right. It was last changed Wednesday.

More importantly, it works. If you need to stick to the HTML 4.01

Maybe. I cannot count on it. That is why to concern myself with
a standard.

recommendation of the W3C, then I'm afraid you are out of luck. But I
would not take HTML 4.01 too seriously; the W3C doesn't - they have
effectively abandoned it. It's still relevant (it reasonably well
reflects what browsers do, though some parts are unimplemented, and
there is a lot more that browsers do), but it is not being maintained,
and the W3C works in close cooperation with the WHATWG though not in
complete harmony.

If Company Police/Policy or some other authority requires HTML 4.01
conformance, you might cheat a bit and set the "forbidden" tabindex
value in JavaScript. But tabindex = -1 won't get caught by markup
validators anyway (they don't check the value).

I do not care if validators do not catch the error. If it is an
error, then it is an error. I am reluctant to use such.

Sincerely,

Gene Wirchenko

 

[Jukka K. Korpela]

Why?

In a process of filling in data, submitting a form, starting over, the
user should not be bothered with removing previous data. Neither should
he be given the opportunity of accidentally destroying data he has entered.

I do not care if validators do not catch the error. If it is an
error, then it is an error. I am reluctant to use such.

I see your point, but who died and made the W3C God? It's an industry
consortium, which has made great contributions to web technologies and
specifications. But in the realm of HTML, they just painted themselves
in a corner, decorated with X's all over. HTML 4.01, defined in 1999
(and almost identical with the original HTML 4.0, 1997 vintage), is
becoming more and more historical. And it was never implemented in any
browser, though most modern browsers come close.

 

[Gene Wirchenko]

In a process of filling in data, submitting a form, starting over, the
user should not be bothered with removing previous data. Neither should
he be given the opportunity of accidentally destroying data he has entered.

Pardon me. I think you are making some unjustified assumptions.

Starting over could mean initialising to starting values. (These
could be non-blank values.) This does not require the user to remove
previous data.

It could also mean continue with the previous data. (One use
case for this is when my boss is setting charging rates and may wish
to set some rates where most of the rate data is the same as the
previous row. We have general rates, client-specific rates, and
project-specific rates.) In this case, the user wants the previous
data present.

I might go either way, or both, on the above.

I am not giving the user the opportunity to destroy his data
accidentally (any more than just using the computer enables him to do
so). A form reset will not change the database.

I see your point, but who died and made the W3C God? It's an industry

So that is it. I forgot the sacrifice. Look, doesn't all the

consortium, which has made great contributions to web technologies and
specifications. But in the realm of HTML, they just painted themselves
in a corner, decorated with X's all over. HTML 4.01, defined in 1999
(and almost identical with the original HTML 4.0, 1997 vintage), is
becoming more and more historical. And it was never implemented in any
browser, though most modern browsers come close.

It is a standard. It is accepted. If there is a better
standard, what is it? Is that Living Standard really a standard, or
is it just called one? If I have to write non-standard code, I will,
but I really prefer not to.

Sincerely,

Gene Wirchenko

 

[Jukka K. Korpela]

Pardon me. I think you are making some unjustified assumptions.

I'm afraid there's a misunderstanding here. In my note, "then" referred
to a case where "a data entry form [is] used by a person repeatedly, in
manual input of a set of entries"

It is a standard.

To be exact, it isn't. The W3C is not a standards organization. There is
an HTML standard, by ISO, but very few people take it seriously, and
still fewer actually deploy it.

If there is a better
standard, what is it?

There isn't.

Is that Living Standard really a standard, or
is it just called one?

"Living Standard" is an oxymoron, of course.

If I have to write non-standard code, I will,
but I really prefer not to.

When there is no real standard, there can be no standard-conforming code
either. We can just make a reasonable guess on what will be supported in
the future and do some study to see what works today. Since negative
tabindex values are supported by modern browsers and since they have
reasonable use cases, support to them will hardly be removed from
browsers, and future specifications will most probably allow them.

 

[Norman Peelman]

^^^^^^^^
Oops: I meant "tabindex" above and below.



That does not work. The page states that 0 means that those
controls will be last in the tab order for getting focus. I do not
want the form reset button to be tabbed to at all.

Sincerely,

Gene Wirchenko

While the page does not state that at all, it does appear to be the
case. "-1" does remove a control from the tab order though.

 

[BootNic]

I am writing a form handler. One of my co-workers suggested that
I remove the form reset button from the taborder so that it does
not accidentally get invoked.

From a Web search, I see that I can do this with taborder=-1 but
this is contrary to the HTML 4.01 standard which specifies that
the taborder value must be in the range of 0 to 32767.

I want my pages to be as stand-compliant as possible.

Is there a standard-compliant way of doing what I want in HTML?
Or JavaScript?

I believe an input not displayed or disabled will not be in the tabindex.

<style type="text/css">

#recheck ~ [type='reset'] {
display: none;
}

#recheck:checked ~ [type='button'][value='Reset'] {
display: none;
}

#recheck:checked ~ [type='reset'] {
display: inline;
}

</style>

<!-- http://code.google.com/p/ie7-js/ -->

<!--[if lt IE 9]>
<script
src="http://ie7-js.googlecode.com/svn/version/2.1(beta4)/IE9.js">
</script>
<![endif]-->

<div>
<input id="recheck" type="checkbox">
<label for="recheck">Enable Reset</label>
<input type="button" value="Reset" disabled="disabled">
<input type="reset">
</div>




--
BootNic Fri Mar 9, 2012 08:41 pm
It is well known that "problem avoidance" is an important part of problem
solving. Instead of solving the problem you go upstream and alter the system
so that the problem does not occur in the first place.
*Edward de Bono*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9asWIACgkQOcdbyBqMFBE4VQCfYk7E3NZOjgBw2krkWO+W8igO
S1QAoLzVALOgmi39eW5HMJFK3b0GjG8O
=MRxQ
-----END PGP SIGNATURE-----