Você usaria tabelas para fazer um layout?

[João Batista Neto 448]

Minha impressão sobre esse tópico é que se trata de um atoleiro.

 

Um monte de gente dentro de um jipe, patinando na lama, sem sair do lugar.

 

O ponto, contudo, que todos esqueceram aqui, é que tudo não passa de uma questão de custo.

 

E como eu disse e os colegas concordaram, poste uma necessidade real, que você acha inviável com tableless.

me poupara trabalho no futuro, mesmo sendo 2, 3 vezes mais demorado e difícil agora.

 

É essa a ideia que devemos ter sobre tableless, webstandards ou qualquer outra técnica ou padrão. Somente essa: Tempo é dinheiro, consequentemente, quanto maior o tempo, maior o dinheiro empregado.

 

Quando desenvolvemos aplicações web, desenvolvemos toda a parte de engenharia e esta, com certeza, é a parte de maior custo em uma aplicação. A marcação entregue ao user-agent não surge ao acaso, ela é construída segundo as regras definidas na engenharia da aplicação.

 

Mas, o que engenharia tem a ver com tudo isso?

 

Como eu disse anteriormente, o problema está na manutenção da aplicação, ou seja, se precisarmos modificar toda a marcação da aplicação, teremos que envolver, além da equipe de layout, a equipe de engenharia e a de testes.

 

Veja, envolver a equipe de engenharia, além do custo tempo dos profissionais, envolve novos testes na aplicação. Uma coisa que deveria ser simples como mudar o layout da aplicação, passa a ser complexa, cara e sujeita uma aplicação homologada à bugs que poderão surgir.

 

A grande pergunta é: Precisamos ter o custo de envolver a equipe de engenharia e também a equipe de testes apenas para mudar o layout?

 

Não podemos ter uma marcação que represente a estrutura lógica e semântica da aplicação e apenas envolver a equipe de layout?

 

A resposta para essa pergunta é: SIM, podemos.

 

Veja esse site :seta: www.csszengarden.com

 

É um exemplo de que isso é possível. A marcação desse site não muda, apenas o CSS é modificado para mudar toda a estrutura visual do site.

 

Ao não envolver equipes extras para resolver um problema da primeira versão, temos um custo recorrente de manutenção baixo e isso é importante. De fato, essa é a única importância em se utilizar essas técnicas e padrões.

 

;)

[Kaue Machado 0]

 

A grande pergunta é: Precisamos ter o custo de envolver a equipe de engenharia e também a equipe de testes apenas para mudar o layout?

 

Concordo plenamente João! Falando objetivamente, tanto tableless quanto php e afins (tableless nem tanto) dão mais trabalho a curto prazo, mas a longo prazo, na manutenção do projeto, eles trazem um benefício imensurável.

Por exemplo, manter um site com 50 páginas feito apenas em html, sem php, já é um pesadelo, dezenas de horas desperdiçadas, isso considerando que a alteração de todo o estilo é feita através de uma stylesheet css. Agora imagine um site totalmente feito em tabelas, com 50 páginas? Eu ficaria louco!

 

Acho que esse é o maior benefício do CSS, você controla todo o estilo, e layout de todas as páginas através de um único arquivo e em um site bem organizado, você controla apenas o conteúdo pelo mysql ou html, sem misturar markup com estilo.

[João Batista Neto 448]

Falando objetivamente

 

Quando gastamos mais tempo para desenvolver algo escalável, não estamos aumentando o custo do projeto, estamos investindo para que não tenhamos um grande custo no futuro. Qualquer tecnologia tem como objetivo reduzir o custo a longo prazo.

 

Então, falando objetivamente, investimos na primeira versão para que a manutenção das próximas se torne menos custosa.

 

;)

[Mário Monteiro 179]

Quando gastamos mais tempo para desenvolver algo escalável, não estamos aumentando o custo do projeto, estamos investindo para que não tenhamos um grande custo no futuro. Qualquer tecnologia tem como objetivo reduzir o custo a longo prazo.

 

Então, falando objetivamente, investimos na primeira versão para que a manutenção das próximas se torne menos custosa.

 

;)

 

Isso resume a opera toda

 

Além do mais a experiencia faz com que todos os custos envolvidos sejam sempre menores até atingir a perfeição que obviamente nunca deve chegar pois tem sempre algo novo a se aprender ou se aperfeiçoar pelo menos

[Henrique Barcelos 290]

Afinal, qual o beneficio em "não usar" um recurso? Não existe "estudar o uso de tableless", o tableless se baseia simplesmente em não usar tabelas e em não aprender as opções de layout que elas trazem.

Tableless não significa NÃO USAR TABELAS, significa USAR MENOS TABELAS.

Aqui um exemplo onde SE DEVE utilizar tabelas:

 

O problema não é 'utilizar o recurso', é utilizar o recurso onde não é adequado. Depois de uma chuva de granizo que quebrou 2 telhas da sua casa, você contrataria um frete de um caminhão-cegonha para te entregar as 2 telhas? Você tentaria usar um fusquinha para rebocar um caminhão que ficou atolado?

 

html5, css3, dispositivos mobile... nada disso é incompatível com o uso de tabelas amigo.

No outro tópico eu te mostrei que você está enganado quanto a isso.

 

As tabelas são só mais um recurso que se soma a todos os outros recursos e praticas que qualquer partidário do tableless usa.

Eu não me privo desses recursos, quem não usa tabelas é que se priva das vantagens dela.

Eu não me privo de nada, só não vejo NECESSIDADE de utilizá-las fora do contexto para o qual foram criadas...

[Felipe Maia 4]

Acredito que assim como se cria métodos e padrões para organização de código (leitura, escrita e edição) no que tange às futuras modificações seja por qual for o programador (desenvolvedor), deve-se sempre analisar as melhores formas de se trabalhar com um padrão de criação de um layout. O projetista nem sempre desenha o projeto pensando que dalí há 2 ou 3 anos o empregador vai querer mudar o visual para "elástico" ou fixo. Não se deve estipular o que seria mais vantajoso (monetariamente falando) se usar <table> ou <div>, a questão é, como fazer de um projeto, padrão de forma escalonável e flexível e que ao ser alterado, quer para um tamanho fixo ou para um fluido, elemantenha as características visuais como se fosse apenas um padrão de formas variáveis.

 

Devemos avalizar alguns pontos que são importantes:

 

XHTML/CSS (Padrão sem Tabelas)

• Desenho de projeto de fácil entendimento
  
• Blocos de códigos de fácil manipulação
  

 

 

HTML 4 (Tabelas)

• Desenho de projeto de fácil entendimento
  
• Blocos de códigos de difícil manipulação (alguns casos com múltiplas tabelas dentro de outras tabelas)
  

 

 

Quem projeta com Tableless e entende realmente o que faz, sabe que não é só de Faux Columns que se escreve códigos. Se você entende como funciona o posicionamento de blocos, você cria <div> com a mesma precisão de uma <table>, otimiza o tempo de trabalho e facilita a modificação sem a junção da programação (por programador).

 

Uma frase que eu gosto muito:

 

"Tempo é dinheiro, e dinheiro tem que se faz com qualidade de serviço"