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

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.

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.

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.

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.

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.

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.

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.

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

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

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!

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.

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.

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.

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 .

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.

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.

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?

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.

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.

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

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

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.

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/

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

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.

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.

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.

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.

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.

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.

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?