Closed Bug 80784 Opened 19 years ago Closed 19 years ago

WRMB: #top named anchor doesn't work of no <a name="top"> present


(Core :: Layout, defect)

Not set





(Reporter: mkaply, Assigned: kmcclusk)




(Keywords: top100, topembed, Whiteboard: [EDT+][PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk and 094 branch)


(2 files, 1 obsolete file)

Although I can't find it in spec, it appears that IE and NS 4.x had a default 
named anchor of #top that would always take you to the top of the page:

<A href="#top>Go to the top of the page</A>

This doesn't work in Mozilla (0.6 or current builds).
I'm not sure if it ever worked along the way.

Scroll to the bottom of the testcase and click on the last link.
actually, IE and NS4.x will scroll to top for _any_ unknown anchor.  try <a
href="#foo"> if you like.

We just ignore the anchor if it's not in the document -- this seems like better

See also bug 80346.
Summary: #top named anchor doesn't work → #top named anchor doesn't work of no <a name="top"> present
Actually, only NS 4.x scrolls on any anchor.

IE only scrolls to the top on #top.

80346 was marked invalid, but I'm not sure that this is the right answer. Do we 
know if this behavior is documented anywhere?
*** Bug 86074 has been marked as a duplicate of this bug. ***
Since RFC 2396 disclaims the fragment identifier as part of the URI, I would 
suggest that the handling of such a URI be theoretically treated in two steps:
1) Load base URI (URI of current document), action uniform to all URIs.
2) Handle fragment identifier within context of loaded document (an action well-
defined for HTML documents).

Based on this model, I would suggest that the behavior of links with href=
"(current document)", href="(current document)#nonexistant anchor", href=
"#nonexistant anchor", and (as a bonus) href="" all be treated in the same 
manner. [From RFC 2396: "If the path component is empty and the scheme, 
authority, and query components are undefined, then it is a reference to the 
current document and we are done."  That is to say, an anchor with href="" points 
to a relative URI which expands into the absolute URI of the current document.]

I tend to feel that this behavior should be as in NS 4.x, i.e., the position 
within the document returns to the default at the top when clicking the link, and 
remains there because the fragment identifier is meaningless.

CCing dbaron, for more informed commentary and better logic.

