Multiple archnavbar versions

[lahwaacz]

Why do we have this and this?

Also, we should probably use arch-common-style to generate the navbar style. (Didn't check yet if there is actually a visual difference...)

[jelly]

I am planning on switching to the arch-common-style one, and that version should also become responsive somehow. The plan is to first switch plain css to scss so I can get rid of cssmin which isn't even maintained anymore.

We'll have to figure out if a git submodule checkout can be used for the common-style and research if django-sass is good enough to generate css

[Phosphenius]

Hi, can I help with this? I work with sass/scss in my day job.

The way I see it you could also just host the arch-common-style CSS somewhere and then <link> it from archweb. Of course this has some advantages, but you would not have to deal with git submodules.

While we're at it, what about my PR? I'd probably have to rewrite it in scss, right?

[lahwaacz]

Well, the minimalist solution is to build archlinux-common-style with make and sassc. As far as I understand, django-sass does not have any benefits here since archlinux-common-style is not a Django app and we're not trying to switch the whole archweb to SASS (yet?).

[jelly]

I don't see any benefit in the minimalist solution, I'd rather switch to djang-sass to take advantage of something which using all the common styles which it adds for colors etc.

[jelly]

Ok, turns out django-sass has pros and cons:
+ pure python
- doesn't support relative paths as ../

So relying on an arch package like sassc is probably easier but I don't really like deploying running sass on our server. So maybe I'll just commit the generated css as it won't change that often anyway.

[jelly]

Truns out django-sass uses libsass which is deprecated in favor of https://sass-lang.com/dart-sass which we package!

https://gitlab.com/mailman/hyperkitty/-/issues/319