ti-enxame.com

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

Parece ser a opinião geral que as 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 este é um argumento falacioso; pensamento clichê . Eu acho que é verdade que usar o elemento de tabela para 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 precisam manter um cuidado na página da Web ... Uma tabela é menos sustentável? Acho que usar uma tabela é mais fácil do que usar divs e CSS.

    By the way ... por que está usando um div ou uma extensão boa separação de conteúdo do layout e uma mesa não? Obter um bom layout apenas com divs geralmente requer muitos divs aninhados.

  • 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 quê? Alguém pode mostrar alguma evidência de que é? Ou uma declaração do Google de que as tabelas são desencorajadas de uma perspectiva de SEO?

  • Tabelas são mais lentas.
    Um elemento extra tbody deve ser inserido. Isso é um amendoim para navegadores modernos. Mostre-me alguns pontos de referência em que o uso de uma tabela atrasa significativamente uma página.

  • Uma revisão de layout é mais fácil sem tabelas, veja css Zen Garden .
    A maioria dos sites que precisam de atualização também precisam 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 de Nice, mas um pouco teórico. Sem mencionar o seu so indevido de CSS.

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

665
Benno Richters

Eu vou passar por 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; Cliché Thinking.

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 outras línguas), mas possíveis implicações negativas devem ser contrabalançadas. Além disso, mesmo que não haja argumentos contra o uso indevido do elemento <table> hoje, pode haver um futuro devido à maneira como os fornecedores de navegadores aplicam tratamento especial ao elemento. Afinal, eles sabem que “os elementos <table> são apenas para dados tabulares” e podem usar esse fato para melhorar o mecanismo de renderização, alterando sutilmente o comportamento de <table>s e, assim, quebrando casos em que ele foi usado incorretamente 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 é competente, então ela vai se importar, porque os usuários vontade .

Talvez eu ou meus colegas desenvolvedores que têm que manter um cuidado de página da web ... É uma tabela menos passível de manutenção? Eu acho que usar uma tabela é mais fácil do que usar divs e css.

A maioria dos desenvolvedores web profissionais parece se opor a você[ citação necessária ]. Aquelas tabelas são de fato menos sustentáveis ​​devem ser óbvias. Usar tabelas para layout significa que mudar o layout corporativo significará, na verdade, alterar todas as páginas. Isso pode ser muito caro. Por outro lado, o uso criterioso de HTML semanticamente significativo combinado com CSS pode confinar essas mudanças no CSS e nas imagens usadas.

By the way ... por que está usando um div ou uma extensão boa separação de conteúdo do layout e uma mesa não? Obter um bom layout apenas com divs geralmente requer muitos divs aninhados.

<div>s profundamente aninhados são um antipadrão, assim como os layouts de tabela. Bons web designers não precisam de muitos deles. Por outro lado, mesmo esses divs com aninhamento profundo não apresentam muitos dos problemas dos layouts de tabela. Na verdade, eles podem até contribuir para uma estrutura semântica dividindo logicamente o conteúdo em partes.

Legibilidade do código 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 tabelas 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

Eu não sei se isso é verdade e não usaria isso como um 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. Seria, portanto, lógico excluir o conteúdo tabular da filtragem e, assim, reduzir o tempo de processamento (e os custos!) Por um fator grande.

Tabelas são mais lentas. Um elemento extra tbody deve ser inserido. Isso é um amendoim para navegadores modernos.

O elemento extra não tem nada a ver com tabelas sendo mais lentas. Por outro lado, o algoritmo de layout para tabelas é muito mais difícil, o navegador geralmente tem que esperar que a tabela inteira seja carregada antes que possa começar a criar o layout do conteúdo. Além disso, o armazenamento em cache do layout não funcionará (o CSS pode ser facilmente armazenado em cache). Tudo isso foi mencionado antes.

Mostre-me alguns pontos de referência em que o uso de uma tabela atrasa significativamente uma página.

Infelizmente, não tenho dados de referência. Eu estaria interessado em mim, porque é certo que este argumento não tem um certo rigor científico.

A maioria dos sites que precisam de atualização também precisam 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. Eu trabalhei em vários casos em que a alteração do design foi simplificada por uma separação de conteúdo e design. Geralmente ainda é necessário alterar algum código HTML, mas as alterações sempre serão muito mais confinadas. Além disso, alterações de design devem, ocasionalmente, ser feitas dinamicamente. Considere os mecanismos de modelo, como aquele usado pelo sistema de blogs do WordPress. Layouts de tabelas 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 (captura de tela) muito mais difícil. Isso pode parecer trivial porque, afinal, quem faz isso? Eu me surpreendi. O screen scraping 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 esta é uma triste realidade. Técnicas web modernas e WebServices não atingiram 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 executem essas tarefas manualmente. Para milhares de conjuntos de dados.

497
Konrad Rudolph

Aqui está a resposta do meu programador de um thread simliar

Semântica 101

Primeiro, dê uma olhada neste código e pense no que está 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 do carro é uma classe inadequada para a instância da bicicleta. O código está livre de erros, mas é semanticamente incorreto. Isso reflete mal no programador.

Semântica 102

Agora, aplique isso na marcação do documento. Se o documento precisar apresentar dados tabulares, a tag apropriada será <table>. Se você colocar a navegação em uma tabela, no entanto, você está usando indevidamente o propósito pretendido do elemento <table>. No segundo caso, você não está apresentando dados tabulares - você está (mis) usando o elemento <table> para atingir uma meta de apresentação.

Conclusão

Os visitantes notarão? Não. Seu chefe se importa? Talvez. Nós às vezes cortamos cantos como programadores? Certo. Mas devemos nós? Não. Quem se beneficia se você usa marcação semântica? Você - e sua reputação profissional. Agora vá e faça a coisa certa.

290
Carl Camera

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

Duas outras coisas importantes são acessibilidade e SEO.

Ambas se importam 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 o colocar na terceira célula da segunda linha da segunda tabela aninhada na página.

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

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

104
erlando

Veja esta pergunta duplicada.

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

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 como ela separa a apresentação do conteúdo. Mas uma vez que você entra em uma loja onde eles são dois papéis distintos, as vantagens começam a se tornar mais claras.

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

91
Joel Coehoorn

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

Assim, um site cuja finalidade é mostrar a vantagem de manter o design fora do conteúdo, agora compromete regularmente o UNSPEAKABLE SIN 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 seria).

O que só serve para mostrar que mesmo aqueles que advogam a rigorosa religião DIV & CSS, não podem seguir suas próprias regras. Você pode usar isso como uma diretriz em quão perto você os segue.

54
James Curran

Este não é o argumento definitivo, por qualquer meio, mas com o CSS você pode pegar a mesma marcação e mudar o layout dependendo do meio, o que é uma boa vantagem. Para uma página de impressão, você pode suprimir silenciosamente a navegação sem ter que criar uma página de impressão amigável, por exemplo.

48
expedient

