Words

99,9% dos sites Web estão Obsoletos
Um excerto de “Designing with Web Standards”

Por Jeffrey Zeldman

Uma doença de igualdade de oportunidades aflige quase todos os sites na Web, desde as mais humildes páginas pessoais até aos sites milionários dos gigantes grupos empresariais. Astuta e traiçoeira, a doença passa largamente despercebida porque se baseia em normas da indústria. Apesar dos seus donos e gestores ainda não se aperceberem disso, 99,9% de todos os sites web estão obsoletos.

Estes sites podem ter boa aparência e funcionar bem nos browsers actuais, cujos nomes terminam nos números 4 ou 5. Mas fora desses ambientes tolerantes a falhas, os sintomas de doença e decadência começaram já a aparecer.

Nas últimas versões do Microsoft Internet Explorer, Netscape Navigator, e Mozilla (o browser open source, baseado no Gecko, cujo código é o motor do Netscape Navigator, Compuserve, e outros), alguns layouts cuidadosamente construídos começaram a ter problemas, e comportamentos dispendiosamente concebidos deixaram de funcionar. À medida que estes browsers evoluem, o desempenho dos sites continua a deteriorar-se.

Nos browsers alternativos, em leitores de écran usados por pessoas com deficiências, e em dispositivos cada vez mais populares que vão desde os Palm Pilots™ aos telefones celulares com acesso à web, muitos destes sites nunca funcionaram e ainda não funcionam, enquanto que outras funções funcionam marginalmente na melhor das hipóteses. Dependendo das necessidades e do orçamento, os donos e produtores de sites têm ignorado estes browsers e dispositivos alternativos, ou então suportam-nos detectando a sua presença e fornecendo-lhes código e marcação personalizados a cada uma das versões e tipo de browser.

Enquanto que as versões alternativas dos sites levam os utilizadores de browsers sofisticados como o Opera a uma má experiência quando comparada com o Explorer ou o Netscape, nas versões wireless a experiência é pior. Muitos dependem de linguagens de marcação wireless pouco suportadas e obsoletas.

Estas práticas desperdiçam tempo e dinheiro. Nenhum destes abunda; ambos têm sido particularmente escassos, especialmente desde que a economia ocidental entrou em recessão. Alem do mais, estas práticas não resolvem o problema. Os sites continuam a não funcionar. Alguns utilizadores ainda ficam excluídos.

Pensamentos passados

Levante-se a camada visível de qualquer grande site, desde a Amazon à Microsoft.com, desde a Sony à ZDNet. Examine-se a sua marcação tortuosa não standard, os seus scripts proprietários com ActiveX e JavaScript (por vezes com erros), e o mau uso de Cascading Style Sheets – quando as usam de todo. É um mistério que estes sites funcionem em qualquer browser.

Estes sites funcionam nos browsers antigos porque as últimas quatro a cinco gerações do Netscape Navigator e Internet Explorer não se limitavam a tolerar marcação não standard e código específico de cada browser; estes na realidade encorajavam o desenvolvimento descuidado e o uso de scripts proprietários, dentro da batalha para dominar o mercado dos browsers.

Frequentemente, os sites que não respeitam os standards funcionam nos browsers antigos porque os seus donos investiram em ferramentas de publicação que acomodam as diferenças entre os browsers e criam múltiplas versões não standard, afinadas de acordo com as características de cada browser e plataforma. Esta prática testa a paciência dos utilizadores de ligações dial-up, desperdiçando largura de banda em código desnecessário, tabelas aninhadas dentro de outras tabelas, truques com imagens transparentes para corrigir espaçamento, e o uso de tags e atributos inválidos ou fora de uso.

Ao mesmo tempo, estas múltiplas versões desperdiçam a largura de banda a um custo elevadíssimo. Quanto maior o site e o tráfego que gera, maior a quantidade de dinheiro desperdiçado em ligações aos servidor, redundâncias, truques com imagens, código e marcação complexos e desnecessários.

Yahoo! homepage

O aspecto do Yahoo – relativamente simples.

Yahoo! code

Aquilo que faz o aspecto do Yahoo – código e marcação intrincados.

