Uma mesma doença oportuna afeta quase todos os sites da Web atualmente,

Transcrição

1 capítulo um 99,9% dos Websites Estão Obsoletos capítulo 1 Uma 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

2 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

3 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 ( 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

4 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.

5 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.

6 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.

7 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.

8 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= ></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.

9 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.

10 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.

11 Code forking Pode ser Arriscado Para a Saúde do Site a Longo Prazo Página inicial da Volkswagen ( 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.

12 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

13 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).

14 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.

15 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.

16 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.

17 Compatibilidade com a Versão Anterior é uma Mentira 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 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.

18 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 ( 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

19 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: y 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. y Desenvolvimento de comportamentos sofisticados que funcionassem em vários navegadores e plataformas. y Cumprimento das regras e instruções de acessibilidade sem comprometer beleza, performance ou sofisticação. y Re-design do site em horas em vez de dias ou semanas, reduzindo os custos e eliminando um trabalho maçante. y 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. y 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.

20 32 capítulo 1 > 99,9% dos Websites Estão Obsoletos y 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. y Transição da salada de tags do passado para a verdadeira Web semântica do presente e do futuro. y 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. y 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. y... 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.