Radio Buttons & Hyperlinks?

[Cerebral Believer]

Anyone know if it is possible to use one hyperlink and a selection of radio
buttons to send a person to a particular page depending on what radio button
they check, eg.

Please Choose A Format

[a] <--- radio buttons

CLICK HERE <-- hyperlink

They would need to check one button, so the page should return with an error
saying (please select a format), or send the user to a default page if no
option is selected.

Would appreciate some sample code if anyone has the time and inclination.

Regards,
C.B.

 

[Harlan Messinger]

Anyone know if it is possible to use one hyperlink and a selection of radio
buttons to send a person to a particular page depending on what radio button
they check, eg.

Please Choose A Format

[a] <--- radio buttons

CLICK HERE <-- hyperlink

They would need to check one button, so the page should return with an error
saying (please select a format), or send the user to a default page if no
option is selected.

What would make this approach preferable to

Read the specs in _Format A_ or _Format B_.

where the underscore delimiters represent the beginning and end of
hyperlinks?

 

[Toby Inkster]

Anyone know if it is possible to use one hyperlink and a selection of radio
buttons to send a person to a particular page depending on what radio button
they check

It's certainly possible with a bit of Javascript attached to the "onclick"
event of the hyperlink, but there are probably better ways of allowing the
user to select between two different formats.

One method might be to use a submit button to submit the radio button
selection. A bit of CSS could style this to look almost exactly like a
regular link.

A better method might be to abandon the radio buttons altogether. If you
simply want to offer a choice between two different formats, you could use
two different links:

<ul>
<li><a href="high/">Broadband version</a></li>
<li><a href="low/">Dial-up version</a></li>
</ul>

 

[richard]

Anyone know if it is possible to use one hyperlink and a selection of
radio buttons to send a person to a particular page depending on what
radio button they check, eg.

Please Choose A Format

[a] <--- radio buttons

CLICK HERE <-- hyperlink

They would need to check one button, so the page should return with an
error saying (please select a format), or send the user to a default page
if no option is selected.

Would appreciate some sample code if anyone has the time and inclination.

Regards,
C.B.

Yes it can be done but not without some type of scripting.
Because html would not know what to do with the clicks, let alone the
buttons.
Html is purely for presentation.

 

[Toby Inkster]

Html is purely for presentation.

No -- CSS is purely for presentation.

HTML is purely for structured content.

 

[Cerebral Believer]

Anyone know if it is possible to use one hyperlink and a selection of
radio buttons to send a person to a particular page depending on what
radio button they check, eg.

Please Choose A Format

[a] <--- radio buttons

CLICK HERE <-- hyperlink

They would need to check one button, so the page should return with an
error saying (please select a format), or send the user to a default page
if no option is selected.

What would make this approach preferable to

Read the specs in _Format A_ or _Format B_.

where the underscore delimiters represent the beginning and end of
hyperlinks?

Yes I agree I wasn't thinking straight. Actually I had been thinking of
having page A where the choice is made, leading onto page B where someone
gets use the format chosen, but I guess this is inefficient, and would
involve using two pages for the same content which could be held on one
page.

Regards,
C.B.

 

[Cerebral Believer]

Hi Toby,

I chose to re-think what I was doing a little after reading the responses
here. I am using FrontPage plus my own efforts to modify some of the code.
I have a page at
http://futurebydesign-music.com/_music/Future By Design/Long Journey Home Listen.htm -
which is a page in progress, on a site in progress. This is what I have
done so far and is my first effort at using FrontPage.

The problem I have is that some of the images I am using do not show up,
they are used as links to streaming audio files, and although the files
reside in exactly the same directory as some other image files I am using on
this page, and the HTML code seems to be correct, but they are not
displaying (I checked they are on the server too). The images do show in
preview mode in FrontPage though, so I am wondering if my CSS has introduced
a conflict somehow which prevents the images from showing?

Here is part of my HTML

<td class="valtop">