Uma tabela para o layout não seria tão ruim assim. Mas você não pode obter o layout que você precisa com apenas uma tabela na maioria das vezes. Logo você tem duas ou três tabelas aninhadas. Isso se torna muito complicado.

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

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

  • O CSS para estilos permite que o seu navegador armazene em cache os arquivos e os pedidos subsequentes são muito mais rápidos. Isso é enorme.

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

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

45
Ben Scheirman

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

É um argumento falacioso porque tabelas HTML são layout! O conteúdo é o 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, você 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 em separar o HTML do CSS é que eles precisam de conhecimento íntimo um do outro - você realmente não pode separá-los completamente. O layout da tag no HTML é fortemente acoplado ao arquivo CSS, não importa o que você faça.

Acho que tabelas vs divs se resume à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 como um navegador cruzado com CSS e DIVs, e foi um pesadelo completo. Nós mudamos para tabelas e tudo apenas trabalhado.

No entanto, temos um público muito fechado para o nosso produto (vendemos um hardware com uma interface web) e os problemas de acessibilidade não são uma preocupação para nós. Eu não sei porque os leitores de tela não podem lidar bem com tabelas, mas eu acho que se é assim, os desenvolvedores têm que lidar com isso.

36
17 of 26

CSS/DIV - são apenas empregos para os garotos de design, não é? As centenas de horas que passei depurando problemas de DIV/CSS, pesquisando na Internet para fazer com que parte da marcação funcione com um navegador obscuro - isso me deixa louco. Você faz uma pequena mudança e todo o layout fica terrivelmente errado - onde, na verdade, é a lógica disso. Passar horas movendo algo 3 pixels desta forma, então outra coisa 2 pixels o outro para fazer com que todos fiquem alinhados. Isso parece simplesmente errado para mim de alguma forma. Só porque você é um purista e algo "não é a coisa certa a se fazer" não significa que você deva utilizá-lo em 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 continue a usar o mínimo, se eu antecipar 20 horas de trabalho para obter um DIV colocado corretamente, eu vou ficar em uma mesa. É 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 quer, em vez de agradar aos puristas. Eles pagam as contas depois de tudo e meu argumento para um gerente impondo o uso de CSS/DIV - gostaria apenas de apontar os clientes pagam seu salário também!

A única razão pela qual todos esses argumentos CSS/DIV ocorrem é devido à deficiência de CSS e porque os navegadores não são compatíveis entre si e, se fossem, metade dos web designers do mundo estaria sem trabalho. .

Quando você cria um formulário do Windows, você não tenta mover os controles depois de colocá-los fora, então acho que é estranho para mim porque você gostaria de fazer isso com um formulário da web. Eu simplesmente não consigo entender essa lógica. Obter o layout certo para começar e qual é o problema. Eu acho que é porque os designers gostam de flertar com criatividade, enquanto os desenvolvedores de aplicativos estão mais preocupados em realmente fazer o aplicativo funcionar, criar objetos de negócios, implementar regras de negócios, descobrir como os dados dos clientes se relacionam, garantir que eles atendam aos clientes requisitos - você sabe - como as coisas do mundo real.

Não me entenda mal, ambos os argumentos são válidos, mas, por favor, não critique os desenvolvedores por escolherem uma abordagem mais fácil e lógica para projetar formulários. Geralmente, temos coisas mais importantes para nos preocupar do que a semântica correta de usar uma tabela sobre uma div.

Caso em questão - com base nesta discussão eu converti alguns tds e trs existentes em divs. 45 minutos brincando com ele tentando fazer com que tudo se alinhasse lado a lado e eu desisti. TDs de volta em 10 segundos depois - funciona - imediatamente - em todos os navegadores, nada mais a fazer. Por favor, tente me fazer entender - que possível justificativa você tem para querer que eu faça de outra maneira!

23
Tim Black

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 há literalmente centenas de artigos online sobre como fazê-lo. Não há praticamente nenhum desses artigos para um layout semelhante com tabelas porque é óbvio. Não importa o que você diz contra as tabelas e em favor do CSS, esse fato desfaz tudo: um layout básico de três colunas no CSS é frequentemente chamado de "O Santo Graal".

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

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

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

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

21
needlestack

De acordo com a conformidade com 508 (para leitores de tela com recursos visuais limitados), as tabelas devem ser usadas apenas para armazenar dados e não para layout, pois isso faz com que os leitores de tela se assustem. Ou então eu tenho dito.

Se você atribuir nomes a cada um dos divs, você pode descascá-los todos juntos usando CSS também. Eles são um pouco mais dolorosos para se sentar do jeito que você precisa deles.

19
Rob

Aqui está uma seção de 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 tabelas é o fato de que eu estou com excesso de zelo com meu recuo. Tenho certeza de que a seção de conteúdo teria mais duas tabelas incorporadas.

Outra coisa para pensar: filesizes. Descobri que os layouts baseados em tabelas têm o dobro do tamanho de suas contrapartes CSS normalmente. Na nossa banda larga de alta velocidade que não é um problema enorme, mas é naqueles com modems dial-up.

18
Ross

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

14
Guido

