Qualquer um que codifique HTML, ou mesmo use um editor WYSIWYG, já esbarrou no problema. Se você trabalha com internet, já deve ter tido também esse problema. O código se tornou complexo, com várias tabelas, uma dentro da outra. Vários frames, com uma porção de scripts para manter o conteúdo atualizado entre eles. Uma parte da aplicação rodando em um pop–up, com um script que atualiza o conteúdo principal.

Então, cumprindo a lei de Murphy, um dos seguintes fatos indesejáveis acontece:

1. Um cliente liga reclamando que o site está dando um tal de “erro de script” quando clica num link, você tenta, mas não consegue reproduzir o erro em nenhum navegador.
2. Alguém da diretoria resolve que os títulos devem ser azuis, não vermelhos. E você se põe a localizar <font face=”verdana” size=”5″ color=”red”> para poder mudar a cor.
3. Alguma tabela não fechada corretamente está dando problemas no Netscape, mas o código tem cinco tabelas aninhadas e você perde um dia tentando achar o defeito.
4. Você percebe uma certa demora para carregar algumas páginas, vai conferir o código e descobre algumas coisas assim: <font
   face=”Verdana”><b></b><i></i><font
   size=”1″><b></b></font><font
   face=”Arial”>Texto</font></font>

Que fazer? É claro que com muito cuidado e talento esse tipo de problema pode ser evitado, mas isso envolve uma quantidade de trabalho insana. Já vi muitos projetos onde se gastou mais tempo preso nas entranhas de um código complexo do que em qualquer outra fase do projeto.

Tem um pessoal na web que propõe uma solução bastante interessante para isso. É a turma do WaSP (www.webstandards.org.) As soluções não são apenas uma lista de novas tecnologias, mas também uma filosofia de desenvolvimento baseada na simplicidade.

Baseado nessa filosofia da simplicidade, que tem me rendido resultados surpreendentes, gostaria de fazer algumas sugestões interessantes:

XHTML

Quem já trabalha com XML certamente percebeu o poder da flexibilidade e da simplicidade. É impossível escrever um XML com erros de sintaxe, porque os interpretadores reclamam imediatamente. É muito simples escrever documentos XML, sendo fácil extrair dados de qualquer banco de dados e transformá-los em XML (a maioria dos SGBDs incorpora ou tem planos de incorporar o suporte nativo a XML.)

Através da poderosa linguagem XSL e da farta oferta de parsers gratuitos, XML pode ser transformado em praticamente qualquer formato de arquivo.

