Porque é que os sites web se estragam em silêncio noutros navegadores

O relato de erro soa familiar: «Aqui a página parece estragada.» A programadora abre a página, vê — nada. Tudo no seu lugar. Só o telefonema de resposta esclarece a situação: o cliente usa o Safari no iPhone, ela o Chrome no computador. Entre os dois estão dois motores de renderização, várias larguras de ecrã e uma série de diferenças silenciosas, das quais nenhuma alguma vez gerou uma mensagem de erro.

Que o mesmo site possa ter um aspeto diferente consoante o navegador não é um acidente de percurso, mas arquitetura. No núcleo de cada navegador trabalha um motor de renderização que traduz HTML e CSS em píxeis. Três famílias repartem hoje entre si praticamente todo o mercado: o Blink move o Chrome, o Edge e a maioria dos derivados menores do Chromium, o Gecko move o Firefox, o WebKit o Safari — e no iPhone renderizam até hoje praticamente todos os navegadores divulgados com WebKit, mesmo quando no ícone se lê Chrome ou Firefox.

Estes motores são implementações independentes dos mesmos padrões da web. Os padrões descrevem o que uma propriedade CSS deve produzir — mas deixam margens, são implementados a velocidades diferentes e, ocasionalmente, duas equipas de desenvolvimento entendem a mesma formulação de maneiras diferentes. O resultado são três programas que leem o mesmo documento e chegam a imagens ligeiramente diferentes. Na maioria das vezes, as diferenças são invisivelmente pequenas. Por vezes, não.

O ponto decisivo: estas diferenças mantêm-se mudas. O CSS foi concebido de propósito para tolerar erros. Uma propriedade que um navegador não conhece é simplesmente ignorada — sem aviso, sem falha, sem entrada em nenhum registo. O que na introdução de técnicas novas é uma bênção, porque os navegadores antigos não respondem a folhas de estilo modernas com uma avaria total, torna-se no dia a dia uma armadilha: a página não parte, apenas fica com o aspeto errado. E ninguém fica a saber, enquanto ninguém olhar.

Os pontos de rotura típicos podem ordenar-se. Há, desde logo, funcionalidades de CSS recentes que um motor já domina e outro ainda não, ou domina de forma diferente nos detalhes. Há questões de interpretação do layout — como o flexbox e o grid lidam com larguras mínimas, quebras de linha ou contentores encaixados, ali onde a especificação deixa margem de interpretação. E há os clássicos: elementos de formulário como campos de seleção, caixas de verificação e entradas de data, que cada navegador desenha ao seu gosto e que só de forma limitada se deixam remodelar.

Um exemplo da primeira categoria torna o padrão palpável. A propriedade CSS gap, que regula os espaçamentos entre elementos, esteve cedo disponível em todos os motores para o layout de grid — no contexto do flexbox, porém, o Safari passou a suportá-la bastante mais tarde do que o Chrome e o Firefox. Uma navegação cujos pontos de menu eram mantidos afastados por flexbox e gap tinha um aspeto impecável em dois motores; em versões mais antigas do Safari, os pontos ficavam colados uns aos outros. Nenhuma mensagem de erro, nenhuma falha, tecnicamente tudo funcionava — só que a página parecia atarracada e mal cuidada numa parte dos iPhones. Nestes casos, a solução passa por um recurso alternativo com margens exteriores clássicas; mas para isso é preciso saber primeiro que a diferença existe. É precisamente essa a verdadeira dificuldade das roturas silenciosas: não constam de nenhuma lista de erros. Constam apenas da imagem.

A isto acrescem diferenças que nem sequer estão na folha de estilos. Os tipos de letra são renderizados de forma diferente em cada sistema operativo e ficam com larguras diferentes; um título que num ambiente se mantém numa linha passa noutro para a linha seguinte e empurra para baixo tudo o que está por baixo. As barras de deslocamento, consoante o sistema, tiram espaço ao conteúdo ou sobrepõem-se a ele — alterando assim a largura disponível. As unidades de viewport comportam-se de maneira diferente nos dispositivos móveis, conforme o modo como o navegador contabiliza as barras de endereço que aparecem e desaparecem.

