By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,190 Members | 1,555 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,190 IT Pros & Developers. It's quick & easy.

relative URLs: OK to omit "http:"?

P: n/a
After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL. Are there any pitfalls to this?

For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html

What I'm wondering is if there are any drawbacks to this. (One that I can
think of is that if someone saves the HTML page to their hard disk, the link
won't work anymore since the URL is relative to the document as on the
website, not as on their harddrive.)

Also, I just tried it and it seems that clicking on the link after the page
has been saved to the hard drive crashes IE 6.0.


Jul 20 '05 #1
Share this Question
Share on Google+
24 Replies


P: n/a
sinister wrote:
After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL. Are there any pitfalls to this?

It is not correct usage of the href attribute:
<http://www.w3.org/TR/REC-html40/struct/links.html#h-12.> It should
contain an URI: <http://www.w3.org/TR/REC-html40/types.html#type-uri>

Your example is _not_ a valid URI.
--
Anne van Kesteren
http://www.annevankesteren.nl/
Jul 20 '05 #2

P: n/a
"sinister" <si******@nospam.invalid> wrote:
After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL.
Of course, it's a basic part of authoring almost any site.
Are there any pitfalls to this?
You need to change links if you move a file around within a site.
For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html
No, you'd shorten it to just page2.html or /page2.html
The version you give is very odd and might cause problems.
What I'm wondering is if there are any drawbacks to this. (One that I can
think of is that if someone saves the HTML page to their hard disk, the link
won't work anymore since the URL is relative to the document as on the
website, not as on their harddrive.)
That's true. But the browser may alter the file when it saves it in
order to prevent this. Browsers vary, and how you trigger this
behaviour may vary as well.
Also, I just tried it and it seems that clicking on the link after the page
has been saved to the hard drive crashes IE 6.0.


Hmmm. Using the strange URL you quoted above? Not surprised that it
doesn't work, surprised that it actuallu crashes anything. But we are
talking IE here...

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #3

P: n/a

"sinister" <si******@nospam.invalid> wrote in message
news:DR***************@nwrddc01.gnilink.net...
After doing a websearch, it appears that it's OK to omit the "http:" to form a relative URL. Are there any pitfalls to this?

For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html


This isn't relative. It shows no relationship of any kind to the first page,
which is on a different, unrelated web site. It is an absolute URL without
the "http:". Maybe some browsers assume a default protocol of "http:" if you
don't use one. IE does if you leave out the protocol in the browser's
Address field; I don't know if IE will work properly if a URL like this is
in an HREF.

A relative URL is just that--identification of a page's location in
relationship to the location of the current page. If used on page1.html, a
URL of

page2.html

is a reference to a file called page2.html in the same directory as
page1.html. A reference to

../page3.html

points to a page in the first page's directory's parent directory. A
reference to

/page4.html

points to a page on the same server as the first page. These are all
relative.

Jul 20 '05 #4

P: n/a

"Anne van Kesteren" <ma**@annevankesteren.nl> wrote in message
news:bo**********@reader08.wxs.nl...
sinister wrote:
After doing a websearch, it appears that it's OK to omit the "http:" to form a relative URL. Are there any pitfalls to this? It is not correct usage of the href attribute:
<http://www.w3.org/TR/REC-html40/struct/links.html#h-12.> It should
contain an URI: <http://www.w3.org/TR/REC-html40/types.html#type-uri>

Your example is _not_ a valid URI.


Which? There are 3 paths in my example.


--
Anne van Kesteren
http://www.annevankesteren.nl/

Jul 20 '05 #5

P: n/a

"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:bo*************@ID-114100.news.uni-berlin.de...

"sinister" <si******@nospam.invalid> wrote in message
news:DR***************@nwrddc01.gnilink.net...
After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL. Are there any pitfalls to this?

For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html


This isn't relative. It shows no relationship of any kind to the first

page, which is on a different, unrelated web site. It is an absolute URL without the "http:". Maybe some browsers assume a default protocol of "http:" if you don't use one. IE does if you leave out the protocol in the browser's
Address field; I don't know if IE will work properly if a URL like this is
in an HREF.

