SkyMinds.Net

Je me suis rendu compte, en rédigeant mes articles sur l’installation d’un serveur dédié, que certains blocs de code Bash ne passaient pas automatiquement à la ligne.

Résultat : une longue commande pouvait s’afficher sur une seule ligne, dépasser de son conteneur, puis créer une barre de défilement horizontale peu élégante. Ce n’est pas dramatique, mais ce n’est pas très agréable à lire, surtout sur mobile.

Le code est généralement affiché avec la balise <pre>, qui sert à afficher du texte préformaté. Elle conserve les espaces, les tabulations et les retours à la ligne. Cependant, par défaut, elle ne replie pas toujours les longues lignes comme un paragraphe classique.

Voici donc plusieurs façons de forcer, contrôler ou éviter le retour à la ligne dans les blocs pre, selon le rendu souhaité.

Pourquoi les blocs pre ne vont pas toujours à la ligne

La balise <pre> signifie “preformatted text”. Elle respecte donc la mise en forme originale du texte. C’est précisément ce qu’on veut pour du code : indentation, espaces, retours à la ligne et alignements restent intacts.

Mais cette fidélité a un effet secondaire : les longues lignes peuvent dépasser horizontalement.

Par exemple, une commande comme celle-ci peut rapidement casser la mise en page :

rsync -avh --delete --progress --exclude="cache/" --exclude="uploads/cache/" /home/www/example.com/public_html/ user@backup-server:/volume1/backups/example.com/public_html/Langage du code : JavaScript (javascript)

Sur ordinateur, une barre de défilement horizontale peut rester acceptable. Sur mobile, en revanche, elle devient vite pénible. On peut donc choisir de forcer le retour à la ligne.

Solution simple : white-space: pre-wrap

La solution la plus simple consiste à utiliser white-space: pre-wrap. Cette valeur conserve les espaces et les retours à la ligne, tout en autorisant le repli automatique des longues lignes.

pre {
  white-space: pre-wrap;
}Langage du code : CSS (css)

C’est le comportement le plus utile quand on veut garder l’indentation du code, mais éviter les débordements horizontaux.

En clair :

• les retours à la ligne existants sont conservés ;
• les espaces multiples restent visibles ;
• les lignes trop longues peuvent être repliées ;
• le bloc reste lisible sur mobile.

C’est souvent le meilleur compromis pour les articles de blog techniques.

Version moderne recommandée

Pour un site actuel, je recommande généralement cette base :

pre,
pre code {
  white-space: pre-wrap;
  overflow-wrap: anywhere;
}Langage du code : CSS (css)

white-space: pre-wrap autorise le retour à la ligne tout en conservant la mise en forme. Ensuite, overflow-wrap: anywhere permet au navigateur de couper une chaîne très longue si elle ne contient aucun espace naturel.

C’est utile pour les URLs, les chemins de fichiers interminables, les tokens, les commandes longues, ou les chaînes générées automatiquement.

La propriété overflow-wrap sert justement à éviter qu’une chaîne autrement insécable dépasse de sa boîte. MDN précise aussi que l’ancien nom word-wrap reste un alias historique largement reconnu.

Variante plus prudente : overflow-wrap: break-word

Si vous trouvez que anywhere coupe parfois les chaînes de manière trop agressive, utilisez plutôt break-word.

pre,
pre code {
  white-space: pre-wrap;
  overflow-wrap: break-word;
}Langage du code : CSS (css)

Cette version reste très pratique, mais elle se montre un peu moins brutale. Le navigateur essaie d’abord de couper aux endroits naturels, puis il casse la chaîne si elle dépasse vraiment.

Pour un blog technique, c’est souvent le réglage que je préfère. Il évite les débordements sans transformer le code en puzzle.

Faut-il utiliser word-break?

On voit souvent des snippets avec word-break: break-all. Personnellement, je l’éviterais pour des blocs de code.

pre {
  word-break: break-all;
}Langage du code : CSS (css)

Cette règle force des coupures très agressives. Elle peut casser les mots, les commandes, les chemins et les options au milieu d’un segment. Le résultat devient vite difficile à lire.

