Set focus on First text field, if any

Discussion in 'Javascript' started by Bill H, Aug 29, 2007.

  1. Bill H

    Bill H Guest

    Can someone tell me where I could find a JavaScript example of setting
    the focus to the first form text field, if t here is on, on a web page
    when it is loaded in the browser?

    Bill H
     
    Bill H, Aug 29, 2007
    #1
    1. Advertising

  2. Bill H wrote:

    > Can someone tell me where I could find a JavaScript example of setting
    > the focus to the first form text field, if t here is on, on a web page
    > when it is loaded in the browser?


    for (f=0; f<document.forms.length; f++)
    for (x=0; x<document.forms[f].length; x++)
    if (document.forms[f].elements[x].type == 'text') {
    document.forms[f].elements[x].focus()
    return
    }

    Hope this helps,

    --
    Bart
     
    Bart Van der Donck, Aug 29, 2007
    #2
    1. Advertising

  3. Bill H

    RobG Guest

    On Aug 29, 9:36 pm, Bill H <> wrote:
    > Can someone tell me where I could find a JavaScript example of setting
    > the focus to the first form text field, if t here is on, on a web page
    > when it is loaded in the browser?



    You could try Googling for "javascript focusfirst" but the results
    were unimpressive, you might try something like:

    window.onload = function(){
    var el, inputs = document.getElementsByTagName('input');
    for (var i=0, len=inputs.length; i<len; i++) {
    el = inputs;
    if (el.type == 'text' && el.focus) {
    el.focus();
    return;
    }
    }
    }

    Don't forget to add feature detection and account for other handlers
    that might be added onload.


    --
    Rob
     
    RobG, Aug 29, 2007
    #3
  4. Bill H

    Stevo Guest

    Bart Van der Donck wrote:
    > Bill H wrote:
    >> Can someone tell me where I could find a JavaScript example of setting
    >> the focus to the first form text field, if t here is on, on a web page
    >> when it is loaded in the browser?

    >
    > for (f=0; f<document.forms.length; f++)
    > for (x=0; x<document.forms[f].length; x++)
    > ...
    >
    > Hope this helps,
    > Bart


    Beware Bill, if you use that directly it'll create (or more importantly
    overwrite) global variables f and x. Try the following first two lines
    instead:

    for (var f=0; f<document.forms.length; f++)
    for (var x=0; x<document.forms[f].length; x++)
     
    Stevo, Aug 29, 2007
    #4
  5. Bill H

    Bill H Guest

    On Aug 29, 8:19 am, Bart Van der Donck <> wrote:
    > Bill H wrote:
    > > Can someone tell me where I could find a JavaScript example of setting
    > > the focus to the first form text field, if t here is on, on a web page
    > > when it is loaded in the browser?

    >
    > for (f=0; f<document.forms.length; f++)
    > for (x=0; x<document.forms[f].length; x++)
    > if (document.forms[f].elements[x].type == 'text') {
    > document.forms[f].elements[x].focus()
    > return
    > }
    >
    > Hope this helps,
    >
    > --
    > Bart


    Thanks Bart, RobG. I tried googling, but google sometimes leaves a lot
    to be desired (so much fluff, not much substance).

    Instead of using an Onload, would either of these routines be safe
    running before the </HTML> tag (after </BODY>) or is there still a
    chance that the page hasn't rendered in the browser? Is there a actual
    set rule on when things are rendered into the browser or is it first
    come first serve?

    Bill H

    Bill H
     
    Bill H, Aug 29, 2007
    #5
  6. Bill H wrote:

    > Thanks Bart, RobG. I tried googling, but google sometimes leaves a lot
    > to be desired (so much fluff, not much substance).
    >
    > Instead of using an Onload, would either of these routines be safe
    > running before the </HTML> tag (after </BODY>)


    That would not be a good practice. Just before </BODY> would be "a bit
    better" practice, but still not recommended.

    > or is there still a chance that the page hasn't rendered in the browser?


    Yes, there is.

    > Is there a actual set rule on when things are rendered into the browser
    > or is it first come first serve?


    Yes, the general rule is first come first served - but there might be
    exceptions.

    The recommended way is onLoad.

    --
    Bart
     
    Bart Van der Donck, Aug 29, 2007
    #6
  7. Bill H

    RobG Guest

    On Aug 29, 10:37 pm, Bill H <> wrote:
    [...]
    > Thanks Bart, RobG. I tried googling, but google sometimes leaves a lot
    > to be desired (so much fluff, not much substance).
    >
    > Instead of using an Onload, would either of these routines be safe
    > running before the </HTML> tag (after </BODY>)


    Mostly, yes. There may be some browsers that won't like it so could
    perhaps add :

    if (!document || !document.getElementsByTagName ) return;

    feature testing to the code I posted. At worst, it will simply not
    focus on the element.

    > or is there still a
    > chance that the page hasn't rendered in the browser?


    You have no way of knowing for sure, by adding the above test, at
    least you ensure graceful degradation.


    > Is there a actual
    > set rule on when things are rendered into the browser or is it first
    > come first serve?


    Markup and code is parsed it arrives, most browsers will display
    content as they can, even if the layout is not final. Users have
    shown a preference for browsers that do so, so that is what they do.


    --
    Rob
     
    RobG, Aug 29, 2007
    #7
  8. Bill H

    RobG Guest

    On Aug 29, 11:05 pm, RobG <> wrote:
    > On Aug 29, 10:37 pm, Bill H <> wrote:

    [...]
    > > Instead of using an Onload, would either of these routines be safe
    > > running before the </HTML> tag (after </BODY>)

    >
    > Mostly, yes.


    Wrong, I should have said no - keep it before the closing body tag,
    script elements must be in the head or body, not outside.


    --
    Rob
     
    RobG, Aug 29, 2007
    #8
  9. RobG wrote:
    > On Aug 29, 9:36 pm, Bill H <> wrote:
    >> Can someone tell me where I could find a JavaScript example of setting
    >> the focus to the first form text field, if t here is on, on a web page
    >> when it is loaded in the browser?

    >
    > [...]
    > window.onload = function(){
    > var el, inputs = document.getElementsByTagName('input');
    > [...]
    > }


    <head>
    ...
    <meta http-equiv="Content-Script-Type" content="text/javascript">
    <script type="text/javascript">
    function handleLoad()
    {
    // ...
    }
    </script>
    </head>

    <body onload="...">
    ...
    </body>

    should be used instead, to avoid the proprietary, and therefore inherently
    unreliable `onload' property. I'd also recommend Bart's solution instead,
    because it is backwards-compatible to DOM Level 0, and it has been
    established per the OP's question that the `input' element is a descendant
    of `form'.

    > Don't forget to add feature detection and account for other handlers
    > that might be added onload.


    Event handlers cannot be added, they are built-in to a DOM. `onload' is
    *the* event handler for the `load' event. Other event *listeners* could
    be added (for that event), though.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, Aug 29, 2007
    #9
  10. Thomas 'PointedEars' Lahn wrote:
    > <head>
    > ...
    > <meta http-equiv="Content-Script-Type" content="text/javascript">
    > <script type="text/javascript">
    > function handleLoad()
    > {
    > // ...
    > }
    > </script>
    > </head>
    >
    > <body onload="...">


    <body onload="handleLoad()">

    > ...
    > </body>
     
    Thomas 'PointedEars' Lahn, Aug 29, 2007
    #10
  11. Bart Van der Donck wrote:
    > Bill H wrote:
    >> Instead of using an Onload, would either of these routines be safe
    >> running before the </HTML> tag (after </BODY>)

    >
    > That would not be a good practice. Just before </BODY> would be "a bit
    > better" practice, but still not recommended.


    Where it should be emphasized that "not recommended" means in fact "strongly
    recommended against", where the (W3C) Recommendation we are talking about is
    the HTML 4.01 Specification (and its "relatives"). It is not Valid (X)HTML,
    IOW a violation of the aforementioned Web standard, if there is a `script'
    element in the document that is not within the `head' or the `body' element.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
     
    Thomas 'PointedEars' Lahn, Aug 29, 2007
    #11
  12. Thomas 'PointedEars' Lahn wrote:
    > Bart Van der Donck wrote:
    >> Bill H wrote:
    >>> Instead of using an Onload, would either of these routines be safe
    >>> running before the </HTML> tag (after </BODY>)

    >> That would not be a good practice. Just before </BODY> would be "a bit
    >> better" practice, but still not recommended.

    >
    > Where it should be emphasized that "not recommended" means in fact "strongly


    Replacing "not recommended" in my text with "not a good practice" to avoid a
    misunderstanding.

    > recommended against", where the (W3C) Recommendation we are talking about is
    > the HTML 4.01 Specification (and its "relatives"). It is not Valid (X)HTML,
    > IOW a violation of the aforementioned Web standard, if there is a `script'
    > element in the document that is not within the `head' or the `body' element.


    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, Aug 29, 2007
    #12
  13. Bill H

    Matt Kruse Guest

    On Aug 29, 7:31 am, RobG <> wrote:
    > window.onload = function(){
    > var el, inputs = document.getElementsByTagName('input');
    > for (var i=0, len=inputs.length; i<len; i++) {
    > el = inputs;
    > if (el.type == 'text' && el.focus) {
    > el.focus();
    > return;
    > }
    > }
    > }


    You may also wish to consider:
    1) If the input is hidden, it cannot receive focus
    2) If the input is disabled, it cannot receive focus
    3) If the user has already changed the value in the field (and
    possibly tabbed to the next field already), you shouldn't re-focus it

    Matt Kruse
     
    Matt Kruse, Aug 29, 2007
    #13
  14. On Aug 29, 3:10 pm, Thomas 'PointedEars' Lahn wrote:
    > RobG wrote:
    >> On Aug 29, 9:36 pm, Bill H wrote:
    >>> Can someone tell me where I could find a JavaScript example
    >>> of setting the focus to the first form text field, if t here
    >>> is on, on a web page when it is loaded in the browser?

    >
    >> [...]
    >> window.onload = function(){
    >> var el, inputs = document.getElementsByTagName('input');
    >> [...]
    >> }

    <snip>
    > <script type="text/javascript">
    > function handleLoad()
    > {
    > // ...
    > }
    > </script>
    > </head>
    >
    > <body onload="...">
    > ...
    > </body>
    >
    > should be used instead, to avoid the proprietary, and therefore
    > inherently unreliable 'onload' property.

    <snip>

    What do you propose should be used instead of the proprietary "and
    therefore inherently unreliable" - document - property of the ECMAScript
    global/window object? (And don't bother saying that W3C DOM Views
    defines - document - because the - document - it defines is a property
    of the AbstractView interface and there is nothing that says that the
    ECMAScript global/window object is required to either be the object
    referred to by - document.defaultView - or implement the AbstractView
    interface (regardless of how many specific implementations have chosen
    to do it that way). The ECMAScript bindings for DOM Views could have
    required both if they had wanted to.)

    Richard.
     
    Richard Cornford, Sep 1, 2007
    #14
  15. Richard Cornford wrote:
    > On Aug 29, 3:10 pm, Thomas 'PointedEars' Lahn wrote:
    >> RobG wrote:
    >>> On Aug 29, 9:36 pm, Bill H wrote:
    >>>> Can someone tell me where I could find a JavaScript example
    >>>> of setting the focus to the first form text field, if t here
    >>>> is on, on a web page when it is loaded in the browser?
    >>> [...]
    >>> window.onload = function(){
    >>> var el, inputs = document.getElementsByTagName('input');
    >>> [...]
    >>> }

    > <snip>
    >> <script type="text/javascript">
    >> function handleLoad()
    >> {
    >> // ...
    >> }
    >> </script>
    >> </head>
    >>
    >> <body onload="...">
    >> ...
    >> </body>
    >>
    >> should be used instead, to avoid the proprietary, and therefore
    >> inherently unreliable 'onload' property.

    > <snip>
    >
    > What do you propose should be used instead of the proprietary "and
    > therefore inherently unreliable" - document - property of the ECMAScript
    > global/window object? (And don't bother saying that W3C DOM Views
    > defines - document - because the - document - it defines is a property
    > of the AbstractView interface and there is nothing that says that the
    > ECMAScript global/window object is required to either be the object
    > referred to by - document.defaultView - or implement the AbstractView
    > interface (regardless of how many specific implementations have chosen
    > to do it that way). The ECMAScript bindings for DOM Views could have
    > required both if they had wanted to.)


    Comparing apples and oranges does not help. Yes, there is no Web standard
    (yet) that says that the Global Object or the host object referred to by
    `window' has to or should implement the AbstractView interface. But at some
    point even standards compliant DOM referencing has to start. Why not at the
    point that was inherited from DOM Level 0?

    The `onload' property of the Global Object or the object referred to by
    `window', on the other hand, is proprietary and it is only that. There is
    no Web standard that says this property even should exist, no standard
    interface that defines a corresponding attribute to be implemented, and no
    specification that defines what values should be handled by that property
    and how the value should affects the event propagation process.

    It is unwise to assume the well-defined propagation process as defined in
    W3C DOM Level 2 and on the other hand rely on that assigning to a
    proprietary property does the same as calling addEventListener() would do.
    IOW, it should be the last resort to ensure backwards compatibility, not
    the default procedure of event programming.


    PointedEars
    --
    "Use any version of Microsoft Frontpage to create your site. (This won't
    prevent people from viewing your source, but no one will want to steal it.)"
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
     
    Thomas 'PointedEars' Lahn, Sep 1, 2007
    #15
  16. Thomas 'PointedEars' Lahn wrote:
    > Richard Cornford wrote:
    >> On Aug 29, 3:10 pm, Thomas 'PointedEars' Lahn wrote:

    <snip>
    >>> should be used instead, to avoid the proprietary, and therefore
    >>> inherently unreliable 'onload' property.

    >> <snip>
    >>
    >> What do you propose should be used instead of the proprietary
    >> "and therefore inherently unreliable" - document - property of
    >> the ECMAScript global/window object? (And don't bother saying
    >> that W3C DOM Views defines - document - because the - document
    >> - it defines is a property of the AbstractView interface and
    >> there is nothing that says that the ECMAScript global/window
    >> object is required to either be the object referred to by
    >> - document.defaultView - or implement the AbstractView
    >> interface (regardless of how many specific implementations
    >> have chosen to do it that way). The ECMAScript bindings for
    >> DOM Views could have required both if they had wanted to.)

    >
    > Comparing apples and oranges does not help.


    But my complaint is precisely that the two do have equivalent status in
    practice. Both being properties of the window/global object that came
    into existence prior to standardisation and have been repeatedly (and
    reasonably consistently) implemented in web browser ever since, and are
    likely to go in being implemented regardless of whether they are ever
    explicitly defined in any standards.

    > Yes, there is no Web standard (yet) that says that the Global
    > Object or the host object referred to by `window' has to or
    > should implement the AbstractView interface.


    What is to stop someone from categorising - onload - as not "yet"
    standardised? Granted it is in the nature of the property that including
    it in an IDF formulation of a standard would probably be somewhere
    between difficult and impossible, which may leave the W3C unable to
    standardise it, but that does not mean it could never happen.

    > But at some point even standards compliant DOM referencing
    > has to start. Why not at the point that was inherited from
    > DOM Level 0?


    Yes, there has to be some entry point for the DOM, and so we continue to
    use the proprietary "and therefore inherently unreliable" - document -
    property of the global object. But the fact that we are willing to do
    that as a matter of course puts 'proprietary "and therefore inherently
    unreliable"' into perspective. We are not expecting any new browser to
    stop implementing a - document - property of the global object because
    doing so will make that browser seem utterly bracken. The same is true
    of the - onload - property. Its omission may not make a browser look
    quite as usless as one without a - document - property, but it would
    still look so broken that it would be unlikely to get out of QA without
    serious questions being raised as to its viability as a web browser.

    > The `onload' property of the Global Object or the object
    > referred to by `window', on the other hand, is proprietary
    > and it is only that.


    It is only "proprietary" in the sense that all of DOM 0 is proprietary.
    These things persist (and will continue to be implemented) because they
    are used.

    > There is no Web standard that says this property even
    > should exist,


    So much like - document -.

    > no standard interface that defines a corresponding attribute to
    > be implemented, and no specification that defines what values
    > should be handled by that property


    So much like - document -.

    > and how the value should affects the event propagation process.
    >
    > It is unwise to assume the well-defined propagation process as
    > defined in W3C DOM Level 2 and on the other hand rely on that
    > assigning to a proprietary property does the same as calling
    > addEventListener() would do.


    The window/ECMAScript global object is not specified as being a Node
    interface implementing object so would not be expected to have an -
    addEventListener - method at all.

    > IOW, it should be the last resort to ensure backwards
    > compatibility, not the default procedure of event programming.


    There is no standardised method for a script to dynamically assign a
    function to be called when an associated document finishes loading.
    Without that the longstanding and universally (in scriptable browsers)
    implemented - window.onload - is the sensible choice.

    Richard.
     
    Richard Cornford, Sep 2, 2007
    #16
    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. =?Utf-8?B?TWlrZSBNb29yZQ==?=

    Set Focus to a Text Box Field on a User Web Control

    =?Utf-8?B?TWlrZSBNb29yZQ==?=, Dec 9, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    422
    Steve C. Orr [MVP, MCSD]
    Dec 9, 2004
  2. reneecccwest
    Replies:
    1
    Views:
    120
    McKirahan
    Feb 24, 2004
  3. Replies:
    2
    Views:
    357
    Thomas 'PointedEars' Lahn
    Jun 6, 2005
  4. Zvonko
    Replies:
    1
    Views:
    124
  5. Roger
    Replies:
    3
    Views:
    379
Loading...

Share This Page