A relative URL is just that--identification of a page's location in
relationship to the location of the current page. If used on page1.html, a
URL of

page2.html

is a reference to a file called page2.html in the same directory as
page1.html. A reference to

../page3.html

points to a page in the first page's directory's parent directory. A
reference to

/page4.html

points to a page on the same server as the first page. These are all
relative.


But
http://www.webreference.com/html/tutorial2/3.html states:
"A relative URL that begins with // (two slashes) always replaces everything
from the hostname onwards."
It has this example: working from a base URL of
http://WebReference.com/html/
the relative URL
//www.internet.com/
is translated into
http://www.internet.com/

Similarly, http://www.w3.org/Addressing/rfc1808.txt has a base URL of
<URL:http://a/b/c/d;p?q#f>
plus a relative URL of
//g
being mapped to
http://g
if I'm reading that doc correctly.
Jul 20 '05 #6

P: n/a

"Steve Pugh" <st***@pugh.net> wrote in message
news:39********************************@4ax.com...
"sinister" <si******@nospam.invalid> wrote:
After doing a websearch, it appears that it's OK to omit the "http:" to forma relative URL.
Of course, it's a basic part of authoring almost any site.
Are there any pitfalls to this?


You need to change links if you move a file around within a site.
For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html


No, you'd shorten it to just page2.html or /page2.html
The version you give is very odd and might cause problems.


I think you misunderstood my example.

If the page
http://www.domain1.com/page1.html
contains
page2.html
or
/page2.html
those relative URLs become
http://www.domain1.com/page1.html
whereas I want "domain2.com", not "domain1.com".

About the strange example, with the leading "//":
http://www.webreference.com/html/tutorial2/3.html states:
"A relative URL that begins with // (two slashes) always replaces everything
from the hostname onwards."
It has this example: working from a base URL of
http://WebReference.com/html/
the relative URL
//www.internet.com/
is translated into
http://www.internet.com/

Similarly, http://www.w3.org/Addressing/rfc1808.txt has a base URL of
<URL:http://a/b/c/d;p?q#f>
plus a relative URL of
//g
being mapped to
http://g
if I'm reading that doc correctly.
What I'm wondering is if there are any drawbacks to this. (One that I canthink of is that if someone saves the HTML page to their hard disk, the linkwon't work anymore since the URL is relative to the document as on the
website, not as on their harddrive.)


That's true. But the browser may alter the file when it saves it in
order to prevent this. Browsers vary, and how you trigger this
behaviour may vary as well.


Right.
Also, I just tried it and it seems that clicking on the link after the pagehas been saved to the hard drive crashes IE 6.0.


Hmmm. Using the strange URL you quoted above? Not surprised that it
doesn't work, surprised that it actuallu crashes anything. But we are
talking IE here...


Right...
Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>



Jul 20 '05 #7

P: n/a
Anne van Kesteren wrote:
sinister wrote:
After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL. Are there any pitfalls to this?


It is not correct usage of the href attribute:
<http://www.w3.org/TR/REC-html40/struct/links.html#h-12.> It should
contain an URI: <http://www.w3.org/TR/REC-html40/types.html#type-uri>

Your example is _not_ a valid URI.


My understanding of RFC2396 is that //host and //host/path are
relative URIs, called network-path references (sec. 5). Appendix
C.1, titled "Normal Examples", shows how the relative URI //g
should be resolved when the base URI is http://a/b/c/d;p?q . The
resulting absolute URI is http://g . And that's not even an
abnormal example.

The HTML4.01 specification, section 6.4, says: "Relative URIs are
resolved to full URIs using a base URI. [RFC1808], section 3,
defines the normative algorithm for this process". But section 3
doesn't define any process of resolving relative URIs; section 3
talks about the various ways of establishing a base URL. And
indeed, HTML4.01, sec. 12.4.1, says that "user agents must
calculate the base URI for resolving relative URIs according to
[RFC1808], section 3". Does that mean there isn't a normative
algorithm for resolving URIs?

RFC1808, sec. 4, and RFC2396, sec. 5.2, on the other hand, suggest
possible algorithms for resolving relative URLs.

--
Jock
Jul 20 '05 #8

