HTML Pode Fazer Isso

Artigo original ↗ Discussão no Hacker News ↗

HTML e CSS modernos agora são capazes de lidar nativamente com muito mais interatividade — coisas como dialogs, popovers, `details` agrupados, imagens responsivas e até alguma UI no estilo acordeão e abas — levando muitos desenvolvedores a questionar se frameworks pesados de JavaScript ou SPAs realmente são necessários para interfaces comuns. Os comentaristas destacam benefícios reais: páginas renderizadas no servidor mais rápidas, melhor acessibilidade de base e arquiteturas mais simples que ainda funcionam para usuários que bloqueiam ou não têm JavaScript. Ao mesmo tempo, apontam arestas e lacunas — suporte irregular para recursos como `<datalist>` e seletores de data, controle limitado de estilo e UX, e a necessidade de componentes mais ricos como tabelas ordenáveis ou comboboxes mais poderosos — argumentando que HTML pode substituir alguns, mas não todos, dos padrões atuais impulsionados por JS.

Capacidades e Limites dos Widgets Nativos de HTML

  • Muitos ficam impressionados com quanta interatividade agora é possível com “apenas HTML” mais CSS (dialogs, popovers, details, transições de visualização).
  • Outros enfatizam que alguns recursos ainda estão “quase lá”: por exemplo, datalist carece de fortes restrições de valor, busca aproximada, e tem suporte irregular nos navegadores.
  • Seletores nativos de data são amplamente criticados por serem bugados, inconsistentes entre navegadores/SO e facilmente quebrados por gerenciadores de senhas.

Conteúdo Oculto, &lt;details&gt;, e Pesquisabilidade

  • hidden="until-found" e &lt;details&gt; são elogiados por permitir que CTRL+F revele conteúdo recolhido (FAQs, organogramas, conteúdo em abas).
  • Os casos de uso incluem painéis “ver termos/exclusões”, árvores recolhíveis e padrões de “ir para o conteúdo” (embora isso seja melhor resolvido com estilo de foco).
  • Há debate sobre comportamento agrupado/de acordeão: alguns querem apenas um &lt;details&gt; aberto; outros (citando pesquisa de UX) acham o fechamento automático frustrante.

SPAs, JavaScript, e Abordagens “HTML-First”

  • Vários usuários usam NoScript e julgam sites pela quantidade de JavaScript de terceiros que exigem; eles apreciam sites que funcionam principalmente sem JS.
  • Muitos não gostam de SPAs por quebrarem URLs, botão voltar e favoritos; outros observam que isso pode ser resolvido com roteamento adequado e atualização de URLs.
  • Há entusiasmo por padrões “renderizado no servidor com enfeites” (HTMX, JS mínimo, View Transition API) e experimentos com UIs totalmente sem JS.

Dialogs, Popovers, e Ações Declarativas

  • Os novos atributos de popover/dialog/command recebem elogios por foco consistente, empilhamento, acessibilidade e menus/tooltips/confirmações sem JS.
  • Críticos veem a API de ações declarativas (popovertarget, ...action) como algo que complica demais o HTML em comparação com simples manipuladores de eventos em JS.
  • Os defensores argumentam que isso permite tempo até interatividade mais rápido, melhor SSR e interatividade sem scripts; atributos de script podem ser desativados, tornando ligações declarativas úteis.

Tabelas, Ordenação, e Layout vs Semântica

  • Alguns querem tabelas nativas ordenáveis e até virtualização встроada; outros insistem que “é para isso que JS serve” e se preocupam com o inchaço dos navegadores.
  • A ordenação no lado do servidor via links nos cabeçalhos é defendida como simples e ainda performática; outros querem ordenação multicampo e sem recarregar.
  • Um debate paralelo: HTML como estrutura/semântica vs layout. Alguns argumentam que as tags descrevem implicitamente o layout; outros citam as especificações dizendo que layout pertence ao CSS.

Datas, Formulários, e Localização

  • Pedidos para forçar formatos de data ISO ou alinhar com o lang da página; os formatos nativos do SO confundem usuários e fluxos de back-office.
  • Sugestões: fazer <time> realmente localizar a exibição, ou sempre enviar ISO enquanto mostra formatos localizados de forma consistente.

Suporte do Navegador, Adoção, e Ferramentas

  • Preocupação de que a superfície crescente de padrões dificulta a construção de novos engines; alguns hesitam em adotar novos recursos mesmo quando suportados.
  • Diz-se que LLMs e geradores de código ficam atrás nas novas APIs de HTML/CSS, reforçando padrões antigos e pesados em JS, embora “skills” e orientação possam mitigar isso.

Notas Diversas

  • Imagens responsivas (srcset, &lt;picture&gt;) são discutidas; &lt;picture&gt; é visto como mais flexível que srcset sozinho.
  • Controles nativos como &lt;select&gt; e entradas de cor são pouco usados em parte porque é difícil estilizá-los uniformemente entre plataformas.