OK
AJAX error!

Les forumsGrammalecteGuillemets

Guillemets


Le traitement actuel des guillemets ne me semble pas parfait.

J'ai utilisé le texte d'essai (d'une ligne) ci-dessous avec l'extension Thunderbird 0.5.18 :

Guillemet 'simple', "double", "mélangé', "manquant, 'autre manquant, fermant".

1° Après corrections Grammalecte, j'obtiens des guillemets typographiques types ‘1’ “2” « 3 ». Le guillemet clavier simple me donne accès aux types 1 et 2. Le guillemet clavier double me donne accès aux types 2 et 3. Pourquoi pas les 3 types dans les 2 cas ?

2° Les caractères apparaissant dans les carrés verts de suggestions ne correspondent pas (ouvrant/fermant) à ce qu'on obtient après correction (seulement le type est bon).
Pour le guillemet clavier "double" l'ordre des types proposés est inversé entre ouvrant et fermant (pas pour le 'simple') !

3° Grammalecte ne tique pas (c'est mauvais) sur les guillemets clavier "mélangés' mais n'accepte pas après correction (c'est bon) les types ouvrant/fermant mélangés même s’il n'a pas proposé des choix compatibles (voir 1° plus haut).

4° Grammalecte ne tique pas (c'est mauvais) sur les guillemets clavier "manquant, 'autre manquant, fermant". Cependant il a détecté s’ils sont ouvrants ou fermants (au moins dans mon texte d'essai).
Comment suis-je sensé découvrir et corriger l'erreur d’appairage (ouvrant/fermant) ? Après correction le texte :
« manquant, “autre manquant, fermant”
ne signale pas d'erreur !

5° Est il possible de traiter les guillemets par paire ouvrant/fermant ?

6° La procédure actuelle est lourde et verbeuse : elle me semble justifiée pour LibreOffice (où les documents sont de haute qualité), mais pas pour Thunderbird (où le style est plus familier) pour lequel j'aimerais avoir au moins les options :
- procédure actuelle,
- ne pas changer les guillemets entrés au clavier en des guillemets typographiques (donc les ignorer sauf les erreurs d’appairage ou mélanges),
- proposer un seul type à la fois (un seul carré vert par ligne) de guillemet typographique : type 1 ou 2 ou 3 (ça fait 3 options différentes).
Donc 5 possibilités en tout.
le 30 octobre 2017 à 18:00
1. Parce qu’il est très peu probable que celui qui écrit <'> ait voulu écrire des chevrons (<«> ou <»>). Parce que celui qui a écrit <"> pouvait déjà écrire un guillemet simple <'> si c’était ce qu’il voulait.

2.

Les caractères apparaissant dans les carrés verts de suggestions ne correspondent pas (ouvrant/fermant) à ce qu'on obtient après correction (seulement le type est bon).


Je ne comprends pas. Ce que j’ai compris, je n’ai pas réussi à le reproduire.

Pour le guillemet clavier "double" l'ordre des types proposés est inversé entre ouvrant et fermant (pas pour le 'simple') !


Ah oui. Corrigé.

3. Avec les guillemets droits (<"> et <'>) il est compliqué de savoir ce qu’a voulu faire l’utilisateur. Quand vous écrivez <«> ou <”>, il y a un sens plus net, c’est pourquoi on contrôle. Il est vrai que les vérifications sont légères. Mais c’est parce qu’on présume que celui qui utilise des guillemets typographiques sait à peu près ce qu’il fait.

4.

« manquant, “autre manquant, fermant”


Ceci est parfaitement valide. Un guillemet ne se ferme pas nécessairement sur le même paragraphe. Or, le correcteur grammatical a pour borne le paragraphe. C’est sa limite. Avant ou après, il ne sait plus rien.
Il est vrai cependant que les guillemets <“> et <’> pourraient être plus contrôlés. Je vais voir ce qui est possible.
Edit : J’ai ajouté d’autres contrôles.

5.

Est il possible de traiter les guillemets par paire ouvrant/fermant ?


Oui, c’est possible. Ça a fonctionné comme ça pendant longtemps, mais ça engendre de nombreux problèmes pires que celui que ça résout. Il est possible qu’il y ait des erreurs entre les guillemets. Et les problèmes de chevauchements d’erreurs sont trop compliqués à gérer dans bien des cas.

6.

- ne pas changer les guillemets entrés au clavier en des guillemets typographiques (donc les ignorer sauf les erreurs d’appairage ou mélanges),


Je ne suis pas sûr de comprendre.
De toute façon, le correcteur n’a aucun moyen de faire la distinction entre ce que vous avez tapé au clavier et le reste. Le correcteur reçoit un texte et ne sait pas d’où il vient, ni comment il a été constitué.

- proposer un seul type à la fois (un seul carré vert par ligne) de guillemet typographique : type 1 ou 2 ou 3 (ça fait 3 options différentes).


Compliqué à mettre en œuvre. Le nombre d’options possible est limité, et à vrai dire je n’en vois pas l’intérêt.
le 30 octobre 2017 à 19:12
Pour bien se comprendre il faut mettre les même sens sur les même mots !
Pour moi :
- les "guillemets clavier" ou "guillemets entrés au clavier" sont ceux qui apparaissent sur mon écran quand j'entre mon texte. Ils sont verticaux (donc aussi bien entrant que fermant) et simple ou double. Ils peuvent encore exister après une passe de Grammalecte si j'ai refusé la correction. Je propose de les appeler "guillemets verticaux", "simples" ou "doubles" selon le cas. Dans le texte cela fait 2 combinaisons binaires différentes.
- les "guillemets typographiques" ne sont pas obtenus simplement au clavier mais par Grammalecte. Ils ont une variante différente en "entrant" et "fermant" et 3 types "simples" ou "doubles" ou "chevron=guillemet_français" en abrégé types 1, 2, 3. Dans le texte cela fait 6 combinaisons binaires nouvelles différentes.

Actuellement je teste uniquement l'extension Thunderbird 0.6.0 du 24 octobre 2017. J'ai des choix qui pourraient être différents si j'utilisais LibreOffice ou Firefox. En effet le courriel est un mode d'expression rapide et en général familier : il ne me parait pas nécessaire d'appliquer toujours toutes les règles de la typographie en particulier de forcer l'usage des variantes typographiques des caractères comme guillemets, signe multiplier, tirets variés, apostrophe, etc. En revanche il faut toujours corriger les fautes d'orthographe ou d'accord, les espaces multiples ou entourant les signes de ponctuation.
Le courriel a la particularité d'avoir un émetteur et un récepteur qui sont 2 personnes différentes et n'utilisent pas forcément le même code page donc il y a un risque d'obtenir des lettres farfelues pour les caractères au delà du rang binaire 128.

Les guillemets servent à introduire une citation, un dialogue (peu courant dans un courriel), mettre le caractère guillemet dans le texte (sans qu'il joue le rôle de guillemet mais c'est vraiment rare) ou, pour moi, à délimiter des groupes de caractères qui ne sont pas des mots normaux (URL, nom de fichier, adresse de courriel) donc ils sont couramment utilisé dans un courriel. C'est pour ça que j'ai à cœur leur traitement.

1. Parce qu’il est très peu probable que celui qui écrit <'> ait voulu écrire des chevrons (<«> ou <»>). Parce que celui qui a écrit <"> pouvait déjà écrire un guillemet simple <'> si c’était ce qu’il voulait.


Votre position est logique si on admet que l'auteur sait parfaitement, au moment de l'entrée du texte, quel type de guillemet sera utilisé après correction par Grammalecte.
Pour moi je préfère attendre la fin de l'entrée du texte pour choisir le type de guillemet le meilleur. IL me parait plus souple d'offrir, quelque soit le guillemet non typographique dans le texte, les 3 types de guillemets typographiques donc 3 carrés verts. Pour l'utilisateur, il n'est guère plus compliqué de choisir 1 parmi 3 que 1 parmi 2 et il peut toujours corriger les erreurs de guillemets entrés, "mélangés' ou autres, en une seule passe au lieu de 2 si on veut les guillemets typographiques simples ou chevrons. Pour le programme il est probablement plus simple de n'avoir à choisir qu'entre 2 lignes de 3 carrés verts (au lieu de 4 de 2 carrés) mais plus compliqué de choisir selon le carreau cliqué parmi 3 le caractère à insérer.

2.

Je ne comprends pas. Ce que j’ai compris, je n’ai pas réussi à le reproduire.


Visuellement le guillemet représenté dans le carré vert de suggestion ne présent aucune ambiguïté ouvrant/fermant pour les chevrons mais pour les 2 autres types il semble vertical donc ambiguë et non conforme à la correction qui est inclinée vers l'intérieur (en descendant) du contenu de la paire de guillemets ouvrant/fermant. Êtes vous sûr d'avoir utilisé le bon code binaire ?

4.

Ceci est parfaitement valide. Un guillemet ne se ferme pas nécessairement sur le même paragraphe. Or, le correcteur grammatical a pour borne le paragraphe. C’est sa limite. Avant ou après, il ne sait plus rien.


Sauf le cas d'une longue citation les guillemets sont ouverts puis fermés dans la même phrase. Les exemples que j'ai donnés ont probablement 90 % de chances d'être une erreur : les 10 % de faux positifs sont un mal nécessaire ! Une longue citation abrégée avec [...] ou l'utilisation d'un guillemet comme signe (voir 6) peuvent donner des guillemets non en couple !
Beaucoup de programmes (sauf JavaScript) introduisent une chaine de caractères entre 2 "guillemets verticaux", "simples" ou "doubles" selon le choix du programmeur. L'autre type peut figurer dans la chaine. Ils savent gérer ça même si la chaine est continuée sur plusieurs lignes...

l est vrai cependant que les guillemets <“> et <’> pourraient être plus contrôlés. Je vais voir ce qui est possible.
Edit : J’ai ajouté d’autres contrôles.


Mettre le guillemet français dans le même sac.

5.

Oui, c’est possible. Ça a fonctionné comme ça pendant longtemps, mais ça engendre de nombreux problèmes pires que celui que ça résout. Il est possible qu’il y ait des erreurs entre les guillemets. Et les problèmes de chevauchements d’erreurs sont trop compliqués à gérer dans bien des cas.


Je respecte votre expérience. J'aurais aimé pouvoir corriger la paire d'un seul clic car je suis paresseux !

6.

Je ne suis pas sûr de comprendre.
De toute façon, le correcteur n’a aucun moyen de faire la distinction entre ce que vous avez tapé au clavier et le reste. Le correcteur reçoit un texte et ne sait pas d’où il vient, ni comment il a été constitué.


Je tape sur des touches ce qui met dans le texte original certaines combinaisons binaires et je vois apparaitre des formes, le correcteur voit des octets contenant une combinaison binaire et les change selon les instructions du programme et celles que je lui donne ce qui modifie, à chaque passe, les formes que je vois (un peu, beaucoup , pas du tout).

Les 5 options que je proposais sont :
1 ne rien changer à la procédure actuelle.
2 ne pas forcer l'usage des caractères typographiques comme guillemets, signe multiplier, tirets variés, apostrophe, etc. donc ne pas réagir aux combinaisons binaires entrées au clavier pour les représenter de façon approximative et passe-partout. Cela devrait éviter d’exécuter pas mal de regexp donc accélérer le programme et l'utilisateur aurait beaucoup moins d'erreurs à lire et à choisir de cliquer ou non donc autre gain de temps. Cette option peut être réalisée avec une grosse option générale aux caractères typographiques ou plusieurs s’appliquant à des groupes différents de caractères.
3, 4 et 5 : quelque soit le type de "guillemet vertical" dans le texte, proposer un seul type à la fois (un seul carré vert par ligne) de guillemet typographique : selon le cas type 1 ou 2 ou 3.
En général les utilisateurs ont un guillemet typographique préféré (pour moi le "chevron" ou guillemet français aussi utilisé par LibreOffice) qu'ils utilisent presque toujours. S'il est seul proposé on ne risque pas une erreur en visant mal avec la souris !

Compliqué à mettre en œuvre.


Pas forcément : si le code de la ligne correspondant à l'erreur est préparée 1 fois pour toute en début du programme dans une variable.

Le nombre d’options possible est limité, et à vrai dire je n’en vois pas l’intérêt.


Les options nombreuses plaisent aux utilisateurs car le programme s'adapte à leurs désirs mais c'est un cauchemar pour le programmeur car 10 options (choix binaire) indépendantes et ne s'excluant pas=1024 cas à tester et 20=un million ! Il faut un équilibre... Est ce que les options 3, 4, 5 valent le coup ?

LibreOffice se débrouille assez bien quand on entre le texte :
Il traduit le guillemet double " en chevron en gérant ouvrant/fermant de façon simpliste et conserve le simple ' inchangé.
« guillemet double » 'autre guillemet simple'.
Après une espace ou au début " donne guillemet français ouvrant, après une lettre c'est fermant.
On obtient :
X dit : « dans un dialogue, on utilise le signe « pour la prise de parole ». après espace <signe ">
Y - «  mais le signe « pour la fin ». après espace <signe "> = planté !
Z - «  non, le signe » pour la fin ». après lettre <signe"> = bon
le 10 novembre 2017 à 18:03
Il faut comprendre que le correcteur grammatical est le même pour toutes les interfaces, que ce soit LibreOffice, Firefox, Thunderbird, en mode serveur, etc.
Les options sont là pour que chacun puisse faire ce qu’il veut. Elles ne sont pas si compliquées à ajouter, mais il y a un gros problème : l’interface de LibreOffice ne permet pas d’en créer un nombre énorme. Ça doit tenir sur une petite fenêtre. J’aimerais pouvoir créer des onglets pour ajouter des tonnes d’options, mais ce n’est pas possible. D’où une limitation drastique des choix.

1.

Pour moi je préfère attendre la fin de l'entrée du texte pour choisir le type de guillemet le meilleur. IL me parait plus souple d'offrir, quelque soit le guillemet non typographique dans le texte, les 3 types de guillemets typographiques donc 3 carrés verts.


Pourquoi pas. Je vais y songer.

2.

Visuellement le guillemet représenté dans le carré vert de suggestion ne présent aucune ambiguïté ouvrant/fermant pour les chevrons mais pour les 2 autres types il semble vertical donc ambiguë et non conforme à la correction qui est inclinée vers l'intérieur (en descendant) du contenu de la paire de guillemets ouvrant/fermant. Êtes vous sûr d'avoir utilisé le bon code binaire ?


Ce qui est affiché dans les zones de suggestion, quel que soit le logiciel, correspond exactement à ce que vous insèrerez dans votre texte en cliquant dessus. S’il y a des différences d’affichage, elles ne peuvent venir que de la manière d’afficher du logiciel. Je présume donc que le coupable, c’est la police de caractères.

4.

Sauf le cas d'une longue citation les guillemets sont ouverts puis fermés dans la même phrase. Les exemples que j'ai donnés ont probablement 90 % de chances d'être une erreur : les 10 % de faux positifs sont un mal nécessaire ! Une longue citation abrégée avec [...] ou l'utilisation d'un guillemet comme signe (voir 6) peuvent donner des guillemets non en couple !


Grammalecte ne sait pas distinguer une citation d’un dialogue. Il est hors de question de signaler les chevrons ouvrants ou fermants qui ne trouvent pas leur équivalent dans le paragraphe. Ça voudrait dire que quiconque écrit un roman dans LibreOffice verrait ses dialogues ponctués de faux positifs. Il se trouve que c’est la raison précise pour laquelle j’ai créé Grammalecte.
Quand j’ai voulu modifier LanguageTool pour rectifier ces insupportables faux positifs sur les guillemets, on m’a demandé de justifier mon approche par une étude statistique. De mon point de vue, ça n’avait aucun sens, puisque ça dépend de ce qu’on fait. Or, pour moi, un faux positif est pire qu’un silence trompeur. Je comprends qu’on puisse ne pas être d’accord avec ce choix, mais c’est l’approche choisie.
Idéalement, il faudrait une option pour ce point, mais comme dit plus haut, c’est problématique. Et comme les guillemets oubliés ne me semblent pas être une erreur si fréquente, l’option ne me paraît pas digne d’intérêt dans le cadre limitant dans on lequel on est.

Réflexion faite, il y a quelques cas où il serait peut-être possible de distinguer un dialogue d’une citation. Il faut que j’y réfléchisse.

Edit : J’ai créé une règle pour détecter les guillemets doubles <“> <”> qui manqueraient dans un paragraphe. Puisque seuls les chevrons sont utilisés pour ouvrir ou fermer des dialogues sur plusieurs paragraphes.

5.

Cette option peut être réalisée avec une grosse option générale aux caractères typographiques


Cette option existe déjà. Les options typographiques sont déjà les plus nombreuses.

Pour le reste, comme signalé, je suis limité dans le nombre d’options.
Et je trouve votre demande de n’avoir qu’un seul guillemet proposé en contradiction avec votre demande première d’avoir les trois guillemets dans tous les cas.

Pas forcément : si le code de la ligne correspondant à l'erreur est préparée 1 fois pour toute en début du programme dans une variable.


Ça ne peut pas fonctionner comme ça dans LibreOffice, les paragraphes n’étant pas nécessairement passés dans l’ordre.
Et même si c’était faisable, ce que vous demandez, c’est que le logiciel devine ce que vous voulez faire et active des options en fonction de ça. Ça me paraît casse-gueule. J’ai déjà répondu à d’autres demandes du même tonneau : je préfère ne pas faire de devinettes sur les intentions des utilisateurs.

Et, je le répète, le correcteur n’a aucun moyen de faire la distinction entre ce que vous avez tapé au clavier et le reste. Le correcteur reçoit des paragraphes en entrée, il renvoie une liste d’erreurs en fonction des options activées.
le 10 novembre 2017 à 20:18

Les options sont là pour que chacun puisse faire ce qu’il veut. Elles ne sont pas si compliquées à ajouter, mais il y a un gros problème : l’interface de LibreOffice ne permet pas d’en créer un nombre énorme. Ça doit tenir sur une petite fenêtre. J’aimerais pouvoir créer des onglets pour ajouter des tonnes d’options, mais ce n’est pas possible. D’où une limitation drastique des choix.


J'ai vu que Libre Office prévois qu'un utilisateur leur envoie un message lorsqu'il détecte un mauvais fonctionnement de leur programme. Pourquoi n'utiliserai-je pas ça pour leur demander de corriger ce qui vous gêne ? Pouvez vous me préciser ce qu'il faut que je demande ?
J'ai regardé dans leurs menus : il y a "Outils -> Options" qui permet d'accéder aux options de LibreOffice, dans la partie gauche 9 chapitres qu'on peut ouvrir en sous-chapitres ; si on sélecte un de ces derniers on obtient une page à droite avec de nombreuses options. J'évalue le nombre total à plusieurs centaines (certaines semblent faire double emploi avec Grammalecte). Il y a a aussi "gestionnaire d'extensions" dont l'aide dit qu'on obtient les options de l'extension en cliquant dessus. Il ne se passe rien pour la vieille version de Grammalecte que j'ai ; une autre extension affiche un écran similaire (mais plus petit) à celui de "Outils -> Options" mais je ne sait pas s'il accepte des sous-chapitres...
Je suggère de créer 3 nouveaux fils à placer en tête de la liste : ce qui gêne l'écriture des versions de Grammalecte pour 1 Firefox, 2 LibreOffice, 3 Thunderbird. Si un de leurs développeurs vient sur le site (ça arrivera d'autant plus que nous serons nombreux à demander) il verra tout de suite ce qu'il y a à faire !

1.

Pourquoi pas. Je vais y songer.

Pourrez vous me prévenir de ce que vous ferez ?

2.

Ce qui est affiché dans les zones de suggestion, quel que soit le logiciel, correspond exactement à ce que vous insèrerez dans votre texte en cliquant dessus. S’il y a des différences d’affichage, elles ne peuvent venir que de la manière d’afficher du logiciel. Je présume donc que le coupable, c’est la police de caractères.


J'aurais du y penser plus tôt : La zone texte et la zone suggestion n'ont visiblement pas la même taille ni fonte de caractères !
Je suis en mode texte sur Thunderbird (le mode html peut cacher des codes malicieux). Dans les options de TB on peut définir des codages différents pour les messages entrants et sortants, avoir une police et une taille par défaut mais en accepter d'autres. Qu'est ce que Grammalecte impose ?

4.

Grammalecte ne sait pas distinguer une citation d’un dialogue.


Normalement il y a un guillemet au début et à la fin pour les 2 et dans le dialogue un tiret devant chaque intervenant sauf pour le premier.

Or, pour moi, un faux positif est pire qu’un silence trompeur. Je comprends qu’on puisse ne pas être d’accord avec ce choix, mais c’est l’approche choisie.


J'ai été dégouté par le correcteur grammatical de Word 2 où seulement 1/3 des propositions étaient valides mais je suis prêt à accepter 10 % de faux positifs. Comme vous le dite on peut toujours écrire une succession de phrases pièges. Il faudrait des options fines pour s'adapter au genre qu'on écrit. Donc ce n'est pas actuellement possible.

5.

Cette option existe déjà. Les options typographiques sont déjà les plus nombreuses.

Je n’avais pas osé décocher "caractères typographiques" !

Et je trouve votre demande de n’avoir qu’un seul guillemet proposé en contradiction avec votre demande première d’avoir les trois guillemets dans tous les cas.


Pas vraiment : il y a le mode avec toutes les possibilités "3 carrés" (au lieu de 2) pour les textes compliqués (plusieurs étages de guillemets) et le mode simple étage rapide "1 carré".

Le correcteur reçoit des paragraphes en entrée,


Quelle est la définition du paragraphe pour le correcteur ?
Pour moi il y a le
- point simple suivi d'une espace, la phrase suivante commence juste après par une majuscule sur la même ligne ;
- point à la ligne, pas d'espace, la phrase suivante commence par une majuscule à la ligne en dessous ;
- point à la ligne suivi d'une ligne vide ou blanche qui marque la fin du paragraphe et le début du paragraphe suivant.
Est ce que le correcteur utilise les même définitions ?
le 18 novembre 2017 à 16:45

nigelle :
Si un de leurs développeurs vient sur le site (ça arrivera d'autant plus que nous serons nombreux à demander) il verra tout de suite ce qu'il y a à faire !


Les bugs ont déjà été signalés, mais sont noyés sous la masse des choses qu’ils ont à faire, et les dévs de ces logiciels ne viennent pas ici.

1.

Pourrez vous me prévenir de ce que vous ferez ?


Mes réflexions prennent parfois beaucoup de temps. Et pour l’instant, je ne suis pas convaincu.
Quant à vous prévenir, il me semble que ça se verra aisément si le comportement du logiciel change.
Mais j’ai déjà amélioré et je vais améliorer encore la détection des citations non ouvertes et non fermées, mais la marge de manœuvre est limitée.

2.

J'aurais du y penser plus tôt : La zone texte et la zone suggestion n'ont visiblement pas la même taille ni fonte de caractères !
Je suis en mode texte sur Thunderbird (le mode html peut cacher des codes malicieux). Dans les options de TB on peut définir des codages différents pour les messages entrants et sortants, avoir une police et une taille par défaut mais en accepter d'autres. Qu'est ce que Grammalecte impose ?


Pour le panneau de correction, hormis le paragraphe corrigé qui est affiché avec une police monospace, aucune police n’est spécifiée pour le reste. Grammalecte utilise donc la police par défaut de Thunderbird, je pense.

4.

je suis prêt à accepter 10 % de faux positifs.


C’est déjà beaucoup. Et signaler tous chevrons ouvrants non fermés ou l’inverse va emmerder à 100 % ceux qui écrivent des dialogues.
Dans le fond, le problème, c’est que l’erreur que vous voudriez que Grammalecte signale est, pour ce que j’en ai observé, extrêmement rare, totalement minoritaire par rapport à l’usage courant. Il peut y avoir des centaines, des milliers de dialogue dans un texte. Combien de citations avec des guillemets manquants ? C’est une erreur que je n’ai quasiment observée.

5.

Quelle est la définition du paragraphe pour le correcteur ?
Pour moi il y a le
- point simple suivi d'une espace, la phrase suivante commence juste après par une majuscule sur la même ligne ;
- point à la ligne, pas d'espace, la phrase suivante commence par une majuscule à la ligne en dessous ;
- point à la ligne suivi d'une ligne vide ou blanche qui marque la fin du paragraphe et le début du paragraphe suivant.
Est ce que le correcteur utilise les même définitions ?


Non, vos deux premiers exemples sont complètement erronés. Vous n’avez jamais réfléchi à la question. Le troisième est potentiellement correct, mais ce n’est pas comme ça que ça fonctionne. Il n’y a pas de définition uniforme d’un paragraphe.

Pour LibreOffice, ce n’est pas Grammalecte qui décide ce qui est un paragraphe, c’est LibreOffice. Et pour LO, un paragraphe se termine par un caractère “fin de paragraphe”. Qu’importe la ponctuation ou ce qu’il y a après.
En HTML, c’est un </p> ou </div>. Peu importe ce qui est avant ou après. Peu importe la ponctuation.
Mais c’est plus compliqué que ça, parce que Firefox et Chrome, par exemple, n’ont pas la même approche, et décident ce qu’ils veulent.
Dans Thunderbird, c’est bordel.
Et sur du texte simple, la fin de paragraphe, c’est simplement la fin de ligne (ou éventuellement la ligne vide).
le 20 novembre 2017 à 11:25

Notification par e-mail    1