CSS, Responsive Design and Design Systems

Introduction and Context

Cascading Style Sheets (CSS) is the presentation language of the Web. While HTML expresses document structure and meaning, CSS controls visual appearance, spatial relationships, interaction states, animation, and adaptation to different devices and user preferences. At postgraduate level, CSS should be understood not merely as a collection of properties, but as a rule-processing system and a design technology that influences accessibility, performance, maintainability, and organisational consistency.

Modern interfaces are delivered across phones, tablets, desktops, televisions, embedded displays, and assistive technologies. Users may also request reduced motion, increased contrast, larger text, or dark colour schemes. Consequently, effective front-end engineering requires more than making a page visually attractive at one viewport width. It requires systematic decisions about constraints, components, design tokens, responsive behaviour, and long-term change.

This chapter examines the CSS cascade, specificity and inheritance; layout models; responsive and adaptive design; animation; preprocessors and utility frameworks; component styling; and design systems. It also considers governance, accessibility, performance, and the role of AI-assisted development.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain how the CSS cascade, origins, layers, specificity, inheritance, and source order determine computed styles.

2. Select and justify appropriate layout models, including normal flow, Flexbox, Grid, positioning, and container queries.

3. Design responsive and adaptive interfaces using fluid constraints, media queries, and progressive enhancement.

4. Create accessible and performant transitions and animations.

5. Compare preprocessors, utility-first CSS, CSS Modules, and component-oriented styling approaches.

6. Define and apply design tokens and establish a maintainable design system.

7. Critically evaluate CSS architecture, governance, tooling, and AI-assisted CSS generation.

1. CSS as a Rule-Processing System

A browser transforms HTML and CSS into a rendered image through several conceptual stages: parsing, construction of a document and style structure, calculation of styles, layout, painting, and compositing. CSS does not directly specify every pixel. Instead, it supplies constraints and relationships from which the browser computes a result.

A declaration consists of a property and a value, for example:

```css

.card {

padding: 1rem;

color: #202124;

}

```

A rule consists of a selector and a declaration block. Selectors identify elements; declarations provide possible values. When multiple declarations target the same property, the browser resolves their conflict through the cascade.

1.1 The cascade

The cascade is commonly analysed using four questions:

• Origin and importance: Does the declaration come from the user-agent stylesheet, the author stylesheet, or the user stylesheet? Is it marked `!important`?
• Cascade layer: If layers are used, which layer has precedence?
• Specificity: How strongly does the selector identify the element?
• Source order: If the preceding criteria are equal, which declaration occurs later?

Normal author declarations generally override normal user-agent declarations. Important declarations reverse some of the normal origin ordering because user preferences and critical accessibility rules must be able to prevail. The exact cascade also includes transitions and animations, which occupy special precedence positions. Therefore, `!important` should not be treated as a routine conflict-resolution mechanism; it can make future maintenance harder and can interfere with user accessibility preferences.

Cascade layers provide an explicit ordering mechanism:

```css

@layer reset, base, components, utilities;

@layer base {

body { margin: 0; font-family: system-ui, sans-serif; }

}

@layer components {

.button { border-radius: 0.5rem; }

}

```

The layer order can make a low-specificity utility reliably override a component rule without requiring increasingly complex selectors. Layers are particularly useful when integrating third-party CSS, although the layer strategy must be documented.

1.2 Specificity

Specificity is a comparison mechanism, not a measure of visual importance. A useful conceptual representation is a tuple `(a, b, c, d)`, where `a` represents inline styles, `b` IDs, `c` classes, attributes and pseudo-classes, and `d` type selectors and pseudo-elements. The tuples are compared lexicographically: the first unequal component determines the winner. This is a comparison model rather than a universal numerical formula; selector-specific exceptions and pseudo-class rules must be considered according to the CSS specification.

For example:

```css

p { color: black; } / type selector /

.notice { color: blue; } / class selector /

#warning { color: red; } / ID selector /

```

For an element `<p id="warning" class="notice">`, the ID selector outranks the class and type selectors for `color`. However, high specificity creates coupling. A component styled with deeply nested selectors becomes difficult to customise. Prefer low, predictable specificity and use classes, layers, and component boundaries rather than selector escalation.

The pseudo-class `:where()` contributes zero specificity, whereas `:is()` adopts the specificity of its most specific argument. This distinction enables carefully controlled APIs:

```css

:where(.prose h2) { margin-block: 2rem 0.75rem; }

```

1.3 Inheritance, initial values, and computed values

Some properties inherit automatically, such as `color` and `font-family`; others, such as `margin`, `padding`, and `border`, do not. Inheritance passes a value from an ancestor to a descendant when the property permits it or when `inherit` is explicitly specified.

CSS-wide keywords are useful in reasoning about values:

• `initial` selects the property’s initial value.
• `inherit` takes the parent’s computed value.
• `unset` acts as `inherit` for inheriting properties and as `initial` otherwise.
• `revert` returns to an earlier cascade origin or user-agent behaviour.
• `revert-layer` returns to a previous cascade layer.

The distinction between specified, computed, used, and actual values matters in advanced debugging. For instance, a percentage height may remain unresolved until the containing block has a definite height, while a relative length such as `rem` is resolved using the root font size.

2. The Box Model and Layout Models

Every element is represented conceptually by a box containing content, padding, border, and margin. With the default `content-box` model, declared width applies to the content area. With `border-box`, declared width includes content, padding, and border:

```css

, ::before, *::after {

box-sizing: border-box;

}

```

This convention makes component dimensions more predictable. Box sizing does not eliminate layout constraints: content may still overflow if it cannot wrap or if minimum sizes are imposed by descendants.

2.1 Normal flow

Normal flow is the browser’s default layout model. Block boxes are arranged vertically, while inline content participates in line boxes. Normal flow is robust because content changes naturally alter surrounding layout. Developers should preserve flow whenever possible rather than positioning every element manually.

Margins can collapse between some block boxes. Padding and borders do not collapse in the same manner. Understanding margin collapse prevents erroneous attempts to solve spacing problems with arbitrary positioning or negative margins.

2.2 Flexbox

Flexbox is a one-dimensional layout system. It distributes items along a main axis and aligns them along a cross axis.

```css

.toolbar {

display: flex;

flex-wrap: wrap;

gap: 0.75rem;

align-items: center;

justify-content: space-between;

}

```

Important concepts include the flex container, flex items, main and cross axes, available free space, `flex-basis`, `flex-grow`, `flex-shrink`, and the automatic minimum size of flex items. The declaration `flex: 1` is commonly interpreted as `flex: 1 1 0%` in browser implementations, causing items to share available space from a zero basis. Explicit values are preferable where intrinsic sizes matter.

A frequent problem is text refusing to shrink because a flex item has a content-based minimum size. `min-width: 0` can allow the item to shrink and wrap:

```css

.sidebar-layout__main {

min-width: 0;

}

```

2.3 Grid

CSS Grid is a two-dimensional layout system. It defines rows and columns and places items into a grid or allows automatic placement.

```css

.gallery {

display: grid;

grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));

gap: 1rem;

}

```

`minmax()` specifies a lower and upper track size. `auto-fit` collapses empty tracks, allowing existing cards to expand; `auto-fill` preserves the conceptual tracks and can leave empty space. Grid is appropriate when relationships in both dimensions matter, while Flexbox is generally more natural for a single row, column, or component control group.

Subgrid permits a nested grid to use tracks defined by its parent. This is useful for cards whose headings, content, and actions must align across a row, although browser support and component complexity should be considered in production decisions.

2.4 Positioning and stacking

`relative` establishes a positioning context without removing an element from normal flow. `absolute` removes the element from normal flow and positions it relative to a containing block. `fixed` is generally positioned relative to the viewport, while `sticky` behaves like a relatively positioned element until a threshold is reached during scrolling.

Stacking is not determined by `z-index` alone. Stacking contexts may be created by positioned elements with a non-auto `z-index`, transforms, opacity less than one, certain containment values, and other features. A child cannot escape its ancestor’s stacking context merely by receiving a larger `z-index`. A documented layering scale, such as base, dropdown, modal, and notification layers, is safer than arbitrary values such as `z-index: 999999`.

3. Responsive and Adaptive Design

Responsive design allows an interface to adjust continuously or at defined thresholds to its environment. Relevant variables include viewport width, available container width, pointer precision, input modality, pixel density, orientation, and user preferences. Adaptive design generally selects among more discrete layouts or experiences, often using device or capability categories. The distinction is conceptual rather than absolute: a modern system may combine fluid responsive layout with adaptive content and interaction decisions.