this seems a duplicate of 68434 (dont know if pointing out
duplicates is an appropriate thing for me - end user - to

See bug 93077, where this issue has been closed as INVALID.  This bug should 
probably get the same, since there's a very simple workaround.
Didn't NN4 make any named anchor it couldn't find go to the top of the page? 
(i.e., is "top" not special?)  Does IE do the same thing?
If a company has deployed 10,000 web pages that rely on this behavior, there is 
no such thing as a "simple workaround"

I'm marking this 4xp.
Keywords: 4xp
At least in Netscape 4 the page won't scroll to the top of the page like it
would do by using the scrollbar IF AN ANCHOR IS DEFINED. If the page has an
standard margin of, say, 5 pixels, the document will actually be scrolled down
by 5 pixels after you clicked the link to #top. To be able to go to the absolute
top, 0 pixels, you have to use an undefined anchor, JavaScript, or no margin
which influences the rest of the page as well. Therefore Mozilla should behave
like NS 4 and IE do: scroll up as far as it can.
Looking at the HTML spec, specifically section 12 it states:

12.2.4 Unavailable and unidentifiable resources

A reference to an unavailable or unidentifiable resource is an error. Although 
user agents may vary in how they handle such an error, we recommend the 
following behavior:

* If a user agent cannot locate a linked resource, it should alert the user. 
* If a user agent cannot identify the type of a linked resource, it should still 
attempt to process it. It should alert the user and may allow the user to 
intervene and identify the document type. 

I do not see where it states that the user agent should default to the top. 
Where is that stated in the spec? It seems that this bug should be marked as 
invalid in regard to the information in the above section.
Summary: #top named anchor doesn't work of no <a name="top"> present → WRMB: #top named anchor doesn't work of no <a name="top"> present
Whiteboard: [bugscape: 7514]
Changed Bugscape bug to metabug 10365.
Whiteboard: [bugscape: 7514] → [bugscape: 10365]
For some reason there are HTML developers who have counted on not needing to
include <a name="top"> -- perhaps because IE, N4.x, and even Opera 5 take the
user to the top of the page when <a name="top"> is not present. While this isn't
a WC3 standard it seems to be a non-standard standard. 

So my suggestion is that when in quirks mode if there is no target for an anchor
link that the Netscape 4.x behavior take effect. 

This will prevent user inconvenience and resulting calls to website customer
support reporting these broken links. 
Another example:
Keywords: topembed
Kevin, Marc and I aren't sure who to reassign this to.
Assignee: karnaze → kmcclusk
Why only quirks mode?  We should only diverge when a standard clearly says that
we can't do what we want to do in quirks mode, and I don't know of anything that
says that.
What do you mean David? Are you suggesting that we have the same behavior in 
strict mode as well?

I discussed this with WG members and the response to this "problem" was this:
1. strictly following the spec, we should display a 404 error message
2. a moderate approach would be to silently fail
3. the wrong approach would be to do what is requested for this bug

I would be against allowing #3 in strict mode
What part of the HTML spec overrides what choess says about RFC 2396 above?  The
RFC should be authoritative on how to interpret URLs, unless the HTML spec says
something specific about how to handle undefined fragments within HTML documents.
Yes, section 12 discusses this, please see my previous comment
Section 12 is quite large, and I didn't see anything in it supporting that comment.
CC'ing sarri, joki since scrolling to a named anchor is done by changing focus
to frame with the named anchor. 
Actually, in looking at section 12, this says top to me:

* If a user agent cannot identify the type of a linked resource, it should still 
attempt to process it. 

So we cannot identify the anchor, but we know what they meant so we attempt to 
process it by going to #top.

This is a classic case of "undefined" Is there somewhere in a spec that says 
#top should not go to the top? Is there somewhere in a spec that says #top 
should go to the top?

Sometimes we just have to bite the bullet and accept that something has become a 
defacto standard.

Otherwise people will just interpret our browser as broke.
this is a response from the W3C:

There is a good W3C Note that all UA implementors should read, Common User Agent 
Problems. In point 1.2, "If the user attempts to follow a link that is broken 
because it designates a missing anchor, let the user know it is broken." 
<> says:

    Wrong: Some user agents scroll to the top or bottom of the
    document when the user attempts to follow a broken link. This behavior
    is discouraged since it is indistinguishable from the correct behavior
    when a target is at the beginning or end of a document.

Recommendation: mark this bug as invalid or won't fix
Target Milestone: --- → mozilla0.9.6
OK, let's not call #top a broken link then.

Let's call #top an internal anchor.
which is pointing to an invalid named anchor, which makes it a broken link
Is it really difficult simply to do the scrolling if the link is named "#top"? I
created several pages and i thought it would something like "_new" in the
target... some browser-internal thing. As EVERY Browser except Mozilla DOES a
scrolling to the top... 
 You're right: Really it IS a broken link. But you know where it should go. And
if thousands of pages need to be redesigned because of a behavior exact to the
letter of W3C... many really don't like to use it then, i think.
So, for this new undocumented feature request (bug), should we also read the 
intent of the author if they have an href value of href="#bottom"? Should we 
know that the authro meant to go to the top if they coded href="#to_top"? Or is 
the expectation that we only do this for #top? How would someone know that only 
#top has this super special deal and not others?

Standards compliance is the goal here by the way.
Well if standards compliance is the goal, then put it in 
quirks mode as was mentioned earlier.

And as far as what to do - the answer is #top takes you to 
the top. That seems to cover the majority of pages.

I understand the standards compliance tradeoff very well. 
But the most standards compliant browser in the world is 
pretty danged useless if it can't view existing web pages.
Do me a favour:

1. visit
2. View both files (top-defined.html and top-not-defined.html) with IE, Netscape
4 or Opera.
3. Scroll down to the bottom and click the #top link.

top-defined.html: <A name="top"></A> right after <BODY>
top-not-defined.html: No anchor named "top"

In top-defined.html, you will see the document starting right at the beginning
of the blue box, but the box is some pixels away from the top of the document -
where I intended the link to go to (test it: you can still scroll up after
clicking the link!).
In top-not-defined.html, the 3 mentioned browsers will do what I wanted to
achieve: they go to the beginning of the document, like they do if the document
is opened without an anchor defined. There is no way to achieve this with an
anchor defined, unless you use JavaScript to go up (in which case the anchor
would be useless) or set the top margin of the page to 0px, which requires
different approaches for different browsers, if it works at all.
So simply not defining the anchor is an easy way that worked with every browser
so far. Okay, I could also make an href="" or href="top-defined.html" to
effectively go to the top but this requires the page to be loaded from the
server again and is therefore not an acceptable alternative to a simple scroll.

Mozilla would require pages to be modified in order to make top-links possible
because Mozilla also scrolls to the beginning of the box and not to the
beginning of the document (see top-defined.html).

So please: let Mozilla do what all browsers do - consider an undefined anchor as
a link to the top. The top of the document and not of its first element. This is
even better than the current behaviour of Mozilla (do nothing) since the user
gets a feedback that Mozilla has handled the click.

I mentioned this above as well, I hope it got clearer now.
Actually, the not scrolling to top is bugzilla bug 68434
whiteboard garbage
Whiteboard: [bugscape: 10365] → [quirks][bugscape: 10365][beppe:101201]
I think this bug belongs to joki. Looking at the ScrollTo code it is fired on
the EventStateManager by changing of focus. I'm not sure where the actual code
which locates the frame to scrollTo is found.

Tom: If you don't own this area go ahead and reassign back to me.
Assignee: kmcclusk → joki
Taking bug back, Tom is on vacation.
Assignee: joki → kmcclusk
Whiteboard: [quirks][bugscape: 10365][beppe:101201] → [quirks][bugscape: 10365][beppe:101201] Fix in hand waiting for r/sr
Comment on attachment 53814 [details] [diff] [review]
Scroll window to top/left if an anchor can not be found (Quirks mode only)

Attachment #53814 - Flags: superreview+
Comment on attachment 53814 [details] [diff] [review]
Scroll window to top/left if an anchor can not be found (Quirks mode only)

Not a requirement, but why not just set rv to the return val of
ScrollTo() to catch any errors it might throw?

+        rv = scrollingView->ScrollTo(0, 0, NS_VMREFRESH_IMMEDIATE);
Attachment #53814 - Flags: review+
Whiteboard: [quirks][bugscape: 10365][beppe:101201] Fix in hand waiting for r/sr → [quirks][bugscape: 10365][beppe:101201] Read to check in
Marking nsbranch+
Keywords: nsbranch+
Checked patch (53814) into the trunk.  Mozilla now behaves the same as 4.x in
quirks mode.
Whiteboard: [quirks][bugscape: 10365][beppe:101201] Read to check in → [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk
PDT: This small fix is isolated to clicking on a link to a named anchor that
doesn't exist. Previous behavior was to do nothing, new behavior is compatible
with 4.x which is to scrollto the upper left corner. 
Comment on attachment 53901 [details] [diff] [review]
scroll to the top/left only if  the anchor name is top

sr=attinasi (though I personally prefer the Nav approach...)
Attachment #53901 - Flags: superreview+
I prefer the Nav compatibility personally. The IE method essentially makes the
use of a named anchor #top at a location other than the top dubious. Why do you
want to do the IE version and not the Nav version? It seems that the Nav version
will cover the same sites as the IE version, and has the added benefit of not
making '#top' a special name (it just scrolls to the top for all nonexistant

Either way, sr=attinasi
Comment on attachment 53901 [details] [diff] [review]
scroll to the top/left only if  the anchor name is top

The patch looks fine to me, though I kind of agree with Marc.

Are we sure that we aren't going to break any important sites that rely
on the 4.x behavior?
Attachment #53901 - Flags: review+
We discussed this issue in the W3C HTML WG teleconference today. I wanted to 
convey to you via the bug what the W3C HTML WG had to say about this:
1. regardless as to what we do, the history stack should not be corrupted with 
the resulting jump to the top

2. treating #top as an exception, if necessary, is at least tolerable as long as 
other unknown links are not treated the same. It can easily be inferred that 
#top was meant, by the author, to go to the top. But other invlaid named anchor 
links should not be interpreted the same way. The UA should not interpret the 
authors intent with other named anchor links. The UA response on other #whatever 
links should be to either silently ignore, or provide user feedback that lets 
them know the named anchor can not be found.
If #top is easily inferred to mean the top of the document, then why not support
#bottom too? What I dislike most about the argument (that 'top' can be infered
to mean the top of the document) is that it does not address the fact that an
author may actually choose to put a valid named anchor called 'top' anywhere,
and so 'top' becomes somewhat ambiguous - sometimes it means jump to the top of
the page, sometimes it means jump to some other location where the anchor is.

Also, what is the reason for NOT putting the jump in the history? If we jump to
the top, then to another location, shouldn't back return us to the top? I don't
understand the value in keeping that out of the history.

Anyway, thanks for the WG clarification Beth.
The discussion was that the link was invalid, therefore it should not be added 
to the stack. Like any other invalid link, this particular link should not alter 
the history stack. The choice to honor the invalid link instead of ignoring it 
is an implementation decision and not a recommendation. 
I'm confused. we put 404 urls into history, don't we? -- we do in 0.9.5
> If #top is easily inferred to mean the top of the document, then why not support
> #bottom too? 

Because no-one is using #bottom on the web without setting <a name="bottom>. 

Like many of our quirks, this is a quirk to work around a common, yet incorrect,
authoring practice on the web, while following the standards as much as
possible. kmcclusk's latest patch does exactly that.

We should, however, document this behaviour in the same place that we document
all our other quirks so that web authors know about them. We do do that, right?

Oh - if it's not too late, can we use EqualsIgnoreCase, if there is such a
method? Kat Momoi was telling me that MSFT have a related problem - they have <a
href="#TOP"> at the bottom and <a name="top> at the top of the document, and our
current anchor code is case-sensitive.


Attachment #53901 - Attachment is obsolete: true
Comment on attachment 54220 [details] [diff] [review]
Ignore case when comparing "top"

Attachment #54220 - Flags: superreview+
PDT- For this week, but it can be picked up for embedding next week if they'd like.
Whiteboard: [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk → [PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk
r=rods (looks good)
checked patch 54220 into trunk

Blocks: 107066
adding EDT+ (first usage of it :-)). please proceed w/ 0.9.4 branch checkin.
Whiteboard: [PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk → [EDT+][PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk
Checked into 094 branch.
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [EDT+][PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk → [EDT+][PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk and 094 branch
Just wanted to say THANKS for getting this done. It has fixed anchors on as well. :-) Works for me! (build 2001112003)
You need to log in before you can comment on or make changes to this bug.