Produits Entr'ouvert » Publik

J'ai commencé à tester 2 3 trucs.

execCommand¶

Cette spec nous vient d'un truc dev par Windows pour IE 5.5 et implémenté ensuite différemment par chaque navigateur. Elle est incomplète, bancale et finalement officiellement devenue obsolète pour être un jour remplacée par https://w3c.github.io/input-events/

https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c
La liste des commands et quelques différences expliquées entre browser : https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand

On a pas vraiment le choix, il va falloir faire avec cette spec dans un premier temps. Les navigateurs "récents" sont à priori un peu plus unifiés entre eux. Mais faire pour IE11, je vois pas comment rester compatible.
Ensuite, garder à l'esprit qu'on va bricoler des trucs. Et qu'il faudra réécrire tout ça dans quelques années.

Coller depuis LibreOffice¶

Le test qui fait peur. Et en effet ça na pas loupé, coller du contenu depuis LibreOffice dans un [contentEditable] ramène du markup ingérable.
J'ai décidé de supprimer toute mise en forme et de ne coller que la version plain text du Press Papier.

      // Paste only plain text
      this.editor_content.addEventListener("paste", function(e) {
          e.preventDefault();
          // get text representation of clipboard
          var text = (e.originalEvent || e).clipboardData.getData('text');
          // insert text manually
          document.execCommand("insertText", false, text);
      });

Différences remarquées entre Chrome et FF :

Lors d'un execCommand "bold", "italic", "underline" sur une selection "text", FF va généré `<u><i><b>text</b></i></u>` : il 'wrap' avec la nouvelle commande. chrome va généré l'inverse `<b><i><u>text</u></i></b>`

Si le cursor est dans un paragraphe (block créé par défaut avec un retour chariot) et que l'invoque execCommand "insertUnorderedList" pour créer une liste à puce, firefox va remplacer le <p> par <ul><li></li></ul>, alors que Chrome va l'insérer à l'intérieur du <p> (pas cool du tout)

Toujours les listes
Lors d'une suppression d'une liste, chrome remplace les items de liste par des `<span style="font-size: 16px;"> … <br>` (merci pour le style inline). FF laisse un texte sans tag avec un <br> à la fin.

ProseMirror me parait un bon choix de framework.
https://prosemirror.net

Il y a derrière une demande pour un regard technique, voir si ça peut être packagé et exploité ?

https://packages.debian.org/search?keywords=prosemirror liste une série de paquets, mais ça ne sont pas les dernières versions, et il n'y a pas un module comme prosemirror-view qui apparait essentiel, mais peut-être que ça n'était pas le cas à l'époque, mais peut-être que ça n'est pas packagé parce que c'est une galère et pareil pour les nouvelles versions.

_~~

Sinon je ne sais pas ce que je peux dire d'autre que dire que sûr ça peut être essayé; il y a une vidéo dans la description du ticket avec quelque chose qui peut peut-être servir de modèle pour une démonstration d'utilisation effective, ou quelque chose d'autre. (par exemple déjà dégager la barre d'outils qui fait vieux cul).

Il y a derrière une demande pour un regard technique, voir si ça peut être packagé et exploité ?

1. maintenu
2. utilisé sur des gros projets open source
3. bien documenté

https://www.tiptap.dev/ est basé sur ce framework.

Mais je n'ai pas été plus loin (pas encore testé), d'autres avis et regards techniques comme le packaging sont bienvenues, surtout si c'est un aspect éliminatoire.

Premiers tests de proseMirror cette semaine.
L'API est assez mastoc et pas très simple à prendre en main.
Mais l'outil me semble bien construit.

Toute l'UI est à faire.

Et il est contraignant dans le sens où tout block autorisé au sein de l'éditeur doit être déclaré ainsi que ses enfants. Tout autre markup non déclaré est supprimé au parsing. Ce qui me semble très bien mais cela va compliqué la migration du code accepté de CKeditor vers notre nouvel editeur.

Je prévois un poc pour le camp.
Le code sera distribué sous forme de modules ES. Je vais pousser le code sur misc-tjund pour le moment.

avant de cleaner le code, faut choisr un petit nom.

Toutes les idées sont bienvenues. Premières propositions :

• Phylly (nom donné par Fred à son poc)
• Fraso (nom donné à mon POC)

Godo

Test ici https://perso.entrouvert.org/~tjund/godo/

404.

404

retry