3.1 Mobile-first constraints

A mobile-first stylesheet begins with a simple, narrow layout and adds capabilities as space and capability increase:

```css

.navigation {

display: grid;

gap: 0.5rem;

}

@media (min-width: 48rem) {

.navigation {

grid-template-columns: auto 1fr auto;

align-items: center;

}

}

```

Breakpoints should follow content failure rather than popular device labels. If a navigation row becomes unreadable at 43rem, that observation is more meaningful than calling 48rem a tablet breakpoint. Container queries improve component portability by allowing a component to respond to its own available space:

```css

.card-list {

container-type: inline-size;

}

@container (min-width: 35rem) {

.card {

grid-template-columns: 8rem 1fr;

}

}

```

3.2 Fluid sizing and intrinsic design

Functions such as `min()`, `max()`, and `clamp()` express constraints without excessive breakpoints:

```css

.page-title {

font-size: clamp(2rem, 1.4rem + 2vw, 4rem);

}

```

The first argument is the minimum, the second is the preferred fluid expression, and the third is the maximum. The value remains within the stated bounds, assuming valid units and a normal computed context. Fluid typography must still meet readability and zoom requirements; a visually elegant formula is not a substitute for accessibility testing.

Responsive images should use appropriate intrinsic dimensions and, where suitable, `srcset`, `sizes`, and modern formats. CSS should not be used to download a large image and merely hide it on small screens. Content hierarchy should remain meaningful when styles fail or when a user uses assistive technology.

3.3 Media features and user preferences

Media queries can respond to preferences and capabilities:

```css

@media (prefers-reduced-motion: reduce) {

, ::before, *::after {

animation-duration: 0.01ms !important;

animation-iteration-count: 1 !important;

scroll-behavior: auto !important;

}

}

```

Reduced motion does not mean all movement must be eliminated in every context; it means unnecessary motion should be reduced and essential state changes should remain understandable. Other relevant features include `prefers-color-scheme`, `forced-colors`, `hover`, `pointer`, and `prefers-contrast` where supported.

4. Animation, Transition, and Performance

A transition interpolates a property when its value changes. An animation uses keyframes and may repeat independently of a direct state change.

```css

.button {

transition: background-color 160ms ease, transform 160ms ease;

}

.button:hover {

transform: translateY(-1px);

}

```

Good animation communicates causality, hierarchy, and feedback. It should not disguise slow operations or create distraction. Prefer animating `transform` and `opacity`, which can often be handled efficiently by compositing, rather than repeatedly changing layout-affecting properties such as `width`, `top`, or `margin`. This is a performance heuristic, not a guarantee: excessive layers, large surfaces, and device limitations can still cause expensive rendering.

Focus indicators must not be removed merely to achieve a visual style. A component must expose hover, focus, active, disabled, loading, and error states where applicable. Keyboard focus and reduced-motion behaviour should be tested independently of pointer interaction.

5. CSS Architecture and Styling Strategies

5.1 Preprocessors

Sass and similar preprocessors provide variables, nesting, mixins, functions, and compilation. They can improve authoring productivity, but native CSS now provides custom properties, nesting in modern implementations, layers, and powerful functions. Preprocessor variables are resolved during compilation; custom properties remain available at runtime and can be changed by themes or component states.

Over-nesting is a common Sass failure. Deeply nested output increases specificity and coupling. Mixins can also duplicate CSS and increase payload size. Use abstractions when they express a stable design concept, not merely because repetition exists once.

5.2 Custom properties and component styling

Custom properties support semantic configuration:

```css

:root {

--color-surface: #ffffff;

--color-text: #1f2937;

--space-3: 0.75rem;

}

.panel {

background: var(--color-surface);

color: var(--color-text);

padding: var(--space-3);

}

```

They inherit by default and can be scoped. The `@property` rule can define syntax, inheritance, and an initial value in environments that support it, improving validation and interpolation for registered properties.

Component styles may use globally named classes, BEM conventions, CSS Modules, Shadow DOM, or framework-specific mechanisms. No strategy is universally superior. Global classes are simple and interoperable; CSS Modules reduce naming collisions; Shadow DOM provides stronger encapsulation but introduces styling and theming considerations; CSS-in-JS may colocate styles but can affect runtime cost and server rendering. The decision should consider team skills, rendering architecture, debugging, accessibility, and build constraints.

