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

Status: NEW

(Core :: Layout, defect)

Description

[mikewrite]

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.

Comment 1

[mikewrite]

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

Comment 2

[R.K.Aa.]

you said it in the summary too. Correcting it.

Comment 3

[mikewrite]

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.

Comment 4

[Fabian Guisset]

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.

Comment 5

[mikewrite]

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

[Keyser Sose]

Reporter you got a testcase we can use?

Comment 7

[Brian Haskin (Janzert)]

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.

Comment 8

[mikewrite]

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

Comment 9

[mikewrite]

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

Comment 10

[Keyser Sose]

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

[bsharma]

qa contact updated.

Comment 12

[bsharma]

changing the component to 'Layout'.

Comment 13

[Fabian Guisset]

marking NEW (it has a target milestone). Adding hixie to CC for the
standards-compliance issue.

Comment 14

[karnaze (gone)]

Pierre, can you please look at this and reassign if appropriate.

Comment 15

[Hixie (not reading bugmail)]

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

[Fabian Guisset]

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

[Hixie (not reading bugmail)]

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

[Martin Jacobs]

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

[Martin Jacobs]

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

Comment 20

[Fabian Guisset]

Attachment: Testcase for bug 68434

Comment 21

[Fabian Guisset]

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.

Comment 22

[Pierre Saslawsky]

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.

Comment 23

[Asa Dotzler [:asa]]

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)

Comment 24

[Douglas Steven]

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

Comment 25

[Jesse Ruderman]

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

[Vedran Miletic]

retargeting

Comment 27

[Boris Zbarsky [:bzbarsky]]

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?