Empty fragment identifier: <a href="#" ...>

[DU]

I often see this type of anchor:

<a href="#"
onclick="window.open('http://www.domainName.com/someFile.html',
'WindowName', '[list of parameters]);">Descriptive text</a>

Now, there is no return false canceling the default action of the link,
so, the script should open the secondary window and then scroll back to
the top of the document in the opener and add a crosshatch "#" character
to the opener's uri.

I searched to better understand this behavior and found this:

http://www.ietf.org/rfc/rfc1808.txt
2.4.1. Parsing the Fragment Identifier

If the parse string contains a crosshatch "#" character, then the
substring after the first (left-most) crosshatch "#" and up to the
end of the parse string is the <fragment> identifier. If the
crosshatch is the last character, or no crosshatch is present, then
the fragment identifier is empty. The matched substring, including
the crosshatch character, is removed from the parse string before
continuing.
http://www.ietf.org/rfc/rfc1808.txt

Some browsers scroll back to the top and add the crosshatch "#"
character to the uri. Some other browsers do not seem to do that.
And the rfc1808 seems to suggest that browsers should not append the
crosshatch "#" to the uri.

I'm really confused. Can someone clarify all this? What should be the
correct behavior of browsers when parsing and rendering links coded like
<a href="#" ...>?

DU

 

[Mark Parnell]

I'm really confused. Can someone clarify all this? What should be the
correct behavior of browsers when parsing and rendering links coded like
<a href="#" ...>?

Does it really matter? Links shouldn't be written like that in the first
place. Don't write the links like that, and you don't need to worry
about what the browsers will do.

 

[Luigi Donatello Asero]

Does it really matter? Links shouldn't be written like that in the first
place. Don't write the links like that, and you don't need to worry
about what the browsers will do.

Is it wrong to write so?
<a href="#skip"> <img src="./ONEPIC.GIF" height="1" width="1" alt="Bitte,
zum Hauptinhalt dieser Seite direkt gehen"></a>
The page http://www.scaiecat-spa-gigi.com/de/ferienwohnung-sizilien.html
validates

 

[DU]

Does it really matter? Links shouldn't be written like that in the first
place. Don't write the links like that, and you don't need to worry
about what the browsers will do.

I agree but there is a bugfile at bugzilla requesting that Mozilla
behaves like other browsers (which does not bring back the document to
the top) and after searching, I couldn't find anything explicitly
describing this behavior as the correct, expected behavior.

My question remains: after
<a href="#" ...>
where does it say that the document should (or should not) scroll back
to the top of the document?

DU

 

[Neal]

Is it wrong to write so?
<a href="#skip"> <img src="./ONEPIC.GIF" height="1" width="1" alt="Bitte,
zum Hauptinhalt dieser Seite direkt gehen"></a>
The page http://www.scaiecat-spa-gigi.com/de/ferienwohnung-sizilien.html
validates

Here, your anchor points to the precise location id="skip" in your current

 

[Toby A Inkster]

I'm really confused. Can someone clarify all this? What should be the
correct behavior of browsers when parsing and rendering links coded like
<a href="#" ...>?

The "correct" behaviour is not defined anywhere I'm afraid. I've looked
into this before and my head started to hurt. I think I reached the
conclusion that it wasn't entirely clear whether <a href="#"> was even
*allowed* by the HTML 4.01 spec.

 

[DU]

DU wrote:




The "correct" behaviour is not defined anywhere I'm afraid. I've looked
into this before and my head started to hurt. I think I reached the
conclusion that it wasn't entirely clear whether <a href="#"> was even
*allowed* by the HTML 4.01 spec.

I found this:

G.4. Modifications from RFC 1808
RFC 1808 (Section 4) defined an empty URL reference (a reference
containing nothing aside from the fragment identifier) as being a
reference to the base URL. Unfortunately, that definition could be
interpreted, upon selection of such a reference, as a new retrieval
action on that resource. Since the normal intent of such references
is for the user agent to change its view of the current document to
the beginning of the specified fragment within that document, not to
make an additional request of the resource, a description of how to
correctly interpret an empty reference has been added in Section 4.

http://www.ietf.org/rfc/rfc2396.txt

4.2. Same-document References

A URI reference that does not contain a URI is a reference to the
current document. In other words, an empty URI reference within a
document is interpreted as a reference to the start of that document,
and a reference containing only a fragment identifier is a reference
to the identified fragment of that document.

I think I got the answer I was looking for. Thanks for your time.

DU

 

[rf]

The "correct" behaviour is not defined anywhere I'm afraid. I've looked
into this before and my head started to hurt. I think I reached the
conclusion that it wasn't entirely clear whether <a href="#"> was even
*allowed* by the HTML 4.01 spec.

My feeling is that it is an error condition. The spec talks about what to do
with a fragment identifier that is incorrect (perhaps misspelt) but not
about one that is simply missing.

<researches>

RFC1738 talks about fragment/anchor identifier but only that it might be
there (including the #).

RFC1808 mentions fragment identifier by pointing out that "a parser must be
able to recognise the fragment when it is present".

Aha, 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.

 

[Eric B. Bednarz]

I'm not sure what "parsing and rendering links" is supposed to mean; the
result of a retrieval action should be the start of the current document
instance.

The "correct" behaviour is not defined anywhere I'm afraid. I've looked
into this before and my head started to hurt. I think I reached the
conclusion that it wasn't entirely clear whether <a href="#"> was even
*allowed* by the HTML 4.01 spec.

The HTML 4.01 specification itself does not make any attempt to clarify
the details; the crosshatch is CDATA enough to be syntactically
*allowed*, and the prose--as well as the entity voodoo in the external
doctype declaration subset tries to suggest--restricts the value of the
HREF attribute to URIs.

The normative references of HTML 4.01 invoke RFC 2396. Clause 4.2 deals
with the behaviour of empty URI references.

As far as mystery meat purpose links are concerned, I would prefer

href="?"

though, it provides richer semantics by the means of aesthetics.

 

[DU]

DU wrote:



The "correct" behaviour is not defined anywhere I'm afraid. I've looked
into this before and my head started to hurt. I think I reached the
conclusion that it wasn't entirely clear whether <a href="#"> was even
*allowed* by the HTML 4.01 spec.

My feeling is that it is an error condition. The spec talks about what to do
with a fragment identifier that is incorrect (perhaps misspelt) but not
about one that is simply missing.

<researches>

RFC1738 talks about fragment/anchor identifier but only that it might be
there (including the #).

RFC1808 mentions fragment identifier by pointing out that "a parser must be
able to recognise the fragment when it is present".

Aha, 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.

I added your comment into a bugzilla bugfile:

http://bugzilla.mozilla.org/show_bug.cgi?id=248023

Thanks

DU