68. Editor de texto rico — toolbar mínima

O que é, e o que explicitamente NÃO é. Este §68 é o editor de CAMPO: a descrição de uma ordem de serviço, a observação de um laudo, o corpo de um comentário. Toolbar mínima, marcas fechadas, registro tipográfico de interface.

Ele não é o editor de DOCUMENTO (arquétipo A13), e essa fronteira não é preferência — ela está medida. O dispositivo C25 do estudo-clickup-completo.md registra, no editor de documento do produto de referência: coluna de 660px, texto 16px / line-height 24px (=1,5) e uma stack de fonte diferente da do resto do aplicativo. Interface quer 14px/1,15 e densidade; leitura corrida quer 16px/1,5 e medida de linha controlada — usar o mesmo registro nos dois piora os dois. Um componente só para os dois casos não serviria bem a nenhum. A13 continua AUSENTE do mapa de cobertura, e é assim que fica dito.

68.0 Rodada zero — leitura visual MEDIDA, e ela decidiu a fronteira#

Veredito: MEDIDO — e é o caso raro em que a leitura visual entrou na spec decidindo o que fica de fora. Os dispositivos lidos: C25 (registro tipográfico próprio da coluna de leitura), C101 (o documento abre como overlay com ×, não como rota), C103 (rail de ferramentas vertical flutuante à direita), C105 (toolbar flutuante de bloco, que aparece ao passar o mouse), C106 (callout como bloco tingido).

Todos os cinco pertencem ao editor de DOCUMENTO. Nenhum deles é do editor de campo — e é por isso que eles aparecem aqui como fronteira, não como contrato: importar a toolbar flutuante de bloco (C105) para um campo de descrição de OS traria um controle que só aparece com o mouse por cima, sobre um campo de três linhas. Leitura visual bem lida também serve para dizer o que não se copia.

68.1 RITO — três rodadas encadeadas#

68.2 A decisão estruturante: o conjunto de marcas é FECHADO em seis#

Negrito · itálico · lista com marcadores · lista numerada · link · limpar formatação.

O motivo não é estético, é de custo em quatro lugares. O valor deste campo não fica na tela: ele é reimpresso na proposta (seed-ds-proposta), no e-mail (seed-email.md) e no PDF. Toda marca que o editor aceita é uma marca que os outros três meios precisam saber desenhar — e o e-mail é o mais restrito dos quatro. Uma marca nova custa quatro implementações e quatro testes, não um.

Descartado, com o porquê: títulos e tabelas dentro do campo (são estrutura de documento, e o documento é o A13) · cor de texto e realce (não invertem no tema escuro, e cor não é informação que sobrevive à reimpressão) · imagem embutida (vira anexo, que é o §14) · Markdown como formato de entrada (exigiria que a pessoa soubesse a sintaxe — o oposto de toolbar mínima).

68.3 Os contratos ET1–ET14#

68.4 Os números medidos#

Alvo dos seis botões: 44×44px.

A prova da higienização, medida — colado o HTML que um editor de escritório produz (style="font-family:Calibri;color:#333333", <b>, <font color="#FF0000">, <div>, <span>):

68.4-b O gate achou o que a lista branca não cobria: comentário também é conteúdo#

O Rafael colou de um editor real e o resultado trouxe <!--StartFragment--> para dentro do campo. A higienização varria no.querySelectorAll('*') — e comentário não é elemento. Ele sobrevivia inteiro, e a suíte não via, porque ela media tags e comentário não é tag.

Não é enfeite: <!--StartFragment--> e <!--EndFragment--> são marcadores que o clipboard do Windows adiciona a todo text/html; e o Word emite comentários condicionais (<!--[if gte mso 9]><xml>…<![endif]-->) com folhas de estilo inteiras dentro deles. Uma lista branca de tags não vê nada disso.

