Por que as pessoas estão criando tabelas com divs?

No desenvolvimento moderno da Web, encontro esse padrão cada vez mais. Se parece com isso:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

E no CSS há algo como:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

^{* (O nome da classe é apenas ilustrativo; na vida real, são nomes de classe normais que refletem o que é o elemento)}

Até recentemente tentei fazer isso sozinho porque ... sabe, todo mundo está fazendo isso.

Mas ainda não entendi. Por que estamos fazendo isso? Se você precisar de uma mesa, basta fazer uma jateada <table>e pronto. Sim, mesmo que seja para layout. É para isso que servem as tabelas - organizando as coisas de maneira tabular.

A melhor explicação que tenho é que agora todos já ouviram o mantra de "não use tabelas para o layout", então o seguem cegamente. Mas eles ainda precisam de uma mesa para layout (porque nada mais tem a capacidade de expansão de uma tabela), então eles fazem uma <div>(porque é não uma mesa!) E depois adicionar CSS que faz com que seja uma tabela de qualquer maneira.

Para todo o mundo, isso me parece colocar obstáculos desnecessários arbitrários no seu caminho e depois fazer um trabalho extra para contorná-los.

O argumento original para afastar as tabelas para o layout era que é difícil modificar um layout tabular posteriormente. Mas modificar um layout de "tabela falsa" é igualmente difícil e pelos mesmos motivos. De fato, na prática, modificar um layout é sempre difícil, e quase nunca basta alterar o CSS, se você quiser fazer algo mais sério do que pequenos ajustes. Você vai precisar de entender e mudar a estrutura HTML para alterações de design graves. E as tabelas não tornam o trabalho mais difícil ou mais fácil do que divs.

Na verdade, a única maneira que eu ver que mesas poderia fazer um layout difícil de modificar, é se você ab usou-os e criou uma confusão ímpios. Você pode fazer isso com divs também.

Então ... na tentativa de mudar isso de um discurso retórico para uma pergunta coerente: o que estou perdendo? Quais são os benefícios reais de usar uma "tabela falsa" em vez de uma tabela real?

Sobre o link duplicado: não é uma sugestão para usar outra tag ou algo assim. Esta é uma pergunta sobre como usar um <table>vs display:table.

Este é um padrão comum para criar tabelas responsivas. É difícil exibir dados tabulares em celulares, pois a página será ampliada para ler texto, o que significa que as tabelas saem do lado da página e o usuário tem que rolar para trás e para frente para ler a tabela, ou a página será reduzida. , geralmente significando que a tabela é muito pequena para poder ler.

As tabelas responsivas alteram o layout em telas menores - algumas vezes, algumas colunas ficam ocultas ou são agrupadas, por exemplo, nome e endereço de email podem ser separados em telas grandes, mas são recolhidos em uma célula em telas pequenas para que as informações sejam legíveis sem a necessidade de rolar.

<div>s são usados ​​para criar as tabelas em vez de <table>tags por alguns motivos. Se <table>forem usadas tags, você precisará substituir os estilos e o layout padrão do navegador antes de adicionar seu próprio código, portanto, nesse caso, as <div>tags economizam bastante CSS CSS. Além disso, as versões mais antigas do IE não permitem substituir os estilos de tabela padrão; portanto, usar <div>s também facilita o desenvolvimento entre navegadores.

Há uma boa visão geral das tabelas responsivas em CSS-Tricks .

Edit: Devo ressaltar que não estou defendendo esse padrão - ele cai na armadilha da divite e não é semântico - mas é por isso que você encontrará tabelas feitas com divs.

A questão é se os dados são semanticamente uma tabela (isto é, um conjunto de dados ou unidades de informação organizadas logicamente em duas dimensões) ou você apenas usa a grade para o layout visual, por exemplo, porque deseja que uma barra lateral se expanda ou algo parecido.

