Hello everyone,
while working on some other part of Horizon, I recently looked at the source of the pages generated, and noticed that a substantial amount of each page is the style, compiled and included on every single page using the <style> tags. That is a rather bad practice for a number of reasons, from performance to waste of bandwidth. I decided to see if that could be easily fixed, so prepared this patch that instead includes the compiled style using a <link> tag:
https://review.opendev.org/c/openstack/horizon/+/966665
Now, I'm writing to this list for two reasons. The first is to make sure that there isn't some rule or regulation, possibly introduced before the Web was invented, that requires all OpenStack software to handle the styles in that way, and that we would be breaking if we went with my patch. no in fact we could entirely remove the use so SCSS entirly and adopt a modern stack like tailwind or anything else my understanding is scss has generally fallen out of style in much of
On 19/11/2025 15:38, Radomir Dopieralski wrote: the Django and modern web wold as has the way horizon is using the compressor component in favor of tailwind and django-webpack-loader to allow loadign precompied assets to be generated at build time instead fo doign the compresson in python at runtime with the django-libsass and django-copressor you dont need tailwind to use django-webpack-loader this block talks about using it with scss https://blog.kalvad.com/django-webpack-series/ i have nto done much with horizon dev but i found the current scss and django comporess ro be very fagile and hard to fix when it did break requiring a lot of manualy purging of caches or manual compress to keep working so much so that i endd up wrigitn https://review.opendev.org/c/openstack/grian-ui/+/952608/3/TROUBLESHOOTING.m... it was a very frustrating experience to debug and off puttign to even attepmpt to work on horizon. the only thing to keep in mind with using something like this woudl be that npm is specified for javascritp depnices https://github.com/openstack/governance/blob/master/reference/pti/javascript... so while bun or a diffent tool might be temptign npm shoudl be used to do the webpack build |i.e `npm run watch` to have it watch teh file tree and hot reload and compile the css as you edit the files.|
The second is of a more technical nature, and pertains to the change that had to be made to the `_components.scss` file in that patch. In short, a similar change would have to be done in any Horizon plugin that adds style sheets to `HORIZON_CONFIG.scss_files`. Since we don't have control over Horizon plugins and can't possibly force such a change, and since merging my patch without such changes would break the plugins, I would like to hear from the plugin maintainers about the best way to proceed with this (or, just leaving things as they are, if that is the better option).
The change becomes necessary, because the included `scss_files` can no longer be compiled in one huge block with the rest of horizon's styles, but have to be included with their own <link> tags as separate files, which means that any dependencies they rely on have to be explicitly included using the `@import` mechanism. Most of those styles at the minimum will rely on the common variables from the theme, that's why this particular import, but there may be a need for more imports added depending on what the stylesheet in question uses.
I'm also open to suggestions on how to avoid the need for this change and compile everything in one big blob as we are doing now, but don't inline the style on every page. Between Django, Django-compressor, SCSS compiler and template mechanism, I don't currently see a way to do this.
if you are reoping the topic of how hohrizon does CSS woudl consider taking a step back and seeing if there is a simpler stack to acive the same goal. if you were to move away form SCSS entirlly there propably woudl need to be some deprecation or upgrade path/gudiacne on how to supprot custom styling but if your not propsoing moving away form https://sass-lang.com/ as the css lanague then refactorign the way its used within horizon should jut need to follow horisong normal feature development flow which i assume need a spec? its kind of like upgrading to django 5.2 adopting the latest lts version of django is just an internal change tha tis not visable outside of the developer. if this work woudl impact the dependencies thre is also an impact on updating the requirement repos if your addign some but if our usign the same dependencies but just in a new way that an internal change that shoudl not really impact others. horizon plugins can provide css but typically dont, they could be impacted if the classes that are incldued by default change but that coudl be tested with dnm or depends on change. to the relevent plugins.
Thank you for your feedback, -- Radomir Dopieralski