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

269

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.

Vilx-
fonte
6
@JuhaUntinen: isso ... parece improvável. Fonte?
Paul D. Waite
5
@ PaulD.Waite - Na verdade, ainda é verdade hoje, eu acho. Leia as outras respostas. A menos que a tabela tenha table-layout:fixed, ela precisará carregar totalmente antes de poder ser exibida. Com a banda larga moderna, esse efeito é simplesmente menos perceptível.
Vilx-
4
@JuhaUntinen: Isso não é totalmente preciso. O mecanismo de renderização de tabela era mais lento quando você usava porcentagens para larguras de coluna, pois a tabela inteira precisava ser baixada antes que o navegador pudesse começar a descobrir o tamanho de tudo. Isso foi mais complicado pelas tabelas aninhadas. No entanto, havia então (e ainda existem) maneiras de tornar a renderização de tabela MUITO MAIS RÁPIDA. Pouquíssimos desenvolvedores se preocupam em aprender seu ofício o suficiente e, em vez disso, pular em bandwagon.
NotMe
4
Nos dias ainda mais antigos, costumávamos imitar divs com tabelas.
Wyatt Barnett
4
Alguém leu que não deveria usar tabelas para o layout e entendeu que elas não deveriam usar tabelas. Detesto essa tendência.
Casey #

Respostas:

120

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.

whostolemyhat
fonte
6
Estou aceitando esta resposta porque parece que nada mais útil está chegando. Há respostas com maior número de votos, mas elas basicamente dizem "porque a semântica" (e a única razão da semântica que eles podem fornecer são os leitores de tela, o que não me convence). A resposta da @ HorusKol mencionou a capacidade de resposta antes da sua, mas a sua é mais objetiva. Se uma resposta melhor aparecer no futuro, mudarei para que seja a aceita.
Vilx-
5
Isso é ridículo e preguiçoso. Qualquer coisa que você esteja fazendo com <div>"tabelas" provavelmente poderia ser feita com outras regulares, portanto, literalmente, não há razão (além das versões antigas do IE e da preguiça) de usar elementos não-semânticos para criar tabelas. Dito isto, dados tabulares reais parecem raros na internet, então talvez isso não seja um problema.
Você
1
@Vilx: A pergunta que você fez é "Por que as pessoas estão fazendo tabelas com divs", e é para isso que você está recebendo respostas. Por exemplo, você pode não se importar com os leitores de tela, mas isso não muda que a acessibilidade seja uma preocupação real para muitos e (junto com os mecanismos de pesquisa) o principal motivo pelo qual muitas pessoas escolhem o HTML semântico.
precisa saber é o seguinte
13
Para todos os efeitos, isso é totalmente errado. Se seus dados são tabulares, eles são exibidos em uma tabela. Alegar que as tabelas se comportam especialmente mal em um dispositivo móvel é BS. Você pode alterar com facilidade as propriedades de exibição dos elementos da tabela para valores que não sejam da tabela, assim como pode fazer com que os elementos que não sejam da tabela tenham valores de tabela.
Cimmanon 04/04
8
Eu acredito que esta resposta é um pouco enganadora. As tabelas responsivas são um bom design, mas são independentes da pergunta se você deve usar <table> ou <div> - você pode usar o mesmo efeito visual. De fato, isso é essencial na idéia de separação de estrutura e apresentação. É verdade que as versões mais antigas do IE não permitiam substituir o estilo da tabela, mas as versões mais antigas do IE também não suportavam display: table, portanto você não podia usar as tabelas responsivas de qualquer maneira.
precisa saber é o seguinte
153

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.

