Closed Bug 80784 Opened 19 years ago Closed 19 years ago
WRMB: #top named anchor doesn't work of no <a name="top"> present
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 behavior.... 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 do).
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.
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: http://people.aol.com/people/index.html
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." <http://www.w3.org/TR/cuap#usability> 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
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.
Actually, the not scrolling to top is bugzilla bug 68434
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
some sites with nonfunctional "back to top" links: which are fixed by patch 53814 http://www.barnesandnoble.com http://www.aa.com http://www.chipsbits.com http:/www.christianitytoday.com (home page) http://www.realtor.com http://www.nba.com http://www.thestreet.com http://www.lucent.com http://www.campuspipeline.com http://www.mitre.org/
Comment on attachment 53814 [details] [diff] [review] Scroll window to top/left if an anchor can not be found (Quirks mode only) sr=attinasi
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) firstname.lastname@example.org 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
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 anchors). Either way, sr=attinasi
Comment on attachment 53901 [details] [diff] [review] scroll to the top/left only if the anchor name is top email@example.com 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. Gerv
Attachment #53901 - Attachment is obsolete: true
Comment on attachment 54220 [details] [diff] [review] Ignore case when comparing "top" firstname.lastname@example.org
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
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.
Status: ASSIGNED → RESOLVED
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 Fidelity.com as well. :-) Works for me! (build 2001112003)
You need to log in before you can comment on or make changes to this bug.