Aplicando o progressive enhancement - Blog da Caelum: desenvolvimento, web, mobile, UX e Scrum
Um exemplo prático disso é a utilização da tag <nav> do HTML5. Podemos utilizá-la em nossa marcação visando melhorar a semântica de nossa página, mas se o navegador não a suportar, a lista com os links de navegação ainda continuará acessível:
<li><a href=""#"">Produtos</a></li>
<li><a href=""#"">Promoções</a></li>
<li><a href=""#"">Contato</a></li>
Tags não suportadas são ignoradas, logo, não podem ser estilizadas. isto é um problema, principalmente se você precisa estilizar uma tag contêiner como <section> do HTML5. Todas as versões do Internet Explorer inferiores a versão 9 sofrem deste problema.
<link rel="stylesheet" type="text/css" href="apenas-para-ie6.css">
<link rel="stylesheet" type="text/css" href="apenas-para-ie7.css">
O Internet Explorer 10 não suportará comentários condicionais.
CSS e progressive enhancement
Assim como o HTML, o CSS também é fail-safe: se alguma propriedade não existir, ela será ignorada sem comprometer o acesso ao recurso pelo usuário. Além disso, essa característica pode proporcionar ao mesmo tempo resultados louváveis.
background-color: rgb(127, 214, 110);
background-color: rgba(127, 214, 110, .1);
border-width: 1px 1px 4px 4px;
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.
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.
window.localStorage.cep = "XXXXX-YYY";
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á.
<script type="text/javascript" src="script/modernizr-custom.js"></script>
nope: ['script/localstorage-polyfill.js']
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-".
<html class="localstorage no-boxshadow"]
<!-- restante do html -->
/* aplicado apenas se box-shadow for suportado */
.boxshadow h1 {
box-shadow: -3px 3px 2px
/* aplicado apenas se box-shadow não for suportado */
.no-boxshadow h1 {
A equipe do Modernizr sugere que o programador front-end adicione a classe "no-js" na tag <html>. 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:
/* classe .no-js adicionada */
.no-boxshadow h1, .no-js h1 {
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.
Tags: enhancement, html, progressive, wd-43
Roberto Shizuo 31/10/2012 at 14:09 #
excelente post! realmente é algo bem relacionado com a tal da web responsiva que o Sergio fala no site dele. pra falar a verdade, não vejo tanta diferença.
Flávio Almeida 31/10/2012 at 17:00 #
Olá Shizuo, obrigado! Esses conceitos se aproximam bastante. Eu posso implementar um design responsivo que é aplicado progressivamente tirando vantagem de novos recursos disponibilizados pelos navegadores.
Lucas Polo 31/10/2012 at 18:49 #
Muitas vezes eu ficava preocupado sobre essas questões de compatibilidade, mas dessa forma que você apresentou o desenvolvimento front-end muda muito positivamente. Acho que o segredo é o que você destacou em todo o texto, deixar o site funcional, e depois aplicar objetos que enriquecem o site, mas diminuem a compatibilidade.
Flávio Almeida 31/10/2012 at 19:26 #
Realmente Lucas, se o site já tem uma base funcional, o que for "extra" e não funcionar para determinado browser não impedirá o usuário de utilizar essa base. Mas como disse no post, tem que ser tudo de caso pensado. O que dificulta é quando esta base funcional só é pensada depois do site pronto. É como Aristóteles dizia: "Bem começado, metade feito". Abraço.
Gilson 01/11/2012 at 13:06 #
Flávio Almeida, você esta de parabéns!!
Todas essas questões são importantes, pois traz para reflexão os problemas que enfrentamos com a diversidades de browsers etc..
Márcio Gonçalves 07/11/2012 at 11:15 #
Muito bom o artigo, Flávio. Parabéns! Abraço.
Leandro Rodrigues 07/11/2012 at 13:34 #
Muito obrigado pelo artigo. Realmente o Progressive Enhancement é outro patamar de desenvolvimento.
Adnan Neser Junior 07/11/2012 at 15:22 #
Considero extremamente importante ter um front-end flexível o suficiente para funcionar nos mais diversos browsers existentes sem apresentar erros que acabem com a navegação já que hoje em dia uma parcela considerável do tráfego da web está vindo de aparelhos móveis e esse tipo de acesso tende a crescer ainda mais.
Java Progressivo 13/11/2012 at 13:28 #
Parabéns pela aula e por compartilhar sua experiência profissional…essas coisas são importantes e são pouco ensinadas em cursos, se aprende mais na hora de trabalhar.
Flávio Almeida 13/11/2012 at 13:42 #
Olá! Progressivo, esta é uma preocupação que temos aqui, tanto isso é verdade, que boa parte do que escrevi neste post esta presente nos treinamentos WD-43 e WD-47. É claro que nestes treinamentos a abordagem é mais prática e menos teórica do que aqui.
Rafael 19/11/2012 at 13:48 #
Obrigado pelo conteúdo de qualidade Caelum! Excelente aula!
Leonardo Araújo 20/11/2012 at 09:03 #
Não tem haver com o post, porém os posts da caelum são sempre excelentes, porém estão vindo com uma constância menor … gostaria que voltasse a quantidade do que era antes (a qualidade continua excelente)
Abraão Isvi 20/11/2012 at 13:30 #
Rasa 27/06/2014 at 10:57 #
No exemplo do CSS condicional:
A declaração deve ser nessa ordem certo? Se eu colocar no meu arquivo css o .no-boxshadow h1 antes do .boxshadow não daria certo a condição certo?