Aplicando o progressive enhancement

Havia um grande rio que cortava duas cidades e dois concorrentes no negócio de travessia. O primeiro utilizava canoa e o segundo jet ski. O primeiro, para melhorar a experiência de seus usuários, adicionou um motor à canoa.

Tudo funcionava perfeitamente até que houve escassez de combustível. Sem energia, o jet ski deixou de funcionar e nenhuma travessia era feita. Com a canoa, ainda era possível navegar, mesmo sem o motor do concorrente, permitindo que os usuários ainda acessem este recurso.

E o Progressive enhancement?

O conceito de progressive enhancement define que a construção de uma página parte de uma base comum e garantida de executar nos mais diversos navegadores para depois acrescentar pequenas melhorias mesmo que só funcionem em navegadores modernos.

Se alguma dessas melhorias não for suportada pelo navegador, o usuário ainda assim conseguirá acessar o website, mesmo que tenha sua experiência reduzida.

Este conceito não se aplica uniformemente numa página e deve ser pensando isoladamente para a estrutura, estilo e comportamento. Cada ponto da tríade se comporta diferentemente quando degradado, isto é, quando não é suportado pelo navegador.

Uma maneira de pensar em cada ponto é através do critério fail-safe.

O critério fail-safe

O critério fail-safe diz que, se um determinado recurso não é suportado pelo navegador, isso não deve resultar em erro, até mesmo sem haver a necessidade de tratamento especial pelo programador. Estão incluídos neste critério o  HTML e o CSS.

No HTML, quando usamos alguma tag desconhecida pelo navegador, nenhum erro é gerado, porque a tag é simplesmente ignorada.

Um exemplo prático disso é a utilização da tag

No exemplo acima, o seletor aplica à propriedade background-color uma cor através de rgb. Esta propriedade repete-se logo em seguida, mas recebendo a mesma cor através de  rbga com suporte à  transparência. O primeiro possui ampla cobertura pelos navegadores, já o segundo, nem tanto.

Acontece que, após a primeira propriedade ter sido atribuída, ela será sobrescrita com o valor da segunda, apenas se o navegador a suportar. Sendo assim, aquele desprovido de transparência terá seu fundo estanque. Nenhum erro ocorrerá, consagrando a natureza fail-safe do CSS.

Você pode encontrar mais exemplos no excelente post css3 e progressive enhancement.

Estilos conflitantes

Diferente do HTML, um design progressivo com CSS demanda do programador front-end um pouco mais de atenção:

Para criar um efeito de sombra, foi utilizada a propriedade border-width com suporte consistente em diversos navegadores. Logo em seguida, a propriedade box-shadow do CSS3, com suporte mais reduzido do que o primeiro, mas com uma experiência visual aprimorada.

Caso o browser não suporte box-shadow, a propriedade border-width será aplicada, mas se a primeira também for suportada, teremos duas propriedades funcionando concomitantemente, o que é um problema.

Repare que aqui não é uma questão de fail-safe, apesar dele também poder fazer parte da equação, mas uma questão condicional, ou seja, aplicação de estilos condicionada ao suporte ou não de deterninado recurso.

JavaScript não-obstrusivo e progressive enhancement

O JavaScript em sua natureza não é fail-safe, sendo o ponto da tríade mais problemático. No lugar de aplicar o conceito fail-safe, aplica-se a técnica de JavaScript não-obstrusivo.

A técnica de JavaScript não-obstrusivo, a grosso modo, parte da premissa na qual usuários sem suporte à JavaScript conseguirão consumir a página, pois o não funcionamento de scripts não bloqueará o acesso ao conteúdo.

Esta técnica muda a maneira pela qual o JavaScript é visto, considerando-o como um "plus" e nunca um recurso fundamental para o funcionamento da página.

É devido a essas características que esta técnica se coaduna com o conceito de progressive enhancement, pois uma base sólida e garantida de funcionar nos mais diversos navegadores é uma base sem JavaScript. Um exemplo:

