Empty Anchors, I can't find a W3C specification for it

[Lastwebpage]

Hello,
I am little surprised about the following:
<a href="#" ...

I found some lines about the href tag for a site should point to an
name or in XHTML to an ID,
but in both cases this seems to be not valid name="#" or id=""...
And I wonder why the online validator allow this in all cases.DOCUMENT
types.

Can someone give me a definitive link to any W3C document where I can
see this is Valid? I found only some sites where the consequence would
be this is not valid.

Peter

[Jukka K. Korpela]

Scripsit La*********@gmail.com:

I am little surprised about the following:
<a href="#" ...

Just don't use them, mm'kay? But that's a practical issue. Formally, it is
well-defined.

I found some lines about the href tag for a site should point to an
name or in XHTML to an ID,

Wrong. The href _attribute_ value is a _URL_. You need to check the current
URL specifications to see what is allowed as a URL.

Can someone give me a definitive link to any W3C document where I can
see this is Valid?

The relevant DTD in a the relevant HTML specification implies that it is
valid, just as href="some %¤!¤"9^ stuff I just decided to put here!" is
valid. Validity means very little in this context.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Alexander Clauss]

La*********@gmail.com <La*********@gmail.comwrote:

I am little surprised about the following:
<a href="#" ...

Yes, this is often found in the web. In general this doesn't make any
sense but because the author of the web page doesn't know very much
about JavaScript and event handlers (especially about the return value
of the "onclick" handler), he uses this empty fragment identifier to
workaround some side effects of his bad and buggy JavaScript code.

Usually you'll find these empty fragment identifier together with an
onclick handler like in the following code:

<a href="#" onclick="someJavaScriptCode()">click here</a>

In this case clicking the link will execute the javascript code of the
onclick handler first. The hanlder can then return a value (true, false)
to tell the browser if the default action of the link must be also
executed (which means opening the page that is referenced through the
href attribute). So returning the value "false" forces the browser not
to open the link. But web authors who don't know about this don't return
any value in the event handler and so the browser is also executing the
default action for the link. Which means opening the page that is given
in the href attribute. And so these web authors tend to use this
"#" in the href attribute to prevent that the browser doesn't open a new
page. But this has also some negative side effects: some browsers scroll
the page to the top, assuming the empty fragment identifier identifies
the top of the document.

I found some lines about the href tag for a site should point to an
name or in XHTML to an ID,

No, the href attribute must always contain an URI value. The fragment
identifier (the part after the "#") is also part of an URI value. So
"#" is a relative URL which can be resolved to the absolute URL of the
document itself. This is the reason why this "#" is "working": it
tells the browser to load the page which is already displayed and this
will usually be interpreted by the browser to do nothing (because the
page is already shown). But as I said above, some browsers scroll to the
top, some may even reload the page that is currently displayed.
--
Alexander

[Lastwebpage]

On 7 Apr., 14:08, "Jukka K. Korpela" <[e-mail]:

Scripsit [e-mail]:

I am little surprised about the following:
<a href="#" ...

Just don't use them, mm'kay? But that's a practical issue. Formally, it is
well-defined.

I found some lines about the href tag for a site should point to an
name or in XHTML to an ID,

Wrong. The href _attribute_ value is a _URL_. You need to check the current
URL specifications to see what is allowed as a URL.

Can someone give me a definitive link to any W3C document where I can
see this is Valid?

The relevant DTD in a the relevant HTML specification implies that it is
valid, just as href="some %¤!¤"9^ stuff I just decided to put here!" is
valid. Validity means very little in this context.

--
Jukka K. Korpela ("Yucca")http://www.cs.tut.fi/~jkorpela/

Thanks, I searched at the wrong place in the W3C docu, now I found
http://www.w3.org/Addressing/URL/4_2_Fragments.html and some other
places.
In my opinon there is still something wrong in the anchor definition
for XHTML, but ok.

Peter

[Lastwebpage]

On 7 Apr., 15:18, [e-mail] (Alexander Clauss)
wrote:

[e-mail] <[e-mail]:

