v3 theming proposal #441

prudho · 2019-01-29T09:54:59Z

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 !

The text was updated successfully, but these errors were encountered:

y0hami · 2019-01-29T10:08:21Z

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.

etshy · 2019-01-29T10:42:52Z

Nice to start discussing about that.

Here are my first thoughts about that.

In my opinion we should think about a way to build multiple theme and a way to quickly change them, like a class ui default theme on the <html> tag or something like that. All users have not the same taste and propose a quick way to have a "theme changer" plugin (or even make a little component for that) could be good. I have no idea we could do something like that for now though.
About theming itself, I'm not against the .overrides files so much. But if we remove them, and we need to make changes that are not part of a variable, how can we do that ? We could remove the css in the src/definitions and move them to the theme folder? Still with a .variables file (at the roo of the theme folder ?) to be able to quickly change global things, we could have a real different theme, where we can change everything we want ? It would copy all the files though, so surely it's not a good idea...
to make it simple to create a new theme, we could make a gulp tasks to create empty/basic files ? something like gulp create-theme *theme_name*. I don't know much about gulp and that kind of tasks, so I don't know if it's possible.
The inverted class is a good thing, but I think FUI need a proper "default dark theme" (inverted cass should still be available though). And as hammy said, having that much theme is not necessary. It can be good to show what can be done, and how to make a theme in a demo/tuto, in another repo maybe, but there is no use to have them in the src.

That's just quick thought/ideas I had after seeing this threads, I'll think more about how we could improve the theming system.

y0hami · 2019-01-29T10:55:16Z

@etshy I agree with a lot of your points. About your ui default theme suggestion on the HTML tag. This could be something we investigate since this would allow users to switch themes dynamically like you said and can also provide us with an inheritance system for some styles as discussed here #367 we could inherit the font face from the top level theme class. I do however think this should be on the body not the HTML tag and technically it could be on a single div where you want to use FUI since we could potentially make components only style when in ui ... theme class element. This would stop possible style collisions.

etshy · 2019-01-29T11:15:37Z

Maybe make another class if we want another them for a component only then, right ?

A theme should be for the entire website, and we can make a ui *theme_name* component (instead of ui *theme_name* theme) to change a component theme inside another theme ?

And I thought about putting it in the <html> because I often have to do some "positioning" CSS (like min-height or position) on the <html> AND the <body>.

y0hami · 2019-01-29T11:21:03Z

@etshy I think we will include a full copy of normalize.css in v3 which will mean you wont need to do that.

etshy · 2019-01-29T11:51:21Z

I never used normalize.css yet, but if it helps that's good to include it.

Another question, do FUI keep less ? I saw that bootstrap4 changed for less to Sass, mostly for the theming part.
I don't know exactly why though, for me they're quite equivalent.

y0hami · 2019-01-29T12:09:44Z

@etshy We (FUI team) did have a slight chat about being able to switch to SASS if these theming changes go forward 👀

y0hami · 2019-01-29T21:32:08Z

Ok so I have been messing around with a possible repository structure and have thought about this theming quite a bit so I will try and explain what I think will work or a possible starting point which we can build on.

So in v3 we are changing to a monorepo with all the components in separate packages which will make it difficult to change variables etc. Now currently SUI/FUI puts its whole src directory and dist files into your project and this is a large directory and kind of pointless if your not theming it so my first thought is why do we need to move these files in the first place? For a quick example I will show a small structure of a few components.

packages/
	core/
	site/
	button/
	card/
	dropdown/