O código acima guarda o CEP digitado pelo usuário para que ele não tenha que digitá-lo toda vez, mas não funcionará e gerará um erro caso o browser não suporte localStorage do HTML5, como é o caso do IE 7.0 entre outros.

A ausência desse recurso tornará menos agradável a experiência do usuário (ter que digitar toda vez), mas ele poderá continuar comprando, por exemplo.

Feature Detection

Uma das formas de contornar o problema acima é utilizar a técnica de feature detection, que consiste em testar a existência de determinada feature do navegador, permitindo que o programador decida o que fazer. Assim temos:

Polyfill

O programador, após ter elaborado sua lógica de detecção, no lugar de simplesmente deixar de utilizar a feature não suportada, pode criar seu próprio “tapa buraco” ou apelar para bibliotecas de terceiros que mimetizem a feature original.

Estas bibliotecas de terceiros são chamada de polyfills. Por exemplo, para localStorage é possível utilizar o polyfill https://gist.github.com/350433.

Lembre-se que mesmo que você utilize um polyfil, ele deve ser um "plus", e não algo sem o qual seu website não funcionará.

Feature Detection com Modernizr

Nem sempre é fácil desenvolver algoritmos de detecção de recurso com no exemplo acima. Além disso, o algoritmo do exemplo é falho, pois a presença de qualquer objeto com o nome localStorage, pode causar falso positivo.

Uma biblioteca que auxilia no processo de detecção é o Modernizr. Há uma série de verificações, inclusive para os recursos mais recentes do HTML5.

Uma vez detectada a ausência de determinado recurso, basta escolher o polyfill (o seu ou de terceiros) de interesse que o Modernizr se encarregará de carregá-lo para você.

É possível personalizar o build do Modernizr com os testes de interesse em seu próprio site, diminuindo assim o tamanho da biblioteca final.

Aplicação condicional de estilos

O próprio Modernizr ajuda a resolver o problema do nosso CSS, quando temos duas propriedades que não podem ser aplicadas concomitantemente, aplicando-as condicionalmente. Como?

O Modernizr adiciona automaticamente na tag HTML uma classe para cada recurso que detecta e se o recurso não for suportado, ele receberá o prefixo "no-".

O exemplo abaixo ilustra o suporte ao localStorage e ausência ao box-shadow:

Agora, só resta alterar o CSS:

O exemplo acima leva em consideração as classes adicionadas automaticamente pelo Modernizr, garantindo a aplicação condicional de estilos.

E se o JavaScript estiver indisponível?

O Modernizr possui um mecanismo de fallback limitado, porém não menos útil para situações nas quais o suporte ao JavaScript esteja indisponível.

A equipe do Modernizr sugere que o programador front-end adicione a classe “no-js” na tag . Quando o Modernizr é carregado (JavaScript habilitado), ele automaticamente mudará a tag “no-js” para “js”. Esse comportamento possibilita aplicar estilos condicionais baseados na disponibilidade ou não do JavaScript:

Uma possível crítica para esta solução aparece quando o navegador sem suporte à JavaScript tiver suporte à propriedade box-shadow, pois será aplicado o estilo básico utilizando o truque com bordas, ainda sim haverá conformidade com o conceito de progressive enhancement, garantindo uma base sólida de funcionar nos mais diversos navegadores.

Conclusão

Aplicar o conceito de progressive enhancement em cada ponto da tríade estrutura, estilo e comportamento é um quebra-cabeça que demanda ainda mais do programador-front.

Novos problemas necessitam de novas soluções, como é o caso da pluralidade de dispositivos móveis, TV's e até geladeiras que hoje acessam nossos websites.

Existem técnicas e recursos prontos para serem utilizados, o progressive enhancement é uma deles, ainda temos o responsive design entre outros.

Twitter: @flaviohalmeida