重新思考 JS 中的 CSS

0. 簡介

在 Web 開發領域，CSS 是使用者介面美觀且實用的關鍵元素。

然而，隨著 Web 應用程式複雜性的增加，CSS 管理已成為一項越來越具有挑戰性的任務。風格衝突、效能下降、維護困難是許多開發者關心的問題。

這些問題是否阻礙了您的專案進度？ （圖片來源）

本文深入探討了解決這些問題的新方法，特別是 JS 中的 CSS。
它從 CSS 的歷史背景開始，涵蓋了廣泛的主題從現代樣式方法到未來的設計系統。

文章架構如下：

1. JS中CSS的定義與背景
   • 1. JS 中的 CSS 是什麼？
   • 2. CSS在JS的背景
2. CSS 與設計的歷史背景
   • 3. CSS的背景
   • 4.設計背景
   • 5.設計系統背景
3. 風格管理方法分析及新建議
   • 6.樣式是如何管理的？
   • 7.樣式該如何管理？
4. CSS在JS中的具體實作方案
   • 8.為什麼在 JS 使用 CSS？
   • 9.介紹一下mincho專案
   • 10。 JS 中 CSS 友善的 CSS
   • 11。 JS 中的可擴展 CSS
5. 與設計系統整合
   • 12。用於設計系統的 JS 中的 CSS

特別是，本文介紹了稱為 SCALE CSS 方法論和 StyleStack 的新概念，並基於這些概念提出了一個 mincho 項目。它的目標是在 JS 中實現 CSS，對 CSS 友好且可擴展。

本文的最終目的是向開發人員、設計師和其他 Web 專案利害關係人展示更好的樣式解決方案的可能性。

現在，讓我們在正文中深入探討 JS 中 CSS 的世界。這將是一段漫長的旅程，但我希望它能為你帶來新的靈感和挑戰的機會。

1.JS中的CSS是什麼？

JS 中的 CSS 是一種允許您直接在 JavaScript（或 TypeScript）程式碼中編寫 CSS 樣式的技術。
您可以在 JavaScript 檔案中與元件一起定義樣式，而不是建立單獨的 CSS 檔案。

/** @jsxImportSource @emotion/react */
import { css } from "@emotion/react";

const buttonStyles = (primary) => css({
  backgroundColor: primary ? "blue" : "white",
  color: primary ? "white" : "black",
  fontSize: "1em",
  padding: "0.25em 1em",
  border: "2px solid blue",
  borderRadius: "3px",
  cursor: "pointer",
});

function Button({ primary, children }) {
  return (
    <button css="{buttonStyles(primary)}">
      {children}
    </button>
  );
}

function App() {
  return (
    <div>
      <button>Normal Button</button>
      <button primary>Primary Button</button>
    </div>
  );
}

能夠將其整合到 JavaScript 中當然看起來很方便？

2.CSS在JS的背景

CSS in JS 是在 Facebook 開發者 Vjeux 的題為「React: CSS in JS – NationJS」的演講中介紹的。

CSS-in-JS旨在解決的問題如下：

更具體的問題是什麼？
而JS中的CSS又是如何解決的呢？

我將它們整理在下表中：

	Problem	Solution
Global namespace	Need unique class names that are not duplicated as all styles are declared globally	Use Local values as default - Creating unique class names - Dynamic styling
Implicit Dependencies	The difficulty of managing dependencies between CSS and JS - Side effect: CSS is applied globally, so it still works if another file is already using that CSS - Difficulty in call automation: It's not easy to statically analyze and automate CSS file calls, so developers have to manage them directly	Using the module system of JS
Dead Code Elimination	Difficulty in removing unnecessary CSS during the process of adding, changing, or deleting features	Utilize the optimization features of the bundler
Minification	Dependencies should be identified and reduced	As dependencies are identified, it becomes easier to reduce them.
Sharing Constants	Unable to share JS code and state values	Use JS values as they are, or utilize CSS Variables
Non-deterministic Resolution	Style priority varies depending on the CSS loading order	- Specificity is automatically calculated and applied - Compose and use the final value
Breaking Isolation	Difficulty in managing external modifications to CSS (encapsulation)	- Encapsulation based on components - Styling based on state - Prevent styles that break encapsulation, such as .selector > *

But it's not a silverbullet, and it has its drawbacks.

1. CSS-in-JS adds runtime overhead.
2. CSS-in-JS increases your bundle size.
3. CSS-in-JS clutters the React DevTools.
4. Frequently inserting CSS rules forces the browser to do a lot of extra work.
5. With CSS-in-JS, there's a lot more that can go wrong, especially when using SSR and/or component libraries.

Aside from the DevTools issue, it appears to be mostly a performance issue.
Of course, there are CSS in JS, which overcomes these issues by extracting the CSS and making it zero runtime, but there are some tradeoffs.
Here are two examples.

1. Co‑location: To support co-location while removing as much runtime as possible, the module graph and AST should be analyzed and build times will increase. Alternatively, there is a method of abandoning co-location and isolating on a file-by-file basis, similar to Vanilla Extract.
2. Dynamic styling restrictions: The combination of build issues and the use of CSS Variables forces us to support only some representations, like Styling based on props in Pigment CSS, or learn to do things differently, like Coming from Emotion or styled-components. Dynamicity is also one of the main metrics that can be used to distinguish between CSS in JS.

Therefore, pursuing zero(or near-zero) runtime in CSS-in-JS implementation methods creates a significant difference in terms of expressiveness and API.

3. The background of CSS

3.1 The Beginning of CSS

Where did CSS come from?
Early web pages were composed only of HTML, with very limited styling options.

<p><font color="red">This text is red.</font></p>
<p>This is <strong>emphasized</strong> text.</p>
<p>This is <em>italicized</em> text.</p>
<p>This is <u>underlined</u> text.</p>
<p>This is <strike>strikethrough</strike> text.</p>
<p>This is <big>big</big> text, and this is <small>small</small> text.</p>
<p>H<sub>2</sub>O is the chemical formula for water.</p>
<p>2<sup>3</sup> is 8.</p>

For example, the font tag could change color and size, but it couldn't adjust letter spacing, line height, margins, and so on.

You might think, "Why not just extend HTML tags?" However, it's difficult to create tags for all styling options, and when changing designs, you'd have to modify the HTML structure itself.
This deviates from HTML's original purpose as a document markup language and also means that it's hard to style dynamically.

If you want to change an underline to a strikethrough at runtime, you'd have to create a strike element, clone the inner elements, and then replace them.

const strikeElement = document.createElement("strike");
strikeElement.innerHTML = uElement.innerHTML;
uElement.parentNode.replaceChild(strikeElement, uElement);

When separated by style, you only need to change the attributes.

element.style.textDecoration = "line-through";

If you convert to inline style, it would be as follows:

<p style="color: red;">This text is red.</p>
<p>This is <span style="font-weight: bold;">bold</span> text.</p>
<p>This is <span style="font-style: italic;">italic</span> text.</p>
<p>This is <span style="text-decoration: underline;">underlined</span> text.</p>
<p>This is <span style="text-decoration: line-through;">strikethrough</span> text.</p>
<p>This is <span style="font-size: larger;">large</span> text, and this is <span style="font-size: smaller;">small</span> text.</p>
<p>H<span style="vertical-align: sub; font-size: smaller;">2</span>O is the chemical formula for water.</p>
<p>2<span style="vertical-align: super; font-size: smaller;">3</span> is 8.</p>

However, inline style must be written repeatedly every time.
That's why CSS, which styles using selectors and declarations, was introduced.

<p>This is the <strong>important part</strong> of this sentence.</p>
<p>Hello! I want to <strong>emphasize this in red</strong></p>
<p>In a new sentence, there is still an <strong>important part</strong>.</p>

<style>
strong { color: red; text-decoration: underline; }
</style>

Since CSS is a method that applies multiple styles collectively, rules are needed to determine which style should take precedence when the target and style of CSS Rulesets overlap.

CSS was created with a feature called Cascade to address this issue. Cascade is a method of layering styles, starting with the simple ones and moving on to the more specific ones later. The idea was that it would be good to create a system where basic styles are first applied to the whole, and then increasingly specific styles are applied, in order to reduce repetitive work.

Therefore, CSS was designed to apply priorities differently according to the inherent specificity of CSS Rules, rather than the order in which they were written.

/* The following four codes produce the same result even if their order is changed. */
#id { color: red; }
.class { color: green; }
h1 { color: blue; }
[href] { color: yellow; }

/* Even if the order is changed, the result is the same as the above code. */
h1 { color: blue; }
#id { color: red; }
[href] { color: yellow; }
.class { color: green; }

However, as CSS became more scalable, a problem arose..

3.2 Scalable CSS

Despite the advancements in CSS, issues related to scalability in CSS are still being discussed.
In addition to the issues raised by CSS in JS, several other obstacles exist in CSS.

1. Code duplication: When writing media queries, pseudo-classes, and pseudo-elements, a lot of duplication occurs if logic is required.
2. Specificity wars: As a workaround for name collisions and non-deterministic ordering, specificity keeps raising the specificity to override the style. You can have fun reading Specificity Battle!
3. Lack of type-safety: CSS does not work type-safely with TypeScript or Flow.

These issues can be addressed as follows:

1. Penduaan kod: Gunakan bersarang dalam prapemproses CSS, dsb.
2. Peperangan kekhususan: CSS atom ditakrifkan untuk setiap sifat secara berasingan, jadi ia mempunyai kekhususan yang sama kecuali untuk susunan pemuatan dan !penting.
3. Kekurangan jenis-keselamatan: Hanya gunakan CSS dalam JS dengan sokongan jenis-selamat.

Menyatakan reka letak ialah satu lagi halangan dalam CSS, yang dibuat lebih kompleks dengan interaksi antara pelbagai sifat.

