How to use <A NAME> with drop box

#1 July 30th, 2005, 02:05 AM

I wish to use a drop box where each Option will not take the user to a web
page - but a certain location on the same page the drop box exists. For
example, Option 1 would take the user to "Chapter 1", Option 2 would be
"Chapter 2", and so on. All destinations are on the same page.

I already have <A NAME="#ChapterX"> tags placed in the appropriate places in
the document. (A no-GO button drop box is preferred.)

How do I achieve this?

#2 July 30th, 2005, 04:15 AM

Yeah wrote:
[color=blue]
> I wish to use a drop box where each Option will not take the user to a web
> page - but a certain location on the same page the drop box exists. For
> example, Option 1 would take the user to "Chapter 1", Option 2 would be
> "Chapter 2", and so on. All destinations are on the same page.
>
> I already have <A NAME="#ChapterX"> tags placed in the appropriate places
> in the document. (A no-GO button drop box is preferred.)
>
> How do I achieve this?[/color]

Try this...

In <head>:

<script type="text/javascript">

function formHandler(form){
var URL =
document.form.site.options[document.form.site.selectedIndex].value;
window.location.href = URL;
}

</script>

In <body>:

<form name="form">
<select name="site" onChange="javascript:formHandler()">
<option value="index.html#chaper1">Chapter 1
<option value="index.html#chaper2">Chapter 2
</select>
</form>

Also:

<A NAME="#chapter1">Chapter 1</A>

....

<A NAME="#Chapter2">Chapter 2</A>

....

I can confirm that it works properly in all major modern browsers.

Roy

--
Roy S. Schestowitz
http://Schestowitz.com

#3 July 30th, 2005, 05:25 AM

Gazing into my crystal ball I observed Roy Schestowitz
<newsgroups@schestowitz.com> writing in
news:dceqmq$2c86$1@godfrey.mcc.ac.uk:
[color=blue]
> Yeah wrote:
>[color=green]
>> I wish to use a drop box where each Option will not take the user to a
>> web page - but a certain location on the same page the drop box
>> exists. For example, Option 1 would take the user to "Chapter 1",
>> Option 2 would be "Chapter 2", and so on. All destinations are on the
>> same page.
>>
>> I already have <A NAME="#ChapterX"> tags placed in the appropriate
>> places in the document. (A no-GO button drop box is preferred.)
>>
>> How do I achieve this?[/color]
>
> Try this...
>
> In <head>:
>
><script type="text/javascript">
> function formHandler(form){
> var URL =
> document.form.site.options[document.form.site.selectedIndex].value;
> window.location.href = URL;
> }
></script>
>
> In <body>:[/color]
<snip>
[color=blue]
> I can confirm that it works properly in all major modern browsers.
>[/color]

For users with javascript enabled. One should always provide another means
of navigation for users without, eg. Google.

--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

#4 July 30th, 2005, 07:55 AM

Adrienne wrote:
[color=blue]
> Gazing into my crystal ball I observed Roy Schestowitz
> <newsgroups@schestowitz.com> writing in
> news:dceqmq$2c86$1@godfrey.mcc.ac.uk:
>[color=green]
>> Yeah wrote:
>>[color=darkred]
>>> I wish to use a drop box where each Option will not take the user to a
>>> web page - but a certain location on the same page the drop box
>>> exists. For example, Option 1 would take the user to "Chapter 1",
>>> Option 2 would be "Chapter 2", and so on. All destinations are on the
>>> same page.
>>>
>>> I already have <A NAME="#ChapterX"> tags placed in the appropriate
>>> places in the document. (A no-GO button drop box is preferred.)
>>>
>>> How do I achieve this?[/color]
>>
>> Try this...
>>
>> In <head>:
>>
>><script type="text/javascript">
>> function formHandler(form){
>> var URL =
>> document.form.site.options[document.form.site.selectedIndex].value;
>> window.location.href = URL;
>> }
>></script>
>>
>> In <body>:[/color]
> <snip>
>[color=green]
>> I can confirm that it works properly in all major modern browsers.
>>[/color]
>
> For users with javascript enabled. One should always provide another
> means of navigation for users without, eg. Google.[/color]

