Por que não usar tabelas para layout em HTML? [fechadas]


665

Parece ser a opinião geral de que tabelas não devem ser usadas para layout em HTML.

Por quê?

Eu nunca (ou raramente para ser honesto) vi bons argumentos para isso. As respostas usuais são:

  • É bom separar o conteúdo do layout.
    Mas esse é um argumento falacioso; Pensamento Clichê . Eu acho que é verdade que o uso do elemento de tabela para o layout tem pouco a ver com dados tabulares. E daí? Meu chefe se importa? Meus usuários se importam?

    Talvez eu ou meus colegas desenvolvedores que precisamos manter um cuidado com a página da web ... A tabela é menos sustentável? Eu acho que usar uma tabela é mais fácil do que usar divs e CSS.

    A propósito ... por que o uso de uma div ou extensão é uma boa separação do conteúdo do layout e uma tabela não? Obter um bom layout com apenas divs geralmente requer muitas divs aninhadas.

  • Legibilidade do código
    Eu acho que é o contrário. A maioria das pessoas entende HTML, poucas entendem CSS.

  • É melhor para o SEO não usar tabelas
    Por que? Alguém pode mostrar alguma evidência disso? Ou uma declaração do Google de que as tabelas são desencorajadas da perspectiva de SEO?

  • As mesas são mais lentas.
    Um elemento tbody extra deve ser inserido. Este é um amendoim para navegadores modernos. Mostre-me alguns benchmarks em que o uso de uma tabela diminui significativamente a página.

  • Uma revisão de layout é mais fácil sem tabelas, consulte o css Zen Garden .
    A maioria dos sites que precisam de atualização também precisa de novo conteúdo (HTML). Cenários em que uma nova versão de um site precisa apenas de um novo arquivo CSS não são muito prováveis. Zen Garden é um site legal, mas um pouco teórico. Sem mencionar o uso indevido de CSS.

Estou realmente interessado em bons argumentos para usar divs + CSS em vez de tabelas.


Concordado, as tabelas são boas ao apresentar dados tabulares. Eles devem ser evitados ao usá-lo apenas para o layout. Então, novamente, às vezes, você precisa seguir o caminho mais fácil agora e melhorá-lo mais tarde. Basta ver a fonte e você verá o que quero dizer.
hackeado


11
A resposta é simples: depende. Se as tabelas são usadas para resolver um problema específico que as versões atuais do CSS não conseguem, elas são bem usadas. Se você começar a colocar tabelas dentro de tabelas, dentro de milhões de tabelas, estará fazendo errado. Se for a tabela ocasional apenas para o layout de duas colunas ou algo parecido, não a desaprovo na minha equipe: é mais rápido e fácil fazê-lo. (Eu, pessoalmente, sempre tentar usar CSS, mas no final do dia, a entrega é mais importante do que HTML semântica correta)
ALFATEK

1
@Camilo SO ainda vive no século XX. Jeff aparentemente não sabe como usar a ultag. Veja todas as listas deste site (crachás, perguntas relacionadas, tags recentes). São todas colunas únicas ou parágrafos longos separados por br.
Yi Jiang

2
@ Brad: Dependendo de alguns detalhes específicos (esse é o meu ponto de partida para qualquer retorno inteligente ;-); o uso de DIVs AINDA é melhor do que abusar de tabelas. Duas partes de um documento que são dispostas lado a lado podem legitimamente estar contidas nos elementos DIV, mas certamente não são dados tabulares. Não importa qual seja um estilo específico; o conteúdo é tabular ou não. Nota: Eu não estou defendendo DIVitis quer :)
Bobby Jack

Respostas:


496

Vou examinar seus argumentos um após o outro e tentar mostrar os erros neles.

É bom separar o conteúdo do layout. Mas esse é um argumento falacioso; Pensamento Clichê.

Não é falacioso porque o HTML foi projetado intencionalmente. O uso indevido de um elemento pode não estar completamente fora de questão (afinal, novos idiomas também se desenvolveram em outros idiomas), mas possíveis implicações negativas precisam ser contrabalançadas. Além disso, mesmo que não haja argumentos contra o uso indevido do <table>elemento hoje, pode haver amanhã devido à maneira como os fornecedores de navegadores aplicam tratamento especial ao elemento. Afinal, eles sabem que “os <table>elementos servem apenas para dados tabulares” e podem usar esse fato para melhorar o mecanismo de renderização, alterando sutilmente como <table>se comporta e, assim, quebrando casos em que ele foi mal utilizado anteriormente.

E daí? Meu chefe se importa? Meus usuários se importam?

Depende. Seu chefe é de cabelos pontudos? Então ele pode não se importar. Se ela for competente, ela se importará, porque os usuários o farão .

Talvez eu ou meus colegas desenvolvedores que precisamos manter um cuidado com a página da web ... A tabela é menos sustentável? Eu acho que usar uma tabela é mais fácil do que usar divs e css.

A maioria dos desenvolvedores profissionais da Web parece se opor a você[ citação necessária ] . Que as tabelas sejam de fato menos sustentáveis ​​deve ser óbvia. Usar tabelas para o layout significa que alterar o layout corporativo na verdade significa alterar todas as páginas. Isso pode ser muito caro. Por outro lado, o uso criterioso de HTML semântico significativo combinado com CSS pode limitar essas alterações ao CSS e às imagens usadas.

A propósito ... por que o uso de uma div ou extensão é uma boa separação do conteúdo do layout e uma tabela não? Obter um bom layout com apenas divs geralmente requer muitas divs aninhadas.

<div>S profundamente aninhados são um antipadrão, assim como layouts de tabela. Bons web designers não precisam de muitos deles. Por outro lado, mesmo esses divs profundamente aninhados não têm muitos dos problemas de layouts de tabela. De fato, eles podem até contribuir para uma estrutura semântica dividindo logicamente o conteúdo em partes.

Legibilidade do código Eu acho que é o contrário. A maioria das pessoas entende html, pouco entende css. É mais simples.

"A maioria das pessoas" não importa. Profissionais importam. Para os profissionais, os layouts de tabela criam muito mais problemas do que HTML + CSS. É como dizer que não devo usar o GVim ou o Emacs porque o Notepad é mais simples para a maioria das pessoas. Ou que eu não deveria usar o LaTeX porque o MS Word é mais simples para a maioria das pessoas.

É melhor para o SEO não usar tabelas