CSS mungkin kelihatan mudah di permukaan, ia tidak mudah untuk dikuasai. Umum mengetahui bahawa ramai orang bergelut walaupun dengan penjajaran tengah yang mudah(1, 2). Kesederhanaan CSS yang jelas boleh mengelirukan, kerana kedalaman dan nuansanya menjadikannya lebih mencabar daripada yang kelihatan pada mulanya.

Sebagai contoh, paparan dalam CSS mempunyai model reka letak yang berbeza: blok, sebaris, jadual, lentur dan grid.
Bayangkan kerumitan apabila sifat berikut digunakan dalam kombinasi: model kotak, Reka bentuk responsif, Terapung, Kedudukan, transformasi, mod penulisan, topeng, dll.

Apabila skala projek meningkat, ia menjadi lebih mencabar kerana kesan sampingan yang berkaitan dengan Penempatan DOM, lata dan kekhususan.

Isu reka letak harus ditangani melalui rangka kerja CSS yang direka dengan baik, dan seperti yang dinyatakan sebelum ini, menggunakan CSS dalam JS untuk mengasingkan gaya boleh mengurangkan kesan sampingan.

Bagaimanapun, pendekatan ini tidak menyelesaikan semua masalah sepenuhnya. Pengasingan gaya boleh membawa kepada kesan sampingan baharu, seperti saiz fail meningkat disebabkan oleh pengisytiharan gaya pendua dalam setiap komponen atau kesukaran dalam mengekalkan konsistensi gaya biasa merentas aplikasi.
Ini secara langsung bercanggah dengan reka bentuk isu letupan dan konsistensi gabungan yang akan diperkenalkan seterusnya.

Buat masa ini, kami boleh mewakilkan kebimbangan reka letak kepada rangka kerja seperti Bootstrap atau Bulma dan memfokuskan lebih pada aspek pengurusan.

4. Latar belakang Reka Bentuk

Pada terasnya, CSS ialah alat yang berkuasa untuk menyatakan dan melaksanakan reka bentuk dalam pembangunan web.

Terdapat banyak faktor yang perlu dipertimbangkan semasa mencipta UI/UX dan elemen berikut adalah penting untuk diwakili dalam reka bentuk anda:

1. Reka Bentuk Visual
   • Reka Letak: Menentukan struktur skrin dan peletakan elemen. Pertimbangkan jarak, penjajaran dan hierarki antara elemen.
   • Warna: Pilih palet warna yang mempertimbangkan identiti jenama dan pengalaman pengguna. Pemahaman tentang teori warna adalah perlu.
   • Tipografi: Pilih fon dan gaya teks yang sepadan dengan kebolehbacaan dan imej jenama.
   • Ikon dan Elemen Grafik: Reka bentuk ikon dan grafik yang intuitif dan konsisten.
2. Reka Bentuk Interaksi
   • Reka bentuk gelagat elemen UI seperti butang, peluncur dan bar skrol.
   • Berikan pengalaman pengguna semula jadi melalui animasi dan kesan peralihan.
   • Pertimbangkan reka bentuk responsif yang menyesuaikan diri dengan pelbagai saiz skrin.
3. Seni Bina Maklumat
   • Reka bentuk struktur dan hierarki kandungan untuk membolehkan pengguna mencari dan memahami maklumat dengan mudah.
   • Reka bentuk sistem navigasi untuk membolehkan pengguna bergerak ke lokasi yang dikehendaki dengan mudah.
4. Kebolehaksesan dan Kebolehgunaan
   • Kejar reka bentuk inklusif yang mempertimbangkan pengguna yang pelbagai. i18n juga boleh disertakan.
   • Buat antara muka yang intuitif dan mudah digunakan untuk mengurangkan beban kognitif pengguna.
5. Panduan Ketekalan dan Gaya
   • Buat panduan gaya untuk mengekalkan bahasa reka bentuk yang konsisten sepanjang aplikasi.
   • Membangunkan komponen dan corak yang boleh diguna semula untuk meningkatkan kecekapan.

Menyatakan pelbagai elemen reka bentuk dengan tepat merentas pelbagai keadaan memberikan cabaran yang ketara.
Pertimbangkan bahawa anda perlu mengambil kira peranti (telefon, tablet, komputer riba, monitor, TV), peranti input (papan kekunci, tetikus, sentuhan, suara), mod landskap/potret, tema gelap/cerah, mod kontras tinggi, pengantarabangsaan (bahasa). , LTR/RTL), dan banyak lagi.
Selain itu, UI yang berbeza mungkin perlu dipaparkan berdasarkan tetapan pengguna.

Oleh itu, Letupan Kombinatorial tidak dapat dielakkan, dan adalah mustahil untuk melaksanakannya satu demi satu secara manual. (sumber imej)

作為代表性範例，請參閱我的 Firefox 主題中標籤欄佈局的定義和編譯。
儘管只考慮作業系統和使用者選項，但大約 360 行的檔案編譯結果達到大約 1400 行。

結論是，有效的設計實作本質上需要可擴展，通常以程式設計方式或透過明確定義的規則集進行管理。
結果是一個用於大規模一致管理的設計系統。

五、設計系統背景

設計系統作為單一事實來源，涵蓋從視覺樣式到 UI 模式和程式碼實現的設計和開發的各個方面。

根據 Nielsen Norman Group 的說法，設計系統包括以下內容：

• 風格指南：針對特定風格需求提供風格指導的文檔，包括品牌、內容和視覺設計。
• 元件庫：這些指定可重複使用的單一 UI 元素，例如按鈕。對於每個UI 元素，都提供了具體的設計和實現細節，包括可自定義的屬性（大小、複製等）、不同狀態（啟用、懸停、焦點、禁用）等信息，以及每個元素的可重複使用的乾淨、緊湊的程式碼元素。
• 模式庫： 這些指定可重複使用模式，或從元件庫中取得的單一 UI 元素組。例如，您可能會看到頁面標題的模式，它可以由標題、麵包屑、搜尋以及主要和輔助按鈕組成。
• 設計資源：為了讓設計師實際使用和設計元件和函式庫，需要一個設計文件（通常在 Figma 中）。通常還包含徽標、字體和字體以及圖標等資源，供設計師和開發人員使用。

設計系統應該充當設計師和開發人員的十字路口，支援功能、表單、可訪問性和自訂。
但設計師和開發者的想法不同，視角也不同。

讓我們以組件為鏡頭，來認識設計師和開發者視角的差異！ ！

5.1 組件結構

設計者也應該決定複選框控制項將使用哪個圖示。

設計師傾向於關注形式，而開發者傾向於關注功能。
對設計師來說，按鈕看起來很吸引人按就是按鈕，而對開發者來說，只要能按就是按鈕。

如果組件更複雜，設計師和開發人員之間的差距可能會進一步拉大。

5.2 設計者考慮

• 視覺選項：外觀根據設定的選項而變化，如主要、重音、輪廓、純文字等
  

• 狀態選項：外觀會根據狀態和上下文而變化
  

• 設計決策：透過元件結構、視覺/狀態選項、視覺屬性（顏色、版式、圖示等）等來決定值。

5.3 開發者考慮因素

• 選項：可設定的初始值。還包括視覺選項。例如）輪廓，尺寸
• 狀態： 基於使用者互動的變更。例如）懸停、按下、聚焦、選擇（選取）
• 事件： 觸發狀態變更的操作。例如）HoverEvent、PressEvent、FocusEvent、ClickEvent
• 上下文： 從影響行為的程式碼注入的條件。例如）唯讀、停用

最終的形式是 Option、State 和 Context 的組合，從而導致上面提到的組合爆炸。

其中，Option 符合設計者的觀點，而 State 和 Context 則不然。
考慮並行狀態、層級結構、守衛等進行狀態壓縮，以返回設計者的角度。

• 啟用：停用關閉、按下關閉、懸停關閉、聚焦關閉
• 懸停： 關閉、按下關閉、懸停開啟
• 聚焦： 關閉、按下關閉、對焦開啟
• 按：停用關閉，按開啟
• 已停用： 停用開啟

6. 樣式是如何管理的？

正如您現在可能已經意識到的那樣，創建和維護高品質的 UI 是一項艱苦的工作。

所以狀態管理庫涵蓋了各種狀態，但是樣式是如何管理的呢？
雖然由於解決方案尚未建立，方法論、函式庫和框架不斷出現，但有三個主要範例。

1. 語意CSS：依元素的目的或意義分配類別。
2. 原子 CSS： 為每個樣式（視覺）屬性建立一個類別。
3. JS 中的 CSS： 用 Ja​​vaScript 編寫，並為每個元件單元隔離 CSS。

其中，JS 中的 CSS 感覺像是一種範式，使用完全不同的方法來表達和管理樣式。
這是因為JS中的CSS就像機制，而語意CSS和原子CSS就像策略。
由於這種差異，JS 中的 CSS 需要與其他兩種方法分開解釋。 （圖片來源）

在討論 JS 機制中的 CSS 時，可能會想到 CSS 前/後處理器。
同樣，在談論政策時，可能會想到「CSS 方法」。

因此，我將按照以下順序介紹樣式管理方法：JS中的CSS、處理器、語義CSS和原子CSS以及其他樣式方法。

6.1 JS 中的 CSS

那麼，CSS在JS中的真實身分是什麼？
答案就在上面的定義中。

用 JavaScript 寫 和 為每個元件單元隔離 CSS。

1. 用 JavaScript 寫的 CSS
2. 元件層級的 CSS 隔離

其中，CSS隔離可以充分應用於現有CSS，解決全域命名空間和破壞隔離問題。
這是 CSS 模組。

根據上面提到的CSS in JS分析文章的鏈接，我將功能分類如下。
每個功能都有權衡，這些是在 JS 中創建 CSS 時重要的因素。

6.1.1 集成

特別值得注意的內容是SSR（伺服器端渲染）和RSC（React Server Component）。
這些是代表前端的React和NEXT所追求的方向，它們很重要，因為它們對實現有重大影響。