5.3 Utility-first frameworks

Utility frameworks provide small classes such as spacing, display, colour, and typography utilities. They encourage composition in markup and can reduce the need for bespoke selectors. Benefits include consistency, fast implementation, and constrained design choices. Risks include verbose markup, abstraction leakage, difficulty expressing complex component states, and dependence on a framework’s token vocabulary. A mature implementation combines utilities with semantic components and documented exceptions rather than treating utility classes as a replacement for design thinking.

6. Design Tokens and Design Systems

A design system is a coordinated set of principles, tokens, components, patterns, documentation, tooling, and governance. It is broader than a component library. A library supplies reusable code; a design system also defines why and when components should be used.

6.1 Token levels

Tokens should progress from raw values to semantic roles:

```css

:root {

--blue-600: #2563eb; / global/raw token /

--space-2: 0.5rem;

--color-action: var(--blue-600); / semantic token /

}

[data-theme="dark"] {

--color-surface: #111827;

--color-text: #f9fafb;

}

```

Raw tokens describe palettes or scales. Semantic tokens describe purpose, such as `color-action`, `color-danger`, or `surface-raised`. Component tokens may describe a local API, such as `button-padding-inline`. Semantic indirection makes theme changes safer because components depend on roles rather than literal colour names.

A token system should document units, naming, permitted values, contrast expectations, and ownership. Token names should represent meaning, not implementation accidents. `--color-text-muted` may remain useful when its role is stable; `--gray-500` exposes less design intent.

6.2 Governance and quality

A design system requires contribution rules, versioning, changelogs, accessibility acceptance criteria, visual regression tests, and deprecation procedures. Governance should prevent both uncontrolled divergence and excessive centralisation. Product teams need a route for legitimate exceptions, while the central system needs evidence before adding new components.

Useful measures include adoption of supported components, duplicate implementations retired, accessibility defect rates, visual regression findings, bundle impact, and time required to implement a standard interface. These metrics should be interpreted carefully. High adoption may indicate value, but it may also reflect organisational enforcement rather than usability.

7. Detailed Applied Case: A Responsive University Service Portal

Background

The fictional Northbridge University plans a portal for enrolment, fee payment, timetable access, and support requests. Existing pages were created by separate teams. They use inconsistent colours, duplicated CSS, fixed-width tables, inaccessible focus states, and mobile layouts that require horizontal scrolling.

Problem

The university needs a coherent interface that supports students using phones and desktops, accommodates keyboard and screen-reader users, and allows faculties to deliver features without copying styles. The portal must also support a dark theme and reduce motion when requested.

Analysis

An audit identifies 14 button styles, five spacing conventions, and three unrelated breakpoint schemes. The most severe problems are not aesthetic: keyboard users cannot identify focus on several controls; data tables overflow on small screens; and modal stacking is inconsistent. The team decides that a token-and-component system is more valuable than a wholesale visual redesign.

Approach and solution

First, the team defines semantic tokens for surfaces, text, borders, actions, status colours, spacing, radii, and typography. Colour tokens are tested for text contrast in light and dark themes. A reset layer and base layer are placed before component and utility layers.

Second, the team establishes components with explicit states: button, form field, alert, card, dialog, navigation, and data table. Each component documents keyboard behaviour, accessible name requirements, focus treatment, and responsive rules. A dialog traps focus while open, returns focus to its invoking control on close, and exposes an appropriate accessible relationship.

Third, layout is implemented with normal flow, Grid, and Flexbox. The page shell uses a maximum readable measure rather than a fixed device width. The card collection uses an auto-fitting grid. The data table provides a deliberate small-screen alternative: critical fields remain visible, while secondary details are available through an accessible expansion pattern rather than forcing users to pan across a wide table.

Fourth, container queries are used for reusable cards embedded in both wide dashboard regions and narrow side panels. Breakpoints are added only where navigation or content becomes unusable. Motion is limited to short opacity and transform transitions, and a reduced-motion mode removes nonessential movement.

Finally, automated tests check token usage, component snapshots, keyboard navigation, colour contrast, and layout at representative widths. A visual review process evaluates content zoom, forced-colour modes, and long translated strings.

Outcome