I am little surprised about the following:
<a href="#" ...

Yes, this is often found in the web. In general this doesn't make any
sense but because the author of the web page doesn't know very much
about JavaScript and event handlers (especially about the return value
of the "onclick" handler), he uses this empty fragment identifier to
workaround some side effects of his bad and buggy JavaScript code.

Usually you'll find these empty fragment identifier together with an
onclick handler like in the following code:

<a href="#" onclick="someJavaScriptCode()">click here</a>

In this case clicking the link will execute the javascript code of the
onclick handler first. The hanlder can then return a value (true, false)
to tell the browser if the default action of the link must be also
executed (which means opening the page that is referenced through the
href attribute). So returning the value "false" forces the browser not
to open the link. But web authors who don't know about this don't return
any value in the event handler and so the browser is also executing the
default action for the link. Which means opening the page that is given
in the href attribute. And so these web authors tend to use this
"#" in the href attribute to prevent that the browser doesn't open a new
page. But this has also some negative side effects: some browsers scroll
the page to the top, assuming the empty fragment identifier identifies
the top of the document.

I found some lines about the href tag for a site should point to an
name or in XHTML to an ID,

No, the href attribute must always contain an URI value. The fragment
identifier (the part after the "#") is also part of an URI value. So
"#" is a relative URL which can be resolved to the absolute URL of the
document itself. This is the reason why this "#" is "working": it
tells the browser to load the page which is already displayed and this
will usually be interpreted by the browser to do nothing (because the
page is already shown). But as I said above, some browsers scroll to the
top, some may even reload the page that is currently displayed.

--
Alexander

Found it now, thanks, see answer above.

Peter

[Jukka K. Korpela]

Scripsit La*********@gmail.com:

Thanks, I searched at the wrong place in the W3C docu, now I found
http://www.w3.org/Addressing/URL/4_2_Fragments.html and some other
places.

The W3C pages are not the authoritative source on URL syntax. They refer to
URL RFCs. The authoritative specification of generic URL syntax is Internet
standard 66, currently RFC 3986, see
http://www.apps.ietf.org/rfc/rfc3986.html

In my opinon there is still something wrong in the anchor definition
for XHTML, but ok.

As I mentioned, href="#" is practically wrong anyway, so why bother? The
HTML vs. XHTML distinction is irrelevant here.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
Quote this sig to join the Clueless Club!

[Jukka K. Korpela]

Scripsit Alexander Clauss:

So "#" is a relative URL which can be resolved to the absolute URL of the
document itself. This is the reason why this "#" is "working": it
tells the browser to load the page which is already displayed and this
will usually be interpreted by the browser to do nothing (because the
page is already shown).

Browsers are, by the specification, not expected to _reload_ the page, but
that's different from not doing anything. A simple href="#foo" should not
cause a reload either, but it should and it does cause a repositioning of
the document's content in the browser window.

But as I said above, some browsers scroll to
the top, some may even reload the page that is currently displayed.

All browsers I've tested treat href="#" as a reference to the top of the
page, positioning the content accordingly, without reloading the page. Some
versions of Opera have been reported to fail to understand href="#" at all,
but this should be considered a browser bug.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Alexander Clauss]

Jukka K. Korpela <jk******@cs.tut.fiwrote:

A simple href="#foo" should not cause a reload either,
but it should and it does cause a repositioning of
the document's content in the browser window.

Yes, because this URL includes an explicit destination inside the
document.

All browsers I've tested treat href="#" as a reference to the
top of the page,

You've not tested all existing browsers ;-)
And of course a browser is not required to assume that a non-existing
or empty fragment identifier represents the top of the document.

But in any case, if the onclick handler would return a suitable value
the silly "#" URLs would not be necessary.
--
Alexander

[Adrienne Boswell]

Gazing into my crystal ball I observed ac*****@hrzpub.tu-darmstadt.de
(Alexander Clauss) writing in news:1hw7gek.5izlpu1jzf1f4N%
ac*****@hrzpub.tu-darmstadt.de:

>I am little surprised about the following:
<a href="#" ...

