Wordgard: ProseMirror作者によるブラウザー向けリッチテキストエディター

 (wordgard.net)
1 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • Wordgardは、ブラウザーでリッチテキストエディターを作るためのオープンソースJavaScriptライブラリで、ProseMirror作者が手がけた新しいエディター基盤
  • 自由形式のHTMLエディターよりも文書構造の制御に重点を置き、開発者が許可するコンテンツの種類や意味構造を精密に定義できる
  • 複雑なカスタムエディターを対象に、スキーマベースのモデルと拡張中心の構造を提供し、必要に応じて機能を差し替えたり修正したりできる
  • アクセシビリティ、国際化、RTL・双方向文書、構造化コンテンツ、関数型スタイル、共同編集といった要件をエディター基盤で扱う
  • MITライセンスの寛容なオープンソースだが、バグ報告は歓迎しつつPull requestは受け付けない運営方針を採っている

文書構造を制御するエディター基盤

  • Wordgardは、ブラウザー内でリッチテキストエディターを実装するためのオープンソースJavaScriptライブラリ
  • 自由形式のHTMLエディターではなく、開発者がサポートするコンテンツの種類と文書構造を正確に制御するセマンティックなリッチテキストエディターシステム
  • 文書構造を精密に定義し、カスタム文書要素を作れるようにするスキーマベースのアプローチを提供
  • プログラミングインターフェースは汎用性と柔軟性を目指して設計されており、要件の大きいカスタムエディターの基盤として使える

拡張性、アクセシビリティ、共同編集機能

  • ほとんどのエディター機能は拡張(extension) として実装されており、要件に合わなければ差し替えたり修正したりできる
  • アクセシビリティ機能はスクリーンリーダー利用者、キーボードのみを使う利用者、モバイル端末環境を考慮し、UIの国際化にも対応する
  • 右から左へ書く環境のために、コンテンツとインターフェースの両方で方向認識をサポートし、双方向コンテンツとRTL文書を扱える
  • 文書ツリーには、テーブル、入れ子リスト、キャプション付きのfigure、カスタム構造といった構造化コンテンツを含められる
  • システムの大部分は、明確さとテストしやすさのために関数型スタイルで書かれている
  • 複数のユーザーが同じ文書を同時に編集し、同時編集内容を統合する共同編集をサポートする

ライセンスとプロジェクト運営

関連記事