<a class="lisbut" onmouseover="document.getElementById('trk1m').src =
'../../images/listenbuy/mp3_mo.jpg';"
onmouseout="document.getElementById('trk1m').src =
'../../images/listenbuy/mp3.jpg';"
href="../../musdir/001Rs/Smooth%20Groove.m3u" type="audio/x-mpegurl">
<img class="lisbut" id='trk1m' src="../../images/listenbuy/mp3.jpg"
alt="Smooth Groove (.mp3)"></a>

<a class="lisbut" onmouseover="document.getElementById('trk1r').src =
'../../images/listenbuy/ra_mo.jpg';"
onmouseout="document.getElementById('trk1r').src =
'../../images/listenbuy/ra.jpg';"
href="../../musdir/001Rs/Smooth%20Groove.ram" type="audio/x-pn-realaudio">
<img class="lisbut" id='trk1r' src="../../images/listenbuy/ra.jpg"
alt="Smooth Groove(.ra)"></a>

<br>

<a type="audio/x-mpegurl" title="Listen to the .mp3 sample of this track"
href="../../musdir/001Rs/Smooth%20Groove.m3u">mp3</a>&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;

<a title="Listen to the .ra sample of this track"
href="../../musdir/Smooth%20Groove.ram">real</a><br/></td>

</tr>

The relevant CSS is:

..valtop {
vertical-align: top;
text-align: center;
}
..lisbut {
border: 1.5px solid #000000;
}

Maybe I will not use CSS to align my images, perhaps it was wrong to use
text-align but instead I should have used a div or <p align="center"> tag.
What are your thoughts on this and the design in general.

Regards,
C.B.

 

[Cerebral Believer]

No worries I fixed this. The new image files I added carried the .JPG
extension, instead of .jpg, and that made all the difference!

Hi Toby,

I chose to re-think what I was doing a little after reading the responses
here. I am using FrontPage plus my own efforts to modify some of the
code. I have a page at
http://futurebydesign-music.com/_music/Future By Design/Long Journey Home Listen.htm -
which is a page in progress, on a site in progress. This is what I have
done so far and is my first effort at using FrontPage.

The problem I have is that some of the images I am using do not show up,
they are used as links to streaming audio files, and although the files
reside in exactly the same directory as some other image files I am using
on this page, and the HTML code seems to be correct, but they are not
displaying (I checked they are on the server too). The images do show in
preview mode in FrontPage though, so I am wondering if my CSS has
introduced a conflict somehow which prevents the images from showing?

Here is part of my HTML

<td class="valtop">

<a class="lisbut" onmouseover="document.getElementById('trk1m').src =
'../../images/listenbuy/mp3_mo.jpg';"
onmouseout="document.getElementById('trk1m').src =
'../../images/listenbuy/mp3.jpg';"
href="../../musdir/001Rs/Smooth%20Groove.m3u" type="audio/x-mpegurl">
<img class="lisbut" id='trk1m' src="../../images/listenbuy/mp3.jpg"
alt="Smooth Groove (.mp3)"></a>

<a class="lisbut" onmouseover="document.getElementById('trk1r').src =
'../../images/listenbuy/ra_mo.jpg';"
onmouseout="document.getElementById('trk1r').src =
'../../images/listenbuy/ra.jpg';"
href="../../musdir/001Rs/Smooth%20Groove.ram" type="audio/x-pn-realaudio">
<img class="lisbut" id='trk1r' src="../../images/listenbuy/ra.jpg"
alt="Smooth Groove(.ra)"></a>

<br>

<a type="audio/x-mpegurl" title="Listen to the .mp3 sample of this track"
href="../../musdir/001Rs/Smooth%20Groove.m3u">mp3</a>&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;

<a title="Listen to the .ra sample of this track"
href="../../musdir/Smooth%20Groove.ram">real</a><br/></td>

</tr>

The relevant CSS is:

.valtop {
vertical-align: top;
text-align: center;
}
.lisbut {
border: 1.5px solid #000000;
}