• IDE： 語法突出顯示和程式碼完成
• TypeScript: 是否類型安全
• 框架
  • 不可知論：獨立於框架，像 StyledComponent 這樣的函式庫是專門為 React 設計的。
  • SSR： 在伺服器上渲染時將樣式提取為字串並支援水合作用
  • RSC： RSC 僅在伺服器上運行，因此無法使用客戶端 API。

伺服器端渲染在伺服器上建立 HTML 並將其傳送到客戶端，因此需要將其提取為字串，並且需要對串流進行回應。與樣式組件的範例一樣，可能需要額外的設定。 （圖片來源）

1. Server-side style extraction
   • Should be able to extract styles as strings when rendering on the server
   • Insert extracted styles inline into HTML or create separate stylesheets
2. Unique class name generation
   • Need a mechanism to generate unique class names to prevent class name conflicts between server and client
3. Hydration support
   • The client should be able to recognize and reuse styles generated on the server
4. Asynchronous rendering support
   • Should be able to apply accurate styles even in asynchronous rendering situations due to data fetching, etc.

Server components have more limitations. [1, 2]
Server and client components are separated, and dynamic styling based on props, state, and context is not possible in server components.
It should be able to extract .css files as mentioned below.

1. Static CSS generation
   • Should be able to generate static CSS at build time
   • Should be able to apply styles without executing JavaScript at runtime
2. Server component compatibility
   • Should be able to define styles within server components
   • Should not depend on client-side APIs
3. Style synchronization between client and server
   • Styles generated on the server must be accurately transmitted to the client

6.1.2 Style Writing

As these are widely known issues, I will not make any further mention of them.

• Co-location: Styles within the same file as the component?
• Theming: Design token feature supports
• Definition: Plain CSS string vs Style Objects
• Nesting
  • Contextual: Utilize parent selectors using &
  • Abitrary: Whether arbitrary deep nesting is possible

6.1.3 Style Output and Apply

The notable point in the CSS output is Atomic CSS.
Styles are split and output according to each CSS property.

• Style Ouput
  • .css file: Extraction as CSS files
  • Injection into the of the
  • Inline style: Injected inline for each HTML element
• Styles apply method
  • className: Specify className as a string
  • styled component: Create and use Styled Components
  • css prop: Generate className from the css prop in jsx
• Atomic CSS: Create separate classes for each CSS property

6.2 CSS Processors

There might be a way to solve this by extending CSS rather than using a JavaScript-centric approach. (image source)

CSS preprocessors use their own syntax to extend CSS for writing code, which is then compiled into regular CSS.
Examples of CSS preprocessors include Sass, Less, and Stylus.

CSS postprocessors use standard CSS syntax as-is and transform it through a plugin system.
PostCSS is an example of a CSS postprocessor, and Lightning CSS also has postprocessing capabilities.

Here, the nesting and mixin features are particularly worth discussing.
I will explain based on SCSS.

The nesting feature allows you to write CSS code in a structure similar to HTML.

.nav {
  background-color: #f0f0f0;
  ul {
    list-style: none;
    li {
      display: inline-block;
      a {
        color: #333;
        &:hover {
          color: #007bff;
        }
      }
    }
  }
}

You can use the & symbol to reference the parent selector. This is useful when creating pseudo-classes or modifier classes.

