Move DNN Styles Into Cascade Layers to Allow Modern CSS Styling

[jeremy-farrance]

Reference: MDN Core CSS Features - Cascade Layers

Note that the issues here are not unique to Tailwind CSS v4 or DNN. Any system that uses CSS Cascade Layers on top of an existing framework that does not already use layers ends up with ALL of its CSS in the implicit outer layer and an unbeatable specificity.

---

Credit for raising the issue/need: #6686 - [Enhancement]: Wrap default.css in @layer to work with Tailwind 4

---

The primary reason for difficulties in using Tailwind CSS v4 with a pre-cascade-layers (legacy) framework (e.g. DNN, WordPress, etc.) stems from Tailwind v4's reliance on native CSS Cascade Layers, a feature that legacy frameworks and their extensions do not natively support or integrate with effectively.

Please keep in mind, this is not about TailwindCss v4. DNN currently prevents the use of the modern CSS Cascade Layers feature and it needs to be addressed.

Here's why this creates incompatibility:

• Unlayered Styles Priority: In CSS, unlayered declarations (styles not explicitly placed within a @layer rule) have higher priority than declarations within a layer, regardless of their order in the stylesheet. Legacy frameworks' existing styles are largely unlayered.

• Tailwind v4's Use of Layers: Tailwind CSS v4 utilizes native cascade layers to organize its utility classes and ensure proper cascading behavior. This means Tailwind's styles are placed within layers.

• Conflict in DNN and other legacy frameworks: When Tailwind v4 styles (layered) are used alongside the framework's unlayered styles, the unlayered styles often override Tailwind's intended styling, even if Tailwind's rules appear later in the stylesheet or have the same specificity. This can lead to unexpected visual inconsistencies and broken layouts, particularly in the legacy framework's admin or backend area where numerous unlayered styles are in play. In DNN this borders on unusable for on-page things like Module Settings.

Addressing the Issue:

While directly integrating Tailwind v4's layered approach into DNN or WordPress or any legacy framework can be challenging, potential workarounds or solutions might involve:

• Wrapping DNN Styles in Layers: Attempting to wrap all of DNN core, admin, extension, module styles within @layer rules. Though not technically difficult, the results could potential introduce complex and potentially fragile results that may require additional work for the backend.

• Using !important: Applying the !important modifier to classes in layers can force them to take precedence, but this can lead to difficult-to-manage CSS and conflicts with other !important declarations. It might be prudent to remove all occurrences of !important in the framework's CSS and fix the precedence issues correctly using other logic, cascade layers (nesting), or other options.

• Exploring Compatibility Builds or Tools: Some projects or tools might emerge to provide better compatibility between Tailwind v4 and legacy frameworks, potentially by adjusting how styles are loaded or processed. For example DnnCssInclude() could add features that would introduce a default target layer when not specified - as well as handle a passed in layer parameter. However, since the HTML LINK element does not yet support a layer="" attribute, this becomes a modification process that may involve storing/caching multiple versions of CSS files. Too early to speculate, but imagine: default.css, default.min.css, default.layer.css, and default.layer.min.css and DNN loads the correct one based on Host, Site (or Theme) settings. **

Repeating from above, I am just reiterating this for clarity: This is not about TailwindCss v4. DNN currently prevents the use of the modern CSS Cascade Layers feature and it needs to be addressed.

---

** One future option is that it is likely within the next 1 to 3 years, the HTML spec will add an attribute to the <link> element. You can read about this here. Note that this is a massive discussion covering a lot of ground.

The HTML Standard - Issue 7540 - Allow authors to apply new css features while linking stylesheets
whatwg/html#7540

[jeremy-farrance]

If you would like to see a working website with a TailwindCss v4.1.14 theme that has a hacked (working) solution in place as a demonstration, go here
https://accu2025.accuraty.us/DNN/DNN-Multilanguage-Set-up-Walkthrough

We've manually modified the [/Resources/Shared/stylesheets/] dnndefault/10.0.0/default.css and moved the whole thing into our base layer like this:

This one change solved at least 3 major issues as well as dozens of minor/glitchy visual problems in the DNN backend.