Places where I embed such code have an alternative version that is
JavaScript-free. The OP can include another version which has a simple
expanded menu rather than a drop-down, but it's a poor choice from an
SEO-centric point-of-view.

Roy

--
Roy S. Schestowitz
http://Schestowitz.com

#5 July 30th, 2005, 01:05 PM

On Fri, 29 Jul 2005 19:55:06 -0500, "Yeah" <yeah@positive.net> wrote:
[color=blue]
>I already have <A NAME="#ChapterX"> tags[/color]

Try <A NAME="ChapterX"> instead

"#" is a fragment _separator_, not part fo the fragment's name itself.
You use it in the URL that refers to it, but not in the target's name.

<a href="#ChapterX" >Click Here</a>

#6 July 31st, 2005, 02:45 AM

Roy Schestowitz wrote:[color=blue]
> Yeah wrote:
>
>[color=green]
>>I wish to use a drop box where each Option will not take the user to a web
>>page - but a certain location on the same page the drop box exists. For
>>example, Option 1 would take the user to "Chapter 1", Option 2 would be
>>"Chapter 2", and so on. All destinations are on the same page.
>>
>>I already have <A NAME="#ChapterX"> tags placed in the appropriate places
>>in the document. (A no-GO button drop box is preferred.)
>>
>>How do I achieve this?[/color]
>
>
> Try this...
>
> In <head>:
>
> <script type="text/javascript">
>
>
> function formHandler(form){
> var URL =
> document.form.site.options[document.form.site.selectedIndex].value;
> window.location.href = URL;
> }
>
> </script>
>
>
>
> In <body>:
>
> <form name="form">
> <select name="site" onChange="javascript:formHandler()">
> <option value="index.html#chaper1">Chapter 1
> <option value="index.html#chaper2">Chapter 2
> </select>
> </form>
>[/color]

Using 'onchange' with select elements has serious usability issues
with keyboard navigation in IE, particularly if the options cause URLs
to be followed.

Try the following by tabbing to the select, then using the down arrow key:

<select onchange="alert(this[this.selectedIndex].text);">
<option>Option 1</option>
<option>Option 2</option>
<option>Option 3</option>
</select>

In IE the alert is fired every time the down arrow is pressed. If each
option is a link, then users will never get beyond the first step
downward before being whisked away to the new URL.

--
Rob

#7 July 31st, 2005, 07:15 AM

RobG wrote:
[color=blue]
> Roy Schestowitz wrote:[color=green]
>> Yeah wrote:
>>
>>[color=darkred]
>>>I wish to use a drop box where each Option will not take the user to a
>>>web page - but a certain location on the same page the drop box exists.
>>>For example, Option 1 would take the user to "Chapter 1", Option 2 would
>>>be "Chapter 2", and so on. All destinations are on the same page.
>>>
>>>I already have <A NAME="#ChapterX"> tags placed in the appropriate places
>>>in the document. (A no-GO button drop box is preferred.)
>>>
>>>How do I achieve this?[/color]
>>
>>
>> Try this...
>>
>> In <head>:
>>
>> <script type="text/javascript">
>>
>>
>> function formHandler(form){
>> var URL =
>> document.form.site.options[document.form.site.selectedIndex].value;
>> window.location.href = URL;
>> }
>>
>> </script>
>>
>>
>>
>> In <body>:
>>
>> <form name="form">
>> <select name="site" onChange="javascript:formHandler()">
>> <option value="index.html#chaper1">Chapter 1
>> <option value="index.html#chaper2">Chapter 2
>> </select>
>> </form>
>>[/color]
>
> Using 'onchange' with select elements has serious usability issues
> with keyboard navigation in IE, particularly if the options cause URLs
> to be followed.
>
> Try the following by tabbing to the select, then using the down arrow key:
>
>
> <select onchange="alert(this[this.selectedIndex].text);">
> <option>Option 1</option>
> <option>Option 2</option>
> <option>Option 3</option>
> </select>
>
>
> In IE the alert is fired every time the down arrow is pressed. If each
> option is a link, then users will never get beyond the first step
> downward before being whisked away to the new URL.[/color]

I never actually had it tested to account for keyboard behaviour. I can see
your point and I wonder how other browsers handle it.

With older versions of Netscape, the selection and request to move to a new
URL was not obeyed IIRC. I used to remember some more issues with the
implementation above. That's why I added a JS-free version wherever I had
such a menu placed.

