Bug si le contenu dépasse la largeur du textarea #3

Closed
opened 2021-10-28 15:26:32 +02:00 by MathieuAlphamosa · 36 comments

Si il n'y a pas d'espace/tiret pour scinder une ligne de contenu alors PRISM perd les pédales

Pour test :

LIGNEPASOKsqdqsdqsdqsdqsdjhqskjdgjqsgdjhqsgdjhqsghjdgqshjdgqshjdgjhsqgdhsqgjhdgqsjhgdjhqsgdjhqsgdjhgqsjhdgqjhsdgjhsqdgjhghj


LIGNEOKsqdqsdqsdqsdqsdjhqskjdgjqsgdjhqsgdjhqsghjdgqshjdgqshjdgjhsq-gdhsqgjhdgqsjhgdjhqsgdjhqsgdjhgqsjhdgqjhsdgjhsqdgjhghj


<img_carrousel|images=4,7,1,2|navigation=points|format=ligne_images|largeur=800|hauteur=400|clic=image|legende=titre>

A noter : le scroll horizontal qui apparaît également, c'ets peut être une piste pour régler le souci.

Si il n'y a pas d'espace/tiret pour scinder une ligne de contenu alors PRISM perd les pédales Pour test : ``` LIGNEPASOKsqdqsdqsdqsdqsdjhqskjdgjqsgdjhqsgdjhqsghjdgqshjdgqshjdgjhsqgdhsqgjhdgqsjhgdjhqsgdjhqsgdjhgqsjhdgqjhsdgjhsqdgjhghj LIGNEOKsqdqsdqsdqsdqsdjhqskjdgjqsgdjhqsgdjhqsghjdgqshjdgqshjdgjhsq-gdhsqgjhdgqsjhgdjhqsgdjhqsgdjhgqsjhdgqjhsdgjhsqdgjhghj <img_carrousel|images=4,7,1,2|navigation=points|format=ligne_images|largeur=800|hauteur=400|clic=image|legende=titre> ``` A noter : le scroll horizontal qui apparaît également, c'ets peut être une piste pour régler le souci.
Member

Résolu par le simple 9cb8501c6c a priori.

Je te laisse clôturer si cela marche bien :)

Résolu par le simple https://git.spip.net/spip-contrib-extensions/prism/commit/9cb8501c6c636cc99d2cb3a90b1b891bf4dd8451 a priori. Je te laisse clôturer si cela marche bien :)
Member

Je ne pense pas que ça soit une bonne idée

image

  1. ça coupe sur le milieu de tous les mots
  2. il faut aussi le mettre (si conservé) sur le textarea
Je ne pense pas que ça soit une bonne idée ![image](/attachments/5b885454-c540-4282-b0a2-9d593fc9f99e) 1) ça coupe sur le milieu de tous les mots 2) il faut aussi le mettre (si conservé) sur le textarea
155 KiB
Member

Par contre, cela semble bien corriger

.prism-live code.language-md,
.prism-live code.language-markdown,
.prism-live code.language-spip_typo, 
pre.prism-live, 
textarea.prism-live {
    white-space: pre-wrap !important;
+    overflow-wrap: break-word;
}

Pour références : https://css-tricks.com/where-lines-break-is-complicated-heres-all-the-related-css-and-html/

Par contre, cela semble bien corriger ```diff .prism-live code.language-md, .prism-live code.language-markdown, .prism-live code.language-spip_typo, pre.prism-live, textarea.prism-live { white-space: pre-wrap !important; + overflow-wrap: break-word; } ``` Pour références : https://css-tricks.com/where-lines-break-is-complicated-heres-all-the-related-css-and-html/
Member

image

![image](/attachments/b1b943f5-f253-4c9c-85f1-65b55110362b)
135 KiB
Member

Ah merde, en effet, j'en ai oublié de tester sur du texte courant ! :-/ Solution fioreuse du coup, à ne pas conserver... merci @marcimat :)

Après, est-ce vraiment un bug ? Comment peut-on se retrouver avec des lignes entières sans espace tiret ?

Pour le cas des modèles, il suffit de les saisir sur plusieurs lignes, ça permet de gagner en lisibilité qui plus est ^^ :-p