Os layouts CSS geralmente são muito melhores para acessibilidade, desde que o conteúdo venha em uma ordem natural e faça sentido sem uma folha de estilo. E não são apenas os leitores de tela que lutam com os layouts baseados em tabela: eles também dificultam muito para os navegadores de dispositivos móveis renderizar 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 exclusão de cabeçalhos, rodapés e navegação de páginas impressas - eu 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 de conteúdo do layout seja mais fácil com divs do que com tabelas, dê uma olhada no HTML baseado em div em CSS Zen Garden , veja como mudar as folhas de estilo pode mudar drasticamente o layout , e pense se você poderia conseguir a mesma variedade de layouts se o HTML fosse baseado em tabelas ... Se você está fazendo um layout baseado em tabela, é improvável que você esteja usando CSS para controlar todo o espaçamento e preenchimento na tabela. células (se você fosse, você 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 que as tabelas especificam a ordem da esquerda para a direita e de cima para baixo no HTML, as tabelas tendem a significar que o layout se torna muito fixo no HTML.

Realisticamente, acho muito difícil mudar completamente o layout de um design baseado em div e CSS sem alterar um pouco as 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
MB.

O fato de que esta é uma questão muito debatida é um testemunho do fracasso do W3C em antecipar a diversidade de designs de layout que seriam tentados. Usar o divs + css para um layout amigo da hora é um ótimo conceito, mas os detalhes da implementação são tão falhos que limitam a liberdade criativa.

Eu tentei mudar um dos sites da nossa empresa de mesas em divs, e foi uma dor de cabeça tão grande que eu descartei totalmente as horas de trabalho que eu havia colocado nele e voltei para as mesas. Tentar lutar com minhas divs para ganhar o controle do alinhamento vertical me amaldiçoou com grandes problemas psicológicos que eu nunca abalarei enquanto durar este debate.

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

13
DLH

Nenhum argumento em DIVs favorece de mim.

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

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

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

13
Radu094

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

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

12
ceejayoz

Tendo que trabalhar com um site que envolveu 6 camadas de tabelas aninhadas geradas por algum aplicativo e, se ele tivesse gerado HTML inválido, era na verdade um trabalho de 3 horas para corrigir a quebra de uma pequena alteração.

Este é, obviamente, o caso Edge, mas o design baseado em tabelas é insustentável. Se você usa css, você separa o estilo, então ao consertar o HTML você tem menos para se preocupar em quebrar.

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

"Meu chefe se importa"

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

8
Kent Fredric

flexibilidade do layout
Imagine que você está fazendo uma página com um grande número de miniaturas.
DIVs:
Se você colocar cada miniatura em um DIV, flutuou à esquerda, talvez 10 deles se encaixam em uma linha. Faça a janela mais estreita, e BAM - é 6 em linha, ou 2, ou quantos se encaixam.
TABELA:
Você tem que dizer explicitamente quantas células estão em uma linha. Se a janela é muito estreita, o usuário tem que rolar horizontalmente.

manutenibilidade
A mesma situação acima. Agora você deseja adicionar três miniaturas à terceira linha.
DIVs:
Adicione-os. O layout será ajustado automaticamente.
TABLE: Cole as novas células na terceira linha. Oops! Agora há muitos itens lá. Cortar alguns da linha e colocá-los na quarta linha. Agora há muitos itens lá. Cortar alguns daquela fileira ... (etc)
(Naturalmente, se você estiver gerando as linhas e células com scripts do lado do servidor, isso provavelmente não será um problema.)

7
Nathan Long

Eu acho que o barco navegou. Se você olhar a direção que a indústria tomou, você 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 em html, com exceção dos formulários, os designers usarão divs em vez de tabelas. Eu tenho dificuldade com isso porque eu não sou um guru CSS, mas é assim.

7
Thomas Wagner

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

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

5
Swati

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

Sem tabelas para layout e semântica adequada, o HTML é muito mais limpo, portanto, mais fácil de ler. Por que alguém que não entende CSS tenta lê-lo? E se alguém se considera webdeveloper, então 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 no topo da página e ter uma melhor relação entre conteúdo e marcação.

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

5
Rimantas

Toda a ideia em torno da marcação semântica é a separação de marcação e apresentação, que inclui layout.

Div não estão substituindo tabelas, eles têm seu próprio uso na separação de conteúdo em blocos de conteúdo relacionado (,). Quando você não tem as habilidades e está confiando nas tabelas, muitas vezes terá que 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 marcação que implique layout para que aqueles de nós que tenham as habilidades para apresentar conteúdo possam continuar com nossos trabalhos, e os desenvolvedores não precisem voltar ao código para fazer alterações quando as necessidades de apresentação mudarem.

5
Steve Perks
  • Conformidade 508 - a capacidade de um leitor de ecrã fazer sentido da sua marcação.
  • Esperando por renderização - as tabelas não são renderizadas no navegador até chegar ao final do elemento </table>.
5
Rick Glos

Isso não é realmente sobre se 'divs são melhores que tabelas para layout'. Alguém que entenda CSS pode duplicar qualquer design usando 'tabelas de layout' de forma bem direta. A verdadeira vitória é usar elementos HTML para o que eles estão lá. A razão pela qual você não usaria tabelas para dados não-tabulares é a mesma razão pela qual você não armazena números inteiros como cadeias de caracteres - a tecnologia funciona muito mais facilmente quando usada para o propósito para o qual é desenhada. Se alguma vez foi necessário usar tabelas para o layout (por causa de falhas no navegador no início dos anos 90), certamente não é agora.

4
domgblackwell

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ê está lutando para usar divs flutuantes para alinhar verticalmente um logotipo com algum texto de patrocínio, basta usar a tabela e seguir em frente com a vida. A religião do jardim Zen simplesmente não dá muito estrondo para o fanfarrão.

A ideia de separar o conteúdo da apresentação é particionar o aplicativo para que diferentes tipos de trabalho afetem diferentes blocos de código. Isso é realmente sobre o 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 de 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 mudança para "conteúdo" é sempre acompanhada por uma alteração para "apresentação", qual será o sucesso do particionamento?

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

3
Patrick May

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

CSS é claramente preferível nos casos em que marcação de apresentação e CSS suportam o mesmo tipo de design, ninguém no seu perfeito juízo argumentaria que as tags font- são melhores do que especificar tipografia em CSS, já que CSS dá a mesma potência que font- tags, mas de uma maneira muito mais limpa.

O problema com as tabelas, no entanto, é basicamente que o modelo de layout de tabela em CSS não é suportado no Microsoft Internet Explorer. Tabelas e CSS são, portanto, não equivalentes em poder. A parte ausente é o comportamento de grade das tabelas, onde as bordas das células se alinham vertical e horizontalmente, enquanto as células ainda se expandem para conter seu conteúdo. Este comportamento não é fácil de conseguir em CSS puro sem codificar algumas dimensões, o que torna o design rígido e frágil (desde que tenhamos de suportar o Internet Explorer - em outros navegadores isso é facilmente conseguido usando display:table-cell).

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

A razão mais importante para não usar tabelas é acessibilidade. As Diretrizes de Acessibilidade ao Conteúdo da Web http://www.w3.org/TR/WCAG10/ conselhos novamente usando tabelas para layout. Se você está preocupado com acessibilidade (e em alguns casos você pode ser legalmente obrigado a), você deve usar CSS mesmo se as tabelas forem mais simples. Note que você pode sempre criar o mesmo layout com CSS como com as tabelas, isso pode exigir mais trabalho.

3
JacquesB

Ferramentas que usam layouts de tabela podem se tornar extraordinariamente pesadas devido à quantidade de código necessária para criar o layout. Por padrão, o portal Netweaver da SAP usa TABELA para criar suas páginas.

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

Tomando o tempo para diminuir o peso da página para que você possa usar sua largura de banda para fazer atividades envolventes com os usuários vale a pena o esforço.

3
Mike Cornell

Manipulação de DOM é difícil em um layout baseado em tabela.

Com divs semânticos:

$('#myawesomediv').click(function(){
    // Do awesome stuff
});

Com tabelas:

$('table tr td table tr td table tr td.......').click(function(){
    // Cry self to sleep at night
});

Agora, concedido, o segundo exemplo é meio idiota, e você pode sempre aplicar IDs ou classes a uma tabela ou elemento td, mas isso seria adicionar valor semântico, que é o que os proponentes da tabela se opõem com veemência.

3
Chris Fletcher

Fiquei surpreso ao ver que alguns problemas não estavam cobertos, então aqui estão meus 2 centavos, além de todos os pontos muito válidos feitos 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. Há alguns anos atrás, os motores de busca estavam dando uma ênfase significativa aos fatores "on-page". Algo no topo 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 de 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 é mais clara e, portanto, carrega mais rápido para um spider de mecanismo de pesquisa. (aranhas não se importam em baixar arquivos css externos). O carregamento rápido de páginas é uma consideração importante no ranking de vários mecanismos de pesquisa, incluindo o Google

c) O trabalho de SEO geralmente requer testes e mudanças, o que é muito mais conveniente com um layout baseado em CSS

