v3 theming proposal

About theming…

I have opened this issue to talk about the actual state of theming, and how, in my opinion, we could improve it and simplify it at the same time.

The actual state…

… is a mess. The user have to define a theme.config file, then he can choose which pre-defined theme apply for each component, and to finish, he can edit .variable and .override files to fine-tune his site theme…

I mean, who find that usefull and/or intuitive ? Who really want to use different theme for one component to another ? And what’s the purpose of this override stuff ?

The future state of theming…

… needs to be more simple. FUI has only one “official” default theme which is located in /src/theme. If a user want to edit his website theme, he just have to edit the variable files stored in /src/site then build the CSS. If he wants to apply a theme, I think that he just have to paste a theme package to his /src/site folder then rebuild… That’s it !

No more theme.less file. No more useless .override files ! And creating a theme-generator would be more simple too: you generate your theme package trough the generator, download it and paste it down in your site folder, and you’re done !

Final notes

Like I already said, it’s just my own opinion and vision… Maybe some users needs more customization options in their build system, but I don’t think that this user base represent more than 0.5% of total FUI users.

So let’s start discuss about it, folks !

[hammy2899]

I agree theming is a huge topic which needs to be addressed in v3. I know how the theming works and yet I still make “hacky” changes to get custom themes to work because it easier.

I think your suggestion of making a central directory is something we should look into. Currently SUI/FUI provide 23 different themes (including default) which is madness and especially when they don’t even get updates so maybe in v3 we drop all these and just support one theme in the core library.

[bborn]

Just chiming in with my support, also, for the 3-layer system that currently exist (as @thiscantbeserious @hugopeek and @witrin said). I don’t think it’s overly complicated. Variable overrides go in .variables, hard css customizations go in .overrides. There’s room for improvement in the way some of the components are built (and documenting the variables somewhere), but overall I think it works.