<img_carrousel
|images=4,7,1,2
|navigation=points
|format=ligne_images
|largeur=800
|hauteur=400
|clic=image
|legende=titre>
Ah merde, en effet, j'en ai oublié de tester sur du texte courant ! :-/ Solution fioreuse du coup, à ne pas conserver... merci @marcimat :) Après, est-ce vraiment un bug ? Comment peut-on se retrouver avec des lignes entières sans espace tiret ? Pour le cas des modèles, il suffit de les saisir sur plusieurs lignes, ça permet de gagner en lisibilité qui plus est ^^ :-p ``` <img_carrousel |images=4,7,1,2 |navigation=points |format=ligne_images |largeur=800 |hauteur=400 |clic=image |legende=titre> ```
Member

Si si, il faut l’implémenter : c’est très facile d’avoir ça simplement avec une URL.

Si si, il faut l’implémenter : c’est très facile d’avoir ça simplement avec une URL.
Member

J'ai donc commité ta proposition @marcimat qui après quelques tests semble parfaitement fonctionner, en tout cas mieux que la mienne...

J'ai donc commité ta proposition @marcimat qui après quelques tests semble parfaitement fonctionner, en tout cas mieux que la mienne...
Author
Member

Alors on a toujours le souci sur :

  • des URLs longues https://monbeaunomdedomainearallonge.com/chemin/chemin/chemin/chemin/chemin/chemin/chemin/oups
  • des modèles chelous <img_carrousel|images=4,7,1|navigation=vignettes|hauteur=500|clic=image|legende=titre>
    Voir captures d'écrans.

J'arrive à corriger avec la règle suivante :

.prism-live .token.tag,
.prism-live .token.url {
    line-break: anywhere;
}

Mais aucune idée si on devrait l'appliquer à d'autres éléments ou si c'ets le bon endroit pour le faire.

Alors on a toujours le souci sur : - des URLs longues `https://monbeaunomdedomainearallonge.com/chemin/chemin/chemin/chemin/chemin/chemin/chemin/oups` - des modèles chelous `<img_carrousel|images=4,7,1|navigation=vignettes|hauteur=500|clic=image|legende=titre>` Voir captures d'écrans. J'arrive à corriger avec la règle suivante : ``` .prism-live .token.tag, .prism-live .token.url { line-break: anywhere; } ``` Mais aucune idée si on devrait l'appliquer à d'autres éléments ou si c'ets le bon endroit pour le faire.
Member

Étrange, je ne reproduis pas, ni sous FirefoxESR (v. 78.15.0), ni sous Firefox (v. 88.0.1), ni sous Vivaldi (v. 4.3.2439.56), sous une Debian Testing à jour...

Par contre, sous Chromium sous Debian ou sous Chrome ou Edge sous Windows, en effet, ça coince...

Re-EDIT : En fait... non, je ne reproduis finalement sur aucun de ces navigateurs sous Windows ou Debian... La faute à une drôle de blague du cache... J'ai complètement désinstallé le plugin, refait un git clone, purgé le cache et là, magie, tout fonctionne !

Étrange, je ne reproduis pas, ni sous FirefoxESR (v. 78.15.0), ni sous Firefox (v. 88.0.1), ni sous Vivaldi (v. 4.3.2439.56), sous une Debian Testing à jour... Par contre, sous Chromium sous Debian ou sous Chrome ou Edge sous Windows, en effet, ça coince... Re-EDIT : En fait... non, je ne reproduis finalement sur aucun de ces navigateurs sous Windows ou Debian... La faute à une drôle de blague du cache... J'ai complètement désinstallé le plugin, refait un git clone, purgé le cache et là, magie, tout fonctionne !
Member

@MathieuAlphamosa, bonjour :-) le problème persiste-t-il ? Si non, on pourra clôturer et proposer un nouveau tag pour répondre à https://discuter.spip.net/t/coloration-code-et-coloration-live/19863/88

Merci pour ton retour !

@MathieuAlphamosa, bonjour :-) le problème persiste-t-il ? Si non, on pourra clôturer et proposer un nouveau tag pour répondre à https://discuter.spip.net/t/coloration-code-et-coloration-live/19863/88 Merci pour ton retour !
Author
Member

@bricebou Salut ! Alors oui, j'ai retéléchargé la dernière version depuis le git, fait des tests et j'ai toujours le même problème que plus haut (Safari) #3 (comment)

Avec la correction que j'avais indiqué ça fonctionne, mais je t'avoue qu'il va falloir la tester. Perso je l'ai mise dans prism-live.spip.css ligne 39, sans trop savoir si c'ets la bonne façon de procéder vis à vis de ton plugin.

Edit : attention, je viens de me rendre compte que ma modif CSS pose d'autres problème ssur Chrome cette fois-ci ! J'essaye de trouver la bonne façon de faire...

