No seu livro clássico Como os edifícios aprendem, Stewart Brand destaca uma ideia pelo arquiteto britânico Frank Duffy:
"Um edifício concebido corretamente são diversas camadas de longevidade."
Duffy se referia a essas como camadas de corte. Cada uma dessas camadas se desloca numa escala temporal diferente. Brand ampliou a ideia, propondo seis camadas:
- Sede–o espaço físico do edifício só é alterado em uma escala temporal geológica.
- Estrutura–o edifício por si só pode durar por séculos.
- Casca–a superfície exterior passa por um processo de modernização ou mudança de cor em algumas décadas.
- Serviços–o encanamento e a fiação necessita de manutenção a cada dez anos aproximadamente.
- Plano espacial–a disposição das paredes e portas podem mudar ocasionalmente.
- Material–a organização do mobiliário em um cômodo pode mudar diariamente.
A ideia de camadas de corte também podem ser aplicadas para as nossas criações na web. Nossos nomes de domínios são as sedes geológicas sobre a qual nós construímos. Na outra ponta da escala do tempo, o conteúdo da web–o "material"–podem ser adicionados e atualizados a cada hora, minuto ou mesmo segundos. No meio estão as camadas de estrutura, apresentação e comportamento: HTML, CSS e JavaScript.
Essas camadas podem ter baixo acoplamento, mas eles não são completamente independentes. Assim como um edifício não pode ter mobiliário sem ter cômodos e paredes, uma folha de estilos precisa que exista elementos de marcação para poder funcionar. O acoplamento entre estrutura e apresentação é feito através dos seletores CSS: seletores de elementos, seletores de classes etc. Com JavaScript, o acoplamento é manejado através do vocabulário do Document Object Model, ou DOM.
Em um livro subsequente, The Clock Of The Long Now, Stewart Brand aplicou a ideia de camadas de corte–ou camadas de velocidade–na própria civilização. A camada mais lenta é natureza, depois temos cultura, seguida por governança, infraestrutura e por último comércio e moda são as camadas mais rápidas. Com baixo acoplamento, cada camada depende de sua camada inferior. Por sua vez, o acúmulo de cada camada permite um "adjacente possível" preenchido com mais possibilidades.
Da mesma forma, a expressividade de CSS e JavaScript só é possível com uma base de HTML, que requer uma URL para ser acessível, que igualmente precisa do protocolo HTTP, o qual está localizado dentro do protocolo TCP/IP.
Cada uma das camadas de corte da web pode ser descascada para revelar uma camada interior. Percorrendo esse processo de forma contrária–adicionando cada camada da mesma forma–é um princípio essencial do web design resiliente.
Em 2003, o festival South by Southwest em Austin (Texas) era um evento principalmente voltado para músicos e cineastas. Hoje em dia, as seções de músicas e cinema foram ofuscadas pelo fanatismo do South by Southwest Interactive, dedicado para o mundo digital. Ainda em 2003, South by Southwest Interactive era café pequeno, relegado a um cantinho de um andar do Centro de Convenções de Austin. Era a oportunidade para alguns web designers e blogueiros se juntarem e trocarem ideias. Naquele ano, Steven Champeon e Nick Fink apresentaram uma palestra intitulada Web Design Inclusiva Para o Futuro com Melhoria Contínua. Eles começaram com esse chamado à guerra:
"O web design deve amadurecer e aceitar as evoluções dos últimos anos, abandonar as posturas exclusivistas dos galopantes e acidentados tempos das 'pontocom', perceber a aproximação do futuro dos dispositivos e plataformas de vários os tipos e separar a marcação semântica da lógica de apresentação e comportamento."
Assim como Tim Berners-Lee, Steven Champeon também utilizou SGML, a linguagem de marcação que teria enorme influência sobre o HTML. Ao lidar com documentos que precisavam ser redefinidos para diversos destinos, ele começou a valorizar a separação entre estrutura e apresentação. Um documento com a sua marcação com alto teor semântico pode ser exibido de muitas formas diferentes ao adicionar CSS e JavaScript.
Essa abordagem com camadas da web permite que o mesmo conteúdo seja entregue para uma grande variedade de pessoas. Mas isso não significa que todos têm a mesma experiência. Champeon percebeu que uma grande separação de responsabilidades permitiria que as melhorias fossem aplicadas de acordo com as capacidades do dispositivo do usuário final.
Parafraseando Karl Marx, a melhoria contínua permite que designers requisitar a cada navegador segundo sua capacidade; e entregar a cada dispositivo, segundo suas necessidades.
Alguns web designers tinham receio que a melhoria contínua fosse uma camisa-de-força criativa. Projetar para o menor denominador comum não soava como uma receita para progedir. Mas isso era um equívoco. A melhoria contínua solicita que os designers comecem do menor denominador comum (um documento com boa marcação), mas não existem limites onde eles poderiam ir a partir disso.
Na verdade, é a onipresença do HTML formando um alicerce sólido que permite que web designers utilizem o melhor CSS possível. Graças a Lei de Postel e a forma relaxada que CSS trata seus erros, os designers estão livres para aplicar estilos que só funcionam nos navegadores mais recentes.
Isso significa que nem todos verão o mesmo design visual. Isso não é um bug. Isso é uma funcionalidade da web. Navegadores mais recentes e mais antigos; telas monocromáticas e multicoloridas; conexões rápidas e lentas; telas enormes, pequenas ou até sem telas; todo mundo pode acessar seu conteúdo. Esse conteúdo deve parecer diferente de acordo com as situações diversificadas. Se um website aparenta ser o mesmo em um navegador de dez anos atrás assim como em um dispositivo novo, então provavelmente ele não está usufruindo da flexibilidade notável que a web oferece.
Para dar ênfase a isso, o design Dan Cederholm criou um website para responder a pergunta: "Os sites precisam ser exatamente iguais em todos os navegadores?". Você pode ver a resposta para essa pergunta na URL: dowebsitesneedtolookexactlythesameineverybrowser.com
Correndo o risco de acabar com a surpresa, a resposta é um enorme "Não!". Se você visitar o website, você verá a resposta sendo exibida de forma honrosa. Mas, dependendo das capacidades do seu navegador, você pode ou não pode ver alguns dos floreados estilísticos que foram aplicados para a resposta. Ainda que você não veja nenhuma estilização, você ainda terá o conteúdo marcado com HTML semântico.
Separar estrutura e apresentação é algo relativamente claro. Você pode declarar qualquer estilo que você quiser, sabendo que os navegadores ignorarão o que eles não entendem. Separar estrutura e comportamento já não é tão fácil. Se você dá ao navegador um tanto de JavaScript que ele não entende, não só ele não irá se comportar da forma desejada, como ele se recusará em processar o restante do código.
Antes de você utilizar uma funcionalidade específica do JavaScript, é válido testar para observar se a funcionalidade é suportada. Esse tipo de detecção de funcionalidade pode poupar os visitantes de seu site de ter uma experiência mal-sucedida por conta de uma funcionalidade que não recebe suporte. Se você quer utilizar Ajax, confira em primeiro lugar se aquele navegador oferece suporte ao objeto que você está prestes a utilizar para habilitar aquela funcionalidade Ajax. Se você quer utlizar a API de geolocalização, cheque antes se o navegador oferece suporte a ela.
Uma equipe de desenvolvedores web que trabalhavam no site de notícias da BBC referiu-se a esse tipo de detecção como "dar conta do recado". Navegadores que dão conta do recado possuem uma experiência com melhorias. Navegadores que não dão conta do recado ainda acessam o conteúdo, mas sem as melhorias com JavaScript.
Detecção de funcionalidade, dar conta do recado, de qualquer forma que você queira chamá-la, é uma técnica simples. Vamos supor que você deseja transcorrer o DOM utilizando querySelector e adicionar eventos em alguns nós do documento utilizando addEventListener. Sua lógica de "dar conta do recado" deve parecer com algo assim:
if (document.querySelector && window.addEventListener) { // Melhorias! }
Existem duas observações a serem feitas aqui:
-
Isso é detecção de funcionalidade, não é detecção de navegador. Ao invés de perguntar "Qual navegador que você é?" e tentar adivinhar se oferece suporte a partir da resposta, é mais seguro simplesmente perguntas "Você oferece suporte a essa funcionalidade?".
-
Não existe o bloco
else.
Lá atrás quando os web designers tentavam inserir a lógica do impresso para controlar os navegadores web, um website bem projetado era medido na perfeição dos pixels: o website é exatamente o mesmo em todos os navegadores?
A menos que todos os navegadores ofereçam suporte uma funcionalidade específica–assim, como bordas arredondadas no CSS–então essa funcionalidade estava fora de cogitação. Ao invés disso, designers fingiriam com código a mais e imagens. Os websites careciam de honestidade estrutural. Não era só uma perda de talento e energia por parte dos designers, era uma perda de potencial dos navegadores web da época.
O surgimento dos dispositivos móveis, tablets e do design responsivo ajudou a enfraquecer essa forma de pensar restritiva. Não faz mais parte da realidade esperar que os pixels sejam exibidos da mesma forma entre dispositivos e navegadores. Porém, você ainda encontrará web designers lamentando o fato que que eles precisam oferecer suporte a um navegador antigo já ultrapassado por conta de uma porção da sua audiência. Assim como Brad Frost diz:
"Há uma diferença entre oferecer suporte e otimização."
Oferecer suporte para todos os navegadores... mas não otimizar para nenhum.
Alguns designers entenderam errado a melhoria contínua como se fosse significasse que todas as funcionalidades deveriam ser entregues para todas as pessoas. Na verdade é o oposto. Melhoria contínua significa oferecer a funcionalidade essencial para todos. Depois disso, é cada navegador por si. Longe de restringir quais funcionalidades você pode utilizar, melhoria contínua proporciona aos web designers uma forma segura de utilizar as melhores e mais atualizadas funcionalidades sem se preocupar com navegadores antigos. Scott Jehl, do escritório Filament Group, resumiu de forma sucinta:
"Melhoria Contínua nos liberta de focar nos custos de construir funconalidades para navegadores contemporâneos, sem muito se preocupar em deixar alguém de fora. Com um código bem escrito, o suporte do navegador vai acontecer por tabela."
Se um website é construído utilizando a melhoria contínua, então está tudo bem se uma funcionalidade específica não funciona ou tem problemas de carregamento: Ajax, geolocalização ou qualquer coisa assim. Enquanto a funcionalidade essencial ainda está disponível, web designers não precisa se dobrar pra trás tentando alavancar o suporte para novas funcionalidades em navegadores antigas.
Você também acaba obtendo um website que é mais resiliente ao modelo de tratamento de erros do JavaScript. Mat Marquis trabalhou junto com Scott Jehl no website responsivo do Boston Globe e disse:
"Muitas das funcionalidades legais do Boston Globe não funcionam quando JS deixa de funcionar; "ler as notícias" não é uma delas."
O truque é identificar o que é considerado uma funcionalidade essencial e o que é uma melhoria.