Marco Gomes

Depois de vários posts falando sobre coisas que eu não entendo, vamos nos enveredar por um caminho que já conheço um pouco: Padrões Web, código XHTML e CSS, e relacionamento com clientes.

Valide seu código (não é sarcasmo, é real)

Validação não significa nada, é verdade, concordo plenamente que o que importa é o bom senso. De nada adianta perder 40 horas para economizar uma div no seu código se o site vai ter média de 5.000 visitas por mês. Se você está montando um hotsite que será retirado do ar em 3 meses, não vale a pena gastar metade do prazo do projeto em um problema que pode ser facilmente resolvido com um truque CSS (hack, workaround, não importa). Mas, acredite em mim, validação tem preço.

O cliente não sabe XHTML e CSS

O resultado do validador é como um diploma de ensino superior: na prática não vale muita coisa, a realidade pode ser contrária ao que o comprovante especifica, porém, ainda é a melhor garantia instantânea (pra quem não tem tempo ou conhecimento para avaliar melhor).

Seu cliente não sabe XHTML e CSS, ele não consegue olhar o código-fonte da página e perceber onde há erros reais e onde há aplicações de bom senso, ele não sabe a especificação do HTML e do XHTML de cabeça pra fazer uma verificação no código que você entregou, logo, ele precisa confiar em alguém.

Os validadores são a prova

Por motivos óbvios, ás vezes o cliente não pode confiar apenas na garantia do programador de interfaces que montou o site, em certos casos é bom ter a análise de alguém de fora do projeto. Para não contratar um consultor em Padrões Web, o que iria impactar em um aumento do custo final do projeto, ele pode confiar em um serviço especializado em verificar código de páginas web: o software validador.

Com a aprovação do validador, o cliente, leigo, tem uma prova que o documento segue regras internacionais. Além disso ele tem uma quase-garantia que as páginas irão funcionar em plataformas menos usuais, como dispositivos móveis e motores de busca. Existe a possibilidade do montador ter estruturado tudo errado, mas já que não dá pra contratar um consultor, pode-se conviver com esta dúvida.

Por isso, ao entregar seus projetos, entregue também uma documentação técnica com as principais características do código das páginas, neste documento inclua um anexo com print-screens dos resultados das análises de validadores, dê preferência aos mais conhecidos: daSilva, W3C Markup Validation Service, HiSoftware® Cynthia Says™, mas quanto mais validações, mais moral com o cliente.

Diferencial de mercado

E já que você vai entregar o projeto aprovado nos principais validadores, por que não usar isso como um diferencial?

Inclua em suas propostas que o projeto será verificado nos principais validadores de código e acessibilidade usados no mundo.

Diga que a conformidade com estes validadores cumpre o Decreto lei 5.296 de 2 de dezembro de 2004, que regulamenta a Lei 10.098 de 19 de dezembro de 2000, também conhecida como a Lei brasileira de acessibilidade, pode incluir também o cumprimento da Section 508, lei americana de acessibilidade.

Com isso, a montagem entra em conformidade com padrões internacionais, garantindo compatibilidade com dispositivos de acesso à web da atualidade e do futuro.

Se você fizer tudo certinho, nada do que está escrito acima é mentira e o cliente vai ficar ainda mais feliz por ter um site bonito e compatível com cafeteiras e relógios de pulso.

O objetivo deste texto não é ser uma verdade absoluta, tampouco pretendo abordar todos os mínimos detalhes do tema a ser discutido, pois, provavelmente poderia ser escrita toda uma coleção de livros e ainda assim não abordaria-se todas as minúcias de um tema tão complexo.

Observação: Eu posso estar errado.

As melhores pessoas para falarem sobre tableless é o pessoal do Tableless.com.br, por isso, não acredite em nada do que está escrito abaixo e só acredite neles quando se tratar deste assunto.

Ao contrário do que pode parecer, uma página tableless não é uma página totalmente sem tabelas, e sim, uma página com <table> para construir tabelas de dados e <div> para construir divisões de conteúdo.

Por quê? Porque dessa forma os browsers não PC vão rederizar o conteúdo de forma inteligível mesmo que as tabelas se percam na renderização. Também porque alguns browsers antigos (todas as versões do Internet Exploder incluídas) precisam baixar todo o conteúdo da tabela antes de exibi-la, ou seja, se todo o seu layout está dentro de uma tabela, o browser só vai exibir o conteúdo depois de baixar tudo, imagens, texto, animações etc.

