Clicking on Disabled Controls: What Happens?

Gene Wirchenko · Apr 13, 2012

Hello:

This is posted to both comp.lang.javascript and alt.html, because
it might have to do with either JavaScript or HTML. I expect that it
is the former, but.

My form handler is coming along slowly, but the results are nice.
I am now adding buttons for handling modes (adding, updating,
deleting). When data entry is being done, only some of the controls
are enabled. If a button or input control is disabled, it can get
weird.

Suppose that DE is being done. Call the current input control
Workpoint.

If I click on something that is not enabled, the validation for
Workpoint executes.

If there is a validation error, an alert is issued, and the focus
gets put back to Workpoint. (Spare me that this not how Web pages
should work. "Sticky" focus on errors is what is needed and wanted.)

However, if there is not a validation error, the focus goes off
somewhere I know not where, AND I CAN NOT TELL WHERE. I want the
focus back on Workpoint.

The focus, despite not showing on the form, can be moved. If I
press [Tab] immediately after this, the focus moves to the first
enabled control on the form. This is weird.

Ideally, I would like that when a non-enabled item is clicked on,
that the click is ignored, that is, it is as if nothing had happened.

If I can not have that, I would, at least, like to have the focus
returned to Workpoint whether the validation succeeds or not.

Unfortunately, document.currentElement does not give me a value
that I can work with so that I can detect the weirdness. How can I
tell where the focus is going? (I think I would then check if the
control is disabled, and if so, set focus back to Workpoint.)

Sincerely,

Gene Wirchenko

Evertjan. · Apr 14, 2012

Gene Wirchenko wrote on 13 apr 2012 in comp.lang.javascript:

This is posted to both comp.lang.javascript and alt.html, because
it might have to do with either JavaScript or HTML. I expect that it
is the former, but.

My form handler is coming along slowly, but the results are nice.
I am now adding buttons for handling modes (adding, updating,
deleting). When data entry is being done, only some of the controls
are enabled. If a button or input control is disabled, it can get
weird.

Only if your code does not account for those states.
I suggest you write code that incorporates all possible states.

Suppose that DE is being done. Call the current input control
Workpoint.

What is DE?
What is Workpoint?

If I click on something that is not enabled, the validation for
Workpoint executes.

Impossible, unless a higher onclick is being invoked,
and then only in IE, not in Chrome. Try:

<body onclick='alert("body")'>
<input type='submit' disabled>

If there is a validation error, an alert is issued,

What validation error?
Of javascript or html?
Or of a function called myValidation() ?

and the focus gets put back to Workpoint.

What is Workpoint?

(Spare me that this not how Web pages
should work. "Sticky" focus on errors is what is needed and wanted.)

But if the execution differs between IE and Chrome [and the other major
browsers], that is not how web pages are supposed to work, and your code
is incomplete or faulty in that sense.

However, if there is not a validation error, the focus goes off
somewhere I know not where, AND I CAN NOT TELL WHERE. I want the
focus back on Workpoint.

Only if your code does not specify where the focus should go.
change your code to be ready for all states.

If a text input does not have a value that is acceptable
[is that what you mean by validation?]
then the user should get a warning and should be returned to the state
where he [she?] can correct that input or by his choice cancel the
process.

What is Workpoint?

The focus, despite not showing on the form, can be moved.

That depends on the browser, focus should be visible it is on a form
element that can be used for input under html.

You should set the focus on such element if the default is not doing that
crossbrowserwize.

If I
press [Tab] immediately after this, the focus moves to the first
enabled control on the form. This is weird.

No, that is standard, if the focus is not on an inputtable input element.
However if it is, it works as expected.
Try tabbing and shift-tabbing here:

<body onload='document.getElementById("q").focus()'>
<form>
<input>
<input id=q>
<input>
<input>
</form>

Ideally, I would like that when a non-enabled item is clicked on,
that the click is ignored, that is, it is as if nothing had happened.

That is blissfully ignored in Chrome,
and outwardly doing the same in IE if you programme accordingly.

It would be nice if we could ignore IE altogether.

If I can not have that, I would, at least, like to have the focus
returned to Workpoint whether the validation succeeds or not.

What is Workpoint, the ID of an input element??

You can do that:

<form onclick='document.getElementById("Workpoint").focus()'>

or perhaps 'better':

function myValidation(inp) {
if (validateMe(inp))
document.getElementById("Workpoint").focus()
else
document.getElementById("Workpoint").focus();
}; // ;-)

