CSS in JS neu denken

0. Einführung

In der Welt der Webentwicklung ist CSS ein Schlüsselelement, um Benutzeroberflächen schön und funktional zu gestalten.

Da jedoch die Komplexität von Webanwendungen zunimmt, ist die CSS-Verwaltung zu einer immer anspruchsvolleren Aufgabe geworden. Stilkonflikte, Leistungseinbußen und Wartungsschwierigkeiten bereiten vielen Entwicklern Sorgen.

Behindern diese Probleme den Fortschritt Ihrer Projekte? (Bildquelle)

Dieser Artikel befasst sich eingehend mit neuen Ansätzen zur Lösung dieser Probleme,

insbesondere CSS in JS. Ausgehend vom historischen Hintergrund von CSS deckt es ein
breites Themenspektrum ab, von modernen Styling-Methoden bis hin zu zukünftigen Designsystemen.

Der Aufbau des Artikels ist wie folgt:

1. Definition und Hintergrund von CSS in JS
   1. Was ist CSS in JS?
   2. Der Hintergrund von CSS in JS
2. Historischer Kontext von CSS und Design
   3. Der Hintergrund von CSS
   4. Der Hintergrund des Designs
   5. Der Hintergrund des Design Systems
3. Analyse von Stilmanagementmethoden und neuen Vorschlägen
   6. Wie wurden Stile verwaltet?
   7. Wie sollen Stile verwaltet werden?
4. Spezifische Implementierungspläne für CSS in JS
   8. Warum CSS in JS?
   9. Projekt Mincho vorstellen
   10. CSS-freundliches CSS in JS
   11. Skalierbares CSS in JS
5. Integration mit Designsystemen
   12. CSS in JS für Designsysteme

In diesem Artikel werden insbesondere neue Konzepte namens SCALE CSS-Methodik und StyleStack vorgestellt und ein darauf basierendes

Mincho-Projekt vorgeschlagen. Ziel ist es, CSS in JS zu implementieren, das CSS-freundlich und skalierbar ist.

Der ultimative Zweck dieses Artikels besteht darin, Entwicklern, Designern und anderen Webprojektbeteiligten die

Möglichkeit besserer Styling-Lösungen vorzustellen.

Lassen Sie uns nun im Haupttext tiefer in die Welt von CSS in JS eintauchen. Es wird eine lange Reise sein, aber ich hoffe, dass sie Ihnen neue

Inspirationen und Möglichkeiten zur Herausforderung bietet.

1. Was ist CSS in JS?

CSS in JS ist eine Technik, mit der Sie CSS-Stile direkt in Ihren JavaScript- (oder TypeScript-) Code schreiben können.

Anstatt separate CSS-Dateien zu erstellen, können Sie Stile neben Komponenten in Ihren JavaScript-Dateien definieren.