Se suas informações são semanticamente uma tabela, use <table>-tag. Se você deseja apenas uma grade para fins de layout, use outros elementos html apropriados e use display:tablena folha de estilos.

Quando os dados são semanticamente uma tabela? Quando os dados são organizados logicamente em dois eixos. Se fizer sentido com cabeçalhos para as linhas ou colunas, você poderá ter uma tabela semântica. Um exemplo de algo que não é semanticamente uma tabela está apresentando um texto em colunas como em um jornal. Isso não é semanticamente uma tabela, pois você ainda a leria linearmente e nenhum significado seria perdido se a apresentação fosse removida.

OK, por que não usar <table>para tudo e não apenas para algo que é semanticamente uma tabela? Visualmente, é obviamente o mesmo (já que o elemento da tabela possui apenas display:elementna folha de estilos padrão).

A diferença é que as informações semânticas podem ajudar agentes de usuário alternativos. Por exemplo, um leitor de tela pode permitir que você navegue em duas dimensões na tabela e leia os cabeçalhos de uma célula para ambos os eixos, se você esquecer onde está. Isso seria confuso se a tabela não fosse semanticamente uma tabela, mas apenas usada para o layout visual.

A discussão <table>versus display:tableé apenas um caso do princípio mais geral do uso da marcação semântica. Veja, por exemplo: Por que alguém se incomodaria em marcar corretamente e semanticamente? ou Por que a marcação semântica dá mais peso aos mecanismos de pesquisa?

Em alguns lugares, pode ser exigido legalmente o uso da marcação semântica por motivos de acessibilidade e, em qualquer caso, não há motivo para tornar sua página intencionalmente menos acessível.

Mesmo se você não se importa com usuários com deficiência, ter uma apresentação separada do conteúdo oferece benefícios. Por exemplo, o layout de três colunas pode ser apresentado em uma única coluna em um celular usando uma folha de estilo alternativa.

Na verdade, eu diria que o uso de nomes de classe como "tabela" em seu exemplo demonstra como as pessoas não entendem o que estão fazendo ao tentar a marcação semântica. Eles recebem notas por tentar mostrar que o conteúdo não é um dado tabular , mas perdem notas por nomes de classes incorretos.

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

Tudo o que esse desenvolvedor fez foi replicar a <table>marcação original com nomes de classes CSS. Isso significa que, assim que esse layout não for uma tabela, os nomes das classes estarão em desacordo.

O que esse desenvolvedor deveria ter feito é considerar quais informações estão na tabela - é uma galeria de miniaturas? Bem então:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

Agora eu posso criar um CSS adaptável:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

Por que divs e não tabelas

Uma tabela contém dados tabulares - a apresentação de uma tabela está indissociavelmente vinculada à estrutura de uma tabela. Os dados tabulares sempre precisam estar em formato tabular, não importa onde você coloca esse conteúdo ou em qual tela / dispositivo você deseja que ele seja exibido.

Uma galeria de miniaturas (ou muitas outras coisas, como um formulário de registro, um menu e mais) não são dados tabulares. Pode ser apresentado como uma tabela em alguns layouts de design, mas em outros casos, como telas estreitas de telefone, você deseja que ele use layouts de blocos mais tradicionais. Ou talvez você queira exibir miniaturas em uma barra lateral em vez de na área de conteúdo principal.

Sua escolha agora é produzir marcações diferentes para o conteúdo da tela ampla (tabelas) e o conteúdo da tela lateral ou da barra lateral (divs) - o que significa que os scripts do servidor terão que estar cientes de onde o conteúdo está indo, se você estiver criando isso programaticamente - ou seu script do lado do servidor produz a mesma marcação (porque não se importa onde você está colocando isso) e usa regras CSS diferentes para as diferentes situações.

Então, você tem a opção de sempre gerar tabelas e substituir as regras de exibição de tabela natural com bloco (o que realmente deve afiar algumas engrenagens em qualquer cabeça de desenvolvedor) ou usar divs bem rotulados que permitem abordagens mais flexíveis ao estilo.

E as práticas recomendadas há vários anos são evitar tabelas quando não é necessário apresentar dados tabulares.

Antigamente, o mecanismo de renderização de tabela " aparecia " mais lentamente quando você usava porcentagens para larguras de coluna. O mecanismo basicamente teve que fazer o download de todo o conjunto de dados antes de começar a descobrir o tamanho de tudo para desenhá-lo na tela.

O mecanismo DIV era diferente. Como o navegador encontrava um DIV, ele o seguia e o colocava e começava a preencher o conteúdo em linha. Obviamente, as div podem pular à medida que os dados terminam de carregar. Daí porque eu apareço nas citações acima. O prazo para conclusão de ambos era o mesmo, no entanto, as tabelas não foram desenhadas até o final, o que significava que o usuário não tinha certeza se estava carregando ou não por um segundo ou dois.

Isso piorou à medida que as tabelas foram aninhadas.

Havia então (e ainda existe) maneiras de tornar a renderização de tabelas MUITO MAIS RÁPIDA. Basicamente, dando uma dica de que os tamanhos das colunas não estão mudando, o navegador começa a renderizar dados tabulares imediatamente. Em última análise, isso significa que as tabelas podem realmente ser exibidas na posição correta mais rapidamente que as divs, dando a elas a aparência de serem melhores.

Mas essa não é a história toda. O resto é que a maioria dos desenvolvedores simplesmente não se preocupa em aprender sua arte o suficiente para saber disso. Em vez disso, eles pulam em várias bandwagons e seguem o código que podem copiar / colar. Ainda hoje, acho que pouquíssimos desenvolvedores da web sabem a diferença de um tipo de documento para o outro - e esse é o principal motivo pelo qual vários sites têm todo o tipo de soluções alternativas para cobrir vários navegadores.

Então, +1 para você por fazer a pergunta.

Se eu conseguir um pouco de "meta" aqui, isso me traz dois problemas:

Primeiro: alguém propõe uma regra por um bom motivo, e as pessoas perdem completamente o objetivo, seguindo a letra técnica da regra, ignorando o espírito. Eles encontram uma maneira de realizar todas as coisas ruins que a regra estava tentando impedir, enquanto ainda seguiam tecnicamente a regra conforme redigida.

Segundo: alguém vê um problema e propõe uma regra para evitá-lo. Outros vêem o valor desta regra. Em seguida, insistem na devoção cega a essa regra, sem levar em consideração o problema original que deveria resolver e / ou independentemente de outros problemas que ela crie. Eu tive muitas conversas em que alguém diz: "Você deve fazer X porque essa é a regra", e então pergunto: "Mas por que devemos fazer X?", E eles me olham com perplexidade e exasperação e dizem: "Mas Eu acabei de te contar! Porque é a regra! " Eu respondo: "Mas parece causar mais problemas do que resolve. Acho que seria melhor fazermos Y". E então a pessoa diz: "Não, veja, eu vou lhe mostrar. Veja, está bem aqui neste livro. X é a regra".

Nesse caso, temos um problema: A tag da tabela faz duas coisas: uma, controla o layout de um documento. Segundo, ele transmite a ideia de que os dados incluídos são compostos de linhas e colunas de números ou outros dados.

Muitas pessoas propuseram a solução: não use tags de tabela para controlar o layout de coisas que não são logicamente "tabelas". Use CSS.

Mas há um problema com esta solução. A tag da tabela e suas subtags desempenham muitas funções de layout muito úteis que não são fáceis de obter usando CSS e, quando podem ser alcançadas, o código necessário para isso é geralmente complicado - difícil de ler e de manter. Por que devemos fazer as coisas de uma maneira desajeitada e difícil, quando existe uma maneira limpa e fácil?

Pessoalmente, acho que seria melhor declarar: "O fato de algo estar dentro de uma tag de tabela não significa necessariamente que ela representa linhas e colunas de números". Este não teria sido um pronunciamento ultrajante. Nunca ouvi alguém dizer que a tag "p" pode ser usada apenas para coisas que são realmente parágrafos de frases em inglês gramaticalmente corretas e construídas de maneira lógica. Nunca ouvi alguém dizer que é errado usar uma tag "ul" para uma lista que, de fato, vem em uma ordem lógica, apenas porque você queria marcadores e não números de sequência. Etc.

Já existem toneladas de ótimas respostas aqui. Mas eu queria acrescentar que os tableelementos têm limitações de renderização que não existem para divelementos. Tente criar uma tabela que faça rolagem virtual (como: SlickGrid , DataTables e outras) e você ficará muito desapontado. Simplesmente não funciona. A maioria das grades Javascript modernas (Todas?) Usa divs porque o css permite uma renderização muito mais flexível.

Existem outras limitações também. Minha regra geral é que, se eu vou ver a tabela inteira em uma única tela e não quiser renderização personalizada, use um tableelemento; caso contrário, divino-me porque posso controlar os resultados , muito mais facilmente.

HTML e CSS desenvolveram um certo grau de flexibilidade, o que significa que mesmo elementos "bloco" conceitualmente como <div>(a forma mais antiga e mais geral de conteúdo de blocos em HTML) não precisam ser exibidos como blocos:

div { display: inline; }

Como você observa, <div>pode ser redirecionado para emular <table>e seus companheiros de viagem. Na verdade, a maioria das tags pode. Dado seus papéis especiais, duvido que você poderia ser útil remapear etiquetas macro como <html>, <head>, <body>, e <script>, mas tags "comuns", como <div>, <p>, <b>, <em>, <span>, e <pre>? Em disputa. Faça os blocos de tags inline, os blocos inline, os tags pré-formatados fluírem, os estacionários flutuarem. Enlouqueça, se quiser!

É possível . Você pode querer discutir sobre como todos devemos usar a "marcação semântica" blá blá blá , ou acreditar com os pythonistas que "deve haver uma - e preferencialmente apenas uma - maneira óbvia de fazer isso". No entanto, Tim Toady é um cara inteligente e curioso. Dada a mão livre, ele explorará todos eles. Isso inclui o uso da flexibilidade disponível para fazer substituições. Alguns são sábios, outros serão provados de outra maneira. Mas tentativa, erro e experiência são a única maneira de descobrir isso. Portanto, as condições suficientes para substituição estão presentes.

Não acho exagero dizer que a substituição também é necessária. No mínimo, é extremamente conveniente . Por um longo tempo, HTML não têm <menu>, <section>ou <aside>elementos. No entanto, páginas da web e aplicativos em todos os lugares têm menus, seções e barras laterais. Quão? Porque os elementos da lista HTML ( <ul>, <ol>e <li>) foram facilmente reaproveitado e alguns usos re-classificada como recipientes de menu e peças. <div>poderia substituir <article>, <section>, <aside>, <figure>, e <summary>. O HTML5 atualizou e adicionou elementos sob medida para alguns casos de uso não endereçados anteriormente. É uma ótima atualização e correção para acomodar o uso comum no mundo real.

Mesmo assim, existem muitos idiomas comuns que não possuem tags ou modelos semânticos personalizados . Coisas como páginas, notas de rodapé, aspas, fluxos de comentários, avatares associados, "curtidas", subtítulos e legendas que eu e muitos outros usamos todos os dias. O que devemos fazer? O que nós podemos. Reaproveite elementos "próximos, mas inexatos", com classes e IDs, para apoiar e apoiar nosso trabalho pelos próximos cinco ou dez ou, no entanto, muitos anos até que o HTML6 ou o HTML7 os atualizem. Em teoria, o HTML / CSS "sim, é um X, mas vamos marcá-lo e trabalhar com ele como um Y" é incrivelmente conveniente. Indispensável, realmente. Isso torna o conteúdo da Web flexível e não quebradiço.

