99,9% dos Websites Estão Obsoletos

capítulo um
99,9% dos Websites
Estão Obsoletos
capítulo 1
U
ma mesma doença oportuna afeta quase todos os sites da Web atualmente, desde os websites pessoais mais simples até os de milhões de
dólares de grandes empresas. Esperta e traiçoeira, ela passa despercebida por respeitar as normas do mercado. Embora os donos e administradores de sites talvez ainda não tenham notado, 99,9% de todos os websites estão obsoletos. Eles podem parecer e funcionar bem nos navegadores
principais e em áreas de trabalho. Entretanto, fora desses ambientes
tolerantes a erros, já começam a aparecer os sintomas de decadência.
Nas versões modernas do Microsoft Internet Explorer, do Opera Browser
da Opera Software, do Safari da Apple, do Chrome do Google e do Mozilla
(navegador de código aberto baseado no Gecko cujo código é o que faz
funcionar o Firefox e o Camino), layouts cuidadosamente construídos
começaram a falhar e comportamentos custosamente projetados começaram a parar de funcionar. Conforme esses navegadores principais evoluem, a performance do site continua a se deteriorar.
Em navegadores “genéricos”, leitores de tela usados por pessoas com
necessidades especiais e em muitos telefones celulares, grande parte
desses sites jamais funcionou e ainda não funciona, enquanto outros
funcionam precariamente. Dependendo de suas necessidades e verbas, os donos e desenvolvedores de sites ou ignoraram esses sites e
13
designing_with_web_std_cad_01_PB.indd 13
11/10/2010 09:04:06
14
capítulo 1 > 99,9% dos Websites Estão Obsoletos
dispositivos genéricos ou os suportam apenas detectando a presença deles e
enviando a eles marcações e códigos específicos, como fazem com os navegadores “regulares”.
A fim de entender a inutilidade desta prática ultrapassada de mercado e observar como ela aumenta o custo e a complexidade do desenvolvimento de sites
sem obter o resultado desejado, devemos analisar como os navegadores atuais e
compatíveis com padrões se diferem daqueles do passado.
Navegadores Atuais e Padrões Web
Neste livro, quando me refiro a navegadores “atuais” ou “compatíveis com padrões”, quero dizer aqueles que entendem e suportam HTML e XHTML, Folhas
de Estilo em Cascata (CSS - Cascading Style Sheets), ECMAScript (mais conhecido como “padrão JavaScript”) e o Modelo de Objetos de Documentos (DOM
– Documents Object Model). Juntos, eles são os padrões que nos permitem lidar
com as linguagens de marcação de apresentação, as de script incompatíveis e a
obsolescência contínua que elas geram.
Dentre esses navegadores estão o Firefox 3.5+ de código aberto, ganhador de
uma premiação; o Microsoft Internet Explorer 7/8 e versões maiores para Windows; o Safari 3.0/4.0+ da Apple para Macintosh OS X; o Chrome do Google;
e o Opera 9/10+ da Opera Software. (Deixei de fora o seu navegador predileto
compatível com padrões? Meu intuito aqui não é desmerecê-lo, mas se eu fosse
listar cada navegador compatível com padrões, levaria tanto tempo que este livro ficaria ultrapassado mais rápido que a dança da Macarena). Embora eu use
o termo “compatível com padrões”, lembre-se de que navegador algum é, ou
possa vir a ser, 100% compatível com padrões.
Mas essa falta de perfeição não é motivo para evitá-los. Milhões de pessoas
ainda usam o Internet Explorer 6 para Windows e seu suporte a padrões é decididamente inferior ao do IE7+, do Firefox, do Opera e do Safari. Então se alguns
de seus usuários usam o IE6 você não deve usar os padrões? Isso significa que
você deve dizer a eles para atualizarem seus navegadores ou caírem fora? É claro que não! A criação de sites usando padrões não precisa e não deve implicar
“construir apenas para os navegadores mais recentes”.
Da mesma forma, usar XHTML e CSS não implica ter que dizer aos usuários de
navegadores antigos para caírem fora. Mas é improvável que um site devidamente construído com padrões tenha a mesma apresentação, pixel por pixel,
no IE6 do que naqueles compatíveis com padrões. De fato, dependendo de seu
designing_with_web_std_cad_01_PB.indd 14
11/10/2010 09:04:06
Um Novo Código para uma Nova Função 15
método de criação, ele pode ter uma aparência totalmente diferente. Até aí tudo
bem. Na verdade, alguns designers chegaram a sugerir fornecer aos usuários
do IE6 estilos personalizados que aumentem a legibilidade, sem tentar imitar a
aparência e a impressão do site quando exibido em navegadores mais compatíveis. Leia o “Universal Internet Explorer 6 CSS” (www.forabeautifulweb.com/blog/
about/universal_internet_explorer_6_css) de Andy Clarke para mais detalhes sobre
essa abordagem.
Um Novo Código para uma Nova Função
Os navegadores atuais não são simplesmente novas versões dos anteriores. Eles
possuem diferenças consideráveis em relação a seus predecessores, e, em muitos casos, foram totalmente reconstruídos do zero. Mozilla Firefox, Camino e
navegadores relacionados baseados no Gecko não são versões novas do há muito
extinto Netscape 4. O Opera 10 não se baseia no mesmo código de suas versões
anteriores. Esses produtos foram criados com códigos novos para executarem
novas funções – isto é, para aderir da melhor forma possível aos padrões Web
discutidos aqui.
Em contrapartida, os navegadores da década de 1990 baseavam-se em tecnologias exclusivas (apenas da Microsoft, apenas da Netscape) e davam pouca atenção a padrões.
Navegadores antigos ignoravam alguns padrões completamente, mas, paradoxalmente, essa falta de suporte não trazia muitos problemas. Se os navegadores
não suportavam o padrão PNG (Portable Network Graphic), por exemplo, então os
desenvolvedores não usavam imagens PNG. Sem problema. Mas aqueles navegadores também forneciam suporte parcial e incorreto a alguns padrões. Esse
suporte desleixado e inconsistente para padrões básicos, como HTML, criou um
ambiente de publicação Web sem restrições.
Quando o apêndice de um paciente rompe, um cirurgião qualificado efetua uma
apendicectomia. Mas e se em vez disso fosse um residente bêbado que removesse metade do apêndice, sem querer perfurando alguns outros órgãos e se
esquecesse de suturar as costas do paciente? Assim era o suporte a padrões em
navegadores antigos: incompetentes, incompletos e perigosos à saúde da Web.
Se o Netscape 4 ignorava as regras CSS aplicadas ao elemento body e inseria
aleatoriamente espaços em branco a cada estrutura de elementos em sua página e o IE4 entendia o body, porém o processava mal, qual tipo de CSS era
mais seguro para se usar? Alguns desenvolvedores preferiram não usar CSS
designing_with_web_std_cad_01_PB.indd 15
11/10/2010 09:04:06
16
capítulo 1 > 99,9% dos Websites Estão Obsoletos
algum. Outros usavam folhas de estilo para compensar as falhas do IE4 e outras diferentes para compensar os erros do Netscape 4. A fim de compensar as
diferenças de fontes e widgets de desktop multiplataforma, alguns desenvolvedores também ofereciam diferentes folhas de estilo para variados sistemas
operacionais.
O CSS não era o único problema: os navegadores não usavam o mesmo HTML,
renderização de tabela ou linguagens de script usadas para adicionar interatividade à página. Não havia uma forma 100% correta de suporte para estruturar o
conteúdo de uma página, produzir seu design ou adicionar um comportamento
sofisticado a um site.
Esforçando-se para lidar com cada incompatibilidade que surgia, designers e
desenvolvedores criaram versões personalizadas (não padrão) de código e marcação para contornar as deficiências em cada navegador lançado. Era tudo o que
podíamos fazer naquela época se quiséssemos criar sites que funcionassem em
mais de um navegador ou sistema operacional. Mas hoje esse é o caminho errado a se tomar, pois todos os navegadores atuais suportam os mesmos padrões
abertos. Mesmo assim tal prática ainda existe, desnecessariamente devorando
recursos, fragmentando a Web e levando a sites que não podem ser acessados ou
utilizados.
O Problema da “Versão”
A criação de várias versões de marcação e código não padrão é a origem da contínua obsolescência que assola a maioria dos sites e seus donos. Entretanto,
embora seja cara, inútil e insustentável, essa prática ainda persiste.
Ao se depararem com navegadores que suportam padrões Web, desenvolvedores o tratam como se não suportassem. Com isso, eles criam scripts para detectar o IE6 e, então, fornecem um código voltado apenas para a Microsoft mesmo
que o IE6 suporte JavaScript padrão e o DOM.
designing_with_web_std_cad_01_PB.indd 16
11/10/2010 09:04:06
O Problema da “Versão” 17
Os Riscos da Detecção de Navegadores
Todos os navegadores possuem uma string de agente de usuário (UA): uma
string curta de texto com o nome, a versão e a plataforma do navegador, que
funciona como a impressão digital do navegador. Servidores Web frequentemente registram a UA, fornecendo valiosas informações aos donos de
websites que procuram melhor entender seus usuários. Mas muito constantemente eles usam código Javascript ou código do lado do servidor para
analisar a sintaxe da string UA de modo que possam fornecer o conteúdo
apropriado àquela plataforma ou específico àquela versão. O problema com
esse método é que não se pode depender da string UA. Dependendo das
configurações de segurança ou de rede do usuário, o navegador talvez não
passe sua UA ao servidor, ocasionando falha no script de detecção e impedindo que os usuários cheguem onde desejam.
Além disso, todos os navegadores atuais permitem ao usuário alterar a UA,
seja através de extensões instaladas pelo usuário (Firefox) ou através de um
recurso do próprio navegador (Safari e Opera). Na verdade, antes da versão
8.02, o Opera, por padrão, identificava a si mesmo como Internet Explorer
para evitar ser bloqueado pelos sites que só aceitavam o IE.
A falibilidade de detecção da UA foi ressaltada no lançamento do Opera 10,
o primeiro navegador a conseguir usar dois dígitos. Esse grande avanço foi
prejudicado com o lançamento da versão beta, na qual uma legião de scripts
mais aperfeiçoados de detecção da versão do navegador não conseguiu registrar o segundo dígito no número de versão do Opera 10, identificando-o como
“Opera 1”. O problema foi tão extenso que a Opera fez alterações para que seu
navegador fosse identificado não como “Opera 10.00”, mas “Opera 9.80” (sua
versão mais recente, dev.opera.com/articles/view/opera-ua-string-changes).
Infelizmente, essa versão do “bug do milênio” aguarda a todos os navegadores que faltam chegar à versão 10, a não ser que acabemos com a detecção do
navegador e adotemos uma abordagem mais voltada para padrões.
Com cada versão vem o aumento constante de custos e enigmas. Sites desenvolvidos para especificações de scripts próprios de navegadores já há muito extintos não funcionam nos navegadores e dispositivos atuais. O dono do site deveria
destinar mais dinheiro ao problema pedindo aos desenvolvedores que criem
uma quinta ou sexta versão do site? E se não houver verba para isso? Muitos
usuários não conseguiriam acessar o site.
designing_with_web_std_cad_01_PB.indd 17
11/10/2010 09:04:06
18
capítulo 1 > 99,9% dos Websites Estão Obsoletos
Mesmo quando adotam tecnologias de padrões Web, como XHTML e CSS, os
designers e desenvolvedores que aprendem os métodos antigos costumam não
perceber a questão. Em vez de usar padrões para evitar a necessidade de múltiplas versões, muitos desenvolvedores que usam as práticas antigas criam arquivos CSS específicos a variados navegadores e plataformas, o que quase sempre é
autodestrutivo.
1.1
Em 1999, o MSN Game Zone
(zone.msn.com/blog.
asp) tinha três folhas de estilo
externas e ainda assim não
era exibido adequadamente
na maioria dos navegadores.
Ele também possuía vários
scripts (a maioria in-line),
incluindo detecção de
navegadores reforçados.
Nem assim funcionava ainda.
Lançar mais versões de
códigos em um problema
raramente o resolve.
1.2
Para ser justo, a foto anterior
já tem quatro anos. Hoje,
a mesma página ficou pior
ainda conforme acrescentam
mais códigos a ela. Seis
anos depois de a Microsoft
lançar o primeiro navegador
compatível com padrões,
algumas partes de seu site
ainda não usam os padrões
do novo navegador.
designing_with_web_std_cad_01_PB.indd 18
11/10/2010 09:04:07
Venda On-line de Produtos de Segunda Mão 19
Essas práticas desperdiçam tempo e dinheiro, e nenhum desses dois jamais foi
uma comodidade. Criar múltiplas versões de sites que ninguém possa bancar
não acrescenta nada à causa pela qual tanto tempo e dinheiro foram gastos. Os
sites ainda estão com falhas, e os usuários sem acesso.
Venda On-line de Produtos de Segunda Mão
Analise minuciosamente grandes sites comerciais, como Amazon.com e eBay.com.
Observe suas tortuosas marcações não padrão, seus confusos JavaScripts (geralmente com scripts de detecção falhos) e o mal uso do CSS. É surpreendente como
esses sites funcionam em qualquer navegador.
Geralmente, sites não compatíveis com padrões funcionam em navegadores antigos porque seus donos investiram em ferramentas dispendiosas que
aceitam as diferenças entre os navegadores através da criação de múltiplas
versões não padrão voltadas para as peculiaridades de sites e plataformas
específicos, como descrito anteriormente no tópico O problema da“versão”.
As quatro primeiras gerações do Nestcape Navigator e do Microsoft Internet Explorer não suportavam simplesmente marcações não padrão e códigos
específicos para cada navegador; e sim incentivavam a criação de scripts e
desenvolvimento de sites desleixados numa batalha doentia para dominar o
mercado de navegadores.
Entra Lixo, Sai Lixo
Antigamente, nos cursos de programação, aprendia-se o chavão “Entra lixo,
sai lixo”. Da mesma forma, dentre as primeiras coisas que um designer gráfico
aprende é que a qualidade das fontes primárias determina a eficiência do produto final. Comece com uma resolução alta, uma fotografia de alta resolução e a
impressão ou o gráfico da Web ficará bom. Experimente desenvolver com uma
fotografia ou uma imagem da Web de baixa resolução que o resultado não valerá
a pena. Entra lixo, sai lixo.
Mas os navegadores antigos não funcionam assim. Negligentes ao absurdo, eles
passam marcações falhas e links errôneos para os arquivos fonte javaScript sem
pestanejar. E, na maioria dos casos, exibem o site como se tivesse sido desenvolvido corretamente. Essa falta de rigor incentiva designers e desenvolvedores
de front-end a criarem hábitos ruins – e também estimula desenvolvedores de
middleware e back-end a enxergarem tecnologias como XHTML, CSS e JavaScript
como primitivas e insignificantes.
designing_with_web_std_cad_01_PB.indd 19
11/10/2010 09:04:07
20
capítulo 1 > 99,9% dos Websites Estão Obsoletos
Quem não respeita uma ferramenta possivelmente não a usará corretamente.
Veja o pedaço de código abaixo extraído de um site caro de e-commerce de uma
empresa que compete num mercado acirrado:
<td width=“100%”><ont face=“verdana,Helvetica,arial” size=“+1”
color=“#CCCC66”><span class=“header”><b>Join now!</b></span>
</ont></td>
A desnecessária tag ont, é um erro de digitação da obsoleta tag font – um erro que
ocorre diversas vezes ao longo do site graças a uma ferramenta de publicação
altamente eficiente. Erros à parte, essa marcação talvez seja familiar a você e
até mesmo pareça com a marcação do seu site. No contexto dessa página Web, é
necessário usar apenas:
<h3>Join now!</h3>
Combinado com uma regra adequada numa folha de estilo, a marcação acima
(mais simples) fará exatamente o mesmo que a outra marcação excessiva, não
padrão e inválida – ao mesmo tempo economizando tráfego entre o cliente e o
servidor e facilitando a transição para sites mais flexíveis com marcações semânticas (provavelmente incluindo código de máquina legível, como microformatos, discutido mais para frente neste livro). Esse mesmo site de e-commerce
possui o seguinte link quebrado em JavaScript:
<script language=JavaScript1.1src=
“http://foo.com/Params.richmedia=yes&etc”></script>
Outro problema é que o valor de language sem aspas se mistura com a tag source.
Em outras palavras, está sendo dito ao navegador para usar uma linguagem de
script inexistente (“JavaScript1.1src”).
Uma medida racional seria o site apresentar erro alertando aos desenvolvedores
que o corrigissem imediatamente. Mas, até recentemente, o JavaScript daquele
site funcionava na maioria dos navegadores, perpetuando assim o ciclo de sites
mal desenvolvidos. Não é de se estranhar que programadores habilidosos enxergassem os desenvolvedores de front-end como pessoas burras desmerecedoras de respeito ou atenção.
Conforme os novos navegadores se tornam mais compatíveis com padrões Web,
eles toleram cada vez menos marcações e códigos falhos. Entra lixo, sai lixo está
começando a se estabelecer no mundo dos navegadores, tornando o conhecimento sobre padrões Web uma necessidade para todos que projetam ou criam
websites.
designing_with_web_std_cad_01_PB.indd 20
11/10/2010 09:04:07
Code forking Pode ser Arriscado Para a Saúde do Site a Longo Prazo 21
Code forking Pode ser Arriscado Para a Saúde do
Site a Longo Prazo
Mais de uma empresa que conheço gastou mais de um milhão de dólares
em um sistema de gerenciamento de conteúdo (SGC) altamente complexo
e de uso dificílimo. Os criadores desse gigantesco software defendem seu
custo absurdo ressaltando sua capacidade de se esforçar para cobrir todas
as versões não padrão de código. Além de desperdiçar enormes quantias insensatas de dinheiro, esta prática afeta a navegabilidade ao inserir conteúdo
significativo num mar de tags não semânticas (1.3). O mais injusto é que ela
exige demais da paciência de usuários de acesso discado (ou Smartphones),
desperdiçando largura de banda com code forking, tabelas muito aninhadas,
espaços em pixels e outros truques com imagens e tags e atributos desatualizados ou inválidos.
1.3
Rápido! Encontre informações
sobre os modelos e serviços
da Volkswagen na confusa
e desestruturada marcação
HTML do site www.
volkswagen.com. Dica: Se teve
dificuldades para achá-las,
também as terão os leitores e
as ferramentas de pesquisa.
designing_with_web_std_cad_01_PB.indd 21
11/10/2010 09:04:08
22
capítulo 1 > 99,9% dos Websites Estão Obsoletos
O que é Code Forking?
Código é o que os programadores escrevem para criar programas, sistemas operacionais ou praticamente tudo no mundo digital. Quando mais
de um grupo de desenvolvedores trabalha em um projeto, o código pode
se “ramificar” em várias versões incompatíveis, especialmente se cada
grupo estiver tentando resolver um problema diferente ou seguindo outro
planejamento. Essa inconsistência e perda de controle centralizado costumam ser vistos como uma coisa ruim.
Neste livro, code forking se refere à pratica de criação de múltiplas versões de código incompatível para lidar com as necessidades dos navegadores que não suportam o padrão JavaScript e o DOM (consulte o tópico
anterior O problema da“versão”).
Ao mesmo tempo, code forking desperdiça tanto a largura de banda do dono do
site a um custo que mesmo os contadores ultraminuciosos sairiam perdendo
na contagem. Quanto maior o site, maior o tráfego e maiores são os gastos com
chamadas ao servidor, redundâncias, truques com imagens e marcações e códigos complexos e desnecessários.
É difícil alcançar certas metas, mas, de modo geral, se um site reduz seu problema com as marcações em 35%, o mesmo ocorrerá nos custos com a largura de
banda. Uma empresa que gasta 2 mil e quinhentos dólares por ano com largura
de banda economizaria 875 dólares. Outra que gasta 160 mil dólares por ano
economizaria 56 mil dólares.
Considere a página inicial do Volkswagen.com (1.4). Apesar do design elegante
e objetivo, a marcação da página é analisada como antiquada, cheia de tabelas,
com JavaScript ineficazes e páginas de CSS embutidas. Agora, esse não é um site
amador: o portal internacional de um das marcas mais conhecidas mundialmente é acessado milhões de vezes por dia. Multiplique cada byte desperdiçado,
de truques de design HTML ultrapassados, pelo número gigantesco de páginas
visitadas do site. O resultado serão gigabytes de largura de banda que exigem
demais dos servidores da Volkswagen e também adicionam custos exorbitantes,
como os do Pentágono, em suas despesas gerais. Se a Volkswagen simplesmente
substituísse sua marcação ineficiente e devoradora de largura de banda (1.3 e
1.5) por um HTML semântico com CSS e leve, o custo com cada página seria reduzido consideravelmente. E isso aumentaria os lucros da empresa.
designing_with_web_std_cad_01_PB.indd 22
11/10/2010 09:04:08
Code forking Pode ser Arriscado Para a Saúde do Site a Longo Prazo 23
1.4
Página inicial da Volkswagen
(www.volkswagen.com) –
completo, chamativo, belo.
1.5
Belo, até que você olhe por
debaixo dos panos. Retire
a “capa” da Volkswagen
(com o “exibir código-fonte”
de seu navegador) e verá
que o código e a marcação
usados para criar esse site
de aparência simples são
inacreditavelmente complexos
e confusos.
designing_with_web_std_cad_01_PB.indd 23
11/10/2010 09:04:10
24
capítulo 1 > 99,9% dos Websites Estão Obsoletos
Então por que a Volkswagen não faz alterações? Aparentemente, a empresa
deseja que seu site seja exibido exatamente da mesma forma tanto nos navegadores antigos que não suportam CSS como nos atuais que usam padrões. O
irônico é que quem usa um navegador de dez anos atrás, provavelmente pouco
se importará com a aparência do site da Volkswagen. E certamente não fará
comparações da exibição do site no IE5 com as do Firefox3 ou IE8. Se a equipe
de designers da Volkswagen usasse as técnicas expostas neste livro, poderia garantir a acessibilidade ao seu site através de qualquer dispositivo e navegador,
independente da aparência do site.
Quando uma empresa tão competente como a Volkswagen perde uma oportunidade como essa você logo percebe a mentalidade arraigada dos gerentes de
marcas, que tratam a Web como se fosse uma propaganda impressa, e dos desenvolvedores, que colocam a compatibilidade com a versão anterior acima do
bom senso, da usabilidade ou de seus próprios lucros.
O Custo Indireto de uma Marcação Grande Demais
Suponha que o código e a marcação de uma página Web criada com técnicas
antigas some 60 K. Digamos que, ao substituir as tags font e outros entulhos de
apresentação e de uso exclusivo por uma marcação clara e estruturada e algumas regras CSS, a mesma página possa ficar com 30 K. (Em nossa empresa,
geralmente conseguimos diminuir 60 K de marcação para 22 K ou menos. Mas
fiquemos com um exemplo mais discreto, que representa economia de 50% de
largura de banda). Considere os dois cenários típicos a seguir.
Redução no Número de Linhas de T1
Cenário: um website auto-hospedado de um negócio ou de um setor público
recebe um fluxo constante de visitantes – centenas deles em qualquer momento. Depois de reduzir pela metade o tamanho de sua página ao migrar para uma
marcação XHTML clara, enxuta e estruturada, a empresa economiza mil dólares
por mês.
Como funciona: antes da migração, a fim de atender seu público, o site
auto-hospedado exigia quatro linhas de T1, cada uma alugada por 500 dólares ao mês (custo normal de uma linha de T1 de 1,544 megabits por segundo). Após reduzir o tamanho dos arquivos em 50%, a empresa descobre que
pode manter a mesma eficiência com apenas duas linhas de T1, removendo,
assim, mil dólares por mês de suas despesas operacionais. Além da economia com a largura de banda, haverá também gastos menores nas despesas
designing_with_web_std_cad_01_PB.indd 24
11/10/2010 09:04:10
O Custo Indireto de uma Marcação Grande Demais 25
com hardwares e redução nos custos de armazenagem e no uso de energia
de grandes centrais de processamento de dados, tanto no uso de máquinas
como no resfriamento da sala. Isso mesmo: os padrões Web podem ajudar a
salvar o planeta.
Quanto mais simples for a marcação, mais rapidamente ela chegará ao usuário.
E, consequentemente, menos do servidor será exigido – e menos servidores
você terá de comprar, fazer manutenção e substituir. Isso é válido especialmente para servidores que precisam lidar com conteúdo dinâmico de banco de
dados – ou seja, todos os sites comerciais e a maioria dos conteúdos atuais (até
mesmo blogs).
Megabytes Excedentes
Cenário: com o aumento da popularidade de sites que oferecem hospedagem,
os donos desses websites notaram que estão pagando por uma taxa inesperada
por ultrapassar o limite mensal de transferência de dados, chegando a centenas,
ou mesmo milhares de dólares. Reduzir o tamanho dos arquivos pela metade
retorna o custo mensal a uma taxa aceitável e cabível.
Como funciona: muitos serviços de hospedagem pagos oferecem a seus usuários um limite “gratuito” de transferência mensal – digamos até 3GB. Não
ultrapasse esse limite e você pagará o valor normal de sua mensalidade. Ultrapasse-a e você pagará mais – às vezes muito mais.
Em um caso vergonhoso, uma empresa de hospedagem cobrou 16 mil dólares de
taxas adicionais do designer Al Sacui após seu site não comercial (Nosepilot.com)
exceder o limite de sua transferência mensal. Era um caso extremo. Portanto,
Sacui conseguiu evitar a cobrança ao provar que a empresa havia mudado os
termos de serviço sem notificar seus clientes – mas só depois de longas brigas
judiciais. Quem arriscaria contas ultrajantes ou brigas judiciais demoradas com
uma empresa de hospedagem encrenqueira?
Mas é claro que nem toda empresa de hospedagem cobra quantias exorbitantes por exceder o limite de transferência. Seja seu site grande ou pequeno,
visitado por milhões ou apenas algumas pessoas, quanto menor forem seus
arquivos, menor será o seu tráfego. (Aliás, é melhor escolher uma empresa de
hospedagem que ofereça transferência de dados ilimitada ou limitada com um
valor fixo para os megabytes excedentes do que uma que penaliza você por ter
um site popular).
designing_with_web_std_cad_01_PB.indd 25
11/10/2010 09:04:10
26
capítulo 1 > 99,9% dos Websites Estão Obsoletos
Marcação Condensada e Compactada
Depois de dar uma palestra sobre padrões Web, um desenvolvedor veio
até mim e alegou que as vantagens da largura de banda de uma marcação
clara e bem estruturada pouco ajudam empresas que compactam seus códigos HTML.
Além de condensar sua marcação com o uso de estruturas semânticas,
você pode compactá-la digitalmente em alguns ambientes de servidores.
Por exemplo, o servidor Web da Apache possui um módulo mod_gzip que
comprime o HTML no lado do servidor. Depois, ele é expandido novamente no navegador do usuário.
Aquele desenvolvedor que falou comigo me deu um exemplo: Se o Amazon.com desperdiça 40 K em tags font ultrapassadas e outros entulhos, mas
usa o mod_gzip para compactá-los para 20K, então a marcação grande demais do Amazon.com representaria menos despesas do que minha palestra
(e este livro) sugerira.
Mas a Amazon não usa o mod_gzip. De fato, essa ferramenta é pouco usada
na Web comercial. Possivelmente devido ao tempo extranecessário para
compactar as páginas antes de enviá-las. Entretanto, desconsiderando
essa questão, quanto menor for o arquivo, mais compactado ele ficará. Se
você economiza dinheiro compactando uma página de 80 K para 40 K, você
economizaria muito mais quando uma de 40 K passa para 20 K. Reduzir o
processo de exibição de uma página pode parecer pequeno, mas seu valor é
acumulativo. Com o tempo, pode diminuir consideravelmente os custos de
operação.
Economia com largura de banda é apenas uma das vantagens de se escrever marcações claras e bem estruturadas, mas uma apreciada por contadores e clientes. O mesmo vale tanto para quem compacta seus próprios
códigos HTML como para o resto de nós.
designing_with_web_std_cad_01_PB.indd 26
11/10/2010 09:04:10
Compatibilidade com a Versão Anterior é uma Mentira 27
Compatibilidade com a Versão Anterior é
uma Mentira
O que os desenvolvedores querem dizer com “compatibilidade com a versão
anterior”? Se perguntar, eles dirão que é “prover suporte a todos os nossos usuários”. E que argumento há contra tal dedicação?
Na prática, contudo, compatibilidade com a versão anterior significa usar marcação e código exclusivos (ou obsoletos) para garantir que cada visitante obtenha os mesmos resultados, estejam usando o IE2 ou o Opera 10. Teoricamente,
compatibilidade com a versão anterior soa ótimo. Mas o custo é alto demais e
essa prática sempre se baseou em uma mentira. A verdade é que não há uma
compatibilidade com a versão anterior real. Sempre existe uma limitação. Por
exemplo, nem o Mosaic (primeiro navegador visual) e nem o Netscape 1.0
suporta layouts com tabelas HTML. Logo, por definição, quem usa esses navegadores antigos jamais poderia obter a mesma visualização de quem usa navegadores mais recentes, como o Netscape 1.1 ou o MSIE2.
Desenvolvedores e clientes que alegam se esforçar para obter compatibilidade com a versão anterior inevitavelmente especificam um “navegador base”,
como o Internet Explorer 6, afirmando ser o navegador mais antigo que seus
sites suportarão. (Nesse cenário, os usuários do IE5 estão sem sorte). A fim
de oferecer suporte ao navegador base, os desenvolvedores inserem em suas
marcações artifícios não padrão específicos a determinados navegadores, criam
variados scripts para acomodar os navegadores “suportados” e usam a detecção
da UA para prover a cada navegador o código mais adequado. Ao fazer isso, eles
aumentam o tamanho das páginas, sobrecarregam o servidor e garantem a continuidade da obsolescência.
designing_with_web_std_cad_01_PB.indd 27
11/10/2010 09:04:10
28
capítulo 1 > 99,9% dos Websites Estão Obsoletos
Limitar Usuários é Ruim para os Negócios
Enquanto algumas empresas prejudicam seus próprios lucros ao tentar garantir
que mesmo os navegadores antigos exibam seus sites exatamente como os atuais, outras decidiram que só um navegador importa. Num esforço equivocado
para reduzir as despesas, muitos sites são desenvolvidos para funcionar apenas
no Internet Explorer, e às vezes só na plataforma Windows. Isso exclui entre 15
e 25% os possíveis visitantes e clientes [1.6, 1.7, 1.8, 1.9, 1.10].
1.6
A página da KPMG (www.
kpmg.com), em 2003, vista
no Netscape Navigator. Ou
melhor, não vista, graças ao
código voltado apenas para
o IE.
1.7
O site também ficava inútil no
Nestcape 7.
designing_with_web_std_cad_01_PB.indd 28
11/10/2010 09:04:11
Compatibilidade com a Versão Anterior é uma Mentira 29
1.8
Bem, se o site fosse apenas
para o IE, como ele funcionava
no IE5/Mac? Aparentemente,
não tão bem assim.
1.9
Mesmo site visto no IE6/
Windows, onde ele finalmente
funciona.
1.10
Para ser justo, o site “meio
que funcionou” no Opera
7 para Windows quando o
navegador estava configurado
para ser identificado como se
fosse o IE, caso contrário não
funcionaria.
designing_with_web_std_cad_01_PB.indd 29
11/10/2010 09:04:11
30
capítulo 1 > 99,9% dos Websites Estão Obsoletos
1.11
Após um novo
desenvolvimento, hoje o site
da KPMG parece e funciona
bem em vários sites e
plataformas. Mas ainda há
muito espaço para melhorias
no código, porém uma
marcação atualizada e voltada
não apenas para o IE fez toda
a diferença.
Ver Apêndice - Imagens Coloridas
Não fingirei que entendo o modelo de negócios de uma empresa que excluiria
um quarto de possíveis clientes. E só a quantidade de clientes perdidos devido
a essa abordagem com falta de percepção deveria chocar qualquer dono de negócios racional ou agência não corporativa cuja função seja servir ao público.
Segundo estatísticas recentes (www.internetworldstats.com), quase 1,6 bilhões
de pessoas usaram a Web em maio de 2009). Faça as contas!
Digamos que você não se importe de perder 25% de visitantes do seu site. A
prática “só IE” ainda não faz sentido, pois não há garantias de que o IE (ou mesmo outros navegadores) continuará a dominar a Web. Conforme escrevo essas
linhas aqui, o Firefox continua a tomar espaço do IE, e cada vez mais pessoas
estão acessando a internet através de dispositivos móveis como o Webkit e o
Opera Mini. Conforme a informática se propaga e gera novos mercados, a noção
de desenvolvimento exclusivo para qualquer navegador parece cada vez mais
coisa do século XX e cada vez menos inteligente.
Além disso, como este livro mostrará, padrões possibilitam desenvolver sites
para todos os navegadores e dispositivos de forma tão rápida e fácil como se fosse apenas para um.
No esforço para prover visualizações idênticas em ambientes incompatíveis de
navegadores, nos esquecemos de seu verdadeiro potencial como um meio rico
e multicamadas, com acessibilidade para todos. Isso ocorreu quando designers
designing_with_web_std_cad_01_PB.indd 30
11/10/2010 09:04:12
A Cura 31
e desenvolvedores, lutando para cumprirem as demandas de produção durante
o curto estouro da internet, aprenderam técnicas altamente falhas de criação de
sites, o que nos levou ao estado de obsolescência atual.
Mas o período de obsolescência do desenvolvimento Web está sumindo conforme você lê este livro, levando inúmeros sites junto. Se for dono, administrador,
designer ou programador de sites, seu site corre perigo também.
A Cura
“Escreva uma vez, publique em todo lugar”. A promessa de padrões Web é
mais do que um pensamento desejado. Hoje em dia eles já são viáveis através dos métodos que exploraremos aqui. Embora os principais navegadores
atuais finalmente suportem esses padrões e métodos, muitos designers e desenvolvedores ainda não estão cientes deles. E novos sites ainda são construídos na areia movediça de códigos e marcações não padrão. Este livro espera
mudar isso.
Criadas por membros do W3C e outras entidades de padrões e suportadas por
todos os navegadores a partir do ano 2000, tecnologias como CSS, XHTML, Javascript e o DOM do W3C possibilitaram que designers conseguissem:
yy Controle mais preciso no layout, posicionamento e tipografia de navegadores gráficos ao mesmo tempo permitindo que usuários modificassem a
exibição conforme suas necessidades.
yy Desenvolvimento de comportamentos sofisticados que funcionassem em
vários navegadores e plataformas.
yy Cumprimento das regras e instruções de acessibilidade sem comprometer
beleza, performance ou sofisticação.
yy Re-design do site em horas em vez de dias ou semanas, reduzindo os custos e eliminando um trabalho maçante.
yy Suporte a vários navegadores sem o incômodo e a despesa para se criar
versões separadas, e geralmente com pouco ou nenhum code forking.
yy Suporte a dispositivos não tradicionais e novos, desde gadgets sem-fio e
smartphones a dispositivos com saída em Braille e leitores de tela usados
por pessoas com deficiências – novamente sem o incômodo e a despesa
para se criar versões separadas.
designing_with_web_std_cad_01_PB.indd 31
11/10/2010 09:04:12
32
capítulo 1 > 99,9% dos Websites Estão Obsoletos
yy Provimento de versões impressas sofisticadas de qualquer página Web,
geralmente sem criar versões separadas de impressões para o usuário final ou sem depender de sistemas exclusivos de publicação para gerar tais
versões.
yy Transição da salada de tags do passado para a verdadeira Web semântica
do presente e do futuro.
yy Garantia de que sites bem projetados e criados funcionarão corretamente
nos navegadores atuais compatíveis com padrões e terão um desempenho
aceitável nos navegadores antigos – mesmo que a renderização pixel por
pixel desses não seja a mesma que nos atuais.
yy Garantia de que sites bem desenvolvidos continuarão a funcionar nos
navegadores e dispositivos futuros, incluindo aparelhos que ainda nem
foram imaginados. Essa é a promessa da compatibilidade futura.
yy ... e tem mais, como este livro mostrará.
Antes que possamos aprender como os padrões atingem esses objetivos, devemos analisar as técnicas antigas que eles irão substituir e descobrir exatamente
como elas perpetuam o ciclo de obsolescência. O Capítulo 2 tratará disso tudo.
Não está no clima para ler sobre história? Pule para o Capítulo 3 para um pouco
de ar puro.
designing_with_web_std_cad_01_PB.indd 32
11/10/2010 09:04:12