@bricebou Salut ! Alors oui, j'ai retéléchargé la dernière version depuis le git, fait des tests et j'ai toujours le même problème que plus haut (Safari) https://git.spip.net/spip-contrib-extensions/prism/issues/3#issuecomment-29337 Avec la correction que j'avais indiqué ça fonctionne, mais je t'avoue qu'il va falloir la tester. Perso je l'ai mise dans prism-live.spip.css ligne 39, sans trop savoir si c'ets la bonne façon de procéder vis à vis de ton plugin. Edit : attention, je viens de me rendre compte que ma modif CSS pose d'autres problème ssur Chrome cette fois-ci ! J'essaye de trouver la bonne façon de faire...
Author
Member

Ca y est, je pense avoir trouvé la bonen façon de procéder, avec le code suivant tout fonctionne sur Safari/Chrome/Firefox.

.prism-live .token.tag,
.prism-live .token.url {
    overflow-wrap: break-word;
}

Je te laisse vérifier de ton côté.

Ca y est, je pense avoir trouvé la bonen façon de procéder, avec le code suivant tout fonctionne sur Safari/Chrome/Firefox. ``` .prism-live .token.tag, .prism-live .token.url { overflow-wrap: break-word; } ``` Je te laisse vérifier de ton côté.
Member

Ne reproduisant pas et n'ayant pas de Safari sous la main, je ne saurais vérifier --"

@marcimat reproduisais-tu le problème éventuellement ? Si oui, le fix proposé par Mathieu résoud-t-il le problème ?

Si oui, je pusherai la modif et ferai un nouveau tag !

Merci par avance :)

Ne reproduisant pas et n'ayant pas de Safari sous la main, je ne saurais vérifier --" @marcimat reproduisais-tu le problème éventuellement ? Si oui, le fix proposé par Mathieu résoud-t-il le problème ? Si oui, je pusherai la modif et ferai un nouveau tag ! Merci par avance :)
Author
Member

Bon je comprends plus rien.
Ce matin ma modif fonctionne vraiment bizarrement dans Safari, j'ai jamais vu ça ! Elle ne semble pas appliquée, si je la ré-applique manuellement dans l'inspecteur ça fonctionen comme prévu... Je me demande si j'ai pas un souci avec ma version de Safari. Donc oui ça demande vérification ailleurs.

Bon je comprends plus rien. Ce matin ma modif fonctionne vraiment bizarrement dans Safari, j'ai jamais vu ça ! Elle ne semble pas appliquée, si je la ré-applique manuellement dans l'inspecteur ça fonctionen comme prévu... Je me demande si j'ai pas un souci avec ma version de Safari. Donc oui ça demande vérification ailleurs.
Member

Du nouveau sur ce ticket ? @MathieuAlphamosa, @marcimat ? Des utilisateurs de Safari?

Du nouveau sur ce ticket ? @MathieuAlphamosa, @marcimat ? Des utilisateurs de Safari?
Author
Member

J'ai toujours les mêmes problèmes, il faut absolument que je prenne un peu de temps (si possible avant la fin de semaine) pour refaire le point sur une installation clean.

J'ai toujours les mêmes problèmes, il faut absolument que je prenne un peu de temps (si possible avant la fin de semaine) pour refaire le point sur une installation clean.
Member

Salut @MathieuAlphamosa !

Alors, finalement, en cherchant un peu, j'ai trouvé pour Debian le navigateur Epiphany qui est basé sur WebKit et en effet je reproduis le problème.

Par contre, ta dernière proposition ne fonctionne pas dans mon cas:

.prism-live .token.tag,
.prism-live .token.url {
    overflow-wrap: break-word;
}

Ta première solution fonctionne parfaitement pourtant:

.prism-live .token.tag,
.prism-live .token.url {
    line-break: anywhere;
}

Mais je me demande pourquoi le limiter aux seuls .token.tag et .token.url ? Pourquoi ne pas l'appliquer à .prism-live afin de répondre au cas extrême de

LIGNEPASOKsqdqsdqsdqsdqsdjhqskjdgjqsgdjhqsgdjhqsghjdgqshjdgqshjdgjhsqgdhsqgjhdgqsjhgdjhqsgdjhqsgdjhgqsjhdgqjhsdgjhsqdgjhghj

Pour le moment j'ai donc modifié la déclaration des sélecteurs .prism-live textarea.prism-live,.prism-live pre.prism-live aux lignes 9-21 ainsi:

