Pour garder le code source des tableaux Markdown lisible, ajoutez des espaces de remplissage aux cellules et réalignez chaque colonne après les modifications importantes. Sur un Mac avec Obsidian, effectuez les modifications dans l’éditeur de tableau natif, puis examinez le mode Source. Vérifiez séparément le remplissage du code source et l’alignement du texte affiché.

Ce flux de travail s’adresse à une personne qui tient à jour un petit tableau Markdown dans une application de notes sur ordinateur : une liste de lecture, un inventaire de fournitures de bureau ou une liste de tâches de projet. L’objectif est de garder le texte lui-même facile à parcourir à mesure que les entrées changent, tout en conservant un tableau fonctionnel dans le moteur de rendu prévu.

Qu’est-ce qui rend le code source d’un tableau Markdown lisible ?

Un tableau source lisible présente des limites de colonnes reconnaissables, un espacement régulier et une ligne complète par rangée. Ses barres verticales s’alignent quand on l’affiche dans une police à chasse fixe. La documentation de GitHub précise que les cellules n’ont pas besoin d’avoir la même largeur ni que les colonnes du code source soient parfaitement alignées : cet alignement facilite donc la modification, mais n’est pas nécessaire à la validité du tableau. Organiser des informations avec des tableaux.

Par exemple, ce tableau synthétique est compact, mais devient plus difficile à parcourir après l’ajout d’un nom d’article plus long :

| Item | Finish | Count |
| --- | --- | ---: |
| Pencil | Matte | 4 |
| Large sketchbook | Linen | 12 |

L’ajout d’espaces rend le même contenu plus facile à examiner en texte brut :

| Item             | Finish | Count |
| ---------------- | ------ | ----: |
| Pencil           | Matte  |     4 |
| Large sketchbook | Linen  |    12 |

En GFM, les espaces entre les barres verticales et le contenu des cellules sont supprimés. Le remplissage ne détermine donc pas la largeur des colonnes affichées. Les deux-points dans ----: définissent l’alignement à droite de la colonne affichée ; les espaces avant 4 rendent simplement cet exemple de code source plus facile à parcourir. Spécification GitHub Flavored Markdown, tableaux.

Considérez qu’il s’agit de deux décisions distinctes : choisissez le remplissage pour faciliter la lecture du code source et les deux-points de la ligne de délimitation pour aligner le texte affiché. Si votre seul problème est l’irrégularité des barres dans l’éditeur, modifier les deux-points ne le résoudra pas.

Quel moteur de rendu affichera le tableau ?

Les tableaux à barres verticales sont une extension, et non une fonctionnalité de CommonMark de base. La spécification CommonMark actuelle correspond à la version 0.31.2, tandis que la spécification GFM publiée par GitHub définit explicitement les tableaux comme une extension de CommonMark. Un moteur de rendu décrit uniquement comme compatible avec CommonMark ne garantit donc pas la prise en charge des tableaux à barres verticales. Vérifiez s’il prend également en charge une extension pour les tableaux. Spécification CommonMark, Spécification GitHub Flavored Markdown.

Voici les distinctions à garder à l’esprit lorsque vous déplacez une note d’une application à une autre :

Destination Comportement documenté Choix pratique
CommonMark de base La syntaxe des tableaux à barres verticales ne figure pas dans la spécification de base Vérifiez qu’une extension pour les tableaux est disponible
GitHub Son guide sur les tableaux exige au moins trois traits d’union dans chaque cellule de délimitation Utilisez --- ou davantage
Obsidian Son guide sur les tableaux accepte un minimum de deux traits d’union et n’exige pas l’alignement des cellules dans le code source Utilisez-en au moins trois si vous ciblez aussi GitHub

Les exigences concernant le nombre de traits d’union ci-dessus proviennent des guides respectifs des produits. En utiliser au moins trois est une convention commune pratique pour ces deux destinations ; cela ne rend pas tous les moteurs de rendu Markdown équivalents. Documentation de GitHub sur les tableaux, Syntaxe de mise en forme avancée d’Obsidian.