Não sei se isso é verdade e não usaria isso como argumento, mas seria lógico. Os mecanismos de pesquisa pesquisam dados relevantes . Embora os dados tabulares possam, é claro, ser relevantes, raramente é o que os usuários pesquisam. Os usuários pesquisam os termos usados ​​no título da página ou em posições de destaque semelhantes. Portanto, seria lógico excluir o conteúdo tabular da filtragem e, assim, reduzir o tempo de processamento (e os custos!) Por um grande fator.

As mesas são mais lentas. Um elemento tbody extra deve ser inserido. Este é um amendoim para navegadores modernos.

O elemento extra não tem nada a ver com as tabelas serem mais lentas. Por outro lado, o algoritmo de layout para tabelas é muito mais difícil, o navegador geralmente precisa aguardar o carregamento de toda a tabela antes de começar a planejar o layout do conteúdo. Além disso, o cache do layout não funcionará (o CSS pode ser facilmente armazenado em cache). Tudo isso foi mencionado antes.

Mostre-me alguns benchmarks em que o uso de uma tabela diminui significativamente a página.

Infelizmente, não tenho dados de referência. Eu mesmo estaria interessado, porque é certo que esse argumento carece de um certo rigor científico.

A maioria dos sites que precisam de atualização também precisa de novo conteúdo (html). Cenários em que uma nova versão de um site precisa apenas de um novo arquivo css não são muito prováveis.

De modo nenhum. Já trabalhei em vários casos em que a alteração do design foi simplificada por uma separação de conteúdo e design. Muitas vezes ainda é necessário alterar algum código HTML, mas as alterações sempre serão muito mais limitadas. Além disso, as alterações de design devem, ocasionalmente, ser feitas dinamicamente. Considere mecanismos de modelo como o usado pelo sistema de blogs WordPress. Os layouts de tabela literalmente matariam esse sistema. Eu trabalhei em um caso semelhante para um software comercial. Ser capaz de alterar o design sem alterar o código HTML era um dos requisitos de negócios.

Outra coisa. O layout da tabela torna a análise automatizada de sites (raspagem de tela) muito mais difícil. Isso pode parecer trivial porque, afinal, quem faz isso? Eu me surpreendi. A raspagem de tela pode ajudar muito se o serviço em questão não oferecer uma alternativa de WebService para acessar seus dados. Estou trabalhando em bioinformática, onde essa é uma triste realidade. Técnicas modernas da Web e serviços da Web não alcançaram a maioria dos desenvolvedores e, muitas vezes, a captura de tela é a única maneira de automatizar o processo de obtenção de dados. Não é de admirar que muitos biólogos ainda realizem essas tarefas manualmente. Para milhares de conjuntos de dados.


139
"alterar o layout corporativo na verdade significa alterar todas as páginas" - As pessoas ainda duplicam o layout corporativo em todas as páginas? É tão fácil resolver com páginas mestras ou controles de usuário em .net, incluir arquivos em php ou asp clássico, etc ... Qualquer pessoa que copie o layout da empresa assim merece um chute a **! ;-)
John MacIntyre

43
Desculpe, mas isso é realmente "torta no céu". Os usuários se importam? Não. Ninguém se importa, exceto um pequeno número de revisionistas equivocados. O HTML (incluindo tabelas) é muito mais antigo que a noção relativamente nova de "semântica versus layout". Ah, e fonte para "a maioria dos desenvolvedores profissionais da web se opõe a você".
Cletus

20
Erro de digitação acima: a semântica estava implícita desde o início. <table> em HTML sempre foi feito apenas para dados tabulares, nunca para layout (nos primeiros anos, você não podia alterar a aparência da tabela de qualquer maneira, impedindo seu uso como uma âncora de layout). De fato, os primeiros rascunhos de HTML não tinham noção de layout, e o HTML nunca foi feito para layout, mas para estruturar texto. Ainda mais: a primeira proposta de HTML adverte repetidamente contra o abuso de tags para influenciar o layout e recomenda o uso de marcação lógica sobre física.
Konrad Rudolph

109
Obtenha um leitor de tela e leia uma página com um layout de tabela. isso é tudo.
Corymathews 26/07/09

8
@Sergio: por favor, não edite informações relevantes. Esta é uma afirmação dúbia sem fonte que estou usando lá e quero deixar isso bem claro. Sua edição colocou na minha boca uma alegação de que não posso fazer backup, efetivamente me tornando uma mentirosa, se isso for falso.
Konrad Rudolph

290

Aqui está a resposta do meu programador a partir de um tópico semelhante

Semântica 101

Primeiro, dê uma olhada neste código e pense sobre o que há de errado aqui ...

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

O problema, é claro, é que uma bicicleta não é um carro. A classe de carro é uma classe inadequada para a instância da bicicleta. O código está livre de erros, mas está semanticamente incorreto. Isso reflete mal no programador.

Semântica 102

Agora aplique isso à marcação do documento. Se o seu documento precisar apresentar dados tabulares, a tag apropriada seria <table>. Se você colocar a navegação em uma tabela, no entanto, estará abusando da finalidade do <table>elemento. No segundo caso, você não está apresentando dados tabulares - está (mis) usando o <table>elemento para atingir uma meta de apresentação.

Conclusão

Os visitantes perceberão? Não. Seu chefe se importa? Talvez. Às vezes cortamos cantos como programadores? Certo. Mas deveríamos? Não. Quem se beneficia se você usar marcação semântica? Você - e sua reputação profissional. Agora vá e faça a coisa certa.


39
Desculpe, isso não retém água. Você não usa carro para a minha moto porque, em vez disso, definiria uma classe de "bicicleta". Você não pode definir outra coisa para "<table>" porque é mais do que uma simples tag semântica - ela diz ao navegador como renderizar seu conteúdo também.
Jimmy Jimmy

57
Boa analogia e ótima conclusão. Por que alguém deveria ser forçado pelo chefe e / ou usuários a fazer a coisa certa? Ninguém mais se orgulha de seu próprio trabalho?
Sherm Pendley

39
Eu acho que este é um post bastante arrogante que não explica nada, mas apenas repete as mesmas afirmações novamente sem responder à pergunta. Eu não entendo por que recebeu tantos votos positivos ??
Markus

10
Eu concordo com tharkum. Essa resposta é bastante subjetiva e, na verdade, não responde à pergunta colocada. Embora eu concorde que os DIVs devam ser usados ​​para o layout da página, não consigo imaginar que qualquer web designer fique confuso com um layout baseado em tabela.
Richard Ev

16
@tharkun & Richard: Como é que "semanticamente incorreto" é subjetivo e não explica nada?
Vinko Vrsalovic

104

Resposta óbvia: Veja CSS Zen Garden . Se você me disser que pode facilmente fazer o mesmo com um layout baseado em tabela (lembre-se - o HTML não está mudando), use todos os meios para o layout.

Duas outras coisas importantes são acessibilidade e SEO.

Ambos se preocupam com a ordem em que as informações são apresentadas. Você não pode apresentar facilmente sua navegação na parte superior da página se o layout baseado em tabela a colocar na 3ª célula da 2ª linha da 2ª tabela aninhada na página.

Portanto, suas respostas são de manutenção, acessibilidade e SEO.

Não seja preguiçoso. Faça as coisas da maneira certa e correta, mesmo que sejam um pouco mais difíceis de aprender.


24
Um truque frequentemente usado no Zen Garden é substituir o texto por imagens e defini-lo no CSS, tornando-o invisível do HTML. Muito, muito errado.
GvS 17/09/08

3
Sinto muito, mas isso não está certo. O texto ainda está no HTML - esse é um dos requisitos de um design CSSZG. O HTML deve permanecer inalterado.
erlando

10
Se você observar atentamente alguns dos designs, o texto em alguns cabeçalhos será diferente do texto no HTML. Isso ocorre porque o HTML é invisível e, em vez disso, uma imagem é inserida. (Exemplo: csszengarden.com/?cssfile=/212/212.css&page=0 , o? Caminho? Para? Conquista?)
GvS 17/08/08

6
Desculpe, não há absolutamente nenhuma evidência de que os layouts de div sejam melhores para SEO. Além disso, o próprio Google afirmou que a validação HTML não importa para eles - um problema um pouco diferente, mas voltado para tabelas porque elas raramente são validadas.
DisgruntledGoat

“Muitos de vocês estão familiarizados com as virtudes de um programador. Existem três, é claro: preguiça, impaciência e arrogância. ” - Larry Wall
inkredibl

91

Veja esta pergunta duplicada.

Um item que você está esquecendo é a acessibilidade. Os layouts baseados em tabela não são traduzidos também se você precisar usar um leitor de tela, por exemplo. E se você trabalha para o governo, pode ser necessário oferecer suporte a navegadores acessíveis, como leitores de tela .

Eu também acho que você subestima o impacto de algumas das coisas que você mencionou na pergunta. Por exemplo, se você é o designer e o programador, pode não ter uma avaliação completa de quão bem ela separa a apresentação do conteúdo. Mas quando você entra em uma loja onde eles têm dois papéis distintos, as vantagens começam a ficar mais claras.

Se você sabe o que está fazendo e possui boas ferramentas, o CSS realmente possui vantagens significativas sobre as tabelas de layout. E embora cada item por si só possa não justificar o abandono de tabelas, em conjunto, geralmente vale a pena.


Sim, de fato. Eu vejo que é duplicado. Perdi. Alguma ação necessária além de prometer que terei mais cuidado da próxima vez :-)?
Benno Richters

Não se preocupe. Isso será cada vez mais comum à medida que o número de perguntas aumentar. Eu nem sequer votei. Nós apenas queremos ter certeza de que, o máximo possível, todos eles apontem para uma fonte comum.
Joel Coehoorn

8
Eu realmente gosto desta resposta. O uso de tags semanticamente significativas não é apenas uma questão de tradição, permite que aqueles que não são navegadores obscuros (leitores de tela, raspadores de tela, vários analisadores) categorizem corretamente os vários objetos da sua página.
Fantasma Watson

6
Eu esperava que alguém mencionasse isso. A acessibilidade deve ser uma prioridade!
Andrew

Não posso dizer que concordo com a noção de que a acessibilidade deve ser uma prioridade em um exercício comercial. A relação custo-benefício não é viável. É como colocar uma rampa para cadeira de rodas em uma loja de escalada - um desperdício ridículo de recursos que poderia ser aplicado a itens com melhor RBC. Se você estava falando de uma instalação médica, uma rampa para cadeira de rodas seria uma prioridade. Da mesma forma, eu me preocuparia apenas com a acessibilidade de páginas da Web para sites direcionados a pessoas com deficiência visual.
quer

54

Infelizmente, o CSS Zen Garden não pode mais ser usado como um exemplo de bom design HTML / CSS. Praticamente todos os designs recentes usam gráficos para o cabeçalho da seção. Esses arquivos gráficos são especificados no CSS.

Portanto, um site cujo objetivo é mostrar a vantagem de manter o design fora do conteúdo, agora compromete regularmente o PECADO INESPERÁVEL de colocar conteúdo no design. (Se o cabeçalho da seção no arquivo HTML fosse alterado, o cabeçalho da seção exibido não mudaria).

O que só mostra que mesmo aqueles que defendem a religião estrita do DIV e CSS, não podem seguir suas próprias regras. Você pode usar isso como uma diretriz para o quanto você os segue.


18
Você quer dizer que eles estão fazendo <h1>Some Text</h1>e depois no CSS h1 { background-image('foo.jpg'); text-indent:-3000px }:? Essa é a maneira correta de fazer isso, porque você está retendo o máximo de informações semânticas no html sem estilo. Ou talvez eu tenha te entendido mal.
Karan

9
Karen está certa, você está errada, James. Seu exemplo é um homem de palha. Esquecer de alterar a imagem quando você alterou o HTML semântico seria estúpido. Então, está deixando o seu laptop em um ônibus. Onde você quer chegar?
AmbroseChapel 27/03/09

36
@ Ambrose: Porque o objetivo principal do site é demonstrar a separação entre conteúdo e estilo. O Conteúdo e o Estilo devem ser tratados adequadamente por pessoas diferentes, nenhuma das quais deve "lembrar" o que a outra mudou.
James Curran

5
Sr. S&N: isso tornaria as coisas ainda piores. Você precisaria gerar dinamicamente novas imagens - no estilo correto. Então agora você mudou o estilo do CSS para o código da camada de negócios.
James Curran

9
@ James: Conteúdo e estilo nem sempre podem ser manipulados por pessoas diferentes. Quando o conteúdo é estilizado, a colaboração deve ocorrer. Como é <h1><img src="something.png"></h1>mais sustentável que <h1 class="something image">Something</h1>? Nos dois exemplos, algo.png precisa ser atualizado. Mas o segundo exemplo é muito mais acessível.
Josh

48

Este não é o argumento definitivo, por qualquer meio, mas com CSS você pode pegar a mesma marcação e alterar o layout dependendo da mídia, o que é uma boa vantagem. Para uma página impressa, você pode suprimir silenciosamente a navegação sem precisar criar uma página para impressão, por exemplo.


Bom ponto, embora você possa usar css para ocultar células em um layout baseado em tabela, para suprimir a navegação em uma versão imprimível, por exemplo, um layout CSS oferece muito mais flexibilidade por trás da simples ocultação de dados.
Cory House

