ti-enxame.com

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 sobre 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, faça apenas um <table> E termine com ela. 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 tabela para layout (porque nada mais tem os recursos de expansão de uma tabela), então eles fazem um <div> ( porque é não uma tabela!) e adicione CSS que a torna uma tabela de qualquer maneira.

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

O argumento original para se afastar das 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ê será precisa entender e alterar a estrutura HTML para alterações sérias no design. E as tabelas não tornam o trabalho mais difícil ou mais fácil do que divs.

De fato, a única maneira que vejo que as tabelas podem dificultar a modificação de um layout é se você abusou-os e criou uma bagunça ímpia. 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 detrimento de uma tabela real?

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

278
Vilx-

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 estão ocultas ou são agrupadas, por exemplo o nome e o endereço de e-mail podem ser separados em telas grandes, mas são agrupados 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. E se <table> tags são usadas, você precisa substituir os estilos e o layout padrão do navegador antes de adicionar seu próprio código, portanto, neste caso <div> tags economizam muito CSS padrão. Além disso, versões anteriores de IE não permitem substituir estilos de tabela padrão, portanto, use <div>s também facilita o desenvolvimento entre navegadores.

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

Edit: Devo salientar 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 de divs.

122
whostolemyhat

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

Se suas informações são semanticamente uma tabela, use um <table>- tag. Se você deseja apenas uma grade para fins de layout, use outros elementos html apropriados e use display:table na 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 use <table> para tudo e não apenas para algo que é semanticamente uma tabela? Visualmente, é obviamente o mesmo (já que o elemento da tabela apenas possui display:element na 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.

O <table> versus display:table discussão é apenas um caso do princípio mais geral do uso de 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. seu layout de três colunas pode ser apresentado em uma única coluna em um celular usando uma folha de estilo alternativa.

154
JacquesB

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 marcas por tentar mostrar que o conteúdo não é dados tabulares , mas perdem marcas 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 o original <table> marcação com nomes de classe 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

ma tabela contém dados tabulares - a apresentação de uma tabela está inextricavelmente vinculada à estrutura de uma tabela. Os dados tabulares sempre precisam estar em formato tabular, independentemente de 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 moer algumas marchas em qualquer cabeça de desenvolvedor) ou usar divs bem rotulados que permitem abordagens mais flexíveis ao estilo.

E práticas recomendadas há vários anos foi para evitar tabelas quando não era necessário apresentar dados tabulares.

102
HorusKol

Antigamente, o mecanismo de renderização de tabela "aparece" era mais lento 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 divs 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 rápido do que 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ários bandwagons e seguem o código que podem copiar/colar. Até hoje, acho que pouquíssimos desenvolvedores da web sabem a diferença de um tipo de documento para o outro - e essa é a principal razão pela qual vários sites têm todos os tipos de soluções alternativas para cobrir vários navegadores.

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

11
NotMe

Se eu conseguir um pouco de "meta" aqui, isso traz dois problemas à minha mente:

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.

Dois: 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 o X porque essa é a regra", e então pergunto: "Mas por que devemos fazer o X?", E eles me olham com espanto 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 fácil e limpa?

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.

5
Jay

Já existem toneladas de ótimas respostas aqui. Mas eu queria acrescentar que os elementos table têm limitações de renderização que não existem para os elementos div. 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 for ver a tabela inteira em uma única tela e não desejar renderização personalizada, use um elemento table, caso contrário, divs porque Eu posso controlar os resultados muito, muito mais facilmente.

5
Crisfole

HTML e CSS desenvolveram um certo grau de flexibilidade, o que significa que mesmo conceitualmente "bloqueia" elementos como <div> (A forma mais antiga e mais geral de conteúdo de blocos do HTML) não precisa ser exibida 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. Dadas as funções especiais, duvido que você possa remapear utilmente as tags de 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 discutir sobre como todos devemos usar a "marcação semântica" blá blá blá ou acreditar com os pitonistas que "deveria haver um - e de preferência apenas um - óbvio maneira de fazê-lo. " 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.

Eu não acho que exagero dizer que a substituição também é necessária. No mínimo, é extremamente conveniente . Por um longo tempo, o HTML não tinha <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 reaproveitados e alguns usos foram reclassificados como contêineres e peças de menu. <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, ainda 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 ainda mais longe, "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. Já trabalhei em documentos com pelo menos meia dúzia de tipos diferentes de "ênfase". Nós precisamos sermos capazes de personalizar e remapear isso para diferentes usos, diferentes interpretações. Um tipo de ênfase em HTML? Excruciante reducionista. Limitando. Frágil. O mesmo vale 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 expressões idiomáticas 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.

3
Jonathan Eunice

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 de 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.

0
Robert Munn