/** @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>
  );
}

Es scheint sicherlich praktisch zu sein, es in JavaScript integrieren zu können?

2. Der Hintergrund von CSS in JS

CSS in JS wurde in einer Präsentation mit dem Titel „React: CSS in JS – NationJS“ von Vjeux, einem Facebook-Entwickler, vorgestellt.

Die Probleme, die CSS-in-JS lösen wollte, waren wie folgt:

Was ist das Problem konkret?

Und wie löst CSS in JS das Problem?

Ich habe sie in der folgenden Tabelle geordnet:

	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. Codeduplizierung:Verschachtelung in CSS-Präprozessoren usw. verwenden
2. Spezifitätskriege: Atomares CSS wird für jede Eigenschaft separat definiert, sodass es bis auf die Ladereihenfolge und !important.
die gleiche Spezifität aufweist
3. Mangelnde Typsicherheit:Verwenden Sie einfach CSS in JS mit typsicherer Unterstützung.

Layout auszudrücken ist eine weitere Hürde in CSS, die durch die Interaktionen zwischen verschiedenen Eigenschaften noch komplexer wird.

CSS mag oberflächlich betrachtet einfach erscheinen, es ist jedoch nicht leicht zu beherrschen. Es ist bekannt, dass viele Menschen bereits mit der einfachen Mittelausrichtung Schwierigkeiten haben (1, 2). Die scheinbare Einfachheit von CSS kann trügen, da seine Tiefe und Nuancen es anspruchsvoller machen, als es zunächst scheint.

Zum Beispiel hat die Anzeige in CSS verschiedene Layoutmodelle: Block, Inline, Tabelle, Flex und Raster.
Stellen Sie sich die Komplexität vor, wenn die folgenden Eigenschaften in Kombination verwendet werden: Boxmodell, Responsive Design, Floats, Positionierung, Transformation, Schreibmodus, Maske usw.

Mit zunehmender Projektgröße wird es aufgrund von Nebenwirkungen im Zusammenhang mit DOM-Positionierung, Kaskadierung und Spezifität noch schwieriger.

Layoutprobleme sollten durch gut gestaltete CSS-Frameworks behoben werden, und wie bereits erwähnt, kann die Verwendung von CSS in JS zur Isolierung von Stilen Nebenwirkungen abmildern.

Dieser Ansatz löst jedoch nicht alle Probleme vollständig. Stilisolation kann zu neuen Nebenwirkungen führen, wie z. B. zu erhöhten Dateigrößen aufgrund von doppelten Stildeklarationen in jeder Komponente oder Schwierigkeiten bei der Aufrechterhaltung der Konsistenz allgemeiner Stile in der gesamten Anwendung.
Dies steht in direktem Konflikt mit den Design-kombinatorischen Explosions- und Konsistenzproblemen, die als Nächstes eingeführt werden.

Im Moment können wir Layout-Anliegen an Frameworks wie Bootstrap oder Bulma delegieren und sich mehr auf Managementaspekte konzentrieren.

4. Der Hintergrund des Designs

Im Kern ist CSS ein leistungsstarkes Werkzeug zum Ausdruck und Implementieren von Design in der Webentwicklung.

Beim Erstellen einer UI/UX sind viele Faktoren zu berücksichtigen, und die folgenden Elemente müssen in Ihrem Design unbedingt berücksichtigt werden:

1. Visuelles Design
   • Layout: Bestimmt die Struktur des Bildschirms und die Platzierung der Elemente. Berücksichtigen Sie Abstand, Ausrichtung und Hierarchie zwischen Elementen.
   • Farbe: Wählen Sie eine Farbpalette, die die Markenidentität und das Benutzererlebnis berücksichtigt. Kenntnisse der Farbtheorie sind erforderlich.
   • Typografie: Wählen Sie Schriftarten und Textstile, die zur Lesbarkeit und zum Markenimage passen.
   • Symbole und grafische Elemente: Entwerfen Sie intuitive und konsistente Symbole und Grafiken.
2. Interaktionsdesign
   • Entwerfen Sie das Verhalten von UI-Elementen wie Schaltflächen, Schiebereglern und Bildlaufleisten.
   • Sorgen Sie durch Animationen und Übergangseffekte für ein natürliches Benutzererlebnis.
   • Erwägen Sie ein responsives Design, das sich an verschiedene Bildschirmgrößen anpasst.
3. Informationsarchitektur
   • Entwerfen Sie die Struktur und Hierarchie der Inhalte, damit Benutzer Informationen leicht finden und verstehen können.
   • Entwerfen Sie Navigationssysteme, damit Benutzer problemlos zu gewünschten Orten gelangen können.
4. Zugänglichkeit und Benutzerfreundlichkeit
   • Verfolgen Sie ein integratives Design, das unterschiedliche Benutzer berücksichtigt. i18n kann ebenfalls enthalten sein.
   • Erstellen Sie intuitive und benutzerfreundliche Schnittstellen, um die kognitive Belastung der Benutzer zu reduzieren.
5. Konsistenz- und Stilleitfaden
   • Erstellen Sie einen Styleguide, um eine einheitliche Designsprache in der gesamten Anwendung beizubehalten.
   • Entwickeln Sie wiederverwendbare Komponenten und Muster, um die Effizienz zu steigern.

Die genaue Darstellung verschiedener Designelemente unter verschiedenen Bedingungen stellt eine große Herausforderung dar.
Bedenken Sie, dass Sie Geräte (Telefone, Tablets, Laptops, Monitore, Fernseher), Eingabegeräte (Tastatur, Maus, Touch, Stimme), Quer-/Hochformatmodi, dunkle/helle Themen, hohen Kontrastmodus und Internationalisierung (Sprache) berücksichtigen müssen , LTR/RTL) und mehr.
Darüber hinaus müssen je nach Benutzereinstellungen möglicherweise unterschiedliche Benutzeroberflächen angezeigt werden.

Daher ist eine kombinatorische Explosion unvermeidlich und es ist unmöglich, sie einzeln manuell zu implementieren. (Bildquelle)

Als repräsentatives Beispiel sehen Sie sich die Definition und Zusammenstellung des Tab-Leisten-Layouts in meinem Firefox-Theme an.
Obwohl nur das Betriebssystem und die Benutzeroptionen berücksichtigt werden, führt eine Datei mit etwa 360 Zeilen zu einem Kompilierungsergebnis von etwa 1400 Zeilen.

Die Schlussfolgerung ist, dass eine effektive Designimplementierung von Natur aus skalierbar sein muss und typischerweise entweder programmgesteuert oder durch klar definierte Regelsätze verwaltet werden muss.
Das Ergebnis ist ein Designsystem für konsistentes Management im großen Maßstab.

5. Der Hintergrund des Design Systems

Designsysteme dienen als einzige Quelle der Wahrheit und decken alle Aspekte des Designs und der Entwicklung ab, von visuellen Stilen bis hin zu UI-Mustern und Code-Implementierung.

Laut der Nielsen Norman Group umfasst ein Designsystem Folgendes:

• Style Guides: Dokumentation, die Stilrichtlinien zu spezifischen Stilanforderungen bietet, einschließlich Marke, Inhalt und visuellem Design.
• Komponentenbibliothek: Diese spezifizieren wiederverwendbare einzelne UI-Elemente, zum Beispiel Schaltflächen. Für jedes UI-Element werden spezifische Design- und Implementierungsdetails bereitgestellt, einschließlich Informationen wie anpassbaren Attributen (Größe, Kopie usw.), verschiedenen Zuständen (aktiviert, Hover, Fokus, deaktiviert) und dem wiederverwendbaren, sauberen, kompakten Code für jedes Element Element.
• Musterbibliothek: Diese spezifizieren wiederverwendbare Muster oder Gruppen einzelner UI-Elemente aus der Komponentenbibliothek. Beispielsweise sehen Sie möglicherweise ein Muster für einen Seitenkopf, der aus einem Titel, einem Breadcrumb, einer Suche sowie einer primären und sekundären Schaltfläche bestehen könnte.
• Designressourcen: Damit Designer die Komponenten und Bibliotheken tatsächlich verwenden und entwerfen können, ist eine Designdatei erforderlich (normalerweise in Figma). Ressourcen wie Logos, Schriftarten und Schriftarten sowie Symbole sind normalerweise auch enthalten, damit Designer und Entwickler sie verwenden können.

Designsysteme sollten als Schnittstelle für Designer und Entwickler fungieren und Funktionalität, Form, Zugänglichkeit und Anpassung unterstützen.
Aber Designer und Entwickler denken anders und haben unterschiedliche Perspektiven.

Lassen Sie uns Komponenten als Linse nutzen, um die Unterschiede zwischen den Perspektiven von Designern und Entwicklern zu erkennen!!

5.1 Komponentenstruktur

Der Designer sollte auch entscheiden, welches Symbol für das Kontrollkästchen-Steuerelement verwendet wird.

Designer neigen dazu, sich auf die Form zu konzentrieren, während sich Entwickler eher auf die Funktion konzentrieren.
Für Designer ist ein Knopf ein Knopf, wenn er zum Drücken einlädt, während er für Entwickler ein Knopf ist, solange er gedrückt werden kann.

Wenn die Komponente komplexer ist, könnte die Kluft zwischen Designern und Entwicklern noch größer werden.

5.2 Überlegungen zum Designer

• Visuelle Optionen: Das Erscheinungsbild ändert sich entsprechend den eingestellten Optionen wie Primär, Akzent, Umrissen, Nur Text usw.
  

• Statusoptionen: Das Erscheinungsbild ändert sich je nach Status und Kontext
  

• Entwurfsentscheidung:Bestimmen von Werten mit Komponentenstruktur, visuellen/Zustandsoptionen, visuellen Attributen (Farbe, Typografie, Symbol usw.) und mehr.

5.3 Überlegungen für Entwickler

• Option: Konfigurierbare Anfangswerte. Visuelle Optionen sind ebenfalls enthalten. Bsp.) Umrissen, Größe
• Status: Änderungen basierend auf Benutzerinteraktion. Bsp.) Schweben, gedrückt, fokussiert, ausgewählt (markiert)
• Ereignis: Aktionen, die eine Zustandsänderung auslösen. Bsp.) HoverEvent, PressEvent, FocusEvent, ClickEvent
• Kontext: Aus Code injizierte Bedingungen, die sich auf das Verhalten auswirken. Bsp.) Schreibgeschützt, Deaktiviert

Die endgültige Form ist eine Kombination aus Option, Zustand und Kontext, was zu der oben erwähnten kombinatorischen Explosion führt.

Von diesen stimmt Option mit der Perspektive des Designers überein, während Status und Kontext dies nicht tun.
Führen Sie eine Zustandskomprimierung unter Berücksichtigung paralleler Zustände, Hierarchien, Wachen usw. durch, um zur Designer-Perspektive zurückzukehren.

• Aktiviert: Deaktiviert AUS, Gedrückt AUS, Schweben AUS, Fokussiert AUS
• Bewegt: Deaktiviert AUS, Gedrückt AUS, Bewegt EIN
• Fokussiert: Deaktiviert AUS, Gedrückt AUS, Fokussiert EIN
• Gedrückt: Deaktiviert AUS, Gedrückt EIN
• Deaktiviert:Deaktiviert EIN

6. Wie wurden Stile verwaltet?

Wie Sie vielleicht inzwischen erkannt haben, ist die Erstellung und Pflege einer hochwertigen Benutzeroberfläche harte Arbeit.

Die verschiedenen Bundesstaaten werden also von der State-Management-Bibliothek abgedeckt, aber wie wurden Stile verwaltet?
Während Methoden, Bibliotheken und Frameworks weiterhin entstehen, weil die Lösung noch nicht etabliert ist, gibt es drei Hauptparadigmen.

1. Semantisches CSS: Weisen Sie eine Klasse basierend auf dem Zweck oder der Bedeutung des Elements zu.
2. Atomic CSS: Erstellen Sie eine Klasse für jedes Stilattribut (visuell).
3. CSS in JS: Schreiben Sie in JavaScript und isolieren Sie CSS für jede Komponenteneinheit.

Unter diesen fühlt sich CSS in JS wie ein Paradigma an, das einen grundlegend anderen Ansatz zum Ausdrücken und Verwalten von Stilen verwendet.
Dies liegt daran, dass CSS in JS wie Mechanismen ist, während semantisches CSS und atomares CSS wie Richtlinien sind.
Aufgrund dieses Unterschieds muss CSS in JS getrennt von den beiden anderen Ansätzen erklärt werden. (Bildquelle)

Wenn man über den CSS-in-JS-Mechanismus spricht, fallen einem vielleicht CSS-Prä-/Postprozessoren ein.
Wenn man über Richtlinien spricht, fallen einem möglicherweise auch „CSS-Methoden“ ein.

Daher werde ich Stilverwaltungsmethoden in der folgenden Reihenfolge vorstellen: CSS in JS, Prozessoren, semantisches CSS und Atomic CSS sowie andere Stilmethoden.

6.1 CSS in JS

Was ist dann die wahre Identität von CSS in JS?
Die Antwort liegt in der obigen Definition.

Schreiben Sie in JavaScript und isolieren Sie CSS für jede Komponenteneinheit.

1. CSS geschrieben in JavaScript
2. CSS-Isolierung auf Komponentenebene

Unter anderem kann die CSS-Isolation ausreichend auf vorhandenes CSS angewendet werden, um globale Namespace- und Breaking Isolation-Probleme zu lösen.
Das sind CSS-Module.

Basierend auf dem Link zum oben erwähnten Artikel zur CSS-in-JS-Analyse habe ich die Funktionen wie folgt kategorisiert.
Jede Funktion hat Kompromisse, und diese sind wichtige Faktoren beim Erstellen von CSS in JS.

6.1.1 Integration

Besonders erwähnenswerte Inhalte wären SSR (Server Side Rendering) und RSC (React Server Component).
Das sind die Richtungen, die React und NEXT, die das Frontend darstellen, anstreben, und sie sind wichtig, weil sie einen erheblichen Einfluss auf die Umsetzung haben.

• IDE: Syntaxhervorhebung und Codevervollständigung
• TypeScript: Ob es typsicher ist
• Rahmen
  • Agnostisch: Framework-unabhängig, Bibliotheken wie StyledComponent wurden speziell für React entwickelt.
  • SSR: Stile beim Rendern auf dem Server als Strings extrahieren und Hydratation unterstützen
  • RSC: RSC läuft nur auf dem Server und kann daher keine clientseitigen APIs verwenden.

Serverseitiges Rendering erstellt HTML auf dem Server und sendet es an den Client, daher muss es als Zeichenfolge extrahiert werden und eine Antwort auf Streaming ist erforderlich. Wie im Beispiel von Styled Component können zusätzliche Einstellungen erforderlich sein. (Bildquelle)

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