Improve visibility of element navigation by moving it above content

[Arpan200502]

Description #6759

This change improves the visibility of the element navigation bar in the sidebar.

Previously, the navigation (Node / History / Versions) appeared after the element content (tags, changeset details, etc.), which meant users often had to scroll to access it when elements had many tags.

This PR moves the navigation <nav> block directly below the sidebar header and applies Bootstrap utility classes to keep it visible while scrolling.

Changes made:

• Reordered the HTML layout so the navigation appears above the element content.
• Added Bootstrap utility classes (sticky-top, bg-body, border-bottom, pb-2, z-1) so the navigation remains visible while scrolling.

Files modified:

• app/views/elements/show.html.erb
• app/views/old_elements/index.html.erb
• app/views/old_elements/_actions.html.erb

This improves usability when browsing elements with long tag lists or version histories.

How has this been tested?

Tested locally using the development environment with Docker.

Steps:

1. Started the Rails server locally.
2. Created a test node in the Rails console.
3. Added many tags to the node to create a long scrollable sidebar.
4. Verified that the navigation bar now appears directly below the element title and remains visible while scrolling.

Test pages checked:

• /node/:id
• /node/:id/history
• /node/:id/:version

[pablobm]

Thank you, I think this is showing promise. A few comments:

• On small screens, the sticky nav can obscure the content. This should be responsive.
• The bottom padding of the navigation is a bit awkward. There's a bit too much padding, then the panel content starts right after the border, with no breathing space. I think there should be top padding on the scrollable panel, and less bottom padding above the border. I'm open to other options.

• What's the z-1 class for? Perhaps it makes sense, but I don't know what it is. I have been playing with it and can't find a difference with/without.
• The changes should also apply to the "version show" pages. Click on "History", then click on an individual version number (eg: Version #3) to see it. Template should be app/views/old_elements/show.html.erb.

Then there's this part of the original issue:

The navigation bar repeats some of the information already present in the headings. Maybe we could consolidate this information.

But that can be done in a separate PR instead of here.

Finally, remember to present a clean commit history. From CONTRIBUTING.md:

Please ensure your commit history is clean and avoid including "fixup" commits. If you have added a fixup commit (for example to fix a rubocop warning, or because you changed your own new code) please combine the fixup commit into the commit that introduced the problem. git rebase -i is very useful for this.

[Arpan200502]

@pablobm

Update

Rebased the branch on the latest master and cleaned up the commit history.

While resolving earlier conflicts and CI issues, an incorrect reset accidentally introduced unrelated upstream changes into the branch. The branch has now been reset to the intended commit and force-pushed so the PR only contains the relevant modifications.

Changes in this PR

• Move the element navigation <nav> block above the element content in the sidebar.
• Apply Bootstrap utility classes (sticky-top, bg-body, border-bottom, pb-2, z-1) so the navigation remains visible while scrolling.
• Apply the same layout adjustment to the corresponding history/version views to keep behavior consistent.
• Minor ERB lint cleanup (trailing newline).

Result

• Navigation is visible immediately below the sidebar header.
• Navigation remains accessible when scrolling long tag lists or version histories.
• Commit history is now a single clean commit rebased on the latest master.
• All checks are passing.

[pablobm]

I'm not sure you addressed any of my comments? For one, the scroll is still not responsive:

[Arpan200502]

I'm not sure you addressed any of my comments? For one, the scroll is still not responsive:

Thanks for the feedback — that helps a lot.

I’ve moved the navigation into a sticky wrapper and adjusted the spacing and responsive behavior as suggested. However, I want to make sure I’m addressing the scroll issue correctly.

Could you clarify which part is currently affecting the scroll responsiveness? For example, is the sticky navigation overlapping the content, or is it related to the sidebar scroll container itself?

If you have a specific scenario (screen size or page interaction) where the problem is visible, that would help me reproduce it locally and adjust the layout properly.

[pablobm]

It's the sticky navigation. To be clear: I don't mean that the scroll itself is unresponsive (eg: there's a lag or something). I mean that the sticky navigation is not responsive in the sense that it doesn't adapt well do different screen sizes. I see how my latest comment wasn't very clear in that point.

For example:

1. Select an element with a few versions of history.
2. On the navigation, click "History".
3. Scroll down (on a small screen).

The sticky navigation will not leave much room for the scrollable content.