Eu bati isso com um dos meus aplicativos; menino, fiquei feliz quando percebi como era fácil criar a versão "amigável para impressão" com apenas alguns CSS impressos para as mesmas páginas que estavam na tela.
Lawrence Dol

45

Uma tabela para o layout não seria tão ruim. Mas você não pode obter o layout necessário em apenas uma tabela na maioria das vezes. Em breve, você terá 2 ou três tabelas aninhadas. Isso se torna muito complicado.

  • É MUITO mais difícil de ler. Isso não é de opinião. Há apenas mais tags aninhadas sem marcas de identificação.

  • Separar o conteúdo da apresentação é uma coisa boa, pois permite que você se concentre no que está fazendo. Misturar os dois leva a páginas inchadas que são difíceis de ler.

  • CSS para estilos permite que seu navegador armazene em cache os arquivos e as solicitações subsequentes são muito mais rápidas. Isso é ENORME.

  • As tabelas prendem você a um design. Claro, nem todo mundo precisa da flexibilidade do CSS Zen Garden, mas nunca trabalhei em um site em que não precisei mudar um pouco o design aqui e ali. É muito mais fácil com CSS.

  • As mesas são difíceis de estilizar. Você não tem muita flexibilidade com eles (ou seja, você ainda precisa adicionar atributos HTML para controlar totalmente os estilos de uma tabela)

Eu não usei tabelas para dados não tabulares em provavelmente 4 anos. Eu não olhei para trás.

Eu realmente gostaria de sugerir a leitura de CSS Mastery por Andy Budd. É fantástico.

Imagem em ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg


1
Posso altamente recomen este livro
Jacob T. Nielsen

Contém bons exemplos de modelo de caixa, seletores e posicionamento.
KMAN

36

É bom separar o conteúdo do layout.
Mas esse é um argumento falacioso; Pensamento clichê

É um argumento falacioso, porque as tabelas HTML são layout! O conteúdo são os dados na tabela, a apresentação é a própria tabela. É por isso que separar CSS de HTML pode ser muito difícil às vezes. Você não está separando o conteúdo da apresentação, está separando a apresentação da apresentação! Uma pilha de divs aninhados não é diferente de uma tabela - é apenas um conjunto diferente de tags.

O outro problema ao separar o HTML do CSS é que eles precisam de um conhecimento íntimo um do outro - você realmente não pode separá-los completamente. O layout da tag no HTML está fortemente associado ao arquivo CSS, não importa o que você faça.

Acho que tabelas vs divs se resumem às necessidades do seu aplicativo.

No aplicativo que desenvolvemos no trabalho, precisávamos de um layout de página em que as peças se dimensionassem dinamicamente para seu conteúdo. Passei dias tentando fazer isso funcionar em vários navegadores com CSS e DIVs e foi um pesadelo completo. Mudamos para mesas e tudo funcionou .

No entanto, temos um público muito fechado para o nosso produto (vendemos um hardware com uma interface da Web) e os problemas de acessibilidade não são uma preocupação para nós. Não sei por que os leitores de tela não conseguem lidar bem com as tabelas, mas acho que se é assim, os desenvolvedores precisam lidar com isso.


6
screenreaders lida com tabelas ok .. É o problema das tabelas não lidar com screenreaders. Um layout baseado em tabela é propenso a apresentar as informações de maneira inacessível. Pense em como seria uma navegação do lado direito. Seria bem abaixo da página.
erlando 17/09/08

Ok, isso faz sentido então - obrigado!
17 de 26

8
Só porque <table> ou <div> têm uma apresentação padrão na maioria dos agentes de tela, não os iguala a serem elementos de apresentação em vez de elementos semânticos.
Mark Brackett

1
Não estou falando especificamente de HTML, estou falando conceitualmente no design básico da interface do usuário. Uma tabela determina como as coisas são dispostas na tela, ou seja, como elas são apresentadas ao usuário. Isso é apresentação.
17 de 26

1
"Passei dias tentando fazer com que isso funcionasse" - se algo que estou tentando descobrir leva mais de algumas horas, eu o coloco na comunidade StackOverflow. Não saber fazer algo corretamente não é desculpa para não fazê-lo corretamente. Especialmente quando temos todas as respostas na ponta dos dedos.
DaveDev

23

CSS / DIV - são apenas trabalhos para os garotos do design, não é? As centenas de horas que passei depurando problemas de DIV / CSS, pesquisando na Internet para obter parte da marcação trabalhando com um navegador obscuro - isso me deixa louco. Você faz uma pequena alteração e todo o layout dá terrivelmente errado - onde a lógica é essa. Passar horas movendo algo de 3 pixels dessa maneira e depois outros 2 pixels para alinhar todos eles. Isso apenas parece errado para mim de alguma forma. Só porque você é um purista e algo "não é a coisa certa a fazer" não significa que você deve usá-lo até o enésimo grau e sob todas as circunstâncias, especialmente se isso facilitar sua vida 1000 vezes.

Então eu finalmente decidi, puramente por motivos comerciais, embora eu use o mínimo possível, se eu antecipar 20 horas de trabalho para colocar um DIV corretamente, vou ficar em uma mesa. Está errado, perturba os puristas, mas na maioria dos casos custa menos tempo e é mais barato de gerenciar. Posso então me concentrar em fazer o aplicativo funcionar como o cliente deseja, em vez de agradar os puristas. Afinal, eles pagam as contas e meu argumento para um gerente que impõe o uso de CSS / DIV - eu apenas apontaria que os clientes pagam seu salário também!

A única razão pela qual todos esses argumentos CSS / DIV ocorrem é por causa da falta de CSS em primeiro lugar e porque os navegadores não são compatíveis entre si e, se fossem, metade dos web designers do mundo ficaria sem trabalho. .

Quando você cria um formulário do Windows, não tenta mover os controles depois de defini-los, então eu acho que é estranho para mim o motivo de você querer fazer isso com um formulário da Web. Simplesmente não consigo entender essa lógica. Obtenha o layout certo para começar e qual é o problema. Eu acho que é porque os designers gostam de flertar com a criatividade, enquanto os desenvolvedores de aplicativos estão mais preocupados em realmente fazer com que o aplicativo funcione, criando objetos de negócios, implementando regras de negócios, calculando a forma como os bits de dados dos clientes se relacionam entre si, garantindo que as coisas atendam aos clientes requisitos - você sabe - como as coisas do mundo real.

