LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Context and Problem Statement
  • Decision Drivers
  • Considered Options
  • Decision Outcome
  • Positive Consequences
  • Negative Consequences
  • Pros and Cons of other Options
  • CSS Modules with SASS/PostCSS
  • Styled Components

Was this helpful?

  1. Technical overview
  2. Architectural Decision Records

CSS

PreviousContinuous IntegrationNextBranching and Release Strategy

Last updated 2 years ago

Was this helpful?

  • Status: accepted

  • Deciders: devs

  • Date: 2020-05-26

Context and Problem Statement

We're building websites and web applications that share a common design system with reusable components. How do we write CSS styles in a way that is performant and safe?

Decision Drivers

  • Should be performant, with code splitting, caching and minimal runtime overhead.

  • Needs to have easy access to our design system constants. These should optimally be shared with JS logic.

  • Should be type-safe to catch issues when refactoring.

  • Reusable components should be closed, not accepting arbitrary styles/classes.

  • We want a pattern for responsive props with atomic layout components.

Considered Options

  • with /

Decision Outcome

Chosen option: Treat, because it combines the best of both worlds from CSS-in-JS and CSS modules.

We'll create shared components that have responsive props, but are otherwise closed for modifications. Theme variables are defined in a shared library with TypeScript.

Example:

// Good:
<Box padding"small" />
<Box padding={{xs: 'small', md: 'medium'}} />
<Input large />
<Text preset="heading3" as="p" />
// Bad:
<Box className={customLayout} />
<Input style={{ height: 50, padding: 16 }} />
<Text className={styles.heading} />

Positive Consequences

  • Treat is statically extracted at build time, so it has minimal runtime.

  • Styles load in parallel with JS, also when code splitting.

  • Styles are written in TypeScript which gives us type safety when referring to shared variables, styles and helpers.

  • Styles are in special files, separate from markup and components giving us clear separation with good visibility into the rendered markup.

  • We can pull in responsive layout component patterns from Braid, which gives us a good base to lay out components and pages.

Negative Consequences

  • We are choosing a pretty new framework, so it may 1) have bugs or issues, 2) be an obstacle for new developers or 3) be discontinued.

  • When we're generating responsive styles at build time we need to be mindful at how many variations we allow (eg media queries, columns, whitespace), since they can easily bloat our CSS with unused styles.

Pros and Cons of other Options

CSS Modules with SASS/PostCSS

  • Good, because it builds on top of standard CSS syntax which everyone knows.

  • Good, because it has no runtime.

  • Good, because it is separate from markup.

  • Bad, because it is messy to generate advanced styles in a CSS-based language.

  • Bad, because it's not type safe.

Styled Components

  • Good, because it's the industry leader in CSS-in-JS.

  • Good, because it allows rendering pages with no redundant styles.

  • Good, because it has excellent developer experience, making it easy to implement dynamic styles based on theme/props.

  • Bad, because it's runtime may significantly affect site performance.

  • Bad, because it hides the markup which may cause accessibility issues.

CSS Modules
SASS
PostCSS
Styled Components
Treat