P: n/a
"sinister" <si******@nospam.invalid> wrote:
"Steve Pugh" <st***@pugh.net> wrote:
"sinister" <si******@nospam.invalid> wrote:
>After doing a websearch, it appears that it's OK to omit the "http:" to
>form a relative URL.

>For example, if there is a page
>http://www.domain1.com/page1.html
>with a link to
>http://www.domain2.com/page2.html
>you can abbreviate the second link as
>//www.domain2.com/page2.html


No, you'd shorten it to just page2.html or /page2.html
The version you give is very odd and might cause problems.


I think you misunderstood my example.


Sorry, I missed the fact that they are two different domains.

And on reflection, once my memory started working I realised that yes,
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.

Calling it a relative URL is a bit misleading. Strictly speaking it is
a relative URL, but really the only thing it's relative to is the
protocol.

Which explains your problem with locally saved copies.
//example.com/foo/bar is then resolved as being
file://example.com/foo/bar and the browser goes off looking for a
local host called example.com.
Obviously it won't find it, but IE still shouldn't have crashed.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #9

P: n/a
On Wed, 5 Nov 2003, Steve Pugh wrote:
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.


Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?
Jul 20 '05 #10

P: n/a
On Wed, 5 Nov 2003, Steve Pugh wrote:
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.

Alan J. Flavell <fl*****@ph.gla.ac.uk> wrote: Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?


My reading of http://www.ietf.org/rfc/rfc2396.txt is that a relative URI
can omit only the scheme. Excerpted from Appendix C:

relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
...
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
...
authority = server | reg_name
...
server = [ [ userinfo "@" ] hostport ]

Have I misread the RFC?
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"We are Microsoft. Resistance is futile. You will be assimilated."
Jul 20 '05 #11

P: n/a

"Steve Pugh" <st***@pugh.net> wrote in message
news:m9********************************@4ax.com...
"sinister" <si******@nospam.invalid> wrote:
"Steve Pugh" <st***@pugh.net> wrote:
"sinister" <si******@nospam.invalid> wrote:

>After doing a websearch, it appears that it's OK to omit the "http:" to >form a relative URL.

>For example, if there is a page
>http://www.domain1.com/page1.html
>with a link to
>http://www.domain2.com/page2.html
>you can abbreviate the second link as
>//www.domain2.com/page2.html

No, you'd shorten it to just page2.html or /page2.html
The version you give is very odd and might cause problems.
I think you misunderstood my example.


Sorry, I missed the fact that they are two different domains.

And on reflection, once my memory started working I realised that yes,
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.

Calling it a relative URL is a bit misleading. Strictly speaking it is
a relative URL, but really the only thing it's relative to is the
protocol.

Which explains your problem with locally saved copies.
//example.com/foo/bar is then resolved as being
file://example.com/foo/bar and the browser goes off looking for a
local host called example.com.


Right.
Obviously it won't find it, but IE still shouldn't have crashed.
Right, but...
Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

Jul 20 '05 #12

P: n/a
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
On Wed, 5 Nov 2003, Steve Pugh wrote:
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.


Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?


As other people have said: RFC2396. Although, on a quick reread, I
can't see an explicit "SHOULD" for this case, I think it's a
reasonable opinion based on, amongst other things, the example //g
given in Appendix C.1.

Do you have a different opinion?

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #13

P: n/a
On Thu, 6 Nov 2003, Steve Pugh wrote:
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
On Wed, 5 Nov 2003, Steve Pugh wrote:
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.
Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?


As other people have said: RFC2396.


Sorry, you caught me out being lazy - I asked the question in
preference to actually consulting the spec.
Although, on a quick reread, I can't see an explicit "SHOULD" for
this case, I think it's a reasonable opinion based on, amongst other
things, the example //g given in Appendix C.1.
I can't fault you on that. The more formal part would be section 5,
and the specific paragraph seems to be:

A relative reference beginning with two slash characters is termed a
network-path reference, as defined by <net_path> in Section 3.
Such references are rarely used.

The justification for wanting such references is given in the third
paragraph of section 5.
Do you have a different opinion?


I didn't really have an opinion at that point - I asked the question
because I was unsure - but I confess the right thing to do would have
been to consult the RFC - which I have now done - rather than to
pester usenet.

