here’s a little explanation on what I’m working on: In my company, we’re building a web framework for business application and company informational content, for something we call “the digital workplace”. So we’ve quite a lot of styles, this framework depends on. Not all of these styles can be covered by Semantic UI, there’s quite a bit which isn’t related to Semantic UI.
We also separated this portion into several module imports, similar, but not quite as sophisticated, as sUI does. But it allows us building individual themes for customer demands, using a Less build, just like in sUI.
The second part is everything, which is covered by sUI componentes: Menus, Accordion, Buttons, Image, and many more.
My example from the last post a bit more precise: In fact we have 3 sUI Menus on our framework page: One for the navigation left off-canvas, one icon menu in the header and one icon menu for content related functions (sharing, printing, help, contact person), located right off-canvas.
Each of these sUI menu has some pecularities, so we use classes/IDs of each menu’s outermost DOM element, to differentiate these pecularities from each other, like this:
These additional styles are kept in
menu.overrides, since it’s sUI-specific AND menu-specific.
We follow this approach for all other Semantic UI component customization, accordion, card, image, etc…
Thus we keep as much modularization as possible and in theory, it allows us to tear apart our sUI theme by its components.
On the other hand,
site.overrides only bears global sUI customizations, like e.g. individual font stuff, and remains relatively short.
I hope this explanation helps you deciding, where to put your overrides…