Design System

Vue d'ensemble

L'apparence d'un projet tient dans un seul fichier, la charte graphique web/configurations/brand.identity.json. Au rendu de chaque page, le framework la convertit en variables CSS (--brand, --text-primary, --space-4, --radius-md...) posées sur :root, puis sur [data-theme="light"] pour le thème clair. Les blocs ne lisent que ces variables : une valeur changée dans la charte change tout le site, sans retoucher un bloc.

L'éditeur de charte écrit brand.identity.json ; à droite, l'accueil du projet reçoit les variables qui en sortent.w/[wsSlug]/p/[slug]/edit/brand

Sur ces variables, le paquet @asynccode/ac_tools construit la feuille du design system : un squelette de mise en page, une grille de 12 colonnes, des classes d'espacement, de visibilité, de typographie, de tons, de rayons et d'ombres. Les éditeurs de l'Atelier posent ces classes sur les nœuds des arbres (tree.json, structure.json). Ce qu'aucune classe n'exprime part dans le styleJson du nœud, écrit en jetons et compilé dans le style.css du bloc.

Ce que vous écrivez, ce que la page reçoit

Le fichier de charte

La charte vit dans web/configurations/brand.identity.json. Sa seule forme est un conteneur à trois clés : defaultTheme, dark et, en option, light. Le framework lit dark comme base des deux thèmes. Un fichier plat, avec les groupes à la racine, n'est pas lu : getBrand reçoit un bloc vide et n'émet que ses valeurs de repli, sans aucune couleur.

La fusion du thème clair

Le thème clair n'est pas lu seul : le framework fusionne light sur une copie de dark, en profondeur. Un objet imbriqué se fusionne clé par clé (light.palette.brand remplace dark.palette.brand et garde les autres couleurs), une valeur simple remplace. Le résultat passe par getBrand comme le bloc sombre, et le jeu complet des variables est émis une seconde fois sous [data-theme="light"].