Não me interpretem mal, os dois argumentos são válidos, mas não critique os desenvolvedores por escolher uma abordagem mais fácil e lógica para criar formulários. Muitas vezes temos coisas mais importantes com que nos preocupar do que a semântica correta de usar uma tabela sobre uma div.

Caso em questão - com base nessa discussão, converti alguns tds e trs existentes em divs. 45 minutos brincando com isso tentando alinhar tudo ao lado do outro e eu desisti. Os TDs voltam em 10 segundos depois - funcionam - imediatamente - em todos os navegadores, nada mais a fazer. Por favor, tente me fazer entender - que justificativa você tem para querer que eu faça de outra maneira!


Não concordo mais com este post. Nos 10 anos em que estou no design, não consigo pensar em uma única vez em que o argumento "usamos CSS, porque facilita as mudanças em todo o site" seja tão preciso.
precisa

6
sabe o que facilita o gerenciamento de alterações em todo o site? Sistemas MVC e modelo
Jiaaro

Por favor, não me entenda mal - eu ainda uso CSS, mas eu o uso para aplicar estilo (cores, imagens de fundo e assim por diante) e não layout. O CSS parece ser bastante consistente entre os navegadores quando usado apenas para controlar o estilo. Onde ele falha e cai em grande parte é a maneira pela qual o layout é especificado e implementado nos navegadores. Alguém já tentou fazer com que o ASP.NET MasterPages funcionasse de maneira confiável com DIVs? É quase impossível!
Tim Black

21

O layout deve ser fácil. O fato de haver artigos escritos sobre como obter um layout dinâmico de três colunas com cabeçalho e rodapé em CSS mostra que é um sistema de layout ruim. É claro que você pode fazê-lo funcionar, mas existem literalmente centenas de artigos on-line sobre como fazê-lo. Não existem artigos desse tipo para um layout semelhante com tabelas porque é óbvio. Não importa o que você diga em relação às tabelas e a favor do CSS, esse fato desfaz tudo: um layout básico de três colunas no CSS costuma ser chamado de "O Santo Graal".

Se isso não faz você dizer "WTF", então você realmente precisa interromper o kool-aid agora.

Eu amo CSS. Ele oferece opções de estilo incríveis e algumas ferramentas interessantes de posicionamento, mas como um mecanismo de layout é deficiente. Precisa haver algum tipo de sistema de posicionamento dinâmico da grade. Uma maneira direta de alinhar caixas em vários eixos sem conhecer primeiro seus tamanhos. Eu não dou a mínima se você chamar isso de <table> ou <gridlayout> ou qualquer outra coisa, mas esse é um recurso básico de layout que está faltando no CSS.

O maior problema é que, ao não admitir que faltam recursos, os fanáticos do CSS retiveram o CSS de tudo o que poderia ser. Eu ficaria perfeitamente feliz em parar de usar tabelas se o CSS fornecesse um posicionamento decente da grade de vários eixos, como basicamente todos os outros mecanismos de layout do mundo. (Você percebe que esse problema já foi resolvido muitas vezes em vários idiomas por todos, exceto o W3C, certo? E ninguém mais negou que esse recurso fosse útil.)

Suspiro. Chega de ventilação. Vá em frente e enfie a cabeça na areia.


Os "fanáticos por CSS" (como você diz) não ignoram esse fato. A próxima especificação CSS não possui apenas uma, mas duas soluções para corrigir os problemas com layouts em CSS. Layouts de modelos: w3.org/TR/css3-layout e posicionamento de grade: w3.org/TR/css3-grid Isso não apresenta especificações concorrentes. As duas especificações realmente se complementam. No momento em que escrevemos esse comentário, nenhum navegador o implementou ainda.
Dan Herbert

+1: eu concordo completamente. Você não deveria "fazê-lo funcionar" (embora eu também não goste de tabelas).
3lectrologos

Isso é 100% exatamente como eu me sinto. Eu gostaria de poder votar você na melhor resposta.
bobwienholt

19

De acordo com a conformidade 508 (para leitores de tela para transmissão visual), as tabelas devem ser usadas apenas para armazenar dados e não para o layout, pois isso causa surtos nos leitores de tela. Ou assim me disseram.

Se você atribuir nomes a cada um dos divs, também poderá usá-los usando CSS. Eles são um pouco mais difíceis de se sentar do jeito que você precisa.


18

Aqui está uma seção do html de um projeto recente:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

E aqui está o mesmo código que um layout baseado em tabela.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

A única limpeza que vejo nesse layout baseado em tabela é o fato de eu ser excessivamente zeloso com meu recuo. Tenho certeza de que a seção de conteúdo teria mais duas tabelas incorporadas.

Outra coisa a se pensar: o tamanho do arquivo . Descobri que os layouts baseados em tabela têm o dobro do tamanho de suas contrapartes CSS normalmente. Em nossa banda larga de alta velocidade, esse não é um grande problema, mas é para aqueles com modems dial-up.


3
a velocidade não é a única coisa prejudicada por arquivos maiores: muitas empresas pagam pela largura de banda. Se você pode cortar pela metade as contas de largura de banda do seu cliente, simplesmente codificando bem, é uma grande vantagem.
Mr. Shiny and New

2
Sim, mas não esqueça que, embora o HTML possa ser duas vezes maior em um layout sem CSS, o uso de um layout DIV + CSS resultará em (pelo menos) uma solicitação HTTP extra para o arquivo CSS, além do uso da largura de banda para o próprio arquivo.
2029 goldenratio

12
Mas o arquivo css precisa ser baixado apenas uma vez, onde toda a estrutura da tabela é reenviada em cada solicitação de página.
User151841

3
Você escolheu um design adequado para div + css e mostrou que é mais detalhado em um design baseado em tabela? E daí: seria igualmente fácil criar um design adequado ao layout baseado em tabela e mostrar os bastidores que você precisaria pular para replicá-lo no CSS.
Draemon

4
@ Demra: Talvez você queira dar um exemplo?
Bobby Jack

14

Gostaria de acrescentar que os layouts baseados em div são mais fáceis de manter, evoluir e refatorar. Apenas algumas mudanças no CSS para reordenar elementos e está feito. Pela minha experiência, redesenhar um layout que usa tabelas é um pesadelo (mais se houver tabelas aninhadas).

Seu código também tem um significado do ponto de vista semântico .


Meu sonho é ter um designer gráfico que leva os objetos / dados que fornecem e colocá-los em uma página sem eu ter que se preocupam com CSS, DIV, TABLE ... :)
Manrico Corazzi

Em segundo lugar, Manrico - um designer visual que permitiria criar um layout e definir dimensões fixas e percentuais e depois gerar HTML e CSS mínimos seria extremamente útil!
Richard Ev

