Clicking on Disabled Controls: What Happens?

Discussion in 'HTML' started by Gene Wirchenko, Apr 13, 2012.

  1. 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
    Gene Wirchenko, Apr 13, 2012
    #1
    1. Advertising

  2. Gene Wirchenko

    Evertjan. Guest

    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>
    </body>

    > 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>
    </body>

    > 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.]

    >
    > Sincerely,
    >
    > Gene Wirchenko
    >




    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
    Evertjan., Apr 14, 2012
    #2
    1. Advertising

  3. Gene Wirchenko

    Jeff North Guest

    On Fri, 13 Apr 2012 12:12:17 -0700, in comp.lang.javascript Gene
    Wirchenko <>
    <> wrote:

    >| 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.

    >| 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
    Jeff North, Apr 14, 2012
    #3
  4. On Sat, 14 Apr 2012 10:35:50 +0000, Evertjan. wrote:

    > 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
    Denis McMahon, Apr 14, 2012
    #4
  5. Gene Wirchenko

    Evertjan. Guest

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

    > On Sat, 14 Apr 2012 10:35:50 +0000, Evertjan. wrote:
    >
    >> 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.


    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]

    >}
    > 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.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
    Evertjan., Apr 14, 2012
    #5
  6. On Sat, 14 Apr 2012 17:39:41 +0000, Evertjan. wrote:

    > Denis McMahon wrote on 14 apr 2012 in comp.lang.javascript:
    >
    >> On Sat, 14 Apr 2012 10:35:50 +0000, Evertjan. wrote:
    >>
    >>> 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.

    >
    > 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.


    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.

    >> 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]


    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
    Denis McMahon, Apr 14, 2012
    #6
  7. Gene Wirchenko

    Stefan Weiss Guest

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

    On 2012-04-13 21:12, Gene Wirchenko wrote:
    > 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
    Stefan Weiss, Apr 14, 2012
    #7
  8. On 14 Apr 2012 10:35:50 GMT, "Evertjan."
    <> wrote:

    >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.


    How fatuous!

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

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

    >
    >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
    #8
  9. On Sat, 14 Apr 2012 23:58:59 +1000, Jeff North <>
    wrote:

    >On Fri, 13 Apr 2012 12:12:17 -0700, in comp.lang.javascript Gene
    >Wirchenko <>
    ><> wrote:
    >
    >>| 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.

    >>| 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. 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.

    >
    >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.

    >>| 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.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Apr 16, 2012
    #9
  10. Gene Wirchenko

    Jeff North Guest

    On Sun, 15 Apr 2012 20:51:42 -0700, in comp.lang.javascript Gene
    Wirchenko <>
    <> wrote:

    >| On Sat, 14 Apr 2012 23:58:59 +1000, Jeff North <>
    >| wrote:
    >|
    >| >On Fri, 13 Apr 2012 12:12:17 -0700, in comp.lang.javascript Gene
    >| >Wirchenko <>
    >| ><> wrote:
    >| >
    >| >>| 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?
    Jeff North, Apr 16, 2012
    #10
  11. Gene Wirchenko

    Evertjan. Guest

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

    > On 14 Apr 2012 10:35:50 GMT, "Evertjan."
    > <> wrote:
    >
    >>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.

    >
    > 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.

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

    >>
    >> What is DE?

    >
    > 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?

    >
    > 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.

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
    Evertjan., Apr 16, 2012
    #11
  12. On Mon, 16 Apr 2012 18:52:52 +1000, Jeff North <>
    wrote:

    >On Sun, 15 Apr 2012 20:51:42 -0700, in comp.lang.javascript Gene
    >Wirchenko <>
    ><> wrote:
    >
    >>| On Sat, 14 Apr 2012 23:58:59 +1000, Jeff North <>
    >>| wrote:


    [snip]

    >>| >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.


    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.

    >>| 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.


    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?

    >>| 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.


    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.

    >
    >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
    Gene Wirchenko, Apr 16, 2012
    #12
  13. Gene Wirchenko

    Neil Gould Guest

    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.

    --
    best regards,

    Neil
    Neil Gould, Apr 16, 2012
    #13
  14. Gene Wirchenko

    Tim Streater Guest

    In article <jmhk1v$j3k$>,
    "Neil Gould" <> wrote:

    > 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.


    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.

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
    Tim Streater, Apr 16, 2012
    #14
  15. Gene Wirchenko wrote:
    > On Mon, 16 Apr 2012 18:52:52 +1000, Jeff North<>
    > wrote:
    >
    >> On Sun, 15 Apr 2012 20:51:42 -0700, in comp.lang.javascript Gene
    >> Wirchenko<>
    >> <> wrote:
    >>
    >>> | On Sat, 14 Apr 2012 23:58:59 +1000, Jeff North<>
    >>> | wrote:

    >
    > [snip]
    >
    >>> |>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.

    >
    > 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.

    >
    >>> | 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.

    >
    > 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>


    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Apr 16, 2012
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David
    Replies:
    2
    Views:
    332
    Natty Gur
    Jul 31, 2003
  2. =?Utf-8?B?RHVuZQ==?=

    validator controls and disabled controls

    =?Utf-8?B?RHVuZQ==?=, Feb 4, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    694
    Peter Blum
    Feb 4, 2004
  3. NM
    Replies:
    6
    Views:
    449
    Default User
    Sep 20, 2006
  4. Rick
    Replies:
    0
    Views:
    134
  5. What-a-Tool
    Replies:
    2
    Views:
    153
    What-a-Tool
    Feb 22, 2005
Loading...

Share This Page