Améliorer la typographie de la rédaction

Malgré les limites de ZMarkdown

a marqué ce sujet comme résolu.

Bonjour,

En Markdown on peut utiliser _ ou * pour mettre en italique. Ou plus exactement, pour indiquer l’emphase (balise <em> en HTML final), laquelle peut possiblement être rendue en italique sur le navigateur avec le style par défaut.

La règle typographique classique prévoit certains cas d’utilisation de l’italique, dont voici les plus courants :

  • les termes étrangers, incluant possiblement les locutions latines (sauf exceptions) ;
  • l’emphase sur un terme ou une phrase ;
  • les titres d’ouvrage ou d’autres œuvres en général.

Une liste plus complète se trouve sur Wikipédia.

Pour l’emphase, le Markdown gère déjà (même si nous faisons le pari que l’implémentation cliente utilisera de l’italique). En revanche, pour bien d’autres cas basiques, il n’y pas de solution satisfaisante. Certains termes n’ont aucun besoin de finir dans des balises <em>, cela mettrait en péril la structure sémantique de la page HTML finale. L’usage de _ ou de * pour ces cas n’est donc pas pleinement satisfaisant.

C’est plutôt la balise <i> qui aurait cette charge, une balise qui est sémantiquement neutre.

Voici un exemple d’utilisation de la balise <i> dans la documentation MDN :

<p>
  <i class="latin">Musa</i> is one of two or three genera in
  the family <i class="latin">Musaceae</i>;
  it includes bananas and plantains.
</p>

Le Markdown classique peut autoriser le HTML direct, permettant ainsi l’utilisation de <i>...</i>. Cependant, notre ZMarkdown a fait le choix de ne pas l’implémenter pour des raisons de sécurité :

De plus, le Markdown standard autorise l’insertion de HTML, mais pour des raisons de sécurité nous avons choisi de ne pas laisser cette possibilité. Si vous écrivez du HTML, celui-ci apparaitra donc tel quel dans votre texte.

Rédiger sur ZdS

Serait-il envisageable d’autoriser les balises <i> ou une autre solution pour permettre à ZdS de mieux respecter les usages typographiques sur les contenus ?

Qu’en pensez-vous ?

Tout l’ironie de ma question se trouve dans le fait que ces problèmes me sont apparus lors de la validation d’un contenu qui traitait des failles de sécurité par injection de code 🙃

+3 -1

Hello,

La volonté du Markdown est de rester le plus simple possible à écrire. Je ne pense pas qu’ajouter des balises html rentre vraiment dedans. La spécification de base du Markdown, il me semble, est vraiment _ pour de l’italique, peu importe la raison.

+3 -1

Le _ ou * est fait pour ajouter une emphase, ce qui a un sens sémantique (d’où la balise <em>). Il y a une différence avec de l’italique de présentation (balise <i>). Les lecteurs d’écrans et autres robots n’auront pas la même interprétation des deux.

Permette le HTML me paraît dangereux : au-delà de la sécurité, si on autorise certaines balises il va falloir maintenir une liste qui va vite grandir, voire des attributs.

