Search Index anchors point a line too low

[zoffixznet]

For example, if you search for is-approx, the link will lead here; hiding the title of the section.

The same problem exists with glossary, when searching for, say, reify leads to this page, again, with the title of the section hidden.

I believe this is due to the X<> bits being below the title.

[AlexDaniel]

I believe this is due to the X<> bits being below the title.
Correct, but how can we possible resolve this? I hope there is a way, does anybody have any idea?

[zoffixznet]

Some suggestions:

• Put X<> above title
• Add JS to scroll up a bit
• Generate bare anchors in HTML a bit above where they actually are
• Fix the bug in HTML generator so that X<> can be placed into the titles instead of having to be below them

I think the last one is the most desirable, even if most complicated.

[zoffixznet]

Put X<> above title

Just tried that and it works well.

[AlexDaniel]

It feels semantically incorrect, but maybe I'm being too picky?

[zoffixznet]

It'd be better if it worked in titles, but lacking that, feels OK to me semantically and functionally.

[JJ]

Titles are a problem. If you index them, sometimes they are simply not indexed. See Raku/doc#1938

[MorayJ]

This appears to be fixed...or is it a work in progress?

[Altai-man]

@MorayJ
1)This is not fixed;
2)There is a complete re-design in progress, where this ticket is addressed, so probably not a lot of sense to spend time on it now.

[finanalyst]

I have just tried some of the above. I do not understand the issue being raised yet.

There are several issues:

• Some, but not all, headings are coded in the source as =head1 X<Some indexed heading>. This means that there is indexation in the glossary and in the table of contents. The combination of index and headings does cause complications.
• The X<> markup creates an anchor which must have a unique id, the =headx also creates an anchor. It is not clear yet how Pod::To::HTML` does this.
• Several source authors put empty X<> anchors into the text after the heading. This causes a glossary entry with a name like the heading. Hitting that anchor will put the heading above the window.
• Search input is generated from several sources, and it is not clear from the issue as stated here which of the search elements is being referenced, and hence which source is generating the anchor.
• There was a major change in the way Headings are rendered in the OgdenWebb template to resolve the issue of them being clickable when they have a =headx X<header> form.

@coke is it possible to make this issue clearer in order to be able to tackle it?

[Altai-man]

@finanalyst I'll try to clear it up.

This issue is already fixed. :)

In short, it was about anchors on the pages. For example, when you jump to this URL: https://new-raku.finanalyst.org/language/mop.html#WHERE the browser scrolls down so that the anchor of the WHERE header is at the top of the content of the browser window. HOWEVER. Because we have a fixed top header, in "broken" circumstances this ticket appears, the browser would ignore the header, and as a result after the jump the header would "cover" the header. However, CSS is already fixed so that it is not happening, thus closed.