Set focus on First text field, if any

B

Bill H

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
 
B

Bart Van der Donck

Bill said:
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,
 
R

RobG

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

Stevo

Bart said:
Bill said:
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++)
 
B

Bill H

Bill said:
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,

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
 
B

Bart Van der Donck

Bill said:
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?

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

RobG

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

Thomas 'PointedEars' Lahn

RobG said:
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
 
T

Thomas 'PointedEars' Lahn

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

<body onload="...">
 
T

Thomas 'PointedEars' Lahn

Bart said:
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
 
T

Thomas 'PointedEars' Lahn

Thomas said:
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.
 
M

Matt Kruse

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
 
R

Richard Cornford

[...]
window.onload = function(){
var el, inputs = document.getElementsByTagName('input');
[...]
}
<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.
 
T

Thomas 'PointedEars' Lahn

Richard said:
RobG said:
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');
[...]
}
<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
 
R

Richard Cornford

Thomas said:
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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top