Para que servem as tabelas (e o que elas já estragaram) — Tabelas

Uma pergunta decide

Abra qualquer painel admin de uma app Rails: pedidos, usuários, faturas, deploys. O formato é sempre o mesmo: linhas de registros, colunas de atributos. Antes de escrever uma única tag, faça a pergunta que decide se <table> é a ferramenta certa:

Esse conteúdo faria sentido colado numa planilha, com cabeçalhos de coluna descrevendo cada célula abaixo deles?

Se sim, é dado tabular e <table> é a escolha correta e semântica. Se não: se você só quer coisas lado a lado visualmente, não é uma tabela, e CSS (alguns cursos adiante neste roteiro) é a ferramenta. Essa distinção parece óbvia, mas a história da web diz o contrário.

A anatomia, no menor tamanho

<table>
  <tr>
    <th>Product</th>
    <th>Price</th>
  </tr>
  <tr>
    <td>Blue T-Shirt</td>
    <td>$25.00</td>
  </tr>
</table>

Três tags carregam a estrutura inteira:

Tag	Significa	Trabalho
`<table>`	table	O contêiner anunciando "grade de dados"
`<tr>`	table row	Um registro horizontal
`<td>`	table data	Uma célula com um valor
`<th>`	table header	Uma célula que descreve as células da sua coluna ou linha

Repare no que está faltando: não existe tag de "coluna" onde você escreve células. Colunas são implícitas: a primeira célula de cada linha se alinha na coluna um, a segunda na coluna dois, e assim por diante. Linhas são explícitas; colunas emergem.

th não é "td em negrito"

Navegadores mostram o <th> em negrito e centralizado por padrão. Isso tenta iniciantes a usá-lo como atalho de estilo, ou a trocá-lo por um <td> em negrito. As duas coisas erram o alvo, e é o mesmo alvo que todo curso desta série vem martelando: a tag codifica significado, não aparência.

Um <th> diz ao navegador (e, muito mais importante, a um leitor de tela) "esta célula rotula outras." Quando um usuário de leitor de tela chega a uma célula no meio de uma tabela grande, o software anuncia os cabeçalhos dela: "Price, Blue T-Shirt, $25.00." Sem os <th>, ele ouve só "$25.00", sem saber o que o número significa nem de qual registro é. A Aula 5 aprofunda isso; por enquanto, a regra é simples: toda tabela de dados real tem cabeçalhos, e cabeçalho é <th>.

O que o navegador constrói a partir disso

O curso de DOM Basics mostrou que a marcação vira uma árvore viva com papéis atribuídos. Tabelas ganham uma família inteira deles:

table       → role: table
  tr        → role: row
    th      → role: columnheader (ou rowheader)
    td      → role: cell

Por causa desses papéis, a tecnologia assistiva navega a tabela célula a célula, coluna a coluna, como seu olho varre uma planilha. É também a primeira coisa a conferir no painel Accessibility das DevTools quando uma tabela se comporta mal. Este curso vai criar esse hábito aula a aula.

A idade das trevas: tabelas de layout

Por cerca de uma década (do fim dos anos 1990 até os anos 2000) <table> foi a principal ferramenta de layout de página da web inteira. Sites aninhavam tabelas dentro de tabelas dentro de tabelas para montar sidebars, barras de navegação e páginas de múltiplas colunas, porque layout em CSS mal existia. Um esqueleto de página típico era assim:

<!-- Como páginas eram construídas por volta de 2001. Nunca faça isso. -->
<table width="100%">
  <tr>
    <td width="200">links de navegação...</td>
    <td>todo o conteúdo de fato...</td>
  </tr>
</table>

Funcionava no visual e era um desastre semântico. Leitores de tela anunciavam menus como grades de dados, a marcação era impossível de manter e o significado de cada página sumia sob mentiras estruturais. O CSS moderno (Flexbox e Grid, ambos neste roteiro) encerrou essa era por completo. Hoje a regra não tem exceção que valha aprender: tabela é para dado, CSS é para layout. Se você herdar um codebase antigo e encontrar uma tabela de layout, encontrou arqueologia, não uma técnica.

Um sobrevivente curioso: e-mail HTML. O suporte a CSS dos clientes de e-mail está décadas atrás dos navegadores, então e-mails de marketing ainda usam layout com tabelas internamente. É um nicho com ferramentas próprias. Vale saber que existe para um template de e-mail não te confundir, mas este curso não ensina isso.

Por que isso importa para o Rails

O loop @products.each é o coração da maioria das views de index no Rails, e o alvo natural de renderização dele é uma linha de tabela:

<table>
  <tr>
    <th>Name</th>
    <th>Price</th>
  </tr>
  <% @products.each do |product| %>
    <tr>
      <td><%= product.name %></td>
      <td><%= product.price %></td>
    </tr>
  <% end %>
</table>

Um registro por <tr>, um atributo por <td>: a tabela do banco e a tabela HTML se espelham quase linha a linha. Os scaffolds do Rails deixaram de gerar tabelas no Rails 7: a view de index agora renderiza um <div> por registro via partial. Telas de admin, relatórios e painéis ainda pedem tabelas, então dominar tabelas compensa rápido no trabalho real com Rails.

Como este curso está organizado

Para que servem as tabelas, e a aula de moral das tabelas de layout (você está aqui)
Linhas, células e cabeçalhos: tr, td, th, e o que os navegadores corrigem em silêncio
Dando estrutura a uma tabela: thead, tbody, tfoot e caption
Células que se estendem: colspan, rowspan, e a matemática de grade que os mantém honestos
Tabelas que leitores de tela navegam: scope e companhia
Tabelas que não cabem: lidando com overflow em telas pequenas
Juntando tudo: uma tabela de index Rails com cara de produção

No fim, suas tabelas serão do tipo que um revisor aprova sem comentário. Funcionam para quem enxerga e varre colunas, para quem navega células com leitor de tela e para o navegador que monta a árvore de acessibilidade. O ponto de partida é o que acontece quando você escreve uma tabela um pouco errada. O navegador tem opiniões sobre isso, e a Aula 2 as mostra nas DevTools.