Você sabia que até tabelas HTML têm uma API?

• A API HTMLTableElement existe há muito tempo, mas é uma interface nativa para manipulação de tabelas HTML que quase não é usada
• Com essa API, é possível criar e acessar diretamente tbody, thead, tfoot, caption, row, cell etc., sem precisar renderizar a tabela inteira novamente a cada alteração
• O código de exemplo mostra como converter dados em arrays aninhados em uma tabela e adicionar linhas e células com insertRow() e insertCell()
• Também é possível fazer várias manipulações, como acessar células por índice com t.rows[1].cells[1] ou adicionar a última linha com insertRow(-1)
• O autor comenta que essa API tem potencial para ampliar as capacidades da tabela como estrutura de dados, com espaço para eventos e recursos extras, como acontece com formulários

---

Visão geral da API de tabelas HTML

• A maioria dos desenvolvedores cria tabelas com métodos do DOM (createElement etc.) ou com inserção de strings via innerHTML, mas a segunda opção traz riscos de segurança
• O HTML tem uma antiga API HTMLTableElement, que permite lidar com corpo, linhas, células, cabeçalho, rodapé, legenda e resumo (summary) da tabela
• Essa API permite manipular elementos individuais sem rerenderizar a tabela inteira

Exemplo de código: criando uma tabela a partir de um array

• No exemplo, o autor converte o seguinte array aninhado em uma tabela
  • [['one','two','three'], ['four','five','six']]
• A tabela é criada com document.createElement('table'), e cada linha (insertRow) e célula (insertCell) é adicionada em um loop
• O conteúdo de cada célula é definido com innerText

Acesso e modificação de células

• As células da tabela criada podem ser acessadas com base em índices
  • Ex.: t.rows[1].cells[1] → <td>five</td>
• Também é possível remover ou adicionar linhas e células
  • Ex.: t.insertRow(-1) adiciona uma linha ao final
  • t.rows[2].insertCell(0) cria uma nova célula, e depois innerText = 'foo' define seu valor

Limitações da API

• Existem regras de índice pouco intuitivas, como em insertRow(-1)
• Não há como criar elementos TH diretamente, então todas as células acabam sendo tratadas como TD

Possibilidades de expansão futura

• O autor aponta que criar tabelas ainda é algo trabalhoso e sugere revisitar essa API para expandir suas funcionalidades
• Assim como formulários HTML ganharam formData e eventos change, tabelas também poderiam receber eventos ou recursos avançados
• Com isso, a tabela poderia deixar de ser apenas uma ferramenta de layout e assumir um papel mais claro como estrutura de dados

[sonnet]

Como um desenvolvedor com relativamente pouca experiência, fico surpreso com textos que falam como se tivessem “descoberto” uma API que está em uso desde o começo.

[GN⁺]

Comentários no Hacker News

• Parece que muita gente não leu o artigo direito O ponto principal do texto não é a tag `` em si, mas sim a interface DOM específica para tabelas Por exemplo, métodos como HTMLTableElement.prototype.insertRow() e HTMLTableRowElement.prototype.insertCell() são mais intuitivos do que createElement() ou appendChild() Mas em UIs baseadas em bibliotecas como React, Svelte e Vue, quase não se usa mais esse tipo de método É interessante que, como na sintaxe HTML, mesmo omitindo thead, tbody e tfoot, isso é tratado automaticamente Nos últimos 5 anos, eu cheguei a usar diretamente .insertRow, .insertCell, .createTHead, .rows e .cells em scripts de demonstração Em termos de estilo de código, acho mais limpo usar for em vez de forEach e omitir o argumento de índice

  • Hoje em dia os frameworks substituíram demais a manipulação básica de DOM, então parece que ficou raro encontrar gente que conheça bem esses fundamentos Isso me fez lembrar da época em que li no C|net a notícia de que a tag `` tinha sido adicionada pela primeira vez. Acho que eu estou ficando bem velho também

• Lembro de ter usado essa API uns seis meses atrás, depois de ver a documentação da MDN ou por recomendação de uma IA As propriedades rows e cells foram muito úteis para implementar navegação por teclado Um exemplo relacionado pode ser visto no código do ClickHouse

  • O que mais me entristece na web hoje em dia são as pessoas que fazem tabelas com divs Não dá nem para ordenar, e há muitos casos de implementações desastrosas, especialmente como no M365 Admin

• Está no mesmo contexto da discussão sobre botões (thread anterior) Desde uns 10 a 15 anos atrás, tudo foi virando ``, e o HTML passou a ser usado mais como uma caixa de ferramentas de UI do que como marcação semântica

  • Isso acontece porque o DOM é usado originalmente não como documento semântico, mas como alvo de renderização HTML semântico é um bom conceito, mas na prática é difícil esperar isso Além disso, elementos semânticos vêm com estilos padrão, o que leva desenvolvedores a preferirem o neutro Na verdade, acho até que separar e `` foi um erro de design
  • Uso HTML há mais de 20 anos, mas pela minha experiência a maioria ainda usa tags com significado de forma adequada Claro, alguns fazem tudo com div, mas em casos como botões normalmente as coisas são escritas corretamente
  • Acho que essa mudança foi inevitável A maior parte do conteúdo da web é centrada em marketing, então as empresas querem que tudo apareça exatamente do jeito que desejam Se existisse uma web DocBook separada para documentação técnica, seria interessante porque o usuário poderia aplicar seu próprio estilo

• Já usei essa API ao criar uma ferramenta para comparar imagens do Stable Diffusion Como havia muitas linhas e colunas, era preciso recriar a tabela com frequência, mas atualizar o DOM era mais lento do que gerar tudo de uma vez como string Imagino que isso aconteça porque cada chamada da API atualiza o DOM imediatamente

• Havia uma explicação dizendo que “não é necessário renderizar a tabela inteira de novo”, mas na verdade os métodos padrão do DOM já funcionam assim Ainda assim, é bem legal o fato de isso reduzir a navegação tediosa no DOM

  • Dei uma olhada no código do WebKit, e internamente a mesma lógica é usada, então quase não há diferença de desempenho

• A API de formulários HTML também precisa ser redescoberta

• O problema das tabelas não é preencher os dados, e sim o fato de não terem recursos de busca, ordenação e filtragem

  • Fico curioso em relação a que isso está sendo comparado Não vejo motivo para não implementar esse tipo de recurso também em tabelas

• Não entendo a ideia de que “essa API foi abandonada” Eu ainda a uso com frequência para criar tabelas HTML

  • A expressão “Abandonware” é um termo originalmente usado no contexto de licença, então aqui o título é um pouco exagerado Parece que o autor queria dizer que essa API é uma área antiga com espaço para expansão Assim como a API de formulários, acho que tabelas também poderiam ganhar recursos como ordenação e filtragem
  • Hoje a maioria usa frameworks de UI declarativos como React ou Svelte, então essas APIs imperativas de DOM estão se tornando cada vez mais um nicho
  • Em resumo: agora estamos na era do React

• O código de exemplo é interessante, mas os nomes de variáveis são encurtados demais e isso prejudica a legibilidade Em vez de b, t, r e c, seria melhor usar nomes significativos

  • Esse tipo de discussão no fim parece uma discussão de bicicletário, focada em detalhes pequenos demais
  • Em escopos curtos, usar nomes curtos de variável é algo natural
  • Ainda assim, acho que nomes de variável de uma letra são uma otimização equivocada Como alguém que usa Haskell, concordo especialmente com isso
  • Mais do que os nomes curtos em si, o que confunde é a mistura de índices como em (ri, i) Quando variáveis têm papéis parecidos, é melhor manter também um padrão no comprimento dos nomes
  • Linhas como let b = document.body; são especialmente difíceis de ler Você economiza alguns bytes, mas só aumenta a carga cognitiva