A segunda grande fonte de roturas silenciosas são as larguras de ecrã. O design responsivo define pontos de mudança — breakpoints — em que o layout se reorganiza: a navegação encolhe para um símbolo de menu, as colunas empilham-se umas sobre as outras, os espaçamentos diminuem. A experiência mostra que se testa nas larguras padrão dos dispositivos correntes. O que se estraga, estraga-se pelo meio: em tamanhos de janela invulgares, em tablets no formato horizontal, em janelas a meio ecrã em monitores largos de secretária.

Uma particularidade atinge com especial dureza as páginas em língua alemã: as palavras compostas longas. Onde o inglês tem três palavras curtas, o alemão tem a «Datenschutzgrundverordnung», a sua palavra única para o RGPD — uma palavra que se recusa a mudar de linha, sai do seu contentor ou faz rebentar uma navegação assim que o espaço escasseia. As interfaces traduzidas, que no original inglês tinham um aspeto impecável, estão por isso entre as candidatas mais fiáveis a problemas de quebra de linha.

Aliás, mesmo uma página que hoje tem um aspeto correto em todo o lado não continua assim por si só. Os navegadores atualizam-se a si próprios em ritmos curtos, os motores de renderização mudam detalhes do seu comportamento — e o site muda de aspeto sem que ninguém tenha feito qualquer implementação. O teste cuidadoso feito no lançamento é, por isso, um instantâneo, não um estado permanente. O mesmo vale no sentido inverso: cada atualização do CMS, cada plugin novo, cada alteração de texto pode desencadear deslocações.

Por detrás de tudo isto está um problema psicológico de fundo que qualquer pessoa conhece do dia a dia do desenvolvimento: «works on my machine». Quem constrói uma página vê-a centenas de vezes no seu próprio navegador, no seu próprio monitor — e toma inconscientemente essa vista pela verdade. As visitantes e os visitantes, porém, repartem-se por motores, classes de dispositivo e tamanhos de janela, e nenhum deles se manifesta por iniciativa própria quando alguma coisa se desloca. São pouquíssimas as pessoas que escrevem um e-mail quando um menu se sobrepõe. Simplesmente vão-se embora.

Tanto mais valioso é o caso raro de alguém se manifestar mesmo — desde que a comunicação seja tratada com método. Um procedimento comprovado tem quatro passos. Primeiro, perguntar pelo ambiente: que navegador, que dispositivo, que largura de janela aproximada? Sem estas indicações, qualquer procura é adivinhação. Segundo, reproduzir no motor adequado, não numa simulação — se necessário, através de um serviço de capturas de ecrã, quando não houver à mão um dispositivo com o motor certo; como decorre uma dessas séries de verificação, descreve-o o ScanU passo a passo. Terceiro, delimitar que mecanismo está em causa: o layout parte-se num ponto de mudança, falta uma funcionalidade de CSS, um tipo de letra fica mais largo? A resposta determina a reparação — os problemas de breakpoint resolve-os a própria folha de estilos, as funcionalidades em falta precisam de um recurso alternativo, os problemas de tipos de letra muitas vezes apenas de contentores mais generosos. E quarto, o passo que mais vezes é omitido: depois da correção, voltar a ver todos os motores. Quem verifica apenas o ponto comunicado facilmente não repara que a reparação deslocou alguma coisa noutro sítio.

Óbvia seria, a esta altura, a objeção de que as ferramentas de programação dos navegadores já resolveram o problema há muito: qualquer navegador moderno traz um modo de dispositivo que simula os tamanhos de ecrã de telemóveis e tablets. A objeção ignora o que esse modo faz realmente. Quem no Chrome escolhe a vista de iPhone obtém uma janela estreita com resolução adaptada e identificação móvel — mas continua a renderizar-se com o Blink, o motor do Chrome. As particularidades do WebKit do navegador verdadeiro do iPhone esta simulação não as mostra, tal como não mostra as particularidades do Gecko do Firefox. Para o trabalho nos breakpoints, o modo de dispositivo é uma ferramenta excelente; como prova de compatibilidade entre navegadores não serve. Um motor não se deixa simular, apenas trocar.