_ Podre isso né?

Nem tanto, pois, lembre-se, as <table> foram feitas para formatar tabelas de dados – como preços de produtos, ou os ramais e os funcionários dos departamentos de uma certa empresa, logo, é aceitável que o browser baixe tudo antes de exibir, para não confundir o usuário com informações "incompletas".

Também faz parte desse "movimento" a utilização das tags para o que elas foram projetadas, por exemplo, se você tem um título, use: <h1>, se você tem um subtítulo: <h2>, <h3>, <h4> e assim por diante. Se você tem uma lista de itens – um Menu, por exemplo -, use: <ul> ou <ol> e <li> para cada item. Se vai formatar uma lista de definições: <dl>, <dt>, <dd>. Se você vai escrever uma definição: <dfn>, uma abreviação: <abbr>, um acrônimo: <acronym>, uma citação: <cite>, um código computacional: <code> e de forma semelhante existem dezenas de tags específicas para cada tipo dee conteúdo, o melhor mesmo é estudar a documentação do HTML 4.01 do W3C. Estes padrões é o que chamamos de webstandards.

_ Mas por quê isso, pra quê esse fundamentalismo todo em volta dos webstandards?

Xiita? Eu? Quê isso! Um dos motivos é que os arquivos ficam muito menores, podendo chegar a menos da metade do tamanho do arquivo não tableless. A redução é de alguns KB, mas em um site como o UOL ou Terra essa redução aparentemente insignificante pode traduzir-se em dezenas de terabytes economizados! Para ver mais exemplos como este veja os estudos de caso do Tableless.com.br.

Outro motivo é que marcados semânticamente, um browser não visual – como um leitor de tela ou um robô de busca – vai saber o que fazer com o texto que está com marcação semanticamente correta (conceitos de Semantic Web [Web Semântica]). Por exemplo, um leitor de tela ao invés de ler WYSIWYG – o que seria um verdadeiro caos – lê "What You See Is What You Get" se seu acrônimo estiver marcado assim: <acronym title="What You See Is What You Get">WYSIWYG</acronym>.

E não é só isso, um robô de busca – Google por exemplo – pode colocar em seu banco de dados que sua página tem a expressão "What You See Is What You Get" no seu conteúdo caso você use o <acronym>, se você não usar essa tag ele simplesmente não vai saber que WYSIWYG tem o mesmo significado. Isso implica que, se alguém procura por WYSIWYG, seu site vai aparecer no resultado, porém, se alguém procura por "What You See Is What You Get", bem, aí sua página rodou, você não estará no resultado.

A publicidade gratuita dos sites de procura é muito preciosa e não pode ser desperdiçada. Um texto marcado com <h1> por exemplo, recebe um escore muito maior que um marcado com <p>. No futuro, com a popularização da Semantic Web, poderemos criar mecanismos de busca específicos, como, por exemplo, um que procure apenas pela definição de "opróbrio", ou então pelo significado da abreviação LTDA.

_ Mas afinal, qual a diferença entre acrônimo e abreviação? Ou qual a diferença entre abreviação e acrônimo?

Bem, eu quebrei bastante minha cabeça para compreender isso… Acrônimo é uma sequência de letras que são lidas normalmente e representam várias palavras, como o já citado WYSIWYG ou IE, W3C, GNU, Linux, WinAmp. Nem sempre precisam ser todas maiúscilas, tampouco é regra que seja apenas uma letra de cada palavra, pode ser mais de uma letra como em WinAmp, por exemplo, o importante é que seu acrônimo represente mais de uma palavra. Abreviação é um modo reduzido de escrever uma palavra, como ex, Ms, Win, site, fone, Br, end etc.

_ Beleza, marquei meu texto todo seguindo os padrões, tudo lindo e cheio de tags malucas, mas e agora? Tá tudo feio e monocromático aqui no meu browser super moderno que aceita até applet Java! Deixa eu colocar tudo em um applet Java com uma reflexão bem linda e um super movimento bem legal?

Não faça isso, pelo amor de Deus, applet Java ninguém merece. Java é lento.

