CSS corner-shape : pourquoi border-radius ne suffit plus pour un design system moderne

Un design system moderne ne veut pas “un radius”. Il veut une intention d’angle. Arrondi, biseauté, “squircle-like”, coupé, super-ellipse… Et surtout : la même intention partout (boutons, cartes, champs, modals, avatars, images). Le problème, c’est que border-radius ne sait faire qu’un truc : des quarts d’ellipse. Ça marche… jusqu’au jour où tu dois industrialiser.

corner-shape arrive précisément pour ça : sortir du bricolage “on augmente le radius et on prie” et rendre les angles déclaratifs. Sauf que côté implémentation navigateur, c’est bien plus tordu qu’un simple “nouveau style d’arrondi”. Donc si tu veux l’intégrer dans un design system réel, il te faut une stratégie : tokens, mapping CSS, compat, et une règle simple pour décider quand l’utiliser (et quand rester sur un bon vieux radius).

Le vrai problème de border-radius dans un design system

border-radius est parfait pour : “cette carte est un peu arrondie”. Il est moins bon pour : “notre marque a un langage d’angles cohérent et reconnaissable”. Voilà ce qui casse en pratique :

• Pas d’intention de forme : un rayon n’exprime pas “biseau”, “squircle”, “coupé”. Tu finis avec des hacks (SVG, masks, pseudo-elements).
• Incohérences multi-surfaces : un bouton peut être en CSS, une image en img, un composant en canvas, un overlay en backdrop-filter… et chaque couche a sa propre façon de “faire un angle”.
• Rayons qui ne scale pas : quand le composant change de taille, un rayon “fixe” peut devenir trop rond ou trop carré. Tu compenses avec des variantes (sm/md/lg) et des règles implicites.
• Angles composites : bordure + background + outline + box-shadow. Selon comment tu empiles, tu peux avoir des décalages visibles (surtout sur les thèmes dark, les borders fines et les zooms).

Résultat : tu crois avoir un token “radius-md”, mais en vrai tu as une collection de cas particuliers.

corner-shape : ce que ça change (et ce que ça ne change pas)

L’idée de corner-shape, c’est de séparer la taille (le “combien”) de la forme (le “comment”). Tu gardes une dimension (proche de l’usage de border-radius), mais tu peux choisir une forme de coin différente.

Ce point est clé pour un design system : tu peux enfin avoir des tokens du type “angle = squircle” indépendamment de “angle-size = md”.

Pourquoi ce n’est pas un détail d’implémentation

Si tu lis entre les lignes des retours d’implémentation côté moteur (Blink), tu comprends vite pourquoi la compat va prendre du temps : un coin n’est pas juste un arrondi sur un rectangle. Il interagit avec :

• Les bordures (épaisseur variable, styles différents, jointures, anti-aliasing).
• Les backgrounds (multiple backgrounds, gradients, background-clip, background-origin).
• Les effets (shadows, filters, compositing, clipping, hit-testing).
• Les cas limites : coins asymétriques, rayons trop grands, formes concaves/convexes, zooms, subpixel.

Donc non : ce n’est pas “un nouveau radius fun”. C’est un changement qui touche au rendu bas niveau. Conclusion pragmatique : tu dois le traiter comme une amélioration progressive, pas comme une base.

Modéliser des tokens d’angles (sans t’enfermer)

Le piège classique : créer 12 tokens “radius-*” et espérer que ça couvre la marque. Pour un design system solide, sépare :

• Token de taille (xs, sm, md, lg, xl…).
• Token de forme (round, bevel, squircle, cut…).
• Token de contexte (ex : surfaces vs controls, ou “interactive” vs “container”). Parce que tu ne veux pas forcément la même forme sur une card et sur un chip.

Et surtout : accepte l’idée qu’au début tu auras 2 formes max. La cohérence vient plus de la discipline que du nombre de variantes.

Mapping CSS : une base simple (progressive enhancement)

Objectif : un composant consomme --corner-size et --corner-shape. Si le navigateur ne supporte pas, il retombe sur border-radius et ton UI reste cohérente (même si moins “signature”).

:root{
  /* tailles */
  --corner-size-xs: 6px;
  --corner-size-sm: 10px;
  --corner-size-md: 14px;
  --corner-size-lg: 18px;

  /* formes (valeurs indicatives, à ajuster selon la spec/implémentation réelle) */
  --corner-shape-round: round;
  --corner-shape-squircle: squircle;
  --corner-shape-bevel: bevel;
}

