- Wordgard est une bibliothèque JavaScript open source pour créer des éditeurs de texte enrichi dans le navigateur, fondée sur une nouvelle base d’éditeur conçue par le créateur de ProseMirror
- Plutôt qu’un éditeur HTML libre, elle met l’accent sur le contrôle de la structure du document, permettant aux développeurs de définir précisément les types de contenu autorisés et leur structure sémantique
- Pensée pour des éditeurs personnalisés complexes, elle propose un modèle fondé sur des schémas et une architecture centrée sur les extensions, avec la possibilité de remplacer ou modifier les fonctionnalités selon les besoins
- La base de l’éditeur prend en charge des exigences comme l’accessibilité, l’internationalisation, le RTL et les documents bidirectionnels, le contenu structuré, un style fonctionnel et l’édition collaborative
- Logiciel open source permissif sous licence MIT, le projet accepte volontiers les rapports de bugs mais n’accepte pas les pull requests
Une base d’éditeur qui contrôle la structure des documents
- Wordgard est une bibliothèque JavaScript open source permettant d’implémenter des éditeurs de texte enrichi dans le navigateur
- Ce n’est pas un éditeur HTML libre, mais un système d’édition de texte enrichi sémantique dans lequel les développeurs contrôlent précisément les types de contenu pris en charge et la structure du document
- Elle adopte une approche fondée sur des schémas afin de définir finement la structure des documents et de créer des éléments de document personnalisés
- L’interface de programmation a été conçue avec un objectif de généralité et de flexibilité, afin de pouvoir servir de base à des éditeurs personnalisés aux exigences élevées
Extensibilité, accessibilité et collaboration
- La plupart des fonctionnalités de l’éditeur sont implémentées sous forme d’extensions ; si elles ne conviennent pas, elles peuvent être remplacées ou modifiées
- Les fonctions d’accessibilité prennent en compte les utilisateurs de lecteurs d’écran, ceux qui n’utilisent que le clavier et les environnements mobiles, tout en prenant aussi en charge l’internationalisation de l’interface
- Pour les environnements s’écrivant de droite à gauche, le système prend en charge la gestion de direction à la fois dans le contenu et l’interface, et peut traiter du contenu bidirectionnel ainsi que des documents RTL
- L’arborescence du document peut inclure du contenu structuré comme des tableaux, des listes imbriquées, des
figureavec légende et des structures personnalisées - Une grande partie du système est écrite dans un style fonctionnel afin de favoriser la clarté et la testabilité
- Le système prend en charge l’édition collaborative, permettant à plusieurs utilisateurs de modifier le même document simultanément et de fusionner leurs modifications concurrentes
Licence et fonctionnement du projet
- La licence est MIT, et le développement se fait sur code.haverbeke.berlin
- Les rapports de bugs sont bienvenus, mais les pull requests ne sont pas acceptées
- Pour les discussions et questions sur le projet, il est recommandé d’utiliser le forum ; les bugs doivent être signalés dans l’issue tracker
1 commentaires
Avis sur Hacker News
Je pense que la plupart des gens voudront savoir « pourquoi ? ». Ce document traite des différences avec ProseMirror, et c’est ce qui se rapproche le plus d’une réponse à cette question : https://wordgard.net/docs/prosemirror/
Un point à noter : il n’y a pas de chemin de migration. Il partage beaucoup de concepts avec ProseMirror, mais passer de l’un à l’autre semble demander pas mal de travail. Obsidian étant basé sur CodeMirror, il ne changera probablement pas, mais des projets comme tiptap.dev pourraient être concernés
@merijn, je serais curieux de savoir si tu peux expliquer en quoi Wordgard vaut le coût de migration
Édition : j’ai vu que beaucoup de ces points étaient abordés sur le blog personnel de Marijn, et j’ai soumis https://marijnhaverbeke.nl/blog/wordgard-0.1.html sur HN pour donner davantage de contexte
Cela dit, comme je l’explique dans le billet de blog, j’ai accumulé pas mal de nouvelles idées de conception permettant d’éviter certains problèmes rencontrés avec ProseMirror, ce qui m’a donné envie d’en faire une nouvelle itération
J’ajouterai un lien vers le billet de blog dans la section documentation du site
Et le prénom est marijn, pas merijn
La landing page aurait besoin de plus d’informations sur le « pourquoi » que sur le « quoi »
Indépendamment de l’éditeur, l’artiste qui a réalisé le design est vraiment impressionnante. C’est très soigné et ça saute aux yeux : https://kamilastankiewicz.com/
Il y a environ 25 ans, faire tourner un éditeur WYSIWYG pour mettre en ligne un site PHP-Nuke destiné au journal de mon école était un gros obstacle, que j’avais fini par surmonter
C’est absurde qu’il n’existe pas d’implémentation de standard web, déjà validé il y a 15 ans, pour ce genre de fonctionnalité
contenteditable, et Wordgard ou ProseMirror sont fondamentalement construits par-dessus. Le reste relève plutôt de l’interface utilisateur et de l’interopérabilité avec des systèmes qui ne veulent pas accepter du HTML arbitraire en entréeÇa a l’air étonnamment excellent
J’ai récemment cherché quelque chose de similaire et j’ai fini par le faire moi-même, avec une transformation opérationnelle (OT) par blocs synchronisée vers un serveur local, puis une synchronisation différentielle vers un serveur distant
En lisant le guide du système, je n’arrête pas d’acquiescer. Voir les similitudes et les contrastes donne une vraie impression de validation
Il y a un domaine très basique où tous les éditeurs ont échoué : peut-on saisir une phrase complète dans l’éditeur depuis un iPhone ?
Wordgard ne réussit pas ce test. Les entrées provenant de la correction automatique ou des suggestions du clavier sont avalées, et les mots partiellement saisis ou mal orthographiés sont supprimés
Safari mobile et Chrome sur Android ont énormément de comportements étranges par rapport à leurs homologues desktop, et interprètent les standards de manière assez souple. Il faut donc souvent une longue traîne de contournements pour que tout fonctionne correctement
Wordgard y arrivera aussi, mais avant la première version, l’accent était mis sur l’architecture
Impossible de sélectionner correctement, correction automatique cassée, le curseur ne bougeait pas quand on appuyait sur le texte, la saisie se bloquait, le clavier ne disparaissait pas quand l’élément perdait le focus, etc.
Il y a eu plusieurs tentatives, ces dernières décennies, pour ajouter au web un vrai élément de texte riche, mais je ne sais pas pourquoi elles ont toutes échoué. Probablement parce que c’est un chantier énorme, complexe et peu gratifiant
La prise en charge native correcte du texte riche est l’un des grands angles morts du web. Les plateformes natives ont résolu ce problème il y a des décennies
Il y a environ 6 ans, j’ai beaucoup galéré à étudier et implémenter l’autocomplétion de ressources distantes de style @, c’est-à-dire la possibilité de référencer d’autres utilisateurs ou documents. Le mécanisme d’extension de cet éditeur ressemble à une évolution de ProseMirror
Ce serait vraiment bien que ce soit une fonctionnalité intégrée par défaut, plutôt que quelque chose à construire soi-même à partir de l’exemple du dinosaure. Chaque fois que j’utilise une bibliothèque d’éditeur de texte de ce type, c’est mon cas d’usage numéro un, suivi du WYSIWYG
Une prise en charge mobile de premier ordre est tout aussi nécessaire
Ce qui m’a posé problème en utilisant ProseMirror via TipTap, c’est que l’on doit très souvent manipuler programmatiquement la représentation JSON du document pour en extraire des données. Pour cela, on a besoin — ou du moins on finit par fortement préférer — une représentation avec typage statique
ProseMirror n’a pas vraiment de dispositif prévu pour ça, donc on finit par faire l’une des deux choses suivantes
Je n’ai pas encore essayé Wordgard, donc je ne sais pas s’il traite ce problème, mais je le signale comme un point de friction qu’il serait utile de résoudre
Les illustrations du site sont magnifiques. On dirait presque qu’on avait oublié cette manière d’attirer l’attention
Je n’aime pas le WYSIWYG sur le web. On passe du temps à mettre en forme un long message de forum ennuyeux, puis on ferme l’onglet et tout disparaît
Je préfère utiliser un éditeur de texte local puis coller avec Ctrl+V dans le formulaire web. Avec Markdown, on peut faire ça
localStorage. Elles enregistrent automatiquement un « brouillon » pendant la saisie, puis le restaurent naturellement quand on rouvre la pageLa première fois que ça m’est arrivé après avoir fermé un onglet par erreur, ça a été une très agréable surprise
Le point essentiel, c’est que ce n’est pas un problème technique, mais un problème produit
Pour mon application de notes, j’ai choisi le WYSIWYG parce qu’il n’y a pas assez de place pour une vue scindée et que je ne voulais pas non plus ne voir que le Markdown brut
Mon principal reproche au WYSIWYG est qu’il peut se mettre en travers du chemin. Par exemple, on crée un bloc verbatim et on se retrouve parfois incapable d’en sortir. Je pense à Teams en disant ça. C’est peut-être pour ça que j’aimais autant LaTeX
Ça fait vraiment plaisir de voir de nouveau du véritable art après si longtemps. C’est beau