Écrire du HTML.
Peels fait le reste.

Le problème avec les classes

Prenons un exemple concret. Tu veux styliser un bouton de soumission. Dans un framework utilitaire, tu écris quelque chose comme :

<button class="px-4 py-2 bg-blue-500 text-white rounded hover:bg-blue-600">
  Envoyer
</button>

C'est fonctionnel. Mais tu n'as pas écrit du HTML — tu as écrit du CSS déguisé en attribut. La sémantique est noyée sous la présentation.

Avec Peels :

<button type="submit">Envoyer</button>

Les layers comme architecture

Peels est organisé en sept couches CSS :

@layer reset, tokens, contract, theme, base, elements, a11y;

Chaque couche a une responsabilité distincte. Les tokens définissent les valeurs brutes. Le contrat mappe vers les rôles sémantiques --peels-*. Le thème surcharge l'identité selon le contexte. Base stylise les conventions HTML transverses. Elements contient les éléments et leurs fallbacks locaux. A11y garantit l'accessibilité.

Personnaliser sans casser

Les variables --peels-* sont les seuls points de contact officiels. Tu ne surcharges jamais les tokens bruts — tu surcharges les rôles UI.

--peels-text-body

La couleur du corps de texte.

--peels-gap-section

L'espacement entre sections — toutes s'alignent automatiquement.

--peels-component-radius

Le rayon de coin global des composants.