D
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
<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