.2. Conteúdo gerado:

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

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

Gerar uma mesa é simples e seguro. É auto-suficiente e integra-se bem em 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 no flight e adicionar o estilo inline 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 (em código), facilitando a modificação.

Esta é uma razão pela qual alguns sites muito bem desenhados (SO, por exemplo) ainda usam layouts de tabelas.

É claro que, se os resultados precisarem ser resolvidos por meio do JavaScript, os divs valerão 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 o que obtém os melhores resultados. Um layout baseado em CSS torna as coisas consideravelmente mais fáceis

.4. soluções diferentes para problemas diferentes

Tabelas de layout são geralmente dissed porque "todo mundo sabe divs & 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 são mais robustas do que a maioria dos layouts CSS. (Sim, CSS pode ser tão robusto, mas um rápido olhar através da rede em diferentes navegadores e resoluções de tela mostram que nem sempre é 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. Há muitos usos profissionais para uma solução rápida e confiável.

Algum tempo atrás, eu tive que reescrever um layout CSS limpo e simples usando tabelas porque uma parte significativa dos usuários estaria usando uma versão mais antiga de IE com suporte muito ruim para CSS

Eu, por exemplo, estou doente e cansado da reação instintiva "Oh noes! Tabelas para layout!"

Quanto ao "não foi destinado para esse fim e, portanto, você não deve usá-lo desta maneira" multidão, isso não é hipocrisia? O que você acha de todos os truques de CSS que você tem que usar para fazer a maldita coisa funcionar na maioria dos navegadores? Eles foram feitos para esse propósito?

3
Sylverdrag

Porque é difícil 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 problemáticos (a menos que você não os entenda - mas, bem vindos ao mundo dos computadores).

Qualquer um que esteja pensando em fazer o layout com uma mesa melhor, não espera que eu a mantenha. É a maneira mais comum de renderizar um website. Graças a Deus, temos uma alternativa muito melhor agora. Eu nunca iria voltar.

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

3
Chuck Le Butt
  1. Tente mesclar/dividir um colspan/rowspan de 10/20 algo profundo. Mais de uma vez tive que reprimir meu instinto de começar uma briga com alguém. [?!]
  2. Tente alterar a ordem do código-fonte sem alterar a ordem visível. [SEO, usabilidade, ...]
  3. A página muito (muito simples) que estamos vendo é ~ 150K. Aposto que pode quase ser reduzido pela metade usando CSS adequado. [SEO (sim, SEO, leia as últimas especificações do Google, etc), perfo, ...]
  4. Tente criar um modelo de iterador que possa funcionar em qualquer largura.
  5. A discussão do assunto neste meio baseado em tabelas de SO pode causar uma singularidade e destruir todos nós
2
Halil Özgür

A questão de separar rigidamente a apresentação e o conteúdo parece-me mais ou menos análoga à separação dos arquivos de cabeçalho dos arquivos de implementação em C++. Faz sentido, mas também pode ser uma dor. Testemunhe Java e C # onde as classes são definidas em um único arquivo de origem. Os autores das linguagens mais recentes notaram algo que estava causando dores de cabeça aos programadores e eles se livraram disso. Essa parece ser a essência dessa discussão. Um lado está dizendo que CSS é muito difícil, o outro lado está dizendo que é preciso se tornar um mestre CSS.

Para problemas simples de layout, por que não dobrar a regra que diz que a apresentação deve ser completamente separada? Que tal uma nova tag (ou alguma extensão da tag div) que nos permite controlar a apresentação diretamente em HTML? Afinal, já não estamos vazando apresentação para HTML? Olhe para h1, h2 ... h6. Todos nós conhecemos essa apresentação de controle.

A capacidade de ler código (e HTML é código) é muito importante. Gurus tendem a ignorar o quão importante é tornar um ambiente de programação tão acessível quanto possível às massas. É muito míope pensar que apenas os programadores profissionais são importantes.

2
user825628

Um grande problema para mim é que as tabelas, especialmente as aninhadas, demoram muito mais para renderizar do que uma implementação css bem definida. (Você pode fazer css tão lento).

Todos os navegadores processam o css mais rápido porque cada div é um elemento separado, portanto, uma tela pode ser carregada conforme o usuário está lendo. (Para grandes conjuntos de dados, etc). Eu usei css em vez de tabelas nessa instância nem mesmo lidar com o layout.

Uma tabela aninhada (tabelas dentro de células, etc) não será renderizada na janela do navegador até que a última "/ table" seja encontrada. Pior ainda - uma tabela mal definida nem sempre será renderizada! Ou quando isso acontece, as coisas se comportam mal. (não colspanning corretamente com "TD" 'etc.)

Eu uso tabelas para a maioria das coisas, mas quando se trata de dados grandes e o desejo de ter uma tela renderizada rapidamente para um usuário final - eu tento o meu melhor para utilizar o que o CSS tem a oferecer.

2
Tim Fischer

Eu tive que fazer sites em ambas as formas, além de um terceiro, o temido layout "híbrido" com tabelas, divs e estilos: Divs/CSS ganha, com folga.

Você teria que aninhar divs três deep para corresponder ao peso do código de apenas uma célula da tabela, logo de cara. Esse efeito é dimensionado com tabelas aninhadas.

Eu também prefiro fazer uma alteração de layout, em vez de uma alteração para cada página do meu site.

Eu tenho controle total sobre todos os aspectos da apresentação com divs/css. Tabelas bagunçam isso de formas hediondas, especialmente no IE, um navegador que eu nunca tive a opção de não suportar.

Meu tempo para manutenção ou redesenho de um site divs/css é uma fração do que seria em tabelas.

Finalmente, posso inovar layouts múltiplos e alternáveis ​​com CSS e virtualmente qualquer linguagem de script. Isso seria impossível para mim com as tabelas.

Boa sorte com o seu ROI ao tomar essa decisão.

2
John Dunagan

Um exemplo: você deseja centralizar a área de conteúdo principal de uma página, mas para conter os flutuadores dentro dela, ela precisa estar flutuando. Não há "float: center" em CSS.

Essa não é a única maneira de "conter os flutuadores" dentro de um elemento centralizado. Então, não é um bom argumento!

De certa forma, é uma falsa premissa, a coisa "divs vs tables".

Divisão rápida e suja de uma página em três colunas? Tabelas são mais fáceis, para ser honesto. Mas nenhum profissional os usa mais para o layout, porque eles bloqueiam o posicionamento dos elementos da página na página.

O argumento real é "posicionamento feito por CSS (esperançosamente em um arquivo remoto)" em oposição ao "posicionamento feito por HTML na página". Certamente todos podem ver os benefícios do primeiro em oposição ao segundo.

  1. Tamanho - se o layout da página estiver no HTML, nas páginas, ele não poderá ser armazenado em cache e deverá ser repetido em todas as páginas. Você economizará enormes quantidades de largura de banda se seu layout estiver em um arquivo CSS em cache, não na página.
  2. Vários desenvolvedores podem trabalhar na mesma página ao mesmo tempo - eu trabalho no HTML, outro cara trabalha no CSS. Nenhum repositório necessário, nenhum problema com excesso de escrita, bloqueio de arquivos, etc.
  3. Fazer alterações é mais fácil - haverá problemas com o layout em diferentes navegadores, mas você só precisa corrigir um arquivo, o arquivo CSS, para classificá-los.
  4. Acessibilidade, como mencionado muito anteriormente. As tabelas assumem que um layout bidimensional funciona para todos. Não é assim que alguns usuários visualizam seu conteúdo e não é como o Google visualiza seu conteúdo.

Considere isto:

[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]

que representa duas linhas de uma tabela com 6 células. Alguém que pode ver o layout da tabela em 2D verá uma legenda sob cada foto. Mas usando a síntese de fala, ou um PDA, e para uma aranha de mecanismo de busca,

picture picture picture caption caption caption

e o relacionamento, que é óbvio com a mesa no lugar, desaparece.

Os DIVs e CSS são melhores para a tarefa de simplesmente criar retângulos em uma página HTML para obter um determinado design no menor tempo possível? Não, eles provavelmente não são. Mas não estou no negócio de criar rapidamente retângulos para alcançar um determinado design. Estou pensando em uma foto muito maior.

2
AmbroseChapel

A separação entre o conteúdo e o layout também facilita a geração de layouts compatíveis com impressão ou apenas estilos diferentes para seu site, sem a necessidade de criar arquivos HTML diferentes. Alguns navegadores (como o Firefox) até suportam a seleção de uma folha de estilo no menu de visualização.

E eu acho que é mais fácil manter um layout sem tablete. Você não precisa se preocupar com registros de linha, bibliotecas, etc. Basta criar alguns divs de contêiner e colocar o conteúdo onde for necessário. E isso disse que também é mais legível (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).

É só um pequeno 'truque' que você tem que aprender (e depois de dominar o truque, acho que é mais fácil e faz mais sentido).

2
Grad van Horck

Para responder ao argumento "as tabelas são mais lentas", você está pensando no tempo de renderização, que é a métrica errada. Muitas vezes, os desenvolvedores escrevem uma tabela enorme para fazer o layout inteiro de uma página - o que aumenta significativamente o tamanho da página a ser baixada. Goste ou não, ainda há muitos usuários de discagem por aí.

Veja também: uso excessivo do ViewState

1
Greg Hurlman

Da experiência passada, eu teria que ir para o DIV. Mesmo em OOP, o principal objetivo é reduzir o acoplamento entre os objetos, para que este conceito possa ser aplicado a DIVS e tabelas. Tabelas são usadas para armazenar dados, não para organizá-los em uma página. Um DIV é projetado especificamente para organizar itens em torno de uma página, portanto, o design deve usar DIV's, tabelas devem ser usadas para armazenar dados.

Além disso, editar sites feitos com tabelas é simplesmente difícil (na minha opinião)

1
Richard

o posicionamento de div e CSS permite um design mais flexível, levando a modificações e modelos mais fáceis de suas páginas da web.

Dito isto, se você não está interessado na flexibilidade, então usar uma tabela em vez de alguns divs que são transformados em uma tabela por CSS é definitivamente muito mais fácil e mais rápido para derrubar. Eu costumo usar tabelas ao criar um design apenas para dar a impressão de que é um pouco mais rápido.

1
workmad3

Quando desenho meu layout usando CSS, geralmente dou a cada seção principal seu próprio div de raiz (nível de corpo) e uso o posicionamento relativo/absoluto para colocá-lo em seu devido lugar. Isso é um pouco mais flexível que as tabelas, pois não estou limitado a um arranjo que eu possa representar usando linhas e colunas.

Além disso, se eu decidir que quero reorganizar o layout (digamos que eu quero que a barra de navegação esteja no momento), posso simplesmente alterar a posição dos elementos em um lugar (o arquivo CSS) e o HTML não. t tem que mudar. Se eu estivesse fazendo isso com tabelas, eu teria que entrar e encontrar as informações e fazer um monte de modding, copiar e colar atributos para obter o mesmo efeito.

De fato, usando CSS, eu posso até ter meu suários selecione como eles querem que seu layout funcione. Contanto que o tamanho geral das áreas de conteúdo não mude, eu estou perfeitamente bem em usar um pouco de PHP scripts para gerar meu CSS com base nas preferências do usuário, e permitir que eles reorganizem o site para seu próprio gosto. Mais uma vez, possível com tabelas, mas muito mais difícil de manter.

Por fim, o CSS permite um benefício MAIOR que as tabelas nunca fornecerão: a capacidade de reformatar o conteúdo com base no dispositivo de exibição. CSS permite-me usar um conjunto de estilos completamente diferente (incluindo posição, formatação, etc) para uma impressora do que a que eu uso para o monitor. Isso pode ser estendido para outras mídias também, um excelente exemplo é o Opera Show, que permite que uma página CSS aprimorada (e muito padronizada) seja vista como uma apresentação de slides.

Então, no final, flexibilidade e gestão são os verdadeiros vencedores. Geralmente, o CSS permite que você faça mais com o layout. Não há nada tecnicamente fora do padrão sobre um layout baseado em tabela, mas por que você quer se limitar?

1
Nicholas Flynt

No passado, os leitores de tela e outros softwares de acessibilidade tinham dificuldade em lidar com as tabelas de maneira eficiente. Até certo ponto, isso foi tratado em leitores de tela pelo leitor, alternando entre um modo de "tabela" e um modo de "layout" com base no que viu dentro da tabela. Isso geralmente estava errado e, portanto, os usuários precisavam alternar manualmente o modo ao navegar pelas tabelas. Em qualquer caso, as tabelas grandes, muitas vezes altamente aninhadas, eram, e em grande parte, ainda muito difíceis de navegar usando um leitor de tela.

O mesmo acontece quando divs ou outros elementos em nível de bloco são usados ​​para recriar tabelas e são altamente aninhados. O objetivo do divs é ser usado como um elemento de layout e layout e, como tal, deve ser usado para armazenar informações semelhantes e disponibilizá-las na tela para usuários visuais. Quando um leitor de tela encontra uma página, ele normalmente ignora qualquer informação de layout, tanto baseada em CSS quanto em atributos baseados em html (isso não é verdade para todos os leitores de tela, mas para os mais populares, como JAWS, Windows Eyes e Orca para Linux é).

Para isso, os dados tabulares, ou seja, os dados que fazem sentido lógico serem ordenados em duas ou mais dimensões, com algum tipo de cabeçalho, são melhor colocados em tabelas e usam divs para gerenciar o layout do conteúdo na página. (outra maneira de pensar em "dados tabulares" é tentar desenhá-los em forma de gráfico ... se você não puder, provavelmente não está melhor representado em uma tabela)

Por fim, com um layout baseado em tabela, para obter um controle refinado da posição dos elementos na página, geralmente são usadas tabelas altamente aninhadas. Isso tem dois efeitos: 1.) Maior tamanho de código para cada página - Como a navegação e a estrutura comum geralmente são feitas com as tabelas, o mesmo código é enviado pela rede para cada solicitação, enquanto um layout baseado em div/css puxa o arquivo css mais de uma vez e, em seguida, usa menos divs wordy. 2.) Tabelas altamente aninhadas levam muito mais tempo para o navegador do cliente renderizar, levando a tempos de carregamento um pouco mais lentos.