Indo além, a "marcação semântica" tem limitações irredutíveis . Isso vale para qualquer tipo de estrutura rigorosa que você possa imaginar para o conteúdo.

Os formatos padrão não podem abranger toda a riqueza de necessidades, desejos e variedades humanas. Eles sempre estarão "atrás da curva" do que as pessoas estão fazendo agora . Como eles estão inovando. Heck, o HTML5 ainda está atrás da curva em notas de rodapé, subtítulos e outras inovações de impressão do século XVII. Faltam recursos essenciais para muitos profissionais da informação e criadores de conteúdo. Então, improvisamos.

Ainda mais imutável é que as informações não cumprem um conjunto de regras. Claro, começa como uma mesa. Mas talvez você queira apenas o resumo - diga o título de cada linha, como uma lista. Talvez ocupe muito espaço e você queira que seja uma lista inline que economiza espaço. Talvez você tenha registros dos quais deseja apenas o título e, se clicar, verá os detalhes subjacentes. Ou você deseja que os itens de uma lista ou tabela complexa sejam agrupados e categorizados. Ah, agora você quer que ela seja transposta e categorizada de uma maneira diferente. Ou os valores plotados como um gráfico de barras. Isso é feito todos os dias em aplicativos, planilhas e visualização de dados. Eles são parte integrante do nosso cenário de informações e o que queremos e precisamos fazer na Web. Os seres humanos constantemente reorganizam a forma e a apresentação de nossos dados. Não é apenas uma coisa, ou um formato / layout, ou um conceito. É fungível, com a semântica dependendo da circunstância e das escolhas que os usuários fazem de maneira interativa. Sim, marque o texto como "enfatizado" (<em>), mas isso é apenas uma convenção. Eu trabalhei em documentos com pelo menos meia dúzia de tipos diferentes de "ênfase". Nós precisamos ser capazes de personalizar e remapear que para diferentes usos, diferentes interpretações. Um tipo de ênfase em HTML? Excruciante reducionista. Limitando. Frágil. O mesmo é verdadeiro para <table>, <p>, etc.

É ótimo ter tags / elementos que ajudem a organizar o pensamento de toda a comunidade sobre "o que vai aonde". Isso ajuda a estabelecer convenções e idiomas e nos torna coletivamente mais eficientes. Mas a capacidade de remapear as coisas, redesenhar e reorientar essas estruturas? Isso faz parte da inclusão e do sucesso da Web.

Os casos de uso são importantes. Há uma grande diferença entre layout / apresentação em uma página de conteúdo e em um aplicativo. No conteúdo, a semântica é muito importante para a percepção e a usabilidade do SEO. Nesses casos, o uso de tabelas para apresentar dados tabulares é geralmente a coisa certa a se fazer. Como outros observaram, os mecanismos de pesquisa o penalizarão, e você pode até infringir as leis de usabilidade se for exigido por lei que esteja em conformidade com as diretrizes de usabilidade do governo.

Em um aplicativo da web, os desenvolvedores podem optar por criar visualizações totalmente separadas para fins de SEO e usabilidade. O design responsivo levou as pessoas a criar visualizações que podem lidar com layouts de desktop e móvel, e os divs são melhores que as tabelas nesses casos de uso.

Veja os sites de comércio eletrônico, por exemplo. A exibição de uma lista de produtos em um resultado de navegação ou pesquisa mostra, em geral, uma lista de produtos em formato tabular, mas essas visualizações podem ser geradas usando divs (que fornecem opções de estilo e layout mais genéricas e flexíveis) em vez de tabelas. Amazon e eBay são bons exemplos dessa abordagem. Inspecione um resultado de pesquisa em qualquer site e você verá um conjunto de divs profundamente aninhado.