Les valeurs de la charte sont des données : avant d'entrer dans le <style>, chaque variable passe le même contrôle qu'une valeur de styleJson (section suivante sur le styleJson). Une valeur refusée (un ;, une accolade, un <, un url( ailleurs que dans le logo) est retirée, et ce qui la lit retombe sur son propre repli.

Le schéma, groupe par groupe

Chaque groupe ci-dessous vit dans dark (et, pour ce qui change, dans light). La colonne « Si absent » dit ce que getBrand émet quand la clé manque : une valeur de repli, une variable absente (retirée du <style>), ou une valeur invalide qui casse les déclarations qui la lisent.

palette : les couleurs

Des couleurs hexadécimales à six chiffres (#rrggbb). Chaque couleur produit aussi son canal -rgb.

surface : les fonds

ink : l'encre et les filets

text est une couleur ; les six autres clés sont des opacités, de 0 à 1, appliquées à text. Toutes les nuances de texte et de filet dérivent donc d'une seule encre.

fonts : les polices

Trois rôles, sans, mono et display, chacun { family, import, fallback }. family est le nom de la famille. import est l'adresse de sa feuille Google Fonts (https://fonts.googleapis.com/css2?...), insérée en <link rel="stylesheet"> dans le <head>. fallback est la pile de repli, lue pour sans et display, limitée à des lettres, chiffres, espaces, virgules, guillemets et tirets (120 caractères).

La typographie dans l'éditeur de charte : une police pour les titres et le texte, une pour les chiffres et les étiquettes, et le champ qui ajoute une police par son nom ou son lien Google Fonts.w/[wsSlug]/p/[slug]/edit/brand

typography : tailles, interlignes, rôles

La typographie est une échelle à 13 crans : 3xs, 2xs, xs, sm, base, lg, xl, 2xl, 3xl, 4xl, 5xl, 6xl, 7xl. Chaque cran porte une taille, un interligne et un interlettrage, parce que la bonne valeur dépend du cran.

Un rôle s'écrit de deux façons. { "step": "xl" } le fixe sur un cran de l'échelle. { "min": 56, "max": 96 } le rend fluide entre 375 et 1280 px de large, avec min > 0 et max >= min. Les deux formes acceptent leading et tracking pour forcer l'interligne et l'interlettrage. Sans eux, un rôle fluide prend ceux du plus grand cran dont la taille ne dépasse pas max. Un rôle mal formé reprend sa valeur par défaut.

radii : les coins

shadows : les ombres

Des valeurs box-shadow complètes, par exemple 0 4px 12px rgba(0, 0, 0, 0.32), 0 2px 4px rgba(0, 0, 0, 0.3).

motion : les courbes et les durées

spacing : l'échelle d'espacement

Des clés numériques, écrites en chaîne dans le JSON, vers des px : "0", "1", "2", "3", "4", "5", "6", "8", "10", "12", "16", "20", "24", "32", "40". Chaque clé n donne --space-n ; la clé "1" donne aussi l'unité --u.

stroke : les traits

grid : la grille et les largeurs

layers : l'empilement

effects : la matière des surfaces

media : logo et favicon

Les groupes sans repli

Un manque produit l'un de trois effets :

• Variable absente : une couleur de palette ou de surface, les ombres soft, lg et brand, motion.easeOut, fast et base, weights.*, lineHeights.*, stroke.*. La variable n'est pas émise ; une déclaration qui la lit par var() sans repli devient invalide, et la propriété reprend sa valeur héritée ou initiale.
• Valeur invalide : spacing pour les clés 0, 1, 2, 3, 4, 6, 8, 12, 16 (--space-4: undefinedpx, --u: undefinedpx), et les opacités de ink (rgba(243, 241, 234, undefined)). La variable existe mais ne vaut rien : chaque marge, retrait, gouttière ou filet qui la lit disparaît.
• Canal noir : le -rgb d'une couleur absente, ou écrite autrement qu'en #rrggbb (#fff, rgb(...), un nom), vaut 0, 0, 0.

Référence des variables CSS

getBrand produit 249 variables par thème, toujours sous les mêmes noms ; celles dont la source manque sont retirées du <style>. Les tableaux ci-dessous les donnent toutes, famille par famille, avec leur source dans la charte. Une variable en -rgb porte les trois canaux séparés par des virgules (210, 58, 79) et s'emploie dans rgba(var(--brand-rgb), 0.2).

Marque et accents

Alias de l'interface

Les mêmes couleurs sous les noms que lisent les fragments du framework. Elles basculent avec le thème comme les autres.

États

Tons

Six tons sémantiques, chacun décliné en six variables. Dans le second tableau, * vaut primary, secondary, success, warning, danger ou info.

Surfaces et voile

Encre et filets

Polices

Échelle typographique

Chaque cran donne trois variables, lues dans typography.sizes, typography.leading et typography.tracking. Valeurs par défaut quand la clé manque :

Rôles de titrage

Graisses, interlignes, interlettrage

Rayons

Ombres

Mouvement

Espacement et traits

Échelles numérotées

Des alias numérotés des mêmes valeurs, lus par la feuille du design system.

Grille, couches, effets

Logo

Variables de contexte

Celles-ci ne viennent pas de getBrand : la feuille du design system les pose selon le contexte du nœud. Elles sont permises dans un styleJson.

Ce que getBrand calcule

La plupart des variables recopient une valeur de la charte. Celles-ci sont calculées ; les connaître évite de les écrire à la main.

Le canal rgb

-rgb découpe une couleur #rrggbb en trois entiers séparés par une virgule et une espace. C'est la forme qui donne une transparence tirée de la charte, comme dans ce bloc d'une démo :

Toute autre écriture (#fff, rgb(...), red) donne 0, 0, 0, et l'encre calculée sur cette couleur devient #ffffff.

Les encres lisibles

--ink-text-on-brand, --ink-text-on-accent et --tone-*-on comparent le contraste du blanc et du noir sur l'aplat et gardent le meilleur : #ffffff ou #0b0b12. palette.brandOn et palette.accentOn imposent une autre encre.

Les tons

• -subtle : l'aplat à 12 % d'opacité.
• -emphasis : l'aplat mélangé à 15 % vers son encre -on. Une marque claire fonce au survol, une marque sombre s'éclaircit, dans les deux thèmes.
• -on-subtle : le ton, poussé par pas de 5 % vers l'encre lisible jusqu'à 4,5:1 de contraste contre surface.base couvert du lavis (20 pas au plus).

Le voile

--scrim part de surface.scrim, ou à défaut de la plus sombre de surface.base et ink.text, assombrie de moitié vers le noir. Il est ensuite assombri par pas de 5 % jusqu'à ce qu'un texte blanc garde 7:1 de contraste sur ce voile posé à 72 % sur du blanc. --scrim-brand et --scrim-accent-2 sont la marque et le deuxième accent de la palette sombre, éclaircis jusqu'à 4,5:1 sur le voile.

Le cadran de rayon

radii.radius est le seul réglage des coins, avec pill. Les crans s'en déduisent à pas de 4 px, bornés à 0 :

14 est la valeur par défaut. --radius-full, --radius-badge et --radius-tag valent radii.pill, 9999 par défaut.

Les tailles fluides

Un rôle { min, max } devient un clamp() qui croît en ligne droite de min à 375 px de large jusqu'à max à 1280 px : pente (max - min) / 905, origine min - pente x 375. Avec min égal à max, la valeur est fixe. Les rôles de la démo de l'exemple complet donnent :

Les accents gris

Quand accent, accent2 et accent3 ont tous une chroma OKLCH inférieure à 0,04, --accents-muted vaut 1. Si c'est vrai dans les deux thèmes, la balise <html> reçoit data-accents="muted", qu'une règle peut cibler pour une charte monochrome.

Clair et sombre

Le Layout émet un <style> en tête de page : :root porte les variables du bloc dark, puis, si le fichier a un bloc light, [data-theme="light"] porte le jeu complet recalculé pour le clair. Les deux sélecteurs pèsent autant ; le second, écrit après, l'emporte dès que <html> porte data-theme="light".

Les couleurs que le client retouche depuis l'administration de contenu sont émises dans un second <style>, après celui-ci, sur :root et :root[data-theme="light"] : elles l'emportent dans les deux thèmes.

Thème clair : <html data-theme="light">, les variables du bloc light.

Thème sombre : sans attribut, les variables du bloc dark.

Le choix du thème avant l'affichage

Un script en ligne, dans le <head>, fixe le thème avant la première peinture, sans flash :

• localStorage theme-mode vaut auto : clair de 7 h à 18 h 59 (heure du poste), sombre sinon.
• Sinon localStorage theme-preference : light ou dark, le dernier choix du visiteur.
• Sinon defaultTheme de la charte.

Clair : <html data-theme="light">. Sombre : l'attribut est retiré, le sombre est l'état sans attribut. Le script écrit aussi data-default-theme. Le contrôleur ThemeManager, monté une fois, réapplique le thème après chaque navigation ; le fragment ThemeSwitcher écrit theme-mode et theme-preference.

Projet sombre seul

• Ne mettez pas de bloc light. Aucune règle [data-theme="light"] n'est émise : même si l'attribut est posé, les variables restent celles de dark.
• Laissez defaultTheme à "dark", ou absent.
• Ne montez pas de ThemeSwitcher.
• Ne figez pas les surfaces dans web/index.css (--bg-primary posé sur body pour forcer le sombre) : c'est la trace d'un bloc light resté dans la charte. Retirez le bloc.

Projet clair par défaut

"defaultTheme": "light" avec un bloc light : un premier visiteur voit le clair, le sombre reste accessible par la préférence. "defaultTheme": "light" sans bloc light pose l'attribut mais ne change aucune variable : le site reste sombre.

Le système de classes

La feuille du design system est générée par @asynccode/ac_tools (designSystemCss) à partir de la charte du projet, au build du site, et insérée dans le CSS global de chaque page. Elle déclare l'ordre des couches de toute la cascade :

Une couche déclarée plus tard l'emporte sur les précédentes, quelle que soit la spécificité, et tout CSS hors couche (le style.css d'un bloc, d'une vue, d'une mise en page) l'emporte sur toutes les couches. Les utilitaires (ds-utilities) battent donc web/index.css (app-globals) et perdent contre le style.css d'un bloc. Aucune classe du système ne porte !important.

Le squelette

--container-w vaut 100%, puis, à partir de 576, 768, 992, 1200 et 1400 px de large, --container-sm, --container-md, --container-lg, --container-xl et --container-xxl.

La grille de 12 colonnes

Le parent porte grid, chaque enfant dit sa largeur en colonnes. Il n'y a pas de cols-N : la grille a toujours 12 pistes (--cols), et « trois colonnes » s'écrit avec trois enfants g-col-4.

Les crans N de gouttière et d'espacement : 0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 16, 20, 24, 32, 40. Exemple réel : une rangée de quatre principes, une colonne pleine sur une grille étroite, deux par rangée à partir de 20rem de grille, quatre à partir de 40rem.

Deux axes de paliers

Les paliers portent les mêmes noms sur deux axes qui ne se mélangent pas : un md d'écran n'est pas un md de grille.

• Écran : @media (min-width: ...), la largeur de la fenêtre. Les utilitaires à palier (d-md-none, mt-lg-4, order-md-first...) et les blocs sm à xxl d'un styleJson.
• Grille : @container ds-grid (min-width: ...), la largeur du .grid parent. Seules g-col-<bp>-*, g-start-<bp>-* et g-order-<bp>-first s'y rangent. Une grille posée dans une colonne étroite se replie donc comme sur un petit écran.
• Cellule : un styleJson qui porte "containerQuery": true écrit ses blocs sm à xxl en @container ds-cell, la largeur de la cellule de grille ou de la bande frame-* qui contient le nœud. cq-order-<bp>-first suit le même axe.

Les utilitaires

Une classe utilitaire fait une seule chose. La forme à palier insère le palier après le préfixe : d-none devient d-md-none, mt-4 devient mt-lg-4. Seules les familles marquées « palier » l'acceptent, et ce palier est celui de l'écran.

Les aides et les recettes

Les aides sont toujours présentes, jamais élaguées : clearfix, text-bg-primary à text-bg-info (fond du ton avec son encre), link-primary à link-info, focus-ring, icon-link et icon-link-hover, translate-middle, translate-middle-x, translate-middle-y, ratio avec ratio-1x1, ratio-4x3, ratio-16x9, ratio-21x9, vstack, hstack, stretched-link, text-truncate, vr, visually-hidden, visually-hidden-focusable.

Des recettes de contenu (table, table-sm, table-striped, table-hover, figure, blockquote, list-unstyled, list-inline, img-thumbnail...), de formulaire (form-label, form-text, invalid-feedback, valid-feedback, form-range) et de composants (alert-primary à alert-info, accordion, modal, offcanvas, list-group, progress, toast, popover, tooltip, breadcrumb, spinner-border, navbar...) complètent la feuille. Les composants sont ajoutés page par page, seulement quand la page cite leur classe. Les familles btn*, badge* et form-control vivent dans le CSS global du framework.

Le contexte : data-surface et data-style

Deux attributs règlent le contexte d'une boîte au lieu de lui donner une couleur. Dans une vue, ils se posent à la racine du nœud ; dans un tree.json, dans props.

• data-surface vide : le niveau se compte par profondeur, trois au plus. Au premier, --surface vaut --sf-1, --line --line-1 et --shadow --shadow-sm ; au deuxième, --sf-2, --line-2, --shadow-md ; au troisième, --sf-3 et --shadow-lg. data-surface="1", "2" ou "3" impose un niveau absolu, pour une modale ou un menu flottant.
• data-style peint la boîte avec une matière : fond --surface, bordure --stroke-thin en --line, ombre --shadow.

Le vocabulaire de l'inspecteur

@utils/dsVocabulary dérive de cette feuille les familles que l'inspecteur de l'Atelier lit et écrit. Une famille regroupe les classes qui posent les mêmes propriétés (deux classes d'une famille s'excluent) et porte un axe : écran, grille ou aucun. L'inspecteur tient une seule source par nœud et par propriété : poser une classe retire du styleJson les déclarations qui touchent ses propriétés (les états restent), et écrire une valeur hors du système retire la famille de classes correspondante.

À l'écriture d'un tree.json ou d'un structure.json, l'API compare chaque classe au vocabulaire. Sont reconnues les classes du design system, les classes propres du bloc (<id>-..., l'id étant le nom de son dossier), les références $..., btn*, badge*, form-control et under-nav. Toute autre classe est écrite quand même, et la réponse porte un avertissement node "<id>": <classes> outside the design system vocabulary.

styleJson dans un tree.json

Chaque nœud d'un tree.json peut porter, à côté de props, un styleJson : des blocs de déclarations en camelCase, la forme d'un objet style React. Les éditeurs y écrivent ce qu'aucune classe ne couvre : couleurs hors tons, dégradés, filets fins, transitions, états.

Un bloc de palier ne contient que des déclarations, pas d'état imbriqué. Quand base pose display: grid sans piste intrinsèque (auto, min-content, max-content, fit-content()), la compilation ajoute une règle qui fait de chaque enfant un conteneur ds-cell.

Exemple réel

Le bandeau d'appel à l'action d'une démo : un conteneur au contexte outlined, un lien avec ses états, une liste qui passe en ligne à partir de 992 px.

Ce que la compilation écrit dans le style.css de chaque bloc :

Propriétés permises

Une clé hors de cette liste est retirée sans erreur. Les noms sont en camelCase et en côtés physiques : paddingLeft, jamais paddingInlineStart.

Valeurs permises

• Une chaîne ou un nombre, de 512 caractères au plus.
• Caractères permis : lettres, chiffres, espaces et . , % # ( ) + * ' " / -. Tout autre caractère refuse la valeur, notamment ;, {, }, <, >, \, :, ! (donc !important), @, & et _.
• url(, @import, expression(, /* et */ sont refusés, ainsi que les mots javascript, vbscript, behavior, -moz-binding, image (donc image-set()), cross-fade, src et brand-logo-url. Une image de fond passe par le choix d'un média, jamais par un styleJson.
• var() : chaque référence doit nommer un jeton permis, c'est-à-dire une variable des tableaux précédents (sauf --accents-muted et les cinq du logo) ou une variable de contexte. Une référence avec repli (var(--brand, red)) ou imbriquée est refusée. Plusieurs références dans une valeur sont permises (var(--space-2) var(--space-4)), et une référence peut vivre dans une fonction (color-mix(in srgb, var(--scrim-ink) 40%, transparent)).
• content n'accepte que none, normal ou une chaîne entre guillemets de 64 caractères au plus.
• Une déclaration refusée est retirée sans message ; le reste du bloc est compilé.

Reteinter un sous-arbre

Dix variables peuvent être redéfinies dans un styleJson pour reteinter un nœud et ses descendants : --brand, --brand-secondary, --accent, --accent-2, --accent-3 et leurs jumelles -rgb. La couleur prend un hexadécimal (3, 4, 6 ou 8 chiffres), un rgb() ou rgba() numérique, ou un jeton permis ; la jumelle -rgb prend un triplet r, g, b. Écrivez toujours la paire, sinon les transparences rgba(var(--brand-rgb), ...) gardent l'ancienne couleur. Aucune autre propriété personnalisée n'est acceptée.

Raccourcis de grille

Un nœud peut aussi porter col, offset, order et g, sur le nœud ou dans props. Ils se développent en styleJson à la compilation : col: 6 donne gridColumn: "auto/span 6" ; col: "md-6" ou col: { "base": 12, "md": 6 } visent un palier d'écran ; offset donne gridColumnStart, order donne order, g donne gap: var(--space-N). Le styleJson écrit à la main l'emporte sur le raccourci. Les éditeurs n'écrivent plus ces raccourcis : préférez les classes g-col-*.

La compilation dans style.css

Les éditeurs de l'Atelier et la création d'un bloc compilent l'arbre (compileFragmentNodesCss) et réécrivent la zone du style.css du bloc comprise entre /* forge:nodes:start */ et /* forge:nodes:end */. Tout ce qui est hors de ces deux marques est conservé tel quel. À la première compilation, la zone est ajoutée en fin de fichier, après le CSS déjà écrit.

Chaque nœud stylé reçoit une règle sur son identifiant préfixé par l'id du bloc, <bloc>--<nœud>, écrit deux fois. Ce doublement porte la règle à une spécificité de (0,2,0), au niveau des styles de base des fragments du framework ([data-fragment='Nom'] .titre), que la création d'un bloc recopie au-dessus de la zone : écrite après eux, elle l'emporte. Toutes les instances d'un même bloc partagent l'identifiant, donc la règle.

Au rendu, le bloc est enveloppé dans <div style="display: contents" data-fid="<bloc>">. Seuls la racine de chaque instance et les nœuds qui portent un style effectif reçoivent l'attribut data-forge-id ; le canevas d'édition, lui, le pose sur tous les nœuds.

Le piège de la classe d'état

Une classe d'état écrite à la main, .x.is-on, pèse (0,2,0) : autant que la règle générée du nœud. À égalité, l'ordre dans le fichier décide. Écrite avant la zone générée, la règle d'état perd sur toute propriété que le styleJson du nœud pose aussi : si base pose background et que .x.is-on pose aussi background, l'état ne s'affiche jamais.

• Laissez hors du styleJson les propriétés que l'état change, et écrivez l'état de repos et l'état actif dans le CSS du bloc (.x et .x.is-on).
• Ou écrivez la règle d'état après /* forge:nodes:end */ : la recompilation conserve ce qui suit la zone.
• Ou préfixez par [data-fid='<bloc>'], comme ci-dessous, pour passer à (0,3,0). Un tel sélecteur bat aussi les retouches de style posées sur le nœud depuis l'administration de contenu (même sélecteur doublé), et la vérification des lois du design system signale tout sélecteur de plus de deux composés : gardez-le pour les états.

Exemple complet

La charte d'une démo de pâtisserie, raccourcie : un thème sombre complet, un thème clair qui ne change que les couleurs et les ombres, le clair par défaut.

Ce qui change entre les thèmes

Ce qui est commun aux deux thèmes

• radius: 6 donne des coins presque droits : --radius-sm tombe à 0, donc boutons et champs sont carrés.
• Les rôles fluides font grandir les titres avec la page : un titre de section passe de 38 px à 375 px de large à 60 px à 1280 px.
• Les cinq largeurs de conteneur valent 1180 : à partir de 576 px, .container ne dépasse jamais 1180 px.
• Le voile est déclaré dans dark et reste le même en clair, comme --scrim-brand, calculé depuis la palette sombre.
• effects.surface: "soft" fait d'un data-style vide une surface pleine sans filet.
• Le bloc light n'a ni fonts ni typography : la typographie est la même dans les deux thèmes.
• weights.semibold vaut 700 : fw-semibold et tout ce qui lit --weight-semibold sont plus gras que d'habitude, sans toucher un bloc.

Règles et pièges

Règles d'usage

• Jamais de couleur en dur dans un bloc : #c42a3f s'écrit var(--brand), une transparence rgba(var(--brand-rgb), 0.2). Une couleur figée ne suit ni le thème clair ni les changements de charte.
• Les variables plutôt que les valeurs, aussi pour les tailles, les rayons, les espacements et les durées : var(--text-lg), var(--radius-md), var(--space-4), var(--duration-fast).
• Les classes d'abord, le styleJson pour ce qu'elles n'expriment pas, le CSS écrit à la main pour le reste : sélecteurs d'enfants, pseudo-éléments complexes, états portés par une classe, images clés.
• Un bloc ne fixe pas sa largeur de page : la largeur vient de container ou d'une bande frame-*. Un bloc se mesure à son conteneur (@container), pas à la fenêtre ; la vérification des lois du design system signale un max-width de 1000 px ou plus centré, et un @media de largeur dans le CSS d'un bloc.

web/index.css perd contre les blocs

web/index.css n'est pas chargé tel quel : il est inséré, avec le CSS global du framework, dans @layer app-globals. Une règle en couche perd toujours contre une règle hors couche, quelle que soit sa spécificité. Une règle de web/index.css ne corrige donc jamais le style.css d'un bloc, d'un fragment ou d'une mise en page.

• Bon usage : le socle du document (body, police, box-sizing) et les valeurs de variables propres au projet, comme --shell-clear.
• Mauvais usage : surcharger un bloc, la règle est ignorée ; poser une remise à zéro large comme *{margin:0;padding:0}, qui bat les couches ds-* déclarées avant app-globals et casse le centrage de .container et les retraits du système.

La mise en page dans layouts/<id>/style.css

Ce qui tient la page autour des blocs (barre collante, zones, filet sous l'en-tête) va dans le style.css de la mise en page, web/configurations/layouts/<id>/style.css. Ce CSS est hors couche et inséré sur chaque page qui monte cette mise en page. Pas dans web/index.css, où ces règles perdraient, ni dans un bloc, qui ne connaît pas la page.

Pièges

• Un spacing incomplet donne undefinedpx pour les clés 0, 1, 2, 3, 4, 6, 8, 12, 16 : marges, retraits et gouttières disparaissent. Même chose pour une opacité de ink manquante.
• Une couleur écrite autrement qu'en #rrggbb donne un canal -rgb noir (0, 0, 0) et une encre calculée blanche.
• Sans typography.lineHeights.base, --leading-base n'existe pas, même avec leading.base.
• radii.radius écrit en chaîne est ignoré : le cadran revient à 14.
• Une police sans import en https:// dans dark ne se charge pas : le site s'affiche dans la pile de repli.
• Une variable inventée (--border-color, --font-size-lg) n'existe pas : sans repli, toute la déclaration tombe. Dans un styleJson, elle est refusée à la compilation.
• Une classe construite à partir d'une donnée est élaguée en ligne alors qu'elle s'affiche dans l'Aperçu.
• Un sélecteur écrit à la main sur [data-forge-id='<bloc>--<nœud>'] ne trouve en ligne que la racine et les nœuds stylés ; le canevas d'édition marque tous les nœuds et cache l'écart.
• Redéfinir --brand sur un nœud ne change ni --tone-primary ni --ink-text-on-brand.
• "defaultTheme": "light" sans bloc light laisse le site sombre.
• Une valeur de charte qui contient ;, une accolade, < ou un url( hors logo est retirée du <style> sans message.