Unfortunately, document.currentElement does not give me a value
that I can work with so that I can detect the weirdness.

There is on weirdness if your programme code is prepared for all states.

How can I
tell where the focus is going? (I think I would then check if the
control is disabled, and if so, set focus back to Workpoint.)

You can tell if your code is the master, as the focus then goes wher you
want it to go [not counting that the user sets the focus somewhere else
by mouse pointing cum clicking or by tabbing or shift-tabbing.

If document.currentElement cannot reliably help you here, there is no
other javascript reachable system variable that shows the focus,
methinks. That only zero one element can have focus is an incidental fact
of life, as seen from the perspective of a single element.

Programmatically then you only know the focus state of elements where an
eventlistener signals it, I think:

<element id='el17'
onfocus = 'storeFocusPosition(this)'
onblurr = 'clearFocusPosition()'
[The onblurr being necessary, when you have not set the onfocus for all
possible elements on the page, which seems impossible on a scale larger
than a minimal example.]

Jeff North · Apr 14, 2012

| Hello:
|
| This is posted to both comp.lang.javascript and alt.html, because
| it might have to do with either JavaScript or HTML. I expect that it
| is the former, but.
|
| My form handler is coming along slowly, but the results are nice.
| I am now adding buttons for handling modes (adding, updating,
| deleting). When data entry is being done, only some of the controls
| are enabled. If a button or input control is disabled, it can get
| weird.
|
| Suppose that DE is being done. Call the current input control
| Workpoint.
|
| If I click on something that is not enabled, the validation for
| Workpoint executes.

That is correct because the input control has lost focus and the
onBlur event has been triggered. It doesn't matter what you click on
(a disabled control, a blank space on the page, another input control,
scrollbars) the same thing will happen.

| If there is a validation error, an alert is issued, and the focus
| gets put back to Workpoint. (Spare me that this not how Web pages
| should work. "Sticky" focus on errors is what is needed and wanted.)
|
| However, if there is not a validation error, the focus goes off
| somewhere I know not where, AND I CAN NOT TELL WHERE. I want the
| focus back on Workpoint.

You need to tell the browser which control is to have focus.

| The focus, despite not showing on the form, can be moved. If I
| press [Tab] immediately after this, the focus moves to the first
| enabled control on the form. This is weird.

Not really, the focus is where you last clicked.

Denis McMahon · Apr 14, 2012

What is DE?
What is Workpoint?

He defined these:

DE is an abbreviation for data entry, ie the user is using the web page
for data entry, as opposed to editing/updating existing data, or just
viewing the current data.

Workpoint he defined as "Call the current input control Workpoint." By
this, I assume that "workpoint" refers to the input, select or textarea
that has just been changed.

The he said "If I click on something that is not enabled, the validation
for Workpoint executes." .... presumably triggered by the onchange()
event for the element that was active and changed, ie the "workpoint"
element.

I suspect that what is needed at the end of the validation routine for
any given workpoint is something like (assuming workpoint is the current
input control):

if ( data_validates ) {
// set workpoint to next active input on form
}
else {
alert( "Please correct the data in the indicated element" );
workpoint.select();
}
workpoint.focus();

So that the focus jumps to the next active control. Determining the best
method of finding the next active control is beyond the scope of the OPs
question.

Rgds

Denis McMahon

Evertjan. · Apr 14, 2012

Denis McMahon wrote on 14 apr 2012 in comp.lang.javascript:

He defined these:

DE is an abbreviation for data entry, ie the user is using the web
page for data entry, as opposed to editing/updating existing data, or
just viewing the current data.
Okay.

Workpoint he defined as "Call the current input control Workpoint." By
this, I assume that "workpoint" refers to the input, select or
textarea that has just been changed.

Does not ring a bell.

The he said "If I click on something that is not enabled, the
validation for Workpoint executes." .... presumably triggered by the
onchange() event for the element that was active and changed, ie the
"workpoint" element.

I suspect that what is needed at the end of the validation routine for
any given workpoint is something like (assuming workpoint is the
current input control):

Well yes, but my questions are to prevent that we should assume and guess
what the OP means, and possibly even probably guess wrongly.

if ( data_validates ) {
// set workpoint to next active input on form
}
else {
alert( "Please correct the data in the indicated element" );
workpoint.select();

Wouldn't a select() also do a focus() ?? [not tested]

Denis McMahon · Apr 14, 2012

Denis McMahon wrote on 14 apr 2012 in comp.lang.javascript:

Does not ring a bell.

Feh - go back and look at the OP. He defined "workpoint" with the exact
text and sentence I quoted:

"Call the current input control Workpoint."

Well yes, but my questions are to prevent that we should assume and
guess what the OP means, and possibly even probably guess wrongly.

Well yeah, but the OP defined the terms he was using pretty specifically.

Wouldn't a select() also do a focus() ?? [not tested]

Probably, didn't test either, but in any case, whatever input element
workpoint is pointing at afterwards gets the select to move his input
focus to where he wants it now.

Although thinking about it, I didn't check that the sequence:

element.select();
element.focus();

in text / textarea doesn't de-select when it focuses either! Or what
happens when you "select" on other input controls than textarea and text.
I imagine select is valid for password and hidden, but for other input
types and select / option list?

Rgds

Denis McMahon

Stefan Weiss · Apr 14, 2012

[Followup-To set to comp.lang.javascript; I don't read alt.html]

If I click on something that is not enabled, the validation for
Workpoint executes.

Don't count on it. Clicking on a disabled text input field in Firefox 11
will not cause the current element to lose focus, nor will the change
event fire. Other browsers handle this situation differently.

If there is a validation error, an alert is issued, and the focus
gets put back to Workpoint. (Spare me that this not how Web pages
should work. "Sticky" focus on errors is what is needed and wanted.)

Okay, so you're dead set on something you know will cause some criticism
(at least in this group). Do as thou wilt, and all that, but there are
other people reading our posts, and they should know why alert()+focus()
is not a good way to do client side form validation.

I'll spare you the details if you're not listening anyway, but I will
say that I'm pretty sure you will give up your insistence on this
"feature" at some point. I've been down that road in the past (years
ago). The customer wanted it, I didn't see anything terribly wrong with
it, it got developed and deployed. Three months later, we were all sick
of the constant alerts, and I changed the form validation code to be
less patronizing and more flexible. User makes an error -> field is
marked as invalid, and a way to see the error message is provided for
each field (for example, an icon which will show the error message on
hover). The user can continue to fill out the form, but will be
prevented from submitting it (you can show an alert then, if you must).
In addition to avoiding the technical issues you mentioned, this will
allow the user to fill out the form in whatever order they want.

Consider this example: user is on the phone with an angry customer, and
begins filling out a trouble ticket form. The first field is the
customer name, and it's a required field. The customer doesn't know that
and gives the error description first. User wants to tab to the text
area to write down the details, but can't, because the focus is
constantly reset to the first field. Maybe that's a contrived example;
my point is that filling out forms in a random order, with temporarily
missing/incomplete/erroneous data, should be possible with a decent web
application (within limits). Submitting the form should not.

However, if there is not a validation error, the focus goes off
somewhere I know not where, AND I CAN NOT TELL WHERE. I want the
focus back on Workpoint.

The focus, despite not showing on the form, can be moved. If I
press [Tab] immediately after this, the focus moves to the first
enabled control on the form. This is weird.

Is it? When the body has focus (which it will in Chrome, for example), a
tab will set the focus to the first available input (observing tabindex,
if set).

Ideally, I would like that when a non-enabled item is clicked on,
that the click is ignored, that is, it is as if nothing had happened.

If I can not have that, I would, at least, like to have the focus
returned to Workpoint whether the validation succeeds or not.

Unfortunately, document.currentElement does not give me a value
that I can work with so that I can detect the weirdness.

Did you try document.activeElement?

Be sure to check for browser support with that. AFAIK, it's supported in
the current releases of all major browsers. If you're in an intranet
with a browser monoculture, it might do what you think you need.

- stefan

Gene Wirchenko · Apr 16, 2012

Gene Wirchenko wrote on 13 apr 2012 in comp.lang.javascript:

Only if your code does not account for those states.
I suggest you write code that incorporates all possible states.

How fatuous!

Of course, I am trying to write code that handles all possible
cases. That is why I post questions to these newsgroups.

What is DE?

A common abbreviation in the industry for "Data Entry".

What is Workpoint?

Reread the second sentence of the paragraph.

[snip]

You sure work hard to misunderstand.

Sincerely,

Gene Wirchenko

Gene Wirchenko · Apr 16, 2012

That is correct because the input control has lost focus and the
onBlur event has been triggered. It doesn't matter what you click on
(a disabled control, a blank space on the page, another input control,
scrollbars) the same thing will happen.

Not ideal for my purposes, but I understand that this is the way
it is, at least, with IE 9.

You need to tell the browser which control is to have focus.

First, I need to detect that I have to. The onfocus for the
disabled control (if it is a control that is clicked on) does not
fire. If it did, I could simply check that the control was disabled,
and if so, then push the focus back.

Though, if the click is on something not a control, that approach
would not work. (Maybe, there is something DOMish that would solve
this. I do not know much about manipulating via the DOM.)

I need to know where to put the code to set the focus back. Since
I am unable to detect which object is getting focus, becoming active,
or whatever it is, I do not know where to put the code.

| The focus, despite not showing on the form, can be moved. If I
| press [Tab] immediately after this, the focus moves to the first
| enabled control on the form. This is weird.

Click to expand...

Not really, the focus is where you last clicked.

Actually, no. I can click on a disabled input control later on
the form, then tab, and the focus moves to the first enabled control,
and this is before both Workpoint and the control just clicked on.

Just now, looking for clickdown/clickup events (which do not
exist), I saw mouseover. I think that I may try seeing if that fires
on a disabled control. If so, I could save that. Hmm, DE will not
follow the mouse, but I could save the control, and if it differs from
Workpoint and is disabled, then I know that I have to do something.

I wish this were easier.

Sincerely,

Gene Wirchenko

Jeff North · Apr 16, 2012

| On Sat, 14 Apr 2012 23:58:59 +1000, Jeff North <[email protected]>
| wrote:
|
| >On Fri, 13 Apr 2012 12:12:17 -0700, in comp.lang.javascript Gene
| >Wirchenko <[email protected]>
| >
| >>| Hello:
| >>|
| >>| This is posted to both comp.lang.javascript and alt.html, because
| >>| it might have to do with either JavaScript or HTML. I expect that it
| >>| is the former, but.
| >>|
| >>| My form handler is coming along slowly, but the results are nice.
| >>| I am now adding buttons for handling modes (adding, updating,
| >>| deleting). When data entry is being done, only some of the controls
| >>| are enabled. If a button or input control is disabled, it can get
| >>| weird.
| >>|
| >>| Suppose that DE is being done. Call the current input control
| >>| Workpoint.
| >>|
| >>| If I click on something that is not enabled, the validation for
| >>| Workpoint executes.
| >
| >That is correct because the input control has lost focus and the
| >onBlur event has been triggered. It doesn't matter what you click on
| >(a disabled control, a blank space on the page, another input control,
| >scrollbars) the same thing will happen.
|
| Not ideal for my purposes, but I understand that this is the way
| it is, at least, with IE 9.

You are fighting the standard GUI guidelines. You will only come to
grief with this type of thinking from both the programmers and users
perspectives.

| >>| If there is a validation error, an alert is issued, and the focus
| >>| gets put back to Workpoint. (Spare me that this not how Web pages
| >>| should work. "Sticky" focus on errors is what is needed and wanted.)
| >>|
| >>| However, if there is not a validation error, the focus goes off
| >>| somewhere I know not where, AND I CAN NOT TELL WHERE. I want the
| >>| focus back on Workpoint.
| >
| >You need to tell the browser which control is to have focus.
|
| First, I need to detect that I have to.

Incorrect. YOU need to keep track of what controls have the focus so
you can return to it if there is an error or such.

| The onfocus for the
| disabled control (if it is a control that is clicked on) does not
| fire.

And that is standard GUI practice. If you think about it, why should a
disabled control react to anything because if it did then it wouldn't
be disabled.

| If it did, I could simply check that the control was disabled,
| and if so, then push the focus back.
|
| Though, if the click is on something not a control, that approach
| would not work. (Maybe, there is something DOMish that would solve
| this. I do not know much about manipulating via the DOM.)
|
| I need to know where to put the code to set the focus back. Since
| I am unable to detect which object is getting focus, becoming active,
| or whatever it is, I do not know where to put the code.

Try the onFocus event to store the control's name.

| >>| The focus, despite not showing on the form, can be moved. If I
| >>| press [Tab] immediately after this, the focus moves to the first
| >>| enabled control on the form. This is weird.
| >
| >Not really, the focus is where you last clicked.
|
| Actually, no. I can click on a disabled input control later on
| the form, then tab, and the focus moves to the first enabled control,
| and this is before both Workpoint and the control just clicked on.

And that is the way it should work. The disabled control has the
(invisible) focus so when you press the tab key the focus moves to the
next non-disabled control (as you have amply demonstrated).

| >>| Ideally, I would like that when a non-enabled item is clicked on,
| >>| that the click is ignored, that is, it is as if nothing had happened.
| >>|
| >>| If I can not have that, I would, at least, like to have the focus
| >>| returned to Workpoint whether the validation succeeds or not.
| >>|
| >>| Unfortunately, document.currentElement does not give me a value
| >>| that I can work with so that I can detect the weirdness. How can I
| >>| tell where the focus is going? (I think I would then check if the
| >>| control is disabled, and if so, set focus back to Workpoint.)
|
|
| Just now, looking for clickdown/clickup events (which do not
| exist), I saw mouseover. I think that I may try seeing if that fires
| on a disabled control. If so, I could save that. Hmm, DE will not
| follow the mouse, but I could save the control, and if it differs from
| Workpoint and is disabled, then I know that I have to do something.
|
| I wish this were easier.

It is - stop fighting the GUI and your life will be much simpler.

Have you looked at the HTML5 attributes of placeholder and required?

Evertjan. · Apr 16, 2012

Gene Wirchenko wrote on 16 apr 2012 in comp.lang.javascript:

How fatuous!

Of course, I am trying to write code that handles all possible
cases.

But why "weird"?

Surely it is not weird if you do not incorporate certain states.
The results then follow whatever is the way single browser tries
to second guess you.

That is why I post questions to these newsgroups.

Why are again and again prescribing the confine of the responses.

At least my responses are not answers because this is usenet, and not a
helpdesk.

A common abbreviation in the industry for "Data Entry".

What "the" industry?

This is a NG for javascriipt adepts and javascript casual interested,
not specialized for the industrious of an industry,
though they are welnome too,
as long as they not claim the local linguo.

I seem to remember a similar claiming by another group,
some transponders, on linguo, equally not done.

What is Workpoint?

Click to expand...

Reread the second sentence of the paragraph.
[snip]

You sure work hard to misunderstand.

You sure work hard to upset the NG-ers that try to help,
not only you, but also or moreso others
that think they have questions like yours.

So prescribing we do not need to address cross-browser issues and not to
address the user-unfriendliness of your validation-routine does not hold
for a NG.

Gene Wirchenko · Apr 16, 2012

| On Sat, 14 Apr 2012 23:58:59 +1000, Jeff North <[email protected]>
| wrote:

Click to expand...

[snip]

| >You need to tell the browser which control is to have focus.
|
| First, I need to detect that I have to.

Click to expand...

Incorrect. YOU need to keep track of what controls have the focus so
you can return to it if there is an error or such.

I do keep track of it. What I need to detect is that a disabled
item has been clicked on. Then, I could shift focus back. I
currently know of no way to detect this.

And that is standard GUI practice. If you think about it, why should a
disabled control react to anything because if it did then it wouldn't
be disabled.

Exactly, but the focus still shifts. It would make more sense to
me if clicking on something disabled did not case a focus shift. Think
about it for a moment. If something is disabled, why should it do
anything?

Try the onFocus event to store the control's name.

I already know which control had the focus (Workpoint). I need
to detect that the focus is going to go into the weeds. After all, it
is sometimes perfectly legitimate for focus to go off a control -- A
field's validation does succeed sometimes -- and I need to
diferentiate the cases.

| >>| The focus, despite not showing on the form, can be moved. If I
| >>| press [Tab] immediately after this, the focus moves to the first
| >>| enabled control on the form. This is weird.
| >
| >Not really, the focus is where you last clicked.
|
| Actually, no. I can click on a disabled input control later on
| the form, then tab, and the focus moves to the first enabled control,
| and this is before both Workpoint and the control just clicked on.

Click to expand...

And that is the way it should work. The disabled control has the
(invisible) focus so when you press the tab key the focus moves to the
next non-disabled control (as you have amply demonstrated).

Well, no. As I have posted, tabbing does not move to the next
non-disabled control but rather to the FIRST non-disabled control.

[snip]

It is - stop fighting the GUI and your life will be much simpler.

I want the GUI to work for my end users. At this point, clicking
in weird places causes weird things. I want to avoid this. Why does
the GUI make this so difficult?

I also do not want the workflow messed up. If someone
accidentally clicks on Add while updating a row, I would rather than
nothing happened. The GUI makes this difficult.

Have you looked at the HTML5 attributes of placeholder and required?

No.

If worse comes to worse, I may simply give up on the disabled
property. I could come up with two versions of CSS for each control:
normal and pseudo-disabled. In the pseudo-disabled, the control would
get the focus, I could detect that the control is not live, and I
could then send the focus back where it belongs. Mind you, this would
not solve the problem of a click where there is no control.

Sincerely,

Gene Wirchenko

Neil Gould · Apr 16, 2012

Gene Wirchenko wrote:
[big snip]

I do keep track of it. What I need to detect is that a disabled
item has been clicked on. Then, I could shift focus back. I
currently know of no way to detect this.
[...]

Exactly, but the focus still shifts. It would make more sense to
me if clicking on something disabled did not case a focus shift. Think
about it for a moment. If something is disabled, why should it do
anything?

Why is it necessary to display disabled items? I realize that you would like
to have a stable UI for your users, but it may be possible to achieve that
by only presenting relevant options. Two other ideas are to provide a
bell/buzzer event for disabled items, or to use graphic elements that look
like the disabled items but can't be clicked on and won't be part of the tab
order.

Tim Streater · Apr 16, 2012

Neil Gould said:
Gene Wirchenko wrote:
[big snip]

I do keep track of it. What I need to detect is that a disabled
item has been clicked on. Then, I could shift focus back. I
currently know of no way to detect this.
[...]

Exactly, but the focus still shifts. It would make more sense to
me if clicking on something disabled did not case a focus shift. Think
about it for a moment. If something is disabled, why should it do
anything?

Click to expand...

Why is it necessary to display disabled items? I realize that you would like
to have a stable UI for your users, but it may be possible to achieve that
by only presenting relevant options.

I display disabled items in order to display the data to the user. When
they want to edit it, and have the edits be saved, they click the 'Edit'
button, part of the effect of which is to enable all those disabled
textareas. The user then edits, and clicks 'Save'. Part of the tidy-up
action is then to disable the textareas again.

Jonathan N. Little · Apr 16, 2012

Gene said:
| On Sat, 14 Apr 2012 23:58:59 +1000, Jeff North<[email protected]>
| wrote:

Click to expand...

[snip]

|>You need to tell the browser which control is to have focus.
|
| First, I need to detect that I have to.

Click to expand...

Incorrect. YOU need to keep track of what controls have the focus so
you can return to it if there is an error or such.

Click to expand...

I do keep track of it. What I need to detect is that a disabled
item has been clicked on. Then, I could shift focus back. I
currently know of no way to detect this.

IF it is disabled it cannot obtain focus so you "detect" it by detecting
the focus is *not* on it.

Exactly, but the focus still shifts. It would make more sense to
me if clicking on something disabled did not case a focus shift. Think
about it for a moment. If something is disabled, why should it do
anything?

It shifts but not to the disabled control. Use tab or click and see for
yourself:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>template</title>
<script type="text/javascript">
function announce(me){
var msg=document.getElementById('status');
msg.firstChild.nodeValue='Focus on ' + me.id;
}
</script>

</head>
<body>

<form>
<ul>
<li id="status">Status</li>
<li>
<label>foo</label>
<input type="text" name="foo" id="foo" onfocus="announce(this)">
</li>
<li>
<label>bar</label>
<input type="text" name="bar" id="bar" disabled onfocus="announce(this)">
</li>
<li>
<label>baz</label>
<input type="text" name="baz" id="baz" onfocus="announce(this)">
</li>
<li>
<label>bin</label>
<input type="text" name="bin" id="bin" onfocus="announce(this)">
</li>
</ul>
</form>

</body>
</html>

Set value after clicking in field	11	May 9, 2023
Uhhhhh, What can I do next?	6	Nov 25, 2023
Look what I found......	1	Nov 18, 2021
Disabled comments based on IP?	6	Mar 4, 2012
Firefox back-button disabled	1	Oct 10, 2010
How to make an input box enable for only past dates and for the startdate if it falls in the current month?	5	Jun 12, 2023
Input Controls	4	Dec 30, 2011
Button enabling before all inputs are filled and disabling when all inputs are filled	1	Aug 18, 2022

Clicking on Disabled Controls: What Happens?

Gene Wirchenko

Evertjan.

Jeff North

Denis McMahon

Evertjan.

Denis McMahon

Stefan Weiss

Gene Wirchenko

Gene Wirchenko

Jeff North

Evertjan.

Gene Wirchenko

Neil Gould

Tim Streater

Jonathan N. Little

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads