Microsoft WorkplaceSharePointSPFxAnálise

O SharePoint agora aceita páginas HTML. É um visualizador, não um framework

A Microsoft começa a liberar as páginas HTML no SharePoint Online. O que é preciso para habilitá-las, o que o sandbox onde rodam permite e em quais cenários o SPFx continua sendo a resposta certa.

Macareno2 de outubro de 20268 min de leitura

Toda vez que a Microsoft anuncia algo com a palavra "HTML" e a palavra "SharePoint" na mesma frase, alguém na equipe de comunicação interna sorri. Finalmente, pensa, vamos poder subir a página que a agência desenhou, com nossas fontes, nossas cores, sem brigar com web parts. E alguém na equipe técnica fica nervoso, porque já viu esse filme.

Nesta semana o filme voltou. A Microsoft publicou no Message Center que o SharePoint Online vai aceitar páginas HTML como mais um tipo de página, ao lado das ASPX de sempre. Dá para criá-las com o Copilot, subir de outra ferramenta, editar e publicar.

Parece revolução. É outra coisa, mais modesta e mais útil do que parece. Vamos por partes.

O que chega e quando

O anúncio é o MC1479517, associado ao item 569208 do roadmap. A prévia pública começa no início de outubro de 2026 e a disponibilidade geral mundial acontece entre meados de novembro e o fim de dezembro.

Na prática, quem cria páginas ganha três caminhos novos: criar uma página HTML pelo menu + New de um site, pedir ao Copilot pelo botão flutuante, ou subir um arquivo .html (ou uma pasta inteira com seus recursos) direto na biblioteca Site Pages. As páginas ficam lá, com as mesmas permissões e a mesma governança que o site já tem.

O que é preciso para usar

A lista de requisitos é curta, e tem algumas surpresas:

Um interruptor por site. Antes que alguém possa subir HTML, um proprietário do site precisa entrar em Site Pages, abrir File types e ativar Allow HTML files. Sem isso, a opção não aparece.
Copilot só para criar com o Copilot. A licença do Microsoft 365 Copilot é necessária para usar a tela de criação assistida e o chat de edição. Subir um HTML próprio, editar o texto, publicar, compartilhar e ver a página não exigem licença.
Dez megas por arquivo. É o tamanho máximo de um HTML em Site Pages.
Lista de permissão para links externos. Para que um link para outro domínio ou outro tenant funcione, o administrador do site precisa incluir o domínio em HTML Field Security.
Sem interruptor global. Segundo a documentação da Microsoft, o recurso não pode ser desativado nem restringido no nível do tenant. O único freio é o toggle de cada site.

Esse último ponto merece uma pausa. Se a sua organização tem centenas de sites, a decisão sobre quem pode publicar HTML fica distribuída entre centenas de proprietários. Para uma equipe de governança, é uma conversa que vale ter antes de novembro, não depois.

Uma sala lacrada

Aqui está a parte que muda todas as expectativas. O SharePoint não serve esse HTML como serviria uma página web. Ele o coloca dentro de um iframe com sandbox e uma política de segurança de conteúdo (CSP) bem rígida, isolado do cabeçalho, da navegação e do resto do site.

Dentro dessa sala, o JavaScript roda, mas não consegue sair. Não faz fetch, não chama APIs externas, não acessa o localStorage. Denis Molodtsov, arquiteto de Microsoft 365, desmontou o visualizador com as ferramentas do navegador durante a fase de Targeted release e documentou o que não está em nenhuma página oficial: o código dentro do iframe não sabe quem é o usuário, não tem contexto de página e não consegue chamar nem a REST API do SharePoint nem o Microsoft Graph.

Também não consegue embutir outros iframes, então um painel do Power BI, um formulário do Forms ou um vídeo do Stream ficam de fora. E todos os links, independente do atributo target, abrem em uma nova aba.

A Microsoft não construiu um lugar para rodar código. Construiu um visualizador para um formato novo, assim como já existia um para PDF.

Há um detalhe para validar quando o recurso chegar ao seu tenant. A documentação oficial, atualizada em 30 de setembro, diz que o sandbox aceita cinco bibliotecas servidas por uma CDN da Microsoft: Chart.js, Mermaid, React, Fluent UI e Babylon. Nos testes de agosto, antes da prévia, nenhuma biblioteca externa carregava. É provável que seja justamente isso que mudou, mas vale confirmar com um arquivo de teste.

Dados "ao vivo" que são uma foto

O recurso mais interessante é o de dados conectados. O Copilot pode gerar um HTML que mostra o conteúdo de uma lista do SharePoint, um Excel ou um CSV, e que se atualiza toda vez que é aberto.

O truque é que o HTML nunca busca os dados. Ele declara num bloco de configuração quais fontes precisa, e é a página do SharePoint, fora do iframe, que traz as linhas e as entrega antes que o arquivo seja desenhado. Até 100 mil linhas por fonte, com todas as colunas, sem paginação nem consultas posteriores.

Filtrar, ordenar e buscar funciona, porque acontece em memória. Gravar de volta, não. Atualizar significa recarregar tudo do zero. É uma foto tirada de novo toda vez que alguém abre a página, não uma conexão.

Páginas HTML frente ao SPFx

Para quem constrói portais, a pergunta inevitável é se isso substitui o SharePoint Framework. A comparação responde sozinha:

	Página HTML	Web part SPFx
Implantação	Subir um arquivo	Pacote no App Catalog
Quem cria	Qualquer autor, ou o Copilot	Um desenvolvedor
Contexto do usuário	Nenhum	Completo (identidade, site, idioma)
REST e Graph	Bloqueados	Disponíveis com permissões aprovadas
Dados	Listas, Excel, CSV, só leitura	Qualquer API, leitura e escrita
Chamadas externas	Bloqueadas	Permitidas via origens confiáveis
Navegação	Sempre nova aba	Normal
Tema do site	Não é herdado no HTML enviado	É herdado
Composição na página	Uma página inteira, isolada	Peça combinável com outros web parts
Licença para criar	Copilot se usar o Copilot	Nenhuma adicional

O que mais pesa num projeto real está nas linhas do meio. Um indicador que respeita a segurança do usuário, um formulário que grava numa lista, uma consulta à Execute Queries API do Power BI (como contamos aqui), um menu que navega: tudo isso continua sendo território do SPFx.

Cinco alertas antes de se empolgar

Não serve para montar uma intranet. Se cada clique abre uma nova aba, um portal feito de páginas HTML vira um labirinto. Para home pages, menus e páginas de área, as páginas modernas continuam sendo o caminho.
O HTML que a agência fez provavelmente não vai funcionar como está. Folhas de estilo externas, fontes web, scripts de terceiros e imagens por URL esbarram no sandbox. Será preciso embutir recursos ou refazer partes.
Os dados não são indexados. A busca enxerga o arquivo, mas não as linhas injetadas ao abri-lo. Ninguém vai encontrar essa página procurando algo que aparece na tabela dela.
Copiar não é migrar. As referências às listas vivem dentro do próprio HTML. Um arquivo copiado para outro site continua lendo a lista original, e as ferramentas de migração não sabem corrigir isso.
A governança fica nas mãos de cada site. Sem controle no nível do tenant, vale definir desde já uma política sobre quais sites habilitam HTML e quem revisa o que é publicado.

Onde ele brilha

Dito tudo isso, o recurso tem um lugar claro e valioso. É o formato perfeito para o Copilot entregar um trabalho pronto: um relatório de status de projeto, um guia visual de marca, um painel de leitura sobre uma lista, um resumo executivo com filtros. Algo que se pede em linguagem natural, se revisa, se ajusta com outro pedido e se compartilha.

E há uma vantagem econômica que pouca gente menciona: quem vê a página não precisa de licença do Copilot. Algumas poucas licenças de autoria podem alimentar uma organização inteira de leitores.

O ponto

As páginas HTML não são uma porta dos fundos para desenvolver no SharePoint sem SPFx. São um tipo de arquivo novo, pensado para que a IA tenha um formato que consegue escrever de uma só vez. Para relatórios de leitura, é uma ótima notícia. Para portais, aplicações e integrações, a arquitetura não muda.

O segredo é não confundir as duas coisas no planejamento. Usar HTML onde basta mostrar, e SPFx onde é preciso saber quem está olhando, conectar sistemas ou gravar algo.

Sua organização está avaliando como as páginas HTML se encaixam na intranet ou no portal em SharePoint? Vamos conversar em macareno.net.

Fontes