word-break contrôle la manière dont les sauts de ligne apparaissent quand le texte dépasse son conteneur. Mais, pour les longues chaînes dans du code, overflow-wrap donne souvent un résultat plus propre.

Je réserverais word-break: break-all à des cas très spécifiques, par exemple une colonne très étroite ou une interface d’administration où il faut absolument empêcher tout débordement.

Alternative : garder le scroll horizontal

Forcer le retour à la ligne n’est pas toujours le meilleur choix. Pour certains langages, un scroll horizontal peut mieux préserver la lisibilité du code.

Par exemple, dans un extrait de PHP, JavaScript ou SQL, une ligne coupée peut devenir ambiguë. On peut alors garder le comportement naturel de pre et simplement rendre le débordement plus propre.

pre {
  overflow-x: auto;
  max-width: 100%;
}Langage du code : CSS (css)

Cette approche laisse les lignes intactes, mais elle empêche le bloc de casser la mise en page globale.

C’est souvent le bon choix pour :

• des extraits de code longs ;
• du SQL ;
• des tableaux en texte brut ;
• des logs alignés ;
• des commandes où chaque espace compte ;
• du code que le lecteur va copier-coller.

Le scroll horizontal n’est donc pas forcément un défaut. Parfois, c’est même le comportement le plus fidèle au code.

La meilleure approche : choisir selon le type de contenu

Sur un blog technique, tous les blocs de code ne méritent pas le même traitement. Une commande Bash longue peut être repliée sans trop de problème. En revanche, un extrait de code structuré peut perdre en clarté s’il se replie automatiquement.

On peut donc définir deux styles différents.

Option 1 : code avec retour automatique à la ligne

.code-wrap pre,
pre.code-wrap {
  white-space: pre-wrap;
  overflow-wrap: break-word;
}Langage du code : CSS (css)

Cette option convient bien aux commandes Bash, aux URLs, aux chemins de fichiers et aux snippets courts.

Option 2 : code avec scroll horizontal

.code-scroll pre,
pre.code-scroll {
  white-space: pre;
  overflow-x: auto;
  max-width: 100%;
}Langage du code : CSS (css)

Cette option convient mieux aux extraits de code plus longs, où l’indentation et la structure comptent davantage.

Dans Gutenberg, on peut ajouter une classe CSS personnalisée au bloc Code depuis le panneau “Avancé”. Par exemple : code-wrap ou code-scroll.

Cibler les blocs Code de Gutenberg

Dans WordPress, les blocs Code de Gutenberg utilisent généralement la classe .wp-block-code. On peut donc cibler les blocs de code sans toucher à tous les éléments pre du site.

.wp-block-code {
  max-width: 100%;
  overflow-x: auto;
}Langage du code : CSS (css)

Si l’on veut forcer le retour à la ligne uniquement dans les blocs Gutenberg :

.wp-block-code code {
  white-space: pre-wrap;
  overflow-wrap: break-word;
}Langage du code : CSS (css)

Et si le thème ou le plugin de coloration syntaxique applique ses styles directement sur pre, on peut être un peu plus explicite :

.wp-block-code,
.wp-block-code code {
  white-space: pre-wrap;
  overflow-wrap: break-word;
}Langage du code : CSS (css)

C’est souvent nécessaire avec les plugins de syntax highlighting, car ils ajoutent parfois plusieurs balises autour du code.

Cas particulier : Syntax Highlighting Code Block

Si vous utilisez un plugin comme Syntax Highlighting Code Block, le HTML peut ressembler à ceci :

<pre class="wp-block-code">
  <span>
    <code class="hljs language-css">...</code>
  </span>
</pre>Langage du code : HTML, XML (xml)

Dans ce cas, il peut être utile de cibler à la fois pre, span et code à l’intérieur du bloc :

.wp-block-code,
.wp-block-code span,
.wp-block-code code {
  white-space: pre-wrap;
  overflow-wrap: break-word;
}Langage du code : CSS (css)