O problema que tenho com o conceito de web semântica é que no HTML 4 o vocabulário é muito limitado e projetado para documentos principalmente técnicos. Muitos sites com objetivos comerciais / de marketing podem ter elementos que não se encaixam perfeitamente nesse vocabulário. O HTML 5 corrige parte disso com tags como nav, header, footer, mas por enquanto estamos presos a tags como span, que na verdade dizem muito pouco sobre como o conteúdo deve ser interpretado.
Nick Van Brunt

13

Nenhum argumento nas divs me favorece.

Eu diria: Se o sapato se encaixar, use-o.

Vale a pena notar que é difícil, senão impossível, encontrar um bom método DIV + CSS de renderização de conteúdo em duas ou três colunas, que seja consistente em todos os navegadores e ainda tenha a aparência que eu pretendia.

Isso ajuda a equilibrar um pouco as tabelas na maioria dos meus layouts, e embora eu me sinta culpado de usá-las (por que, as pessoas dizem que é ruim, então eu tento ouvi-las), no final, a visão pragmática é que é apenas mais fácil e rápido para eu usar TABLEs. Eu não estou sendo pago por hora, então as mesas são mais baratas para mim.


1
Se você deseja criar um site de duas ou três colunas com divs + css que funcione em todos os navegadores, não deve começar do zero. Existem muitos modelos de barebone disponíveis na web que você pode usar como base. Aqueles são geralmente otimizado para displya corretamente em todos os navegadores IE6 +
arturh

13

Os layouts de CSS geralmente são muito melhores para acessibilidade, desde que o conteúdo seja natural e faça sentido sem uma folha de estilo. E não são apenas os leitores de tela que sofrem com os layouts baseados em tabelas: eles também tornam muito mais difícil para os navegadores móveis renderizarem uma página corretamente.

Além disso, com um layout baseado em div, você pode facilmente fazer coisas legais com uma folha de estilo de impressão, como excluir cabeçalhos, rodapés e navegação de páginas impressas - acho que seria impossível, ou pelo menos muito mais difícil, fazer isso com um layout baseado em tabela.

Se você está duvidando que a separação do conteúdo do layout seja mais fácil com divs do que com tabelas, dê uma olhada no HTML baseado em div no CSS Zen Garden , veja como alterar as folhas de estilo pode alterar drasticamente o layout e pense se você poderia obtenha a mesma variedade de layouts se o HTML for baseado em tabela ... Se você estiver criando um layout baseado em tabela, é improvável que esteja usando CSS para controlar todo o espaçamento e preenchimento nas células (se estiver, quase certamente acharia mais fácil usar divs flutuantes etc. em primeiro lugar). Sem usar o CSS para controlar tudo isso, e devido ao fato de as tabelas especificarem a ordem da esquerda para a direita e de cima para baixo no HTML, as tabelas tendem a significar que seu layout se torna muito fixo no HTML.

Realisticamente, acho muito difícil alterar completamente o layout de um design baseado em div e CSS sem alterar um pouco os divs. No entanto, com um layout baseado em div e CSS, é muito mais fácil ajustar coisas como o espaçamento entre vários blocos e seus tamanhos relativos.


13

O fato de ser uma questão muito debatida é uma prova do fracasso do W3C em antecipar a diversidade de projetos de layout que seriam tentados. Usar divs + css para um layout semanticamente amigável é um ótimo conceito, mas os detalhes da implementação são tão falhos que na verdade limitam a liberdade criativa.

Tentei mudar um dos sites da nossa empresa de tabelas para divs, e foi uma dor de cabeça que acabei com as horas de trabalho que dediquei a ele e voltei para as tabelas. Tentar lutar com meus divs para obter o controle do alinhamento vertical me amaldiçoou com grandes problemas psicológicos que nunca vou abalar enquanto esse debate continuar.

O fato de as pessoas frequentemente apresentarem soluções alternativas complexas e feias para atingir objetivos simples de design (como alinhamento vertical) sugere fortemente que as regras não são suficientemente flexíveis. Se as especificações SÃO suficientes, por que sites de alto perfil (como SO) consideram necessário dobrar as regras usando tabelas e outras soluções alternativas?


12

Eu acho que é verdade que o uso do elemento de tabela para o layout tem pouco a ver com dados tabulares. E daí? Meu chefe se importa? Meus usuários se importam?

Outros sistemas automatizados Google e fazer o cuidado, e eles são tão importante em muitas situações. O código semântico é mais fácil para um sistema não inteligente analisar e processar.


Sim, por exemplo, para blogs, o mecanismo separa os comentários da postagem do blog. Imagine que o layout tenha um estilo com tabelas ..
Omar Abid 08/02

2
-1: o Google absolutamente não se importa nem um pouco se você usa tabelas para o layout.
Tom Anderson

@ Tom Anderson Não porque eles tenham problemas com o uso de tabelas para layout, mas simplesmente porque o HTML que não é de tabela tende a ser mais semântico.
precisa

8

Tendo trabalhado com um site que envolvia 6 camadas de tabelas aninhadas geradas por algum aplicativo e gerou HTML inválido, foi de fato um trabalho de 3 horas corrigi-lo para uma pequena alteração.

É claro que esse é o caso extremo, mas o design baseado em tabela é insustentável. Se você usa css, separa o estilo; portanto, ao corrigir o HTML, você tem menos com o que se preocupar em quebrar.

Além disso, tente isso com JavaScript. Mova uma única célula da tabela de um local para outro local em outra tabela. Bastante complicado de executar, onde o div / span funcionaria apenas para copiar e colar.

"Meu chefe se importa"

Se eu fosse seu chefe. Você se importaria. ;) Se você valoriza sua vida.


Ter tido que trabalhar com um site que tinha uma enorme sopa de tags span e div e testemunhar sua fragilidade ao alterar um único elemento quebraria a página inteira (e divs usava em vez de tags de cabeçalho) ...
inkredibl

Usar Div's obviamente não torna seu código magicamente melhor. Muito deve ser dito sobre o uso semântico apropriado de tags.
Kent Fredric

7

Flexibilidade de layout
Imagine que você está criando uma página com um grande número de miniaturas.
DIVs :
se você colocar cada miniatura em um DIV, flutuar para a esquerda, talvez 10 deles se encaixem em uma linha. Torne a janela mais estreita e o BAM - são 6 em uma fileira ou 2 ou, se necessário.
TABELA:
Você precisa dizer explicitamente quantas células estão seguidas. Se a janela for muito estreita, o usuário precisará rolar horizontalmente.

