# SCSS - Code Guidelines | Ocelot.Social Documentation
Ocelot.Social Documentation

Skip to main content

- Introduction
- Neo4J

- Backend

  - GraphQL
  - neo4j-graphql-js

- Webapp (Frontend)

  - Components
  - HTML
  - SCSS
  - Vue

- Testing Guide

  - End-to-end Tests
  - Webapp (Frontend) Tests
  - Backend Tests
- Deployment
- Contributing
- Feature Specification
- Code of Conduct
- Documentation
- License

# SCSS - Code Guidelines

April 5, 2026
About 2 min

On This Page

- We use classes over tags and ids
- We use design tokens instead of magic numbers
- We name our classes after components
- We use variants instead of overriding styles
- We style within the component, we position when we use it
- Recommended reads

# SCSS - Code Guidelines

## We use classes over tags and ids

Never apply styles to `tags` or `ids` – use `classes` instead!

Why?

- HTML tags are responsible for the document structure, not the looks
- targeting HTML tags comes with performance issues
- ids are responsible for identifying a unique element, not for styling it
- ids have higher specificity than classes and therefore don't play well together
- classes can be combined and reused while ids are unique

For more background see the following articles on why not to style tags and why not to style ids.

## We use design tokens instead of magic numbers

In order to achieve a consistent look and feel we use a set of pre-defined `design tokens` to style our components, for example `colors`, `sizes` and `box-shadows`. These tokens are stored as `SCSS variables` and reused throughout the app.

So, instead of typing pixel values or hex codes make sure you use design tokens such as `height-header` or `color-input-border`.

## We name our classes after components

Our SCSS styles live within the corresponding component (see the Vue.js docs for single-file components for reference) and should therefore carry the same unique name.

Why?

- it clearly ties the styles to the one component
- having unique class names means styles will not be accidentally overwritten in other files
- we can avoid using `scoped CSS` which comes with performance caveats

## We use variants instead of overriding styles

Components will sometimes need to look different depending on the context in which they are used – a button might for example be `green` when it represents a call to action and `red` when it triggers a destructive action. Rather than making the `rounded-button` component `green` by default and then overriding the `color` for, say, the `delete-account` action – use variants! Pass the `rounded-button` a prop, such as `color: danger`, and then apply the respective `variant class`.

Name variant classes with a dash prefix, such as `-danger`, then target them like this:

    .rounded-button {
      /* other css styles */

      &.-danger {
        color: $color-danger;
      }
    }

## We style within the component, we position when we use it

In order to make components truly reusable it is important to limit their styles to, well, their actual styling. What color are they, how big is the text, what happens on `hover`, do they have a rounded border – all that is part of it.

Margins, alignment and positioning on the other hand need to be defined in the parent because the same component might sometimes be aligned to the left, sometimes to the right and sometimes float above other content. For more details see the rscss guidelines.

To do that, use the `child selector`, like this:

    .login-form {
      /* other css styles */

      > .rounded-button {
        margin: $margin-small;
        justify-self: flex-end;
      }
    }

A special case are dimensions like `width` and `height`. If it is important that a component always has the same dimensions (the height of a button should be consistent, for example) define it within the component itself, if a component should have flexible dimensions (a card, for example, could stretch over the whole screen in one place and be limited to a certain width in another) define the dimensions in the parent.

## Recommended reads

For a deeper dive into the WHY and HOW have a look at the following resources which the above guidelines are based on:

- rscss – reasonable system for css stylesheet structure
- itcss – inverted triangle architecture for css