feat(_table.scss): make table header sticky

[ALONUCLEAR]

Summary

No jira ticket for this issue as it's just a few lines of scss. I was just annoyed that the table headers weren't sticky so I made these exact changes in the inspector and saw it worked as I wanted. I even made a little extension to add these changes to the page through css injection without the pr, but I thought maybe other people would appreciate this as well.

Testing done

I didn't manage to run the project as is on my pc, so I wasn't able to run any tests on the changed version either, but I assumed because this is such a small change, a reviewer that already has the project succesfully running could maybe do it instead.
I'm sorry for the inconvenience, and I understand if it makes it even less likely for this pr to enter.

Proposed changelog entries

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[welcome]

Yay, your first pull request towards Jenkins core was created successfully! Thank you so much!

A contributor will provide feedback soon. Meanwhile, you can join the chats and community forums to connect with other Jenkins users, developers, and maintainers.

[MarkEWaite]

@ALONUCLEAR thanks for the pull request. Please provide "before" and "after" screenshots so that others can see the result of your change. I'm not clear where the change will be visible or how the change will be perceived by users.

[ALONUCLEAR]

@ALONUCLEAR thanks for the pull request. Please provide "before" and "after" screenshots so that others can see the result of your change. I'm not clear where the change will be visible or how the change will be perceived by users.

Sure, here they are. What I added is that stickiness at the top

[daniel-beck]

The idea seems sound and the justification makes sense to me, but this seems incomplete at least. For example, the plugin manager with its sticky placement of the filter input sticks the table header behind it, blurred. The dark smudge just above the "5 mo 20 days ago" label in the partially visible table row is the "Released" table header.

Not necessarily blocking if others are in favor, but at least a limitation to consider.

[MarkEWaite]

I agree with Daniel's observation that more changes are needed before this is ready to be merged. @daniel-beck said:

For example, the plugin manager with its sticky placement of the filter input sticks the table header behind it, blurred

I think that highlights a general case that needs to be reviewed on each page that has more than one thead tag. I am concerned that attaching stickiness to all thead tags will cause unexpected results on any page that has more than one thead on the page. It behaves reasonably as far as I can tell with pages like /computer/ and /manage/about/and/manage/systemInfo. Each of those locations have multiple thead` tags on the page.

About page (scrolled down)

Computers page (scrolled down)

System information page (scrolled down)

I think that the system information page might be easier to understand if the first thead on the page were sticky rather than the second. I believe that the navigation controls are in the first table.

I think it would be wise to check pages contributed by plugins, though I've not done that yet.

I'll need to test it in more contexts or see the results from others testing it in more contexts.

[mawinter69]

Testing this with the dashboard view plugin with an open PR from me (jenkinsci/dashboard-view-plugin#328).
With this change the tables header inside a dashboard gets misaligned and is not sticky

Without sticky header:

with sticky header:
you can see that the header is no longer vertically aligned in the middle

The header is not sticky at all

Maybe we should make that optional with e.g. jenkins-table--sticky-header

[MarkEWaite]

@ALONUCLEAR are you interested in making the changes that have been requested in this pull request?

If not, then I think it is best to close the pull request rather than leave it open without any further progress.

[MarkEWaite]

Closing after a week with no response from the original submitter. We can reopen or reuse the commits if someone else decides they would like to complete the implementation