Como se encontram roturas que não se manifestam? O caminho tradicional é o trabalho manual: um armário cheio de dispositivos de teste ou uma lista de navegadores que alguém percorre a cliques depois de cada alteração. Funciona, mas escala mal — já três navegadores vezes três classes de dispositivo dão nove vistas por página, e a experiência mostra que o cuidado diminui a cada repetição. O caminho mais sistemático são os serviços de capturas de ecrã, que paralelizam essa inspeção visual. O ScanU, por exemplo, cria depois da introdução de um URL, em cerca de 30 segundos, capturas no Chrome, no Firefox e no Safari, cada um em vistas de telemóvel, tablet e computador; que combinações de dispositivo estão disponíveis, enumera-o a panorâmica de funcionalidades do ScanU. Em vez de abrir nove janelas umas atrás das outras, vê-se uma grelha de imagens — e os casos discrepantes saltam à vista.

Verdadeiramente interessante torna-se na repetição. Os serviços deste tipo comparam o estado atual com um estado de referência guardado e assinalam os desvios lado a lado. Assim, da pergunta vaga «a página tem bom aspeto em todo o lado?» nasce a pergunta bem mais afiada «mudou alguma coisa desde o último estado verificado?» — uma pergunta a que também se consegue responder quando já ninguém tem na cabeça o aspeto da página na semana passada.

Também aqui faz parte a honestidade: as capturas de ecrã mostram estados, não processos. O que acontece ao passar o rato por cima, se um menu abre em condições, como a página se comporta ao deslizar ou com uma ligação lenta — nada disso é reproduzido por uma imagem estática. Tão-pouco uma janela de navegador renderizada substitui a sensação do equipamento verdadeiro: o manuseamento tátil, o desempenho dos dispositivos mais antigos, as particularidades de versões concretas do sistema. Antes de um lançamento importante, pegar no telemóvel verdadeiro continua a ser uma boa ideia, e testes funcionais uma captura de ecrã não substitui de qualquer maneira.

Quanto esforço é adequado para o tema não tem de ser decidido em abstrato — as estatísticas de acesso próprias dão a direção. Mostram por que navegadores, classes de dispositivo e larguras de ecrã chegam as visitantes e os visitantes reais e, com isso, que combinações merecem prioridade na lista de verificação. Duas ressalvas fazem, porém, parte do quadro. Primeira: a estatística mede apenas quem chega — não quem, por causa de uma vista estragada, nem sequer fica; um motor pouco representado pode ser também consequência de um problema, não apenas sinal de pouca relevância. Segunda: as proporções diferem consideravelmente conforme o público-alvo e a situação de utilização: uma oferta que se lê à noite no sofá tem outra distribuição de dispositivos do que um portal especializado para o dia de trabalho no escritório. A lista de verificação própria deveria por isso seguir os números próprios, não panorâmicas gerais do mercado.

Para o dia a dia basta muitas vezes uma rotina simples: depois de cada alteração em estilos ou templates, verificar as páginas mais importantes nas três famílias de motores; depois das releases maiores dos navegadores, controlar uma vez o existente; nos redesenhos, olhar conscientemente também para as larguras intermédias, não apenas para os formatos padrão. Quem receia o esforço começa em pequeno — a página portuguesa do ScanU apresenta o serviço, cujo nível gratuito, com um projeto e 500 créditos por mês, chega para os primeiros passos.

O cerne do problema mantém-se, e essa é talvez a verdadeira conclusão: os navegadores continuarão também no futuro a ser programas independentes com motores próprios, os padrões continuarão a deixar margens, e o CSS continuará a calar-se em vez de avisar. As roturas silenciosas não são sinal de trabalho desleixado, mas uma propriedade do sistema da web. Lidar com elas é por isso, acima de tudo, uma questão de visibilidade: quem observa regularmente a sua própria página com os olhos dos três motores — não importa com que ferramenta — tira ao silêncio o seu efeito.