.prism-live textarea.prism-live,
.prism-live pre.prism-live
{
    --scrollbar-width: 17px;
    margin: 0;
    padding: 1em !important;
    padding-bottom: var(--scrollbar-width) !important;
    padding-right: var(--scrollbar-width) !important;
    border: 1px solid var(--spip-form-input-border-color);
    border-radius: var(--spip-form-border-radius);
    border-top-left-radius: 0;
    border-top-right-radius: 0;

	overflow-wrap: break-word;
	line-break: anywhere;
}

et ça semble fonctionner.

J'essaie d'éprouver cela dans les prochains jours.
Je pousse dans une nouvelle branche (https://git.spip.net/spip-contrib-extensions/prism/src/branch/dev/issue_3) et te laisse tester de ton côté.

Salut @MathieuAlphamosa ! Alors, finalement, en cherchant un peu, j'ai trouvé pour Debian le navigateur Epiphany qui est basé sur WebKit et en effet je reproduis le problème. Par contre, ta dernière proposition ne fonctionne pas dans mon cas: ```css .prism-live .token.tag, .prism-live .token.url { overflow-wrap: break-word; } ``` Ta première solution fonctionne parfaitement pourtant: ```css .prism-live .token.tag, .prism-live .token.url { line-break: anywhere; } ``` Mais je me demande pourquoi le limiter aux seuls .token.tag et .token.url ? Pourquoi ne pas l'appliquer à `.prism-live` afin de répondre au cas extrême de ```LIGNEPASOKsqdqsdqsdqsdqsdjhqskjdgjqsgdjhqsgdjhqsghjdgqshjdgqshjdgjhsqgdhsqgjhdgqsjhgdjhqsgdjhqsgdjhgqsjhdgqjhsdgjhsqdgjhghj``` Pour le moment j'ai donc modifié la déclaration des sélecteurs `.prism-live textarea.prism-live,.prism-live pre.prism-live` aux lignes 9-21 ainsi: ```css .prism-live textarea.prism-live, .prism-live pre.prism-live { --scrollbar-width: 17px; margin: 0; padding: 1em !important; padding-bottom: var(--scrollbar-width) !important; padding-right: var(--scrollbar-width) !important; border: 1px solid var(--spip-form-input-border-color); border-radius: var(--spip-form-border-radius); border-top-left-radius: 0; border-top-right-radius: 0; overflow-wrap: break-word; line-break: anywhere; } ``` et ça semble fonctionner. J'essaie d'éprouver cela dans les prochains jours. Je pousse dans une nouvelle branche (https://git.spip.net/spip-contrib-extensions/prism/src/branch/dev/issue_3) et te laisse tester de ton côté.
Author
Member

Bonne nouvelle @bricebou, je pense avoir trouvé une solution qui fonctionne partout.

Le line-break: anywhere; coupe tous les mots en bout de ligne, c'est très perturbant. J'ai donc repris tout depuis le début (faut avouer que ces propriétés CSS sont pas ultra évidentes).

J'arrive à un résultat correct dans mes tests, et sur tous mes navigateurs (Safari, Chrome, FF) avec :

.prism-live code.language-md,
.prism-live code.language-markdown,
.prism-live code.language-spip_typo,
pre.prism-live,
textarea.prism-live {
    white-space: pre-wrap!important;
    word-wrap: break-word!important;
}

.prism-live textarea.prism-live,
.prism-live pre.prism-live
{
    --scrollbar-width: 17px;
    margin: 0;
    padding: 1em !important;
    padding-bottom: var(--scrollbar-width) !important;
    padding-right: var(--scrollbar-width) !important;
    border: 1px solid var(--spip-form-input-border-color);
    border-radius: var(--spip-form-border-radius);
    border-top-left-radius: 0;
    border-top-right-radius: 0;
}

On oublie mes propositions de ne travailler que sur les tags et URLs (via .token.tag et .token.url).

Bonne nouvelle @bricebou, je pense avoir trouvé une solution qui fonctionne partout. Le `line-break: anywhere;` coupe tous les mots en bout de ligne, c'est très perturbant. J'ai donc repris tout depuis le début (faut avouer que ces propriétés CSS sont pas ultra évidentes). J'arrive à un résultat correct dans mes tests, et sur tous mes navigateurs (Safari, Chrome, FF) avec : ``` .prism-live code.language-md, .prism-live code.language-markdown, .prism-live code.language-spip_typo, pre.prism-live, textarea.prism-live { white-space: pre-wrap!important; word-wrap: break-word!important; } .prism-live textarea.prism-live, .prism-live pre.prism-live { --scrollbar-width: 17px; margin: 0; padding: 1em !important; padding-bottom: var(--scrollbar-width) !important; padding-right: var(--scrollbar-width) !important; border: 1px solid var(--spip-form-input-border-color); border-radius: var(--spip-form-border-radius); border-top-left-radius: 0; border-top-right-radius: 0; } ``` On oublie mes propositions de ne travailler que sur les tags et URLs (via `.token.tag` et `.token.url`).
Member

Salut @MathieuAlphamosa !

Je dois avouer que je ne suis pas trop sûr de comprendre... le code que tu propose est celui de la branche master si je ne m'abuse : https://git.spip.net/spip-contrib-extensions/prism/src/branch/master/css/prism-live-spip.css

Salut @MathieuAlphamosa ! Je dois avouer que je ne suis pas trop sûr de comprendre... le code que tu propose est celui de la branche master si je ne m'abuse : https://git.spip.net/spip-contrib-extensions/prism/src/branch/master/css/prism-live-spip.css
Author
Member

Ouais mais alors ça c'est parceque je suis une andouille... Je suis reparti de zéro et j'ai pas vérifié les différences par rapport à ta branche master... pour arriver au même résultat. La branche master est donc OK. Désolé.

Ouais mais alors ça c'est parceque je suis une andouille... Je suis reparti de zéro et j'ai pas vérifié les différences par rapport à ta branche master... pour arriver au même résultat. La branche master est donc OK. Désolé.
Member

Non non, pas du tout :) mais t'aurais pas un reste de cache qui traînerait ? Parce que personnellement avec Epiphany (moteur Webkit) je reproduis tout à fait ton problème de lignes longues avec la branche master.