Manutenção A
mesma situação acima. Agora você deseja adicionar três miniaturas à terceira linha.
DIVs:
adicione-os. O layout será ajustado automaticamente.
TABELA: Cole as novas células na terceira linha. Opa! Agora, existem muitos itens lá. Corte um pouco dessa linha e coloque-os na quarta linha. Agora, existem muitos itens lá. Corte um pouco dessa linha ... (etc)
( Claro, se você estiver gerando linhas e células com scripts no servidor, isso provavelmente não será um problema. )


7

Eu acho que o barco navegou. Se você observar a direção que a indústria tomou, notará que CSS e padrões abertos são os vencedores dessa discussão. O que por sua vez significa para a maioria dos trabalhos html, com exceção dos formulários, os designers usarão divs em vez de tabelas. Eu tenho dificuldade com isso porque não sou um guru do CSS, mas é assim que é.


5

Além disso, não se esqueça, as tabelas não são bem renderizadas nos navegadores móveis. Claro, o iPhone tem um navegador excelente, mas nem todo mundo tem um iPhone. A renderização de tabela pode ser um amendoim para navegadores modernos, mas é um monte de melancias para navegadores móveis.

Pessoalmente, descobri que muitas pessoas usam <div>tags demais , mas com moderação elas podem ser extremamente limpas e fáceis de ler. Você menciona que as pessoas têm mais dificuldade de ler CSS do que tabelas; em termos de 'código' que talvez seja verdadeiro; mas em termos de leitura de conteúdo (exibição> fonte), é muito mais fácil entender a estrutura com folhas de estilo do que com tabelas.


Bom ponto que você tem lá; mas IMHO a interface do usuário para dispositivos móveis deve ser completamente diferente, levando em consideração as limitações de entrada.
Manrico Corazzi 17/09/08

Verdade; Por isso, às vezes, comecei a usar uma abordagem diferente. No modelo MVC, minha exibição aparece apenas dados brutos XML, ou seja, conteúdo. Em seguida, comece com outro modelo MVC em que os dados brutos xml = modelo; view = html / css; controlador = xsl. A folha de estilo XSL elimina dados desnecessários para dispositivos móveis.
Swati

5

Parece que você está acostumado a mesas e é isso. Colocar o layout em uma tabela limita apenas esse layout. Com o CSS, você pode mover os bits, dê uma olhada em http://csszengarden.com/ E não, o layout geralmente não requer muitas divs aninhadas.

Sem tabelas para layout e semântica adequada, o HTML é muito mais limpo e, portanto, mais fácil de ler. Por que alguém que não consegue entender o CSS deve tentar lê-lo? E se alguém se considera um desenvolvedor da Web, a boa compreensão do CSS é uma obrigação.

Os benefícios de SEO vêm da capacidade de ter o conteúdo mais importante na parte superior da página e de ter uma melhor proporção de conteúdo para marcação.

http://www.hotdesign.com/seybold/


5
  • Conformidade 508 - a capacidade de um leitor de tela entender sua marcação.
  • Aguardando renderização - as tabelas não são renderizadas no navegador até chegar ao final do </table>elemento.

Lembro-me de criar tabelas enormes anos atrás, nos dias de computadores mais lentos, e lembro-me de quando o código chegou, que os fez renderizar à medida que você avançava. IE6? IE4? Não me lembro, mas certamente mudou. Obviamente, isso é útil para dados tabulados, mas as tabelas de layout são estilizadas dentro de uma polegada de suas vidas, portanto, talvez a renderização progressiva seja menos útil, pois a tabela salta para acomodar o conteúdo recém-carregado.
IJW

5

A idéia toda sobre a marcação semântica é a separação da marcação e da apresentação, que inclui o layout.

As divs não estão substituindo tabelas, elas têm seu próprio uso na separação de conteúdo em blocos de conteúdo relacionado (,). Quando você não possui as habilidades e depende de tabelas, geralmente precisará separar seu conteúdo em células para obter o layout desejado, mas não precisará tocar na marcação para obter a apresentação ao usar a marcação semântica. Isso é realmente importante quando a marcação está sendo gerada, em vez de páginas estáticas.

Os desenvolvedores precisam parar de fornecer a marcação que implica o layout, para que aqueles que possuem as habilidades necessárias para apresentar o conteúdo possam continuar com nossos trabalhos, e os desenvolvedores não precisam voltar ao código para fazer alterações quando a apresentação precisar ser alterada.


4

Não se trata realmente de 'divs são melhores que tabelas para layout'. Alguém que entende CSS pode duplicar qualquer design usando 'tabelas de layout' de maneira bem direta. A verdadeira vitória é usar elementos HTML para o que eles servem. O motivo pelo qual você não usaria tabelas para dados não-tablulares é o mesmo motivo pelo qual não armazenam números inteiros como cadeias de caracteres - a tecnologia funciona muito mais facilmente quando você a usa para a finalidade para a qual é designada. Se alguma vez foi necessário usar tabelas para o layout (devido às falhas do navegador no início dos anos 90), certamente não é agora.


3

As ferramentas que usam layouts de tabela podem se tornar extraordinariamente pesadas devido à quantidade de código necessária para criar o layout. O Netweaver Portal da SAP, por padrão, usa TABLE para fazer o layout de suas páginas.

O portal SAP de produção no meu show atual tem uma home page cujo HTML pesa mais de 60K e tem sete tabelas de profundidade, três vezes na página. Adicione no Javascript, o uso indevido de 16 iframes com problemas de tabela semelhantes dentro deles, CSS excessivamente pesado etc., e a página terá mais de 5 MB.

Vale a pena dedicar algum tempo para diminuir o peso da página, para que você possa usar sua largura de banda para realizar atividades envolventes com os usuários.


3

Vale a pena descobrir CSS e divs para que a coluna de conteúdo central seja carregada e renderizada antes da barra lateral em um layout de página. Mas se você estiver com dificuldades para usar divs flutuantes para alinhar verticalmente um logotipo com algum texto de patrocínio, use a tabela e siga em frente com vida. A religião do jardim zen simplesmente não dá muito valor ao dinheiro.

A idéia de separar o conteúdo da apresentação é particionar o aplicativo para que diferentes tipos de trabalho afetem diferentes blocos de código. Na verdade, isso é sobre gerenciamento de mudanças. Mas os padrões de codificação só podem examinar o estado atual do código de maneira superficial.

O log de alterações de um aplicativo que depende dos padrões de codificação para "separar o conteúdo da apresentação" mostrará um padrão de alterações paralelas nos silos verticais. Se uma alteração no "conteúdo" é sempre acompanhada de uma alteração na "apresentação", qual o êxito do particionamento?