Maybe I will not use CSS to align my images, perhaps it was wrong to use
text-align but instead I should have used a div or <p align="center"> tag.
What are your thoughts on this and the design in general.

Regards,
C.B.

 

[Jonathan N. Little]

No worries I fixed this. The new image files I added carried the .JPG
extension, instead of .jpg, and that made all the difference!

Something the Windows user must always be aware if is that unlike
Windows most webservers are not on Windows platforms and filenames and
paths are case-sensitive. The domain name is only where you can be lax
because they are not case-sensitive.

I recommend any Windows users that want to do any significant amount of
web site development to find an old computer and slap together a LAMP
server and do your development there rather than with local files. Will
save you much debug frustration....

 

[Alan J. Flavell]

Something the Windows user must always be aware if is that unlike
Windows most webservers are not on Windows platforms and filenames
and paths are case-sensitive. The domain name is only where you can
be lax because they are not case-sensitive.

Well, yes, but I'd say that's putting the cart before the horse. URLs
are by definition case-sensitive, and that's got nothing to do with
the particular file system used on any specific server. It just so
happens that when URLs are mapped to files on a Windows server, then
typically two different URLs which differ only in their case are
mapped to the same file i.e although the URLs are different, they
access the same resource.

It's not a good idea to rely on this - one should be consistent.

I recommend any Windows users that want to do any significant amount
of web site development to find an old computer and slap together a
LAMP server and do your development there rather than with local
files. Will save you much debug frustration....

You make a good point. For most purposes, I'd recommend Windows users
to install Win32 Apache locally, and use that for browsing their
development site. There's far too many shortcomings involved in
browsing files directly, without a server. But in regard to case
sensitivity, it's going to have the same issues as we are discussing.

 

[Jonathan N. Little]

Well, yes, but I'd say that's putting the cart before the horse. URLs
are by definition case-sensitive, and that's got nothing to do with
the particular file system used on any specific server. It just so
happens that when URLs are mapped to files on a Windows server, then
typically two different URLs which differ only in their case are
mapped to the same file i.e although the URLs are different, they
access the same resource.

I would argue that you are incorrect. URLs are not *always*
case-sensitive and case-sensitivity *is* platform dependent. Domain
names are host names and are *not* case-sensitive yet a domain names can
be a valid URL so:

http://www.example.com
http://WWW.EXAMPLE.COM
http://wWw.eXaMpLe.cOm

are all valid and equivalent URLs regardless of the server platform

Where the trouble lies is with the path and file name part of the URL
and as the w3.org states: "URLs in general are case-sensitive (with the
exception of machine names)."

http://www.w3.org/TR/WD-html40-970708/htmlweb.html

I have yet to come across a IIS that won't parse:

http://www.example.com/somepath/somefile.ext
http://www.example.com/SOMEPATH/SOMEFILE.EXT
http://www.example.com/somepath/somefile.EXT
http://www.example.com/SOMEpath/somefile.ext
http://www.example.com/sOmEpAtH/sOmEfIlE.eXt

as equivalent so I would argue that case-sensitivity is server platform
dependent.

It's not a good idea to rely on this - one should be consistent.


You make a good point. For most purposes, I'd recommend Windows users
to install Win32 Apache locally, and use that for browsing their
development site. There's far too many shortcomings involved in
browsing files directly, without a server. But in regard to case
sensitivity, it's going to have the same issues as we are discussing.

I have never installed Apache on Windows, but as with other platform
independent software like Perl, case does not matter on Windows but will
on *nixes. I would say building a Linux box would be preferable because
it would force you to be case-aware and your site would work regardless
of the public web server...barring server-side scripting of course if
your doing ASP!

 

[Michael Winter]

Jonathan N. Little wrote:

[snip]

URLs are not *always* case-sensitive

Unless explicitly defined otherwise by the scheme, most URI components
are assumed to case-sensitive. The scheme and host components are a
special case. See section 6.2.2.1 in RFC 3986.