(perso pareil peut-être trop tôt pour ces retours, ou il faudra définir une méthode, tu peux juste dire que tu continues à travailler le style).

• le gras/italique translucide ça me perturbe vraiment, ça fait un truc moche qui se déplace et sur lequel un clic ne donne rien, assez étrange. (oui je comprends l'intention "indicateur", mais je trouve que ça ne marche pas).
• en mode basique à autoriser uniquement des paragraphes la "barre d'outils" pourrait totalement ne pas être là.
• je comprends que le textarea est conservé visible pour debug ça sera bien sûr à éliminer.

Sur les dépendances,

"prosemirror-history": "^1.2.0",

pas dispo

"prosemirror-keymap": "^1.1.4",

pas dispo

"prosemirror-model": "^1.15.0",

dispo dans cette version mais bullseye-backports.

"prosemirror-schema-basic": "^1.1.2",

dispo dans cette version mais bullseye.

"prosemirror-state": "^1.3.4",

dispo dans cette version mais bullseye-backports.

"prosemirror-view": "^1.20.1"

pas dispo.

+ "devDependencies",

"@rollup/plugin-buble": "^0.21.3",

ok dispo dans cette version, bullseye ou buster-backports

"@rollup/plugin-node-resolve": "^13.0.6",

pas dispo dans cette version, 11.0.1 dans buster-backports

"rollup": "^2.26.3"

dispo en 2.38.4 dans buster.

Pour le packaging, à titre d'exemple, il pourrait y avoir https://sources.debian.org/src/node-prosemirror-markdown/1.6.0-1/debian/

Frédéric Péters a écrit :

• le gras/italique translucide ça me perturbe vraiment, ça fait un truc moche qui se déplace et sur lequel un clic ne donne rien, assez étrange.

Pareil, testé, c’est chouette mais j’ai pas tout de suite compris que c’était des actions qui étaient utilisables uniquement lorsque du texte est sélectionné. (Aussi, sans doute c’est parce que je suis conditionné par les traitements de texte bureautique où ces actions sont utilisables même lorsque du texte n’est pas sélectionné, et dans ce cas là c’est le texte qui va être écrit à cet endroit précis qui prend cette mise en forme. Peut-être que pour godo il y a moyen de retirer complètement ces deux icônes gras/italique lorsqu’aucun texte n’est sélectionné ?)

qui montre un "G" et "I" parasites

C'est bien un bug qu'il faudra régler dans une configuration mutil-editeur dans une même page (si on garde ce menu fantôme)

le gras/italique translucide ça me perturbe vraiment
en mode basique à autoriser uniquement des paragraphes la "barre d'outils" pourrait totalement ne pas être là.

J'y ai pensé, à il y a alors cet aspect UI à régler :
Si pas de nav "blocks" ni nav "inline" apparente par défaut (parce que uniquement visible lors d'une selection de texte), quel indicateur donné aux usagers qu'ils ont la possibilité de formater leur texte ?

les traitements de texte bureautique où ces actions sont utilisables même lorsque du texte n’est pas sélectionné

Ils fonctionnent sans sélection, mais la vue n'est pas mise à jour (création de balises strong ou em) tant qu'un caractère n'est pas saisi, je n'ai donc pas réussi à retourner un feedback pour informer que l'action est prise en compte.

Packaging releasé, mail envoyé sur trav@ :

J'ai fini le packaging godo via deux dépôts :
* https://git.entrouvert.org/godo.js.git qui contient le code source
de base et produit un paquet libjs-godo
* https://git.entrouvert.org/debian/xstatic-godo.git qui intègre tout
ça à la machinerie XStatic qu'on utilise habituellement.

Le paquet godo.js.git est intégré à jenkins classiquement, le paquet
xstatic-godo par contre il faut l'exécuter via le jobs "debs" mais il
ne nécessite pas d'être mis à jour à chaque fois car il ne contient
rien qui dépende du dépôt godo.

Au niveau utilisation il suffit de s'inspirer de l'exemple donné par
tjund[1] et remplacer les URLs par "{% xstatic 'godo'
'godo{[.min].js,.css}' %}".

Paquets disponibles en buster et bullseye, eobuilder et testing[2]

[1]: https://git.entrouvert.org/godo.js.git/tree/dist/index.html
[2]: https://deb.entrouvert.org/packages.html#libjs-godo
https://deb.entrouvert.org/packages.html#python3-xstatic-godo