Em ambos os casos, o aumento na largura de banda da "última milha", bem como os computadores pessoais muito mais rápidos, atenuam esses fatores, mas, no entanto, eles ainda são problemas existentes em muitos sites.

Com tudo isso em mente, como os outros disseram, as tabelas são mais fáceis, porque são mais orientadas para a grade, permitindo menos reflexão. Se não for esperado que o site em questão permaneça por muito tempo ou não seja mantido, pode fazer sentido fazer o que é mais fácil, porque ele pode ser o mais econômico possível. No entanto, se a base de usuários prevista incluir uma parcela substancial de pessoas com deficiência, ou se o site for mantido por outros por muito tempo, gastar o tempo adiantado para fazer as coisas de maneira concisa e acessível pode render mais no final.

1
cdeszaq

Eu ainda não entendo muito bem como o divs/CSS facilita a mudança do design da página quando você considera a quantidade de testes para garantir que as alterações funcionem em todos os navegadores, especialmente com todos os hacks e assim por diante. É um processo extremamente frustrante e tedioso que desperdiça grandes quantidades de tempo e dinheiro. Felizmente a legislação do 508 só se aplica aos EUA (terra do livre - sim, certo) e assim sendo como estou baseado no Reino Unido, posso desenvolver sites em qualquer estilo que eu escolher. Ao contrário da crença popular (dos EUA), a legislação feita em Washington não se aplica ao resto do mundo - graças a Deus por isso. Deve ter sido um bom dia no mundo do web design no dia em que a legislação entrou em vigor. Acho que estou ficando cada vez mais cínico à medida que envelheço com 25 anos na indústria de TI, mas tenho certeza de que esse tipo de legislação é apenas para proteger os empregos. Na realidade, qualquer um pode reunir uma página web razoável com algumas tabelas. É preciso muito mais esforço e conhecimento para fazer isso com DIVs/CSS. Na minha experiência, pode demorar horas e horas navegando no Google para encontrar soluções para problemas bem simples e ler artigos incompreensíveis em fóruns cheios de fanáticos idealistas, todos argumentando sobre o modo "certo" de fazer as coisas. Você não pode simplesmente mergulhar seu dedo na água e fazer as coisas funcionarem corretamente em todos os casos. Parece-me também que a falta de um guia definitivo para usar o DIVS/CSS "fora da caixa", que se aplica a todas as situações, trabalhando em navegadores e escritos usando linguagem 'normal' sem falar nerd, também cheira a pouco de protecionismo.
Sou um desenvolvedor de aplicativos e diria que demora quase o dobro do tempo para descobrir problemas de layout e testar em todos os navegadores do que para criar o aplicativo básico, projetar e implementar objetos de negócios e criar o banco de dados back end. O meu tempo = dinheiro, tanto para mim como para os meus clientes, por isso lamento se não rejeitar todos os argumentos pro DIV/CSS a favor da redução de custos e da disponibilização de valor para os meus clientes. Talvez seja apenas o modo como as mentes dos desenvolvedores trabalham, mas parece-me muito mais fácil mudar uma estrutura de tabela complexa do que modificar DIVs/CSS. Felizmente, agora parece que uma solução para esses problemas já está disponível - é chamada de WPF.

1
Tim Black

Eu acho que ninguém se importa como um site foi criado/implementado quando ele se comporta muito bem e funciona rápido.

Eu uso as tags "table" e "div"/"span" na marcação HTML.

Deixe-me dar alguns argumentos porque eu estou escolhendo divs:

  1. para uma tabela você tem que escrever pelo menos 3 tags (table, tr, td, thead, tbody), para um design agradável, às vezes você tem um monte de tabelas aninhadas

  2. Eu gosto de ter componentes na página. Não sei explicar exatamente, mas vou tentar. Suponha que você precisa de um logotipo e isso precisa ser colocado, apenas um pequeno pedaço dele, no próximo conteúdo da página. Usando tabelas você tem que cortar 2 imagens e colocar isso em 2 diferentes TDs. Usando DIVs, você pode ter um CSS simples para combinar como quiser. Qual solução você mais gosta?

  3. quando mais de 3 tabelas aninhadas para fazer algo estou pensando em redesenhá-lo usando DIVs

MAS ainda estou usando tabelas para:

  1. dados tabulares

  2. conteúdo que está se expandindo

  3. soluções rápidas (protótipos), porque o modelo de caixa DIVs é diferente em cada navegador, porque muitos geradores estão usando tabelas, etc.

1
Dani

Por ainda usar tabela para layouts, estamos perdendo a inovação no lado div.

