CSS Trimming and Minification

[lhardt]

tl;dr

• Removed unused classes from application.css
• Created and adopted a minified version of application.css (101650 bytes , compared to the original's 235830 bytes, a ~56% reduction).
• Raised questions about OSS attribution

longer version

This PR is intended to expand on #1414 , by minifying the CSS file. Instead of minifying the CSS file directly, I preserved the original one, and created an application.min.css file. For the record, I used this minification tool.

Inspecting a little further, It also seems to me that the application.css file composed of:

• an old version of normalize.css,
• what appears to be bootstrap v2 or v3,
• many rules imported from pivotal-one-styles;
• some custom rules implemented "by hand" to satisfy business needs.

It is essentially overkill, accumulated from another project, when this login-server commit stripped away Sass from the build process and merged all CSS files into what today is application.css. Finally, it ended up here after the contents of login-served were merged into this repo.

The lack of attribution when squashing all Sass might be concerning, and is a possible license violation of the abovementioned CSS libraries. I removed a sizeable part of the "bootstrappy" code that appeared to be unused, as well as gravatar related classes, which could mitigate library risk.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: lhardt / name: lhardt (38fcf69, 3f7a239, 67e3c07, 7aa725f, a13b42b, ab024ec, afd09ff, c2a1a5c)

[lhardt]

I'm not sure here if I understand this line's usage correctly.

If the host provides external branding and provides their on assetBaseUrl, do we expect all the /resources/oss contents to be present there or do we expect the host to provide their own custom application.css?

A remote possibility is, if the host created their own application.css (but not a minified version) this would ensure the css file is not found.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The minified stylesheet changes the unicode-range descriptors in the @font-face rules from U+0000-00FF (in application.css) to U+??. If U+?? is not valid per the CSS Fonts spec in some browsers, the entire unicode-range (or @font-face) may be ignored, potentially impacting font loading/rendering. It would be safer to preserve the original unicode-range values during minification (or validate the output across browsers).

[Copilot]

application.min.css is now a committed build artifact, but there doesn’t appear to be a repository build step/task that regenerates it from application.css. This can easily drift over time (people edit application.css and forget to re-minify), leading to confusing UI regressions. Consider adding a Gradle task (or documented script) that deterministically generates application.min.css during the build, and/or a CI check that ensures application.min.css is in sync with application.css.

[duanemay]

@lhardt Thank you, I think having a step to run minify, during the build process would be a better approach. The minified version is hard for a human to read to make edits, and it is unclear how to regenerate it when changes are made. Doing it in the build solves this.

[lhardt]

In general, true, but given this file is very seldom changed (3 commits in 6 years) I also imagine it would add more maintenance overhead (because of longer pipeline, and version bumping), consequently saving less time than it would consume.

I could implement it either way, I just want the page to load slightly faster :)

You could also have a github post-action to recommit the minified version in case the original changes. Then it wouldn't impact the main build time / tools.

[duanemay]

@lhardt To expedite, this effort could be divided into two separate Pull Requests (PRs):

• Quick Size Fix (PR 1): Focus on immediate size reduction by removing unused CSS classes from application.css. This is expected to deliver a significant and fast improvement.
• Add CSS Minification (PR 2): Integrate CSS minification into the existing build process.

While running CSS minification as a post-build GitHub action saves overall build time, it complicates the CSS testing loop. To address this, we must either clearly document the manual execution steps for the minification process or, preferably, implement a mechanism (such as using file timestamps) to ensure the build only runs the minification step when necessary.

[lhardt]

Done so.

Now the stats are:

• Previous application.css size: 1691 rules, 235830 B = 230 KB
• Trimmed application.css size: 855 rules, 104879 B = 102 KB

If we were to minify this, we would achieve 64902 B = 63 KB .
This is far from the ideal < 14 KB but much better than current and helps the developer identify much more clearly what styles are affecting the pages