La technique de line clamp permet de garder un texte lisible sans casser la grille d’une page: extrait d’article, carte produit, aperçu de commentaire ou bloc d’actualité. Bien utilisée, elle évite les blocs trop hauts; mal réglée, elle coupe des informations utiles et crée une interface frustrante. Dans cet article, je montre ce que fait réellement la propriété, comment l’implémenter proprement, où elle coince encore en 2026 et dans quels cas je préfère une autre approche.
L’essentiel à retenir avant d’écrire une seule ligne de CSS
- `line-clamp` limite l’affichage à un nombre précis de lignes et tronque le reste du texte.
- La version legacy `-webkit-line-clamp` reste la plus fiable si vous visez une compatibilité large.
- Un `overflow: hidden` bien placé évite les débordements visuels et les surprises de rendu.
- Le texte coupé ne doit pas contenir une information critique sans alternative visible.
- Pour un effet interactif, ou si je dois mesurer précisément l’espace disponible, je passe souvent par JavaScript.
Ce que cette propriété fait vraiment
Je vois `line-clamp` comme un outil de mise en page, pas comme un mécanisme de gestion de contenu. Son rôle est simple: afficher un bloc de texte sur un nombre limité de lignes, puis masquer la suite. C’est utile quand je veux garder des cartes homogènes, éviter que des résumés trop longs déséquilibrent une liste, ou donner un aperçu sans noyer l’utilisateur sous un pavé.
Le bon cas d’usage, c’est le contenu de prévisualisation. Un teaser d’article, une description de fiche, une bio courte, un commentaire dans un fil, tout cela supporte bien une coupure visuelle. En revanche, si le texte porte une condition légale, un prix, un nom propre long, une consigne technique ou une information qui doit être lue en entier, je ne compte pas sur cette propriété pour faire le travail à elle seule.
Le point important à retenir, c’est que le texte n’est pas supprimé du DOM pour autant. Il reste là, mais il n’est plus visible dans la zone affichée. C’est précisément ce qui rend l’effet léger et rapide côté frontend. Pour l’utiliser sans mauvaise surprise, il faut ensuite regarder la syntaxe et les variantes qui coexistent encore.
La mise en place CSS qui fonctionne
La version moderne est très compacte, mais je préfère toujours la lire avec les yeux d’un intégrateur avant de la considérer comme “terminée”. Dans sa forme la plus simple, on limite le nombre de lignes et on masque le débordement visuel.
.excerpt {
line-clamp: 3;
overflow: hidden;
}Sur le terrain, je garde presque toujours une version de compatibilité basée sur l’implémentation historique. Elle reste largement utilisée, et son fonctionnement est bien connu dans les équipes frontend.
.excerpt {
display: -webkit-box;
-webkit-box-orient: vertical;
-webkit-line-clamp: 3;
overflow: hidden;
}Ce trio de propriétés n’est pas élégant, mais il reste robuste. `display: -webkit-box` crée le contexte attendu, `-webkit-box-orient: vertical` impose une orientation verticale, et `-webkit-line-clamp` fixe le nombre de lignes visibles. J’ajoute `overflow: hidden` par habitude, parce que je veux un rendu propre même quand le navigateur est plus tolérant que prévu.
| Approche | Ce qu’elle apporte | Ce qu’elle impose | Quand je la choisis |
|---|---|---|---|
| `line-clamp` natif | Syntaxe claire, intention lisible | Compatibilité encore inégale selon les environnements | Quand je pars sur une base moderne et que je teste le rendu |
| `-webkit-line-clamp` | Solution éprouvée dans beaucoup d’interfaces réelles | Syntaxe plus lourde et dépendance à des propriétés annexes | Quand je veux une solution de production solide aujourd’hui |
| JavaScript | Contrôle fin, expansion dynamique, logique conditionnelle | Plus de code, plus de maintenance, plus de cas limites | Quand le texte doit pouvoir se développer ou se recalculer |
Cette différence entre solution native, compatibilité historique et logique scriptée explique pourquoi je ne traite jamais ce sujet comme un simple détail de CSS. Le choix de l’implémentation dépend directement du support attendu, et c’est justement ce point qu’il faut clarifier avant d’aller plus loin.
Ce que le support navigateur change en 2026
Le support s’est amélioré, mais je ne le considère pas encore comme un non-sujet. MDN classe encore la propriété en disponibilité limitée, alors que Can I use montre une couverture large dans les navigateurs récents; en pratique, cela me suffit pour l’utiliser dans des interfaces maîtrisées, pas pour oublier les vérifications. Mon réflexe est simple: si la mise en page dépend fortement de cette coupure, je teste le rendu réel au lieu de me fier uniquement à la théorie.
Ce que j’en tire côté produit est assez clair. Pour une carte d’aperçu ou une liste éditoriale, la solution CSS est généralement acceptable. Pour une interface critique, un catalogue dense ou un contenu sur lequel l’utilisateur doit s’appuyer pour prendre une décision, je garde une stratégie de repli. Ce repli peut être une version sans troncature, un bouton d’expansion ou une légère réorganisation de la carte.
Le support n’est pas seulement une affaire de navigateur; il dépend aussi du contexte d’affichage. La même règle peut sembler parfaite sur un bureau large et devenir bancale sur un mobile avec police système, zoom utilisateur ou texte localisé plus long. C’est pour cela que je passe ensuite au sujet qui compte souvent plus que la compatibilité pure: la lisibilité et l’accessibilité.
Lisibilité et accessibilité quand le texte est coupé
D’un point de vue UX, couper un texte n’est jamais neutre. Une interface peut être propre visuellement tout en restant frustrante si l’utilisateur sent qu’on lui cache une information utile. Je fais donc une distinction nette entre le contenu décoratif, que je peux tronquer, et le contenu décisionnel, que je dois laisser lisible ou rendre déroulable.
Quand je veux permettre une lecture complète, j’ajoute souvent un mécanisme explicite de раскры? Non, en français clair: un bouton “Lire la suite”, “Afficher plus” ou une carte extensible. C’est plus honnête qu’un simple ellipsis, parce que l’utilisateur comprend qu’une suite existe et qu’il peut y accéder. Si je dois gérer l’état ouvert/fermé, j’utilise un bouton avec `aria-expanded` et une zone associée via `aria-controls`, plutôt qu’une astuce visuelle seule.
Je me méfie aussi des textes interactifs tronqués au milieu d’un lien. Quand une phrase entière est cliquable, la coupure peut tomber dans une zone peu lisible et donner l’impression d’une carte mal finie. De la même manière, si la ligne finale se termine par un mot tronqué dans une langue plus longue que prévu, le résultat peut devenir confus. Je teste donc les cas réels, pas seulement le cas idéal de la maquette.
En pratique, la bonne question n’est pas “est-ce que ça rentre ?”, mais “est-ce que l’utilisateur perd quelque chose d’important en ne voyant qu’une partie du texte ?”. Une fois cette réponse posée, il devient beaucoup plus simple de choisir entre CSS pur et logique JavaScript.
Choisir entre CSS natif et JavaScript
Je réserve le CSS seul aux contenus statiques ou semi-statiques. Dès que je veux mesurer la hauteur disponible, animer l’ouverture, réagir à une taille de conteneur ou synchroniser l’affichage avec d’autres règles métier, le JavaScript redevient pertinent. Ce n’est pas un échec de CSS; c’est juste le bon niveau d’outil pour le problème.
| Critère | CSS avec clamp | JavaScript |
|---|---|---|
| Performance | Très léger | Bon, mais plus coûteux à maintenir |
| Lisibilité du code | Très bonne sur la version moderne | Dépend de la qualité de l’implémentation |
| Contrôle fin | Limité | Très élevé |
| États ouverts/fermés | Pas idéal seul | Très adapté |
| Cas les plus simples | Le meilleur choix | Souvent inutile |
Mon approche est pragmatique: si la carte doit juste rester propre, je reste en CSS. Si elle doit devenir un mini-composant interactif, je passe au script sans hésiter. Cette frontière me permet d’éviter deux excès classiques: sur-architecturer un simple extrait, ou au contraire bricoler un effet fragile quand l’interface demande plus qu’une règle de style.
Les erreurs qui reviennent le plus souvent
La première erreur, très fréquente, consiste à oublier `overflow: hidden`. Le texte peut alors afficher un ellipsis sans que le bloc soit réellement propre visuellement. La seconde consiste à appliquer la règle à un conteneur qui n’a pas de structure compatible, puis à conclure trop vite que “ça ne marche pas”.
Je vois aussi souvent des équipes tester l’effet avec une seule police, une seule largeur et une seule langue. C’est trop peu. Un titre français, un texte allemand, un mobile étroit ou une police plus épaisse suffisent parfois à faire apparaître un rendu différent. Pour une interface multilingue, je teste toujours avec des contenus un peu plus longs que la moyenne.
Autre piège: croire que cette technique convient à tout type de conteneur. Les blocs en colonnes, certains contextes de layout ou des compositions trop complexes peuvent produire des effets imprévisibles. Si je sens que la mise en page devient fragile, je simplifie la structure avant d’ajouter une couche de coupe visuelle.
Et il y a un dernier point que je rappelle souvent aux équipes: un ellipsis n’est pas une garantie de compréhension. Si l’utilisateur doit deviner la suite, c’est que la solution n’est pas bonne. C’est précisément la raison pour laquelle je termine toujours par une vérification simple avant de valider l’implémentation.
Ce que je vérifie avant de le mettre en production
Avant de livrer, je me pose quatre questions très concrètes. Le texte peut-il être raccourci sans perte de sens? L’utilisateur a-t-il un moyen clair d’accéder au contenu complet si nécessaire? Le comportement est-il acceptable sur les navigateurs visés? Le rendu reste-t-il propre en français, sur mobile et dans les cas un peu plus longs que la maquette?
Si la réponse est oui à ces quatre points, je suis à l’aise pour garder la solution en CSS. Si l’un d’eux est non, je reviens au composant et je corrige le problème à la source, au lieu de compter sur un effet de troncature pour masquer la faiblesse de l’interface. C’est souvent ce petit tri qui distingue une intégration rapide d’une interface réellement robuste.
Au fond, je traite cette propriété comme un outil de finition: utile pour rendre une page plus lisible, mais insuffisant dès qu’elle doit porter à elle seule une vraie décision produit. Bien utilisée, elle apporte de la discipline visuelle; mal utilisée, elle cache surtout un problème de hiérarchie de contenu.