Pour un tableau destiné à Obsidian et à GitHub, utilisez des barres verticales au début et à la fin, des espaces ordinaires pour le remplissage et une ligne vide avant et après le tableau. Le guide de GitHub exige une ligne vide avant celui-ci ; la spécification GFM indique qu’une ligne vide termine un tableau. Laisser une ligne vide à chaque extrémité rend également le code source plus facile à repérer. Documentation de GitHub sur les tableaux, Limites des tableaux GFM.

Comment tenir le tableau à jour dans Obsidian sur Mac

Obsidian offre une solution pratique aux personnes qui souhaitent modifier facilement les cellules, puis retrouver un Markdown lisible. Les notes de version de la version de bureau 1.5.8 ont introduit la mise en forme automatique des tableaux pendant la saisie, décrite comme produisant des colonnes plus nettes en mode Source. Il s’agit d’un comportement documenté de l’éditeur, et non d’une fonctionnalité de la syntaxe Markdown. Notes de version d’Obsidian 1.5.8 pour ordinateur.

Suivez ces étapes pour une note ordinaire :

  1. Ouvrez la note en mode Live Preview. Au besoin, sélectionnez ce mode à l’aide de l’icône d’état de l’éditeur.
  2. Insérez un tableau à l’aide de la commande Insert Table, ou faites un clic droit et choisissez Insert → Table.
  3. Saisissez ou modifiez le contenu des cellules dans l’éditeur de tableau. Faites un clic droit sur le tableau pour ajouter, supprimer, déplacer ou trier des lignes et des colonnes.
  4. Sélectionnez Source mode à l’aide de l’icône d’état et examinez le Markdown obtenu.
  5. Passez en Reading view pour vérifier l’affichage du tableau.

Les commandes des modes sont documentées dans Modes d’affichage et de modification ; l’insertion de tableaux et les opérations du menu contextuel sont documentées dans Syntaxe de mise en forme avancée.

Pour passer souvent d’un mode à l’autre, attribuez un raccourci clavier à Toggle Live Preview/Source mode. Sur macOS, Cmd+E permet de basculer entre les modes lecture et modification ; utilisez la commande dédiée pour passer spécifiquement de l’un à l’autre des deux modes de modification. Modes d’affichage et de modification dans Obsidian.

Si la modification directe en Source mode laisse un remplissage irrégulier, retournez à l’éditeur de tableau natif pour poursuivre les modifications, puis examinez le code source. La documentation citée confirme la mise en forme automatique des tableaux et l’inspection précise du code source, mais ne garantit pas universellement que toute modification arbitraire du code source entraîne immédiatement un nouveau remplissage. Pour un petit tableau qui reste irrégulier, la méthode manuelle ci-dessous vous donne un contrôle direct.

Comment réaligner les colonnes du code source après une modification importante

Suivez une règle simple : donnez à chaque colonne du code source une largeur suffisante pour sa plus longue entrée actuelle, titre compris. Ajoutez du remplissage aux autres cellules de cette colonne. Recalculez la largeur lorsqu’une entrée dépasse l’espace disponible.

Voici un exemple détaillé utilisant uniquement du texte ASCII ordinaire. Commencez par ce tableau :

| Item   | Finish | Count |
| ------ | ------ | ----: |
| Pencil | Matte  |     4 |
| Folder | Linen  |    12 |

Remplacez maintenant Folder par Large sketchbook. Le nouvel article comporte 16 caractères : la première colonne doit donc avoir une zone de contenu de 16 caractères. Laissez une espace juste après chaque barre verticale délimitant la cellule, puis ajoutez suffisamment d’espaces à la fin pour remplir cette zone :

  • Item compte 4 caractères : ajoutez 12 espaces de remplissage après ce mot, puis l’espace qui précède la barre de délimitation.
  • Pencil compte 6 caractères : ajoutez 10 espaces de remplissage après ce mot, puis l’espace qui précède la barre de délimitation.
  • Large sketchbook remplit la zone de 16 caractères : il suffit donc d’ajouter l’espace qui précède la barre de délimitation.
  • Prolongez la première cellule de délimitation avec 16 traits d’union pour obtenir un repère visuel correspondant.

