No início, fabricantes de browsers, W3C e desenvolvedores começaram quase que ao mesmo tempo.

Neste começo não brotaram desenvolvedores web do chão. Essa profissão não existia. Os primeiros que trabalharam nessa área, migraram de profissões parecidas: quem era programador desktop naquele tempo, começou a programar para web. Quem era designer de impresso, começou a fazer design para web. Os programadores estavam se acostumando com a maneira nova de criar sistemas e sites. E designers estavam se habiatuando às diferenças que existiam no design para web e impresso. Haviam muitas coisas para se acostumar, começando pelos erros de compatibilidade.

O W3C

O W3C foi criado para regulamentar e criar padrões para a publicação de conteúdo na web. Quando ele começou, não haviam documentos completos, com listas e regulamentos explicando cada um dos padrões. Esses documentos eram rascunhos, muitas vezes incompletos e com apenas uma descrição do que seria aquele padrão.

Com a falta de documentação completa e detalhada, os browsers aproveitavam para criar códigos proprietários, dificultando o desenvolvimento.

Os browsers

O Netscape (antigo Mosaic), era o browser com a maior base de usuários. Para ser sincero, não haviam muitos browsers concorrentes naquela época. A Microsoft aproveitou o poder que ganhara com a distribuição do Windows com a IBM, e criou o Internet Explorer para concorrer com o Netscape. Foi aí que a Guerra dos Browsers começou.

A guerra por usuários somada com a falta de padrões resultou em códigos proprietários. Conquiste os desenvolvedores e conquistará a web.

Todo esse tumulto no começo da web fez com que o desenvolvimento de sites se tornasse mais complicado, confuso. Em conseqüência, a mão de obra se tornava mais cara e o custo de desenvolvimento também. Era caro comprar um site e era mais caro ainda manter esse site.

Era preciso fazer duas versões: uma para Internet Explorer e outra para Netscape. Qualquer atualização ou alteração de layout, era necessário modificar as duas versões. Isso significava trabalho em dobro, e o custo aumentava.

A Cavalaria - WaSP

Um grupo de desenvolvedores, na maioria designers, formaram um movimento chamado Web Standards Project - WaSP. Um grupo cuja missão seria divulgar os Padrões Web como guias para o desenvolvimento web. O projeto era encabeçado por profissionais como Jeffrey Zeldman, inconformados com o caminho que o desenvolvimento web estava caminhando. E eles tinham toda a razão.

A primeira grande coisa que fizeram foi convencer a Netscape a doar para a comunidade o engine do browser. Um grande feito que, se não fosse alcançado, hoje não teríamos a fundação Mozilla, com seu browser Firefox.

A segunda missão foi fazer com que os fabricantes de browsers seguissem as idéias e recomendações do W3C.

O diferencial, naquele tempo, era apenas o número de usuários. Não haviam add-ons, interface interligada com serviços sociais, leitores de feeds, nem nada do gênero. Seguir o W3C era dizer adeus ao código proprietário e abrir oportunidades para os desenvolvedores a criarem sites para o browser concorrente.

Outro objetivo do grupo era fazer com que os desenvolvedores também adotassem os Padrões do W3C. E esse objetivo está sendo cumprido até hoje.

A resitência de hoje, não é nada com a resistência encontrada há 5 anos atrás. Os desenvolvedores estão mais aberto às novas propostas e os novos profissionais já começam aprendendo da maneira correta.

Hoje as coisas estão bem mais fáceis. Browsers e desenvolvedores lutam em favor dos padrões. W3C e entusiastas estudam novos padrões e pedem sugestão dos profissionais.

Com o amadurecimento das partes, o conhecimento se renova e desenvolver para web fica mais divertido.

Fonte: Diego Eis, iMasters

O dilema pressa versus perfeição atrapalha os bons desenvolvedores quando o cliente pede soluções cujo código não valida 100% em função dos padrões da web. Há meio termo?

Todos sabemos da importância suprema de entregar sites 100% aderentes a padrões de senvolvimento web. Ao mesmo tempo, o cliente pressiona por entregas para ontem e prazos impossíveis. Nas agências e grandes produtoras esta pode ser uma questão já mais estruturada, mas nas micro-empresas é um dilema muito comum e recorrente na cabeça dos pobres desenvolvedores.

Muitas vezes a aderência aos web standards nem é um pré-requisito no projeto, porém os programadores que entendem a essência dos web standards têm como norma utilizar os padrões em seus projetos.

O grande problema surge quando o cliente pede algo “lunar” e nós, desenvolvedores, temos que entrar em um mundo paralelo highlander solicitado por ele e desenvolver soluções à altura. O problema é que geralmente soluções mirabolantes pedem implementações mirabolantes; em consequência o nível de manipulação do documento XHTML por meio de Javascript é alto e muitas informações são expostas na marcação HTML, para que o JavaScript possa se guiar.

Certamente alguns leitores vão lembrar de um caso parecido. O grande pensamento vem à cabeça:

- O sistema não esta validando, e agora? Eu só consigo implementar esta solução desta forma; não consegui pensar em outra forma de implementar e fazer com que meu código consiga se guiar de maneira eficiente, para manipular este documento.

- Perco mais um, dois ou três dias pensando em uma nova solução somente para implementar esta solução sob o plano B ou deixo este erro de validação passar e sigo em frente com o cronograma?

Sem desespero. Já se foi o tempo em que os programadores eram neuróticos por validação. É importante entender (e repetir) que validar o seu código pela W3C nada mais é do que verificar se ele está “gramaticalmente” escrito de maneira correta. E o fato de estar validado não garante que o seu código será renderizado da mesma forma em outros navegadores.