The portal achieves consistent styling while allowing faculties to compose approved components. The most important improvement is not a numerical visual score but a reduction in task friction: students can complete core actions without horizontal scrolling, keyboard users receive visible focus, and dark-theme changes do not require rewriting component styles. The system also reduces future duplication because teams consume documented components and semantic tokens.

Learning points

1. Responsive design is a content and interaction problem, not simply a set of viewport breakpoints.

2. Design tokens are valuable when they encode semantic decisions and are governed as an API.

3. Accessibility requirements must be part of component design, not a final visual audit.

4. A design system succeeds through documentation, testing, and contribution processes as well as CSS.

8. Limitations, Ethics, and Contemporary Practice

CSS cannot compensate for poor information architecture, unsuitable content, or inaccessible interaction logic. Responsive transformations can also conceal information, and aggressive visual changes may disadvantage users with cognitive or sensory impairments. Teams should test with real users, assistive technologies, keyboard-only navigation, zoom, translation, and high-contrast settings.

Privacy and governance concerns arise when design systems include analytics or remote experimentation. A component should not silently introduce tracking or collect unnecessary user data. Third-party styles and fonts require supply-chain review, licensing checks, integrity controls, and performance assessment.

AI tools can generate CSS, suggest responsive rules, or identify likely specificity conflicts. Their output should be treated as untrusted code requiring human review. AI may reproduce inaccessible colour combinations, obsolete browser assumptions, excessive selectors, or licensing-sensitive examples. Prompts and generated code should not expose confidential product information. The responsible workflow is to define constraints, generate a small proposal, test it against standards and project requirements, and document accepted decisions.

Contemporary CSS development increasingly uses cascade layers, container queries, native nesting, logical properties, `:has()`, view-transition capabilities, and scoped or component-oriented styling. Adoption should be based on browser support policy, progressive enhancement, and measurable benefit. Logical properties such as `margin-inline` and `padding-block` improve support for right-to-left and vertical writing modes, making them preferable to assuming left-to-right horizontal text everywhere.

Best-Practice Checklist

• Prefer normal flow and intrinsic sizing before fixed dimensions.
• Keep selector specificity low and predictable.
• Use cascade layers to express ownership and precedence.
• Choose Flexbox for one-dimensional alignment and Grid for two-dimensional relationships.
• Base responsive decisions on content failure and component space.
• Support keyboard focus, zoom, colour preferences, forced colours, and reduced motion.
• Animate purposefully and prefer transform and opacity when appropriate.
• Use semantic custom properties rather than scattering literal values.
• Treat components, tokens, documentation, tests, and governance as one design-system product.
• Validate AI-generated CSS through human review, accessibility testing, performance testing, and security policy.

Chapter Summary

CSS is a constraint and rule-resolution system whose output is determined by the cascade, layers, specificity, inheritance, and source order. Reliable styling depends on understanding computed values and avoiding unnecessary specificity escalation. Normal flow should be preserved wherever possible, while Flexbox, Grid, positioning, and container queries should be selected according to the spatial problem.

Responsive design combines fluid constraints, content-driven breakpoints, intrinsic sizing, media features, and user preferences. Adaptive behaviour may complement responsive layout when capabilities or tasks differ. Animation should communicate state and preserve accessibility and performance. Preprocessors, utility frameworks, CSS Modules, Shadow DOM, and CSS-in-JS each offer trade-offs rather than universal solutions.

A maintainable design system connects semantic design tokens, reusable accessible components, documentation, testing, versioning, and governance. Its purpose is not merely visual consistency but reliable product development. Ethical and professional practice requires attention to accessibility, privacy, supply-chain risk, internationalisation, performance, and human review of AI-assisted code.

Key Terms

Cascade: The process used to resolve competing CSS declarations.

Specificity: The selector comparison mechanism used when declarations compete.

Inheritance: The transfer of eligible property values from an ancestor to a descendant.

Cascade layer: An explicit author-defined ordering mechanism for groups of CSS rules.

Computed value: The value produced after CSS inheritance and value resolution stages.

Box model: The content, padding, border, and margin structure of an element.

Normal flow: The default arrangement of block and inline content.

Flexbox: A one-dimensional CSS layout model.

Grid: A two-dimensional CSS layout model based on rows and columns.

Containing block: The reference box used to resolve dimensions or positions.

Stacking context: An isolated ordering context for painting and z-index relationships.