XHTML nada mais é do que uma forma de escrever um documento HTML de modo que ele também seja um documento XML válido. Ou seja, seu documento HTML ganha a coerência e flexibilidade de um documento XML, podendo ser facilmente lido por ferramentas automáticas e convertido em outros formatos de arquivos. Com XHTML torna-se muito fácil oferecer os dados do seu site através de WAP ou de um RSS (http://rssficado.pilger.inf.br) por exemplo. Torna-se fácil também transformar o resultado de uma consulta a banco de dados ou um documento XML numa página web.

A boa notícia é que é muito fácil escrever XHTML. Qualquer um que escreva HTML pode aprender a fazê-lo sem muita dificuldade. Existem inclusive uma série de ferramentas interessantes para tornar esse processo mais produtivo, como o excelente HTML Tidy (http://tidy.sourceforge.net) que tem uma eficiência impressionante para uma ferramenta automática.

CSS e a abordagem semântica

Como você cria um título num documento HTML?

O meio comum hoje em dia para fazê–lo é: <font face=”Arial” size=”4″ color=”blue”>Texto do Título</font>.

Quando eu estudei HTML, em 1996, aprendi que existia uma tag específica para criação de títulos. É a tag h1. Assim, a maneira de se criar um título em HTML seria: <h1>Texto do Título</h1>.

Extremamente mais simples, não é verdade? E torna o código também mais significativo. Assim um interpretador pode saber, por exemplo, onde estão os títulos no meio do texto. Ou seja, esta abordagem dá significado semântico ao código. Aquele tag passa a significar alguma coisa, mesmo que não seja vista num browser que renderize a fonte maior e azul que você tinha planejado.

Aliás, por falar no texto azul, se você usar a segunda abordagem seu título será exibido com os estilos padrão do navegador, e seu azul vai para o beleléu. Como você não quer perder a bonita formatação que havia planejado, aqui entra uma segunda linguagem, o CSS. Com CSS você pode colocar toda essa informação sobre formatação num arquivo externo. Assim você fica com um arquivo HTML apenas com informação (que fica muito mais simples, organizado e rápido de se escrever) e mantém toda a formatação num arquivo externo. Se um dia seu chefe resolver que todos os títulos do site tem que ser vermelhos ao invés de azuis (acredite, isso é muito comum) você só precisará alterar uma palavra em um único arquivo e todos os títulos do site estarão automaticamente ajustados.

No tables

Tabelas são um recurso muito útil do HTML. Sem tabelas como exibiríamos informações como uma lista de produtos, um extrato bancário ou um calendário? O problema é que tabelas tem sido usadas para muito mais do que isso. É preciso colocar o menu ao lado do texto? Cria–se uma tabela. É preciso que o texto tenha uma largura delimitada? Cria–se uma tabela. Imagem junto ao texto? Menu no cabeçalho? Duas colunas de texto? Tabela neles!

E como fica, nessa situação, a semântica do documento? Como você deve imaginar, não á aqui aquela prática separação entre informação e formatação. Além disso, temos um outro sério problema: em browsers antigos, ou mesmo em browsers modernos mal desenvolvidos, como o Internet Explorer, as tabelas só são exibidas depois que a última tag </table> chega ao navegador.

É por isso que, quando você está conectado via dial–up, em alguns sites a tela fica em branco durante longos segundos (às vezes minutos) até que é exibido de uma vez só.

Abrir mão de tabelas para montar layouts vai tornar seu código muito menor, mais simples e organizado. Vai também centralizar a formatação, colocando tudo que se refere a layout em um único arquivo. Imagine a facilidade de manutenção. Melhora também a experiência do usuário, pois a informação é exibida instantaneamente, assim que chega ao browser.

Dá–se a esta abordagem o nome de tableless. Apesar do nome, não é a ausência total de tabelas, mas o seu uso apenas onde é semanticamente justificável. De lambuja, um documento tableless bem pensado vai funcionar em qualquer navegador, em qualquer sistema operacional, mesmo em PDAs.

No frames, No pop-ups, no DHTML

Pense muito antes de aplicar uma solução baseada em frames, DHTML, scripts absurdos, pop–ups, plugins, ActiveX, Applets ou qualquer outra tecnologia que quebre essas duas premissas da internet:

– A web é um ambiente multiplataforma.
– Cada documento na web tem um endereço associado a ele.

Não vou me alongar nesse tópico, mas gostaria que você tomasse um tempo para ler:

• http://www.wired.com/news/culture/0,1284,55675,00.html
• http://www.digital–web.com/features/feature_2001–6.shtml
• http://www.digital–web.com/features/feature_2002–09.shtml
• http://www.useit.com/alertbox/990530.html
• http://www.useit.com/alertbox/9612.html

Vamos com calma

O interessante dessa abordagem baseada na simplicidade é que você não precisa fazer tudo de uma vez. Se está inseguro para começar, pode apenas eliminar as tags <font> e criar um arquivo CSS único. Ou pode começar usando os recursos de XML do seu banco de dados para gerar XHTML, ou criando um RSS. O importante é começar a simplificar antes que você fique maluco! [Webinsider]

.

Elcio Ferreira

Elcio Ferreira (elcio@tableless.com.br) é diretor de tecnologia da Visie e um dos autores do site Tableless