What CSS methodology should we use at dev.to?

The CSS for dev.to is fairly wild-west right now. It's mostly scaled by way of isolating parts, meaning more copying and pasting and relying on SCSS nesting, less re-usability and few true rules.

I'm wondering if there are any CSS methodologies or strict rule sets you've used that you like. I'm familiar with BEM and would lean towards that from what I know, but I'm looking for some input to bring to the team.

Comments

[Ahmad Awais ⚡️]

Sass with scss. BEM. That's it.

[Dan]

As a previous Chemistry nerd haha I am truly a fan of Atomic Design for UI in General :)

['''⌐(ಠ۾ಠ)¬''']

I've been learning styled-components after listening Wes Bos' Syntax podcast on the topic and a friend suggesting a look-see at them. So far, I'm really liking it. But I'm very much one for "keep everything together and easy to find", which is a selling point: the styles for the component are right there if you need to refactor/remove something.

['''⌐(ಠ۾ಠ)¬''']

Or, go the other route and try vanilla-css.com

[Geoff Davis]

You should take the CSS-in-JS approach and just use random alphanumeric strings to represent styled elements/components.

[Charles D. Villard]

One of the easier naming conventions I've found is rscss.

[Gage]

I love Tachyons (CSS library). It basically means that you almost never have to write custom CSS. Once you've started to get used to it it's so much faster. Not only that but it solves the CSS scoping issue in plain CSS which means it doesn't matter which framework you use. It's based on a design system so I makes it easy to make everything feel very cohesive. It's also trivial to make responsive websites with it. I've used it for many if my personal and work projects and have nothing but good things to say about it.

Sorry, just a bit of a fan.

[Dazz Knowles]

We like to follow the Trello CSS guide as we find that helps maintain some discipline on our larger systems.

[Doug R. Thomas, Esq.]

I would look at the underlying stuff -- make the pattern library first then implement the pattern library with whatever makes sense for size and scope.

[Theofanis Despoudis]

I like a combination of custom styles with less.js and styled components.

[Valentin Silvestre]

ITCSS at it's finest ! medium.com/dev-notes/just-do-itcss...

[rouzbeh]

I really like cssguidelin.es/ and the 7-1 file structure from sass-guidelin.es/ or some variation of it like smaccs. CSS guidelines is a pretty robust read but I love that it also drops tidbits of things I didn’t know just by explaining why some ‘rules’ exist at all. Both of these are from people I’ve followed and trusted for ages now so I may have a bit of selection bias haha

[Valentin Silvestre]

I've seen a post about a css pyramid coding rules.
It was 9 css files, applied one by one, from the most general to the most specific. I try to find the article ..

[Marco Alka]

@ben

Don't go for hype-driven development!

Use stable architecture! Stay clear of frameworks, preprocessors and build steps. CSS is all you need! Base it for example on Herry's BEMIT and ITCSS. In addition, use very small and simple rules, meaning mainly one class you select (without nesting).

BEMIT is a naming convention, which makes sure that you can get a lot of info from the class name alone: How many elements are affected? Which role does it play? Where on the site can I find it? For example c-menu__logo--small@mq-mobile is a class name, which affects one element, located in the menu, which is a logo and makes the standard representation smaller in size. Additionally, it will only affect the mobile media-query.

ITCSS is basically establishing layers of specificity (ranging from generic to specific), which makes sure you override rules in a sane manner. Harry uses the layers Settings, Tools, Generic, Elements, Objects, Components, Utilities in that order, but you can of course define your own!

On top of that, factor-in theming from the start. I already wrote an explanation, so I'll just copy that here:

1. I assign a "root" theme class to the body element, like t--light
2. Then, every element with a theme (even if only one theme is planned) will get a t- (theme) CSS class. For example t-menu__item--active
3. To make it work, I prefix the CSS selectors with the root theme class. If I want to add a new theme, all I have to do is copy all theme related CSS classes, change the prefixed CSS theme class and do the actual theming
4. Switching the theme is as easy as removing and adding a CSS class in the body tag (either on the server or the client side).

>>> Full Example

---

Using the above techniques allows you to very easily

• maintain your site without fear, even after years with a completely different team
• have self-explanatory CSS (you always want that for source code, why not for CSS?)
• enable theming (dark mode ftw)
• build a responsive layout easily (but please do it device-agnostic!)

[Geoff Davis]

Yeah, I like this approach as well. I use a modified/simpler system of BEM/ITCSS, namely:

.some-class.some-class--modifier
  .some-class_child

Structured like so:

sass/
  components/
  pages/
  parts/
  vendor/
  index.sass

[Arden de Raaij]

Couldn't agree more! I think my favourite ways to write css are based on BEM(IT) and SMACSS. Thanks for t he great comment.

[Ben Halpern]

Hehe, you don't have to tell me about avoiding the hype. We probably have the least hypey approach I can think of. 😄

Thanks a lot for the tips. Will definitely take into consideration.

[Darío Kondratiuk]

When full stack developers, a.k.a. Devs who doesn’t care much about style but need to keep the site in a decent shape, where in charge we followed the Trello guide gist.github.com/bobbygrace/9e961e8...

Now we have front end devs using Atomic design, but we keep the js- rule to id classes that are not use for styling but for JavaScript.

[Daniel Tal Or]

I'm a huge fan of SCSS + BEM, with the component-driven architecture of BEM complementing the component-driven architecture of React. I usually give each component its own small stylesheet and @include it in a main stylesheet. I have found that this gives me the most flexibility, readability, and re-usability of anything I've seen.

[Jim O'Brien]

I've had great results with a similar setup, (also a React app), although with two differences:

• Rather than @include in a core stylesheet, I tend to import the stylesheet directly in the component's JS source, using webpack loaders to handle this. This allows for slightly better build performance when developing, especially when using Storybook or similar, as well as not having a huge list of stylesheet imports in one place.
• I also like to use CSS modules in some projects, as this makes naming collisions impossible, allowing scoping without any cognitive overhead.

[Dan]

One great thing baked into Angular: CSS scopes! I am a fan of Atomic Design :)