A página principal do Yahoo é servida milhões de vezes por dia. Cada byte desperdiçado em truques com HTML desactualizado é multiplicado por um número astronómico de páginas visitadas, resultando em gigabytes de tráfego que sobrecarregam os servidores do Yahoo e adicionam custos enormes às despesas gerais.

Se o Yahoo substituísse as tags <font> já descontinuadas e que consomem muita largura de banda, por CSS que consome muito menos, o custo de servir cada página diminuiria grandemente, e os lucros da companhia aumentariam consequentemente. Então porque é que o Yahoo ainda não fez essa mudança?

Apenas podemos concluir que a companhia quer que o seu site tenha exactamente o mesmo aspecto nos browsers de 1995 que não suportam CSS, e nos browsers modernos que suportam CSS. A ironia é que ninguém para alem dos gestores do Yahoo se importa com o aspecto que o Yahoo tem. O sucesso tremendo do site deve-se ao serviço que fornece, não à beleza do seu design visual (que é inexistente).

O facto de esta companhia, brilhante em outros aspectos, gastar uma largura de banda incalculável para que o seu site tenha um aspecto que ninguém aprecia, diz tudo sobre a forma de pensar dos programadores que consideram a compatibilidade com as versões anteriores mais importante que a razão, a usabilidade ou os seus próprios lucros.

O que é que estes programadores querem dizer com “compatibilidade com versões anteriores”? Usar código e marcação não standard (ou descontinuada) para assegurar que todos os visitantes tenham a mesma experiência, quer estejam a usar o Netcape Navigator 1.0 ou o Internet Explorer 6. Vista como o Santo Graal das práticas de desenvolvimento profissionais, a “compatibilidade com versões anteriores” soa bem em termos teóricos. Mas o custo é demasiado alto e a prática tem sido baseada numa mentira.

Não existe verdadeira compatibilidade com versões anteriores. Há sempre um ponto de rotura. Por exemplo, nem o Mosaic (o primeiro browser visual) nem o Netscape 1.0 suportam layouts HTML baseados em tabelas. Por definição, então, aqueles que usam estes browsers antigos não podem ter a mesma experiência visual que aqueles que vêem a Web usando browsers que lhes sucederam, como o Netscape 1.1 ou o MSIE2.

Os programadores e clientes que se empenham pela compatibilidade com versões anteriores têm inevitavelmente de escolher um browser como base (digamos, o Netscape 3) antes do qual não valerá a pena fazer grande esforço. Para suportar esse browser base e os que se seguirem, os produtores de sites acrescentam camadas de marcação com uma série de truques e soluções não standard, que adicionam peso a cada página. Ao mesmo tempo, escrevem múltiplos scripts para acomodar os vários browsers que decidiram suportar, e usam formas de detectar a versão do browser, para dar a cada um deles o código que mais lhe agrada. Ao fazer isto, estes programadores aumentam ainda mais o peso das páginas, reforçam a carga nos servidores, e asseguram que a corrida contra a obsolência perpétua continuará até que lhes acabe o dinheiro ou as suas empresas fechem.

Enquanto que algumas empresas prejudicam a sua rentabilidade ao tentar assegurar que até os browsers mais antigos vejam os seus sites exactamente da mesma forma que os browsers novos, outras decidiram que apenas um browser importa. Num esforço mal orientado para reduzir despesas, um numero crescente de sites são construídos para funcionar apenas no Internet Explorer, e por vezes apenas na plataforma Windows, deixando assim de fora 15% a 25% de potenciais visitantes e clientes.

Não vamos fingir que percebemos o modelo de negócio de uma empresa que diga que não a até um quarto dos seus potenciais clientes. O número de clientes perdidos devido a esta aproximação míope deveria espantar qualquer gestor racional. De acordo com estatísticas compiladas pela NUA Internet Surveys (www.nua.ie/surveys/), mais de 540 milhões de pessoas usavam a Web em Fevereiro de 2002. É fazer as contas.

Digamos que não nos importamos de perder até 25% das pessoas que escolhem visitar o nosso site. A abordagem “apenas para IE” continua a não fazer sentido, porque não há garantia que o IE (ou os outros browsers para PC) continuem a dominar o espaço web.