Muitos vieram com soluções que facilitam a criação de layout para divs. O mais popular é a arquitetura de grade. Existem geradores de layout dinâmicos baseados nessa arquitetura. Confira: 1) 960.gs e (http://grids.heroku.com/) 2) projeto e tantos de atraso.

Eu não vi muita inovação em termos de arquitetura e ferramentas com o layout das tabelas.

Eu diria, todas as teorias à parte, praticamente layout com CSS e as divs são mais rápidas. Em vez disso, a inovação nessa direção tornou mais fácil do que qualquer coisa.

1
Pixelgrey

Tabelas são boas para HTML que você está jogando juntos para algo simples ou temporário. Se você está construindo um site em larga escala, você deve ir com divs e CSS, já que será mais fácil de manter com o passar do tempo conforme seu site muda.

1
Adam Rosenfield

1: Sim, seus usuários se importam. Se eles usarem um leitor de tela, ele será perdido. Se eu usar qualquer outra ferramenta que tente extrair informações da página, encontrar tabelas que não sejam usadas para representar dados tabulares é enganoso.

Um div ou span é aceitável para separar o conteúdo porque esse é precisamente o significado desses elementos. Quando eu, um mecanismo de pesquisa, um leitor de tela ou qualquer outra coisa, encontro um elemento de tabela, esperamos que isso signifique "o seguinte é dados tabulares, representados em uma tabela". Quando encontramos um div, esperamos que "este seja um elemento usado para div ide meu conteúdo em partes ou áreas separadas.

2: legibilidade: errado. Se todo o código de apresentação estiver em css, eu posso ler o html e vou entender o conteúdo da página. Ou eu posso ler o CSS e entender a apresentação. Se tudo é misturado no html, eu tenho que mentalmente eliminar todos os bits relacionados à apresentação antes mesmo de ver o que é conteúdo e o que não é. Além disso, eu ficaria com medo de conhecer um desenvolvedor web que não entendeu css, então eu realmente não acho que isso seja um problema.

3: As tabelas são mais lentas: sim, elas são. A razão é simples: as tabelas devem ser analisadas completamente, incluindo seus conteúdos antes que possam ser renderizados. Uma div pode ser renderizada quando encontrada, mesmo antes seu conteúdo foi analisado. Isso significa que os divs aparecerão antes que a página termine de ser carregada.

E depois há o bônus, que as tabelas são muito mais frágeis e nem sempre serão processadas da mesma maneira em navegadores diferentes, com fontes e tamanhos de fonte diferentes e todos os outros fatores que podem causar variações no layout. As tabelas são uma excelente maneira de garantir que seu site seja desativado em um ou dois pixels em determinados navegadores, não se adapte bem quando o usuário alterar o tamanho da fonte ou altere suas configurações de qualquer outra forma.

Claro que o nº 1 é o maior. Muitas ferramentas e aplicativos dependem do significado semântico de uma página da Web. O exemplo usual são leitores de tela para usuários com deficiência visual. Se você for um desenvolvedor da Web, descobrirá que muitas empresas de grande porte, que podem contratá-lo para trabalhar em um site, exigem que o site seja acessível, mesmo nesse caso. O que significa que você tem que pensar sobre o significado semântico do seu html. Com a Web semântica, ou mais relevante, microformatos, leitores de RSS e outras ferramentas, o conteúdo da sua página não é mais visualizado exclusivamente por meio de um navegador.

1
jalf

Sinto muito pelo meu inglês, mas aqui está outro motivo:

Eu trabalhei em alguma organização governamental e o número um motivo para não usar o TABLE, é para pessoas com deficiência. Eles usam máquinas para "traduzir" páginas da web.

O problema é que essa "máquina de tradução" não pode ler o site se for feita por TABLE. Por quê ? Porque TABLE são para DATAS.

de fato, se você usar TABLES, para cada CELLS você terá que especificar algumas informações para permitir que as pessoas com deficiência saibam onde elas estão na TABELA. Imagine que você tem uma mesa grande e precisa fazer zoom para ver apenas 1 célula na tela: você precisa saber em qual linha/coluna você está.

Então, o DIV é usado, e os deficientes podem simplesmente ler textos, e não obter algumas informações estranhas sobre linhas/cols quando eles não precisam estar lá.

Eu também prefiro o TABLE para fazer templates rápidos e fáceis, mas agora estou acostumado com o CSS ... ele é poderoso, mas você realmente precisa saber o que está fazendo ... :)

1
RVeur23

Flex tem uma tag para colocar as coisas em colunas verticais. Eu não acho que eles tenham todo o layout/conteúdo certo para ser honesto, mas pelo menos eles resolveram esse problema.

Como muitas das pessoas frustradas com o CSS, eu também procurei uma resposta fácil em todos os lugares, fiquei empolgado quando achei que tinha encontrado e, em seguida, tive minhas esperanças quebradas quando abri a página no Chrome. Eu definitivamente não sou habilidoso o suficiente para dizer que não é possível, mas eu não vi ninguém oferecer código de amostra para revisão por pares provando inequivocamente que isso pode ser feito de forma confiável.

Então, alguém do lado CSS desta ilha pode recomendar uma mentalidade/metodologia para o estabelecimento de colunas verticais? Eu tentei o posicionamento absoluto na segunda e terceira linhas, mas acabo com coisas sobrepostas em todos os lugares e float tem problemas semelhantes se a página é encolhida.

Se houvesse uma resposta para isso eu ficaria em êxtase para - fazer a coisa certa - Apenas me diga algo como: "Hey você já tentou ** fluxo: vertical | horizontal" e eu estou totalmente fora de seu cabelo.

1
Shanimal

O Google dá prioridade muito baixa ao conteúdo de texto contido em uma tabela. Eu estava dando alguns conselhos de SEO para uma instituição de caridade local. Ao examinar seu site, estava usando tabelas para criar o layout do site. Olhando para cada página, independentemente das palavras - ou combinação de palavras - das páginas que usei na caixa de pesquisa do Google, as páginas não apareceriam em nenhuma das principais páginas de pesquisa. (No entanto, ao especificar o site na pesquisa, a página foi retornada.) Uma página foi bem copiada por padrões normais para produzir um bom resultado em uma pesquisa, mas ainda não apareceu em nenhuma das primeiras páginas de resultados de pesquisa retornados . (Observe que esse texto estava dentro de uma tabela). Depois, localizei uma seção de texto nas páginas que estava em uma div e não em uma tabela. Colocamos algumas das palavras desse div no mecanismo de pesquisa. Resultado? Ele entrou no No.2 no resultado da pesquisa.

1
Simon Measures

Uma vez aprendi que uma tabela é carregada de uma só vez, em outras palavras, quando a conexão é lenta, o espaço em que a tabela vem fica em branco até que a tabela inteira seja carregada, uma div é carregada de cima para baixo tão rápido quanto os dados e independentemente se já estiver completo ou não.

1
Davy

Use tabelas quando precisar garantir que os elementos precisem permanecer em um relacionamento físico específico no layout. Para dados, a tabela é geralmente o melhor elemento de layout a ser usado porque você não deseja que suas colunas sejam agrupadas de uma forma inesperada e confundam as associações.

Pode-se também argumentar que os elementos que não são de dados que devem permanecer em um relacionamento específico também devem ser renderizados em uma tabela.

Layouts css flexíveis são ótimos para conteúdo que é adequado para dispositivos móveis e telas grandes e impressão e outros tipos de exibição, mas às vezes, o conteúdo precisa ser exibido de uma maneira muito específica e se isso exigir que os leitores de tela não possam acessá-lo facilmente, poderia muito bem ser justificado.

1
Sal

Eu tento evitar TABLEs, tanto quanto possível, mas quando estamos projetando formas complexas que misturam vários tipos de controle e diferentes posições de legenda com controles bastante rígidos sobre o agrupamento, usar DIVs não é confiável ou quase impossível.

Agora, não vou argumentar que esses formulários não poderiam ser reprojetados para acomodar melhor um layout baseado em DIV, mas para alguns deles nosso cliente é inflexível em não alterar os layouts existentes da versão anterior (escrita em ASP clássico) porque é semelhante a um papel que seus usuários estão familiarizados.

Como a apresentação dos formulários é dinâmica (em que a exibição de algumas seções é baseada no estado do caso ou nas permissões do usuário), usamos conjuntos de DIVs empilhados, cada um contendo um TABLE de elementos de formulário agrupados logicamente. Cada coluna do TABLE é classificada para que possa ser controlada pelo CSS. Dessa forma, podemos desativar seções diferentes do formulário sem o problema de não ser tabela para agrupar linhas em DIVs.