Roy

#8 July 31st, 2005, 07:45 AM

Roy Schestowitz wrote:[color=blue]
> RobG wrote:
>
>[color=green]
>>Roy Schestowitz wrote:
>>[/color][/color]
[...][color=blue][color=green][color=darkred]
>>>[/color]
>>Using 'onchange' with select elements has serious usability issues
>>with keyboard navigation in IE, particularly if the options cause URLs
>>to be followed.
>>
>>Try the following by tabbing to the select, then using the down arrow key:
>>
>>
>><select onchange="alert(this[this.selectedIndex].text);">
>> <option>Option 1</option>
>> <option>Option 2</option>
>> <option>Option 3</option>
>></select>
>>
>>
>>In IE the alert is fired every time the down arrow is pressed. If each
>>option is a link, then users will never get beyond the first step
>>downward before being whisked away to the new URL.[/color]
>
>
> I never actually had it tested to account for keyboard behaviour. I can see
> your point and I wonder how other browsers handle it.
>
> With older versions of Netscape, the selection and request to move to a new
> URL was not obeyed IIRC. I used to remember some more issues with the
> implementation above. That's why I added a JS-free version wherever I had
> such a menu placed.
>
> Roy[/color]

According to the HTML specification, onchange should fire if the
control has changed when it looses focus. In that respect, Mozilla et
al do it by the book for select elements.

On the other hand, Mozilla will fire an onchange for a radio button
the moment it is clicked (effectively making it an onclick event) and
doesn't wait for the loss of focus. IE waits for the button to lose
focus, which has the unfortunate side-effect that when you click one,
nothing happens. If you click another, the onchange from the previous
one fires.

There are a number of such gotchas - but that's just part of the fun
of web development!

--
Rob

#9 July 31st, 2005, 08:25 AM

RobG wrote:
[color=blue]
> Roy Schestowitz wrote:[color=green]
>> RobG wrote:
>>
>>[color=darkred]
>>>Roy Schestowitz wrote:
>>>[/color][/color]
> [...][color=green][color=darkred]
>>>>
>>>Using 'onchange' with select elements has serious usability issues
>>>with keyboard navigation in IE, particularly if the options cause URLs
>>>to be followed.
>>>
>>>Try the following by tabbing to the select, then using the down arrow
>>>key:
>>>
>>>
>>><select onchange="alert(this[this.selectedIndex].text);">
>>> <option>Option 1</option>
>>> <option>Option 2</option>
>>> <option>Option 3</option>
>>></select>
>>>
>>>
>>>In IE the alert is fired every time the down arrow is pressed. If each
>>>option is a link, then users will never get beyond the first step
>>>downward before being whisked away to the new URL.[/color]
>>
>>
>> I never actually had it tested to account for keyboard behaviour. I can
>> see your point and I wonder how other browsers handle it.
>>
>> With older versions of Netscape, the selection and request to move to a
>> new URL was not obeyed IIRC. I used to remember some more issues with the
>> implementation above. That's why I added a JS-free version wherever I had
>> such a menu placed.
>>
>> Roy[/color]
>
> According to the HTML specification, onchange should fire if the
> control has changed when it looses focus. In that respect, Mozilla et
> al do it by the book for select elements.
>
> On the other hand, Mozilla will fire an onchange for a radio button
> the moment it is clicked (effectively making it an onclick event) and
> doesn't wait for the loss of focus. IE waits for the button to lose
> focus, which has the unfortunate side-effect that when you click one,
> nothing happens. If you click another, the onchange from the previous
> one fires.
>
> There are a number of such gotchas - but that's just part of the fun
> of web development![/color]

I wouldn't label it all "fun". It makes Web development more laborious. At
some stage I gave up on testing pages under different browsers and just
ensured that new pages validated. If the browser cannot dipslay valid pages
properly, the browser should be blamed. Alternatively, the formal
specifications should take the blame. For example, a user who cannot use
the mouse might suffer from focus-related decisions. Then again, Windows
has a poor notion of focus (only click window or widget to focus) so not
wonder IE fails.

Roy

--
Roy S. Schestowitz
http://Schestowitz.com

What is Bytes?

Popular Articles