Alguns anos antes de este livro ser escrito, o browser Netscape Navigator tinha uma margem de mercado maior que aquela que o Internet Explorer tem hoje. Na altura, a sabedoria convencional defendia que o Netscape era o único browser que contava, e que os programadores trabalhavam com base nele. Incontáveis milhões de dólares depois, o mercado mudou. Os sites feitos apenas para o Netscape foram descartados na lixeira ao lado da Auto-estrada da Informação.

Poderá o mesmo destino estar reservado para os sites feitos apenas para o IE? Embora possa parecer inconcebível, não há forma de prever. Na Web, a única constante é a mudança. Se tomarmos em conta o uso cada vez mais generalizado de dispositivos não tradicionais com acesso à Internet, a noção de desenvolvimento com base nas características de alguns browsers de PC às custas de todos os outros browsers e dispositivos começa a revelar-se como a decisão tola de negócio que de facto é.

Além do mais, como este livro vai mostrar, os standards tornam possível desenvolver tão facilmente e rapidamente para todos os browsers e dispositivos como para apenas um. Entre os custos exponenciais de criar versões diferentes de acordo com o browser e as vistas curtas de construir para apenas um browser, os standards web são a única abordagem à produção para a web que faz o mínimo de sentido.

Nem as técnicas dispendiosas de adaptar os sites conforme a versão do browser, nem a decisão deliberada de suportar apenas um browser ou plataforma vão ajudar os sites de hoje a funcionar nos browsers de amanhã, nem vingar no mundo em constante mudança que existe para além da secretária. Se estas práticas continuam, os custos e complexidades vão apenas escalar até que apenas as maiores empresas tenham recursos financeiros para construir sites web.

A Microsoft venceu a Guerra dos Browsers, mas todos nós perdemos algo mais importante: a possibilidade de criar uma Web utilizável e acessível, construída sobre standards de indústria comuns. Perdemo-la quando os designers e programadores, na tentativa de acompanhar as exigências de produção durante o curto período de boom da Internet, aprenderam formas não standard e específicas de um dado browser de criar sites, trazendo-nos à situação actual cujo nome é obsolência.

O período de obsolência no desenvolvimento para a Web está a morrer neste momento, levando com ele inúmeros sites. Se possui, gere, desenha ou constrói sites, os sinos dobram por si.

A doença

Desde cedo na formação de um programador, ele ou ela aprende a expressão: “Garbage In, garbage out”. De uma forma simples, no mundo da programação, se escrevermos o código correctamente, ele funciona. Se o escrevermos de forma incorrecta, ele falha. Linguagens como o C++ e o Java não encorajam apenas práticas correctas de código, exigem-nas.

De igual forma, de entre as primeiras coisas que um designer gráfico aprende, é que a qualidade do material original determina a eficácia do produto final. Se tivermos por base uma fotografia de alta resolução e qualidade, o produto impresso ou o gráfico para a Web terá boa aparência. Se tentarmos trabalhar com uma fotografia ou imagem de baixa resolução para a Web, o resultado final não valerá a pena ser visto. Conseguimos converter um EPS de alta qualidade num logotipo para uma página web optimizado adequadamente, mas não conseguimos converter um GIF de baixa resolução num logotipo de alta qualidade para a web, impressão ou TV. “Garbage in, garbage out.”

Os principais browsers não funcionam da mesma forma. Permissivos até níveis absurdos, admitem sem hesitar marcação incompleta e erros nos links para ficheiros de JavaScript, mostrando o site em muitos casos como se tivesse sido criado correctamente. Esta permissividade encorajou os designers e programadores a desenvolver maus hábitos que passam largamente despercebidos. Ao mesmo tempo, fez com que estes vissem as tecnologias como o XHTML, o CSS e o JavaScript como primitivas.

Aqueles que não respeitam uma ferramenta provavelmente não a usarão correctamente. Considerem o seguinte excerto de código, retirado de um site de comércio electrónico de uma empresa que opera num mercado muito competitivo, que aqui se reproduz em toda a sua glória:

<td width="100%"><ont face="verdana,helvetica,arial"
size="+1" color="#CCCC66"><span class="header"><b>Join now!
</b></span></ont></td>

