Snap to top of page if named anchor is within n% of the top

NEW
Unassigned

Status

()

Core
Layout
17 years ago
6 years ago

People

(Reporter: mikewrite, Unassigned)

Tracking

({testcase})

Trunk
Future
x86
Windows 2000
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
At one point I said Mozilla 0.8 when of course I meant 0.7  :-)

Comment 2

17 years ago
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
(Reporter)

Comment 3

17 years ago
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

17 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
(Reporter)

Comment 5

17 years ago
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

17 years ago
Reporter you got a testcase we can use?
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.
(Reporter)

Comment 8

17 years ago
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
(Reporter)

Comment 9

17 years ago
Typo, sorry:  in the first graf that should be "... if the anchor tag is 
outside the body tags ...", not "anchor page."

Comment 10

17 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 11

17 years ago
qa contact updated.
QA Contact: gerardok → bsharma

Comment 12

17 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

17 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

17 years ago
Pierre, can you please look at this and reassign if appropriate.
Assignee: karnaze → pierre
Target Milestone: mozilla0.8.1 → mozilla1.0
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

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

17 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

17 years ago
Hopefully, this'll work on any JS1.2-enabled browser : 
<a href="javascript:self.scrollTo(0,0);">top</a> 

Comment 20

17 years ago
Created attachment 35795 [details]
Testcase for bug 68434

Comment 21

17 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.
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

17 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

17 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

16 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 :)
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

16 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 26

15 years ago
retargeting
Target Milestone: mozilla1.0.1 → Future
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
Assignee: layout → nobody
QA Contact: ian → layout
You need to log in before you can comment on or make changes to this bug.