E entramos no dilema da guerra dos browsers. Você segue os padrões, mas o browser do seu cliente não, e aí? O que acontece depois?

Se você se preocupa com os padrões, ótimo! Deve!

Colocar em risco o ciclo de vida do projeto por causa de um erro de validação não compensa para você nem para sua empresa. Pode ter certeza que se você tiver somente este erro, o seu site/sistema não vai se comprometer ou deixar a desejar para o seu cliente.

Pense muito bem na hora de fazer esta decisão. Se você tem um código 100% validado, ótimo! Se você tem próximo a 95% validado, ótimo também!

Houve o tempo onde as pessoas eram loucas e fissuradas pelo validador da W3C. O validador deve somente ser usado como parâmetro para verificar a sintaxe do seu código XHTML. Muitas coisas podem passar despercebidas na correria do desenvolvimento, da mesma forma que muitas coisas podem ser corrigidas sem comprometer o andamento do projeto com a “ajuda” do validador.

Use o validador como uma ferramenta aliada e não como uma ferramenta inimiga.

O W3C é uma organização que documenta “recomendações” e não “obrigações”. Existem recomendações que são extremamente fundamentais para a renderização e comportamento correto em diferentes plataformas, porém temos que ter um meio termo para tudo.

Links úteis:

* Site Oficial da W3C
* W3C - Markup Validator Service
* W3C - CSS Validator Service
* W3C - RDF Validator Service
* Web Standards Group

A questão tem muitos lados e espero ter contribuído.
Fonte: Webinsider, Igor Escobar

Recentemente, vi alguns profissionais e blogueiros revoltados com a repercussão do termo “Tableless” na mente dos pobres alunos e aprendizes.

Meu objetivo com este texto é tentar salvar as pobres mentes puras de alguns destes aprendizes que talvez cheguem até aqui através dos buscadores, sites que estejam linkando a matéria, etc. Provavelmente grande parte dos leitores já saibam exatamente o significado deste termo e como utilizar esta técnica na prática. O aprendizado é inevitável, cedo ou tarde você acaba descobrindo o que é Tableless de fato.

O Problema

O termo Tableless veio à tona no Brasil em 2003, pelos amigos Elcio Ferreira e Diego Eis, fundadores do site www.tableless.com.br, que incentiva o uso da técnica, com exemplos, mostrando benefícios, boas práticas de desenvolvimento e diversos assuntos que giram em torno do código fonte do desenvolvedor. Para a maioria destes aprendizes, este site pode se tornar evangelizador (rs), você entra crendo no poder das tabelas e sai como table-killer.

Esta é a visão interpretada pela maioria das pessoas. Sempre que alguém começa a ler sobre o termo, logo quer sair botando a mão na massa, e contar para todo mundo: - Agora eu sei Tableless, é fácil, é só nunca mais usar tabelas!

As pessoas tendem a ler o conteúdo pela metade ou rápido demais, ignorando detalhes, afinal, a sua teoria já esta embutida no seu próprio título certo? Errado!

Eu não sei ao certo o que acontece. É difícil identificar de quem é a culpa, enfim, de duas, uma:

Pode ser nossa (disseminadores de conteúdo), que passamos a informação as vezes incompleta, sem muita clareza, omitindo alguns detalhes, ou a culpa é do próprio leitor.

Tableless - Definitivo

O termo Tableless, nesse começo de 2008, faz 5 anos que vem sendo falado, estudado e colocado na prática no Brasil.

O Tableless é um técnica de desenvolvimento web cujo o foco esta exclusivamente no seu código fonte. Antes de aplicar o tableless e sair por ai saltitando, estude a semântica das tags, amplie o seu conhecimento em relação às tags, se você não conhece o HTML a fundo, sua capacidade de criação de interfaces com Tableless fica muito limitada, e exposta ao famoso “jeitinho brasileiro” ou gambiarras, como preferir.

Tableless não é NUNCA mais usar tabelas, Tableless é usar as tags do HTML respeitando os seus valores semânticos, se você programa sob esta filosofia, automaticamente seu código no final será um código, semântico, compatível e claro, Tableless.

As tabelas foram criadas para exibição de dados tabulares e não para estruturação de layout e criação de interfaces.

A W3C diz:

“Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media.”

Tabelas não podem ser utilizadas meramente para definição da estrutura do seu layout, isso provavelmente vai gerar problemas na rederização para midias não visuais.

Se você parar para fazer uma análise, vai ver que é uma resposta meio lógica, se a web 2.0 encoraja o uso dos padrões web para o desenvolvimento, por que o Tableless, que é um técnica que surgiu junto com o amadurecimento da web, iria encorajar o contrário?

O termo talvez gera dúvida na cabeça das pessoas por que todos os lugares que você encontra fonte de informação principalmente no tableless.com.br fala-se muito em livre-se das tabelas, o fim das tabelas, tabelas nunca mais etc.

O autor do texto repete muito isso somente para fixar o objetivo do técnica e enfatizar o resultado em si. Mas em nenhum momento é citado que você deve esquecer as tabelas, se fosse somente isso, esquece-las, seria simples, tudo gira em torno de como se virar sem elas para fazer o básico o resto é com você.

Tableless = Menos tabelas (rs) e não livre de tabelas ou sem tabelas ou qualquer outra variante.

Aceita uma dica? Não leve as coisas tão ao pé da letra, tente entender o por quê das coisas antes de mudar.

Eu sei que este texto não vai chegar nem a 0,00000001% das pessoas que estão começando com desenvolvimento web, mas se este texto pelo menos ajudar uma pessoa a pensar diferente sobre o Tableless se encontrando na definição dos termos já vou ficar contente.

Fonte: iMasters, Igor Escobar