What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?

Jul 20 '05 #14

P: n/a
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?


Totally agreed. I would certainly not recommend the use on a www site.
The benefits on that case (saving five bytes per off-site link) are
unlikely to outweigh the problems (broken local copies; uncertain
browser support).

On a site/network/whatever that was accessed via multiple schemes it
could conceivably be useful, but only in the case where the authority
and path would be the same for all usable schemes. Which in my
experience is rarely the case.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #15

P: n/a

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk...
On Thu, 6 Nov 2003, Steve Pugh wrote:
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
On Wed, 5 Nov 2003, Steve Pugh wrote:

> a URL starting with // will resolve as //hostname/path and that should> work in any decent browser.

Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?


As other people have said: RFC2396.


Sorry, you caught me out being lazy - I asked the question in
preference to actually consulting the spec.
Although, on a quick reread, I can't see an explicit "SHOULD" for
this case, I think it's a reasonable opinion based on, amongst other
things, the example //g given in Appendix C.1.


I can't fault you on that. The more formal part would be section 5,
and the specific paragraph seems to be:

A relative reference beginning with two slash characters is termed a
network-path reference, as defined by <net_path> in Section 3.
Such references are rarely used.

The justification for wanting such references is given in the third
paragraph of section 5.
Do you have a different opinion?


I didn't really have an opinion at that point - I asked the question
because I was unsure - but I confess the right thing to do would have
been to consult the RFC - which I have now done - rather than to
pester usenet.

What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?


It works in IE 6.

What's the point of having a spec if the spec isn't followed?
Jul 20 '05 #16

P: n/a
"sinister" <si******@nospam.invalid> wrote:
It works in IE 6.
And 'works' includes crashing, by you own account
What's the point of having a spec if the spec isn't followed?


Good question. Maybe Microsoft have an answer, considering how often
they fail to follow the spec...

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #17

P: n/a
"Alan J. Flavell" wrote:
A relative reference beginning with two slash characters is termed a
network-path reference, as defined by <net_path> in Section 3.
Such references are rarely used.

The justification for wanting such references is given in the third
paragraph of section 5.
The example given in the justification is one that would be used infrequently,
however there is one good use for network-path references: Sites which are
accessible with http and https schemes can implement scheme independent links
to other servers, for example

<img src="//imageserver.example.org/example.gif" width="100" height="100"
alt="This is an example" />

Without network-paths, developers have a choice between using the http scheme,
which results in a warning message and/or broken image links when the page is
accessed over https, or using the https scheme which means unnecessary overhead
when the page is served over http (at least for static pages, for dynamic
content the server can set the scheme in references to other servers according
to the scheme used for accessing a page).
What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?


This is widely implemented in current and older browsers such as Netscape 4
(and I believe even earlier versions of Netscape and Internet Explorer handled
this fine), as well as libraries such as the Perl HTTP library.

--
Klaus Johannes Rusch
Kl********@atmedia.net
http://www.atmedia.net/KlausRusch/
Jul 20 '05 #18

P: n/a
Alan J. Flavell wrote:
What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?


I've noticed slashdot.org uses it widely, which probably indicates browser
support is very good.

James

Jul 20 '05 #19

P: n/a
Tim
Alan J. Flavell wrote:
What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?

James Bursa <ja*********@strcprstskrzkrk.co.uk> wrote:
I've noticed slashdot.org uses it widely, which probably indicates browser
support is very good.


I wouldn't use that, or any other particular site to reinforce the
notion. To post a contrary example: We've all noticed many sites with
serious errors, therefore those errors can't be so serious (even if the
site doesn't work). :-\

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.
Jul 20 '05 #20

P: n/a
"sinister" <si******@nospam.invalid> wrote in message
news:6d***************@nwrddc01.gnilink.net...

But
http://www.webreference.com/html/tutorial2/3.html states:
"A relative URL that begins with // (two slashes) always replaces everything from the hostname onwards."


First, just speaking logically: If webreference.com said a dog without a
tail is a cat, would it be right? "Relative" means "in relationship to". A
relative URL is one stated in terms that are relative to the location of the
current resource.

