Wordgard: editor de rich text para navegador do criador do ProseMirror

 (wordgard.net)
1 pontos por GN⁺ 5 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Wordgard é uma biblioteca JavaScript open source para criar editores de rich text no navegador, uma nova base de editor feita pelo criador do ProseMirror
  • Em vez de ser um editor HTML de formato livre, foca no controle da estrutura do documento, permitindo que desenvolvedores definam com precisão os tipos de conteúdo permitidos e sua estrutura semântica
  • Voltado a editores personalizados complexos, oferece um modelo baseado em schemas e uma arquitetura centrada em extensões, permitindo substituir ou modificar funcionalidades conforme a necessidade
  • Trata, na própria base do editor, requisitos como acessibilidade, internacionalização, documentos RTL e bidirecionais, conteúdo estruturado, estilo funcional e edição colaborativa
  • É open source permissivo sob licença MIT, mas adota um modelo de operação em que relatos de bugs são bem-vindos e Pull requests não são aceitos

Uma base de editor que controla a estrutura do documento

  • Wordgard é uma biblioteca JavaScript open source para implementar editores de rich text no navegador
  • Não é um editor HTML de formato livre, mas sim um sistema de edição de rich text semântico que permite ao desenvolvedor controlar exatamente os tipos de conteúdo suportados e a estrutura do documento
  • Oferece uma abordagem baseada em schemas para definir a estrutura do documento com precisão e criar elementos de documento personalizados
  • A interface de programação foi projetada com foco em generalidade e flexibilidade, podendo servir como base para editores personalizados com requisitos amplos

Extensibilidade, acessibilidade e colaboração

  • A maior parte das funcionalidades do editor é implementada como extensões (extensions), podendo ser substituída ou modificada quando não se adequar às necessidades
  • Os recursos de acessibilidade consideram usuários de leitores de tela, usuários que usam apenas teclado e ambientes de dispositivos móveis, além de oferecer suporte à internacionalização da UI
  • Para ambientes escritos da direita para a esquerda, oferece suporte a consciência de direção tanto no conteúdo quanto na interface, permitindo lidar com conteúdo bidirecional e documentos RTL
  • A árvore do documento pode incluir conteúdo estruturado, como tabelas, listas aninhadas, figures com legendas e estruturas personalizadas
  • Grandes partes do sistema são escritas em estilo funcional para favorecer clareza e testabilidade
  • Oferece suporte a edição colaborativa, permitindo que vários usuários editem o mesmo documento simultaneamente e que alterações concorrentes sejam mescladas

Licença e operação do projeto

Leituras relacionadas