Yes, this is often found in the web. In general this doesn't make any
sense but because the author of the web page doesn't know very much
about JavaScript and event handlers (especially about the return value
of the "onclick" handler), he uses this empty fragment identifier to
workaround some side effects of his bad and buggy JavaScript code.

I actually use it when I am in the process of creating/testing a site.
For example:
<li><a href="#">Contact</a></li>
<li><a href="#">Links</a></li>
....
--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

[Lars Eighner]

In our last episode,
<11**********************@y80g2000hsf.googlegroups .com>,
the lovely and talented La*********@gmail.com
broadcast on comp.infosystems.www.authoring.html:

Hello,
I am little surprised about the following:
<a href="#" ...

In the first place, you have not given enough to tell whether
the anchor is empty or not. Your question seems to be about the
href attribute. <a href="anycrap"></awould be an empty anchor.
<a href="!@#$#%^&">Something</awould not be an empty anchor.

I found some lines about the href tag for a site should point to an
name or in XHTML to an ID,
but in both cases this seems to be not valid name="#" or id=""...
And I wonder why the online validator allow this in all cases.DOCUMENT
types.

The specs (for 4.01) say href should be a URI, which is CDATA and in
particular an absolute URI or a relative URI either of which may be followed
by a fragment starting with "#". The fragment is supposed to be "additional
reference information to be interpreted by the user agent." The empty string
is a valid relative URI and what to make of the empty fragment is a task for
the user agent. So, yes, this seems to be VALID, but valid does not
necessarily mean useful, meaningful, what you had in mind, good, right,
desirable, etc. However id="" is not valid because id must begin with a
letter, which the empty string doesn't (4.01 spec) --- and of course,
name="#" is not valid for a similar reason.

Can someone give me a definitive link to any W3C document where I can
see this is Valid? I found only some sites where the consequence would
be this is not valid.

RFC2396 and the 4.01 spec.

--
Lars Eighner <http://larseighner.com/ <http://myspace.com/larseighner>
Countdown: 653 days to go.
Chinese Terrorists:: Xuzhou Anying Biologic Technology Development Company Ltd.
Identified :: Wangdian Industrial Zone, Peixian, CN-32, China 221623

[=?ISO-8859-1?Q?G=E9rard_Talbot?=]

La*********@gmail.com wrote :

Hello,
I am little surprised about the following:
<a href="#" ...

You could search for the thread

Subject line: "Empty fragment identifier: <a href="#" ...>"
newsgroup: alt.html
Date posted on July 27th 2004 and replied on July 28th 2004.
I think Richard Formby's reply was best:

{
(...)
RFC1808, in section 2.2 defines in modified BNF form
"fragment = 1*pchar"
and mentions that the 1* means "[one] or more repetitions of the [pchar].

So, zero repetitions is not allowed and href="#" is therefore an error.

Since it is an error then the browser, as per the spec, is at liberty to
interperet it as the browser sees fit. There is no "correct" behaviour.
}

So, I too would recommend to stay away from href="#" and would
explicitly recommend to avoid using href="#" at all times.

Gérard
--
Using Web Standards in your Web Pages (Updated Dec. 2006)
http://developer.mozilla.org/en/docs...your_Web_Pages

[Lars Eighner]

In our last episode,
<13*************@corp.supernews.com>,
the lovely and talented Gérard Talbot
broadcast on comp.infosystems.www.authoring.html:

La*********@gmail.com wrote :

>Hello,
I am little surprised about the following:
<a href="#" ...

You could search for the thread

Subject line: "Empty fragment identifier: <a href="#" ...>"
newsgroup: alt.html
Date posted on July 27th 2004 and replied on July 28th 2004.
I think Richard Formby's reply was best:

{
(...)
RFC1808, in section 2.2 defines in modified BNF form
"fragment = 1*pchar"
and mentions that the 1* means "[one] or more repetitions of the [pchar].

RFC2396 supersedes RFC1808, and it states that a fragment is
*uric (i.e. 0 or more uric characters) [Section 4.1, RFC2396]. Clearly
the empty string (consisting of 0 uric) is valid, although as I have
written elsewhere, that does not mean that it is necessarily useful,
meaningful, etc. The interpretation of the fragment is up to the user
agent.

So, zero repetitions is not allowed and href="#" is therefore an error.

Since it is an error then the browser, as per the spec, is at liberty to
interperet it as the browser sees fit. There is no "correct" behaviour.
}