and case-sensitivity *is* platform dependent.

Whether the mapping of URIs to the file system is case-sensitive or not
is platform-dependent, yes, but that's irrelevant to whether URIs
themselves are case-sensitive.

[snip]

I have yet to come across a IIS that won't parse:

http://www.example.com/somepath/somefile.ext
http://www.example.com/SOMEPATH/SOMEFILE.EXT
http://www.example.com/somepath/somefile.EXT
http://www.example.com/SOMEpath/somefile.ext
http://www.example.com/sOmEpAtH/sOmEfIlE.eXt

as equivalent so I would argue that case-sensitivity is server
platform dependent.

Check your browser cache. You should find separate entries for each one
(I do).

It doesn't matter that the server returns precisely the same response:
even after case normalisation (which usually affects only the scheme,
host, and percent-encoding), the URIs will be considered different when
a comparison is made because they /are/ different (certainly so under HTTP).

I would say building a Linux box would be preferable because it would
force you to be case-aware ...

I would recommend a much simpler approach: make sure that all resources
use lower-case names, and write lower-case URIs.

Mike

 

[Alan J. Flavell]

Alan J. Flavell wrote:

I would argue that you are incorrect. URLs are not *always* case-sensitive

As you have pointed out, the host name part is not case-sensitive,
that's true.

and case-sensitivity *is* platform dependent.

No, that's wrong.

Domain names are host names and are
*not* case-sensitive yet a domain names can be a valid URL so:

http://www.example.com
http://WWW.EXAMPLE.COM
http://wWw.eXaMpLe.cOm

are all valid and equivalent URLs regardless of the server platform

Accepted, but this is a distraction from the important point...

Where the trouble lies is with the path and file name part of the
URL and as the w3.org states: "URLs in general are case-sensitive
(with the exception of machine names)."

Fine by me.

http://www.w3.org/TR/WD-html40-970708/htmlweb.html

I have yet to come across a IIS that won't parse:

http://www.example.com/somepath/somefile.ext
http://www.example.com/SOMEPATH/SOMEFILE.EXT
http://www.example.com/somepath/somefile.EXT
http://www.example.com/SOMEpath/somefile.ext
http://www.example.com/sOmEpAtH/sOmEfIlE.eXt

as equivalent so I would argue that case-sensitivity is server platform
dependent.

Those are all different URLs, by definition. If you used them - even
assuming that the web server delivers the same content for all of them
- they would all have to be cached separately by browsers,
intermediate caches, etc.

I have never installed Apache on Windows, but as with other platform
independent software like Perl, case does not matter on Windows but

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

will on *nixes.

Again this is wrong as stated. If I'm running e.g a CGI script on my
Win32 Apache, then the script will see the actual URL that was
presented, case and all, and can act accordingly. The distinction
between differently-cased URLs disappears when the typical win32
server maps URLs into the *file system*, it's true, but that's not
because the URLs have magically become case-insensitive, but because
the *file system* is, for these purposes, case-insensitive. The web
doesn't know that, nor care about such internal server details -
that's an important principle: URLs define a hierarchy of their own,
which was designed to be server-agnostic.

And note also what it says in
http://httpd.apache.org/docs/2.2/platform/windows.html#cust
about case-sensitivity in configuration directives for Win32 Apache.

<aside>
One *could* implement a Windows server in such a way that mis-cased
URLs were redirected (301 would be good) to its canonically-cased URL,
from which the resource would then be retrieved. This could relieve
the problem of multiple URLs which all retrieve the same resource.
But at the cost of an additional network transaction for mis-cased
URLs.
</>

 

[Toby Inkster]

http://www.example.com/somepath/somefile.ext
http://www.example.com/SOMEPATH/SOMEFILE.EXT
http://www.example.com/somepath/somefile.EXT
http://www.example.com/SOMEpath/somefile.ext
http://www.example.com/sOmEpAtH/sOmEfIlE.eXt