JacquesB
fonte
14
@ Vilx- por que usar <em>e <strong>ao invés de <b>e <i>? Porque <b>e <i>não são sobre a semântica da tag. <table>tem significado semântico . Usá-lo para algo que não é uma tabela torna mais difícil entender o significado semântico do documento.
22
@ Vilx- The book <i>Peoplesoft</i> is the <em>best</em> book on the subject. Colocar o <i>melhor em prática seria errado, porque isso significa algo diferente do que o <i>título do livro. Para saber mais, consulte Por que as tags <b>e estão <i>obsoletas? e Qual é a diferença entre <b>e <strong>, <i>e <em>?
19
Se você não se importa com o que seu conteúdo significa, sugiro que você pare de usar qualquer elemento, exceto formulários e divs. Basta adicionar classes para aplicar estilo e comportamento.
Rich Remer
9
@ Vilx-: Quando você diz que se importa com a experiência de seus usuários, parece significar apenas um subconjunto deles. O principal motivo para usar a marcação corretamente da maneira que você está descrevendo é a acessibilidade, que está diretamente relacionada à experiência do usuário de usuários com deficiência. Essas são as pessoas que se beneficiam de você fazer as coisas da maneira certa e ignorar essas convenções significa provavelmente dificultar a experiência na Web.
ROOBY
31
@ Vilx-, sim, um leitor de tela trata uma <tabela> muito diferente de um <div>. <div> s são ignorados e lidos sequencialmente. Dentro de uma <tabela>, ele deve fornecer diferentes pressionamentos de tecla / comandos de navegação ("Ir para a célula à direita", "Ler o título da coluna e da linha" e assim por diante) e exibir informações de localização diferentes (quando o fluxo de leitura entra em uma tabela aparece algo como "Tabela 3, linha 1 coluna 1, Lorem Ipsum dolor ... ")
Euro Micelli 31/03
102

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.

HorusKol
fonte
Os nomes das classes eram na verdade apenas um exemplo. Na vida real, eles são principalmente descritivos. De qualquer forma, no seu exemplo, por que você usa em <div>vez de <table>? Que benefícios oferece?
Vilx-
1
Hmm ... bem, no seu caso, você realmente faz duas representações diferentes do mesmo HTML por meio de consultas de mídia. OK, esse é um bom caso de uso. Mas se esse não fosse o caso, e você saberia de antemão que essa galeria de miniaturas será exibida apenas em um só lugar e apenas em formato de tabela - você usaria um <table>então ou ainda display:table? Porque, de certa forma, são dados tabulares. Exceto que os "dados" são imagens, mas ainda assim.
Vilx-
15
bem, não, não são dados tabulares. você o está apresentando em uma grade que se assemelha a uma tabela. Os dados tabulares são estatísticas e informações comparativas - pense como uma planilha. Você diria que a exibição de miniaturas no Windows File Explorer é uma tabela? E isso sempre será apresentado como uma tabela? E se você quiser um estilo de exibição diferente em 6 ou 12 meses? Por que impor restrições que têm efeitos a longo prazo, a fim de serem obstinados diante da prática amplamente aceita?
HorusKol
12
Exceto que não são dados tabulares. Não há outra razão além da decisão arbitrária de layout de que esse conteúdo se assemelhe a uma tabela. Não são dados estruturados em colunas e linhas, é uma lista de conteúdo, dispostos em uma grade. - editar: O que o HorusKol disse.
Eric King
3
Bem, tudo bem, isso foi esticar um pouco. :) Bem, você me deu algo em que pensar! Obrigado por isso! Ainda não estou 100% convencido, mas pelo menos é algo para continuar. :)
Vilx:
11

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.

Eu não
fonte
Offtopic sobre o DOCTYPE: Eu pensei que, embora houvesse uma diferença teórica (e os validadores levassem isso a sério), na prática, os navegadores realmente não diferenciavam entre eles. OK, talvez tenha havido pequenas alterações entre os sabores HTML / XHTML, mas as informações de versão e DTD pelo menos não foram usadas. É por isso que o HTML5 descartou tudo de qualquer maneira e seguiu justamente, <!DOCTYPE html>e é por isso que funciona mesmo em navegadores antigos como o IE6. Perdi alguma coisa?
Vilx-
2
@ Vilx: Um doctype coloca um navegador em um determinado modo. Entre outras coisas, define o modelo de caixa em uso. Para vários tipos de documento, os navegadores não se alinharam porque o modelo de caixa usado era diferente. É por isso que muitos desenvolvedores se queixaram de que os navegadores mostravam as páginas de maneira diferente e, em vez de corrigir o tipo de documento, usavam enormes folhas de redefinição de css. No entanto, existem alguns tipos de documentos nos quais todos os navegadores usavam o mesmo modelo de caixa - mas esses nunca eram o padrão, era necessário conhecê-los.
NotMe #
@ Vilx: html 5 não descartou a coisa toda. Em vez disso, um novo doctype foi adicionado. A questão é que a primeira linha que aparece na parte superior do documento html é crítica e se você não entende o que faz e como os vários navegadores reagem a ele, você gastará muito tempo descobrindo por que seu layout está "quebrado" em um navegador específico.
NotMe
Espera, por isso não são diferentes doctypes que fazem o mesmo documento processar diferente? Quais? Lembre-se de que estou falando sobre diferentes tipos de documento, não doctype vs falta de doctype (também conhecido como quirksmode).
Vilx-
@Vilx: É um pouco mais complicado, já que alguns doctypes acionam o modo quirks (o mesmo que sem doctype) e outros doctypes (incluindo o html5 doctype) acionam o modo standard, e existem até alguns doctypes que acionam um terceiro "quase-padrão "em alguns navegadores.
precisa saber é o seguinte
5

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.