Vous obtenez le tableau avec remplissage présenté plus haut. Seule la première colonne avait besoin d’être élargie. Les autres colonnes conservent leur espacement et leurs marqueurs d’alignement.

Il s’agit d’une méthode de mise en forme manuelle pour l’exemple ASCII indiqué, et non d’un algorithme général de calcul de largeur des caractères. Pour les modifications courantes, examinez le résultat dans un affichage du code source à chasse fixe. Si les cellules contiennent beaucoup de mise en forme en ligne, tenez compte de la largeur du texte réellement écrit, y compris la ponctuation comme les accents graves et les astérisques.

Après une série de modifications, réalignez le tableau une seule fois au lieu d’ajuster chaque ligne à chaque frappe. Si les entrées deviennent souvent des paragraphes, envisagez de ne garder qu’un intitulé court dans le tableau et de déplacer l’explication dans le texte courant en dessous. Cela réduit le travail de gestion des espaces sans raccourcir les informations sous-jacentes.

Que vérifier si un tableau ne s’affiche pas correctement ?

Commencez par la structure avant d’ajuster les espaces. En GFM, les lignes d’en-tête et de délimitation doivent contenir le même nombre de cellules. Les cellules manquantes des lignes du corps du tableau sont ajoutées comme cellules vides ; les cellules excédentaires sont ignorées. Un tableau peut donc sembler plausible alors que le résultat affiché omet du contenu. Règles d’analyse des tableaux GFM.

Après une modification importante, suivez ces étapes de diagnostic :

  1. Comparez les lignes d’en-tête et de délimitation. Prévoyez une cellule de délimitation pour chaque en-tête.
  2. Examinez chaque ligne du corps du tableau. Conservez le nombre de cellules prévu, même lorsqu’une valeur est vide.
  3. Recherchez les barres verticales littérales dans le contenu. Une barre non échappée peut être interprétée comme une limite supplémentaire.
  4. Examinez les limites des lignes. Gardez chaque ligne du tableau sur une seule ligne de code source et évitez les lignes vides à l’intérieur du tableau.
  5. Affichez un aperçu dans l’application de destination. Vérifiez les valeurs affichées et l’apparence du tableau.

Pour les barres verticales littérales, GitHub indique qu’il faut placer une barre oblique inverse avant le caractère. Cet exemple complet garde Blue | Green dans une seule cellule :

| Item   | Options       |
| ------ | ------------- |
| Folder | Blue \| Green |

L’échappement est nécessaire à la structure ; ajouter des espaces autour d’une barre non échappée ne résoudra pas le problème. Exemple de GitHub sur les barres verticales littérales.

Obsidian documente également l’échappement de la barre verticale utilisée dans l’alias d’un lien interne placé dans un tableau. Il s’agit d’une particularité de la syntaxe d’Obsidian : un alias échappé ne garantit donc pas à lui seul un comportement équivalent des liens sur GitHub. Instructions de mise en forme des tableaux d’Obsidian.

N’appuyez pas sur Enter au milieu d’une longue cellule pour que son code source paraisse moins large. Les tableaux GFM acceptent le contenu en ligne et excluent les éléments de bloc ; ils n’offrent pas de format général pour les cellules dont le code source s’étend sur plusieurs lignes. Déplacez les longues explications hors du tableau lorsque les lignes sur une seule ligne deviennent difficiles à gérer. Règles GFM sur le contenu des tableaux.

Gardez les opérations de mise à jour simples : terminez les modifications du contenu, vérifiez les limites des cellules, ajoutez du remplissage aux colonnes concernées et examinez le tableau affiché. Dans Obsidian, l’éditeur de tableau natif suivi du Source mode constitue un point de départ pratique. Le remplissage manuel reste utile lorsque vous souhaitez obtenir une mise en page particulière en texte brut.

Sources