1 points par GN⁺ 5 시간 전 | 1 commentaires | Partager sur WhatsApp
  • 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 figure avec 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

1 commentaires

 
GN⁺ 5 시간 전
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

    • Quant à savoir si « Wordgard vaut le coût de migration », peut-être pas. Si vous êtes satisfait de ProseMirror, continuez à utiliser ProseMirror ; je continuerai à le maintenir
      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
    • Le blog dit : « Je n’aime plus vraiment non plus le jeu de mots ProseMirror. C’est CodeMirror, mais pour la prose, vous voyez ? » ; il semble donc que ce soit maintenant au tour de quelqu’un de créer Codegard
    • La vraie question intéressante est : « pourquoi cela vaudrait-il le coût de migration ? ». Plus important encore, pourquoi ne pas en avoir simplement fait ProseMirror v2 ?
      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/

    • Même avis. C’est vraiment magnifique, et je me demande combien coûterait l’ajout de telles illustrations à un site existant
    • Les graphismes sont étonnamment bons, avec aussi une ambiance Ghibli. C’est étrange de se retrouver à dire ça dans le contexte d’un éditeur de texte riche
  • 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é

    • Il y a 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
    • Pendant longtemps, les éditeurs de navigateurs n’arrivaient même pas à se mettre d’accord sur les détails du comportement d’une simple sélection de texte
  • Ç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

    • ProseMirror — et sans doute Wordgard aussi — fait vraiment beaucoup de choses correctement
  • 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

    • ProseMirror, et Lexical mentionné dans un commentaire frère, devraient pouvoir gérer cela correctement
      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
    • Il y a quelques années, j’avais évalué des éditeurs de texte riche web. Sur desktop, tout avait l’air correct, mais sur mobile, tout ce que j’ai essayé était catastrophique
      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

    • Si les mentions de style @ étaient fournies par défaut, avec simplement une API, ce serait excellent
      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

    1. Définir le schéma deux fois : une fois avec ProseMirror, une fois avec quelque chose comme Zod, puis ajouter tout un tas de tests d’équivalence pour vérifier que les deux schémas correspondent
    2. Créer une couche de définition de méta-schéma capable de produire un schéma ProseMirror, tout en respectant la spécification Standard Schema https://standardschema.dev/ ; cette approche est plus pratique lorsqu’on n’utilise pas quelque chose comme Tiptap
      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

    • Et c’est aussi « 0 % IA ». Cette artiste est vraiment géniale
    • Voir de belles illustrations dessinées à la main est vraiment rafraîchissant, alors qu’il y a partout des déchets d’IA
  • 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

    • J’ai vu certaines plateformes résoudre ce problème avec localStorage. Elles enregistrent automatiquement un « brouillon » pendant la saisie, puis le restaurent naturellement quand on rouvre la page
      La 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
    • Regardez Linear. Je n’ai aucun lien avec eux, mais pas plus tard qu’hier, j’ai fermé par erreur une boîte de dialogue ; quand j’ai recliqué pour créer une issue, le long texte que j’avais écrit était toujours là
      Le point essentiel, c’est que ce n’est pas un problème technique, mais un problème produit
    • Ça dépend. Mon blog a un éditeur web, mais il utilise simplement Markdown avec un aperçu, donc c’est proche du flux de travail décrit
      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
    • Il existe déjà de bons backends pour ProseMirror et d’autres éditeurs. Ce n’est pas difficile à configurer
    • D’accord, mais beaucoup de gens préfèrent le WYSIWYG. La solution simple est d’avoir une vue côte à côte, comme dans de nombreux éditeurs HTML ou Markdown
  • Ça fait vraiment plaisir de voir de nouveau du véritable art après si longtemps. C’est beau