So core/ will be all the components (basically just the current fomantic-ui package but this will not have any code for the components, all the components will be dependencies. All the other components like button/ for example will include the SASS files and any JavaScript if its a module like dropdown/ it will also include the compiled code so the CSS and bundled JavaScript. This allows you to install specific components.

Now for the theming, I think we could make a package called @fomantic/theming (possibly another name which makes more sense. Maybe something like build, forge or customize give some suggestions 😄) and this package will create the directory we are all familiar with in your project directory but it won't pull all the source code it will just make some SASS files for any components you have installed or if you have @fomantic/core it will create them all which you can then add variables to for them components. Now the @fomantic/theming package will come with a simple CLI which will have a command so you can build the distribution files. Now for example a button theme would do the following in the build process

@import '~@fomantic/button/_variables.scss'
@import 'fomantic/default/elements/button.scss'
@import '~@fomantic/button/button.scss'

The second import being the custom variables file. fomantic being the directory your theme is stored in and default being the name of your theme this gives you the ability to have multiple themes per project e.g. allows light and dark themes.

What this will essentially do is import the button variables file and then override them variables with any custom user variables and then import the button SASS code which uses them variables.

So for a simple overview this is what your project would look like

fomantic.json
node_modules/
	@fomantic/
		button/
		dropdown/
		theming/
assets/
	fomantic/
		dist/
			default/
				fomantic.min.css
				fomantic.min.js
		themes/
			default/
				elements/
					button.scss
				modules/
					dropdown.scss

The fomantic.json would specify where the themes files are and where the dist files should go on build (this file would only be created if you are using themes)

This means no more large directories with all the source code and only files for components you are theming.

Give me your thoughts and suggestions!

etshy · 2019-01-30T10:11:52Z

This seems good.

About variables files, it will be one file per component/modul only, or will we have also a global file (to choose colors, border settings or others things that could be global) ?

And these variables could still be overrides in the component/module variables file, I guess.

I like a lot the fact to keep the theme directory. With that we could make an easy way to change them by changing the url part with theme name 👍

For the @fomantic/theming package, I like the forge proposition, but I don't know is it's clear enough it's about theming. same with build, it could lead to the idea we need this package to build the dist files, and it's not to build the them but to create it and its basic folder/files.

Maybe you should include the "theme" word in it, something like @fomantic/theme-forge ?

So in your example, in assets folder we will only have the theme folders and dist files ?
The "default" files will still be in node_modules/@fomantic ?

Not thats it's really important, just a question that came.

Also what's the point of the @ in the package name ? that's not the first time I see that, but I don't know the use of that.

y0hami · 2019-01-30T10:48:35Z

@etshy I was messing around last night with a quick prototype I put together to see if this concept works in reality and it was good news 🎉

About variables files, it will be one file per component/modul only, or will we have also a global file (to choose colors, border settings or others things that could be global) ?

From making the prototype I can see that the variable files will need to be kind of how they are now so a separate file for each component so you would have a button.scss file for button variables and site.scss for site variables like fonts etc. Keep in mind you would only need the variable files for the components you are theming so lets say you have all the components installed but you want to change the border radius of your button. This would mean you only need 1 file in your themes directory which would be <PATH_TO_FUI>/themes/<THEME_NAME>/button.scss (you may have noticed there is not elements directory like I mentioned above. After some testing last night I figured that these directories aren't needed and we could potentially remove them if we wanted.)

Doing a method like this would also allow users to potentially extend custom themes so say you have the FUI default theme and you also have a theme downloaded from NPM for your button you could make your own button.scss file in your themes directory and do the following

@import "~custom-fomantic-ui-button-theme";

$borderRadius: 2em;

This would allow for "extending" of themes which is how theming is setup right now in SUI/FUI. This could be really useful for a dark theme for example. Install a dark theme from NPM and you can easily change the color to your liking.

I like a lot the fact to keep the theme directory. With that we could make an easy way to change them by changing the url part with theme name 👍

Now for changing themes easily I think we should investigate adding a ui theme class which the theming package would create if you add theming so if you use components it would be as normal like how it is now but if you installed the theming package it would scope all the classes to ui <THEME_NAME> theme so we could potentially make the dist contain all the themes you create so you could have a light and dark theme and both would be in the fomantic.css file so you just need to add ui light/dark theme to your body to change the theme.

So in your example, in assets folder we will only have the theme folders and dist files ?
The "default" files will still be in node_modules/@fomantic ?

So once theming is enabled it will create a fomantic.json file in your project root and a fomantic directory (or what ever you call it) which can be placed where you want just like the installer is now. In the fomantic directory it will have a themes directory and then in that it will have a directory named after your theme like dark or light. The theme directory will be where you variable files will be. So yes all the default theme files will still be in your node_modules directory. This is what it will look like

node_modules/
	@fomantic/
		button/
			_variables.scss
			button.scss
fomantic/
	dist/
		fomantic.min.css
	themes/
		dark/
			button.scss

Also what's the point of the @ in the package name ? that's not the first time I see that, but I don't know the use of that.

The @ defines the org scope so in v3 we are moving the packages to a NPM org so I can allow more people to publish packages and then they aren't published under my username. You can find out more via the NPM docs here

etshy · 2019-01-30T12:34:18Z

The part about extending themes and all seems very interesting. Like you said, it could allow to create theme packages and easily use theme in a theme and the scope thing could ease that too.

Now for changing themes easily I think we should investigate adding a ui theme class which the theming package would create if you add theming so if you use components it would be as normal like how it is now but if you installed the theming package it would scope all the classes to ui <THEME_NAME> theme so we could potentially make the dist contain all the themes you create so you could have a light and dark theme and both would be in the fomantic.css file so you just need to add ui light/dark theme to your body to change the theme.

Afther thinking about it, I'm not sure having multiple themes in one file is good.

Imagine a site that have like 5 or more themes, will you load the css for all the themes ?
I think it's better to have multiple folder/files for each theme, like this, you load only the selected theme files, and you can still change the url to load another theme.

y0hami · 2019-01-30T12:36:56Z

@etshy I'm sure we can add an option to the config to enable/disable the theme bundling 😉

etshy · 2019-01-30T13:17:56Z

Didn't event think about an option in the build command ...
Yeah that could be a good solution.
If you have only one or two them you can bundle them in only one file and if you have more it will generate multiple files, one for each theme, like dist/fomantic.<THEME_NAME>.min.css (no need to have a folder per theme).

y0hami · 2019-01-30T13:27:16Z

@etshy Do you not think it would get a little messy with lots of files for each theme

dist/
	components/
			button.dark.css
			button.dark.min.css
			button.light.css
			button.light.min.css
	fomantic.dark.min.css
	fomantic.dark.css
	fomantic.light.min.css
	fomantic.light.css
	fomantic.js
	fomantic.min.js

Just think for all components and multiple themes. I think they should go inside a directory like this

dist/
	dark/
		components/
			button.dark.css
			button.dark.min.css
		fomantic.dark.min.css
		fomantic.dark.css
	light/
		components/
			button.light.css
			button.light.min.css
		fomantic.light.min.css
		fomantic.light.css
	fomantic.js
	fomantic.min.js

etshy · 2019-01-30T13:50:24Z

Hmm I thought about building the whole src and theme files into one theme file.
And it ends with things like this

dist/
        fomantic.dark.min.css
        fomantic.light.min.css

You only load one of those file, as there is everything in it (global and theme CSS rules).
We could have a fomantic-core.min.css, maybe but no more.
As most of browser are limited to 6 paralel request, we shouldn't have more 2 files to load, just for css, IMO.

y0hami · 2019-01-30T13:55:04Z

@etshy We are going to keep the dist how it is now (FUI team have already discussed this) because lots of users like to include only the files they need. You might have all components because you use them all but you might only need to menu, form and grid components on a contact page so you only include those files and then your not including a large CSS file for all the components which you don't need but you might use them on other pages.

Again we could always figure out a way to customize the distribution format in the build tool.

etshy · 2019-01-30T15:24:02Z

I guess yeah.
I have the very bad habit to load all components...

To prevent having too much files to load, should we think about a way to make bundle files then?
Like in a json where you can specify a filename, an array of modules we want to bundle etc. ?

something like that

{
    "bundles" : [{
          "name" : "<BUNDLE_NAME>",
          "components" : ["menu", "label", "grid", ...]
    }, {
          ...
    }]
}

Like that we coud make "page-specific" files.
The above could generate the following

dist/
    <THEME_NAME>/
        <BUNDLE_NAME>.css
    fomantic.js

but maybe that's more a work for a bundler like webpack ? 🤔

Also about your latest dist representation, If we have a folder for the theme I don't think including the theme_name in the filename is necessary. It's a little detail, though

crewow · 2019-03-07T09:13:19Z

Whats the plan of V3 launch.

y0hami · 2019-03-07T14:37:08Z

@crewow We are still in the planning and proposal phase so there is no set date for a release right now. Depending on how large the v3 scope becomes will determine on how long it will take.

GammaGames · 2019-03-08T18:07:14Z

I was looking at other CSS frameworks a while ago I came across mini.css. One thing I thought they did really well was allowing users to set variables with --fore-color, --button-fore-color, --universal-padding in css to to their liking. It seemed more beginner friendly than requiring a user to compile the theme on their own. They even have the variables in the documentation for each component.

They also have a theme builder on their site, but that's a little more involved.

y0hami · 2019-03-12T11:37:32Z

@GammaGames That's a cool idea and I may look into that. If we decide to do this I don't think we should do it for the first release of v3 because it would add a lot to the scope.

witrin · 2019-03-18T14:04:14Z

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 ?

@prudho In fact the company I'm working for needs this three layers! Here is why:

The definition layer is the bare component. It's important that this component has to be completely independent from any specific project, so we can reuse it in such projects. Thus the main goal of this layer is re-usability! There is ONE code base and all projects just have a dependency to a specific version.
The theme layer is another possibility to re-use work. Think about a theme as reusable component you worked very hard on and you want to have only ONE code base for this component. Later on want to use a specific version of that theme in your next project because the budget is low and the customer is okay with the base look of your standard theme; in fact we use such theme for our low budget projects.
The site layer is always on the project level. It's customer specific and will be not reused BUT it needs maintenance AND it must be able to reuse/extend/modify themes.

Now let's imagine you have one standard theme and six projects which are based on that theme. After a while you find some bugs in your standard theme and all six projects are affected. If you don't have this second (theme) layer you have to fix the bugs in all of these six project-repositories repetitive. You don't want that! You wan't to fix the bug only once and update the dependencies in your (six) projects. MAYBE you have to patch some of your projects a little bit more because you did some advanced stuff with your theme but that's okay, because your customer paid for it.

But what if you WANT to make your next huge project from the scratch? You just want to 'skip' the theme layer. Well you just take a blank theme and start from that.

But without that theme layer you CAN'T reuse your work except you copy your theme again and again with all the drawbacks.

Regarding that theme.config. Yes it is a bad approach I think. We doing this with a so called .uirc for themes and sites:

{
   // extend another `.uirc`
   "extends": "lib/vendor-ui/src/.uirc",
    // the base theme to use (so you could also build a theme based on a theme)
    "theme": "default",
    // (vendor) paths to look in for themes and definitions (the most top wins)
    "paths": [
        "lib/semantic-ui/src",
        "lib/vendor-ui/src"
    ],
    // the components you want to use/override/adapt in your project/site
    "components": {
        "behaviors/load": true,
        "behaviors/breakpoint": true,
        // ...
        "globals/reset": "globals/reset": {
            // just use another theme than `default`
            "theme": "resetcss"
        },
        "globals/site": true,
        // ...
        "modules/dropdown": true,
        // ...
    },
    "libraries": {
        // use some non-semantic-ui stuff
        "js": [
            "lib/jquery/dist/jquery.js"
        ]
    },
    "variables": {
        "less": {
            // override some variables
            "buildFontPath": "'assets/fonts'",
            "buildImagePath": "'assets/images'"
        }
    },
    "output": {
        // how to name the output
        "less": "styles.css",
        "js": "scripts.js"
    }
}

The example above is only able to produce a single output so out put splitting is not possible. We don't use Gulp and I think this would be also important. Everybody should decide on it's own if he/she want's to use some thing like Gulp or not; therefore we build our own tool-chain.

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 !

I totally agree to get it more simpler and LEANER. BUT I don not agree, if I have to pasting a whole theme or a lot of code into one project after another! I think it's very important that I'm always able to reuse work WITHOUT copying it over and over again.

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 !

I agree with: no more theme.less! I agree with a CLI build tool which generates the complete layered LESS stuff. But again I do not agree, if I'm being forced to copy redundant code. The re-usability of themes must be possible!

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.

Yes you are right about the customization and to make it simple for simple use case. You might be not right about the number of 0.5 %. And I think it's important to provide a scalable product!

So let's start discuss about it, folks !

Thanks for your thoughts! 👍

EDIT: Just to be clear: What I vote for is an extreme lean project/site structure what does reuse as much as possible WITHOUT being complicated. In fact we already have such a (VanillaJS) tool chain in production but unfortunately we don't have the time to publish it and we are currently not able to split, which is an important feature I think.

hugopeek · 2019-05-04T14:03:53Z

I want to second what @witrin says here. My workflow is also relying heavily on the 3 theming layers in SUI, in a very similar way.

I maintain a base CMS install and use a theme to make sure all the output is decent enough by default. Then each install has a few options for tweaking colors, fonts, etc and adding a logo. Basically these are all small adjustments in site.variables.

Most of the time, this is good enough for small / low budget projects. And the beauty of it is that with the 'site' layer, we can quickly make changes or fix things on project level. And if it turns out to be a structural issue that affects the entire framework, we merge it into the theme.

For bigger projects, we sometimes create individual themes. Again: reusability is what it's all about. We can create coherent layouts across multiple sites, with a few variations per project but all maintained from a central theme. For a brand with different product sites for example, we mostly work on the same theme and pattern library so in the end they don't pay much more than they would for maintaining a single site. I also introduced SUI to a software developer, so he can reuse his theme across different extras created for the same platform.

Same for me personally. Before Semantic UI, I used to spend a lot of time on fiddling with CSS, but thanks to this theming structure, that has been slashed to maybe as little as 10% of what it was before. Sure, some of that time now goes to debugging stupid NPM issues and waiting for gulp build to complete (any improvements there are more than welcome), but overall it has been a giant leap forward in productivity for me. And I must say that the component.variable and component.override files also helped me there in deciding where to put the custom CSS and later in retrieving it again. It takes some getting used to, but in the end it makes sense to do this per component. Also being able (and encouraged) to use straight up CSS here instead of having to learn language- or framework-specific syntax is a big plus. This could also make a possible transition to something like native CSS variables or PostCSS more doable in the future.

So to conclude: the current theming layers are essential to me as well. I am considering to switch to the Fomantic UI fork and would love to help this project forward (as I'm painfully aware of the current state of the mothership) but simplifying the theming structure would make that impossible for me.

That's not to say there's nothing to improve on the current theming system of course! Some things are already mentioned, but from the top of my mind:

The build process should definitely be faster and less complicated. And preferably easier to hook into different tool chains, as Witrin says.
The default theme needs to be removed from the theme folder.
As for the other themes: I also question their usefulness. It's good for demo purposes, but I haven't actually used them in projects. Could be an option during installation?
A dark theme is also on my wishlist. But what I'm struggling with most, is inverted classes inside user generated elements (like Segments). If through the CMS, a user creates an element with a dark background for example, I would like to have most elements inside it behave like they had an .inverted class.. This takes too much CSS wrestling though and it would also make the stylesheet a lot bigger, so I'm currently manipulating the DOM with PHP in order to add the inverted classes in certain scenarios. Yeah, yikes! (Before it was done with Jquery btw...)
File size of the generated CSS and JS. Being able to split components from the main build helps a little, but most of the times the files are pretty beefy and it comes up for discussion in a lot of our projects. I don't know how most SUI / FUI users use the platform, but I'm mainly building website with it, so asset size is an issue there. Gzip works well and so does HTTP2, but I'm still looking for ways to improve. Some kind of critical CSS implementation for example, or removal of unused CSS. I experimented with these things a little, but it's hard to get it right. If this is something more FUI users are facing, then maybe it could be a discussion item for theming in v3?

In any case: I think care should be taken when overhauling the current theming system. Please don't judge it as messy or complicated too quickly; it might appear that way if you're mostly working on a project level, but in terms of scalability and reusability it makes a lot of sense to have these 3 layers in place. I'm pretty sure Jack Lukic has put a lot of thought into it and as you can see, there are users out there that rely on this structure ;)

In any case 2: thank you for taking the initiative to turn SUI into a community-driven project. I was very relieved when I found out about it and hope it will turn out to be a success. Thanks also to @witrin for your clearly written issue. Can go straight into the theming FAQ!

y0hami · 2019-05-04T21:17:53Z

@witrin @hugopeek Don't worry we aren't removing the 3 layer ability, I am currently prototyping this exact thing right now and I am actually trying to figure out how to implement it so you can have infinite levels of themes so theoretically you could extend a theme from another theme with the first theme extending from the default variables.

A lot of the points you both talk about I agree with and we will try our best to address them. The problems with the build system should be addressed in v3 because it should have a completely new build process which should allow for more flexibility.

hugopeek · 2019-05-09T13:19:04Z

Hi @hammy2899, I'm glad to hear that. So you're building a theme, within a theme, within a theme huh... Good luck; don't go too deep! ;)

Getting more and more warm fuzzies from this project, so I'm porting some sites over to FUI now to take it for a spin.

avickers · 2019-05-18T03:34:10Z

Don't worry we aren't removing the 3 layer ability, I am currently prototyping this exact thing right now and I am actually trying to figure out how to implement it so you can have infinite levels of themes so theoretically you could extend a theme from another theme with the first theme extending from the default variables.

Oh, Oh! I know, senpai! Constructable Style Sheets. Use JS template literals--no need for LESS/SASS. Wrap it in a JS Class and then extend infinitely.

You can apply them to shadow DOMs, so each component on a page can be using a different theme.

People might not even freak out completely at this idea... in 3 more years. :)

Call it my FUI v5 Theme proposal.

thiscantbeserious · 2019-05-28T13:19:06Z

I agree with what @witrin @hugopeek say - also coming from a perspective of architecting a reusable UI framework for my company (with an expected lifetime of about 20 years). I'm currently evaluating if we're going to implement Se/Fomantic as an abstraction layer for the look and feel exactly due the possibilities it offers in regards to theming.

The current theme engine might not be 100% satisfactionally for many people and requires breaking your head around it a bit, especially if you're not familiar with the idea of abstraction in itself but Semantic is about the only one do do it even halfwhat correct (to my knowdlege, correct me if I'm wrong).

It's a standalone feature that attracts those that know how to use it. I would be very careful in how you "rework" it, also in conjuction with Gulp and the whole build process.

There are a plethora of "UI Frameworks" like Materialize that have their own - very specific - look embedded within their body that are as "lean" and "flexible" as a brick.

If you want a "simple" thing, I wouldn't reinvent the wheel by breaking another one in the process.

I also disagree with the suggestion by @avickers - mixing Stylesheets and Javascript for layout purposes is just a mess. Languages like LESS/SASS were invented for very good reasons. Javascript in itself is already a mess (yes even with all the advancements it has made in the last 4 years) - and can change in any minute and completely break your layout (Google is very good with that nowadays, I mean breaking stuff globally - just ask Mozialla employees).

Adjusting to that with a transpiled language like LESS/SASS is way easier to be done than manual hacks like JS template literals for the "feel of leanness" and "reduced complexity".

With LESS/SASS you just update the transpiler - (maybe adjust your build-script) - retranspile - done.

bborn · 2020-01-24T13:43:19Z

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.

prudho added type/discussion Anything which is up for discussion type/build Anything related to the build process tag/platform Anything relating to the Fomantic platform as a whole tag/v3 Any issues which include ideas/proposals for v3 labels Jan 29, 2019

y0hami changed the title ~~About theming...~~ v3 theming proposal Jan 29, 2019

y0hami pinned this issue Jan 29, 2019

y0hami mentioned this issue Feb 1, 2019

The future of Fomantic as v3.0 #319

Closed

y0hami mentioned this issue Mar 7, 2019

Upgrade to less-rails 4 Semantic-Org/Semantic-UI-Rails-LESS#49

Merged

y0hami unpinned this issue Aug 28, 2019

lubber-de mentioned this issue Oct 29, 2020

Dark Mode #1424

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

v3 theming proposal #441

v3 theming proposal #441

prudho commented Jan 29, 2019

y0hami commented Jan 29, 2019

etshy commented Jan 29, 2019 •

edited

Loading

y0hami commented Jan 29, 2019

etshy commented Jan 29, 2019

y0hami commented Jan 29, 2019

etshy commented Jan 29, 2019

y0hami commented Jan 29, 2019

y0hami commented Jan 29, 2019

etshy commented Jan 30, 2019

y0hami commented Jan 30, 2019

etshy commented Jan 30, 2019

y0hami commented Jan 30, 2019

etshy commented Jan 30, 2019

y0hami commented Jan 30, 2019

etshy commented Jan 30, 2019 •

edited

Loading

y0hami commented Jan 30, 2019

etshy commented Jan 30, 2019

crewow commented Mar 7, 2019

y0hami commented Mar 7, 2019

GammaGames commented Mar 8, 2019

y0hami commented Mar 12, 2019

witrin commented Mar 18, 2019 •

edited

Loading

The actual state...

The future state of theming...

Final notes

hugopeek commented May 4, 2019

y0hami commented May 4, 2019

hugopeek commented May 9, 2019

avickers commented May 18, 2019

thiscantbeserious commented May 28, 2019 •

edited

Loading

bborn commented Jan 24, 2020

v3 theming proposal #441

v3 theming proposal #441

Comments

prudho commented Jan 29, 2019

About theming...

The actual state...

The future state of theming...

Final notes

y0hami commented Jan 29, 2019

etshy commented Jan 29, 2019 • edited Loading

y0hami commented Jan 29, 2019

etshy commented Jan 29, 2019

y0hami commented Jan 29, 2019

etshy commented Jan 29, 2019

y0hami commented Jan 29, 2019

y0hami commented Jan 29, 2019

etshy commented Jan 30, 2019

y0hami commented Jan 30, 2019

etshy commented Jan 30, 2019

y0hami commented Jan 30, 2019

etshy commented Jan 30, 2019

y0hami commented Jan 30, 2019

etshy commented Jan 30, 2019 • edited Loading

y0hami commented Jan 30, 2019

etshy commented Jan 30, 2019

crewow commented Mar 7, 2019

y0hami commented Mar 7, 2019

GammaGames commented Mar 8, 2019

y0hami commented Mar 12, 2019

witrin commented Mar 18, 2019 • edited Loading

The actual state...

The future state of theming...

Final notes

hugopeek commented May 4, 2019

y0hami commented May 4, 2019

hugopeek commented May 9, 2019

avickers commented May 18, 2019

thiscantbeserious commented May 28, 2019 • edited Loading

bborn commented Jan 24, 2020

etshy commented Jan 29, 2019 •

edited

Loading

etshy commented Jan 30, 2019 •

edited

Loading

witrin commented Mar 18, 2019 •

edited

Loading

thiscantbeserious commented May 28, 2019 •

edited

Loading