1 comentários

 
GN⁺ 5 시간 전
Opiniões no Hacker News

  • Acho que a maioria vai querer saber “por quê?”. Este documento trata das diferenças em relação ao ProseMirror, então foi a resposta mais próxima para essa pergunta: https://wordgard.net/docs/prosemirror/
    Um ponto a observar é que não há caminho de upgrade. Ele compartilha muitos conceitos com o ProseMirror, mas a migração parece exigir bastante trabalho. O Obsidian é baseado no CodeMirror, então acho que não vai mudar, mas lugares como tiptap.dev podem ser afetados
    @merijn, fico curioso para saber se você poderia explicar por que o Wordgard vale o custo de migração
    Edit: vi que muitos pontos foram abordados no blog pessoal do Marijn e enviei https://marijnhaverbeke.nl/blog/wordgard-0.1.html para o HN para dar um contexto melhor

    • Sobre “o Wordgard vale o custo de migração?”, talvez não. Se você está satisfeito com o ProseMirror, pode continuar usando o ProseMirror, e eu vou continuar dando suporte a ele
      Mas, como expliquei no post do blog, acumulei várias novas percepções de design que permitem evitar alguns problemas que encontrei no ProseMirror, e por isso fiquei com vontade de criar uma nova iteração
      Vou adicionar um link para o post do blog na seção de documentação do site
      E o nome é marijn, não merijn
    • Como no blog está escrito “hoje em dia nem gosto muito do trocadilho ProseMirror. É CodeMirror, só que para prosa, entendeu?”, parece que agora é a vez de alguém criar o Codegard
    • “Por que vale o custo de migração?” é a pergunta que realmente quero ver respondida. Mais importante ainda, também fico curioso por que isso não virou simplesmente o ProseMirror v2
      A landing page parece precisar de mais informação sobre o “porquê” do que sobre o “o quê”

  • Separado do editor, o artista responsável pelo design é realmente impressionante. É muito refinado e chamou muito a atenção: https://kamilastankiewicz.com/

    • Penso o mesmo. É realmente lindo, e fico curioso quanto custaria colocar esse tipo de ilustração em um site existente
    • Os gráficos são surpreendentemente bons e têm uma vibe Ghibli também. É curioso dizer isso no contexto de um editor de rich text

  • Lembro que, cerca de 25 anos atrás, fazer um editor WYSIWYG funcionar para colocar no ar um site PHP-Nuke do jornal da escola era um grande obstáculo, mas acabamos superando
    Não faz sentido que não exista uma implementação de padrão web para esse recurso que já estivesse resolvida há 15 anos

    • Existe contenteditable, e coisas como Wordgard ou ProseMirror são, no fundo, construídas em cima dele. O resto se aproxima mais de interface de usuário e de interoperabilidade com sistemas que não querem receber HTML arbitrário
    • Durante muito tempo, os fornecedores de navegadores nem sequer conseguiam concordar sobre detalhes do comportamento de uma simples seleção de texto

  • Isto parece surpreendentemente excelente
    Recentemente procurei algo parecido e acabei criando o meu próprio, com transformação operacional (OT) baseada em blocos sincronizando com um servidor local e sincronização baseada em diffs para o servidor remoto
    Enquanto leio o guia do sistema, fico assentindo o tempo todo. Ver as semelhanças e os contrastes dá uma sensação de validação bem forte

    • O ProseMirror, e provavelmente o Wordgard também, acerta muita coisa

  • Há uma área muito básica em que todos os editores falharam: conseguir digitar uma frase completa dentro do editor em um iPhone
    O Wordgard não passou nesse teste. Entradas vindas da correção automática ou das sugestões do teclado são engolidas, e palavras parcialmente digitadas ou com erro de ortografia são apagadas

    • O ProseMirror, e também o Lexical mencionado em um comentário irmão, deve conseguir lidar bem com isso
      O Safari móvel e o Chrome no Android fazem muitas coisas estranhas, diferentemente de seus equivalentes desktop, e também tratam os padrões de forma bastante frouxa. Por isso, para fazer funcionar direito, muitas vezes é preciso uma longa cauda de código de contorno
      O Wordgard também vai chegar lá, mas o foco até o primeiro lançamento foi a arquitetura
    • Alguns anos atrás, avaliei editores de rich text baseados na web. No desktop todos pareciam OK, mas no mobile tudo que tentei era um desastre
      Não dava para selecionar, a correção automática quebrava, tocar no texto não movia o cursor, a entrada travava, e o teclado não desaparecia quando o elemento perdia o foco
      Nas últimas décadas houve várias tentativas de adicionar um elemento de rich text adequado à web, mas não sei por que todas falharam. Imagino que seja uma tarefa grande, complexa e sem muita recompensa
      Suporte nativo adequado a rich text é uma das grandes lacunas da web. Plataformas nativas resolveram esse problema décadas atrás

  • Há cerca de 6 anos sofri bastante pesquisando e implementando autocomplete de recursos remotos no estilo @, isto é, recursos para referenciar outros usuários ou documentos. O modo de extensão deste editor parece uma evolução do ProseMirror
    Seria ótimo se isso fosse um recurso nativo básico, em vez de algo que você precisa construir por conta própria a partir do exemplo dos dinossauros. Toda vez que uso uma biblioteca de editor de texto desse tipo, esse é o caso de uso número 1, e WYSIWYG vem depois

    • Se menções no estilo @ viessem prontas e apenas expusessem uma API, seria excelente
      Suporte mobile de primeira classe também é necessário

  • Uma dificuldade que tive ao usar ProseMirror via TipTap foi que muitas vezes é preciso manipular programaticamente a representação JSON do documento para extrair dados. Para isso, você precisa, ou pelo menos passa a preferir muito, uma representação com tipos estáticos
    O ProseMirror não tem exatamente um mecanismo para isso, então acabei fazendo uma de duas coisas

    1. Definir o schema duas vezes: uma no ProseMirror e outra em algo como Zod, com um monte de testes de equivalência para verificar se os dois schemas coincidiam
    2. Criar uma camada de definição de meta-schema capaz de gerar um schema do ProseMirror, mas seguindo a especificação Standard Schema https://standardschema.dev/. Essa abordagem é mais prática quando você não usa algo como Tiptap
      Ainda não usei o Wordgard, então não sei se ele aborda esse problema, mas deixo registrado como um ponto de dor que seria bom resolver

  • A arte do site é linda. Parece que esse modo de chamar atenção havia sido meio esquecido

    • Também é “0% IA”. Esse artista é muito bom
    • Em meio a tanto lixo de IA por toda parte, é realmente refrescante ver ilustrações bonitas desenhadas à mão

  • Não gosto de WYSIWYG na web. Você passa um tempão formatando um post de fórum, fecha a aba e tudo desaparece
    Prefiro usar um editor de texto local e colar no formulário web com Ctrl+V. Com Markdown, dá para fazer isso

    • Já vi algumas plataformas resolverem isso com localStorage. Elas salvam automaticamente um “rascunho” enquanto você digita e restauram naturalmente quando você reabre a página
      Quando passei por isso pela primeira vez depois de fechar uma aba sem querer, foi uma surpresa muito agradável
    • Dê uma olhada no Linear. Não tenho ligação com eles, mas ontem mesmo fechei uma caixa de diálogo por engano e, quando cliquei de novo para criar uma issue, o texto longo que eu tinha escrito ainda estava lá
      O ponto é que isso não é um problema técnico, é um problema de produto
    • Depende do caso. No meu blog há um editor baseado na web, mas ele simplesmente usa Markdown com uma prévia, então é parecido com o fluxo que você descreveu
      No app de notas decidi usar WYSIWYG, porque não há espaço para uma visualização dividida e eu também não queria ver apenas o Markdown bruto
      Minha maior reclamação sobre WYSIWYG é que ele pode atrapalhar. Por exemplo, às vezes você cria um bloco verbatim e não consegue sair dele. Estou olhando para você, Teams. Talvez seja por isso que eu gostava tanto de LaTeX
    • Já existem bons backends para ProseMirror e outros editores. Não é difícil configurar
    • Concordo, mas muita gente prefere WYSIWYG. De forma simples, basta ter uma visualização lado a lado, como vários editores HTML ou Markdown

  • Fico muito feliz de ver arte de verdade depois de tanto tempo. É bonito