Open
Bug 68434
Opened 24 years ago
Updated 2 years ago
Snap to top of page if named anchor is within n% of the top
Categories
(Core :: Layout, defect)
Tracking
()
NEW
Future
People
(Reporter: mikewrite, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
599 bytes,
text/html
|
Details |
If I include either of the doctype identifier strings shown on the bugzilla template, thus inducing standards mode in release 0.7, a named-anchor tag pair for a "top" function does not work. Put <a href="#top">blah</a> at the bottom of the page. Put <a name="top"></a> at the top of the page. In standards mode, the "blah" link at the bottom is dead. Does not matter what combination of locations you choose for either tag: link at bottom within body, anchor at top within body; link within body, anchor between head and body; link within body, anchor within head; link outside ending body tag, anchor wherever ... I think I tried 'em all. Scenario for me as page designer: In NS4.76 (haven't tried earlier), the named anchor link will not snap the page completely to the top, no matter where you locate the anchor/link pair. It always snaps with a few pixels to go. The result is that a menu bar at the top of the page is obscured, forcing a manual scroll to finish getting to the very top and making the menu visible. This is also true in Opera5. IE5 and 6 _don't_ do this: the link snaps the page completely to the top. Fix was to omit the anchor tag and just use the <a name="#top">blah</a> tag at the bottom. Then in NS4.76 and Opera5, when you click the "blah" link the page snaps completely to the top. IE continues to do this as well. (Only works with "top" defined, <a href="#doh>blah</a> does nothing if there's no doh anchor tag.) But in Mozilla 0.8, if the named-anchor tag is omitted at the top, the link at the bottom is dead. That's true in quirks mode or, of course, in standards mode, where the link is dead no matter what. As expected, including the named anchor tag in quirks mode results in NS4 behavior: the page won't snap completely to the top, and the top menu bar is obscured. Best design compromise for me, for now, is to leave out the anchor tag at the top, because that gives me desired perf in the most browsers. Is this a bug in how Mozilla renders the standard? Did the standard for named anchor tags change and I'm clueless? Expected behavior: easiest way out would seem to have it behave as most browsers do when the anchor tag is missing for a #top link: default to snapping completely to the top. Optionally, make the page snap all the way up when an anchor _is_ included, like IE does. But then I'd have to get Opera to fix that, too :-). So the third option is to make it snap all the way up either way, anchor or no anchor, like IE does.
At one point I said Mozilla 0.8 when of course I meant 0.7 :-)
you said it in the summary too. Correcting it.
Summary: Named anchor tag navigation broken in standards mode, 0.7 → Named anchor tag navigation broken in standards mode, 0.8
Thanks. Just reproed dead anchor link in latest nightly build, ID:2001020904, except it's worse. Does this build not operate in quirks mode anymore? Cause it acts like 0.7 in standards mode - anchor link is dead regardless of including or omitting anchor tag, regardless of where anchor/link pair located - even if I _don't_ include the doctype string at the top of the page, which in 0.7 causes quirks mode.
Summary: Named anchor tag navigation broken in standards mode, 0.8 → Named anchor tag navigation broken in standards mode, 0.7
Comment 4•24 years ago
|
||
I remember discussing this before with other people and IIRC #top is not part of the w3c HTML4.01 recommendation (couldn't find any reference to it on the w3c site). However the bug would be that we don't scroll the page to the top when there is a named anchor at the top of the page. Updating summary to read 0.8 instead of 0.7.
Summary: Named anchor tag navigation broken in standards mode, 0.7 → Named anchor tag navigation broken in standards mode, 0.8
I wasn't sure if you meant that the standards specifically exclude only the use of #top as a named anchor, so I tried changing "top" to "doh" in both tags. Nothing, still dead link. So for me at least, in build 2001020904 named anchor tag navigation within a page is dead, period, whether the page has one of the doctype strings for w3c or not.
Comment 6•24 years ago
|
||
Reporter you got a testcase we can use?
Comment 7•24 years ago
|
||
Hmm, this basically works for me with a simple test case I made up. The only possible problem I see is that it looks like we go to the bottom of the top margin not the very top of the page. But I'm not sure that's a bug. I'm not seeing any dead links at all. Reporter if you can put together a test case that would be great.
OK, named anchor tags now work in my test pages in nightly build 2001021820, provided the anchor tag itself is placed within the body tags. (If the standards call for it to work if the anchor page is outside the body tags, say within the head tags or between the closing head and opening body tag, those cases still don't work.) This still leaves the problem of being unable to snap the page completely to the top, which ends up obscuring any menu bar at the top of the page. It may be expected behavior, but it's still not nice. This isn't the forum for it, I know, but I gotta say I don't understand why the standards don't include the simple and elegant #top function of snapping the page completely to the top when the top anchor tag is omitted. Also, if the behavior is to snap only as far as the bottom of the top margin, why does it do this when topmargin=0 is included in the body parameters? Is that unrecognized by the standards too? Or is it not relevant to what the browser sees as the actual top margin of a page? In case it's my clumsy HTML that's the problem, I made a test page from one of my site's live pages. It includes the anchor tag within the body tags, whereas my live pages omit the anchor tag so as to make use of the #top ability to snap the page completely to the top. Test page is http://mikewrite.home.mindspring.com/rant2.html
Typo, sorry: in the first graf that should be "... if the anchor tag is outside the body tags ...", not "anchor page."
Comment 10•24 years ago
|
||
Mozilla is doing the right thing in this page i believe. It is going to where top is defined. However in this case the javascript is defined to go above it but the HTML doesn't know anything about it so it thinks the Top is just below the Menu (since the menu is inserted dynamicly before the #top reference). So I believe that is what is happening. Does it occur in IE or any other browser or is it just Mozilla that has the problem linking to the top?
Comment 12•23 years ago
|
||
changing the component to 'Layout'.
Assignee: clayton → karnaze
Component: HTML Element → Layout
QA Contact: bsharma → petersen
Target Milestone: --- → mozilla0.8.1
Comment 13•23 years ago
|
||
marking NEW (it has a target milestone). Adding hixie to CC for the standards-compliance issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 14•23 years ago
|
||
Pierre, can you please look at this and reassign if appropriate.
Assignee: karnaze → pierre
Target Milestone: mozilla0.8.1 → mozilla1.0
Comment 15•23 years ago
|
||
I'm at a loss. Is the bug that we don't snap to the very top when a named anchor is somewhere _near_ the top?
Comment 16•23 years ago
|
||
basically yes, but the real problem is that there is no way to snap entirely to the top, unless you do some crazy absolute positioning. I think it's fair to request an easy way to go back to the top of a document
Comment 17•23 years ago
|
||
Well, there _is_ a way. "If after moving to a named anchor we have a scroll position that is less than n% of the height of the viewport away from the top of the root element, then scroll the viewport to the top of the root element." Is that what we want to make this bug be?
Comment 18•23 years ago
|
||
Tried on 0.8.1-20010323. This easy example won't work : <body> <a name="top"></a> <!-- the page --> <a href="#top">to the top</a> </body> Please accept this bug.
Comment 19•23 years ago
|
||
Hopefully, this'll work on any JS1.2-enabled browser : <a href="javascript:self.scrollTo(0,0);">top</a>
Comment 20•23 years ago
|
||
Comment 21•23 years ago
|
||
The problem is clearly that we scroll to the anchor, but this anchor is not exactly laid out at the top of the page. So there are 3 or 4 pixels left. I think Hixie's last suggestion is a good one. "If after moving to a named anchor we have a scroll position that is less than n% of the height of the viewport away from the top of the root element, then scroll the viewport to the top of the root element." Or second solution like the reporter suggested, when there is no <a name="top">, scroll to the top automatically.
Updated•23 years ago
|
Keywords: testcase
Summary: Named anchor tag navigation broken in standards mode, 0.8 → Scrolling to named anchor at top doesn't go all the way up
Comment 22•23 years ago
|
||
This bug shouldn't be on my list, my apologies for having overlooked it for so long. Reassigned to evaughan who might be a better owner.
Assignee: pierre → evaughan
Comment 23•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 24•22 years ago
|
||
Many browsers recognise <a href="#top">Top</a> with no anchor as an unconditional jump to the very top of the page. Something of the sort is essential to get above the top margin. Of course a link to the page's own url should do it but would slow navigation and make standardised "#top" links impossible. At: www.tony-foster.co.uk I have just accepted that anyone using Mozilla won't be able to use the top links at the foot of each page - putting a top anchor with a top margin is unsatisfactory in all browsers that I have tried, so I am not keen to do it just to make Mozilla work :)
Updated•22 years ago
|
Summary: Scrolling to named anchor at top doesn't go all the way up → Snap to top of page if named anchor is within n% of the top
Comment 25•22 years ago
|
||
I vote against "If after moving to a named anchor we have a scroll position that is less than n% of the height of the viewport away from the top of the root element, then scroll the viewport to the top of the root element." That would make Mozilla appear not to support named anchors and would confuse users who click on named anchors to near the top of the page.
Comment 27•21 years ago
|
||
Perhaps what we should do is that if the target rect is within less than a line-height of the top of the page we should snap to the top of the page. Thoughts?
Assignee: eric → other
QA Contact: chrispetersen → ian
Updated•15 years ago
|
Assignee: layout → nobody
QA Contact: ian → layout
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•