Et par contre, évidemment, j'avais zappé que ce line-break: anywhereétait un poil trop brutal...
Mais personnellement j'arrive vraiment aux limites de mes connaissances de CSS pour régler ce problème.

@tcharlss ou @marcimat peut-être ?

Non non, pas du tout :) mais t'aurais pas un reste de cache qui traînerait ? Parce que personnellement avec Epiphany (moteur Webkit) je reproduis tout à fait ton problème de lignes longues avec la branche master. Et par contre, évidemment, j'avais zappé que ce `line-break: anywhere`était un poil trop brutal... Mais personnellement j'arrive vraiment aux limites de mes connaissances de CSS pour régler ce problème. @tcharlss ou @marcimat peut-être ?
Member

Salut tout le monde !
Ce problème est quand même pas mal em###dant, surtout pour les rédateurs ...
Une solution de contournement (en attendant de trouver mieux) serait d'ajouter dans la barre d'outils un bouton pour activer/désactiver prism live (il faut juste ajouter/retirer la classe prism-live sur le textarea concerné).
Je n'ai pas encore regarder, mais ça ne doit pas étre trop compliqué !!!

Salut tout le monde ! Ce problème est quand même pas mal em###dant, surtout pour les rédateurs ... Une solution de contournement (en attendant de trouver mieux) serait d'ajouter dans la barre d'outils un bouton pour activer/désactiver prism live (il faut juste ajouter/retirer la classe prism-live sur le textarea concerné). Je n'ai pas encore regarder, mais ça ne doit pas étre trop compliqué !!!
Member

Bonsoir à tous !

Alors, en tâtonnant pas mal encore, j'ai testé la combinaison

white-space: break-spaces !important;
overflow-wrap: break-word;

comme vous pouvez le voir au commit suivant : e0791e0483

@MathieuAlphamosa, @marcimat et @Bredt (je m'excuse d'ailleurs de ne pas avoir répondu plus tôt, je suis complètement passé à côté de la notification :-/), vous avez moyen de tester cette évolution sur la branche dev/issue_3 (https://git.spip.net/spip-contrib-extensions/prism/src/branch/dev/issue_3) ?

Merci par avance pour vos retours !

Bonsoir à tous ! Alors, en tâtonnant pas mal encore, j'ai testé la combinaison ```css white-space: break-spaces !important; overflow-wrap: break-word; ``` comme vous pouvez le voir au commit suivant : https://git.spip.net/spip-contrib-extensions/prism/commit/e0791e0483592a5b4ebf5d0d12290d68b0a08d42 @MathieuAlphamosa, @marcimat et @Bredt (je m'excuse d'ailleurs de ne pas avoir répondu plus tôt, je suis complètement passé à côté de la notification :-/), vous avez moyen de tester cette évolution sur la branche dev/issue_3 (https://git.spip.net/spip-contrib-extensions/prism/src/branch/dev/issue_3) ? Merci par avance pour vos retours !
Author
Member

Eh bien écoute, je n'ai plus aucun prioblème sur Safari, aucun décalage ou ligne cassée. Ca marche très bien ! Bravo.

Eh bien écoute, je n'ai plus aucun prioblème sur Safari, aucun décalage ou ligne cassée. Ca marche très bien ! Bravo.
Member

Super ! Merci beaucoup ! Je vais pousser cette modification et un nouveau tag dans la foulée :-)

