Dnn.ClientSide: Request for README/Roadmap and Discussion on CSS Architecture (default.css vs admin.css)

[thienvc]

https://github.com/dnnsoftware/Dnn.Platform/tree/develop/DNN%20Platform/Dnn.ClientSide

First of all, I really appreciate the initiative behind the Dnn.ClientSide package. It’s a great step forward.

However, I believe it would be extremely beneficial if the creator/maintainers could provide a detailed README.md. We need a clear vision and roadmap so that contributors (myself included) can align our efforts and follow a unified direction. Specifically, I am concerned about avoiding the "bloat" often seen in default.css if we don't have strict guidelines.

I would like to propose a discussion regarding the CSS Loading Strategy:

1. The Hierarchy: Currently, the loading order typically is: default.css -> skin.css -> portal.css (if applicable).
2. The Role of default.css: We need to define exactly what belongs here.
   Proposal: Only essential styles that are required for every page load (e.g., basic typography, Login control styles) should be in default.css. Everything else should be moved out to avoid increasing the initial payload size for anonymous users.
3. The Role of admin.css:

Proposal: This file should contain styles for DNN specific controls and administrative features.

Loading logic: It should be loaded automatically upon successful login.

Exception handling: For specific cases where anonymous users need these styles (e.g., an anonymous "Contact Us" form using complex input controls), the specific Module or Skin should explicitly request to load admin.css, rather than forcing it into default.css.

Conclusion: Could we establish a clear convention/guideline in the README? Contributors need to know strictly: "If I add this feature, does its style go into default.css or admin.css?"

This will help keep the core lightweight and the codebase organized.

[valadas]

default.css has a lot of history. Back in the old days, it was best practice to limit the number of files at the cost of larger files. And a lot was put into default.css for that reason. It grew and grew with the addition of jquery plugins and telerik controls. In DNN 8, default.css was revamped slightly but then never loaded by default, upon the first releases of DNN8, there was so many breaking css changes that affected so many instances, that until DNN10, the default.css from version 7 was still the one loaded by default.

In DNN 10 I did the first step of trying to improve the situation by:

• Removing everything completely unused in platform
• Removing overrides for old browsers
• Implementing a build system for sass
• Started to try and split that humongous file into digestible parts.

There is still a lot of stuff in it that should be move into other components/modules as they are not always needed unless those components/modules are displayed. Modern protocols (HTTP2 with HTTPS) will actually perform better with smaller files loading in parallel just as needed.

I think any effort in that direction would be welcome but documenting it or simply doing it should be the same amount of work.
Generally speaking, default.css should have only what is essential for everyone. admin.css for after being logged-in. And for everything else, it should go into the component affected. So if something is about the journal, it should go in the journal module, etc.

If you have time to submit PRs that go in that direction, I think they would be welcomed improvements as long as they don't break existing sites.

[thienvc]

Oh, so if I understand correctly, our ultimate goal is to completely remove default.css, right?

I just want to understand the direction so that if we ever do PR, we'll be heading in the right direction that everyone wants to go.
But I think it's very difficult to completely remove the default default.css, because there are so many small skin objects; breaking it down too much wouldn't be very good.

[Timo-Breumelhof]

I agree CSS should be loaded by the control that needs it.
IMO the fact that Daniel split up default.cs into SCSS is a very good first step.
You can now unload default.css and add only the part of it you want to your theme.

[valadas]

Well, I think if we move enough stuff out of it, one day it could only have very broad sensible defaults like a base font definition and that kind of global things. The modern web has no issues with lots of small files, it is actually preferred so if everything can move to its appropriate control, that we be the overall direction. No point in having css for search if you site does not use search for instance.

Move everything from https://uxguide.dotnetnuke.com/ into it's own folder in that sass system would be nice too. This is used by a lot of 3rd party extensions and extensively all over DNN itself which is the greatest risk of css breaking changes.

But yeah, it was really hard to reason about when it was a single huge file. It is slightly better and small very focused PRs that improve it further would be awesome to progressively continue that cleanup.