Guidelines for where to put CSS


#1

when creating a site, I tend to just put my CSS all in site/globals/site.overrides such as

.ui.centered.leaderboard.ad {
 margin-bottom: 3em;
 margin-top: 3em;
}

h2.ui.center.aligned.dividing.header {
 letter-spacing: 0.1em;
}

.extra.content a {
 display: inherit;
 text-overflow: ellipsis;
 white-space: nowrap;
 overflow: hidden;
}

.description {
 font-size: 1.1em;
}

.ui.card .image, .ui.cards .ui.card .image {
 background-color: #ffffff ;
}

.ui.inverted.vertical.footer.segment {
 background-color: #545454 ;
 margin-top: 4em;
 padding: 2em 0em;
}

but I see I could also put the .ui.card types in the card element overrides, and the header overrides in site/element/header.overrides

how to decide where to put my styles? or does it really matter at all?

Cheers!


Custom css best practice
#2

When I’m working on a SUI site I tend to try to keep my component specific code in the overrides for that component

I’d also try to keep the CSS to be scoped to the component.

For example if I was adding a new section in card that modified description I’d add this to my site/views/card.overrides

.ui.cards > .card .description,
.ui.card .description {
 font-size: 1.1em;
}

#3

OK this last site I did was pretty simply so .description worked, but I can see how my approach is too shotgun as the site develops and more components come into play.

here’s the page I made:

built in just a few hours yesterday, but works very well across all devices. I love working with Semantic-UI, especially using WebStorm’s Live Edit tools! used to take much much longer to do this kind of stuff!

Thanks!


#4

That’s also our approach.

In addition to that, we also scope component-sepcific CSS, if it should only apply to certain - and not all - screen areas, e.g. (re-using Jack’s code above)

.leftContent
    .ui.cards > .card .description,
    .ui.card .description {
        font-size: 1.1em;
    }
}

#5

in that case so you still put it in site/card.overrides even though it’s not a site-wide mod?

i like to put an id on body and target that for page specific stuff

<body id="mailbox">

CSS

#mailbox h2.ui.center.aligned.dividing.header {
 letter-spacing: 0.1em;
}

but yeah, depends how specifically you want to target something.

We are starting to build Semantic-UI components in React, so we add the component name as an id on the outer most div, then use it to write component specific overrides.

<div id="login" className="ui middle aligned center aligned grid">
   <div className="column">
      <h2 className="ui teal image header">
        <img src="./img/logo.png" className="image"/>
        <div className="content">
          Log-in to your account
        </div>
      </h2>...
#login .column {
  max-width: 450px;
}
#login .ui.message.warning, #login .ui.message.error {
  text-align: left;
}

So same thing as you are saying, but I often just put it all in site.overrides because I feel like it’s less spread out. I feel like overrides for an element like header should only be for site wide changes, not page or section specific changes. You guys feel ALL element overrides should be in the element specific files?

The problem is doubly compounded in my case, because I’m making both a new theme and a new site at the same time. So often asking myself where is the best place for my overrides. Sometimes I have a hard time deciding if my change should be for my theme in general or just for this site specifically!


#6

Max,

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:

.navMenu {
    .ui.menu {
        <...>
    }
}


.headerMenu {
    .ui.menu {
        <...>
    }
}


.pageContentMenu {
    .ui.menu {
        <...>
    }
}

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…

Kind regards,
Sascha.


#7

thanks @Windwalker and @jlukic

I’ll follow suit and reorganize to keep overrides more local.