How do I get Headings not to scroll properly?

[ktbCA57]

I tried using the "fixed" position in the style settings.. which works.. sort of. What happens is two things:

1) any text i have under those headings, slides up behind the heading so the heading overlaps the text
2) the heading stays and the text under it scrolls behind and above it.

see image attached.

[LTinker68]

It's doing exactly what you told it to do -- it's keeping the heading in the fixed position.

There are two things you need to do. First, you need to add the fixed property to the div containing the breadcrumbs so that the scrolled text doesn't go above it either. I can't remember if Flare exposes that DIV in the stylesheet or if you have to manually add it.

Second, you need to modify your heading style to have 0 top margin. Instead, set a padding-top value equal to what your margin-top value had been set to. Likewise, change margin-left and margin-right to 0 and set the same amounts in padding-left and padding-right. What that does is expand the "box" for the heading to the edge of the page and to just under the breadcrumbs (make sure there isn't a margin-bottom set on the breadcrumb DIV, too). The padding will take care of positioning your text within that "box". If you don't make those changes, there will be a very small gap between your heading and the breadcrumb div where the scrolling text will appear. So you need to position the heading "box" to be flush to the bottom of the breadcrumb div so that nothing can appear in that gap.

BTW, you may also need to do the same trick with the margins and padding on the breadcrumbs div. I can't remember if Flare has it already set to 0 margins or not. If you see scrolling text appear to the side or above the breadcrumbs proxy, then make that change. And you may want to add a white background color to the breadcrumb div. I'm assuming you don't have a background color applied to it now.

[ktbCA57]

HI LISA.. PER USUAL... YOU ROCK...

Everything you said makes sense to me... and i'm going to try it all out tomorrow when i get into work..

THANK YOU THANK YOU!

[NorthEast]

I'm not really sure how that would work - surely it would just mean the heading and breadcrumbs would obscure the top few lines of each topic?
You're not doing anything to stop text scrolling behind the fixed areas.

I'm sure someone posted something on the forums here about how to make a non-scrolling heading, but I've had a good look and unfortunately I can't find it.

[Andrew]

I'm not really sure how that would work - surely it would just mean the heading and breadcrumbs would obscure the top few lines of each topic?
You're not doing anything to stop text scrolling behind the fixed areas.

I'm sure someone posted something on the forums here about how to make a non-scrolling heading, but I've had a good look and unfortunately I can't find it.

I think you're right. (Also, I think the "purge" feature of the forums ate a lot of older posts.)

If you search google, you'll find that non-scrolling headers (like we used to have in the old WinHelp) are not a simple matter of pure CSS. They usually require either JavaScript or a table to work in IE6.

[LTinker68]

I'm not really sure how that would work - surely it would just mean the heading and breadcrumbs would obscure the top few lines of each topic?
You're not doing anything to stop text scrolling behind the fixed areas.

I think that's the point. It's basically mimicking a frameset where there's a thin top frame above the content. I'm hoping it's thin anyway -- if it eats too much of the screen real estate it'll just annoying the users if they have to scroll a lot to read the content. Don't forget that the toolbar, if you're including it, is also fixed (that is in a frame), so you're already losing some real estate. It may be cool to "lock" the breadcrumbs and header in place, but you might be better to not do that and instead add a bunch of "TOP" links throughout the content so users can jump back to the top of the topic, if that's what you're worried about.

[NorthEast]

I'm not really sure how that would work - surely it would just mean the heading and breadcrumbs would obscure the top few lines of each topic?
You're not doing anything to stop text scrolling behind the fixed areas.

I think that's the point. It's basically mimicking a frameset where there's a thin top frame above the content. I'm hoping it's thin anyway -- if it eats too much of the screen real estate it'll just annoying the users if they have to scroll a lot to read the content. Don't forget that the toolbar, if you're including it, is also fixed (that is in a frame), so you're already losing some real estate. It may be cool to "lock" the breadcrumbs and header in place, but you might be better to not do that and instead add a bunch of "TOP" links throughout the content so users can jump back to the top of the topic, if that's what you're worried about.

No, my point was that using that position property will obscure the topic text, as it is positioned on a layer above the body text.
If you look at the screenshots you'll see this happening, the heading is on top of the body text; so by having a fixed area at the top will mean you basically can't read the first few lines of any topic.

[LTinker68]

Oops, totally missed that. Yes, if he wants to lock the heading in place his topics should have some blank paragraphs before the topic content so that the text starts below the heading, not behind it.

Test printing from that page, too. I can't remember if a fixed DIV throws extra spacing after the DIV, in which case you might want to play with the styles in the print medium to correct for that.

[i-tietz]

Oops, totally missed that. Yes, if he wants to lock the heading in place his topics should have some blank paragraphs before the topic content so that the text starts below the heading, not behind it.

No - sorry Lisa, that's wrong.
Found a way that works:
1. Put the heading and the breadcrumbs into one div ("headerdiv")
2. put the rest into another div ("contentdiv").
3. place the contentdiv beneath the headerdiv.
Problem: What, if the header is longer than one line? Have scrollbars in the header div?
solution for the problem:
4. have a javascript inserted (onload, onresize) that finds out how high the headerdiv is and then change the position of the contentdiv accordingly.

Other alternative: leave out the contentdiv and change the paddingtop of the body according to he height of the headerdiv.

All that needs to be done in the masterpage of course.

[LTinker68]

1. Put the heading and the breadcrumbs into one div ("headerdiv")...
All that needs to be done in the masterpage of course.

Yeah, that could work. He'd have to use a heading variable in the masterpage that pulls the heading from the topic, and since he wouldn't want the heading to be repeated in the topic itself, he'd have to set the heading style in the topic to not display. And do the same in the page layout for print output (i.e., put the heading variable on the First page above the body frame).

[i-tietz]

1. Put the heading and the breadcrumbs into one div ("headerdiv")...
All that needs to be done in the masterpage of course.

Yeah, that could work. He'd have to use a heading variable in the masterpage that pulls the heading from the topic, and since he wouldn't want the heading to be repeated in the topic itself, he'd have to set the heading style in the topic to not display. And do the same in the page layout for print output (i.e., put the heading variable on the First page above the body frame).

ahem ... no ... in my project it looks like this:

masterpage.png

You can add the breadcrumb proxy right behind the topic toolbar proxy, inside the div.

topic.png

As you see I also added a table.

preview.png

[DurtyMat]

What are you trying to keep in your header that you need to have it displayed all the time? (just curious, always interested in why people do different things in help systems )

[i-tietz]

1. the header
2. the links (inside the table)
3. the toolbar

In that project we will have all sorts of information:
a. CSH topics to explain available fields and commands
b. topics to explain mechanisms and principles (they can be VERY long)
c. topics with step-by-step procs to perform specific tasks
d. topics that tie other topics together - like relays
We don't know what sort of info the user is looking for when opening the help. So: Offering the wanted help without clobbering the user over the head with sth like 80 links in the same topic is difficult. We group those infos and give only one link to a relay topic for each sort. Those links go into the table.
Don't get me wrong: We also have a TOC and an index but users often don't use them. Some go in via CSH (i.e. F1), some open topics via the TOC, some via the index some via the search ... all those ways should give the user a chance to retrieve the wanted information.

We also have very long topics and that's why we work with bookmarks/anchors that often we jump to directly (TOC, index, links, CSH calls). But we also want the user to know what topic he is in so he has a chance to find out if he's in the right place to find what he's looking for. That's why we keep the header in sight permanently.

We also work with dropdowns a lot. That's what we mainly need the toolbar for.

[Andrew]

What are you trying to keep in your header that you need to have it displayed all the time? (just curious, always interested in why people do different things in help systems )

To me, it's a simple thing: if there is significant scrolling (or, really, any scrolling) in a topic, I want the user to always know what topic he / she is in at a glance. This is especially important when users are browsing around, skimming everything, trying to find that bit of info they need. The drawback is that it reduces the viewport for the actual content, but our topic titles are quite small, so that wouldn't be a big issue for us.