1件のコメント

 
GN⁺ 5 시간 전
Hacker Newsのコメント

  • 多くの人は「なぜ？」を知りたがると思う。この記事はProseMirrorとの違いを扱っていて、その問いへの最も近い答えだった: https://wordgard.net/docs/prosemirror/
    ひとつ注目すべき点は、アップグレードパスがないこと。ProseMirrorと共有する概念は多いが、移行にはかなりの作業が必要そうだ。ObsidianはCodeMirrorベースなので変えない気がするが、tiptap.devのようなところには影響があるかもしれない
    @marijn、Wordgardが移行コストを払うだけの価値がある理由を説明してもらえるだろうか
    編集: Marijnの個人ブログで多くの論点が扱われているのを見つけたので、より良い文脈のために https://marijnhaverbeke.nl/blog/wordgard-0.1.html をHNに投稿した

    • 「Wordgardが移行コストを払うだけの価値があるのか？」については、そうではないかもしれない。ProseMirrorに満足しているなら、そのままProseMirrorを使い続ければいいし、私も引き続きサポートするつもりだ
      ただ、ブログ記事で説明したように、ProseMirrorでぶつかったいくつかの問題を避けられる新しい設計上の洞察がかなり蓄積していて、それで新しい反復版を作りたくなった
      ウェブサイトのドキュメント欄にブログ記事へのリンクを追加しておく
      それと、名前はmerijnではなくmarijnだ
    • ブログに「もうProseMirrorというダジャレもあまり気に入っていない。CodeMirrorだけど散文向け、という意味ね」とあるので、今度は誰かがCodegardを作る番のようだ
    • 「移行コストを払う価値がなぜあるのか？」が本当に知りたい質問だ。さらに重要なのは、なぜ単にProseMirror v2として作らなかったのかという点でもある
      ランディングページには、「何を」よりも「なぜ」に関する情報がもっと必要に見える

  • エディタとは別に、デザインを担当したアーティストが本当に印象的だ。とても洗練されていて、強く目を引かれた: https://kamilastankiewicz.com/

    • 同感。本当に美しいし、こうしたイラストを既存のウェブサイトに入れるにはどれくらい費用がかかるのか気になる
    • グラフィックが驚くほど良くて、ジブリっぽさもある。リッチテキストエディタの文脈でこんなことを言うのが不思議なくらいだ

  • 約25年前、学校新聞のPHP-Nukeサイトを立ち上げるためにWYSIWYGエディタを動かすのが大きな難関で、最終的には乗り越えたことを思い出す
    この種の機能について、15年前にはすでに通っていてよかったはずのウェブ標準実装がないのはおかしい

    • contenteditable があり、WordgardやProseMirrorのようなものも結局はその上に作られている。あとは主にユーザーインターフェースと、任意のHTML入力を望まないシステムとの相互運用性の問題に近い
    • 長いことブラウザベンダーは、単純なテキスト選択動作の細部ですら合意できなかった

  • これは驚くほど素晴らしく見える
    最近似たようなものを探していたが、結局自分で作った。ブロックベースの**運用変換（OT）**でローカルサーバーに同期し、リモートサーバーには差分ベースの同期をつけた
    システムガイドを読みながらずっとうなずいている。似ている点と対照的な点を見ると、かなり検証された気分になる

    • ProseMirrorは、おそらくWordgardも同様に、正しく対処できている部分が本当に多い

  • すべてのエディタが失敗してきたごく基本的な領域がひとつある。iPhoneでエディタ内に完全な文章を入力できるかどうかだ
    Wordgardはこのテストに通らなかった。自動修正やキーボード候補から入る入力が飲み込まれ、部分的に入力した単語やスペルミスのある単語が削除される

    • ProseMirrorは、兄弟コメントで挙げられていたLexicalもそうだが、この点はうまく扱えるはずだ
      モバイルSafariとAndroid Chromeは、デスクトップ版の兄弟ブラウザと違って本当に変な挙動が多く、標準の扱いもかなり緩い。そのため、きちんと動かすには長い裾野の回避コードが必要になることが多い
      Wordgardもいずれそこに到達するだろうが、最初のリリースまでの焦点はアーキテクチャだった
    • 数年前にウェブベースのリッチテキストエディタを検討したことがある。デスクトップではどれもまともに見えたが、モバイルでは試したものすべてがひどかった
      選択できない、自動修正が壊れる、テキストをタップしてもカーソルが移動しない、入力が止まる、要素がフォーカスを失ってもキーボードが消えない、といった具合だった
      この数十年、ウェブにまともなリッチテキスト要素を追加しようという試みは何度もあったが、なぜどれも失敗したのかは分からない。大きくて複雑で、報われない仕事だからだろう
      まともなネイティブリッチテキスト対応は、ウェブの大きな空白地帯のひとつだ。ネイティブプラットフォームでは数十年前に解決済みの問題だ

  • 約6年前、@スタイルのリモートリソース自動補完、つまり他のユーザーや文書を参照する機能を調査して実装するのに非常に苦労した。このエディタの拡張方法はProseMirrorの進化形のように見える
    これを恐竜のサンプルをもとに自作しなければならないのではなく、標準内蔵機能として提供してほしい。こうしたテキストエディタライブラリを使うたび、これが最優先のユースケースで、その次がWYSIWYGだ

    • @メンションスタイルが標準で提供され、APIだけが公開されるなら素晴らしい
      一級のモバイル対応も同様に必要だ

  • ProseMirrorをTipTap経由で使っていてつらかった点は、文書のJSON表現をプログラム的に扱ってデータを抽出しなければならない場面がとても多いことだ。そのためには静的型付きの表現が必要になるか、少なくとも強く欲しくなる
    ProseMirrorにはそのための仕組みが特にないので、結局次のどちらかをやることになった

    1. スキーマを二重に定義する。1回はProseMirrorで、もう1回はZodのようなもので定義し、2つのスキーマが一致するかを確認する同値性テストを大量に置く
    2. ProseMirrorスキーマを出力できるメタスキーマ定義レイヤーを作る。ただし、標準スキーマ仕様 https://standardschema.dev/ に従う。このアプローチはTiptapのようなものを使わないときのほうが実用的だ
      Wordgardはまだ使っていないので、この問題を扱っているかは分からないが、解決されるとうれしい痛点として挙げておく

  • ウェブサイトのアートワークが美しい。こういう形で関心を引くやり方は、いつの間にか忘れられていたように感じる

    • 「AI 0%使用」でもある。このアーティストは本当にすごい
    • あちこちAIゴミだらけの状況で、手描きの美しいイラストを見ると本当に清々しい

  • ウェブ上のWYSIWYGは好きではない。フォーラム投稿を長々と退屈に書式設定して、タブを閉じたら全部消える
    ローカルのテキストエディタを使って、ウェブフォームにはCtrl+Vで貼り付けるほうが好きだ。Markdownならそれができる

    • いくつかのプラットフォームでは、localStorage でこの問題を解決しているのを見た。入力中に「下書き」を自動保存し、ページを開き直すと自然に復元する
      誤ってタブを閉じたあと、初めてこれを体験したときは本当にうれしい驚きだった
    • Linearを見てみるといい。関係者ではないが、ちょうど昨日うっかりダイアログを閉じてしまい、もう一度Issue作成を押したら自分の長文がそのまま残っていた
      要点は、これは技術の問題ではなくプロダクトの問題だということだ
    • 場合による。自分のブログにはウェブベースのエディタがあるが、単にMarkdownにプレビューをつけた形なので、あなたの説明したワークフローに近い
      ノートアプリではWYSIWYGを使うことにした。分割表示を置くスペースがなく、Markdownの生テキストを見たいわけでもなかったからだ
      WYSIWYGへの最大の不満は、邪魔になることがある点だ。たとえばverbatimブロックを作ったのに、そのブロックから抜け出せなくなることがある。Teamsのことを言っている。だからLaTeXがあれほど好きだったのかもしれない
    • ProseMirrorや他のエディタ向けには、優れたバックエンドがすでにある。設定もそれほど難しくない
    • 同意するが、多くの人はWYSIWYGを好む。単純に、多くのHTMLエディタやMarkdownエディタのように並べて表示すればいい

  • 久しぶりに本物のアートを見られて本当にうれしい。見ていて気持ちがいい