Si le plugin ajoute une barre horizontale, un style inline, ou une règle plus spécifique, il faudra peut-être adapter le sélecteur. Dans la majorité des cas, la règle ci-dessus suffit.

Une version propre pour les blogs techniques

Voici une base moderne, simple et plutôt sûre pour un blog WordPress technique :

.entry-content pre,
.entry-content .wp-block-code {
  max-width: 100%;
  overflow-x: auto;
}

.entry-content pre code,
.entry-content .wp-block-code code {
  white-space: pre-wrap;
  overflow-wrap: break-word;
}Langage du code : CSS (css)

Cette version combine les deux protections : le bloc ne dépasse pas de son conteneur, et le code peut revenir à la ligne si nécessaire.

Si vous préférez préserver les lignes longues et garder le scroll horizontal, utilisez plutôt :

.entry-content pre,
.entry-content .wp-block-code {
  max-width: 100%;
  overflow-x: auto;
}

.entry-content pre code,
.entry-content .wp-block-code code {
  white-space: pre;
}Langage du code : CSS (css)

Cette variante est plus fidèle au code original. Elle convient mieux aux extraits complexes.

Et white-space: break-spaces ?

CSS propose aussi white-space: break-spaces. Cette valeur ressemble à pre-wrap, mais elle gère les espaces conservés de manière encore plus stricte.

pre {
  white-space: break-spaces;
}Langage du code : CSS (css)

Elle peut être utile si vous affichez du texte où chaque espace doit vraiment compter. Cependant, pour des blocs de code classiques dans un article WordPress, pre-wrap reste généralement plus prévisible.

Anciennes syntaxes spécifiques aux navigateurs

À l’époque, on ajoutait souvent plusieurs propriétés spécifiques pour gérer les anciens navigateurs :

pre {
  white-space: -moz-pre-wrap; /* Anciens navigateurs Mozilla */
  white-space: -pre-wrap;     /* Opera 4-6 */
  white-space: -o-pre-wrap;   /* Opera 7 */
  word-wrap: break-word;      /* Anciennes versions d’Internet Explorer */
}Langage du code : CSS (css)

Aujourd’hui, ces variantes n’ont plus vraiment d’intérêt pour un site moderne. white-space: pre-wrap est largement établi, et overflow-wrap remplace proprement l’ancien word-wrap.

Mémo rapide

/* Retour à la ligne dans pre, en conservant l'indentation. */
pre {
  white-space: pre-wrap;
}

/* Retour à la ligne + longues chaînes cassées si nécessaire. */
pre,
pre code {
  white-space: pre-wrap;
  overflow-wrap: break-word;
}

/* Variante plus agressive pour URLs, tokens et chemins très longs. */
pre,
pre code {
  white-space: pre-wrap;
  overflow-wrap: anywhere;
}

/* Conserver les lignes intactes avec scroll horizontal. */
pre {
  white-space: pre;
  overflow-x: auto;
  max-width: 100%;
}

/* Blocs Code Gutenberg. */
.wp-block-code,
.wp-block-code code {
  white-space: pre-wrap;
  overflow-wrap: break-word;
}Langage du code : CSS (css)

Conclusion

Pour forcer le retour à la ligne dans une balise pre, la règle de base reste très simple :

pre {
  white-space: pre-wrap;
}Langage du code : CSS (css)

Pour un site moderne, j’ajouterais toutefois overflow-wrap: break-word, surtout si vous publiez des commandes longues, des URLs, des chemins de fichiers ou des logs.

pre,
pre code {
  white-space: pre-wrap;
  overflow-wrap: break-word;
}Langage du code : CSS (css)

Enfin, gardez en tête qu’un retour à la ligne forcé n’est pas toujours souhaitable. Pour du code complexe, un scroll horizontal propre peut parfois être plus lisible. Le bon choix dépend donc du contenu : commande Bash courte, logs, extrait PHP, SQL, configuration serveur ou simple mémo technique.

Comme souvent en CSS, la meilleure solution n’est pas la plus agressive. C’est celle qui respecte le contenu tout en évitant de massacrer la mise en page. Charmant programme.