I have tested this item ✅ successfully on b1e7f29

I have tested this item ✅ successfully on b1e7f29

Thanks all for solving the issue.

RTC

Thanks!

As a followup it would be good if someone could split the com_content specific styling from this globals file and create a dedicated scss file for it in a pages subfolder similar to the atum structure https://github.com/joomla/joomla-cms/blob/b1e7f290a81d79117e203a89cfb79af290f7ff29/administrator/templates/atum/scss/pages/_com_content.scss

As a followup it would be good if someone could split the com_content specific styling from this globals file and create a dedicate scss file for it in a pages subfolder similar to the atum structure https://github.com/joomla/joomla-cms/blob/b1e7f290a81d79117e203a89cfb79af290f7ff29/administrator/templates/atum/scss/pages/_com_content.scss

@YatharthVyas Would you like to be that "someone"? ?

@YatharthVyas Would you like to be that "someone"? ?

Sure, Thanks!

I noticed that the atum template's scss/pages/ imports have a message:

I read the PR's discussion and couldn't figure out the reason behind this. This applies to the scss refactoring for Cassiopeia (discussed above) and I want to know what's the correct implementation for these import(s).

I noticed that the atum template's scss/pages/ imports have a message:

joomla-cms/administrator/templates/atum/scss/template.scss

Line 59 in 65d89d0

// Also these DO NOT BELONG HERE!!!

which was added in commit 482aea2

I read the PR's discussion and couldn't figure out the reason behind this. This applies to the scss refactoring for Cassiopeia (discussed above) and I want to know what's the correct implementation for these import(s).

@dgrammatiko Can you answer that?

The problem -that most people don't even see in the above lines- is that we're creating a monolith that is totally inflexible. Of course, most people don't realise the impact of packaging all the css in a file because most of the times they are not even using Joomla correctly (eg extensive use of overrides). So, for those that will never override anything the monolith approach is fine, although a practice of the past that is really against today's needs. BUT if you ever want to override things due to the fact the routes/pages are already styled in the template you're in big trouble and either you have to completely change all the classes (and maybe the structure) of the produced HTML or you have to use !important everywhere. Also, the whole approach is actually fighting Joomla's architecture which is totally modular...

In short, routes (eg component views) should have their own css files. The same goes for modules and everything else that is outputting HTML... We're destroying what should have being a USP for the project (modularity) for the sake of using well establish (and totally outdated) patterns.
My 2c

I absolutely agree with your point

In short, routes (eg component views) should have their own CSS files.

In light of this, I am working on a PR that works on the page related styles for Cassiopeia (I'll later move on to Atum) and this is what I've done:

• Move the scss files for all component's to their respective build/media_source folder
• Import them in their respective component via Web Asset Manager

I have 2 questions for @dgrammatiko :

1. Certain styles are mapped to template variables like $cassiopiea-gutter-width. Should these be hardcoded now as we are separating the component CSS from the Cassiopeia template?
2. Moving these styles to their component folder might not cause any effect for Cassiopeia but they will offset styling for 3rd Party Templates so is it worth it?

Moving these styles to their component folder might not cause any effect for Cassiopeia but they will offset styling for 3rd Party Templates

Not really, the views will still have the default css so, 3rd pd could override the css by adding the relative file in their template css folder. Also you shouldn't really worry about 3rd pd templates as these will be brand new as the ones from version 3 hardly work with the bootstrap 5 markup ?