These are all different URLs -- it doesn't matter what the server platform
is. It just so happens, that a Windows server will return the same text to
the browser in each case.

But that's no different to:

http://example.org/foo.txt
http://example.com/bar.txt

which are also different URLs, but might (by co-incidence or design)
happen to contain identical text.

 

[Jonathan N. Little]

Again this is wrong as stated. If I'm running e.g a CGI script on my
Win32 Apache, then the script will see the actual URL that was
presented, case and all, and can act accordingly. The distinction
between differently-cased URLs disappears when the typical win32
server maps URLs into the *file system*, it's true, but that's not
because the URLs have magically become case-insensitive, but because
the *file system* is, for these purposes, case-insensitive. The web
doesn't know that, nor care about such internal server details -
that's an important principle: URLs define a hierarchy of their own,
which was designed to be server-agnostic.

It may be semantics here, and that the HTTP transaction will be
case-sensitive and it is the mapping file system case-insensitive
occurs. The file system does come to play here though. Yes your can
configure the web server to compensate, but I have really come across
any. In practice then the server is on a Windows platform and URIs sent
to the server in different case combinations, the web server may treat
as unique resources to fetch. The browser may (does) cache as unique
resources. But the Windows file systems will not fetch difference
resource is will all be the same file. So the "appearance" is that on
Windows platforms the URI may "seem" case-insensitive which can lull
less-savvy web designer to make errors that make their site not platform
independent.

 

[Jonathan N. Little]

These are all different URLs -- it doesn't matter what the server platform
is. It just so happens, that a Windows server will return the same text to
the browser in each case.

But that's no different to:

http://example.org/foo.txt
http://example.com/bar.txt

which are also different URLs, but might (by co-incidence or design)
happen to contain identical text.

But is not in the first instance a matter of indiscrimination of the
platform's files system and in the second by configuration of the web
server?

 

[Toby Inkster]

But is not in the first instance a matter of indiscrimination of the
platform's files system and in the second by configuration of the web
server?

As far as the client is concerned, what's the difference?

 

[Toby Inkster]

It may be semantics here, and that the HTTP transaction will be
case-sensitive and it is the mapping file system case-insensitive
occurs. The file system does come to play here though. Yes your can
configure the web server to compensate, but I have really come across
any.

http://www.nct.org.uk/info/Cot_Death/FSiD
versus
http://www.nct.org.uk/info/Cot_Death/FSID

Windows 2000, Apache 2.0.x.

I didn't take any special measures to "compensate" for the file system's
case-insensitivity -- it's simply that the file system is barely even
*used* to serve this page -- it comes from a (case-sensitive) SQL database.

 

[Alan J. Flavell]

[...] The distinction between differently-cased URLs disappears
when the typical win32 server maps URLs into the *file system*,
it's true, but that's not because the URLs have magically become
case-insensitive, but because the *file system* is, for these
purposes, case-insensitive. The web doesn't know that, nor care
about such internal server details - that's an important
principle: URLs define a hierarchy of their own, which was
designed to be server-agnostic.

It may be semantics here, and that the HTTP transaction will be
case-sensitive and it is the mapping file system case-insensitive
occurs.

As several other contributors have also pointed out: URLs are, by
definition, case-sensitive. You can't argue that away (if that's what
you were trying to do). It's an important principle, as I said, that
the URL scheme was defined to be server-agnostic: the web does not
know, and does not need to know, these details about a server, any
more than it would need to have the "/" replaced by ":" or "\"
depending on details of the server's file system.

The file system does come to play here though. Yes your can
configure the web server to compensate, but I have really come
across any.

I think you missed a negative there, but this is an important
principle, and applies irrespective of whether you or I have seen
examples of it actually being done.

This is rather a fundamental principle of the web architecture - it's
not just an argument about "counting angels on pinheads", which is why
I'm still dragging this argument out as long as you seem to be
obscuring the principle. Sorry.