A tag absurda “ont” é uma gralha da tag “font” já descontinuada – uma gralha que se repete milhares de vezes por todo o site, graças a uma ferramenta de publicação eficiente. Aparte esse erro, este código deverá ser-lhe familiar. Pode até parecer-se com o que usa no seu site. No contexto desta página web, tudo o que na realidade é necessário é o seguinte:

<h2>Join now!</h2>

Combinada com a regra apropriada na respectiva folha de estilo, a marcação acima, mais simples e estrutural, fará o mesmo que a outra, que é pesada, inválida e não standard. Poupa-se assim largura de banda ao servidor e aos visitantes, e facilita-se a transição para um site mais flexível, baseado em XML. O mesmo site de comércio electrónico inclui o seguinte link JavaScript, quebrado:

<script language=JavaScript1.1src="http://foo.com/Params.
richmedia=yes&etc"></script>

Entre outros problemas, o atributo language sem as aspas liga-se de forma enganosa à tag source. Por outras palavras, está a ser dito ao browser para usar uma linguagem de script que não existe ("JavaScript1.1src"). Por qualquer parâmetro racional, o site deveria falhar, alertando os produtores para o erro e pedindo-lhes para o corrigirem de imediato. No entanto, até recentemente, o JavaScript deste site funcionava nos browsers mais conhecidos, perpetuando o ciclo de sites mal concebidos e de browsers que os adoram. Não admira muito que os bons programadores vejam frequentemente o desenvolvimento do front-end como um voodoo nada estimulante e indigno de respeito.

À medida que os novos browsers vão respeitando os standards web, vão-se tornando cada vez mais rigorosos em relação ao que esperam dos designers e programadores, tornando-se assim intolerantes a código e marcação inválidos. “Garbage in, garbage out” começa a impor-se no mundo dos browsers, tornando o conhecimento sobre standards numa necessidade para qualquer pessoa que desenhe ou construa sites web.

Os danos não são irreparáveis. Podemos construir sites de uma forma melhor, que funcione em diferentes browsers, plataformas e dispositivos, solucionando os problemas de obsolência e da exclusão de parte dos utilizadores, enquanto se abre caminho no sentido de uma Web mais poderosa, mais acessível, e desenvolvida de forma mais racional.

A cura para a doença de obsolência pode ser encontrada num conjunto nuclear de tecnologias suportadas em comum, a que se chama genericamente “standards web”. Ao aprender como desenhar e construir sites usando os standards web, conseguimos garantir a compatibilidade com o futuro do sites que produzimos.

“Escrever uma vez, publicar em todo o lado”, a promessa dos standards web, é mais que um desejo: está hoje a ser conseguida, usando métodos que vamos explorar neste livro. Mas enquanto que os principais browsers já suportam estes standards e métodos, a mensagem ainda não chegou a muitos designers e programadores, e ainda estão a ser construídos muitos sites sobre as areias movediças do código e marcação inválidos. Este livro espera modificar este cenário.

A cura

Depois de uma longa luta dos designers e programadores contra os fabricantes dos principais browsers, podemos finalmente utilizar técnicas que garantam a aparência e comportamento dos nossos sites, não simplesmente no browser de um fabricante, mas em todos.

Arrancadas a ferros pelos membros do World Wide Web Consortium (W3C) e por outras entidades de standards, e suportadas pelos browsers actuais desenvolvidos pela Netscape, Microsoft, e outros, as tecnologias tais como Cascading Style Sheets (CSS), XHTML, ECMAScript (a versão standard do JavaScript) e W3C DOM permitem aos designers:

Antes de podermos aprender como os standards atingem estes objectivos, devemos examinar os velhos métodos que eles vêm substituir, e descobrir exactamente como as velhas técnicas perpetuam o ciclo de obsolência. O Capítulo 2 revela-o.

Excerto de Designing with Web Standards, por Jeffrey Zeldman, publicado pela editora New Riders. Copyright © 2002-2003 New Riders and Jeffrey Zeldman. Utilizado com permissão da editora New Riders.
Publicado na versão original em Setembro de 2002 na Digital Web Magazine.
Versão Portuguesa por: Pedro Mendes

Words

Referrers