Tab Atkins Jr, um desenvolvedor americano, trabalhou durante muitos anos em uma pequena companhia de software no Texas. Atualmente trabalha no Google como integrante do time de desenvolvimento do Chrome e define sua atuação com sendo um “Web Standards Hacker“.
Ele é membro do Grupo de Trabalho das CSS no W3C e participa como membro e/ou contribuinte de diversos outros Grupos de Trabalho, entre eles os da HTML e das Fontes.
Participa ativamente de várias listas de discussão, escreve para diversos sites de tecnologia web e também no seu Blog pessoal o Tab Completion.
No dia 18 de outubro de 2013, há um mês, ele publicou um documento que chamou de “Proposal for RespImg Syntax” que em tradução livre significa “Proposta de Sintaxe para Imagens Responsivas”.
O documento segue o formato da documentação publicada pelo W3C e a uma primeira vista tem-se a impressão que realmente é um documento daquele Consórcio. Contudo a impressão inicial é logo desfeita, pois o subtítulo do documento esclarece que trata-se de um rascunho de proposta não oficial.
O documento define seu objetivo como sendo o de:
Descrever uma proposta de sintaxe para imagens responsivas que permita ao agente de usuário escolher a versão mais apropriada de uma imagem entre várias candidatas.
Soa bem familiar e aparentemente não há nada de novo em relação aos métodos atuais de definição de imagens responsivas não é mesmo?
O primeiro diferencial é a própria sintaxe que foi bastante simplificada em relação à sintaxe atual. Mas, somente a sintaxe não seria um argumento consistente para implementar um novo método apontando para um rumo bem diverso daquele que vem sendo desenvolvido na busca de uma solução para servir imagens responsivas e que hoje se encontra fundamentado no atributo srcset da HTML5.
O grande diferencial da sintaxe proposta é que ela se propõe a solucionar os problemas próprios das três escolhas para servir imagens responsivas. Problemas esses cujas soluções têm sido o alvo de toda a comunidade envolvida com as imagens responsivas e ainda não solucionado de modo completamente satisfatório.
As escolhas são ditadas pelas peculiaridades de cada projeto e cabe ao autor optar por uma delas.
O termo inglês para essa escolha é “Art-direction”. Se uma imagem grande for reduzida em tamanho é certo que a partir de determinado tamanho, a informação central a ser passada pela imagem se reduza a um tamanho tal que a informação passada pela imagem se perca.
Nessa escolha o autor opta por determinar o tema central da imagem e cortá-la em volta do tema, reduzindo-a em tamanho e mantendo o foco no tema. A medida que o dispositivo diminue em tamanho o corte se faz de modo a captar menos área em torno do tema central.
Nessa hipótese o autor serve a mesma imagem criada com resoluções diferentes, servindo a de alta definição para dispositivos de alta resolução e as de resolução menor para dispositivos com baixa resolução ou limitada largura de banda, evitando perda de tempo com arquivos maiores.
Essa escolha contempla os casos em que o autor precisa considerar o tamanho do dispositivo e os breakpoints projetados.
A necessidade de combinar diferentes resoluções das imagens com o “corte” das imagens acaba criando uma sintaxe verbosa que aliada a necessidade de estudo detalhado para determinar qual imagem servir a cada breakpoint, acaba fazendo com que essa escolha se transforme em uma verdadeira dor de cabeça.
Adicionalmente, há que se considerar o preloader nativo dos navegadores que baixam todas as imagens cuja URL eles conhecem, criando a impossibilidade de servir eficazmente uma só imagem para determinada situação.
A sintaxe consiste em usar-se o elemento img da linguagem HTML com uma série de atributos do tipo src-n (n = 1, 2, 3, etc.). Ao conjunto desses atributos em um elemento denominou-se src-N.
A gramática para a definição do atributo é conforme o formato mostrado a seguir.
<src-n-attribute> = <media-query>? [ <x-based-urls> | <viewport-urls> ] <x-based-urls> = [ <url> <resolution>? ]# <viewport-urls> = <size-viewport-list> ; <size-based-urls> <size-viewport-list> = <image-size> [ ( <viewport-size> ) <image-size> ]* <image-size> = <length> | <percentage> <viewport-size> = <length> <size-based-urls> = [ <url> <integer> ]#
Ops! Não se assuste. A coisa não é tão complicada quanto parece.
A proposta de sintaxe foi desenvolvida de modo a oferecer uma solução consistente para cada uma das três escolhas possíveis, conforme veremos a seguir:
Nessa sintaxe o valor dos atributos src-N começa com a declaração de uma media-query seguida do URL de uma imagem, conforme mostrado a seguir.
<img src-1="(max-width: 400px) oxford-p.jpg"
src-2="(max-width: 1000px) oxford-m.jpg"
src-3="oxford-g.jpg"
src="oxford-falback.jpg"
alt="Maujor e esposa em Oxford.">
Nessa sintaxe os mecanismos internos do navegador percorrem os atributos em ordem numérica e ao encontrar o primeiro casamento com a media-query definida escolhe o URL correspondente e serve a imagem.
Nessa sintaxe o valor do atributo src-n consiste de uma série de URLs, separadas por vírgula, cada uma delas seguida por um identificador de resolução, conforme mostrado a seguir.
<img src-1="oxford.jpg 1x, oxford-alta.jpg 2x, oxford-baixa.jpg .5x"
src="oxford-falback.jpg"
alt="Maujor e esposa em Oxford.">
Nessa sintaxe os mecanismos internos do navegador escolhem a imagem baseados nas informações que eles conseguem processar nativamente a respeito da densidade de pixels da tela, da largura de banda do dispositivo e de qualquer outro fator relevante para a escolha.
O identificador para a imagem com resolução 1x é facultativo (pode constar ou ser omitido da sintaxe).
Cada uma das duas dimensões intrínsecas da imagem escolhida é igual ao tamanho da imagem em pixels dividido pelo respectivo indicador de resolução. Por exemplo se a largura da imagem é de 100px e seu identificador de resolução é 2x sua largura intrínseca será 100/2 = 50px.
Na escolha anterior as imagens criadas em diferentes resoluções têm as mesmas dimensões (CSS pixel), implicando em se servir uma imagem de dimensões fixas (redimensionadas pelo identificador de resolução) para diferentes tamanhos de tela.
Nem sempre isso é desejável. Principalmente em duas situações comuns de projeto.
1-) a imagem deve reencher uma porcentagem do seu container,
2-) o tamanho da imagem é variável de acordo com os breakpoints.
É certo que para esses casos existe uma solução com uso de media-query, mas ela torna-se complicada quando a resolução da imagem está envolvida. Quando servimos a mesma imagem com diferentes dimensões para diferentes resoluções pode ocorrer que uma delas satisfaça a mais de um caso. Manipular tais particularidades pode resultar um um código extremamente longo com repetição exaustiva de URLs além de envolver cálculos matemáticos apurados. Acresce-se ainda o fato de que o código resultante não será apropriado para dispositivos futuros com suas telas de altíssima resolução.
Para cada uma das situações de projeto mencionadas anteriormente é prevista uma sintaxe como mostrado a seguir.
Nesse caso a sintaxe prevê o valor do atributo src-n começando com a porcentagem desejada seguida de ponto e vírgula, seguida por uma lista de URLs separadas por vírgula.
Usando as informações fornecidas pela sintaxe o navegador determina qual será a largura da imagem e converte suas dimensões apropriadamente de modo a otimizar a densidade.
Suponha que temos uma mesma imagem em duas versões, uma com largura de 400px e outra com largura de 800px.
<img src-1="100%; imagem400.jpg 400, imagem800.jpg 800"
src="imagem.jpg"
alt="Descrição da imagem">
Se a largura da viewport for igual a 320px a sintaxe mostrada é equivalente a seguinte sintaxe estudada no item anterior.
<img src-1="imagem400.jpg 1.25x, imagem800.jpg 2.5x"
src="imagem-fallback.jpg"
alt="Descrição da imagem">
Se a largura da viewport for igual a 800px a sintaxe mostrada é equivalente a seguinte sintaxe estudada no item anterior.
<img src-1="imagem400.jpg .5x, imagem800.jpg 1x"
src="imagem-fallback.jpg"
alt="Descrição da imagem">
Indepenente da largura da viewport o navegador saberá qual URL carregar para servir a imagem mais apropriada sem necessidade de que o autor faça qualquer cálculo matemático.
O exemplo a seguir mostra uma situação onde aumentou-se a quantidade de opções de imagem para cobrir uma faixa mais compreensiva de tamanhos de telas e dispositivos.
<img src-1="100%; img1.jpg 160, img2.jpg 320, img3.jpg 640,
img4.jpg 1280, img5.jpg 2560"
src="imagem-fallback.jpg"
alt="Descrição da imagem">
A sintaxe para esse caso é um pouco mais complicada contudo sua estrutura continue a mesma ou seja, a primeira parte do valor do atributo src-n é separada da segunda por ponto e vírgula e a segunda parte é uma lista de URLs e tamanhos de imagem tendo como separador dos itens uma vírgula.
A primeira parte do valor do atributo é uma lista alternada de tamanhos de imagem com valores de breakpoint.
Os valores de breakpoints são colocados entre parenteses para distingui-los visualmente do tamanho da imagem. Os breakpoints são listados em ordem ascendente e os tamanhos de imagens serão servidos entre os dois breakpoints entre os quais foram inseridos na sintaxe.
Para exemplificar a sintaxe considere um layout com três breakpoints (uma coluna – 100%, duas colunas – 50%, três colunas ~33%) como mostrado na figura a seguir.
Supondo que uma imagem será usada para os três layouts (não haverá art-direction) a sintaxe para esse caso é mostrada a seguir.
<img src-1="100% (30em) 50% (50em) calc(33% - 100px);
img100.jpg 100, img200.jpg 200, img400.jpg 400,
img800.jpg 800, img1600.jpg 1600, img3200.jpg 3200"
src="imagem-fallback.jpg"
alt="Descrição da imagem">
A primeira parte do atributo define dois breakpoints (30em e 50em) e declare que até 30em a imagem terá dimensões de 100%, de 30em a 50em as dimensões serão de 50% e acima de 50em as dimensões serão de 33% – 100px.
As seis imagens declaradas cobrem todas as possibilidades. Para telas pequenas uma das imagens entre 100px e 800px será baixada e servida, de acordo com o tamanho e densidade da tela. Para telas de tamanhos médio e grande uma das as imagens entre 400px e maiores será escolhida.
O autor não precisa realizar nenhum cálculo matemático complexo para escolher qual imagem servirá para o que. Basta que ele forneça uma quantidade de imagens que considere razoável para cobrir os casos possíveis e os mecanismos nativos do navegador se encarregarão de fazer a escolha mais adequada.
A largura intrínseca da imagem será igual á largura da imagem escolhida.
Convém esclarecer que apesar do exemplo mostrar imagens com tamanho o dobro da anterior (100px, 200px, 400px, etc) isso não é uma condição mandatória. O autor pode criar imagens do tamanho que achar mais conveniente.
No último item da proposta Tab Atkins descreve o algorítimo a ser implementado no agente de usuário para identificação, seleção e escolha da imagem a ser servida. Não iremos descrever e comentar o algorítimo nessa matéria, mas se você estiver interessado consulte o item 4 – Processing Model da proposta.
Com o aparecimento do design responsivo a busca de uma solução para imagens responsivas, vem sendo perseguida pela comunidade envolvida. Existem vários scripts que se propõem a resolver a questão, contudo nenhum deles oferece uma solução definitiva. Cada um deles tem seus pontos positivos e negativos. Uns se prestam mais para uma determinada situação outros para outras.
Tab Atkins criou uma solução diferente e em lugar de apresentar mais um script está propondo uma sintaxe para ser interpretada pelo agente de usuário, que em última análise será o responsável pela escolha da imagem adequada.
Sem dúvida é uma proposta interessante, que graças ao currículo e ao papel que o autor desempenha na comunidade certamente será considerada e analisada. Pelo menos é essa a minha expectativa.
E você? Gostaria de opinar ou trocar ideias com os demais leitores deste Blog sobre a proposta do Tab Atkins?
Você considera que esse poderá ser o futuro das imagens responsivas?
Fique à vontade. A área de comentários é logo aí embaixo.
Em 2006 comecei a publicar nesse blog uma série de desafios CSS que consistiam em…
Há muito tempo que eu não publico um "Teste seu conhecimento". Esta semana, revendo algumas…
Introdução Elementos da marcação HTML podem ser aninhados uns dentro de outros, criando-se uma cadeia…
HTML5? Web universal? É comum eu me deparar com dúvidas sobre a HTML5 não só…
Pessoal, a BrazilJS Conf 2013 disponibilizou para o Maujor cupons de desconto para serem oferecidos…
Ultimamente recebi vários emails de meus leitores perguntando com criar o efeito que existe no…
View Comments
Já vi muitas técnicas a respeito e essa é bem interessante.
Eu utilizei algo parecido para o site da http://couroshop.com.br
Troca a imagem de acordo com a resolução da tela.
A troca não é perfeita, mas funciona bem.
Solução interessante. O nível de complexidade é bem elevado, introduzir ao dia-a-dia será trabalhoso, mas com o tempo creio que deixarão mais enxuto. A fonte é muito boa!
Legal, site maravilhoso como smepre, post muito bom.
O post é exelente, conhecimento sempre é bom, parabéns.
Ainda prefiro que o server faça esse papel. Não sei se ainda não me senti confortável com essa escrita ou se estou ficando chato mesmo.... kkk. Mas a matéria é ótima. Parabéns!
Abs,
Mauricio
4 Cores Comunicação
Acredito que não seja uma solução definitiva. Me lembro, nas 'épocas jurássicas do HTML' (estamos falando do html 3.5 meados de 1997) a CSS tinha poucos recursos. Lembro que para fazer um efeito hover em um menu, tínhamos que criar duas imagens e inserir um javascript para que funcionasse. Hoje em dia a CSS faz o mesmo trabalho, com a vantagem que eliminamos os scripts e as imagens.
Naquela houve um 'boom' tecnológico, começaram a surgir o mais variados tipos de computadores, monitores de várias resoluções, notebooks, enfim, havia uma luta para uma página web atendesse diferentes computadores.
Hoje estamos passando pelo mesmo problema: novos dispositivos entraram na internet (smartphones, tablets), de várias resoluções, e ao mesmo tempo estamos passando por uma transição para html 5 e o css 3.
Acredito que existem soluções melhores, por exemplo, deixar a tarefa ser feita pelo servidor, ou ainda os principais desenvolvedores entrarem num acordo, que criarem um algorítmico para o redimensionamento automático e assim criar uma definição simples no css.
Parabéns pela matéria e um abraço a todos.
Ainda estou curioso para entender porque o elemento base não é sugerido para indicar a pasta onde estão as imagens.
Com algo assim:
< base href="/img/smallimg/" rel="img" scope="body>section" media="(max-width:50em)">
< base href="/img/bigimg/" rel="img" scope="body>section" media="(min-width:50em)">
eu penso que poderia trocar imediatamente todas as imagens da página. Qual parte eu ainda não peguei que impede de alguém pensar nisso.
Ainda estou curioso para entender porque o elemento base não é sugerido para indicar a pasta onde estão as imagens.
Com algo assim:
section" media="(max-width:50em)">
section" media="(min-width:50em)">
eu penso que poderia trocar imediatamente todas as imagens da página. Qual parte eu ainda não peguei que impede de alguém pensar nisso.
Parece genial, mas o que mais me impressiona foi o esmero dele na redação. Eu nunca tive paciência de ler os documentos do W3C. Quanto mais fazer um texto tão cuidadoso.
Ainda acho que não é a solução definitiva porque não é tão fácil de entender. Continua muito verboso e cheio de minúcias. Eu ainda acredito que uma boa parte do trabalho deve ser feita pelo servidor, embora eu mesmo não faça isso funcionar pra mim como deveria.