.button {
  background-color: #007bff;

  &:hover { background-color: #0056b3; }
  &--large { font-size: 18px; }
  &--small { font-size: 14px; }
}

Related properties and media queries can also be nested, improving the structure of the code.

.element {
  font: {
    family: Arial;
    size: 16px;
  }

  @media (min-width: 768px) {
    font-size: 18px;
  }
}

Mixins are reusable style blocks that allow you to create styles in advance or vary them with parameters.

@mixin center-text {
  text-align: center;
  vertical-align: middle;
}

@mixin border-radius($radius: 3px) {
  border-radius: $radius;
}

.header {
  @include center-text;
  @include border-radius(5px);
}

.button {
  @include border-radius(); // Use default value
}

You can also apply styles using control logic or apply additional styles using the @content directive.

@mixin media-query($breakpoint) {
  @if $breakpoint == tablet {
    @media (min-width: 768px) and (max-width: 1023px) {
      @content;
    }
  } @else if $breakpoint == desktop {
    @media (min-width: 1024px) {
      @content;
    }
  } @else {
    @warn "Unknown breakpoint: #{$breakpoint}";
  }
}

.responsive-element {
  font-size: 16px;

  @include media-query(tablet) {
    font-size: 18px;
  }

  @include media-query(desktop) {
    font-size: 20px;
  }
}

6.3 Semantic CSS and Atomic CSS

The biggest difference between Semantic CSS and Atomic CSS is likely whether they prioritize visual appearance or meaning.
When prioritizing visual appearance, you might use something like .text-red { color: red; }, while prioritizing meaning would lead to something like .error { color: red; }.

Due to these characteristics, the methods for achieving goals also differ.
For example, what if you needed to create various designs with the same content, like in CSS Zen Garden?
The visual approach would keep the CSS fixed but achieve the goal by modifying the HTML.
The semantic approach would keep the HTML fixed but achieve the goal by modifying the CSS.

Maximizing the visual approach minimizes CSS file size and reduces coupling by reusing small, single-purpose classes.
This is precisely Atomic CSS.

Atomic CSS is a functional CSS approach that composes styles by combining small, single-purpose classes.

.m-0 { margin: 0; }
.p-1 { padding: 1rem; }
.text-center { text-align: center; }

<div class="m-0 p-1 text-center">
  Hello, World!
</div>

Maximizing the semantic approach improves code readability and increases CSS cohesion. It also facilitates better separation of content(HTML) and formatting(CSS).
The class serves as an identifier for grouped elements and is also a W3C recommendation because it emphasizes the separation between HTML and CSS.

BEM is one of the most popular semantic CSS methodologies. (image source)

BEM(Block Element Modifier) structures class names of HTML elements by naming them as Block, Element, and Modifier.

• Block: Independent component
• Element: Part of a Block
• Modifier: Variation of Block or Element

/* Structure */
.block {}
.block__element {}
.block--modifier {}

/* Example */
.button {}
.button__icon {}
.button--large {}

<button class="button button--large">
  <span class="button__icon">?</span>
  Open File
</button>

BEM makes it possible to understand the HTML structure through class names alone.

6.4 CSS Methodologies

CSS methodologies are not limited to just Atomic CSS and BEM.
There are many diverse CSS methodologies, and I will compare them to find common elements among these methodologies.

Here are some famous CSS methodologies:

1. OOCSS(Object Oriented CSS): A methodology that separates CSS into reusable 'objects', managing structure and skin independently.
2. SMACSS(Scalable and Modular Architecture for CSS): A methodology that categorizes CSS into five categories: Base, Layout, Module, State, and Theme.
3. ITCSS(Inverted Triangle CSS): An architecture that organizes CSS hierarchically based on specificity, explicitness, and reach.
4. SUITCSS: A component-based CSS methodology with structured class names and clear relationships.
5. CUBE CSS: A methodology that provides flexible and scalable styling by utilizing the inherent characteristics of CSS using the concepts of Composition, Utility, Block, and Exception.

6.4.1 OOCSS (Object Oriented CSS)

OOCSS is a methodology for writing CSS in an object-oriented way. Its main principles are:

• Visual focus: Separation of structure and skin
  • Structure: Defines layout-related properties such as size, position, and margins of elements.
  • Skin: Defines visual styles such as colors, fonts, and shadows.
• Information focus: Separation of container and content
  • Container: The parent element that wraps other elements, mainly responsible for layout.
  • Content: The element containing the actual content, which should maintain consistent styling regardless of its location.

Example:

/* Structure */
.button {
  display: inline-block;
  padding: 5px 10px;
  border-radius: 5px;
}

/* Skin */
.button-primary {
  background-color: blue;
  color: white;
}

/* Container */
.sidebar {
  width: 300px;
  float: left;
}

/* Contents */
.widget {
  margin-bottom: 20px;
  padding: 15px;
  background-color: #f0f0f0;
}

OOCSS can increase reusability and reduce CSS file size.

6.4.2 SMACSS (Scalable and Modular Architecture for CSS)

SMACSS is a methodology that divides CSS into five categories:

1. Base: This category defines basic styles, including default styles for element selectors and CSS resets.
2. Layout: This category defines the main structure and grid system of the page, responsible for layouts such as headers, footers, and sidebars.
3. Module: This category defines reusable independent components, including UI elements such as buttons, cards, and navigation.
4. State: This category represents specific states of modules or layouts, defining state changes such as active, inactive, and hidden.
5. Theme: This category defines the overall look and feel, including styles related to themes such as color schemes and typography.

Example:

/* Base */
body, p, h1, h2, h3 { margin: 0; padding: 0; }

/* Layout */
.l-header { ... }
.l-sidebar { ... }

/* Module */
.btn { ... }
.btn-primary { ... }

/* State */
.is-hidden { display: none; }

/* Theme */
.theme-dark .btn { background-color: #333; }

SMACSS allows for systematic management of CSS structure.

6.4.3 ITCSS (Inverted Triangle CSS)

ITCSS is a methodology that organizes CSS hierarchically according to specificity, explicitness, and reach. (image source)

The main layers are as follows:

1. Settings: This layer includes basic project settings such as global variables, color definitions, and font settings.
2. Tools: This layer defines globally used tools such as mixins and functions, with no actual CSS output.
3. Generic: This layer defines the most basic and high-level styles, such as resets and normalization.
4. Elements: This layer defines the basic styles of HTML elements, using only element selectors without classes.
5. Objects: This layer defines structural and skeletal styles in the OOCSS approach, including reusable design patterns.
6. Components: This layer defines styles for specific and complete UI components.
7. Utilities: This layer includes utility classes that forcefully apply specific styles, being the most specific and highest priority.

This methodology minimizes specificity conflicts in CSS and improves maintainability.

6.4.4 SUITCSS

SUITCSS is a component-based CSS methodology with structured class names and clear relationships:

• Component: The base component class like ComponentName
• Modifier: Changes the style of the component like .ComponentName--modifierName
• Descendent: Part of the component like .ComponentName-descendentName
• Utility: Single-purpose styling like .u-utilityName

/* Component */
.Button { ... }
.Button-icon { ... }

/* Modifier */
.Button--large { ... }

/* Utility */
.u-textCenter { text-align: center; }

<button class="Button Button--large">
  <span class="Button-icon"></span>
  Submit
</button>
<div class="u-textCenter">
  Centered text
</div>

6.4.5 CUBE CSS

CUBE CSS stands for Composition, Utility, Block, Exception and encompasses the following key concepts:

• Composition: Defines layout patterns
• Utility: Defines small units of styles
• Block: Defines reusable components
• Exception: Handles exceptions in specific situations

It maximize the use of CSS Cascade and others.

Example:

/* Composition */
.cluster {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
}

/* Utility */
.center {
  text-align: center;
}

/* Block */
.card {
  background: white;
  padding: 1rem;
  border-radius: 0.25rem;
}

/* Exception */
.card[data-state="active"] {
  border: 2px solid blue;
}

<div class="cluster">
  <div class="card center">
    <h2 id="Card-Title">Card Title</h2>
    <p>Card content</p>
  </div>
  <div class="card center" data-state="active">
    <h2 id="Active-Card">Active Card</h2>
    <p>This card is active</p>
  </div>
</div>

6.5 Atomic Design

And there is a similarly named methodology called Atomic Design, which is related to the Atomic CSS concept mentioned earlier.

It's closer to a designer-centric methodology rather than a developer-centric one.

1. Ions: Design tokens that define basic design values such as colors, typography, and spacing.
2. Atoms: Basic UI elements that cannot be broken down further, such as buttons, input fields, and labels.
3. Molecules: Simple and reusable components created by combining multiple atoms.
4. Organisms: Relatively complex UI sections made by combining molecules and atoms.
5. Templates: Structures that form the layout of a page by arranging various organisms, molecules, and atoms.
6. Pages: Completed UIs filled with actual content, which are the final screens that users see.

If you want to see the differences between these at a glance, I recommend checking out the following tweet or article.

另一個特點是系統和產品的區別。

• 系統：可重複使用和通用組件的集合
• 產品：一組特定產品或項目的元素

7. 風格應該如何管理？

本章旨在基於前面討論的概念，提出適合現代 Web 開發環境的樣式管理的新範式。 （圖片來源）

內容分為三個主要區域：

1. 建構CSS方法並呈現心智模型
2. 提出CSS 表達的最佳實踐和心智模型
3. 考慮這兩個領域的綜合方法風格管理

首先，我們介紹SCALE CSS方法，它直觀且可擴展，是透過對現有CSS方法（例如ITCSS、BEM和OOCSS）的揚棄而開發的。這個過程整合了每種方法論的核心概念，並探索處理各種案例的有效方法。

如第 6 章所述，CSS 方法是策略，而 JS 中的 CSS 和 CSS 前/後處理器是機制。如果政策更接近包含內容的形式，那麼機制就是表達的工具。

為了更關注CSS管理的方法而不是工具，並找到與政策的聯繫點，我們考慮表達的形式而不是其實質。
我們分享這方面的好做法：

1. 設計令牌：對設計決策進行編碼以限制​​可選值並反轉依賴關係。
2. 原子 CSS： 在單一職責下映射樣式屬性和設計標記，透過介面隔離減少耦合。
3. 變體： 將開閉原則下的組件樣式定義為“變體”，以實現里氏替換並增加內聚力。

結合這些概念，我們提出StyleStack作為樣式管理策略。該策略結合了設計令牌的一致性、Atomic CSS 的效率以及變體的靈活性，可以更快、更一致地實現複雜的 UI。

最後，我們將SCALE CSS方法論和StyleStack以形式化的方式結合在一起，幫助方法論走向形式的實體化，並衍生出具體的目錄結構。
完成這些步驟後，我們就準備討論CSS在JS中的實作，一個實體化表達的工具。

7.1 重新思考方法論

從方法論來看，似乎有一種相似感。 （圖片來源）

讓我們根據最詳細的方法論 ITCSS 來組織它們，並添加狀態。
在「工具」中，我包含了 Atomic CSS，將每個 CSS 視為「函數」。

1. 設定： SMACSS 的主題、Atomic Design 的設計代幣
2. 工具： Atomic CSS、CUBE CSS 的實用工具
3. 通用： SMACSS 的基礎
4. 元素：原子設計的原子
5. 物件： OOCSS 的容器、SMACSS 的佈局、CUBE CSS 的組合、Atomic Design 的模板
6. 元件： BEM 的區塊/元素、OOCSS 的內容、SMACSS 的模組、SUITCSS 的元件、CUBE CSS 的區塊、Atomic Design 的分子/有機體
7. 狀態： OOCSS 的結構/皮膚、BEM 的修改器、SMACSS 的狀態、SUITCSS 的修改器
8. 實用工具： SUITCSS 的實用工具，CUBE CSS 的例外

這個分類似乎涵蓋了幾乎所有情況。
但值得注意的是，在Component 的Element（BEM 的元素，Atomic Design 的分子）和State 中，OOCSS 的Structure/Skin 區別結合了兩個概念，而Atomic Design 的模板，定義頁面層級佈局，與物件一起。

We've encountered the concept of Component's Element before, and it's certainly a familiar concept.
Depending on the complexity of the component, we can define it in the same file as the Block, or create a folder and define each Element and Block separately.

Now, let's consider Structure/Skin.
It's ambiguous to add states that affect layout and decorative states as separate classifications.
Instead, it would be better to separate them when creating each Variant, like size: "small" | "medium" | "large" and shape: "primary" | "filled" | "outlined".

Atomic Design's Templates are about separating page-level layouts, not component-level layouts.
It's the same concept as Next.js transitioning from page router to app router, where it's divided into pages and templates.
Depending on the project, they could be managed in the same directory as pages, or collected in something like src/layouts/page-template.

Now that we've sorted out the exceptions, let's further organize the structure and names of ITCSS.
Let's group items that do similar things and change them to more intuitive names.

1. Settings define static values, and Tools define dynamic functions, both meant to be imported and used, not directly affecting the app. Recently, Configs and Utils seem to be used more often.
2. Generic's reset, normalization, and Elements' default styles are Bases styles that apply globally.
3. Layouts is more intuitive than Objects, and Exception is better than Utilities.
4. States are included in each Layout or Component.

Let's apply this to ITCSS:

       /\
      /  \
     /    \  Exceptions (Styles for special cases)
    /      \
   /        \  Components (Reusable components)
  /          \
 /            \ Layouts (Layout-related styles)
/              \
----------------
|    Bases     | (Globally applied styles)
----------------
|    Utils     | (Globally used utilities)
----------------
|   Configs    | (Basic settings)
----------------

1. Configs: Include project basic settings such as global variables, design tokens(color definitions, font settings), etc.
2. Utils: Define globally used tools such as mixins/functions, atomic css etc.
3. Bases: Styles to be applied globally, such as reset/normalization, and basic styles for HTML elements
4. Layouts: Layout-related styles, can have elements and states(structure/skin), page templates
5. Components: Reusable components, can have elements and states(structure/skin)
6. Exceptions: Styles used exceptionally. e.g. Using values not present in design tokens, Increasing CSS specificity, Use !important

In this article, we will refer to it as the SCALE(Scalable, Composable, Adaptive Layered Expression) CSS methodology.

7.2 Design Tokens

The above discussion considered the aspect of management but did not take into account the design system.

A representative element of design systems is design tokens.
Design tokens store repetitive design decisions as a single source of truth.

Simply put, it's like saving a color palette from a vast color space and using it consistently across the project.

However, design tokens are not just simple 'settings'. They need to be set at both the app and component levels, and they function similarly to reactivity. [paste - design tokens, Tokens, variables, and styles]

Design tokens, like styles, are defined from simple to specific.

1. Primitive tokens: Define the most basic design values such as colors, fonts, sizes, spacing, etc.
   • These have the lowest level of abstraction and contain specific values.
   • Example: color-blue-500: #0000FF, font-size-16: 16px
2. Semantic tokens: Semantic tokens are tokens that give meaning based on primitive tokens.
   • They use abstracted names that represent the purpose or intention of the design.
   • They are defined by referencing primitive tokens.
   • Example: color-primary: $color-blue-500, font-size-body: $font-size-16
3. Component tokens: Component tokens define design values thar are applied to specific UI components.
   • These are tokens that are directly applied to actual UI components.
   • They are mainly defined by referencing semantic tokens. (Sometimes primitive tokens can also be directly referenced)
   • Example: button-primary-color: $color-primary

Naming is important for semantic tokens.

7.3 Atomic CSS

Atomic CSS, as we have seen earlier, is one of the major paradigms and is both a useful tool and a controversial topic.
However, when we examine Atomic CSS, it can mean various things:

1. Atomic CSS as usage: Can various types of visual styles be written easily in className?
2. Atomic CSS as scope: Should it be applied globally or only to parts?
3. Atomic CSS as a framework: Does it have a well-defined design system?
4. Atomic CSS as output: Is it converted to single-property classes after build?

Here, we will analyze each case and derive its advantages and disadvantages, focusing primarily on Tailwind CSS, a representative Atomic CSS Framework, while also examining why we need on-demand global atomic CSS.

7.3.1 Atomic CSS as Usage

It can be used like inline CSS.
You don't need to name it, and it's located even closer than co-location, making it very convenient when the scale is small or when creating prototypes.

• This greatly reduces the time spent writing separate CSS files and class names.
• Styles can be applied intuitively.

<!-- PrimaryButton.vue -->
<template>
  <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
    <slot></slot>
  </button>
</template>

However, it's different from inline styles:

1. Limitations: No limitations such as media queries, selectors, pseudo-elements, animations, etc.
2. File size: File size is reduced as it's defined only once for use.
3. Naming: Each name is short and concise, making it good for typing.
4. Value type: It's a string value.

Except for number 4, all are good characteristics.
Number 4 is a definite drawback as it's difficult to utilize type systems and highlighting.
What if we express it in CSS in JS like this:

css([
  {
    bg: {
      base: "blue-500",
      _hover: "blue-700",
    },
    text: "white",
    font: "bold",
    py: 2,
    px: 3,
  },
  "rounded",
]);

Number 3 can also be controversial, but the bigger issue is how to define the ubiquitous language in the design system.
If necessary, you can use the CSS property names as they are.

Finally, the usesage of Atomic CSS itself can be controversial(1, 2).
While it certainly has the drawback of lack of meaning, web development has changed.
With most solutions now having the front-end directly modify HTML and CSS. The era when dynamic pages became necessary in the early days of web development, leading to the emergence of backend technologies like PHP/JSP/Django to generate HTML, and when semantic CSS was absolutely necessary for styling interfaces with the frontend has now passed.

7.3.2 Atomic CSS as Scope

Atomic CSS should be used globally. (image source)

Why has TailWind CSS succeeded, unlike traditional Atomic CSS?
The most significant feature of Tailwind CSS is its utility-first approach.

Previously, it was either used partially like Bootstrap's Helpers or had to be built from scratch.
Partial use is literally closer to utilities or helpers, making it difficult to fully utilize the advantages of Atomic CSS, such as minimal file size increase.
Conversely, building a comprehensive system from scratch is prone to exceptions and difficult to maintain consistently, unlike semantic methodologies that can directly utilize product domain meanings or component structures.

However, Tailwind provides a design system that allows global use of Atomic CSS.
It maps CSS properties to design tokens and designates all available styles as a single source of truth.

To utilize Atomic CSS well, we should prevent one-time style additions and apply it globally!!

7.3.3 Atomic CSS as a Framework

To apply it globally, it's essential to have a framework that allows using predefined classes.
This article doesn't aim to create a CSS framework itself, so we'll skip that.

However, mapping CSS properties to design tokens is an important part as a meta-design system.
We need to provide a way to map according to the theme specifications of Theme UI or Styled System.

7.3.4 Atomic CSS as Output

As seen in 6.1.3 Style Output and Apply, even if the input is not Atomic CSS, Atomic CSS can be generated in the output.
Here, we argue that we should have global atomic CSS as a single source of truth, so we'll skip this as well.

However, generating all styles to create a single source of truth for mapping CSS properties to design tokens is inefficient.
It will become unbearable due to the Combinatorial Explosion.

Styles should be generated only for the rules used on-demand, according to a set of rules that map CSS properties to design tokens based on theme specifications.

Yes, we need on-demand global atomic CSS.

7.4 Variants

Atomic CSS is convenient as it can be written without the need to name classes.
However, what about when we need to handle complex states?

Variants(Modifier) are visual representation that compresses the Option, State, and Context discussed in the design system.

It's also known for its API introduced by Stitches.

The Stitches Variants API is innovative.
It allows for declarative description of each state style of the modifier.

const Button = styled("button", {
  // base styles

  variants: {
    color: {
      violet: {
        backgroundColor: "blueviolet",
        color: "white",
        "&:hover": {
          backgroundColor: "darkviolet"
        }
      },
      gray: {
        backgroundColor: "gainsboro",
        "&:hover": {
          backgroundColor: "lightgray"
        }
      }
    }
  }
});

() => <button color="violet">Button</button>;

What's even more impressive is that you can declaratively express everything from the default value of a Variant to when interactions occur between Variants.

const Button = styled("button", {
  ...styles,

  variants: {
    color: {
      violet: { ...violetStyles },
      gray: { ...grayStyles }
    },
    outlined: {
      true: { ...outlineVariants }
    }
  },

  defaultVariants: {
    color: "violet"
  },

  compoundVariants: [
    {
      color: "violet",
      outlined: true,
      css: {
        color: "blueVariantsviolet",
        borderColor: "darkviolet",
        "&:hover": {
          color: "white"
        }
      }
    },
    {
      color: "gray",
      outlined: true,
      css: {
        color: "gray",
        borderColor: "lightgray",
        "&:hover": {
          color: "black"
        }
      }
    }
  ]
});

() => (
  <button color="violet" outlined>
    Button
  </button>
);

Now BEM can be expressed through the Variants API.

1. Block: File
2. Element: Each component
3. Modifier: Variants included in the component

You can immediately adhere to all constraints without relying on rule-based tools such as BEM Tools.

In traditional Atomic CSS, a tool called CVA(Class Variance Authority) makes this possible.
Since we will be using CSS in JS approach, our method will be slightly different.

7.5 Layers for Style

For the expression of style(CSS) to actually appear, there must be elements(HTML) as content, and dynamic application(JavaScript) should also be considered.
To prevent repetitive styles, pre/post-processors or JavaScript are also needed. (image source)

This is similar to the relationship between JSX and State.

For the expression of JSX to actually render, there must be state as dynamic content.
CSS is essential for visual styling, as JSX and state management alone cannot fully express design aesthetics.
To achieve consistent and maintainable styling, CSS should be strategically integrated with JSX and state management, creating a unified approach to building user interfaces.

From a JavaScript perspective, the layers would be as follows:
Referencing Adobe Spectrum Architecture and The future of Chakra UI.

1. JSX: Binds HTML/Widget and JS
2. State hook: Logic independent of view platform
3. Behavior hook: Handles events, accessibility, internationalization, etc. for platform APIs (DOM, React Native, etc.)
4. Headless Component: Provides binding of JSX and hooks for use
5. Component: Component blocks including design

From a style perspective, it appears as follows:

1. Literal: CSS pre/post-processors or CSS-in-JS, considering repetitive use of CSS, etc.
2. Theme: Design token values and customization for Color, Typography, Spaces, etc.
3. Atomic: Atomic styles that map to visual values
4. Variants: Styles for reusable blocks
5. Styled Component: Binding with JSX components

This will be referred to as StyleStack.

7.6 Combination with Methodologies and Folder Structure

Let's combine the StyleStack Layer with SCALE CSS methodology for management.
The methodologies focus more on Form than Substance, while the style layers focus more on Expression than Content, so there will inevitably be some discrepancies despite seeming similar. (image source)

If you need more explanation about the relationship between Expression-Content and Form-Substance, I recommend reading Rock-Paper-Scissors: A Linguistic Approach to Games.
Basically, it follows the perspective of Hjelmslev's semiotics.

1. Literal: Closer to elements constituting Substance, so it's not here.
2. Theme: Corresponds to Configs.
3. Atomic: Belongs to Utils, right?
4. Variants: Modifiers, so they'll belong to Layouts and Components.
5. Styled Components: Also close to binding to Elements, so they'll belong to Layouts and Components.

Bases and Exceptions don't have separate matches.
Bases are Content made from Literal, and Exceptions are closer to Content that occurs at the component level.

For StyleStack layers and SCALE CSS methodology to complement each other, they should each have Content and Substance, right?
For style layers to have Content, people need to write the content, so there's nothing to do right away.

On the other hand, how about making the methodology into Substance?
It's possible to some extent by creating a Form for the folder structure.

1. Configs: It's better to separate global variables and design tokens.
2. Utils: It's better to separate Atomic CSS (core-style) and simple utilities.
3. Bases: Usually, reset/normalization is imported from libraries, so it's okay to define it together in global css.
4. Layouts: Use as is. However, for page templates, as mentioned earlier, using app/ or layouts/page-template is also good.
5. Components: Use as is.
6. Exceptions: In cases where !important is used, gathering and managing them together is one approach.

src/
├── styles/
│   ├── constants/: Configs - Global variables
│   ├── theme/: Configs - Design Tokens definitions
│   ├── core-styles/: Utils - Atomic CSS definitions
│   ├── utils/: Utils - Mixins and style-related functions
│   └── expetions/: Exeptions - Collection of exceptions
├── app/
│   ├── layout.tsx: Layouts - Page templates
│   ├── page.tsx
│   ├── global.css: Bases - Normalization and global styles
│   └── [pages]/
├── assets/
├── components/
├── layouts/
└── .../

Now, let's focus more on Expression(StyleStack layer) and think about it.

8. Why CSS in JS?

Now that we've finished defining the StyleStack layer, we need to implement a natural connection from Literal to Styled Component. (image source)

First, should we use pre/post-processors or Javascript to extend Literal CSS?
One of the original advantages of CSS in JS, isolation, has been offset by CSS Modules and @layer.
Conversely, since the features of post-processors can be used in CSS in JS, we don't consider them.

8.1 Preprocessors

1. Learning curve: Since it's an extension of CSS, it's easy to adapt and existing CSS code can be used as is.
2. Highlighting and auto-completion: You can use the highlighting and auto-completion provided by the editor as is.
3. Mixins and CSS-specific syntax: Control flow and @content allow you to easily add styles just by declaring styles where needed without object manipulation or returns. Less's property merging and Stylus's Property lookup are also interesting features.
4. CSS-specific utilities: It includes features like SASS's color module and calc() optimization.
5. Ecosystem: There's infrastructure like Stylelint and Critical CSS.

8.2 CSS in JS

1. Code sharing: You can immediately use all of Javascript's functions, variables, and rich libraries.
2. Javascript: You only need to learn Javascript. Also, Javascript provides more robust capabilities for complex object manipulation and flow control compared to preprocessor.
3. References: Dependencies are explicit, and features like go-to-definition and refactoring can be used immediately. Vue partially supports this, but it's not possible when nested. It's also a great help in removing zombie code.
4. Dynamic styles: Features like values changing according to props or compound variants are easy to write and integrate in CSS in JS.
5. Co-location: You can write styles in the same file as the component.

8.3 So, Why CSS in JS

Many of the advantages available in preprocessors can be relatively easily achieved by investing in the tooling infrastructure of CSS in JS.

• Highlighting and auto-completion: It's possible with tools like vscode-styled-components, and there are precedents for copy and paste as well.
• CSS-specific utilities: Can be complemented with a nice library called polished.
• Ecosystem: linaria has proven that source maps, linting, etc. can be used.

With a little effort, you can even mimic usage similar to @mixin.

function mediaQuery(breakpoint) {
  const breakpoints = {
    tablet: "@media (min-width: 768px) and (max-width: 1023px)",
    desktop: "@media (min-width: 1024px)",
  };

  if (breakpoint in breakpoints) {
    return (styles) => ({
      [breakpoints[breakpoint]]: styles,
    });
  } else {
    // or use throw
    console.warn("Unknown breakpoint: " + breakpoint);
    return () => ({});
  }
}

// Usage example
const responsiveElement = css({
  fontSize: 16px,
  ...mediaQuery("tablet")({
    fontSize: "18px",
  }),
  ...mediaQuery("desktop")({
    fontSize: "20px",
  }),
});

Of course, go-to-definition is not exclusive to CSS in JS. It's possible through CSS Module extensions.
However, there are many constraints in sharing Javascript variables and using libraries, dynamic styles, and co-location (possible in SFC).
Crucially, there's also the point that JavaScript runtime is ultimately necessary for creating Styled Components, which is the final step of StyleStack.

I think there's still a lot of room for improvement in CSS in JS infrastructure, and it has relatively fewer constraints.
For these reasons, despite quite liking preprocessors like Sass, I believe investing in CSS in JS is the right path.

9. Introduce project mincho

I would like to introduce you to the project that will proceed based on the content discussed so far.

• mincho-js/mincho

9.1 Motivation

The original motivation for starting my project was to unify the Atomic CSS and SemanticCSS methodologies. From a semiotic approach, I believed that this could be sufficiently represented as Expression and Content using the Sign function.

項目名稱很早就決定了。
在韓國，薄荷巧克力縮寫為「Mincho(민초)」，與香草一起，它是我最喜歡的冰淇淋口味之一。
薄荷巧克力的獨特之處在於其對比鮮明的口味組合，將薄荷的清涼口感與巧克力的香甜順滑口感融為一體。
這就是這個想法的來源：

1. Atomic CSS（好）變體（好）的組合 = 更像薄荷巧克力。
2. 我計劃將其基於一個名為 Vanilla Extract 的庫。
3. 是我喜歡的味道。最個性化的就是最有創意的，不是嗎？ ？

9.2 為什麼要使用香草精？

選擇香草精作為該項目的基礎有幾個原因。

1. 型別安全： 它的創建重點是型別安全。
2. 零運行時間：正如「6.1.1 整合」中所提到的，考慮到 RSC 的未來，這一點非常重要。
3. API：基本設計，例如Composition API，非常乾淨。
4. 功能：現有的Style、StyleVariants、Theme、Recipe等功能已經夠強大，值得參考。
5. 約束： 防止封裝破壞操作，如 .selector > * 在建置時。
6. 潛力：雖然目前無法實現共置，但參考 Macaron 表明它應該是可能的。

9.3 簡要計劃

我們無法從一開始就提供所有功能，我們計劃逐步實現。

1. TypeScript 中的自然 CSS： 我們將綁定各種專門針對 TypeScript 的 CSS 預處理功能。
2. 可擴展的 JS 中的 CSS： 支援並整合 StyleStack（主題、原子 CSS、變體和樣式元件）層，使得管理大規模樣式成為可能。
3. 建立您自己的設計系統：它充當透過 Figma 插件和文件系統等創建設計系統的框架。

在撰寫本文時，「TypeScript 中的自然 CSS」階段已接近完成，我希望在今年內實作 A CSS in JS for Scalable。

由於它目前正在進行中 (WIP)，因此 API 不穩定。
圍繞A CSS in JS for Scalable 階段的完成，計劃進行重大API 檢修，這將綜合考慮小型API 表面、改進的類型安全性、SSR（和伺服器組件）支援以及Vanilla Extract 兼容性.
例如，雖然我們努力確保與香草精的使用最大程度相容，但隨著專案的進展可能會出現差異，並且操作方式也不可避免地存在差異。
因此，我們故意將函數命名為與 Vanilla Extract 不同的（通常使它們更簡潔），並且我們計劃為相容的 API 創建一個單獨的 compat 套件。

以下是我們對StyleStack API 設計方向和後續計畫的想法。

10. JS 中 CSS 友善的 CSS

專門從事CSS處理代表什麼？
除了前面提到的工具基礎架構之外，我們還可以考慮針對 CSS 進行語法最佳化。

讓我們想像JS中的CSS依照各種條件從頭開始。

10.1 模板字串與物件樣式

• CSSinJS 中的範本字串與物件

CSS 的世界 在 JS 中，有兩種表達 CSS 的方式：
模板字串和物件樣式。

範本字串似乎比較適合簡單使用。
這是因為您可以原樣使用 CSS 屬性和語法。

但是，物件樣式與CSSOM的表達方法相同，當需要大量插值時，這是一個更好的方法。

使用 TypeScript 時，還有支援類型的優點。
在 JS 中使用 CSS 的原因基本上是為了處理許多規則並與 JS 互動。
因此，在 JS 中使用 CSS 時，建議主要使用物件樣式。

If there are few design rules and interaction with JS is unnecessary, it's better to use a CSS preprocessor.

10.2 Overcoming Syntax

The fundamental limitation of CSS In JS is that CSS syntax is not literal.

Because of this, color codes basically don't work with pickers in editors, and CSS units (px, rem, vw, etc.) and values (visible, space-between, etc.) cannot be used without treating them as strings.

const sample = css({
  // Color
  color: "red",
  background: "#EEEEEE",

  // Unit
  fontSize: "16px",
  fontSize: "1rem",

  // Value
  visibility: "visible",
  justifyContent: "space-between"
});

Fortunately, there is an extension for color picker.

For properties that receive common values like px, you could define them like JSS's default-unit or Vanilla Extract's unitless property.

const sample = css({
  // cast to pixels
  padding: 10,
  marginTop: 25,

  // unitless properties
  flexGrow: 1,
  opacity: 0.5
});

10.3 SCSS and Nested Syntax

The area where SCSS took the lead is nested syntax.
As you've seen earlier, it supports attribute nesting, parent selector nesting using &, and even nesting of @at-rules like @media.

.sample {
  width: 200px;
  font: {
    /* Property Nested */
    size: 10px;
    weight: bold;
  }

  /* Selector Nested */
  a & {
    background: grey;
  }
  &:hover {
    background: blue;
  }

  /* At rule Nested  */
  @media (prefers-color-scheme: dark) {
    color: red;
  }
}

This is made possible by using several rules:

• Nesting occurs when it's an object rather than a regular value, and since kebab-case is converted to camelCase, nested properties also follow the rules
• If an attribute contains & like in Emotion, it is treated as a selector
• Simple selectors like "&:hover" can be used as :hover, reducing unnecessary &, similar to vanilla extract's Simple pseudo selectors, for Pseudo-classes and Pseudo-elements

const sample = css({
  width: 200,
  font: {
    Size: 10,
    Weight: "bold"
  },

  "a &": {
    background: "grey"
  },
  ":hover": {
    background: "blue"
  },

  "@media (prefers-color-scheme: dark)": {
    color: red;
  }
});

Let's think about how to make it a little more convenient.
Like Panda CSS's Conditional Styles, we can use _ instead of : and use camelCase to make it immediately usable in properties. (Only _ and $ are special characters that can be used immediately in JavaScript properties)

If there's an issue with the Panda CSS approach, it's the ad-hoc nature of inserting arbitrary classes, such as _dark meaning &.dark, .dark &.
This might be acceptable for framework presets, but it's not suitable for applying as a literal syntax.

const sample = css({
  background: "#EEEEEE",
  _hover: {
    background: "blue"
  },
  __before: {
    background: "grey"
  },

  // Or
  background: {
    base: "#EEEEEE",
    _hover: "blue",
    __before: "grey"
  }
});

When nesting at-rules, we could group them together if they're the same rule, or we could utilize Conditional Styles.

const sample = css({
  background: "#EEEEEE",
  "@media": {
    "(min-width: 768px) and (max-width: 1023px)": {
      background: "blue"
    },
    "(min-width: 1024px)": {
      background: "grey"
    }
  },

  // Or
  background: {
    base: "#EEEEEE",
    "@media (min-width: 768px) and (max-width: 1023px)": "blue",
    "@media (min-width: 1024px)": "grey"
  }
});

Of course, excessive use of nesting can cause problems, so it would be good to set a maximum nesting count as an ESLint rule or similar.

10.4 Less and Merge properties

One of the main characteristics of Less is that it's lazy.
However, since JavaScript is strict by default, I think this approach is not suitable for applying to CSS in JS.

However, the Merge properties feature appears to be quite useful.
This is because long properties like box-shadow or transform were difficult to write in a single line.

.sample {
  /* Merge with Comma */
  box-shadow+: inset 0 0 10px #555;
  box-shadow+: 0 0 20px black;

  /* Merge with Space */
  transform+_: scale(2);
  transform+_: rotate(15deg);
}

.sample {
  box-shadow: inset 0 0 10px #555, 0 0 20px black;
  transform: scale(2) rotate(15deg);
}

As mentioned earlier, only _ and $ can be used as special characters in JavaScript.
Since space is similar to _, it would be good to add $ to commas.

• Since you can't have the same key multiple times, values are represented as arrays
• If it ends with $, join with ,, if it ends with _, join with a space

const sample = css({
  boxShadow$: ["inset 0 0 10px #555", "0 0 20px black"],
  transform_: ["scale(2)", "rotate(15deg)"]
});

10.5 Stylus and References

Stylus provides several features for referencing.
Both Partial Reference and Relative Reference seem to have a high potential for causing mistakes.
Moreover, given the nature of CSS in JS, which is designed around components and doesn't require much nesting, the likelihood of needing these is low.

However, property value referencing could be beneficial.
It seems useful as it can eliminate unnecessary variables, and if there's no reference target, it can be displayed as an error at build time.

const sample = css({
  width: 100,
  marginLeft: "@width",
  marginTop: "calc(-(@width / 2))"
});

9.6 PostCSS and CSS Extensions

PostCSS uses standard CSS syntax, so it can be used together with CSS in JS.

Among them, postcss-preset-env extends various syntaxes by default.
For example, there are convenient media query ranges.

const sample = css({
  "@media (480px 





<pre class="brush:php;toolbar:false">@media (min-width: 480px) and (max-width: 767.98px) {
  .sample {
      font-family: system-ui, -apple-system, Segoe UI, Roboto, Ubuntu, Cantarell, Noto Sans, sans-serif;
  }
}

11. Scalable CSS in JS

In CSS-friendly CSS in JS, we explored methods to appropriately express CSS in Javascript.
Now, we need to manage CSS interactions with other CSS and Javascript.

Since runtime caused problems with scalability, we will try to deal with Zero runtime or Near Zero Runtime cases whenever possible.

11.1 Composition

In practice, using multiple CSS classes together is more common than applying just one.

In this case, we can use Composition.
If you want to focus only on class names, clsx is also a good option.

const base = css({ padding: 12 });
const primary = css([base, { background: "blue" }]);
const secondary = css([base, { background: "aqua" }]);

.styles_base__1hiof570 {
  padding: 12px;
}
.styles_primary__1hiof571 {
  background: blue;
}
.styles_secondary__1hiof572 {
  background: aqua;
}

Vanilla Extract's method excellently reduces CSS output.
However, there are specificity issues. It would be more intuitive if the last style was always applied, as it is in Emotion.

const danger = css({
  color: "red"
});
const base = css({
  color: "yellow"
});
const sample = style([base, danger]); // `base` is applied

We can partially solve this by declaring and merging objects, or by directly specifying the color(since .sample is declared after .base). However, we need to consider the potential increase in output size with these approaches.

const danger = {
  color: "red"
};
const base = {
  color: "yellow"
};
const sample = style([base, danger]);

// or
const base = css({
  color: "yellow"
});
const sample = style([base, {color: "red"}]);

Since Atomic CSS also has the Shorthand-Longhand problem, we should always keep specificity issues in mind when dealing with composition.

11.2 UI = f( State )

As React and Flutter assert, UI can be thought of as a function.

Then, is there any reason why Style shouldn't be a function?
This is the same approach as Fela's principles, and following this philosophy, Flutter implements even Padding as a widget.

const sample = css((props) => ({
  color: "red",
  background: props.bgColor
}));

function Sample() {
  return <div classname="{sample({" bgcolor:>content</div>;
}

.sample {
   color: red;
   background: var(--sample-bgColor)
}
.SampleComponent.sample {
  --sample-bgColor: blue;
}

It's not good to have different usages or return values from a single function.
Therefore, interfaces should be separated.

// Return string(class name)
const static = css({
  color: "red",
});

//  Return function
const dynamic = rules(({ color }) => ({
  color,
  background: ({ bg } = { bg: "blue" }) => bg
}));

11.3 Making it Declarative

The previous example would work well in CSS in JS with runtime, but not in zero-runtime CSS in JS.
As seen in the cases of StyleX and PigmentCSS, dynamic styles are quite limited.

const dynamic = rules(({ color }) => ({
  color,
  background: ({ bg } = { bg: "blue" }) => bg
}));

Also, traversing the AST to evaluate dynamic styles is a rather arduous task.
Is it possible to create a declarative approach similar to the Variants example previously mentioned as an effective declarative API?
The above cases could be represented as follows:

const dynamic = rules({
  props: ["color", { bg: { base: "blue", target: "background" }}]
});

You might want arbitrary Props only when using specific variants.

// Same behavior
const sample1 = rules((props) => {
  if("color" in props) {
    if(props.color == "white") {
      return ({
        color: "#EEEEEE",
        background: props.background
      });
    }
  }
});

const sample2 = rules({
  variants: {
    color: {
        white: [{ color: "#EEEEEE" }, "background"]
      }
    }
  }
});

sample2({ color: "white", background: "red" });

It would be convenient if we could create Styled Components with Props specified based on Rules, wouldn't it?

const Container = styled.div([
  sample2,
  {
    display: "flex",
    variants: { vertical: { true: { flexdirection: "column" } } },
  },
]);
function Sample() {
  return (
    <container color="white" background="black" vertical>
      text
    </container>/>
  );
}

By creating it this way, you can make styled components as conveniently as with Styled System.

11.4 Atomic CSS

We've briefly explored simple and dynamic concepts, and addressed Variants, which transformed BEM, a prominent semantic CSS methodology, into a declarative approach.

Recall the primary objective of Atomic CSS in comparison to semantic CSS.

Styles should be generated only for the rules used on-demand, according to a set of rules that map CSS properties to design tokens based on theme specifications.

How can we ensure that styles are generated only for the rules being used?
Looking at various issues(#91, #992, #1132, #1237) with Vanilla Extract, it doesn't seem easy.

A potential approach involves creating rules and utilizing them with the previously defined css(), rules(), and styled() functions, while caching each property-value pair.
By creating it this way, you can achieve Tailwind's usage and Windi CSS's Attributify Mode in a near on-demand manner without the complex regular expressions of UnoCSS.

const { css, rules, styled } = defineRules({ /* Something */ });

const sample1 = css(["inline", { px: 2, c: "indigo-800" }]);
const sample2 = rules({
  px: 4,
  variants: {
    color: {
        white: [{ c: "white-100" }, "bg"]
      }
    }
  }
});
const Sample3 = styled.div([saple2]);

While '11.1 Composition' may cause specificity issues, it can mitigate the problem by behaving similarly to tailwind-merge at build time.

While not yet fully established, we can propose a Draft API as follows:
When strict mode is true, only shortcuts and toggles can be used instead of properties.

const { css, rules, styled } = defineRules({
  // Whether to allow properties attributes - allow only toggles or shortcuts
  strict: true,

  // Restrictions on features available in CSS
  properties: {
    // Allow only values in arrays
    display: ["none", "inline"],
    paddingLeft: [0, 2, 4, 8, 16, 32, 64],
    paddingRight: [0, 2, 4, 8, 16, 32, 64],

    // Allow only values in objects
    color: { "indigo-800": "rgb(55, 48, 163)" },

    //Entire properties
    background: true,
    border: false
  },
  shortcuts: {
    pl: "paddingLeft",
    pr: "paddingRight",
    px: ["pl", "pr"],
    c: "color",
    bg: "background"
  },
  toggles: {
    inline: { display: "none" }
  }
});

However, mapping every element individually may prove cumbersome.
The availability of predefined sets, similar to the ThemeUI spec, would greatly enhance convenience.
You might want to map not only the property values but also shortcuts and toggles like tailwind.

const { css, rules, styled } = defineRules({
  // Restrictions on features available in CSS
  properties: themeUISpec({
    colors: { "indigo-800": "rgb(55, 48, 163)" }, // color, background, accentColor, ...
    space: [0, 2, 4, 8, 16, 32, 64] // margin, padding, inset, top, ..
  }),
   ...twindShorcutSpec() // Predefined shortcuts and toggles like the tailwind API
});

The provision of such diverse presets would significantly simplify the creation and utilization of Atomic CSS.
And, like PandaCSS's Conditional Styles, it will be necessary to provide various conditions.

const { css, rules, styled } = defineRules({
  defaultCondition: ["light", "vertical"],
  conditions: {
    light: "",
    dark: ["&.dark", ".dark &"],
    osLight: {},
    osDark: { "@media": "(prefers-color-scheme: dark)" },
    horizontal: "&[data-orientation=horizontal]",
    vertical: "&[data-orientation=vertical]"
  },
  compoundConditions: [
    {
      when: ["light", "osLight"],
      condition: "&.pureLight"
    },
    {
      when: ["dark", "osDark"],
      condition: "&.pureDark"
    }
  ]
});

11.5 Theme

Let's discuss the Theme concept mentioned in Atomic CSS in more detail.
Themes are mappings of design tokens, and as we saw in Atomic CSS, they typically have two structures.
Of course, we could also follow the W3C Design Token Format.

const theme = {
  spaces: [0, 2, 4, 8, 16, 32, 64],
  colors: {
    "black-100": "#000",
    "white-100": "#fff",
    "blue-500": "#07c"
  }
};

We need to consider the scalability across primitive tokens, semantic tokens, and component tokens.
For primitive tokens, we can create subgroups for categories like color:

const [, tokens] = theme({
  spaces: [0, 2, 4, 8, 16, 32, 64],
  colors: {
    black: {
      100: "#000"
      // ...
    },
    white: {
      100: "#fff"
      // ...
    },
    blue: {
      // ...
      500: "#07c"
    }
  }
});

Let's consider semantic tokens.
While they can be isolated like component tokens, semantic tokens are often used globally at the application level.
Therefore, we need to design them to handle derivable tokens.

const [, tokens] = theme({
  // Main values
  values: {
    spaces: [0, 2, 4, 8, 16, 32, 64],
    colors: {
      black: {
        100: "#000",
        // ...
      },
      white: {
        100: "#fff"
        // ...
      },
      blue: {
         // ...
        500: "#07c"
      }
    }
  },

  // Derived values
  alias: ({ spaces, colors }) => ({
    spaces: {
      small: spaces[2],
      medium: spaces[3],
      large: spaces[5]
    },
    colors: {
      text: colors["white-100"]
      primary: colors["blue-500"]
    }
  })
});

Component tokens should be isolated by component and be derivable.

const [, tokens] = theme({ /* Something */ });
const buttonPrimary = token(tokens.colors.primary);

While it may seem we've covered most aspects of tokens, there's more to consider.
We also need to consider applying tokens in modes (conditions) such as Dark and Light.
It would be fine to manually combine Light and Dark in css() or rules(), but if we want values that automatically switch based on conditions, we run into circular dependency issues with Atomic CSS(defineRules).

I'm currently considering how to express this aspect more elegantly.
However, if we forgo automatic conversion based on conditions, the current structure should suffice.

const { css } = defineRules({
  // ...
  properties: {
    paddingLeft: tokens.spaces,
    paddingRight: tokens.spaces,
    color: tokens.colors,
  }
  // ...
});

A potential solution is to make the result of defineRules() include theme() as well.

11.6 Looking Back

It seems we've achieved to some extent the concept of the StyleStack layers we defined earlier, '7.5 Layers for Style'.

1. Literal: Provides various CSS-specific syntax of CSS preprocessors, considering the syntactic limitations of JavaScript. Use css().
2. Theme: Design token values and customization for Color, Typography, Spaces, etc. Use theme().
3. Atomic: Atomic styles that map to visual values. Use defineRules()
4. Variants: Styles for reusable blocks. Use rules()
5. Styled Component: Binding with JSX components. Use styled()

We have created a hypothetical syntax and library API that is declarative and easy to write/manage.
Personally, I find the result clean and appealing, and there are several principles behind it:

1. Be declarative rather than listing out logic
2. APIs for each layer should be isomorphic
3. Expression and content presuppose each other, so they must be considered
4. The law of excluded middle applies when hierarchies(perspectives) differ

As a result, the API is very clean and consistent.

// Theme Syntax
const [, tokens] = theme({
  spaces: [0, 2, 4, 8, 16, 32, 64],
  colors: {
    black: {
      100: "#000"
      // ...
    },
    white: {
      100: "#fff"
      // ...
    },
    blue: {
      // ...
      500: "#07c"
    }
  }
});
const buttonPrimary = token(tokens.colors.primary);

// Literal Syntax
const base = css({ color: "#444" });
const sample1 = rules({ props: { bg: "background" });
const sample2 = css(["pure-class-name", base, sample1({ bg: buttonPrimary }), { width: 10 }]);

// Atomic Syntax
const { css: atomic } = defineRules({
  properties: themeUISpec(tokens),
   ...twindShorcutSpec()
});
const sample3 = atomic(["uppercase", { px: 4, _hover: { bg: buttonPrimary } }]);

// Variants Syntax
const variants = rules({
  // ... 
  variants: {
    outlined: {
      true: {
        border: "1px solid currentColor",
        background: "transparent"
      },
    },
    accent: {
      // ...
      pink: {
        backgroundColor: "pink",
        color: "white"
      },
    },
  }
});
const sample4 = variants(["outlined", { accent: "pink" }]);

// Atomic Variants Syntax
const { rules: atomicRules } = defineRules({
  properties: themeUISpec(tokens),
   ...twindShorcutSpec()
});
const atomicVariants = atomicRules({
  // ... 
  variants: {
    outlined: {
      true: {
        border: ["base", "current"],
        bg: "transparent"
      },
    },
    accent: {
      // ...
      pink: {
        bg: "pink-500",
        text: "white"
      },
    },
  }
});
const sample5 = atomicVariants(["outlined", { accent: "pink" }]);

// Styled Component Syntax
const Sample6 = styled.button([sample4, { /* Something like rules() */ }]);
const element1 = Button;

// Atomic Styled Component Syntax
const { styled: atomicStyled } = defineRules(/* Something like atomicRules() */);
const Sample6 = atomicStyled.div([sample5, { /* Something like atomic rules() */ }]);
const element2 = ;

Above all, it is possible to use only the parts of StyleStack with "as much abstraction as you want".
This is an important characteristic that enables progressive enhancement and makes scalability and migration easier.

12. CSS in JS for Design Systems

It seems quite good for programmers to manage styles.
Then, how about collaborators? (image source)

Designers primarily focus on making design decisions and creating the visual aspects of components and applications, rather than coding.
This leads to some discrepancies in integration with design tools, documentation, and so on.

Not only designers but also marketers can be considered.
Brand guidelines should be integrated into the style guide, and they will want to see A/B tests and user feedback on UI/UX at a glance.
They may also want to use design assets and templates for newsletters, social media posts, and banners, as well as manage styles for each marketing campaign.

There's also a need to follow certain rules with other developers.
For example, the depth of nested styles and the order of style alignment mentioned earlier.

12.1 Figma

Among the various design tools available, Figma is widely recognized as one of the best for UI design. Therefore, this section focuses on Figma-based workflows. (image source)

One of the problems with design was the Combinatorial Explosion.
Let's take an example.
GitHub's button component has the following conditions:

• 結構：它有leadingVisual、label、trailingVisual和trailingAction元素，這些元素可以同時出現。但是，不存在所有元素都不存在的情況。
• 形狀：有主要顏色、次要顏色、隱形顏色和危險顏色。
• 狀態：有「休息」、「懸停」、「停用」、「按下」和「焦點」狀態。
• 上下文： 有非活動和載入上下文。
• 配色：支援淺色和深色模式

如果我們計算個案數，則為 (2⁴−1)×4×5×2×2=1200。
然而，沒有設計師願意為按鈕創建 1200 個組件。

因此，我希望有以下流程：

1. 設計師和開發人員一起討論組件（需要線框圖）。
2. 設計師創建包含主要視覺選項的元件，而開發人員則實現功能。完成後，使用Figma to Code.
產生初始樣式
3. 收到設計師的解釋後，開發人員分析視覺決策並執行狀態壓縮以盡可能減少案例數量，
4. 應用設計令牌等後，使用Code to Figma建立它
5. 設計者檢查組件是否已按預期創建，如果有任何缺失規則，則更新代表性組件。
6. 使用 Figma to Code 取得該元件的實作訊息
7. 套用視覺規則，然後使用程式碼更新其餘元件到Figma

這需要兩個主要插件。 （圖片來源）

幸運的是，似乎有很多 Figma to Code 的例子。

• Figma 代碼： 設計程式碼、UxPin、故事書
• Figma 到程式碼： Anima、Builder.io、Grida、Figma-低程式碼

除了這些外掛之外，人工智慧驅動的工具還可以顯著增強修改和創建設計的過程。例如，文字到figma允許設計者根據文字描述產生Figma設計，從而簡化設計過程。

為了確保與 Figma 順利集成，特別是自動佈局、約束、位置等功能，可能需要有自己的 CSS 框架。
此框架需要與 Figma 的設計範例相容，同時也適合基於程式碼的開發。有關 Figma 整合的合適 CSS 框架的詳細討論將在另一篇文章中進行討論，以保持本概述的簡潔性。

12.2 文件

風格指南通常由設計師創建，以確保整個專案或組織的設計一致性。
為了促進這些風格指南的創建和維護，易於使用的文件工具必不可少。
Zeroheight、Frontify 和 Supernova 是代表性的例子。 （圖片來源）

對於開發者的組件文檔，有 Storybook、Histoire、Ladle 和 Pattern Lab，但對於設計師來說還不夠。

文件系統至少應具備以下功能：

1. 一起顯示設計令牌和程式碼範例
2. 提供並測試帶有狀態的互動式元件範例
3. 平行解釋設計意圖與技術實作細節
4. 互動式文件編輯器輕鬆修改
5. 搜尋整合與Algolia搜尋等
6. 版本控制追蹤
7. 與Figma集成

特別是對於版本控制跟踪，需要與 Git 集成，類似於 i18n 服務（crowdin、lokalise、pontoon .etc）。

如果我們進一步擴展，我們可以支援以下內容：

1. 工具： 國際化 (i18n) 支援、A/B 測試、響應式測試、可訪問性檢查和效能測試工具整合。
2. 儀表板：用於樣式使用統計和使用者行為模式。
3. 協作與溝通：例如即時評論/回饋以及任務分配和追蹤。
4. 管理：角色為基礎的存取控制系統。
5. 創作工具：允許內容作者根據範本立即建立輸出。
6. 自訂：排列和裝飾頁面。您可能還想包含樣式圖塊(1, 2)。

12.3 開發工具

對於一個全面的設計系統，為開發人員提供強大的工具基礎設施至關重要，包括：（圖片來源）

1. 整合Stylelint和Sourcemap等工具
2. ESLint 外掛程式/規則 用於 JS 中的 CSS
3. 編輯器值字串中的高亮和自動補全與CSS同級，以及kebab-case和camelCase之間的轉換
4. 視覺回歸測驗與 Figma/Storybook 整合的工具
5. 檢查器 喜歡 unocss

---

仍處於非常早期的階段，API 不穩定。
不過，我希望有一天 API 能穩定下來，提供工具基礎設施，讓每個人都能自由表達風格，輕鬆建立和維護設計系統！

感謝您閱讀這篇長文。
如果您覺得這個項目有趣或有幫助，如果您能為該項目加註星標。
，我將不勝感激 如果您想測試它並幫助我們改進它，請在 Twitter 上聯繫或發送電子郵件我：alstjr7375@daum.net。

更多參考資料：（不幸的是，文章/影片是韓文）

• 了解 CSS 為何在其歷史中變得困難
• 設計系統，超越形式：影片/演示
• 跨平台設計系統，1.5年記錄：影片/演示

以上是重新思考 JS 中的 CSS的詳細內容。更多資訊請關注PHP中文網其他相關文章！