Et si le vrai problème avec votre CSS n’était pas qu’il soit global—mais que vous n’ayez jamais vraiment défini ce qu’est une unité d’interface ?
Vous connaissez ce sentiment. Vous ajustez le padding sur un écran. Soudain, un bouton à dix fichiers de distance a l’air bizarrement dimensionné. Le même HTML s’affiche différemment selon les contextes. Vous ne pouvez plus dire quelle règle est responsable de ce qui apparaît à l’écran. Donc vous ajoutez un autre sélecteur pour être sûr. Puis un autre. Jusqu’à ce que votre feuille de styles devienne une fouille archéologique et votre composant ressemble à quelque chose écrit par un comité.
La plupart des équipes blâment le CSS. Elles se trompent.
Le vrai problème n’est pas le CSS—c’est la structure
Voici ce qui se passe réellement : votre HTML vit à un endroit, votre CSS ailleurs, et votre comportement DOM dans un troisième. Chaque partie semble bien indépendamment. Mais elles décrivent la même unité visuelle sans jamais être dans la même pièce.
C’est dans cet écart que la dérive prend naissance.
Le HTML seul ne vous dit pas comment un élément se comporte. Le CSS ne vous dit pas à quelle unité structurelle il appartient. Le code DOM modifie la même zone sans emporter avec lui le contexte de style ou l’intention originale. Vous avez trois équipes différentes qui travaillent sur le même employé, parlent des langues différentes, jamais synchronisées.
« Le problème était qu’il n’existait pas d’unité d’interface claire qui regroupait ces responsabilités. Sans cette unité, les petites corrections s’accumulent dans les vides entre les fichiers. »
Les petites corrections s’accumulent. Un sélecteur se fait ajuster. Une règle s’ajoute. Un patch DOM apparaît. Chacun est localement raisonnable. L’écran dans son ensemble devient incompréhensible.
Un développeur travaillant avec Razor Pages a remarqué quelque chose. L’appairage .cshtml et .cshtml.css imposait une relation—le CSS était automatiquement limité à vivre à l’intérieur de cette page. Le rayon d’impact était petit par défaut. Vous pouviez implémenter des styles sans constamment vous demander si vous veniez de casser quelque chose trois niveaux profondément dans un autre fichier.
Ce n’était pas parfait. Mais cela rendait une chose évidente : quand les responsabilités liées restent attachées à l’unité à laquelle elles appartiennent, elles cessent de s’échapper partout ailleurs.
À quoi ressemble vraiment une unité d’interface réelle ?
Cette réalisation a mené à une question différente : et si le HTML et le CSS devaient rester attachés à une frontière significative dans le code frontend, comme Razor Pages l’a montré ?
Au lieu de penser en termes de couches libres—du balisage ici, du style là-bas, du comportement qui flotte—vous commencez à penser en termes de propriété d’élément. Une frontière possède une racine structurelle, un contexte de style local, et un seul endroit où le comportement DOM existe. Parce que cette frontière devient le seul endroit où la structure, le style et le comportement peuvent se rencontrer, les changements cessent de s’échapper.
Ce n’est pas une question de transformer tout en framework de composants. C’est une question d’avoir une unité assez petite pour posséder sa propre structure.
Imaginez quelque chose de simple appelé ElementBoundary :
const profileCard = new ElementBoundary(
/* html */ `
<section>
<h2 class="title">Profil</h2>
<p class="value">Actif</p>
</section>
`,
/* css */ `
[root] {
padding: 12px;
border: 1px solid #d0d7de;
}
[root] .title {
font-size: 14px;
margin: 0 0 8px;
}
`
);
const screen = ElementBoundary.first("#screen");
screen.append(profileCard);
Le constructeur n’a pas d’importance. Ce qui compte, c’est qu’une unité d’élément possède à la fois son HTML et son CSS. Le conteneur écran est traité via le même modèle de frontière au lieu de revenir à un accès DOM brut. L’espace réservé [root] se réécrit automatiquement en sélecteur spécifique à la frontière, donc le CSS s’applique uniquement à l’intérieur de cette unité.
Ce n’est pas Shadow DOM. Shadow DOM vous retire du flux DOM normal. Ceci vous y garde tout en vous donnant une frontière de style plus étroite qui s’adapte à mesure que l’interface grandit. La création, la recherche et le placement suivent tous le même modèle au lieu d’être des opérations DOM non liées éparpillées dans votre codebase.
Pourquoi cela résout vraiment le problème de dérive
Une fois que vous commencez à penser de cette façon, trois choses changent.
Le CSS devient local parce qu’il est attaché à une racine d’élément au lieu d’être traité comme une couche globale séparée. Le comportement DOM devient plus facile à placer parce qu’il appartient à une unité spécifique au lieu de flotter à travers la page. L’interface elle-même devient pensée de manière cohérente—à la fois les zones existantes et les zones nouvellement créées suivent le même sens structurel.
Vous cessez de vous demander quel sélecteur est responsable ? et commencez à vous demander quelle frontière possède ceci ? C’est une conversation totalement différente.
L’écart entre ce que votre HTML décrit et ce que votre CSS fait et ce que votre code DOM fait—cet écart disparaît. Non pas parce que vous avez utilisé un framework. Parce que vous avez défini ce qu’est une unité.
Cela importe parce que les frontends en expansion ne s’effondrent pas à cause de la syntaxe CSS. Ils s’effondrent parce que les équipes n’ont jamais convenu du moment où la responsabilité commence et se termine. Quand vous définissez une frontière claire, cette ambiguïté meurt. Vous pouvez changer les choses sans crainte. Vous pouvez ajouter des fonctionnalités sans créer de dette technique. Et vous pouvez intégrer les nouveaux développeurs sans qu’ils aient besoin de rétro-ingéniérer toute votre stratégie de style.
Ce n’est pas révolutionnaire. C’est structurel.
🧬 Ressources connexes
- À lire: Higress Joins CNCF as Alibaba’s AI Gateway Bet—And Nginx Has Until 2026 to Worry
- À lire: Claude Code’s Token Collapse: When AI Pricing Models Break Developer Workflows
Questions fréquemment posées
Les frontières du DOM remplaceront-elles les frameworks de composants comme React ? Non. C’est une question d’organisation structurelle dans n’importe quel framework que vous utilisez. Les composants React pourraient adopter ce modèle. Le JavaScript pur aussi. La frontière parle de responsabilité, pas d’outils.
Cela fonctionne-t-il avec le CSS existant ? Oui, si vous pouvez refactoriser vos sélecteurs pour respecter la portée de la frontière. Les nouveaux projets l’adoptent immédiatement. Le code existant nécessite quelques réécritures, mais c’est limité à une unité à la fois.
Est-ce la même chose que les modules CSS ? Objectif similaire, approche différente. Les modules CSS utilisent des conventions de nommage et des outils. Les frontières rendent l’unité structurelle explicite dans votre JavaScript, reliant le HTML, le CSS et le comportement ensemble conceptuellement, pas seulement techniquement.