Peut-être qu’on peut trouver une syntaxe dédiée pour l’italique décoratif (du genre //italique// par exemple) ?

À noter : l’italique lié à la balise <em> — comme le gras pour <strong> — n’est qu’une convention, c’est un style commun mais la sémantique et la présentation sont bien à séparer.

@viki53 c’est bien là où je ne suis pas d’accord, je ne crois pas que Markdown soit conçu pour que ce soit particulièrement une emphase, mais bien de l’italique, tout comme ** est spécifiquement indiqué pour le gras. L’erreur ne viendrait-elle pas du fait que l’on considère, nous, que ce doit être une emphase ?

+0 -0

@Moté: Non * et _ marquent l’emphase en Markdown, rien d’autre. Même CommonMark s’accorde là dessus.

Après, rien n’empèche de juste dire que sur ZdS, on réserve _ à l’italique et __ au gras. Alors que * est ** restent des emphases simples.

Ça ne serait qu’une règle d’écriture et c’est 100% compatible avec Markdown sans aucune modification.


Je m’oppose également à l’ajout de la balise <i>. Cette balise est du Markup et n’apporte rien au Markdown puisqu'elle est également seulement sémantique. Et non pas du tout une “sémantiquement neutre” comme l’OP le mentionne.

Je vois venir qu’on me demande mes sources vis à vis du fait que la balise i n’a qu’un rôle sémantique, donc je source: https://developer.mozilla.org/fr/docs/Web/HTML/Element/i#notes. C’est le la DOC MDN de l’OP, c’est la première note.

+2 -0

C’était en effet incorrect de ma part de présenter cette balise comme « sémantiquement neutre ». Mais l’idée de base reste inchangée malgré tout : on ne peut pas mettre de l’italique typographique sans l’associer à de l’emphase HTML avec ZMarkdown, voire Markdown en général.

Je vois que les échanges tournent beaucoup autour des considérations techniques et d’implémentation. Mais au delà de ces aspects, je ne connais pas particulièrement votre avis sur la question sous-jacente qui est de savoir s’il serait intéressant de pouvoir ou non utiliser des italiques (non emphase) pour augmenter la qualité typographique des contenus sur ZdS.

+0 -0

Salut,

En tant qu’auteur, je suis preneur de tout ce qui permet d’améliorer la qualité potentielle du rendu. Si ça n’existe pas, je m’en passe par la force des choses.

Un soucis que j’ai eu avec zmd, c’est l’absence d’imbrication pour faire de la bonne sémantique. Par exemple, si j’ai envie de mettre de l’emphase dans un titre… ce n’est pas possible. On peut couper en deux comme ceci Ceci est un titre avec une emphase en son sein.

C’est rendu par :

<em>Ceci est un titre avec une</em> emphase <em>en son sein</em>

Une solution meilleure serait :

<cite>Ceci est un titre avec une <em>emphase</em>en son sein</cite>

On ne peut pas vraiment faire de miracles avec markdown ceci dit.


J’élargis un peu, mais avoir des choses un peu évoluées (et propres) offre une différenciation notable sur l’efficacité de la transmission de la connaissance. Une référence qui m’a tapé dans l’oeil à ce niveau-là : https://ciechanow.ski/naval-architecture/ .

Évidemment, chaque avancée notable est une marche du point de vue technique vu comment le site marche actuellement.

On ne peut pas vraiment faire de miracles avec markdown ceci dit.

Aabu

C’est pas faux, c’est notamment pour cette raison que j’ai complètement arrêté de l’utiliser pour rédiger du contenu sur ma plateforme personnelle, au profit du HTML brut. Markdown est sûrement très bien au quotidien pour écrire rapidement : dans des commentaires, des messages de forum ou des notes dans un Wiki, par exemple. Mais sur de la rédaction longue, son usage finit toujours par me mettre des bâtons dans les roues, malgré la légèreté de son formatage, par rapport à HTML ou LaTeX. Il y a juste trop de cas (soi-disant exceptionnels) à gérer et MD ne peut pas les supporter.

+3 -0

Au premier abord j’avais compris que tu voulais faire ceci :

Ceci est une emphase

Par contre effectivement dans un cite oui, ce n’est pas possible. Si c’est vraiment un besoin, on peut ajouter une syntaxe particulière.

Je suis tous à fait d’accord avec le fait que Markdown n’est idéal. Il est très généraliste et donc pas spécifiquement adapté à notre cas d’utilisation. Je pense qu’on peut ensemble trouver moyen de l’adapter. Ou choisir autre chose au final.

+2 -0

Une première étape serait de lister les fonctionnalités marquantes. Ça permettra de savoir quelle niveau d’évolution on a besoin, et donc si on peut se satisfaire d’une évolution du markdown ou s’il faudrait ajouter autre chose.

Pour l’instant sont ressorties dans ce sujet :

  • Pouvoir mettre de l’italique qui ne soit pas une emphase (par exemple pour les locutions latines)
  • Pouvoir mettre de l’emphase dans des titres (dans le contexte d’un cite)

@Aabu et @sgble je suppose qui vous avez d’autres manques, vu vos commentaires ?

Je me permets de faire remonter quelques manques qui me semblent notables :

  • les petites capitales, par exemple pour écrire XVIe siècle, avec des petites capitales au lieu de XVI ;
  • une refonte des règles de blancs typographiques, par exemple c’est "fautif" d’avoir une espace fine après un double point ;
  • une distinction formelle entre les règles de gras et italique et leur signification typographique (mais ça rejoint la discussion déjà plus haut) : on devrait indiquer l’emphase et pas l’italique, c’est au logiciel de calculer quel choix de plomb effectuer ;
  • une gestion des paragraphes : en français on fait un retour à la ligne pour marquer une nouvelle suite de phrases, il est normalement exceptionnel d’insérer une ligne blanche ;
  • la création de guidelines pour les auteurs afin de leur rappeler les règles basiques de grammaire et de typographie : par exemple on ne met pas de guillemets ou de chevrons pour accentuer, mais bien de l’emphase (j’ai validés beaucoup de contenus où il y a des oreilles de lapin partout …)

Merci pour cette contribution !

Je commente juste celle-ci :

une gestion des paragraphes : en français on fait un retour à la ligne pour marquer une nouvelle suite de phrases, il est normalement exceptionnel d’insérer une ligne blanche ;

Certes mais c’est bien spécifié en Markdown. Ok, il y a une ligne vide pour séparer les paragraphes mais ça à plusieurs avantages je pense.

+3 -2

J’en profite pour dire que si on veut que ZdS soit pointilleux sur la typographie, alors il faut que cette charge soit portée par ZdS, et ce d’autant plus que les normes internes s’éloignent de l’usage et de ce qu’il est possible de faire facilement avec un clavier français standard. Pour moi, c’est un boulot d’édition qui serait une plus-value intéressante pour ZdS, mais c’est bien un boulot d’édition : c’est à l’éditeur de le faire, pas aux auteurs. Et ça implique donc d’avoir des éditeurs identifiés comme tels au sein de ZdS.

Le risque sinon, c’est qu’on fasse fuir les auteurs pour ce qui apparaitra comme du détail. On a déjà des retours en ce sens, et on ne croule pas sous les auteurs.

Une première étape serait de lister les fonctionnalités marquantes. Ça permettra de savoir quelle niveau d’évolution on a besoin, et donc si on peut se satisfaire d’une évolution du markdown ou s’il faudrait ajouter autre chose.

Pour l’instant sont ressorties dans ce sujet :

  • Pouvoir mettre de l’italique qui ne soit pas une emphase (par exemple pour les locutions latines)
  • Pouvoir mettre de l’emphase dans des titres (dans le contexte d’un cite)

@Aabu et @sgble je suppose qui vous avez d’autres manques, vu vos commentaires ?

SpaceFox

Je pense que tout a été dit en ce qui concerne l’usage de l’italique. Mais j’ajoute une remarque quant au rendu de l’italique sur le site.

Chez moi, voici le rendu avec la fonte Web chargée par défaut (Merriweather) :

On remarque que l’italique n’est pas vraiment de l’italique. Il s’agit d’une simple manipulation graphique du navigateur. Pour cette fonte, la véritable variante italique devrait avoir plutôt cette tête-ci :

Je ne connais pas assez bien le Web, mais je pense que c’est dû au fait que la déclaration n’inclut pas toutes les variantes. Cela dit, je suppose que cela a un coût en bande passante de tout inclure. Le débat est aussi bien technique, donc.

J’en profite pour dire que si on veut que ZdS soit pointilleux sur la typographie, alors il faut que cette charge soit portée par ZdS, et ce d’autant plus que les normes internes s’éloignent de l’usage et de ce qu’il est possible de faire facilement avec un clavier français standard.

Tout à fait d’accord. En tant que validateur, ça ne me choque pas que cela relève essentiellement de la mission de la validation d’assurer le bon usage de ces trucs-là. Je suppose que c’est un peu le même système avec les éditeurs ?

+2 -0

Juste pour l’italique, c’est tout simplement qu’à la création du site, la police Merriweather (ou peut-être même Google Fonts tout court d’ailleurs) ne proposait pas encore de version italique spécifique. C’est pas compliqué à corriger, pour un cout de bande passante qui devrait être globalement faible (c’est une police assez souvent utilisée, et qui peut être mise en cache très longtemps).

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte