Human Connection
1.0.0
1.0.0
  • Introduction
  • Edit this Documentation
  • Installation
  • Neo4J
  • Backend
    • GraphQL
    • neo4j-graphql-js
  • Webapp
    • Components
    • HTML
    • SCSS
    • Vue
  • Testing Guide
    • End-to-end tests
    • Frontend tests
    • Backend tests
  • Contributing
  • Kubernetes Deployment
    • Minikube
    • Digital Ocean
      • Kubernetes Dashboard
      • HTTPS
    • Human Connection
      • Error Reporting
      • Mailserver
      • Maintenance
    • Volumes
      • Neo4J Offline-Backups
      • Neo4J Online-Backups
      • Volume Snapshots
      • Reclaim Policy
      • Velero
    • Metrics
    • Legacy Migration
  • Feature Specification
  • Code of conduct
  • License
Powered by GitBook
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

Was this helpful?

  1. Webapp

SCSS

PreviousHTMLNextVue

Last updated 5 years ago

Was this helpful?

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 and .

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 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 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.

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:

we can avoid using scoped CSS which

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 .

why not to style tags
why not to style ids
Vue.js docs for single-file components
comes with performance caveats
rscss guidelines
rscss – reasonable system for css stylesheet structure
itcss – inverted triangle architecture for css