Wordgard: ProseMirror 제작자의 브라우저용 리치 텍스트 편집기

 (wordgard.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Wordgard는 브라우저에서 리치 텍스트 편집기를 만들기 위한 오픈소스 JavaScript 라이브러리로, ProseMirror 제작자가 만든 새 편집기 기반임
  • 자유 형식 HTML 편집기보다 문서 구조 통제에 초점을 두며, 개발자가 허용할 콘텐츠 종류와 의미 구조를 정밀하게 정할 수 있음
  • 복잡한 맞춤형 편집기를 겨냥해 스키마 기반 모델과 확장 중심 구조를 제공하고, 필요에 맞게 기능을 교체하거나 수정할 수 있음
  • 접근성, 국제화, RTL·양방향 문서, 구조화 콘텐츠, 함수형 스타일, 협업 편집 같은 요구사항을 편집기 기반에서 다룸
  • MIT 라이선스의 허용적 오픈소스지만, 버그 리포트는 환영하고 Pull request는 받지 않는 운영 방식을 택함

문서 구조를 통제하는 편집기 기반

  • Wordgard는 브라우저 내 리치 텍스트 편집기를 구현하는 오픈소스 JavaScript 라이브러리임
  • 자유 형식 HTML 편집기가 아니라, 개발자가 지원할 콘텐츠의 종류와 문서 구조를 정확히 제어하는 시맨틱 리치 텍스트 편집기 시스템임
  • 문서 구조를 정밀하게 정의하고 커스텀 문서 요소를 만들 수 있도록 스키마 기반 접근을 제공함
  • 프로그래밍 인터페이스는 범용성과 유연성을 목표로 설계되어, 요구사항이 큰 맞춤형 편집기의 기반으로 쓰일 수 있음

확장성, 접근성, 협업 기능

  • 대부분의 편집기 기능은 확장(extension) 으로 구현되어, 필요에 맞지 않으면 교체하거나 수정할 수 있음
  • 접근성 기능은 스크린 리더 사용자, 키보드만 쓰는 사용자, 모바일 기기 환경을 고려하며 UI 국제화도 지원함
  • 오른쪽에서 왼쪽으로 쓰는 환경을 위해 콘텐츠와 인터페이스 모두에서 방향 인식을 지원하고, 양방향 콘텐츠와 RTL 문서를 다룰 수 있음
  • 문서 트리는 테이블, 중첩 리스트, 캡션이 있는 figure, 커스텀 구조 같은 구조화 콘텐츠를 포함할 수 있음
  • 시스템의 큰 부분은 명확성과 테스트 가능성을 위해 함수형 스타일로 작성됨
  • 여러 사용자가 같은 문서를 동시에 편집하고 동시 편집 내용을 병합하는 협업 편집을 지원함

라이선스와 프로젝트 운영

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 대부분은 “왜?”를 알고 싶어 할 것 같음. 이 문서가 ProseMirror와의 차이를 다루고 있어서 그 질문에 가장 가까운 답이었음: https://wordgard.net/docs/prosemirror/
    한 가지 주목할 점은 업그레이드 경로가 없다는 것임. ProseMirror와 공유하는 개념은 많지만, 전환하려면 꽤 많은 작업이 필요해 보임. Obsidian은 CodeMirror 기반이라 바꾸지 않을 것 같지만, tiptap.dev 같은 곳은 영향이 있을 수 있음
    @merijn, 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/

    • 같은 생각임. 정말 아름답고, 기존 웹사이트에 이런 일러스트를 넣으려면 비용이 어느 정도일지 궁금함
    • 그래픽이 놀라울 정도로 좋고 Ghibli 느낌도 남. 리치 텍스트 에디터 맥락에서 이런 말을 하게 되는 게 신기함

  • 약 25년 전 학교 신문에 PHP-Nuke 사이트를 띄우기 위해 위지윅 에디터를 돌리는 게 큰 난관이었고, 결국 넘어섰던 기억이 있음
    이런 기능에 대해 15년 전에 이미 통과된 웹 표준 구현이 없다는 게 말이 안 됨

    • contenteditable이 있고, Wordgard나 ProseMirror 같은 것들도 근본적으로는 그 위에 만들어짐. 나머지는 사용자 인터페이스와, 임의의 HTML 입력을 원하지 않는 시스템과의 상호운용성에 가까움
    • 오랫동안 브라우저 벤더들은 단순한 텍스트 선택 동작의 세부사항조차 합의하지 못했음

  • 이건 놀라울 정도로 훌륭해 보임
    최근 비슷한 걸 찾다가 결국 직접 만들었는데, 블록 기반 운영 변환(OT) 으로 로컬 서버에 동기화하고 원격 서버에는 차이 기반 동기화를 붙였음
    시스템 가이드를 읽으면서 계속 고개를 끄덕이고 있음. 비슷한 점과 대비되는 점을 보니 꽤 검증받는 느낌임

    • ProseMirror는, 아마 Wordgard도 마찬가지로, 맞게 처리한 부분이 정말 많음

  • 모든 에디터가 실패했던 아주 기본적인 영역이 하나 있음. iPhone으로 에디터 안에서 완전한 문장을 입력할 수 있느냐는 것임
    Wordgard는 이 테스트를 통과하지 못했음. 자동 수정이나 키보드 추천에서 들어오는 입력이 삼켜지고, 부분적으로 입력했거나 철자가 틀린 단어가 삭제됨

    • ProseMirror는, 형제 댓글에서 말한 Lexical도 그렇고, 이 부분을 잘 처리할 수 있어야 함
      모바일 Safari와 Android Chrome은 데스크톱 형제 브라우저와 달리 이상한 동작을 정말 많이 하고, 표준도 꽤 느슨하게 다룸. 그래서 제대로 동작하게 만들려면 긴 꼬리의 우회 코드가 필요해지는 경우가 많음
      Wordgard도 결국 도달하겠지만, 첫 릴리스 전까지의 초점은 아키텍처였음
    • 몇 년 전에 웹 기반 리치 텍스트 에디터를 검토했었음. 데스크톱에서는 다 괜찮아 보였지만, 모바일에서는 시도한 것마다 엉망이었음
      선택이 안 되고, 자동 수정이 깨지고, 텍스트를 눌러도 커서가 이동하지 않고, 입력이 멈추고, 요소가 포커스를 잃어도 키보드가 사라지지 않는 식이었음
      지난 수십 년 동안 웹에 제대로 된 리치 텍스트 요소를 추가하려는 시도는 여러 번 있었지만 왜 다 실패했는지는 모르겠음. 크고 복잡하고 보상 없는 작업이라 그런 듯함
      제대로 된 네이티브 리치 텍스트 지원은 웹의 큰 사각지대 중 하나임. 네이티브 플랫폼들은 수십 년 전에 해결한 문제임

  • 약 6년 전 @ 스타일의 원격 리소스 자동완성, 즉 다른 사용자나 문서를 참조하는 기능을 조사하고 구현하느라 매우 고생했음. 이 에디터의 확장 방식은 ProseMirror의 진화형처럼 보임
    이게 공룡 예제를 바탕으로 직접 만들어야 하는 게 아니라 기본 내장 기능이면 정말 좋겠음. 이런 텍스트 에디터 라이브러리를 쓸 때마다 1순위 사용 사례가 이것이고, 그다음이 위지윅임

    • @ 멘션 스타일이 기본 제공되고 API만 제공되면 훌륭할 것임
      일급 모바일 지원도 마찬가지로 필요함

  • ProseMirror를 TipTap으로 쓰면서 힘들었던 점은, 문서의 JSON 표현을 프로그램적으로 다뤄서 데이터를 추출해야 하는 경우가 아주 많다는 것임. 그러려면 정적 타입이 붙은 표현이 필요하거나, 적어도 강하게 선호하게 됨
    ProseMirror에는 이를 위한 장치가 딱히 없어서 결국 둘 중 하나를 하게 됐음

    1. 스키마를 두 번 정의함. 한 번은 ProseMirror로, 한 번은 Zod 같은 것으로 정의하고, 두 스키마가 일치하는지 확인하는 동등성 테스트를 잔뜩 둠
    2. ProseMirror 스키마를 출력할 수 있는 메타 스키마 정의 계층을 만들되, 표준 스키마 명세 https://standardschema.dev/를 따르게 함. 이 접근은 Tiptap 같은 것을 쓰지 않을 때 더 실용적임
      Wordgard는 아직 써보지 않아서 이 문제를 다루는지 모르겠지만, 해결되면 좋을 고통 지점이라 짚어둠

  • 웹사이트의 아트워크가 아름다움. 관심을 끄는 이런 방식이 새삼 잊혀졌던 것처럼 느껴짐

    • “AI 0% 포함”이기도 함. 이 아티스트는 정말 멋짐
    • 여기저기 AI 쓰레기가 넘치는 상황에서 손으로 그린 아름다운 일러스트를 보니 정말 상쾌함

  • 웹에서 위지윅을 좋아하지 않음. 포럼 글을 길고 지루하게 서식 잡아놓고 탭을 닫으면 전부 사라짐
    로컬 텍스트 에디터를 쓰고 웹 폼에 Ctrl+V로 붙여넣는 쪽을 선호함. Markdown이면 그렇게 할 수 있음

    • 어떤 플랫폼들은 localStorage로 이 문제를 해결하는 걸 봤음. 입력하는 동안 “초안”을 자동 저장하고, 페이지를 다시 열면 자연스럽게 복원함
      실수로 탭을 닫은 뒤 처음 이걸 겪었을 때 정말 기분 좋은 놀라움이었음
    • Linear를 확인해 보길. 관계자는 아니지만, 바로 어제 실수로 대화상자를 닫았고 다시 이슈 생성을 눌렀더니 내가 쓴 긴 글이 그대로 있었음
      요점은 이게 기술 문제가 아니라 제품 문제라는 것임
    • 경우에 따라 다름. 내 블로그에는 웹 기반 에디터가 있지만, 그냥 Markdown을 쓰고 미리보기를 붙인 형태라서 설명한 작업 흐름과 비슷함
      노트 앱에는 위지윅을 쓰기로 했는데, 분할 보기를 둘 공간이 없고 Markdown 원문만 보고 싶지도 않았기 때문임
      위지윅에 대한 가장 큰 불만은 방해가 될 수 있다는 점임. 예를 들어 verbatim 블록을 만들었는데 그 블록에서 빠져나올 수 없을 때가 있음. Teams를 보고 하는 말임. 그래서 LaTeX를 그렇게 좋아했던 것 같기도 함
    • ProseMirror와 다른 에디터용으로 좋은 백엔드들이 이미 있음. 설정하기 어렵지 않음
    • 동의하지만 많은 사람은 위지윅을 선호함. 단순하게는 여러 HTML 에디터나 Markdown 에디터처럼 나란히 보기를 두면 됨

  • 오랜만에 진짜 아트를 보게 되어 정말 기쁨. 보기 좋음

답변달기