Wordgard: Rich-Text-Editor für den Browser vom ProseMirror-Entwickler

 (wordgard.net)
1 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Wordgard ist eine Open-Source-JavaScript-Bibliothek zum Erstellen von Rich-Text-Editoren im Browser und basiert auf einer neuen Editor-Grundlage des ProseMirror-Entwicklers
  • Der Fokus liegt stärker auf Kontrolle über die Dokumentstruktur als auf frei formulierbarer HTML-Bearbeitung; Entwickler können präzise festlegen, welche Arten von Inhalten und welche semantischen Strukturen erlaubt sind
  • Für komplexe maßgeschneiderte Editoren bietet Wordgard ein schema-basiertes Modell und eine erweiterungsorientierte Struktur, sodass Funktionen je nach Bedarf ausgetauscht oder angepasst werden können
  • Anforderungen wie Barrierefreiheit, Internationalisierung, RTL- und bidirektionale Dokumente, strukturierte Inhalte, funktionaler Stil und kollaboratives Bearbeiten werden auf Ebene der Editor-Grundlage adressiert
  • Wordgard ist permissive Open Source unter der MIT-Lizenz, verfolgt aber ein Betriebsmodell, bei dem Bug-Reports willkommen sind und Pull Requests nicht angenommen werden

Editor-Grundlage zur Kontrolle der Dokumentstruktur

  • Wordgard ist eine Open-Source-JavaScript-Bibliothek zur Implementierung von Rich-Text-Editoren im Browser
  • Es ist kein frei formulierbarer HTML-Editor, sondern ein semantisches Rich-Text-Editor-System, mit dem Entwickler die Arten unterstützter Inhalte und die Dokumentstruktur genau steuern können
  • Wordgard bietet einen schema-basierten Ansatz, um Dokumentstrukturen präzise zu definieren und eigene Dokumentelemente zu erstellen
  • Die Programmierschnittstelle ist auf Allgemeingültigkeit und Flexibilität ausgelegt und kann als Grundlage für maßgeschneiderte Editoren mit hohen Anforderungen dienen

Erweiterbarkeit, Barrierefreiheit und Kollaboration

  • Die meisten Editor-Funktionen sind als Erweiterungen (Extensions) implementiert und können ersetzt oder angepasst werden, wenn sie nicht zu den Anforderungen passen
  • Barrierefreiheitsfunktionen berücksichtigen Nutzer von Screenreadern, Nutzer, die ausschließlich die Tastatur verwenden, sowie Umgebungen auf Mobilgeräten; auch UI-Internationalisierung wird unterstützt
  • Für von rechts nach links geschriebene Umgebungen wird Richtungserkennung sowohl für Inhalte als auch für die Oberfläche unterstützt, sodass bidirektionale Inhalte und RTL-Dokumente verarbeitet werden können
  • Der Dokumentbaum kann strukturierte Inhalte wie Tabellen, verschachtelte Listen, Figures mit Beschriftungen und eigene Strukturen enthalten
  • Große Teile des Systems sind aus Gründen der Klarheit und Testbarkeit in funktionalem Stil geschrieben
  • Wordgard unterstützt kollaboratives Bearbeiten, bei dem mehrere Nutzer dasselbe Dokument gleichzeitig bearbeiten und parallele Änderungen zusammengeführt werden

Lizenz und Projektbetrieb

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 시간 전
Meinungen auf Hacker News

  • Die meisten dürften wissen wollen: „Warum?“ Dieses Dokument kam einer Antwort darauf am nächsten, weil es die Unterschiede zu ProseMirror behandelt: https://wordgard.net/docs/prosemirror/
    Ein bemerkenswerter Punkt ist, dass es keinen Upgrade-Pfad gibt. Es teilt viele Konzepte mit ProseMirror, aber ein Umstieg scheint einiges an Arbeit zu erfordern. Obsidian basiert auf CodeMirror und wird daher vermutlich nicht wechseln, aber etwas wie tiptap.dev könnte betroffen sein.
    @merijn, ich würde gern wissen, ob du erklären kannst, warum Wordgard den Umstiegsaufwand wert ist.
    Edit: Ich habe gesehen, dass viele der Punkte in Marijns persönlichem Blog behandelt werden, und habe für besseren Kontext https://marijnhaverbeke.nl/blog/wordgard-0.1.html bei HN eingereicht.

    • Bei „Ist Wordgard den Umstiegsaufwand wert?“ könnte die Antwort auch nein sein. Wenn man mit ProseMirror zufrieden ist, kann man ProseMirror weiterverwenden, und ich werde es weiter unterstützen.
      Wie im Blogpost beschrieben, haben sich aber einige neue Design-Einsichten angesammelt, mit denen sich bestimmte Probleme vermeiden lassen, auf die ich bei ProseMirror gestoßen bin. Deshalb wollte ich eine neue Iteration bauen.
      Ich werde im Dokumentationsbereich der Website einen Link zum Blogpost hinzufügen.
      Und der Name ist marijn, nicht merijn.
    • Im Blog steht: „Ich mag das ProseMirror-Wortspiel inzwischen auch nicht mehr besonders. Es bedeutet CodeMirror, aber für Prosa, klar?“ Also ist jetzt wohl jemand dran, Codegard zu bauen.
    • „Warum ist es den Umstiegsaufwand wert?“ ist die wirklich interessante Frage. Noch wichtiger: Warum wurde daraus nicht einfach ProseMirror v2?
      Die Landingpage scheint mehr Informationen zum „Warum“ zu brauchen, nicht nur zum „Was“.

  • Unabhängig vom Editor ist die beauftragte Künstlerin wirklich beeindruckend. Sehr elegant und sofort ins Auge fallend: https://kamilastankiewicz.com/

    • Sehe ich genauso. Wirklich wunderschön, und ich frage mich, was es ungefähr kosten würde, solche Illustrationen in eine bestehende Website einzubauen.
    • Die Grafiken sind erstaunlich gut und haben auch etwas von Ghibli. Schon lustig, so etwas im Kontext eines Rich-Text-Editors zu sagen.

  • Vor etwa 25 Jahren war es eine große Hürde, für die Schülerzeitung eine WYSIWYG-Editor-Komponente auf einer PHP-Nuke-Site zum Laufen zu bringen, und ich erinnere mich, dass wir es am Ende geschafft haben.
    Es ist absurd, dass es für so eine Funktionalität keinen Webstandard gibt, dessen Implementierung schon vor 15 Jahren abgeschlossen war.

    • Es gibt contenteditable, und Dinge wie Wordgard oder ProseMirror sind im Kern ebenfalls darauf aufgebaut. Der Rest ist eher Benutzeroberfläche und Interoperabilität mit Systemen, die keine beliebige HTML-Eingabe wollen.
    • Lange Zeit konnten sich Browseranbieter nicht einmal auf die Details des Verhaltens bei einfacher Textauswahl einigen.

  • Das sieht erstaunlich gut aus.
    Ich habe kürzlich nach etwas Ähnlichem gesucht und es am Ende selbst gebaut: blockbasierte Operational Transformation (OT) mit Synchronisierung zu einem lokalen Server und differenzbasierter Synchronisierung zu einem Remote-Server.
    Beim Lesen des Systemleitfadens nicke ich ständig. Die Ähnlichkeiten und Unterschiede zu sehen, fühlt sich ziemlich bestätigend an.

    • ProseMirror, und vermutlich auch Wordgard, macht wirklich sehr vieles richtig.

  • Es gibt einen ganz grundlegenden Bereich, in dem alle Editoren gescheitert sind: Kann man auf dem iPhone innerhalb des Editors einen vollständigen Satz eingeben?
    Wordgard besteht diesen Test nicht. Eingaben aus Autokorrektur oder Tastaturvorschlägen werden verschluckt, und teilweise eingegebene oder falsch geschriebene Wörter werden gelöscht.

    • ProseMirror sollte das gut hinbekommen, ebenso Lexical, das in einem Geschwisterkommentar erwähnt wurde.
      Mobile Safari und Android Chrome verhalten sich im Gegensatz zu ihren Desktop-Geschwistern in sehr vielen Dingen merkwürdig und legen Standards ziemlich locker aus. Damit es richtig funktioniert, braucht man deshalb oft einen langen Rattenschwanz an Workaround-Code.
      Wordgard wird sicher auch irgendwann dort ankommen, aber der Fokus vor dem ersten Release lag auf der Architektur.
    • Vor ein paar Jahren habe ich webbasierte Rich-Text-Editoren evaluiert. Auf dem Desktop sahen alle in Ordnung aus, aber auf Mobilgeräten war alles, was ich ausprobiert habe, ein Chaos.
      Auswahl funktionierte nicht, Autokorrektur ging kaputt, Tippen auf Text bewegte den Cursor nicht, Eingaben blieben hängen, und die Tastatur verschwand nicht, wenn das Element den Fokus verlor.
      In den letzten Jahrzehnten gab es mehrere Versuche, dem Web ein brauchbares Rich-Text-Element hinzuzufügen, aber ich weiß nicht, warum sie alle gescheitert sind. Vermutlich, weil es eine große, komplexe und wenig dankbare Aufgabe ist.
      Vernünftige native Rich-Text-Unterstützung ist einer der großen blinden Flecken des Webs. Native Plattformen haben dieses Problem schon vor Jahrzehnten gelöst.

  • Vor etwa sechs Jahren habe ich mich sehr damit abgequält, Autovervollständigung für entfernte Ressourcen im @-Stil zu untersuchen und zu implementieren, also Funktionen zum Verweisen auf andere Benutzer oder Dokumente. Die Erweiterungsweise dieses Editors wirkt wie eine Weiterentwicklung von ProseMirror.
    Es wäre wirklich schön, wenn das eine eingebaute Standardfunktion wäre und man es nicht selbst anhand des Dinosaurier-Beispiels bauen müsste. Jedes Mal, wenn ich eine solche Texteditor-Bibliothek verwende, ist das mein wichtigster Anwendungsfall, danach kommt WYSIWYG.

    • Wenn @-Mention-Stil standardmäßig vorhanden wäre und nur eine API bereitgestellt würde, wäre das großartig.
      Mobile-Unterstützung erster Klasse braucht es genauso.

  • Was mir bei ProseMirror über TipTap schwergefallen ist: Sehr oft muss man die JSON-Repräsentation eines Dokuments programmatisch bearbeiten, um Daten zu extrahieren. Dafür braucht man eine statisch typisierte Darstellung oder bevorzugt sie zumindest stark.
    ProseMirror hat dafür eigentlich nichts vorgesehen, sodass wir am Ende eines von zwei Dingen getan haben:

    1. Das Schema zweimal definieren: einmal in ProseMirror und einmal mit etwas wie Zod, plus eine Menge Gleichheitstests, um sicherzustellen, dass beide Schemas übereinstimmen.
    2. Eine Meta-Schema-Definitionsschicht bauen, die ein ProseMirror-Schema ausgeben kann, aber der Standard-Schema-Spezifikation https://standardschema.dev/ folgt. Dieser Ansatz ist praktischer, wenn man so etwas wie Tiptap nicht verwendet.
      Ich habe Wordgard noch nicht ausprobiert und weiß daher nicht, ob es dieses Problem behandelt, aber ich wollte diesen Schmerzpunkt erwähnen, weil es gut wäre, ihn zu lösen.

  • Das Artwork der Website ist wunderschön. Diese Art, Aufmerksamkeit zu erzeugen, fühlt sich fast wie etwas an, das in Vergessenheit geraten ist.

    • Es enthält auch „0 % KI“. Diese Künstlerin ist wirklich großartig.
    • Bei all dem KI-Müll überall ist es wirklich erfrischend, schöne handgezeichnete Illustrationen zu sehen.

  • Ich mag WYSIWYG im Web nicht. Man formatiert einen Forumsbeitrag lang und mühsam, schließt den Tab, und alles ist weg.
    Ich bevorzuge es, einen lokalen Texteditor zu verwenden und dann mit Ctrl+V in das Webformular einzufügen. Mit Markdown geht das.

    • Ich habe gesehen, dass einige Plattformen dieses Problem mit localStorage lösen. Während der Eingabe wird automatisch ein „Entwurf“ gespeichert, und wenn man die Seite erneut öffnet, wird er nahtlos wiederhergestellt.
      Als ich das zum ersten Mal erlebt habe, nachdem ich versehentlich einen Tab geschlossen hatte, war das eine wirklich angenehme Überraschung.
    • Schau dir Linear an. Ich bin nicht beteiligt, aber erst gestern habe ich versehentlich einen Dialog geschlossen, und als ich erneut auf Issue erstellen geklickt habe, war mein langer Text noch da.
      Der Punkt ist: Das ist kein technisches Problem, sondern ein Produktproblem.
    • Kommt darauf an. Mein Blog hat einen webbasierten Editor, aber im Grunde ist es einfach Markdown mit Vorschau, also ähnlich wie der von dir beschriebene Workflow.
      Für meine Notizen-App habe ich mich für WYSIWYG entschieden, weil es keinen Platz für eine geteilte Ansicht gibt und ich auch nicht nur Markdown-Rohtext sehen wollte.
      Mein größter Kritikpunkt an WYSIWYG ist, dass es im Weg stehen kann. Zum Beispiel erstellt man einen verbatim-Block und kommt dann nicht mehr aus diesem Block heraus. Ich schaue dich an, Teams. Vielleicht war das auch der Grund, warum ich LaTeX so mochte.
    • Für ProseMirror und andere Editoren gibt es bereits gute Backends. Sie sind nicht schwer einzurichten.
    • Zustimmung, aber viele Leute bevorzugen WYSIWYG. Ganz einfach kann man wie bei vielen HTML- oder Markdown-Editoren eine Nebeneinander-Ansicht anbieten.

  • Ich freue mich wirklich, nach langer Zeit wieder echte Kunst zu sehen. Sieht gut aus.