Now that I've said *that*, I see that the RFC defines "relative URL" as
anything that doesn't start with the protocol (what they are calling a
"scheme") and colon. So I concede that the technical term is defined this
way. I guess I can understand it if I think of the "scheme" as an uppermost
node on some hierarchy that includes all the resources (hosts, etc.)
underneath it. On a page requested via https:, a URL of "//a/b" is to be
interpreted "relatively" to this topmost "https" node--that is, the browser
should know that https://a/b is meant, not http://a/b.

Jul 20 '05 #21

P: n/a
"Harlan Messinger" <h.*********@comcast.net> wrote in message news:<bo*************@ID-114100.news.uni-berlin.de>...
This isn't relative. It shows no relationship of any kind to the first page,
which is on a different, unrelated web site. It is an absolute URL without
the "http:". Maybe some browsers assume a default protocol of "http:" if you
don't use one. IE does if you leave out the protocol in the browser's
Address field; I don't know if IE will work properly if a URL like this is
in an HREF.


No, actually, it's a perfectly valid relative URI, where "relative"
means, in this case, that it's "relative" to the protocol used in the
base URI. Thus, if a site has a link to
"//domain2.example/page1.html", then if the base URI from which the
link is made is "http://domain1.example/page2.html", then the link URI
would resolve to "http://domain2.example/page1.html"; however, if the
base URI were in a different protocol, say
"https://domain1.example/page2.html" or
"ftp://domain1.example/page2.html", then the resolved link URI would
be "https://domain2.example/page1.html" or
"ftp://domain2.example/page1.html" respectively.

I actually had occasion to use such a link, years ago, on a page that
could be accessed with both a secure (https) or normal (http) Web
address, and which used images from a different domain which similarly
could be accessed by http or https; I wanted the images to be accessed
via the same protocol as the main page (since browsers typically give
warnings or refuse to display portions of the page if secure and
nonsecure protocols are mixed). The syntax starting with "//" worked
fine for my purpose, and on testing, proved to work in all common
browsers at the time (granted, this was in a time when Netscape 3.x
was still a common browser, so I don't know how well it works *now*.)

My discussion of absolute and relative URIs:
http://webtips.dan.info/url.html

--
Dan
Jul 20 '05 #22

P: n/a
Sometime around Thu, 06 Nov 2003 12:41:27 GMT, sinister is reported to have
stated:

What's the point of having a spec if the spec isn't followed?


Take a look at how different all the browsers are. Then imagine how
different they would be if they were all completely making it up as they
went, rather than there being a specification for them to follow (albeit
somewhat badly).

--
Mark Parnell
http://www.clarkecomputers.com.au
Jul 20 '05 #23

P: n/a
"sinister" <si******@nospam.invalid> wrote in message news:<DR***************@nwrddc01.gnilink.net>...
After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL. Are there any pitfalls to this?

For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html

What I'm wondering is if there are any drawbacks to this. (One that I can
think of is that if someone saves the HTML page to their hard disk, the link
won't work anymore since the URL is relative to the document as on the
website, not as on their harddrive.)

Also, I just tried it and it seems that clicking on the link after the page
has been saved to the hard drive crashes IE 6.0.


See the FAQ at Tim BL's personal page
http://www.w3.org/People/Berners-Lee/FAQ.html#etc

I tested it a while ago. It failed in Lynx. I wouldn't be surprised if
it fails in other browsers too.

--
hzr
Jul 20 '05 #24

P: n/a

"Mark Parnell" <we*******@clarkecomputers.com.au> wrote in message
news:ql*****************************@40tude.net...
Sometime around Thu, 06 Nov 2003 12:41:27 GMT, sinister is reported to have stated:

What's the point of having a spec if the spec isn't followed?
Take a look at how different all the browsers are. Then imagine how
different they would be if they were all completely making it up as they
went, rather than there being a specification for them to follow (albeit
somewhat badly).


I agree. I didn't mean to say there's no point in having a spec, but rather
that the spec should be followed.

--
Mark Parnell
http://www.clarkecomputers.com.au

Jul 20 '05 #25

This discussion thread is closed

Replies have been disabled for this discussion.