Jay
fonte
7
escrito no último parágrafo - você leu a especificação HTML5 para esses elementos, não leu? w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/ html / wg / drafts / html / master / semantics.html # the-ol-element - especialmente se a ordem importa, use o elemento ol (já que essa é a parte estrutural) - você ainda pode apresentá-lo como uma lista de marcadores usando CSS
HorusKol 31/03
5
e se você olhar para as outras duas respostas aqui, você vai ver que nem dizer simplesmente "porque é a regra" - ambos lay out justificativas muito claras para os casos de regras e de uso
HorusKol
1
Hmm, parece-me que eu disse algo como: "Alguém vê um problema e propõe uma regra para evitá-lo. Outros vêem o valor dessa regra. Então eles insistem em devoção cega a essa regra, sem levar em consideração o problema original que deveria para resolver e / ou independentemente de quais outros problemas ele cria ". Não nego que haja um pensamento razoável por trás da regra. Eu simplesmente não concordo com a conclusão. Certamente eu posso dizer: "Você tem um bom argumento, mas eu discordo." E certamente você não nego que há pessoas que não entendem os prós e contras e dizer ...
Jay
1
... "porque é a regra". Eu tive várias conversas com essas pessoas ao longo dos anos, sobre esse assunto em particular e sobre muitos outros. Pessoas que se recusam a discutir os prós e contras de uma regra, porque é a regra, o fim da discussão.
Jay
Surgiu essa infeliz noção de que o design HTML tem suas raízes em alguma forma abstrata de engenharia, e não na arte. Como tal, nesse sentido, alguns decidiram que deve haver regras absolutas análogas à física, e a gravidade que deve ser obedecida, ou alguém que quebra essas regras se afasta da "fé mais pura". A realidade é que nenhum navegador nem metáfora de design são infalíveis. Ande cautelosamente em torno daqueles que insistem no contrário.
David W
5

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.

Crisfole
fonte
3

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.

Jonathan Eunice
fonte
4
como isso chega perto de responder à pergunta?
HorusKol
2
Na IMO, ele discute a questão subjacente de por que designers, desenvolvedores e profissionais de conteúdo optam por usar elementos genéricos ( <div>e <span>) no lugar de elementos específicos criados por propósitos (por exemplo <table>). É um pouco mais meta do que apenas essas tags, mas fala diretamente com os padrões e princípios de uso.
Jonathan Eunice
@HorusKol De fato, de todas as respostas aqui, essa é mais consistente e apoia sua resposta. Eu diria que eles se encaixam bem.
Jonathan Eunice
1
Eu não sei se eu iria tão longe a ponto de contrastar div(como genérico) com table(como construído de propósito). Eles são ambos -construído propositadamente, para duas finalidades diferentes (talvez ainda parcialmente sobrepostas). Creio que este é o cerne da questão.
Eric King
@ EricKing É justo dizer que isso divtem um propósito. Mas dive spannão têm a muito específica finalidade que table, thead, tdetc fazer. Ninguém se assustará se você usar divelementos diversos para barras laterais, aspas, agrupamentos de seções etc. - em praticamente qualquer lugar do documento. Tente fazer isso com um unenclosed thead, tdou li. Em vez de "criado para fins específicos", talvez "específico para fins específicos" ou "com uma função específica pretendida".
Jonathan Eunice
0

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.

Robert Munn
fonte