Super ! Merci beaucoup ! Je vais pousser cette modification et un nouveau tag dans la foulée :-)
Member

Je viens de retester rapidement avec quelques assez gros contenus (SPIP 4.2, PHP 8.2, MacOS Ventura, processeur M1, Firefox 109), et

  1. tout semble bien s’afficher
  2. l’édition semble fluide

Cela dit, c’est sur un ordi assez récent, ça joue peut être.

Quelques notes

Rien à voir avec le ticket ici :

  • Le chargement de la coloration prends du temps (1/2, 1/4 de seconde ?) et ça se voit sur la page, le temps que l’article se décore et change de police. Est-ce qu’il ne faudrait pas du coup par défaut utiliser la même police et taille pour l’édition (avec ou sans coloration), la transition serait du coup moins visible ? Voir #14
  • Lorsqu’un mot inconnu ou erroné est souligné de petits points, ces petits points suivent le scroll avec du retard d’animation, sous-entendu que l’un des blocs remonte plus vite que l’autre ou que son animation est différente au scroll.
  • Je me dis qu’il faudrait un bouton pour désactiver / réactiver la coloration sur la barre d’outil, aucazou.
Je viens de retester rapidement avec quelques assez gros contenus (SPIP 4.2, PHP 8.2, MacOS Ventura, processeur M1, Firefox 109), et 1) tout semble bien s’afficher 2) l’édition semble fluide Cela dit, c’est sur un ordi assez récent, ça joue peut être. ### Quelques notes Rien à voir avec le ticket ici : - Le chargement de la coloration prends du temps (1/2, 1/4 de seconde ?) et ça se voit sur la page, le temps que l’article se décore et change de police. Est-ce qu’il ne faudrait pas du coup par défaut utiliser la même police et taille pour l’édition (avec ou sans coloration), la transition serait du coup moins visible ? Voir #14 - Lorsqu’un mot inconnu ou erroné est souligné de petits points, ces petits points suivent le scroll avec du retard d’animation, sous-entendu que l’un des blocs remonte plus vite que l’autre ou que son animation est différente au scroll. - Je me dis qu’il faudrait un bouton pour désactiver / réactiver la coloration sur la barre d’outil, aucazou.
Member

Bon, sur un des longs articles qui fonctionne sous FF 109, je vois que ça bug sur Chrome 109

Mais pas sur Safari 16.1 qui semble aussi correct.

Tiens d’ailleurs surligner du texte et scroller et un autre moyen de voir le décalage d’animation…

