Update the default Xcillion theme

[EPTamminga]

Description of the Problem

The current default theme pack (Xcillion) can be enhanced. A new and updated version of this skin has been created by DNNConsulting (Geoff Barlow) and is available in the store:
(https://store.dnnsoftware.com/home/product-details/dnn-xcillion20).

This theme pack has its own name i.s.o. being an update of the existing theme.

Geoff is OK if we bring the source pack to the DNNCommunity organisation on GitHub.

Please note that the source is based on SASS and not plain CSS

Proposed Solution Option 1

• Modify it to make it an update of the existing Xcillion 1.0.0 theme

Proposed Solution Option 2 (If Needed, repeat for more)

• Make this new theme the default theme for a new installation
• Remove the old Xcillion theme 1.0.0 from the DNN platform install pack
• Do not touch the old theme installation

Alternatives Researched

Affected version

• 9.4.0

[sleupold]

I noticed a few typos in the Xcillion 2 package (e.g. the skin is installed as "Xcillio 2" which should be fixed first IMO (it doesn't find the associated container)

[EPTamminga]

@sleupold Yes, I know. The store pack is not ready for release.
This is also not the sass source.

[mitchelsellers]

If were were to do this, we would need Geoff to contribute it via a Pull Request to meet CLA agreement requirements.

[valadas]

And I would go with option 2 to not disrupt people who have modified the original. I know you should not modify it and make a copy instead but I am pretty sure a lot of people did it anyway.

[EPTamminga]

@mitchelsellers I will ask him to do so if we go this route.

[ohine]

This is awesome, thanks for taking the time to create the RFC and thanks to Geoff for working on the new skin!

I'd rather we do an upgrade and keep the amount of skins/containers down as much as possible. I think with proper wording in the release notes, we could just warn people if they have modified the old skin they need to rename or they might loose customization's.

There are performance issues when we have a bunch of skins and containers installed, but that's a separate issue we could address as well which would be even better!

[mitchelsellers]

I would like to chime in here that I agree with @ohine on this, that we should upgrade the current skin as well for the same performance & bloat perspectives. It wouldn't make sense to uninstall Xcillion on upgrade, but there is no need for two separate default skins.

[sleupold]

sorry to disagree with the previous two, but I might be the only one, who already worked with Xcillion 2.0.
There is a real risk of Xcillion 2.0 (based on bootstrap 4) to break with modules and of course it would overwrite any customization of Xcillion 1 skin or container. I don't see a benefit of installing it by default for upgraded sites - which usually either base on a modified Xcillion (and will fail) 1 or a third party skin (and won't even notice the new skin included.

[sleupold]

I would also vote to include a minimal skin as default (fallback) skin, just with minimal styling and a single skin and container (maybe a blank one as well, which is useful for printing or iframing a site).
Including a splendid default skin is great for demoing DNN after installation, but it should be uninstallable, not to irritate users.

[EPTamminga]

I prefer to have one xcillion theme and not create an additional one (option 1). Modifying the original (remark of @valadas) is not good strategy and we should not encourage that by working around it and create a new separate theme pack.
Like @ohine mentioned, we can use the release notes to give a clear warning and instruction.

[EPTamminga]

@sleupold A minimalistic additonal theme pack seems a good idea, but not part of this RFC.
My suggestion for you is to create an additional RFC for that.

[kurtwilbies]

I prefer a minimalistic theme. And show others how to extend this theme with paid or open source extensions.

[EPTamminga]

Should we

• move the Xcillion theme in its own repository in DNNCOmmunity and remove the content from the DNN.Platform repo,
• or update the current version in the DNN.Platform repo
  (https://github.com/dnnsoftware/Dnn.Platform/tree/development/DNN%20Platform/Skins/Xcillion)

[sleupold]

I'd move it to its own repo - it is an optional extension and would be easier to update.

[EPTamminga]

@sleupold No, it is not optional since it is being used in the standard site template as part of the default installation.

[EPTamminga]

@ohine Is it an option to remove the xcillion source files from this repo and only inlude a zip install pack with a release of the xcillion theme?
That way the xcillion theme can get its own repo with releases. A new release of the theme could be provided to dnnsoftware repo by a PR with the new theme release zip.

[ohine]

@EPTamminga Of course, anything is possible. It's really up to @mitchelsellers on it's final resting place. We already include the CK editor from dnn-connect so I wouldn't see it any different to include the theme from dnncommunity or another similar source.

[ohine]

The only requirement I'd think we'd want to make sure is configured is the 2 person code review requirement on pull requests, and allow the same platform approvers admin access over that repository.

[mitchelsellers]

THis is yet another grey area.

1. Yes, in theory, this skin is optional. However in reality it isn’t. The installer needs it for the default templates. And DNN needs at least one Skin to be operational.

2. many sites, after installation obviously do not use this theme, some even uninstall it. But not many from what I’ve seen.

This puts it into a situation whereby an external repository, with additional build dependencies and additional developer setup is most likely overkill for a required setup. But on the same token since the new version uses Scss etc that’s a complexity we don’t have in platform build.

This is going to open the Big can of worms again. I’ll look to add this to the TAG agenda.

[ohine]

This is going to open the Big can of worms again. I’ll look to add this to the TAG agenda.

It shouldn't. We have already decided to keep the repos separate after a couple RFCs and many discussions on the TAG call. We need to support the open source community and consume projects which help the platform. We can easily make sure the skin is packaged and the source is included in our source package. However, it shouldn't be a requirement to migrate contributions into our main repository, it only contributes to the mess we're trying to untangle and organize correctly.

The same argument can be made for CDF and CK, without either of them the platform doesn't function, yet they're perfectly ok standalone and they're ignored from the larger debate.

Anyways, I look forward to continuing this conversation on the TAG meeting or in another RFC on the topic.

[mitchelsellers]

I’ll make sure this gets added to an agenda and keep this RFC updated

[EPTamminga]

The theme install zip has nothing to do with sass anymore, it is a standard theme pack with containers.
The sass is only used as the source of the theme development, like C# for creating a dll.
So I do not see any can of worms here.

Removing the theme source from the dnnsoftware repo makes that repo cleaner.
Putting the theme in its own repo makes it easier to maintain the theme itself.

[EPTamminga]

@mitchelsellers Is there any news about this? I would like to make some progress with an update of the Xcillion theme.
My preference remains to have the Xcillion theme in it’s own repo in DNNCommunity and provide an update of the theme pack as an install zip in a PR for DNNPlatfform.

[mitchelsellers]

@EPTamminga sorry for the delay on this, we needed to address other issues with the 9.3.0 release and are getting back to this now. The current skin is part of the DNN Platform source, and is built as part of the DNN Platform source. This includes the copying of files from the skins folder into the respective pages for install & upgrade.

The easiest solution would be to create a pull request that updates the source within the existing structure & process. Keeping the same theme name, etc. This is the preferred route, at this time.

Other solutions, including keeping the source outside of DNN.Platfom, will require changes to our build scripts, the automated build/release pipelines, and more downstream impacts.

[EPTamminga]

Ok, I will follow this route for updating DNNPlatform repo.
For easy developmen and testing, I will still create a separate repo for the Xcillion theme pack in DNNCommunity.
Once the update is ready, I will update individual files in the platform repo, while trying to keep names and structure as similar as possible.

[EPTamminga]

Decision made, case closed.

[bdukes]

Certainly, managing a product which must navigate multiple environments is tricky. One small contribution to make that simpler is https://github.com/DNN-Connect/connect.koi, which attempts to allow you to multi-target your markup based on the framework used by the theme. It's definitely not a silver bullet (I don't have any idea how many commercial themes include a koi.json file), but one option to try to wrangle this difficult problem.

[stephen-lim]

@bdukes Thank you for sharing the link. KOI looks like an interesting idea, but in practice, it would be painful to support more than one framework. The razor code would be so heavily bloated.

From a customer support and employee training perspective in a shrinking CMS market, I don't think it's a good idea to encourage using so many different frameworks. I believe the platform should set the technology standards straight and upgrade the standards over time. Better be good at a few things than try to do everything is my kind of philosophy.

[valadas]

There is a concept of each thing having a single responsability, for instance for a module to work on any theme, the module should do it's own thing and not rely on the theme having any specific framework available. Now a lot of people find Bootstrap very popular and want a consistent look across content and modules and the theme. Updating the default theme is in the plans but will it be framework free or rely on bootstrap 4 or maybe bootstrap 5 so we remove the dependency on jQuery ? Who know at this stage. And I see very very few sites that actually run on the default theme, so just things to keep in mind regarding separation of concerns.

KOI although not a bad idea is a bit of work for module developers, like you say, the module then needs to handle all use cases and well, it's a lot of work.

One improvement that should come with Dnn10 is truely reusable web components and css varialbles, this will allow better harmony between look and feel for both the Persona Bar, 3rd party modules and themes. There will be a basic set of very generic info like primary, secondary, tertiary colors and controls radiuses, etc. Then a set of dnn branded reusable components like buttons, inputs, collapsibles, etc will be added and those are standards based and can work in the persona bar, React, Angular, plain html module and so on. I have been working on those for many months and when we start more seriously working on Dnn10, I will merge that here and have blog posts, etc. I have been using them in many custom modules already and they are really nice and tiny and dependency free. You can take a look if you are curious here https://github.com/eraware/dnn-elements ignore the root readme for now, but if you go into each /src/components folder they each have their own little readme explaining the component and it's options.

[stephen-lim]

Your site reminds me of DNN UX. The problem is without sufficient resource, it becomes unmaintained, falls behind modern standards, and nobody you can hire wants to learn it. I think it's more reasonable and achievable to stick with the few big frameworks and just nudge developers and designers to adapt the chosen standards and not try to create your own or have too many.

For example, if DNN officially makes Bootstrap "The Official Framework", the site will already look more or less the same (the look of the persona bar does not really matter, because it lives in an iframe outside the page). Any new designer can create nice themes out of Bootstrap to make the page pretty because the HTML/modules render following the same layout/pattern. Ultimately, to thrive in the ecosystem, developers need simplicity, predictability and consistency. Developers can earn a living selling themes/modules at a decent ROI without worrying that it becomes obsolete or integration bugs overwhelming them. Bootstrap may change with times and remove jQuery and we may have to adapt but at least it's far better than having another slow dying unmaintained standard.

"Having standards is good, but having too many standards is just the same as having no standards at all."

[valadas]

Anyone is free to use a bootstrap theme, this is a choice. Dnn by convention tries to not enforce anything that is not a standard. Bootstrap being popular does not make it a standard.

By standards, I mean web standards like CSS, HTML and Javascript. Those are real true standards and don't depend on any framework. I am not sure what you mean by slow dying unmaintaned standard but when you say that developers without worriyng that it becomes obsolete then locking into a framework goes directly against that. Developers should learn to make their modules standalone, they should just work on any theme and not rely on a theme having a specific framework. Granted, they can opt-in using something like KOI, but we cannot make enforce bootstrap or any other framework, We are be our own mentra open and locking into a specific framework goes against that mantra.

[stephen-lim]

@valadas I appreciate your work for trying to unify the CSS and we'll be happy to use it when it becomes widely adopted. It's really good if it works out because it allows unifying the themes, modules and the persona bar world.

It's just my opinion. What I'm trying to say is developers/designers need more guidance from DNN (call it "standards" or "best practices" if you want). Those who want to use other framework can do so, there's nothing stopping them. But for those who are trying to build a stable unified system it's pretty important commercially. When you have a developer who builds modules and does not speak to the designer who sells themes, we still need to understand each other at the end of the day that what we build will "just work" easily. KOI, for example is a great idea, but it needs to be better communicated by DNN (maybe an official page for developers/designers on what are the current "recommended" standards). I haven't heard of KOI and I think it existed for 3 years now and I don't think I ever saw any themes using it so it's only going to be useful if it gets to mass adoption.

A couple of months ago, we had wanted to invest some serious money and build 100+ new themes so customers would have more choices. We needed to know what is the current recommendation for building themes that has a higher chance of being future-proof knowing that DNN is planning to go .NET Core, Razor, etc.. Themes are kind of fundamental to any CMS so we thought surely there must be some published standards or roadmap or discussion, but we didn't find any. So we had to ask the question in the forum. I think the best answer we got is something like "just keep building using Webforms because we're still far away from migration". It might turn out to be the correct answer, but it doesn't instill confidence. The investment was eventually shelved because we can't invest if we don't know if it's going to be worth it. The same problems plague module developers. We don't know if we should invest time to code for Bootstrap 3 or 4 or some other framework, but we cannot sustain more than one framework otherwise it becomes cost prohibitive. Likewise, designers are building themes using Bootstrap 4 not knowing if the modules will work on them.

I know it's all volunteer work and nobody has time, but I think we can get more developers/designers excited if there was more guidance.

[mitchelsellers]

I understand the request. But I’ll offer a different standpoint from my perspective.

A lot like other platforms we don’t want to “recommend” or endorse a specific paradigm as it could unnecessary limit what people think is acceptable.

I see some vendors, in a manner that I support, having internal support for multiple frameworks, or simply launching to isolated environments for edit.

There is a bit of a long term but here. But I don’t think DNN should suggest any sort of limitation to the types of frameworks being used.

[valadas]

Documentation about KOI would be nice, the Dnn documentation project is open source, you could contribute your findings at https://dnndocs.com

As for investing in a framework assuming everybody will just adopt that one... dont.

Dnn will not enforce a framework and even if Dnn would, nobody can force developers to follow that rule. Again we try to be open and allow people to use or not their framework of choice. It has been tried before with the Dnn UI/UX was an attempt at guiding people towards a common Dnn specific way of doing things, very few developers followed it and we now have a pain in the neck trying to not make these things a breaking change while trying to move Dnn forward to new technologies.

Themes are still webforms based, right now it is the way to go until we have a clear direction on a technology shift. And to future proof any solution, you should get as barebone and follow as much as possible just know standards like html/css/javascript. Any usage of a framework and more importantly enforcing one, would make the transition to newer technologies more difficult and breaking changes more unavoidable.

[mitchelsellers]

Just one additional item. koi documentation would not be proper in dnndocs. @david-poindexter correct me if I’m wrong

[david-poindexter]

Just one additional item. koi documentation would not be proper in dnndocs. @david-poindexter correct me if I’m wrong

You are correct - KOI is a 3rd-party solution by 2sic. It is not part of DNN Platform and therefore does not belong in the core DNN Docs. That said, there would be nothing wrong with a "Lab" being added to dnndocs.com show how to use it in the context of DNN stuff. Hope that makes sense.

[david-poindexter]

Oh, and one more note (before someone mentions it). Just because the Xcillion theme has a koi.json file does not mean that KOI as a solution is part of DNN Platform. This is simply a JSON file in the theme to tell anyone using KOI which CSS framework is being used by the theme. 😉

[david-poindexter]

@stephen-lim I get where you are coming from. I also understand the perception that this rock is just being kicked down the road. We have recently changed our project milestones to help with this perception a bit.

The reason the base theme (Xcillion) has not been updated to Bootstrap 4 is that it would be a breaking change. Therefore, it has to wait until we get to the next major release. By the time we get there, my guess is Bootstrap 5 will in the conversation. ;-)

Therefore, as @bdukes mentioned earlier, we found out that we could address security concerns by simply upgrading the them to the latest Bootstrap 3 version.

Finally, Xcillion is just the default theme. As @valadas mentioned, it is very rarely ever used in production. Therefore, it is up to the implementor of the site to use it, a 3rd party theme, or develop their own. There is no such thing as a one-size-fits-all theme. Now, that being said, we personally use the same modern tooling (nvQuickTheme) for every custom theme we build. We focus on our own "best practices" and those contributed by the community to help refine the tooling. Sometimes we use that tooling with Bootstrap. Sometimes we use it with no CSS framework at all and go pure web "standards" based. Sometimes we use that tooling with Foundation. Someone recently used it with Tailwind CSS. My point is it is really up to the implementor (not DNN Platform) as to how they want to use or not use CSS frameworks.

I hope this helps.

[stephen-lim]

@david-poindexter I appreciate all the hard work you guys put in and I respect the idea of keeping an open platform. I hope I shared some concerns from a vendor perspective and the struggles we go through. I'm glad we had this conversation and learned about KOI. We started testing with KOI today and were able to convert many files to support both Bootstrap 3 and 4 so this is very promising. I think it's something we will use and tell theme vendors to implement.

I understand Xcillion is the default theme and you probably want to install a unique theme eventually. It depends on the use case. If a new user is looking to launch a static site, they will start with a replacement skin and slowly add modules. On the other, if a customer is looking for complex functionality to achieve a particular goal (e.g. ecommerce module to sell online), they will start with the Xcillion theme to test drive the module before browsing for a replacement theme. I'll share an actual conversation our team had with a customer recently (every few weeks we get customers complaining our module won't work with such and such theme running Bootstrap 4):

Customer: I purchased Revindex in the past: but never used it. Actually it didn't work with my skin but i never figured out.
Customer: I'm starting a new site now.
Customer: I am currently installing a fresh Windows Server 2019, SQL 2019 Express, and DNN_Platform_9.6.2
Support: sounds good
Support: We also have hosting support now
Customer: are you aware of any IIS settings which are required for DNN for Windows Server 2019?
Support: No, it will just work out of the box
Customer: does your storefront offer videos and download?
Support: You can upload any file for people to download after purchasing (sell digital product).
Support: The next release allows you to show videos as part of your image galleries
Customer: do you allow for multiple languages?
Support: yes
Customer: OK so i can just download and install to try? will it work with my skin?
Support: You need to look for skins that uses Bootstrap 3. The default skin is compatible.
Support: yes, after your DNN install, you can install the module like usual
Customer: it's a new install so I didn't put a skin.
Support: yup, that should work.
Customer: so any skin will work?
Support: no, only skins with Bootstrap 3. just look for a skin that says "Bootstrap 3"
Customer: what if it doesn't say, will it work?
Support: most likely, you can give it a try. And if it doesn't work, you can try contacting the skin developer to ask if they have an older release with Bootstrap 3. In the future, we'll support the newer Bootstrap 4.
Support: Do you know if your skin has Bootstrap 3?
Customer: no. not sure. I bought it 2 years ago after I bought the module. I don't think my vendor exists anymore.
Support: you can look inside the css and js files for any mention of Bootstrap and version.

The conversation went on and on for many more lines with the customer asking questions about functionality. The customer ended up installing the module on the Xcillion skin. Had he started with a 3rd party skin with Bootstrap 4, it would have bombed badly. Next release will be compatible with Xcillion and skins running Bootstrap 4 with KOI. But I think you can feel the friction in the sales process. I'm sure he'll contact us again in a few weeks once he starts with a different skin and realizes some skins will break the module.

[david-poindexter]

@stephen-lim thanks for the insight and feedback. As a module vendor myself, I can empathize with the pain. 😉

[valadas]

If a module does not work with such or such theme, the module has a serious problem. Extensibility requires decoupling and if a module needs something on the theme, it is wrong (well mainly for off-the shelf modules, if you do build your own themes and modules to go with them, it is a bit more debatable). I don't know enough about RevIndex but if the only provided template needs bootstrap 3 to be present on the theme, I find this very wrong in my opinion. A slightly better solution would be for the module to provide it but with a scope to not interfere with the rest of the theme and other modules as shown here https://stackoverflow.com/a/14145510 or even better rely on plain css/javascript or templating to allow integrators to customize them. The upcoming Dnn css variables will help a lot in relying less on frameworks to provide some sort of styling harmony between themes and modules and more.

To make a simple analogy for a module needing something specific to exists on the theme (in this case Boostrap 3), it would be like building stoves that only work with a specific brand of pots (framework) and then making it even worst by just making them work with one size of pot (framework version). Now the solution to this problem is not to standardize the pots and only manufacture one brand and one size even if that is the most popular brand and size, the solution is to not build stoves that rely on a brand and a size of pot.

[stephen-lim]

The good news is we just made a release that now supports both Bootstrap 4 and 3. The code is a bit more bloated than we like but it works!

It would be nice if the module can be framework agnostic to the theme. Unfortunately, to get anything looking nice with some level of uniformity, we must rely on the theme to style the entire site especially for basic controls. Most DNN themes are built with Bootstrap. The author modifies the CSS values to change the color of the buttons, text, margins, etc. to make it look custom. That's fine and we would like our module to participate in that customization so the colors, text, margins, etc. stay uniform across the site.

We normally don't require a specific version of Bootstrap. We needed it uniquely this time because Bootstrap 4 is a major rewrite and released with many breaking changes. For example, to render tabs in Bootstrap 3 used to be like this:

<div>
  <ul class="nav nav-tabs" role="tablist">
    <li role="presentation" class="active"><a href="#home" aria-controls="home" role="tab" data-toggle="tab">Home</a></li>
    <li role="presentation"><a href="#profile" aria-controls="profile" role="tab" data-toggle="tab">Profile</a></li>
  </ul>
  <div class="tab-content">
    <div role="tabpanel" class="tab-pane active" id="home">...</div>
    <div role="tabpanel" class="tab-pane" id="profile">...</div>
  </div>
</div>

In Bootstrap 4, it's very different. If it was just CSS rules, we could override it or render different CSS files, but some of the breaking changes require modifications to the HTML.

<nav>
  <div class="nav nav-tabs" id="nav-tab" role="tablist">
    <a class="nav-item nav-link active" id="nav-home-tab" data-toggle="tab" href="#nav-home" role="tab" aria-controls="nav-home" aria-selected="true">Home</a>
    <a class="nav-item nav-link" id="nav-profile-tab" data-toggle="tab" href="#nav-profile" role="tab" aria-controls="nav-profile" aria-selected="false">Profile</a>
  </div>
</nav>
<div class="tab-content" id="nav-tabContent">
  <div class="tab-pane fade show active" id="nav-home" role="tabpanel" aria-labelledby="nav-home-tab">...</div>
  <div class="tab-pane fade" id="nav-profile" role="tabpanel" aria-labelledby="nav-profile-tab">...</div>
</div>

Just to throw in another example where frameworks can complicate the module development and make the code bloated. To render tabs with Foundation, it would look like this:

<ul class="tabs" data-tabs id="example-tabs">
  <li class="tabs-title is-active"><a href="#panel1" aria-selected="true">Home</a></li>
  <li class="tabs-title"><a data-tabs-target="panel2" href="#panel2">Profile</a></li>
</ul>
<div class="tabs-content" data-tabs-content="example-tabs">
  <div class="tabs-panel is-active" id="panel1">
    <p>..</p>
  </div>
  <div class="tabs-panel" id="panel2">
    <p>...</p>
  </div>
</div>

For a large module, it would take a large amount of resources to support more than one UI framework. So while DNN is still being released with default theme that uses Bootstrap 3, the understanding is modules should at least continue supporting Bootstrap 3 and figure a path forward to support Bootstrap 4 to be compatible with 3rd party themes sold online working around the breaking changes in Bootstrap.

[valadas]

Bootstrap 4 is a major rewrite and released with many breaking changes

Yep, that's what frameworks do

We normally don't require a specific version of Bootstrap.

Well you kinda do, event though we are talking about major versions, that is the tradeoff of using a third party framework, you never know when there will be a breaking change and the more parts you make depend on it, the more rewrite you have to do when that happens. We are discussion going to bootstrap 4 and bootstrap 5 is in the works. It's an endless chase.

For a large module, it would take a large amount of resources to support more than one UI framework

Yep and this is why I believe modules should not rely on the theme having any framework, a module should be standalone and work on any theme.

the understanding is modules should at least continue supporting Bootstrap 3 and figure a path forward to support Bootstrap 4

I just cannot wrap my head around this reasoning. The theme responsability is styling and using bootstrap there I see no issue, but modules should not depend on the theme; the theme could style the module, as long as modules have a css scope this is possible in any and all themes.

[stephen-lim]

I'll give a small example. Suppose the module has a Save (primary) and Cancel (secondary) button. It would be nice if every button on the site follows the same color scheme. The theme decided that primary buttons should be blue and secondary buttons should be gray with 8 px margin between them and buttons should be 120 px wide. Using a framework like Bootstrap, the theme author can easily style the site consistently because basic components always apply the same classes (btn-*).

<button type="button" class="btn btn-primary">Save</button>
<button type="button" class="btn btn-secondary">Cancel</button>

Of course, the buttons will work even without styling and who cares if primary button is off by 2px margin. It only matters if we care about achieving super nice looking sites.

If the module did not follow the framework, we would have to style it ourselves hoping the module matches the look-and-feel of the current running theme. Even if we CSS scoped it (we actually do that already), it doesn't really help because we can't rely on the theme author to style every module reliably. They're not willing to do so because there are too many modules to keep up with and it's difficult to target components without a standard (e.g. it's hard to keep track of which button is primary vs secondary without CSS classes that follow a convention).

[valadas]

That was the main reasoning behind the Dnn UI/UX pattern and well, that did not live very far.

What is coming up for Dnn 10 are a set of css variables and a set of web components. The css variables will be just living there on the page and provide very basic pieces of information like primary color, controls-radius, all preferences a site admin can adjust with a UI. Then there a set of dnn styled web-components. So a developer that wants controls to be the same as the core one can do and and those will look like all the core buttons (persona bar, module settings, etc.) This is just a button but there is a whole set in the works including modals, collapsibles, etc. You can take a peak here https://github.com/eraware/dnn-elements/tree/development/src/components

Now for those developer who don't like that, they can also just consume the css-variables and write up their own styles but have access to know the primary and secondary colors as well as button rounding preferences on that site. It would look something like:

.my-module button {
   color: var(--dnn-color-primary);
   border-radius: var(--dnn-controls-radius);
}

And well, there will always be those who won't like it and and prefer a framework, the only thing I can say about that is that it is impossible to convince all themes and all modules to agree on which framework and even then when versions change, it all has to start over and themes and modules get out of sync.

[stephen-lim]

This is very nice. I think I understand more what you're trying to achieve. I didn't fully understand it the first time you mentioned it. I hope you will you be including more components like tabs, pills, table, cards, calendar, date picker, dropdown, etc. I think it needs to be extensive enough so we get the general buy-in from developers and designers.

[valadas]

Yeah, that will expand to probably include pretty much all the common stuff starting with most stuff we use in the Persona Bar but re-implemented so it does not rely on React but are standard web components.

[stale]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[sleupold]

still an issue

[stale]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[stale]

This issue has been closed automatically due to inactivity (as mentioned 14 days ago). Feel free to re-open the issue if you believe it is still relevant.