1
CMPalmer

Eu pesquisei a questão de leitores de tela e tabelas há alguns anos e surgiu com informações que contradizem o que a maioria dos desenvolvedores acredita:

http://www.webaim.org/techniques/tables/

"Provavelmente você ouvirá alguns defensores da acessibilidade dizendo que as tabelas de layout são uma má idéia, e que técnicas de layout CSS devem ser usadas. Há verdade no que dizem, mas, para ser honesto, usar tabelas para layout não é o pior coisa que você poderia fazer em termos de acessibilidade. Pessoas com todos os tipos de deficiência podem acessar facilmente as tabelas, desde que as tabelas sejam projetadas tendo em mente a acessibilidade. "

1
Rimian

Eu acredito que esta é uma questão ligada a um problema geral. Quando o HTML nasceu, ninguém poderia prever o seu uso generalizado. Outra tecnologia que quase entrou em colapso sob o peso de seu próprio sucesso. Quando as páginas HTML eram escritas em vi em um terminal de texto verde, um TABLE era tudo o que era necessário para apresentar dados aos visitantes da página, e eram principalmente dados que faziam sentido em uma forma tabular.

Nós todos sabemos como as coisas evoluíram. TABELAS saíram de moda comparativamente recentemente, mas há muitas razões para preferir layouts baseados em DIVs e CSS (acessibilidade não é o último deles). É claro que não posso escrever um CSS para salvar minha vida :-) e acho que um especialista em design gráfico deve estar sempre à mão.

Dito isto ... há muitos dados que devem ser apresentados em uma tabela, mesmo em um site moderno.

1
Manrico Corazzi

Se você está apoiando o ângulo da mesa, encontre um site com tabelas e obtenha um leitor de tela - desligue o leitor de tela e desligue o monitor.

Em seguida, experimente-o com um belo site de layout div semanticamente correto.

Você verá a diferença.

As tabelas não são ruins se os dados nelas não forem tabulares para o layout da página.

1
Allen Hardy

Conforme meu conhecimento em tabelas, se muitas tabelas estiverem aninhadas, haverá uma grande sobrecarga para o navegador ao renderizar a página.

1 - O navegador espera para renderizar a visualização final até que toda a tabela seja carregada.

2 - O algoritmo para renderizar a tabela é caro e não é de uma só vez. O navegador, como e quando, obtém o conteúdo, tentará renderizar o cálculo da largura e altura do conteúdo. Então, se você está tendo tabelas aninhadas, digamos, o navegador recebeu a primeira linha e a primeira célula está tendo uma grande quantidade de conteúdo e largura e altura não definidas, ele calculará a largura e renderizará a primeira linha. enquanto fica na 2ª linha, a célula # 2 terá muito conteúdo! Agora, calculará a largura das células da segunda linha. E quanto ao primeiro? Ele calculará larguras recursivamente. Isso é ruim no lado do cliente. (Para criar um exemplo) Como programador, você otimizará materiais como tempo para buscar dados, estruturas de dados otimizadas e etc. Você otimizará as coisas para serem concluídas no servidor, digamos, em2 segundos, mas o usuário final terá a visão final em 8 segundos O que está errado aqui? 1. Pode ser que a rede esteja lenta! E se a rede estiver bem? O que é rede está entregando o conteúdo nos próximos 1 seg? Onde estão esses 5 segundos extras sendo consumidos? Coisa para se preocupar - O navegador pode estar demorando muito para estimar e renderizar as tabelas!

Como otimizar tabelas? Se você estiver usando tabelas, sugiro sempre definir largura para as células. Isso não garante que o navegador capture cegamente apenas essas larguras, mas seria de grande ajuda para o navegador decidir as larguras iniciais.

Mas, no final, as div são ótimas maneiras como o CSS pode ser armazenado em cache pelo navegador; enquanto a tabela não está em cache!

1
Biranchi Panda

Tabelas usadas como layout puro apresentam alguns problemas de acessibilidade (que eu ouvi). Mas eu entendo o que está sendo perguntado aqui que de alguma forma você está prejudicando a web usando uma tabela para garantir o alinhamento correto de algo em sua página.

Eu já ouvi pessoas argumentarem que os rótulos e entradas do FORM são, na verdade, dados e que devem ser permitidos em tabelas.

O argumento de que usar uma tabela para garantir que alguns elementos se alinham corretamente faz com que esse aumento maciço de código tenda a incluir exemplos de como um único DIV pode atender a todas as suas necessidades. Eles nem sempre incluem as 10 linhas de CSS e hackers especiais que eles tiveram que escrever para IE5, IE5.5, IE6, IE7 ...

Eu acho que continua a ser sobre o uso de equilíbrio em seu design. Tabelas estão na caixa de ferramentas, basta lembrar o que são para ...

0
HB

Certamente o OP foi um pouco difícil, os argumentos parecem tão fáceis de serem enfrentados.

As páginas da Web são o domínio dos desenvolvedores da Web e, se eles disserem que div & CSS é melhor do que as tabelas, isso é bom o suficiente para mim.

Se um layout for obtido por meio de tabelas geradas por um aplicativo de servidor, um novo layout significa alterações no aplicativo, uma reconstrução e uma redelpoy do aplicativo, em vez de apenas alterações em um arquivo css.

Além disso, acessibilidade. As tabelas usadas para o layout tornam um site inacessível, portanto, não as use. É um acéfalo, para não mencionar ilegal.

0
Ian

Super resposta curta: projetar sites sustentáveis ​​é difícil com tabelas e simples com a maneira padrão de fazer isso.

Um site não é uma tabela, é uma coleção de componentes que interagem entre si. Descrevê-lo como uma tabela não faz sentido.

0
Rich Bradshaw

Em termos de manutenção do site e revisões de design, mantendo conteúdo (o que acontece o tempo todo, especialmente no eCommerce):

Conteúdo e design reunidos por meio de tabelas = atualização de conteúdo e design.

Conteúdo separado do design = atualizando o design e talvez um pouco de conteúdo.

Se eu tivesse do meu jeito, eu manteria meu conteúdo em PHP gerando XML, convertido em marcação em XSLT e projetado com CSS e Javascript para a interação. Para o lado Java, JSP para JSTL para gerar a marcação.

0
mltorrefranca

Usando DIV, você pode mudar facilmente as coisas. Por exemplo, você poderia fazer isso:

Menu | Content

Content | Menu

Menu
----
Content

É fácil alterá-lo em CSS, não em HTML. Você também pode fornecer vários estilos (destro, canhoto, especial para tela pequena).

Em CSS, você também pode ocultar o menu em uma folha de estilo especial usada para impressão.

Outra coisa boa, é que seu conteúdo está sempre na mesma ordem no código (o menu primeiro, o conteúdo depois), mesmo que visualmente seja apresentado de outra forma.

0
ofaurax