Bem, sua palavra chave é: CSS! Sim, as tais das folhas de estilo, é com elas que você vai formatar todo o seu conteúdo. Você quer que seu título seja roxo e com uma linda borda verde limão? Você quer que os itens da lista do seu menu esteja todo em apenas uma linha lá no canto direito na página? Você quer que todas os seus acrônimos apareçam em fonte Comic Sans com o fundo prateado? Você quer que as suas citações estejam em itálico e com tamanho 20% maior que o resto do texto? Tudo isso e muito mais pode ser feito via CSS, você nem tem idéia do que estas três letras podem fazer na sua vida… Mais poderosa que elas só Jesus Cristo*.

Como já foi dito, aprenda mais visitando Tableless.com.br e vá também ao W3C, se quiser ver exemplos do poder do CSS veja o CSS Zen Garden. A propósito, deus sempre pode te ajudar nessa busca por conhecimento.

Boa sorte pequeno gafanhoto.

* Exagero explícito e exageradamente forçado.

O objetivo deste texto não é ser uma verdade absoluta, tampouco pretendo abordar todos os mínimos detalhes do tema a ser discutido, pois, provavelmente poderia ser escrita toda uma coleção de livros e ainda assim não abordaria-se todas as minúcias de um tema tão complexo.

Observação: Eu posso estar errado.

HTML quer dizer Hypertext Markup Language – Linguagem de Marcação de Hipertextos – e é baseada na SGML (Standard Generalized Markup Language – Linguagem de Marcação de Generalizada Padrão) que é a base para a criação de todas as linguagens de marcação. Elas são documentadas pelo W3C (World Wide Web Consortium) que é o órgão que regulamenta os padrões da web, o W3C, por sua vez, foi criado por Tim Berners Lee (tio Bern), o criador da tão conhecida WWW.

O mais importante é que você entenda que HTML não é linguagem de programação, é linguagem de marcação, ou seja, se você aprende HTML isso não faz de você um programador, mas sim um marcador, que títulozinho mais fubanga né? Mas é verdade, sinto muito.

A diferença básica é que num programa você entra com dados esses dados são processados e devolvidos a de alguma outra forma. Como numa calculadora, você entra com os números e a operação a ser executada, o programa calcula e devolve o resultado. Já um texto marcado você simplesmente vê um texto com uma formatação especial e com algumas funcionalidades da linguagem de marcação em questão, como hiperlinks, figuras, animações, botões etc.

Quer que eu simplifique mais? Simples, numa linguagem de marcação, você não pode dizer "some 2+2 e exiba o resultado na tela", mas você pode dizer "exiba ‘MarcoGomes.com’ em negrito, maior que o texto normal e com um hiperlink para http://www.marcogomes.com". Entendeu?

Sintetizando: Na marcação, você marca, na programação você executa uma sequência de comandos lógicos.

Exemplos de marcação HTML: <strong>Este texto aparecerá com ênfase (normalmente negrito)</strong>, <h1>Oi, eu sou um título grande e destacado</h1>, <h2>Eu sou um título menos importante que o h1, mas ainda assim, mais importante que o h3.</h2>.

O problema, é que com o tempo, os "sobrinhos que fazem página" (inclusive eu) começaram a usar as tags HTML de maneira diferente do seu propósito inicial, o erro mais comum era usar as tabelas para dividir o conteúdo do site, a tag de divisão de conteúdo é <div> e não <table>. É como se você usasse um carro como peso de papel, é possível, mas é muito mais inteligente usar para isso uma pedra, uma pequena estátua ou seu CD-ROM do Windows.

A web não foi projetada exclusivamente para PC’s, mas sim para ser acessível de qualquer meio que tivesse acesso à internet, como PDA’s, celulares, leitores de tela, browsers em braile, geladeiras, programas que vasculham a rede em busca de informações específicas (robôs como o do Google) e vários outros que ainda podem surgir.

Houve um momento que os documentos HTML estavam ficando tão complexos e ininteligíveis que o só podiam ser acessados por PC’s e a maioria das páginas apenas com o Microsoft Internet Exploder. O W3C teve que intervir e em 1999 lançou o HTML 4 em que recomendava a separação de conteúdo – que deveria ser feita com um arquivo HTML – e formatação – que deveria ser feita com um arquivo CSS. Também começou a chamar atenção dos desenvolvedores para a importância de ter suas páginas em HTML válido e com alto nível de acessibilidade.

Com isso, surgiu o movimento tableless, mas isso é assunto para um outro post.