Porque um blog em blocos tipados vence o WYSIWYG

Escreves um artigo, clicas em negrito, colas uma imagem, publicas. Três meses depois, queres esse mesmo conteúdo numa newsletter e num feed RSS, e é aí que dá o drama: `<span style>` do Word colados à bruta, uma tabela que rebenta no telemóvel, um h1 duplicado que arruína o teu SEO. O problema não é o teu editor — é que guardas HTML livre em vez de guardar dados.

Na Zylior tratamos cada artigo como uma lista de blocos tipados validados, não como uma sopa HTML. Isso muda tudo: um único conteúdo renderiza em página web, em email e em texto simples, sem nunca partir. Eis porque este modelo vence o WYSIWYG, com o detalhe técnico.

O WYSIWYG guarda HTML, e o HTML deriva

Um editor WYSIWYG produz uma string HTML que arrumas na base de dados. O problema: essa string é não restringida. Nada impede um `<div>` órfão, um `style="font-family:Calibri"` colado do Word, um `<h1>` no meio do corpo, ou uma tag nunca fechada. Não o vês no editor — ele "corrige" silenciosamente na exibição — mas no dia em que tiras esse HTML do seu contexto (email, app móvel, API), ele parte.

• Estilos inline parasitas: um copiar-colar do Word/Notion injeta `mso-*`, cores fixas, `<o:p>`. O teu tema deixa de controlar seja o que for.
• Estrutura inválida: `<h1>` duplicado, `<h3>` sem `<h2>` pai → hierarquia partida para o SEO e os leitores de ecrã.
• HTML que não sobrevive ao email: o Gmail remove metade das tuas tags, a tua `<figure>` fica ilegível.
• Nenhuma garantia de re-render: o mesmo HTML renderizado por dois motores (web vs cliente de correio) dá dois resultados diferentes.

Um artigo = dados validados, não markup

A alternativa: nunca guardas HTML, mas sim um array de blocos tipados, cada um com uma forma conhecida validada na escrita. Um parágrafo é `{type:"p", text}`; um título de secção, `{type:"h2", text}`. O inline está restrito a uma whitelist (`negrito`, `itálico`, links https). Tudo o que não entra no esquema é rejeitado ao guardar, não "tolerado na exibição".

{
  "meta_title": "Blocs typés > WYSIWYG",
  "blocks": [
    { "type": "p", "text": "Accroche en **gras** et [un lien](https://zylior.com)." },
    { "type": "h2", "text": "Une section" },
    { "type": "list", "ordered": false, "items": ["Item 1", "Item 2"] },
    { "type": "callout", "tone": "tip", "text": "Un encadré." }
  ]
}

A partir daí, validas com um esquema (Zod, JSON Schema, tanto faz): `type` no enum, `text` limitado a N caracteres, `items` um array de strings, `tone` dentro de `{info,warn,tip}`. Um artigo inválido não pode ser guardado. Deslocas o rigor da exibição para a escrita — onde um erro custa uma mensagem de erro, não uma página partida em produção.

Um só conteúdo, três renders garantidos

É este o verdadeiro ganho operacional para um solo-founder. Como um bloco são dados semânticos ("isto é um título", "isto é uma lista") e não markup, escreves um renderer por alvo e cada bloco sabe renderizar-se em qualquer lado:

1. Web: `h2` → `<h2 class="...">` com o teu design system, `code` → coloração de sintaxe.
2. Email: o mesmo `h2` → tabela HTML com estilos inline compatível com Gmail/Outlook; os tipos proibidos nem sequer conseguem chegar.
3. Texto simples / RSS / LLM: `h2` → `## Título`, `list` → marcadores markdown. Perfeito para resumir um artigo a um agente ou alimentar um digest.
4. JSON-LD: derivas automaticamente `articleBody`, `headline`, `wordCount` a partir dos blocos, sem fazer parse de HTML.

Pré-visualização = publicado, e SEO realmente controlado

Com HTML livre, a tua pré-visualização usa muitas vezes um motor de render diferente do de produção (o editor vs o site): o que vês não é o que sai. Com blocos tipados, a pré-visualização chama exatamente o mesmo renderer web que a publicação. Zero surpresas: se a pré-visualização está boa, o publicado é idêntico. Do lado do SEO, como a estrutura está garantida, controlas o que o WYSIWYG deixa derivar: um único `h1` (vindo de `meta_title`, nunca no corpo), uma hierarquia `h2`/`h3` coerente, uma `meta description` limitada a 140-160 caracteres, um `canonical` limpo, e um `JSON-LD` do tipo `Article` derivado mecanicamente dos blocos. O teu markup é válido por construção, não por esperança.

Para ser honesto, não é de graça: manténs os teus renderers e o editor é mais restrito do que um WYSIWYG de "tudo é permitido" (nada de colagem mágica do Word). Para um blog de portefólio SaaS onde queres fiabilidade e multicanal, é o bom compromisso. Em concreto, para começar: define um enum de tipos (`p`, `h2`, `h3`, `list`, `code`, `callout`, `quote`), escreve um esquema que rejeite tudo o resto, liga um renderer web e um renderer de texto (o email vem depois), e faz a tua pré-visualização apontar para o renderer web de produção. Vais ter um blog onde a pré-visualização nunca mente, onde o mesmo artigo sai em newsletter sem retoques, e onde o teu SEO está correto por omissão — não por vigilância manual.