Stylesheets - Overlapping divs, scrolling and fragment anchors

Author

Overlapping divs, scrolling and fragment anchors

Mark Tranchant

2004-07-29, 4:15 am

I'm looking for some advice here.

Using a browser that supports fixed positioning (not IE), take a look at:

http://tranchant.plus.com/guitar/chord-tutorial/

The page consists of a fixed header and menu, with scrolling content.
The content goes under the header - in Firefox/Mozilla, and allegedly
Safari, you can see this due to the slight transparency of the header.

I've assigned an appropriate (50px) margin-top to the content so that it
starts below the header when the page is loaded.

OK, now click on the "Chords on the guitar" link in the Contents list.
*If* you have Javascript enabled, your browser should do what you
expect, leaving the appropriate <h2> just below the header bar.

Now reload the page - and notice how the <h2> is at the top of the
viewport, underneath the header bar.

In the first case, some Javascript detects if you're clicking a fragment
link, jumps to it, and then scrolls up 55px to compensate.

Can anyone think of a better way to ensure that links to fragment
anchors, whether from the current page or a different one, are aligned
as I want? I'm after some sort of viewport-margin, but don't want to
resort to assigning a scrollbar to the content div separately.

--
Mark.
http://tranchant.plus.com/

Mark Tranchant

2004-07-29, 7:15 am

Mark Tranchant wrote:

> OK, now click on the "Chords on the guitar" link in the Contents list.
> *If* you have Javascript enabled, your browser should do what you
> expect, leaving the appropriate <h2> just below the header bar.

> ... some Javascript detects if you're clicking a fragment
> link, jumps to it, and then scrolls up 55px to compensate.

Follow-up - this doesn't appear to work in Opera.

--
Mark.

Spartanicus

2004-07-29, 12:15 pm

Mark Tranchant <mark@tranchant.plus.com> wrote:

>In the first case, some Javascript detects if you're clicking a fragment
>link, jumps to it, and then scrolls up 55px to compensate.

Ouch, ugly. I once constructed a solution for this problem, from memory:

a[id]{padding-top:55px}

<h2><a id="foobar"></a>Header</h2>

It's been a while since I used it, play with the idea a bit if it
doesn't work immediately.

--
Spartanicus

Christoph Paeper

2004-07-29, 12:15 pm

*Spartanicus* <me@privacy.net>:
> Mark Tranchant <mark@tranchant.plus.com> wrote:
>
>
> a[id]{padding-top:55px}

:target {padding-top: 55px}

Of course that is a CSS3 selector and thus hardly supported yet. On that
site I don't see the reason for that fixed header anyway: most browsers,
that support fixed positioning, do support the 'rel' and 'rev' attributes
of the 'link' element, some even for the 'a' element.

> <h2><a id="foobar"></a>Header</h2>

<h2><a name="foobar"></a>Header</h2>

or rather

<h2><a name="foobar">Header</a></h2>

make sense as does

<h2 id="foobar">Header</h2>

but your code doesn't. Browsers (like NS4) that don't support a target
link to an 'id' in an 'h2' don't support it for 'a' either.

--
"You can only find truth with logic
if you have already found truth without it."
G.K. Chesterton

Spartanicus

2004-07-29, 12:15 pm

Christoph Paeper <christoph.paeper@nurfuerspam.de> wrote:

>
> :target {padding-top: 55px}
>
>Of course that is a CSS3 selector and thus hardly supported yet.

Why mention it then?

>
> <h2><a name="foobar"></a>Header</h2>
>
>or rather
>
> <h2><a name="foobar">Header</a></h2>
>
>make sense as does
>
> <h2 id="foobar">Header</h2>
>
>but your code doesn't.

A deliberate construct. The reason is that although the padding does not
affect the positioning of adjacent boxes in the vertical stack, the
padded area still exists and since it's higher in the z-index stack it
can obscure content, for example if there's a link located under that
padded area it becomes unclickable.

Demo of this effect that uses the more logical <h2><a
id="foobar">Header</a></h2> construct:
http://www.pan-europe.utvinternet.i...htm#stop_switch
(use a proper browser to see the phenomena)

Scroll down the page a bit, hover over the "RIGHT HANDLEBAR CONTROLS"
link to see the effect.

>Browsers (like NS4) that don't support a target
>link to an 'id' in an 'h2' don't support it for 'a' either.

It's up to the OP if he wants to dumb down his code to support fragment
identifiers that are compatible with NS4. I've stopped doing so some
time ago, I'm sure many have done likewise.

--
Spartanicus