Se você realmente deseja particionar seu código produtivamente, use o Subversion e revise seus logs de alterações. Em seguida, use as técnicas de codificação mais simples - divs, tabelas, JavaScript, inclusões, funções, objetos, continuações, o que for - para estruturar o aplicativo para que as alterações se ajustem de maneira simples e confortável.


+1 nas duas primeiras frases.
Sean McMillan

3

Porque é HELL manter um site que usa tabelas e leva muito mais tempo para codificar. Se você tem medo de divs flutuantes, faça um curso neles. Eles não são difíceis de entender e são aproximadamente 100 vezes mais eficientes e um milhão de vezes menos complicados (a menos que você não os entenda - mas ei, bem-vindo ao mundo dos computadores).

Qualquer um que considere fazer seu layout com uma tabela melhor não espera que eu o mantenha. É a maneira mais idiota de renderizar um site. Graças a Deus, temos uma alternativa muito melhor agora. Eu nunca voltaria.

É assustador que algumas pessoas possam não estar cientes dos benefícios de tempo e energia da criação de um site usando ferramentas modernas.


3

As tabelas não são em geral mais fáceis ou mais fáceis de manter que o CSS. No entanto, existem alguns problemas de layout específicos em que as tabelas são realmente a solução mais simples e flexível.

O CSS é claramente preferível nos casos em que a marcação de apresentação e o CSS suportam o mesmo tipo de design, ninguém em sã consciência argumentaria que font -tags são melhores do que especificar tipografia em CSS, pois o CSS oferece o mesmo poder que font-tags, mas em de uma maneira muito mais limpa.

O problema com as tabelas, no entanto, é basicamente que o modelo de layout da tabela no CSS não é suportado no Microsoft Internet Explorer. Tabelas e CSS não são, portanto, equivalentes em poder. A parte que falta é a comportamento semelhante grade das tabelas, em que as bordas das células se alinham vertical e horizontalmente, enquanto as células ainda se expandem para conter seu conteúdo. Esse comportamento não é fácil de obter em CSS puro sem codificar algumas dimensões, o que torna o design rígido e quebradiço (contanto que tenhamos que oferecer suporte ao Internet Explorer - em outros navegadores, isso é facilmente alcançado usando display:table-cell).

Portanto, não é realmente uma questão de se tabelas ou CSS é preferível, mas é uma questão de reconhecer os casos específicos em que o uso de tabelas pode tornar o layout mais flexível.

O motivo mais importante para não usar tabelas é a acessibilidade. O http://www.w3.org/TR/WCAG10/ orienta as diretrizes de acessibilidade de conteúdo da Web, usando tabelas para layout. Se você está preocupado com a acessibilidade (e, em alguns casos, pode ser legalmente obrigado), você deve usar CSS mesmo que as tabelas sejam mais simples. Observe que você sempre pode criar o mesmo layout com CSS e com tabelas; isso pode exigir apenas mais trabalho.


3

Fiquei surpreso ao ver que alguns problemas ainda não estavam cobertos, então aqui estão meus 2 centavos, além de todos os pontos válidos apresentados anteriormente:

.1 CSS e SEO:

a) O CSS costumava ter um impacto muito significativo no SEO, permitindo posicionar o conteúdo da página onde você quiser. Alguns anos atrás, os Mecanismos de pesquisa davam uma ênfase significativa aos fatores "na página". Algo na parte superior da página foi considerado mais relevante para a página do que algo localizado na parte inferior. "Topo da página" para uma aranha significava "no início do código". Usando CSS, você pode organizar seu conteúdo rico em palavras-chave no início do código e ainda posicioná-lo onde quiser na página. Isso ainda é um pouco relevante, mas os fatores na página são cada vez menos importantes para o ranking da página.

b) Quando o layout é movido para CSS, a página HTML fica mais clara e, portanto, carrega mais rapidamente para um mecanismo de busca. (As aranhas não se incomodam em baixar arquivos CSS externos). O carregamento rápido de páginas é uma consideração importante de classificação para vários mecanismos de pesquisa, incluindo o Google

c) O trabalho de SEO geralmente exige testes e alterações, o que é muito mais conveniente com um layout baseado em CSS

.2. Conteúdo gerado:

Uma tabela é consideravelmente mais fácil de gerar programaticamente que o layout CSS equivalente.

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

Gerar uma tabela é simples e seguro. É independente e integra-se bem a qualquer modelo. Fazer o mesmo com CSS é consideravelmente mais difícil e pode não ter nenhum benefício: é difícil editar a folha de estilo CSS durante o vôo e adicionar o estilo embutido não é diferente de usar uma tabela (o conteúdo não é separado do layout).

Além disso, quando uma tabela é gerada, o conteúdo (em variáveis) já está separado do layout (no código), facilitando a modificação.

Essa é uma das razões pelas quais alguns sites muito bem projetados (SO, por exemplo) ainda usam layouts de tabela.

Obviamente, se os resultados precisarem ser analisados ​​por meio do JavaScript, divs valerá a pena.

.3 Teste de conversão rápida

Ao descobrir o que funciona para um público específico, é útil poder alterar o layout de várias maneiras para descobrir quais são os melhores resultados. Um layout baseado em CSS torna as coisas consideravelmente mais fáceis

.4. Soluções diferentes para problemas diferentes

As tabelas de layout geralmente são dissediadas porque "todo mundo sabe que divs e CSS" são o caminho a percorrer.

No entanto, permanece o fato de que as tabelas são mais rápidas de criar, mais fáceis de entender e mais robustas que a maioria dos layouts de CSS. (Sim, o CSS pode ser tão robusto, mas uma rápida olhada na rede em diferentes navegadores e resoluções de tela mostra que geralmente não é o caso)

Há muitas desvantagens nas mesas, incluindo manutenção, falta de flexibilidade ... mas não vamos jogar o bebê com a água do banho. Existem muitos usos profissionais para uma solução rápida e confiável.

Há algum tempo, tive que reescrever um layout CSS limpo e simples usando tabelas, porque uma parte significativa dos usuários usaria uma versão mais antiga do IE com um suporte muito ruim ao CSS

Eu, por exemplo, estou cansado e cansado da reação instintiva "Oh, não! Mesas para o layout!"

Quanto à multidão "não foi projetada para esse fim e, portanto, não deve ser usada dessa maneira", não é hipocrisia? O que você acha de todos os truques de CSS que você precisa usar para fazer com que o danado funcione na maioria dos navegadores? Eles foram feitos para esse fim?

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.