/* API de composant */
.ui-surface{
  --corner-size: var(--corner-size-md);
  --corner-shape: var(--corner-shape-round);

  /* fallback universel */
  border-radius: var(--corner-size);
}

/* activation si support */
@supports (corner-shape: round){
  .ui-surface{
    corner-shape: var(--corner-shape);
    corner-size: var(--corner-size);
  }
}

Note importante : les noms/propriétés exacts peuvent évoluer selon la standardisation. L’idée ici, c’est le pattern design system : une API de tokens stable + @supports + fallback.

La vraie galère : cohérence entre composants, images, masks

Un design system ne gère pas que des divs. Il gère :

• Images (avatars, thumbnails, hero images).
• Overlays (modals, drawers) avec backdrop et ombres.
• États (focus ring, hover, pressed) qui doivent suivre le même coin.

Avec border-radius, tu peux faire illusion tant que tout est “rectangles + backgrounds”. Dès que tu as une image (donc un contenu raster) ou des coins “non elliptiques”, tu retombes sur clip-path ou mask. Et là, tu as deux risques :

• Le mismatch de forme : ton bouton et ton avatar ne “tournent” pas pareil, même si tu leur mets “14px”.
• La dette de perfs : masks/filters sur de grosses surfaces + animations = jank possible sur certaines machines.

Stratégie réaliste

• Surfaces UI (cards, inputs, buttons) : préfère corner-shape si dispo, sinon border-radius.
• Images : reste sur border-radius tant que ta marque ne nécessite pas une forme “signature”. Si tu veux une forme custom, fais-le avec mask SVG mais uniquement sur des endroits à fort impact (ex : avatars, pas toutes les images du feed).
• Focus ring : ne le laisse pas “au hasard”. Si tu as un outline, pense à outline-offset et à l’équivalent de forme (sinon tu auras un ring rond sur un coin squircle, ça se voit).

Grille de décision : quand utiliser corner-shape (et quand rester sur border-radius)

Tu veux une règle simple ? La voilà.

Utilise corner-shape si…

• Tu as un langage de marque où l’angle est distinctif (squircle/biseau) et répété partout.
• Tu as un design system avec tokens et tu veux découpler “forme” et “taille”.
• Tu peux l’assumer en progressive enhancement (l’UI reste OK sans).
• Tu as un parc dominé par des navigateurs qui suivent les nouveautés (ex : produits internes Chrome/Edge, ou audience très web moderne).

Reste sur border-radius si…

• Ton besoin c’est “juste un arrondi propre” (95% des apps).
• Tu as des contraintes de compat strictes (clients corporate, webviews anciennes, multi-device non maîtrisé).
• Tu as déjà des dizaines de composants et tu ne veux pas ouvrir une migration de style qui va créer des écarts subtils.

Plan d’intégration propre dans un design system

• Étape 1 : stabiliser les tokens (tailles + formes), même si tu ne mets que “round” au début. Tu poses l’API.
• Étape 2 : activer corner-shape derrière @supports sur 2-3 composants pivots (button, card, input). Tu mesures visuellement et tu repères les coins “moches”.
• Étape 3 : traiter les éléments sensibles (focus ring, borders fines, overlays) avant d’étendre partout.
• Étape 4 : décider pour les images : soit tu restes sur border-radius (souvent le bon choix), soit tu assumes un mask “signature” très ciblé.
• Étape 5 : documenter : une page “Corners” dans ton DS avec la grille de décision + exemples “Do/Don’t”. C’est là que tu gagnes la cohérence.

Conclusion : corner-shape, oui… mais comme une couche de qualité

corner-shape n’est pas un gadget. C’est une brique qui peut rendre ton design system plus déclaratif, plus cohérent, plus “brandable”. Mais c’est aussi une feature qui touche au rendu fin, donc elle doit être adoptée comme : une amélioration progressive, pilotée par des tokens clairs, avec un fallback propre.

Si tu fais ça, tu obtiens le meilleur des deux mondes : une UI qui reste robuste partout, et une signature visuelle qui monte d’un cran sur les navigateurs compatibles.

Sources

• Chrome for Developers — The corner cases of implementing CSS corner-shape in Blink