Bon, sur un des longs articles qui fonctionne sous FF 109, je vois que ça bug sur Chrome 109 ![](https://git.spip.net/attachments/b4f214f9-f502-44f7-9e18-6ea017cfeeea) Mais pas sur Safari 16.1 qui semble aussi correct. Tiens d’ailleurs surligner du texte et scroller et un autre moyen de voir le décalage d’animation…
Member

Il y a un mot qui fait planter sur Chrome en fait, c’est "manifestante :" en fin de ligne. D’un côté les : seuls sont à la ligne, de l’autre c’est tout le mot et les : (il n’y a pas d’espace insécable.

Soit Chrome n’aime pas les mannifs, soit pas le féminin… soit plutôt il a un problème avec la gestion des : dans ce cas.

Il y a un mot qui fait planter sur Chrome en fait, c’est "manifestante :" en fin de ligne. D’un côté les `:` seuls sont à la ligne, de l’autre c’est tout le mot et les `:` (il n’y a pas d’espace insécable. Soit Chrome n’aime pas les mannifs, soit pas le féminin… soit plutôt il a un problème avec la gestion des `:` dans ce cas.
Member

J’ai 2 des 3 articles longs qui sont en erreur sur Chrome, et ça semble dans des cas tordus, mais réalistes (urls longues dans des paragraphes). Un autre mot en fin de phrase qui a fait planter est "France."

Qui plus est, quand on cherche une occurrence de mot sous Chrome (j’ai pas regardé les autres encore), il ne scroll qu’un des 2 textareas sur le mot…

C’est beaucoup de soucis pour un navigateur !

J’ai 2 des 3 articles longs qui sont en erreur sur Chrome, et ça semble dans des cas tordus, mais réalistes (urls longues dans des paragraphes). Un autre mot en fin de phrase qui a fait planter est "France." Qui plus est, quand on cherche une occurrence de mot sous Chrome (j’ai pas regardé les autres encore), il ne scroll qu’un des 2 textareas sur le mot… C’est beaucoup de soucis pour un navigateur !
Member

Merci @marcimat pour tous ces tests et retours !

Ton dernier message me fait m'interroger plus encore sur la pertinence de cette solution technique... Je crois vraiment qu'il nous faut trouver une autre solution pour répondre au besoin d'une mise en forme simultanée à l'édition. J'ai regardé un peu plus attentivement CodeMirror et il semble bien que l'on puisse "surcharger" des textarea, mais cela signifie du coup un gros boulot sur le Porte-Plume je suppose puisqu'il faudra capter ses événements et appliquer les traitements à un autre élément que le textarea, à moins que le plus simple soit directement de coder une nouvelle barre d'outils...
Est-ce que l'on n'ouvrirait pas un thread spécifique sur discuter ?

Merci @marcimat pour tous ces tests et retours ! Ton dernier message me fait m'interroger plus encore sur la pertinence de cette solution technique... Je crois vraiment qu'il nous faut trouver une autre solution pour répondre au besoin d'une mise en forme simultanée à l'édition. J'ai regardé un peu plus attentivement CodeMirror et il semble bien que l'on puisse "surcharger" des textarea, mais cela signifie du coup un gros boulot sur le Porte-Plume je suppose puisqu'il faudra capter ses événements et appliquer les traitements à un autre élément que le textarea, à moins que le plus simple soit directement de coder une nouvelle barre d'outils... Est-ce que l'on n'ouvrirait pas un thread spécifique sur discuter ?

@bricebou ya déjà un ticket assez détaillé pour ça : spip/porte_plume#3720

Pas compris ton histoire de textarea, si l'éditeur est codemirror ça se fait selon sa méthode, pas une superposition bancale. Et en CodeMirror le principe des boutons c'est que c'est qu'une interface à des comportements/raccourcis prévus dans l'éditeur, c'est pas les boutons qui prévoient le comportement. Par ex "transformer en liste" c'est un comportement/raccourcis claviers dans l'éditeur à coder, et ensuite si on veut on prévoit un bouton qui appelle ce comportement, ça vient dans ce sens.

Mais faire un parser CodeMirror, c'est TRES compliqué, pas juste 15 regexs à déclarer, c'est un truc énorme. Cf le "lexer" de Markdown (et encore qu'une partie) :
https://github.com/lezer-parser/markdown/blob/main/src/markdown.ts

Alors moi je rêve qu'on ait un lexer pour la syntaxe SPIP ok, mais bon je crois que c'est limite plus rapide d'attendre que SPIP passe entièrement au markdown, que d'attendre qu'on arrive à faire un lexer pour SPIP… Mais tant mieux si quelqu'un y arrive.

@bricebou ya déjà un ticket assez détaillé pour ça : https://git.spip.net/spip/porte_plume/issues/3720 Pas compris ton histoire de textarea, si l'éditeur est codemirror ça se fait selon sa méthode, pas une superposition bancale. Et en CodeMirror le principe des boutons c'est que c'est qu'une interface à des comportements/raccourcis prévus dans l'éditeur, c'est pas les boutons qui prévoient le comportement. Par ex "transformer en liste" c'est un comportement/raccourcis claviers dans l'éditeur à coder, et ensuite si on veut on prévoit un bouton qui appelle ce comportement, ça vient dans ce sens. Mais faire un parser CodeMirror, c'est TRES compliqué, pas juste 15 regexs à déclarer, c'est un truc énorme. Cf le "lexer" de Markdown (et encore qu'une partie) : https://github.com/lezer-parser/markdown/blob/main/src/markdown.ts Alors moi je rêve qu'on ait un lexer pour la syntaxe SPIP ok, mais bon je crois que c'est limite plus rapide d'attendre que SPIP passe entièrement au markdown, que d'attendre qu'on arrive à faire un lexer pour SPIP… Mais tant mieux si quelqu'un y arrive.
Member

Ah oui, ça me rappelle quelque chose !

Pour l'histoire de textarea, je pensais en fait à cela https://codemirror.net/docs/migration/#codemirror.fromtextarea
Et oui, j'avais bien conscience de la difficulté à "modéliser" la syntaxe SPIP en un parser...

Ton commentaire me ramène d'ailleurs à une question récurrente que j'ai lorsque j'installe un nouveau SPIP : qu'est-ce qui est recommandé aujourd'hui ? l'installation du plugin Markdown et le choix de cette syntaxe Markdown par défaut ?

Ah oui, ça me rappelle quelque chose ! Pour l'histoire de textarea, je pensais en fait à cela https://codemirror.net/docs/migration/#codemirror.fromtextarea Et oui, j'avais bien conscience de la difficulté à "modéliser" la syntaxe SPIP en un parser... Ton commentaire me ramène d'ailleurs à une question récurrente que j'ai lorsque j'installe un nouveau SPIP : qu'est-ce qui est recommandé aujourd'hui ? l'installation du plugin Markdown et le choix de cette syntaxe Markdown par défaut ?
Member

@bricebou alors j’ai l’impression que ça fonctionne sous chrome «simplement» en remplaçant le white-space: break-spaces !important par

  • white-space: pre-wrap !important ou
  • white-space: pre-line !important.

J’ai testé sous Macos FF109, Chrome109, Safari 16.1 et Opéra 94.0

Donc, je ne comprends pas pourquoi cette ligne a été modifiée récemment du coup.

@bricebou alors j’ai l’impression que ça fonctionne sous chrome «simplement» en remplaçant le `white-space: break-spaces !important` par - `white-space: pre-wrap !important` ou - `white-space: pre-line !important`. J’ai testé sous Macos FF109, Chrome109, Safari 16.1 et Opéra 94.0 Donc, je ne comprends pas pourquoi cette ligne a été modifiée récemment du coup.
Member

Pour le point 2 sur l’effet de l’animation du scroll, ça se corrige avec scroll-behavior: auto; ou scroll-behavior: unset; sur le textarea.

Pour le point 2 sur l’effet de l’animation du scroll, ça se corrige avec `scroll-behavior: auto;` ou `scroll-behavior: unset;` sur le textarea.
Member

Hum... Je me suis peut-être planté dans mon merge... Mais avec cette modification, je n'avais plus les problèmes rencontrés par @MathieuAlphamosa. Et là, ce matin, impossible de reproduire le problème initial...

Peut-être suffisait-il de supprimer les lignes 22-23 de css/prism-live-spip.css sur le sélecteur .prism-live textarea.prism-live, .prism-live pre.prism-live (cf. e0791e0483) ?

Du coup, @MathieuAlphamosa, avec ce que propose @marcimat en #3 (comment), ça donne quoi chez toi ?

Hum... Je me suis peut-être planté dans mon merge... Mais avec cette modification, je n'avais plus les problèmes rencontrés par @MathieuAlphamosa. Et là, ce matin, impossible de reproduire le problème initial... Peut-être suffisait-il de supprimer les lignes 22-23 de css/prism-live-spip.css sur le sélecteur `.prism-live textarea.prism-live, .prism-live pre.prism-live` (cf. https://git.spip.net/spip-contrib-extensions/prism/commit/e0791e0483592a5b4ebf5d0d12290d68b0a08d42) ? Du coup, @MathieuAlphamosa, avec ce que propose @marcimat en https://git.spip.net/spip-contrib-extensions/prism/issues/3#issuecomment-46081, ça donne quoi chez toi ?
Author
Member

En fait j'ai déjà ça dans prism-live-spip.css (ce que je comprends pas trop vu que j'étais avec la version 1.1.4...) :

.prism-live code.language-md,
.prism-live code.language-markdown,
.prism-live code.language-spip_typo,
pre.prism-live,
textarea.prism-live {
  white-space: pre-wrap !important;
  overflow-wrap: break-word;
}

Et donc oui ça fonctionne sur Safari.

J'ai testé à nouveau avec la 1.1.5, ça fonctionne également sur Safari.

En fait j'ai **déjà** ça dans `prism-live-spip.css` (ce que je comprends pas trop vu que j'étais avec la version 1.1.4...) : ``` .prism-live code.language-md, .prism-live code.language-markdown, .prism-live code.language-spip_typo, pre.prism-live, textarea.prism-live { white-space: pre-wrap !important; overflow-wrap: break-word; } ``` Et donc oui ça fonctionne sur Safari. J'ai testé à nouveau avec la 1.1.5, ça fonctionne également sur Safari.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: spip-contrib-extensions/prism#3
No description provided.