So, I too would recommend to stay away from href="#" and would
explicitly recommend to avoid using href="#" at all times.

Gérard

--
Lars Eighner <http://larseighner.com/ <http://myspace.com/larseighner>
Countdown: 653 days to go.
Chinese Terrorists:: Xuzhou Anying Biologic Technology Development Company Ltd.
Identified :: Wangdian Industrial Zone, Peixian, CN-32, China 221623

[Jukka K. Korpela]

Scripsit Lars Eighner:

RFC2396 supersedes RFC1808,

and has itself been superseded. I wonder makes people keep babbling about
the issue, despite all the correct information having been given several
times in the past (in the midst of garbage as usual). The quote RFCs that
have been obsoleted many years ago (and misinterpret them).

Don't people even check RFC editor's database about the status of RFCs
before citing them??

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[John Hosking]

Jukka K. Korpela wrote:

Scripsit Lars Eighner:

>RFC2396 supersedes RFC1808,

and has itself been superseded.

>
Don't people even check RFC editor's database about the status of RFCs
before citing them??

Well, this is cool. I was just wondering how anybody not actually
writing one of the RFCs would know which RFCs are current and which
obsoleted. And now I have an answer (for which, as is The Jukka Way, I
have had to make the actual effort myself).

I plugged the mystic phrase "RFC editor's database" into my nearest
search engine and out popped a list of databases which (purport to) list
current RFCs and the RFCs which replace them, their topic areas, etc.

For those even lazier than I am, http://www.rfc-editor.org/ is a place
to visit and treasure.

--
John

[Lars Eighner]

In our last episode,
<vW*******************@reader1.news.saunalahti.fi> ,
the lovely and talented Jukka K. Korpela
broadcast on comp.infosystems.www.authoring.html:

Scripsit Lars Eighner:

>RFC2396 supersedes RFC1808,

and has itself been superseded.

The current 4.01 Spec cites RFC2396. nks for letting me know that
w3.org is full of shit as usual.

I wonder makes people keep babbling about
the issue,

Why does w3 cite an obsolete RFC?

despite all the correct information having been given several
times in the past (in the midst of garbage as usual).

The garbage as usual is right here:

Linkname: HTML 4 Specification References
URL: <http://www.w3.org/TR/html401/references.html#ref-URI>

The quote RFCs that
have been obsoleted many years ago (and misinterpret them).

Yup, I guess that is what W3 is all about.

Don't people even check RFC editor's database about the status of RFCs
before citing them??

It is W3C that did it. And as usual, relying on the current version of
a W3 spec is inviting a knife in the back.

--
Lars Eighner <http://larseighner.com/ <http://myspace.com/larseighner>
Countdown: 653 days to go.
Chinese Terrorists:: Xuzhou Anying Biologic Technology Development Company Ltd.
Identified :: Wangdian Industrial Zone, Peixian, CN-32, China 221623

[Stan Brown]

Sun, 8 Apr 2007 14:00:36 +0300 from Jukka K. Korpela
<jk******@cs.tut.fi>:

Don't people even check RFC editor's database about the status of RFCs
before citing them??

Until this moment, I didn't know one existed. URL?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[Eric B. Bednarz]

Gérard Talbot <ne***********@gtalbot.orgwrites:

I think Richard Formby's reply was best:

RFC1808, in section 2.2 defines in modified BNF form
"fragment = 1*pchar"
and mentions that the 1* means "[one] or more repetitions of the [pchar].

His reply was certainly best in the sense of entertainment, since it
provides room for speculation whether it was malicious, humorous or just
careless; citing an RFC is much like citing Don Quixote, you can usually
get away with whatever you make up on the spot, because nobody has read
it or even cares to look up particulars when mentioned.
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011