Responsive design: Design that adapts to available space and device conditions.

Adaptive design: Design that selects among discrete experiences or layouts based on context.

Container query: A conditional style rule based on an element’s container size.

Custom property: A runtime CSS variable whose name begins with two hyphens.

Design token: A named, governed value representing a design decision.

Design system: Coordinated principles, tokens, components, documentation, tooling, and governance.

Progressive enhancement: Building a functional baseline and adding capabilities when supported.

Specificity escalation: Increasing selector complexity to force a cascade result.

Visual regression testing: Automated comparison of rendered interfaces across changes.

Review Questions

Short Answer Questions

1. What four factors commonly determine which competing CSS declaration wins?

2. Explain one important difference between Flexbox and CSS Grid.

3. Why can `min-width: 0` be necessary on a flex item?

4. What is the purpose of a semantic design token?

5. State two accessibility considerations for CSS animation.

Long Answer Questions

1. Explain the cascade, specificity, inheritance, and cascade layers, and discuss how they influence maintainability.

2. Compare normal flow, Flexbox, Grid, and positioning. Give an appropriate use case and a limitation for each.

3. Develop a responsive design strategy for a content-heavy university website, including breakpoint selection, container queries, and user preferences.

4. Compare preprocessors, utility-first CSS, CSS Modules, and Shadow DOM as component-styling strategies.

5. Describe how an organisation should govern a design system from token definition through component release and deprecation.

Analytical / Application Questions

1. A dashboard card works in a wide grid but becomes unreadable when placed in a narrow sidebar. Propose a solution using container queries, intrinsic sizing, and accessible content priorities. Justify each decision.

2. A team repeatedly adds `!important` and increasingly long selectors to fix conflicts. Diagnose the architectural causes and design a migration plan using layers, lower-specificity selectors, and component ownership.

3. Evaluate the Northbridge University case as a design-system intervention. Identify two technical risks, two governance risks, and a testing strategy for determining whether the intervention has improved the user experience.

Multiple Choice Questions with Answers

Question 1

Which mechanism is specifically intended to establish an explicit ordering among groups of CSS rules?

A. Cascade layers

B. Margin collapsing

C. Flex wrapping

D. Intrinsic sizing

Correct Answer: A. Cascade layers

Question 2

Which layout model is primarily one-dimensional?

A. CSS Grid

B. Flexbox

C. Absolute positioning

D. The box model

Correct Answer: B. Flexbox

Question 3

What does `min-width: 0` commonly enable on a flex item?

A. It forces the item to become fixed-width

B. It prevents all text wrapping

C. It allows the item to shrink below its content-based minimum

D. It creates a new stacking context

Correct Answer: C. It allows the item to shrink below its content-based minimum

Question 4

Which function constrains a value between a minimum and maximum while allowing a preferred value?

A. calc()

B. var()

C. minmax()

D. clamp()

Correct Answer: D. clamp()

Question 5

What is the principal difference between a media query and a container query?

A. A media query can style only text

B. A container query evaluates the relevant container’s dimensions

C. A container query works only with Flexbox

D. A media query cannot use minimum widths

Correct Answer: B. A container query evaluates the relevant container’s dimensions

Question 6

Which property is generally a strong candidate for efficient interface animation?

A. transform

B. margin-left

C. width

D. top

Correct Answer: A. transform

Question 7

What is the main purpose of a semantic token such as `--color-action`?

A. To encode a browser-specific selector

B. To replace all component documentation

C. To represent a design role independently of a literal value

D. To disable inheritance

Correct Answer: C. To represent a design role independently of a literal value

Question 8

Which CSS-wide keyword returns to an earlier cascade origin or user-agent behaviour?

A. inherit

B. initial

C. unset

D. revert

Correct Answer: D. revert

Question 9

Which practice best supports users who request reduced motion?

A. Remove all focus indicators

B. Reduce or disable nonessential animation using a preference query

C. Replace every transition with a longer animation

D. Use animation only on mobile devices

Correct Answer: B. Reduce or disable nonessential animation using a preference query

Question 10

What distinguishes a design system from a component library?

A. A design system contains no code

B. A component library always includes governance and principles

C. A design system includes coordinated principles, tokens, components, documentation, and governance

D. A design system is only a collection of colour values

Correct Answer: C. A design system includes coordinated principles, tokens, components, documentation, and governance