Correção: a higienização passa a varrer os nós de comentário com TreeWalker antes de olhar os elementos, e removê-los. Guarda nova ET8-b, que cola um text/html com os dois marcadores e um bloco condicional do Word e cobra zero nós de comentário — conferindo, na mesma medida, que nenhum texto se perdeu. Provada capaz de reprovar: desfeito o conserto, o placar vai a 20 · 1.

Regra nova: guarda que varre por TIPO DE NÓ erra em todos os tipos que não listou. É a mesma família dos defeitos de recorte (8º, 14º, 17º) — o escopo errado, de novo, agora escolhido por tipo em vez de por posição ou por texto.

E um achado de leitura, não de código: o bloco "o que se cola" mostra o código-fonte escapado. Selecioná-lo com o mouse e dar Ctrl+C leva texto, e o editor insere texto — corretamente, mas o resultado parece quebrado. A bancada agora diz isso em uma linha, e o botão "Colar isto no editor" é o caminho declarado: ele entrega o mesmo conteúdo como text/html, que é o que o editor de escritório de fato coloca na área de transferência.

68.4-c A lista branca responde QUAIS tags — ela não responde EM QUE ORDEM#

Segunda volta do mesmo gate, e o achado é de outra natureza. Colando dentro de um parágrafo existente, a saída era:

<p>Texto que ja<p>Escopo…</p><p>Prazo…</p> estava no campo.</p>

Bloco dentro de bloco. HTML inválido — um <p> não pode conter um <p>. E a guarda ET7 passava, porque o conjunto de tags estava certo: p, strong, em. O que estava errado era o arranjo.

Por que aconteceu: a colagem insere os nós com range.insertNode, e a API do DOM não impõe modelo de conteúdo — só o parser de HTML impõe. Inserir programaticamente permite o que o parser jamais produziria.

Correção, usando o próprio parser: reatribuir innerHTML faz o conteúdo ser reanalisado, e o parser fecha o <p> de fora ao encontrar o de dentro. Depois disso, parágrafo vazio sai e texto solto no topo é embrulhado — sem bloco, o consumidor (proposta, e-mail, PDF) não sabe onde o parágrafo começa. A normalização roda só na colagem, nunca no input: o round-trip recria os nós, e recriar nós enquanto alguém digita mataria o cursor a cada tecla.

Regra nova: lista branca é vocabulário; estrutura é outra medição. Toda guarda que valida marcação por conjunto de tags precisa de uma irmã que valide aninhamento.

Guarda nova ET7-b: cola com o cursor no meio de um parágrafo — a posição que produzia o defeito — e mede três coisas que só existem na estrutura (bloco aninhado, parágrafo vazio, nó de texto solto no topo), conferindo também que o texto antes e o texto depois do cursor sobrevivem. Provada capaz de reprovar: sem a normalização, ela acusa 2 aninhamentos e o placar vai a 21 · 1.

68.5 Uma decisão de render, e por que ela está escrita#

Os quatro primeiros botões usam glifo tipográfico — B, I, •—, 1—. Os dois últimos usam palavra: “Link” e “Limpar”.

O motivo é um achado do render, não gosto: ⛓ (link) e ⌫ (limpar) caem em fonte de fallback e saem como retângulo vazio em parte das máquinas. O set canônico do §45 não tem glifo de link nem de limpar formatação, e a árvore NM4 manda usar Lucide nesse caso — mas importar dois SVGs para dois botões de uma toolbar de seis é peso sem retorno. Palavra curta é legível em qualquer fonte, em qualquer tema, e não precisa de legenda.

68.6 A suíte#

suite-texto-rico.mjs — 22 PASS · 0 FAIL · 1 medida. A guarda central mede o que sai, não o que aparece: um editor pode parecer perfeito e produzir <b style="color:#333">.

Detalhe de método que vale para as próximas suítes: a lista branca está escrita nas duas pontas — no gerador e na suíte — de propósito. Guarda que importa a régua do medido não mede nada: mede a opinião dele sobre si mesmo. Se alguém afrouxar a lista no gerador, a suíte reprova.

68.7 Pendências#

---