• Module Settings was very difficut to read/use
• Each Module's Command/Action menu was hard to use and the 3rd dropdown for moving module up/down and between pains was blank
• On-page Drag and drop for Modules was broken
• All popup html dialogs had no styling, e.g. simple confirmations needing yes/no answers
• Adding a Module to a Page ("the floater") could not be selected, dragged, dropped
• etc.

[Timo-Breumelhof]

As we now have a version default.css created from an scss source, isn't building your own version (and not loading the "default" default.css) the best option anyway?

[Timo-Breumelhof]

see: https://github.com/dnnsoftware/Dnn.Platform/tree/develop/DNN%20Platform/Dnn.ClientSide/src/styles/default-css/10.0.0

[jeremy-farrance]

If you are not logged in, the problem is minimal or almost non-existent. Well, unless you've got a vendor's modules on the page with old, leaky, or poorly written CSS (and HTML) in play.

If you are logged in, see the screenclip below, every line above the highlighted Aperture skin.css is a CSS file contributed to the page by a clean install of DNN v10.01.02 - currently without a @layer, and therefore all in the implicit outer layer. I am not suggesting all the files create problems currently or for me.

[jeremy-farrance]

Option 1 - Inline-Style with @import ... layer(name);

Note: Opt 2 is in a reply below

One possible solution I've been thinking about would require a fair amount of effort, though in some ways stays conceptually pretty simple. Since the only way to specify a layer is in an @import statement.

We have to modify or extend the Client Resource Management API to provide a new output option. Instead of the result like you see above, a bunch of <link> statements, you'd instead be be building an in-line <style> sheet and all the links become @import statements, something like this:

<style>
@import url(/admin/menus/ModuleActions/ModuleActions.css?cdv=127) layer(base);
@import url(Resources/Shared/stylesheets/dnnicons/css/dnnicon.min.css?cdv=127) layer(base);
@import url(/Portals/_default/Skins/_default/WebControlSkin/Default/GridView.default.css?cdv=127) layer(base);
...
</style>

I understand (at this time) this might be a slight performance hit since the @import ... is known to be slower than a <link> element. 3 to 9 times slower, but we are talking about speeds like 60ms vs 230ms. I'd take that trade off since there are other solutions to the slowness.

DNN would need to add settings for this. It also seems obvious we'd need a default layer to throw them all into and additionally a way to select/match/assign? others to specific layers (e.g. reset, components, utilities, or whatever is needed).

[Timo-Breumelhof]

With the effort to support Content Security Policies, I don't think inline CSS is a good idea?
https://content-security-policy.com/examples/allow-inline-style/

[jeremy-farrance]

Option 2 - Bundle the @import Statements to a file included via <link ...> statement

My CSP knowledge is intermediate through trial and error. But I do not have the impression currently that issues like that are insurmountable. But if it is...

Then we instead compile the CSS into a new file and <link ... > it on the page.

...
<link href="/Resources/Shared/stylesheets/dnndefault/10.0.0/default.css?cdv=127" type="text/css" rel="stylesheet">
<link href="/Portals/_default/[ somewhere ]/layered.css?cdv=127" type="text/css" rel="stylesheet">
<link href="/Portals/_default/Skins/Aperture/css/skin.min.css?cdv=127" type="text/css" rel="stylesheet">
...

layered.css:

@import url(/admin/menus/ModuleActions/ModuleActions.css?cdv=127) layer(base);
@import url(Resources/Shared/stylesheets/dnnicons/css/dnnicon.min.css?cdv=127) layer(base);
@import url(/Portals/_default/Skins/_default/WebControlSkin/Default/GridView.default.css?cdv=127) layer(base);
...

[bdukes]

I think we would want to enable using a nonce to include inline styles and scripts when necessary

[Timo-Breumelhof]

Agreed, but it should not be needed by default IMO?

[bdukes]

If our choices are between the two options @jeremy-farrance presented, I think the inline choice has enough of a performance benefit to use the nonce (maybe we can use HTTP/2 Server Push instead to provide the same benefit).