Tableless

Busca Menu

O Cenário do Web Design Responsivo

Seja o primeiro a comentar por

O Web design responsivo está por aí há alguns anos, e foi destaque em 2012. Muitas estrelas da web, como Brad Frost e Luke Wroblewski, possuem vasta experiência neste tema e têm nos ajudado a fazer grandes melhorias. Mesmo assim, ainda há muito a ser feito.

Neste artigo, vamos ver o que já é possível fazer hoje, o que será possível no futuro – usando propriedades ainda não padronizadas (como CSS nível 4 e API’s do HTML5) – e o que ainda precisa ser melhorado. Este não é um artigo tão completo, por isso não entraremos a fundo em cada técnica, entretanto, você terá links e referências para explorar por conta própria.

O Cenário das Imagens no Web Design Responsivo

Há um aspecto melhor para começar a falar no web design responsivo que não seja imagens? Este até agora tem sido o tópico principal. E fica cada vez mais importante com a chegada das telas de alta densidade. E quando digo alta densidade, quero dizer telas com uma proporção de pixel maior que 2; esses dispositivos são chamados pela Apple de tela retina, e pelo Google de XHDPI. No web design responsivo, as imagens vem relacionadas a dois grandes desafios: tamanho e desempenho.

A maioria dos designers buscam a perfeição no pixel, porém imagens de tamanho “normal” em dispositivos de alta densidade aparecem pixeladas e borradas. Servir imagens com o dobro do tamanho a esses dispositivos parece ser tentador não é mesmo? No entanto, isso pode criar um problema de performance, pois imagens com o dobro do tamanho levam mais tempo para carregar, e usuários de dispositivos com alta densidade de pixels nem sempre tem a largura de banda necessária para fazer o download dessas imagens. Além disso, dependendo do país em que o usuário vive, esta largura de banda pode ser bem cara.

O segundo problema afeta dispositivos menores: Por que um dispositivo teria que fazer o download de uma imagem de 700 pixels quando ele só necessita de uma de 300? Teríamos uma maneira de “cropar” essas imagens para que usuários de dispositivos menores possam focar no que realmente importa a eles?

Duas soluções de marcação: O elemento <picture> e o atributo srcset

O primeiro passo para resolver o desafio de imagens responsivas é mudar a marcação das imagens embutidas em uma página HTML.

O “Responsive Images Community Group” apoia a proposta de um elemento novo e mais flexível, o elemento picture. O conceito é usar as já tão conhecidas media queries para servir imagens diferentes a diferentes dispositivos. Assim, dispositivos menores receberiam imagens menores. Funciona um pouco como a marcação para vídeo, mas com imagens diferentes sendo refenciadas no elemento de origem.

O código na especificação proposta fica da seguinte forma:

<picture width="500"  height="500">     
  <source  media="(min-width: 45em)" src="large.jpg">
  <source  media="(min-width: 18em)" src="med.jpg">
  <source  src="small.jpg">
  <img  src="small.jpg" alt="">
  <p>Accessible  text</p>
</picture>

Se oferecer fontes diferentes para imagens é possível, poderíamos também imaginar o fornecimento de imagens com recortes diferentes e focar naquilo que realmente importa aos dispositivos menores. O tópico “Art Direction” da W3C mostra um belo exemplo do que poderia ser feito.

(Imagem: Egor Pasko)

A solução vem sendo discutida pelo W3C Responsive Images Community Group mas, até onde sabemos, ainda não é utilizável por nenhum browser. Um polyfill chamado Picturefill está disponível, e faz praticamente a mesma coisa. Utiliza uma div e um atributo na sintaxe por questões de segurança.

A segunda proposta para a marcação de imagens responsivas foi feita pela Apple para a W3C e é chamada de “atributo srcset”; Ela é equivalente ao image-set() (propriedade CSS nível 4). A proposta deste atributo é forçar os navegadores a selecionar um recurso apropriado do set, ao invés de baixar o conjunto.

A sintaxe HTML para esta proposta se baseia na própria tag img, e o exemplo na especificação fica desta forma:

<img  alt="The Breakfast Combo" 
  src="banner.jpeg"
  srcset="banner-HD.jpeg  2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x">

Como você pode ver a sintaxe não é não é tão intuitiva. Os valores da tag consistem em uma string separada por vírgulas. Os valores do atributo são os nomes ou URL’s de várias imagens, a densidade de pixels do dispositivo e o tamanho máximo da viewport a que se destina.

Numa linguagem clara, o que o trecho acima diz é:

  • A imagem padrão é banner.jpeg.
  • O dispositivo que tiver um pixel ratio maior do que 2 deve usar o banner-HD.jpeg.
  • Dispositivos com um tamanho máximo da viewport de 100w deve utilizar o banner-phone.jpeg.
  • Dispositivos com um tamanho máximo da viewport de 100w e um pixel ratio maior que 2 devem utilizar o banner-phone-HD.jpeg.

Caso o atributo srcset não seja suportado, a primeira fonte é a imagem padrão. O sufixo 2x para o banner-HD.jpeg significa que esta imagem em particular deveria ser usada para dispositivos com um pixel ratio maior que 2, e o 100w no banner-phone.jpeg representa o tamanho mínimo da viewport em que esta imagem deve ser utilizada. Devido a sua complexidade, a sintaxe do atributo srcset ainda não foi implementada nos navegadores.

A sintaxe da propriedade CSS image-set() funciona praticamente da mesma forma e permite que você carregue uma determinada imagem de background tendo como base a resolução da tela:

background-image: image-set(  "foo.png" 1x,
  "foo-2x.png"  2x,
  "foo-print.png"  600dpi );

Esta proposta ainda esta em fase de projeto na W3C, e por enquanto funciona no Safari (6+) e no Chrome (21+).

Formatos de Imagem, Compressão e SVG: A mudança de como trabalhamos com imagens na web.

Como podem ver, as tentativas em encontrar um novo formato de marcação para imagens ainda são altamente experiementais.Isto por si só levantou uma questão sobre formatos de imagens. Podemos conceber uma solução responsiva para mudar a forma como lidamos com eles?

O primeiro passo seria buscar formatos alternativos de imagens que tenham uma melhor taxa de compressão. O Google, por exemplo, desenvolveu um novo formato de imagem chamado WebP, o qual é 26% menor que o PNG e 25 a 34% menor que o JPEG. O formato é suportado pelo Chrome, Opera, Yandex, Android e Safari, e pode ser ativado no Internet Explorer usando o Google Chrome Frameplugin. O problema principal deste formato é que o firefox não tem planos de implementá-lo. Sabendo disto, por enquanto, o seu uso generalizado é improvável.

Outra ideia que está ganhando popularidade são as imagens JPEG progressivas. Estas imagens são, como o nome sugere, progressivamente renderizadas. A primeira renderização é embaçada, então a imagem vai progressivamente ganhando nitidez. Já as imagens JPEG não-progressivas são renderizadas de cima pra baixo. Em seu artigo “JPEG’s progressivos: Uma nova boa prática”, Ann Robson afirma que o JPEG progressivo aparenta ser mais veloz que o JPEG baseline. Um JPEG progressivo dá ao usuário uma impressão geral sobre a imagem antes mesmo de ela ser totalmente carregada, o que beneficia a experiência do usuário.

Uma outra solução aos problemas de performance e tamanho de imagem está em alterar a taxa de compressão das imagens. Durante muito tempo, pensamos que o alargamento da taxa de compressão de uma imagem prejudicaria a sua qualidade. Entretanto, Daan Jobsis fez uma extensa pesquisa sobre o assunto e escreveu um artigo a respeito chamado “Retina Revolution”. Em seus experimentos, ele testou diferentes tamanhos de imagens e taxas de compressão, o que gerou uma solução muito interessante. Se você dobrar o tamanho de uma imagem, mas também usar uma taxa de compressão mais alta, a imagem terá um arquivo com um tamanho menor que o original, mas ainda serão nítidas em telas normais e de alta densidade. Com esta técnica, Jobsis reduziu em 75% o peso da imagem.

Dadas as dores de cabeça das imagens responsivas, a ideia de ganhar a independência do pixel a partir de imagens, sempre que possível, está seduzindo cada vez mais designers e desenvolvedores. O formato SVG, por exemplo, pode ser usado para criar todos os elementos da interface de um website independente da resolução. Os elementos serão dimensionados para dispositivos menores e não ficarão pixelados nos dispositivos de alta densidade de pixels. Font icons são outra tendência crescente. Eles envolvem o uso de uma fonte, onde os caracteres alfanuméricos são substituídos por ícones glifos, dando a flexibilidade que uma fonte oferece. Infelizmente, esta solução ainda não funciona com imagens, o que faz com que seja ansiosamente esperado uma marcação ou formato de imagem viável.

O Desafio do Layout Responsivo: Reorganizar e Trabalhar o Conteúdo sem Tocar no HTML?

Sejamos realistas, os grids fluidos usados atualmente, produzidos com floats e blocos inline, são um pobre improviso aguardando uma solução melhor. Trabalhar com o layout e rearranjar blocos numa página mobile sem recorrer ao JavaScript hoje em dia é um pesadelo, e não é nem um pouco flexível. Isto é algo crucial a websites criados com CMS, onde o designer não pode alterar o HTML de cada página ou versão do site.

E aí, como isto pode ser melhorado?

Quatro Soluções com CSS3 que abordam o problema do Layout Flexível

A solução mais óbvia possível é o modelo de box flexível do CSS3 (ou flexbox). Seu status atual é a de “candidato a recomendação” na W3C, e é suportado pela maioria dos browsers mobile e desktop (no IE começou na versão 10). O model permite reorganizar facilmente os elementos na tela, independente do HTML. Você também pode alterar o fluxo e a orientação do box, distribuir o espaço e alinhá-lo de acordo com o contexto. Abaixo um exemplo de layout que poderia ser reorganizado para mobile. A sintaxe ficaria assim:

.parent {
   display: flex;
   flex-flow: column; /* exibe itens na coluna */
}

.children {
   order: 1; /* muda a ordem dos elementos */
}

O artigo “CSS3 Flexible Box Layout Explained” dará a você uma compreensão mais profunda de como o flexbox funciona. (nota do tradutor: o bbburp traduziu um excelente artigo sobre flexbox)

Outra solução bastante próxima do conceito flexbox de reordenação de blocos na página, porém com JavaScript, é o Relocate.

Um segundo tipo de layout, que hoje em dia é bastante utilizado no design responsivo, é o layout multiple-column do CSS3. O módulo está no estágio de “candidato a recomendação” na W3C, e funciona muito bem na maioria dos browsers (aguardado para IE9 e abaixo). A principal vantagem deste model é que o conteúdo pode fluir de uma coluna a outra, proporcionando um ganho enorme na flexibilidade. No que diz respeito a responsividade, o número de colunas pode ser alterado de acordo com o tamanho da viewport.

É possível apenas ajustar o tamanho das colunas e deixar com que o browser calcule o seu número de acordo com o espaço disponível. Também é possível ajustar o número de colunas, com gaps e regras entre elas, e deixar que o browser calcule a sua largura.

A sintaxe se parece com isto:

.container {
   column-width: 10em ;
   /* O browser vai criar uma coluna de 10em.
   O número de colunas vai depender dos espaço disponível */
}

.container {
   columns: 5;
   /* O browser vai criar 5 colunas.
   O tamanho das colunas vai depender do espaço disponível. */
   column-gap: 2em;
}

Para aprender mais, leia o artigo de David Walsh: “CSS Columns”.

Uma terceira propriedade CSS3 que pode ganhar mais atenção no futuro é a CSS3 grid layout. Esta propriedade dá a designers e desenvolvedores um grid flexível, onde eles podem trabalhar com na criação de layouts diferentes. Ela permite que os elementos de conteúdo sejam exibidos nas linhas e colunas sem uma estrutura definida. Primeiro você deve declarar um grid no container, e então colocar todos os elementos filhos neste grid virtual. Você pode, então, definir um grid diferente para dispositivos menores ou alterar a posição dos elementos no grid. Isto gera uma enorme flexibilidade quando usado com media queries, em mudanças de orientação, etc.

A sintaxe para esta propriedade é assim (projeto de trabalho no W3C – working draft – a partir de 2 de abril de 2013):

.parent {
   display: grid; /* declare o grid */
   grid-definition-columns: 1stgridsize  2ndgridsize …;
   grid-definition-rows: 1strowsize  2ndrowsize …;
}

.element {
   grid-column: 1;
   grid-row: 1;
}

.element2 {
   grid-column: 1; 
   grid-row: 3;
}

Para definir o tamanho das linhas e colunas você pode usar diversas unidades, conforme detalhado na especificação. Para posicionar os elementos, a especificação diz o seguinte: “Cada parte está posicionada entre as linhas do grid, fazendo referência a linha de grid inicial e então especificando, se houver mais de uma, o número de linhas ou colunas distribuídas para determinar a linha de grid final, delimitando a área do layout”.

O maior problema com esta propriedade é que é suportada apenas pelo IE10. Para aprender mais sobre este layout, leia o artigo “Giving Content Priority With CSS3 Grid Layout” de Rachel Andrew. Além disso, note que a especificação e a sintaxe para grid layouts com CSS foi alterada no dia 2 de abril de 2013. Andrew escreveu uma atualização sobre a sintaxe, a qual foi intitulada de “CSS Grid Layout: What Has Changed?” (CSS Grid Layout: O que mudou?).

O último layout, que pode tornar-se bastante útil no futuro se implementado nos browsers, é o CSS3 template layout. Este módulo CSS3 funciona associando um elemento ao “nome” do layout, e em seguida ordenando os elementos num grid invisível. O grid pode ser fixo ou flexível, e pode ser alterado de acordo com o tamanho da viewport.

A sintaxe fica assim:

.parent {
   display: "ab"
            "cd"; /* criando um grid invisível */
}

.child1 {
   position: a;
}

.child2 {
   position: b;
}

.child3 {
   position: c;
}

.child4 {
   position: d;
}

E é renderizado assim:

Infelizmente, o suporte a navegadores para este módulo é praticamente nulo. Talvez algum dia, se designers e desenvolvedores mostrarem interesse suficiente nesta especificação, algum fabricante de browser possa implementá-lo. Por enquanto, você pode testá-lo usando um polyfill.

Unidades Relativas da Viewport e o fim do Layout baseado em pixels

Medidas de comprimento baseadas na viewportvw, vh, vm, vmin e vmax – são unidades de medida relativa das dimensões da própria viewport.

Uma unidade vw é igual a 1% da largura do bloco inicial que a contém. Se a largura da viewport é 320, então 1vw é 1 x 320/100 = 3.2 pixels.

A unidade vh funciona da mesma maneira, mas é relativa a altura da viewport. Desta forma, 50 vh equivale a 50% da altura do documento. A esta altura você pode se perguntar qual a diferença desta unidade para a percentual. A diferença é que enquanto a unidade percentual é relativa ao tamanho do elemento pai, as unidades vh e vw serão sempre relativas ao tamanho da viewport, independente do tamanho dos seus elementos-pai.

Isso fica bem interessante quando você quer, por exemplo, criar um container e ter a certeza de que ele nunca se extenderá abaixo da altura do viewport para que o usuário não precise rolar a página para baixo para achar o conteúdo.  Também possibilita que criemos um elemento com 100% da altura sem alterar todos os containers pai.

A unidade vmin é igualada ao menor valor da unidade vm ou vh, e vmax ao maior valor; por isso, essas unidades também respondem perfeitamente às alterações na orientação dos dispositivos. Infelizmente, por enquanto, essas unidades não são suportadas pelo browser do Android. Sendo assim, pode ser que você ainda tenha que aguardar um tempo para utilizá-las.

Uma Palavra sobre Tipografia Adaptável (Adaptive Typography)

O layout de um site vai depender muito do conteúdo. Não posso concluir uma seção que fala sobre as diversas possibilidades do layout responsivo sem abordar a tipografia. O CSS3 introduziu uma unidade para fontes que pode ser bastante útil a tipografia responsiva: a unidade “rem. Enquanto as fontes medidas pela unidade “em” apresentam um tamanho herdado do seu elemento pai, a fonte medida pela unidade “rem” é relativa ao tamanho da fonte do seu elemento root (ou raiz). Para um site responsivo, você poderia escrever o CSS como o código abaixo, e em seguida alterar o tamanho de todas as fontes simplesmente mudando o tamanho da fonte especificada no elemento html:

html {
   font-size: 14px;
}

p {
   font-size: 1rem /* isto tem 14px */
}

@media screen and (max-width:380px) {
   html {
      font-size: 12px;
      /* tornando a fonte menor para dispositivos mobile */
   }

   p {
      font-size: 1rem;
      /* isto agora equivale a 12px */
   }
}

Com exceção do IE8 e do Opera mini, o suporte ao “rem é excelente. Para aprender mais sobre a unidade rem, leia o artigo de Matthew Lettini “In Defense of Rem Units”.

A Melhor Maneira de Trabalhar Responsivamente com Outros Conteúdos Complexos

Aos poucos vamos ficando cada vez melhor em lidar com imagens e textos em layouts responsivos, embora ainda seja necessário encontrar soluções para outros tipos mais complexos de conteúdo

Lidando com Formulários no Website Responsivo

De um modo geral, lidar com formulários, especialmente os muito grandes, no web design responsivo é um enorme desafio! Quanto maior o formulário, mais complicado será adaptá-lo a dispositivos menores. A adaptação física não é tão difícil; a maioria dos designers simplesmente colocam os elementos do formulário numa única coluna e esticam os inputs completando a largura da tela. Entretanto, fazer formulários visualmente atraentes não é o bastante. Temos que torná-los fáceis de usar também nos dispositivos mobile.

Para começar, Luke Wroblewski aconselha evitar inputs de texto, contando com checkboxes, radio buttons e menus drop-downs, e utilizando o select sempre que possível. Desta forma, o usuário precisa digitar o mínimo de informação. Outra dica é não fazer com que o usuário aperte o botão “enviar” antes de obter um feedback sobre o conteúdo a ser submetido. A checagem de erros imediata é extremamente importante no mobile, onde a maioria dos formulários ultrapassa a altura da tela. Se o usuário digitar um campo incorretamente e tiver que enviar o formulário para só assim perceber o erro, provavelmente ele não verá onde o erro está.

No futuro, novos inputs e atributos HTML5 serão de grande ajuda na melhoria dos formulários, e não haverá a necessidade de utilizar tanto JavaScript. Por exemplo, você poderia usar o atributo required para dar feedback imediato sobre um campo específico. Infelizmente, por enquanto, o suporte para dispositivos mobile ainda é ruim. O atributo autocomplete também poderia ajudar a montar formulários mais responsivos.

Um smartphone é um bem pessoal, por isso podemos assumir que dados como nome e endereço serão algo consistente. Usando o atributo autocomplete do HTML5 poderíamos fazer um auto-preenchimento dos campos sem que o usuário tivesse que digitar todas as informações. Há ainda uma lista inteira de novos inputs HTML5 que podem ser utilizados muito em breve, a fim de tornar os formulários mais responsivos.

Datas em elementos de formulário são um bom exemplo do que se pode melhorar com o HTML5. Já estamos acostumados a contar com JavaScript ao criar calendários. Eles podem ser muito úteis se utilizados em grandes telas desktop, mas difíceis de usar em dispositivos touch screen, pois selecionar a data certa com o dedo é difícil quando a área sensível ao toque é muito pequena.

Uma solução promissora está no novo input type=”date” do HTML5 , que define uma string no formato de data. Já o input type=”datetime” define uma string no formato de data e hora. A grande vantagem deste método é que deixamos o browser decidir qual UI utilizar. Desta forma, a UI é automaticamente otimizada em dispositivos mobile. Abaixo um exemplo da aparência de um input type=”date” no desktop, em smartphone e tablet com Android (com o browser Chrome), Iphone e Ipad.

Note que as screenshots foram feitas em meu browser e no Android phone, então a linguagem foi automaticamente adaptada ao sistema de linguagem (Francês). Ao utilizar componentes nativos, você não precisa mais adaptar a lingua para diferentes versões do site.

Por enquanto, com exceção do Opera e do Chrome, não há suporte ao input type=”date” para o desktop. Browsers nativos do Android ainda não o suportam completamente, mas o Chrome Android sim, e também o Safari para iOS. O fato é que ainda há muito a ser trabalhado para sermos capazes de utilizar esta solução em sites responsivos. Enquanto isto, você pode usar um polyfill como o Mobiscroll para browsers mobile que não suportarem o atributo nativamente.

Além destas soluções de inputs HTML5, foram feitas tentativas para melhorar outros padrões de design, como as senhas do mobile e inputs complexos utilizando máscaras. Como você pode notar, isto tudo é experimental. O formulário responsivo perfeito não existe no momento; Muito ainda deve ser feito neste campo.

Lidando com Tabelas em Sites Responsivos

Outro tipo de conteúdo que fica bastante confuso em sites mobile e responsivos são as tabelas. A maioria das tabelas são orientadas horizontalmente e apresentam uma grande quantidade de dados de uma só vez. Imagine então que exibi-las corretamente em small screens seja bem complicado. Tabelas HTML são bastante flexíveis – você pode usar porcentagens para mudar a largura das colunas – o que também pode rapidamente tornar o conteúdo ilegível.

Ainda não encontraram uma forma perfeita de mostrar tabelas, mas algumas sugestões foram feitas:

Uma forma de abordagem é esconder colunas consideradas “menos importantes”, e oferecer checkboxes para que o usuário escolha quais ele deseja ver. No desktop, todas as colunas seriam mostradas, enquanto no mobile o número de colunas dependeria do tamanho da tela. O Filament Group explica este método e demonstra em um de seus artigos. A solução também é usada no table column toggle do jQuery Mobile.

A segunda abordagem brinca com a ideia de scroll em tabelas. Você poderia “fixar” uma única coluna com tamanho fixo a esquerda, e então deixar uma scroll bar numa pequena parte da tabela a direita. David Bushell implementa esta ideia em um artigo usando CSS para exibir todo o conteúdo da

 

do lado esquerdo da tabela, deixando o usuário mover-se pelo conteúdo a direita através da scroll bar. Zurb utiliza a mesma ideia, mas de um jeito diferente, neste plug in. Neste caso, as headers ficam no topo da tabela, e a tabela é duplicada com JavaScript de modo que apenas a primeira coluna seja mostrada a esquerda, e as demais colunas sejam mostradas do lado direito através da scroll bar.

A grande questão em utilizar scroll bars e propriedades CSS tais como overflow: auto é que muitos dispositivos mobile e tablets simplesmente não exibem uma scroll bar visível. A área da direita da tabela permite a rolagem, mas o usuário não terá qualquer indício visual desta possibilidade. Precisamos encontrar uma maneira de indicar que há mais conteúdo a ser exibido à direita.

Uma terceira abordagem é em reestruturar a tabela e dividir as colunas em listas de itens com cabeçalhos.Esta técnica é utilizada no “reflow mode” no jQuery Mobile e foi explicada por Chris Coyier em seu artigo “Responsive Data Tables”.

Existem diversas outras técnicas, e qual usar depende muito do seu projeto. Não há dois projetos iguais, por isso só posso mostrar como outras pessoas estão lidando com isto. Se você chegar a uma boa solução, por favor compartilhe nos comentários, no Twitter ou em qualquer outro lugar. Estamos no mesmo barco, e exibir tabelas no mobile está uma droga (é sério). Então vamos melhorá-las juntos!

Incorporando Conteúdo de Terceiros: O problema do Iframe Responsivo

Muitos desses conteúdos, ao serem incorporados, fazem você utilizar iframes. Mas vamos encarar: lidar com iframes no design responsivo é doloroso. O  grande problema é que iframes exigem largura e altura fixa diretamente no seu código HTML. Forçar uma largura de 100% no iframe deveria resolver, mas daí você perderia a proporção do conteúdo incorporado. Então, para incorporar um vídeo ou slideshow e preservar a proporção original, seria necessário encontrar uma solução alternativa.

Uma solução com HTML e CSS

Thierry Koblentz escreveu um ótimo artigo chamado “Creating Intrinsic Ratios for Vídeo” (criando proporções intrínsecas para vídeos), onde ele propõe uma forma de incorporar vídeos responsivos usando uma proporção 16:9. Esta solução pode ser estendida a outros tipos de conteúdos, como apresentações em SlideShare e Google Maps. Koblentz envolve o iframe num container usando uma classe a qual podemos manipular no CSS. O container torna possível o iframe ser redimensionado fluidamente, mesmo tendo um valor fixo de pixels no HTML. O código, adaptado por Anders M. Andersen, fica assim:

.embed-container  {
   position: relative;
   padding-bottom: 56.25%; /* 16:9 ratio */
   padding-top: 30px; /* solução para IE 6 */
   height: 0;
   overflow: hidden;
}

.embed-container iframe,
.embed-container object,
.embed-container embed {
   position: absolute;
   top: 0;
   left: 0;
   width: 100%;
   height: 100%;
}

Isto vai funcionar em todos os iframes. O único problema é que você terá que envolver todos os iframes de seu site em um elemento. Enquanto esta técnica funcionaria muito bem para desenvolvedores que tivessem controle total de seu código, ou para clientes que estivessem razoavelmente familiarizados com HTML, não funcionaria com clientes que não tivessem qualquer habilidade técnica. Você poderia, é claro, usar JavaScript para detectar os elementos iframe e automaticamente incorporá-los na classe, mas como podemos ver, seria uma grande solução, mas não a solução perfeita.

Lidando com Vídeos Responsivos no Futuro

O HTML5 abre um mundo de possibilidades para o vídeo – particularmente com o elemento video. A grande notícia é que o suporte a este elemento é surpreendentemente bom em dispositivos mobile! Com exceção do Opera Mini, a maioria dos browsers o suportam. O elemento video também é bastante flexível, e apresentar um vídeo responsivo é tão simples quanto isto:

video {
   max-width: 100%;
   height: auto;
}

Você provavelmente está se perguntando, “Então, qual o problema?”

O problema é que, embora YouTube e Vimeo suportem o elemento video, você ainda precisa incorporar vídeos usando o tal método do iframe. E isso meu amigo, é uma droga. Sendo assim, até que YouTube e Vimeo ofereçam um meio de incorporar vídeos em sites utilizando a tag video do HTML5, teremos que descobrir soluções para que incorporações de vídeo trabalhem adequadamente em sites responsivos. Pensando nisto, Chris Coyier criou uma solução com um plugin jQuery chamado FitVids.js. Ele usa a primeira técnica mencionada acima: cria um container em torno do iframe e preserva a sua proporção.

Incorporando Google Maps

Se você incorporou um Google Map em seu site, a técnica descrita acima com container e CSS funcionará. Mas, de novo, é um hackzinho sujo. Além disso, o mapa vai redimensionar proporcionalmente e pode ficar tão pequeno, que poderá perder a área de foco que você quer mostrar ao usuário. A página do Google Maps para mobile diz que você pode utilizar uma API de mapas estáticos para incorporações mobile. Usar um mapa estático de fato eliminaria os problemas com iframe. Brad Frost escreveu um belo artigo a respeito, e criou uma demo de mapas adaptáveis (adaptive maps) onde utiliza a mesma técnica. Um JavaScript detecta o tamanho da tela, em seguida o iframe é substituído pelo mapa estático em celulares. Como podemos ver, temos novamente que recorrer a técnicas que lidem com problemas de iframe, devido a ausência de uma solução nativa (ou seja, do Google).

Precisamos de APIS Melhores

Agora a grande pergunta: Há um jeito melhor? O maior problema em usar iframes para incorporar o conteúdo de terceiros responsivamente é a falta de controle sobre o código gerado. Desenvolvedores e designers são muito dependentes de conteúdo de terceiros e, por extensão, o seu HTML gerado. E o número de sites que oferecem conteúdo de outros sites cresce rapidamente. Precisamos de soluções muito melhores do que iframes para incorporar este conteúdo.

Agora, fale a verdade: incorporar iframes do Facebook é um verdadeiro sofrimento. A falta de controle sobre o CSS pode fazer nosso trabalho parecer bem desleixado e algumas vezes arruinar o design. A web é um lugar aberto, por isso talvez fosse um bom momento em começar a pensar em mais API’s abertas! No futuro, vamos precisar de API’s que sejam melhores e mais simples de utilizar, de modo que qualquer pessoa possa incorporar um conteúdo de maneira flexível, sem ter que contar com iframes fixos não responsivos. No entanto, até que decidam criar essas API’s, estamos presos a iframes medíocres, tendo que recorrer a truques para torná-los viáveis.

Navegação Responsiva: Um Panorama pelas Soluções Atuais

Outro grande desafio é o que fazer com a navegação. Quanto mais complexa e profunda a arquitetura de um website, mais inventivos precisamos ser.

(Nota do tradutor: publiquei aqui no Tableless uma tradução sobre padrões complexos de navegação no web design responsivo)

Uma das primeiras tentativas de lidar com isto de maneira simples foi converter a navegação em um menu dropdown para telas pequenas. Infelizmente, esta forma não é a ideal. Primeiro porque esta solução fica terrivelmente complicada numa navegação multi-level, podendo também causar problemas de acessibilidade. Eu recomendo o artigo “Stop Misusing Select Menus” para entender todos os problemas consequentes desta técnica.

Algumas pessoas, incluindo Brad Frost e Luke Wroblewski, têm tentado resolver este problema. Brad Frost compilou algumas de suas técnicas no site This Is Responsive, na seção de navegação.

A navegação alternada (toggle navigation) envolve ocultar o menu nos dispositivos mobile, exibindo um único link. Quando o usuário dá um clique todos os links aparecem como um bloco de elementos abaixo do link, empurrando o conteúdo principal pra baixo da navegação.

Uma variante deste tipo de menu, inspirado em alguns padrões de aplicativos nativos, é a navegação off-canvas. Essa navegação fica escondida debaixo de um link no menu ou ícone. Quano o usuário clica, a navegação desliza em forma de painel pela esquerda ou direita, empurrando o conteúdo principal.

O problema com essas técnicas é que a navegação permanece no topo da tela. Neste artigo “Responsive Navigation: Optimizing for Touch Across Devices”, Luke Wroblewski mostra quais zonas são facilmente acessíveis aos diferentes tipos de dispositivos. A área superior esquerda é a mais difícil de chegar num dispositivo mobile.

Com base nisto, Jason Weaver criou algumas demos com a navegação no bottom da tela. Uma solução é o footer anchor (âncora de rodapé), com a navegação fixada no bottom da página para dispositivos menores, e um menu link que envia o usuário até lá. Esta técnica utiliza o sistema link âncora do HTML.

Diversas outras tentativas foram feitas para solucionar problemas de navegação no web design responsivo. Como você pode ver, ainda não há uma solução perfeita; isso realmente depende do projeto e da profundidade da navegação. Felizmente para nós, alguma pessoas estão tentando resolver esse problema e têm compartilhado suas experiências com a comunidade.

Outra questão não resolvida é qual ícone usar para dizer ao usuário “Olá! há um menu escondido aqui. Clique em mim!”. Alguns websites tem um símbolo de mais (+), outros uma grade de quadrados e alguns têm três linhas (como um ícone de hamburger).

Para ver esses ícones usado em websites reais, dê uma olhada no “We Need a Standard ‘Show Navigation’ Icon for Responsive Web Design” (precisamos de um ícone padrão no web design responsivo para “mostrar a navegação”).

O maior problema é descobrir qual desses ícones seria o mais reconhecível a uma quantidade de usuários. Se todos concordássemos em usar um deles, os usuários seriam instruídos a reconhecê-los. O problema é, qual escolher? Eu realmente gostaria de saber qual ícone vocês usam, então não hesite em compartilhar nos comentários 1 (1 – nota do tradutor: para deixar sua opinião sobre qual o ícone você utiliza, acesse o artigo original).

Especificidades Mobile: “O usuário está com um dispositivo mobile? Se sim, o que pode ser feito?”

Dispositivos mobile e tablets são um mundo novo – longe dos computadores desktops -, com suas próprias regras, comportamentos e capacidades. Podemos querer adaptar nossos projetos a esta nova gama de capacidades.

Detectando Capacidades Touch com JavaScript Nativo

Além do tamanho da tela, aposto que se você perguntasse qual a principal diferença entre mobiles (incluindo tablets) e desktops, a maioria das pessoas diriam ser a capacidade touch. Não há mouse num celular (é verdade!), e com exceção de alguns dispositivos híbridos raros, em que você pode plugar um mouse, você não vai poder realizar muitos eventos num tablet com um mouse. Isto significa que, dependendo do browser, a pseudo-classe :hover do CSS pode não funcionar. Alguns browsers são inteligentes o bastante para oferecer um fallback nativo ao evento do hover traduzindo em um evento touch. Infelizmente, nem todos os browsers são tão flexíveis assim. Criar um design que não dependa de elementos ocultos, a serem revelados sob eventos :hover, seria o mais sensato.

Capturar eventos touch poderia também ser uma outra solução. A W3C working group começou a trabalhar numa especificação de eventos touch. Futuramente, seremos capazes de capturar eventos tais como touchstart, touchmove e toucheend. Seremos capazes de lidar com esses eventos diretamente no JavaScript sem a necessidade de frameworks de terceiros como Hammer.js ou jGestures. Mas JavaScript é uma coisa – E o que acontece com o CSS?

CSS nível 4 – Media Query “Pointer”

O CSS nível 4 especifica uma nova media querry chamada “pointer”, que pode ser usada para capturar a existência e precisão de um dispositivo apontador (pointing device), tal como um mouse. A media query tem um dos três valores:

  • none
    O dispositivo não tem nenhum pointing device.
  • coarse
    O dispositivo tem um pointing device com precisão limitada, por exemplo, um celular ou tablet com capacidades touch, onde o “pointer” seria um dedo.
  • fine
    O dispositivo tem um pointing device preciso, como um mouse, trackpad ou caneta (stylus).

Usando esta media query, nós podemos ampliar a maneira de utilização de botões e links para dispositivos móveis:

@media  (pointer:coarse) {
   input[type="submit"],
       a.button {
       min-width: 30px;
       min-height: 40px;
       background: transparent;
   }
}

A media query pointer ainda não é suportada – apenas sendo proposta. Todavia, ser potencial é enorme, pois seria permitiria detectar dispositivos touch via CSS, sem a necessidade de uma bilbioteca, como Modernizr.

CSS nível 4 – Media Query “Hover”

A especificação CSS nível 4 propõe uma nova media query hover, que detecta se o sistema primário do dispositivo dá suporte ao hover. Ele retorna valores boleanos: 1 se o dispositivo suporta hover, 0 se não suporta. Note que isto não tem nada a ver com a pseudo-classe :hover.

Usando a media query hover podemos melhorar a interface e ocultar certas características dos dispositivos que o suportam. O código fica mais ou menos assim:

@media  (hover) {
   .hovercontent { display: none; }
   /* oculta o conteúdo apenas para dispositivos com suporte ao hover. */
   .hovercontent:hover { display: block; }
}

Pode também ser usado para criar menus dropdowns com hover; e o fallback para dispositivos mobile é em CSS nativo, sem a necessidade de um framework que detecte a feature.

CSS nível 4 – Media Query Luminosity

Outra capacidade dos dispositivos mobile é o sensor de luminosidade. A especificação CSS nível 4 tem a media query luminosity, que nos dá acesso ao sensor de luz dos dispositivos diretamente no CSS. Abaixo a descrição da especificação.

A característica da media “luminosity” é usada para verificar a luminosidade do ambiente o qual o dispositivo está sendo usado, e permitir que o autor ajuste o estilo do documento responsivamente.

No futuro, seremos capazes de criar websites que respondam a luminosidade do ambiente. Isto vai melhorar muito a experiência do usuário. Seremos capazes de detectar, por exemplo, ambientes extremamente brilhantes usando o valor washed, adaptando o contraste do site ao local. O valor dim é usado para ambientes escuros (a noite por exemplo), e o valor normal para quando o nível de luminosidade não necessita de qualquer tipo de adaptação.

O código fica assim:

@media  (luminosity: washed) {
   p { background: white; color: black; font-size: 2em; }
}

Como podemos ver, as CSS4 prometem um monte de coisas novas. Se você está curioso em ver o que vem por aí – não só para mobile – então dê uma olhada na “Sneak Peek Into the Future: Selectors, Level 4”

Mais Recursos Mobile para Detectar o Uso de API’s e JavaScript

Muitas outras coisas poderiam ser detectadas para tornar a experiência do usuário surpreendente num site responsivo. Por exemplo, poderíamos ter acesso nativo ao giroscópio, bússola e acelerômetro para detectar a orientação do dispositivo usando o DeviceOrientationEvent do HTML5. O suporte ao DeviceOrientationEvent nos browsers do Android e iOS está ficando cada vez melhor, mas a especificação ainda está em fase de rascunho. No entanto, a API parece promissora. Imagine jogar jogos HTML5 diretamente no browser!

Outra API que seria particularmente utilizada por alguns usuários mobile é a de geolocation. A boa notícia é que ela já é bem suportada. Esta API nos permite localizar geograficamente o usuário usando o GPS e inferir sua localização a partir de sinais de rede, como IP, RFID, Wi-Fi e endereços MAC Bluetooth. Isto pode ser usado em alguns sites responsivos para oferecer informações contextuais aos usuários. Uma grande cadeia de restaurantes poderia melhorar sua experiência mobile mostrando aos usuários a localização de seus restaurantes em sua área. As possibilidades são infinitas.

A W3C também propôs um rascunho para uma API de vibração. Nele o browser pode oferecer um feedbacl tátil ao usuário em forma de vibração. Isto, no entanto, ainda está engatinhando em campos mais específicos de aplicações Web and mobile games in the browser.

Outra API que tem sido altamente discutida é a network information API. A possibilidade de medir a largura de banda do usuário, e otimizar conforme o resultado, tem seduzido muitos desenvolvedores. Seriamos capazes de servir imagens com qualidade de alta definição para usuários com alta largura de banda e imagens de baixa qualidade aos usuários com baixa largura de banda. Com o atributo bandwith da network API, seria possível calcular a velocidade de download de um usuário em megabytes por segundo. O segundo atributo, metered, é um booleano que nos diz se o usuário tem uma conexão aferida (como um cartão pré-pago). Esses dois atributos são atualmente acessíveis via JavaScript.

Infelizmente, medir a conexão de um usuário é algo tecnicamente complicado, pois uma conexão poderia mudar de forma abrupta. O usuário poderia, por exemplo, entrar num túnel e perder sua conexão, ou sua velocidade poderia cair de repente. Sendo assim, a media query mágica que mede a largura de banda parece ser hipotética no momento. Yoav Weiis escreveu um belo artigo sobre os problemas criados por essa media query e sobre medição de largura de banda chamado “Bandwidth Media Queries? We Don’t Need ’Em!” (media queries de largura de banda? Não precisamos delas!”)

Muitas outras API’s lidam com recursos mobile. Se você estiver interessado em aprender mais, a Mozilla tem uma lista bem detalhada. A maioria ainda não está completamente disponível ou padronizada, e é destinada mais a aplicações web do que a sites responsivos. No entanto, é um ótimo panorama de como grandes e complexos sites mobile podem ser no futuro.

Repensando a Maneira Como Nós e o Usuário Lidamos com o Conteúdo

Do ponto de vista técnico, ainda existem muitos desafios ao lidar com o conteúdo em grande escala. O método mobile-first tem sido parte do processo de desenvolvimento e design já há algum tempo. Poderíamos, por exemplo, servir a dispositivos mobile o mínimo de dados necessários, e então usar JavaScript e AJAX para condicionalmente carregar mais conteúdo e imagens para desktop e tablets. No entanto, para isto, também teríamos que repensar como lidar com o conteúdo e ser capaz de priorizar uma forma de gerar um conteúdo suficientemente flexível e adaptável. Um bom exemplo disto é o mapa de solução responsiva descrito acima: Carregamos uma imagem para mobile, e melhoramos a experiência com um mapa real para desktops. Quanto mais responsivo o website, mais complexo será lidar com o conteúdo. Um código flexível pode nos ajudar a formatar um conteúdo adaptável.

Uma forma sugerida por alguns é criar frases responsivas e marcá-las com spans que tenham classes, e então exibi-los de acordo com o tamanho da tela. Aparar trechos das frases para dispositivos menores é possível com media querries. Você pode ver esta técnica no 37signals’ Signal vs. Noise blog e no artigo de Frankie Roberto “Responsive Text”. Mesmo que tal técnica pudesse ser usada para melhorar pequenas partes de um website, tais como um slogan do footer, aplicando isto a todos os textos de um site é difícil de imaginar.

Isto levanta uma questão no web design responsivo que se tornará mais e mais importante no futuro: a importância de meta dados e a estrutura semântica de conteúdo. Se quisermos ser capazes de reutilizar o conteúdo de outros websites automaticamente, eles deverão estar bem estruturados e preparados para isto. Novas tags HTML5 como article e section são um bom começo para ganhar algum significado semântico. O objetivo é pensar e estruturar o conteúdo de modo que um único item (por exemplo, um post em um blog), possa ser reutilizado e exibido em diferentes dispositivos, e em diferentes formatos.

O grande desafio será fazer com que os metadados sejam facilmente compreendidos a todas as pessoas que fazem parte da criação de conteúdo do website. Teremos que explicar a todos eles como os metadados podem ser utilizados para priorizar o conteúdo e programaticamente reunir o conteúdo, sendo uma plataforma independente. Um grande desafio será o de ajudá-los a pensar em blocos reutilizáveis, em vez de um grande pedaço de texto no qual eles copiam e colam conteúdo do Microsoft Word no seu sistema de gerenciamento de conteúdo WYSIWYG. Teremos que ajudá-los a entender que conteúdo e estrutura são coisas distintas e independentes, como quando os designers tiveram que entender que o conteúdo (HTML) e a apresentação (CSS) eram mantidos melhor separados.

Não podemos nos dar ao luxo de escrever um conteúdo que seja orientado a uma única plataforma. Quem sabe em qual dispositivo ele será publicado daqui a seis meses, ou um ano? Precisamos preparar nossos websites para o inesperado. Mas, para isto, precisamos de ferramentas melhores de publicação também. Karen McGrane deu uma palestra intitulada “Adapting Ourselves to Adaptive Content” (Nos Adaptando a um Conteúdo Adaptável), com alguns exemplos reais da indústria editorial. Ela fala sobre o processo de criação de conteúdo reutilizável e apresenta a ideia do COPE: create once and publish everywhere (Criar uma vez e publicar em todos os lugares). Precisamos construir CMS’s melhores, que possam utilizar e gerar metadados para priorizar o conteúdo. Precisamos explicar às pessoas como o sistema funciona e pensar em objetos de módulos de conteúdo reutilizáveis em vez de páginas WYSIWYG. Como McGrane diz:

“Você pode escrever três versões diferentes de título; você pode escrever duas versões diferentes de resumos e anexar diversas imagens para isto, com diferentes cortes e tamanhos, e você pode não ser a pessoa responsável em decidir qual imagem ou qual título será exibido em uma determinada plataforma. Essa decisão será tomada pelos metadados. Será feita pelas regras de negócios. […] Metadados é a nova direção de arte.”

Truncar o conteúdo para dispositivos menores não é uma estratégia de conteúdo “à prova do futuro”. Precisamos de CMS’s que ofereçam a estrutura necessária para criar esse conteúdo reutilizável. Precisamos de melhores workflows de publicação em CMS’s também. Interfaces desajeitadas assustam os usuários, e a maioria das pessoas que geram conteúdo não estão particularmente confortáveis com ferramentas complicadas. Temos que oferecer a essas pessoas ferramentas mais fáceis de entender e que lhe ajudem a publicar um conteúdo limpo e semântico, independente da apresentação.

Conclusão

Por mais longo que este artigo seja, ele só abrange o básico. Mas agora, a maioria dos leitores da Smashing Magazine entendem que o web design responsivo é muito mais que usar media queries, escolher breakpoints certos e dobrar o tamanho das imagens para celulares de alta densidade. Como você pode ver, o caminho é longo e ainda não chegamos lá. Há ainda muitas questões não resolvidas, e a solução responsiva perfeita ainda não existe.

Soluções técnicas podem ser descobertas no futuro usando alguma nova tecnologia apresentada neste artigo, com a ajuda da W3C, WHATWG e organizações como o Filament Group.

Mais importante, nós web designers e desenvolvedores podemos ajudar a encontrar soluções ainda melhores. Pessoas como Luke Wroblewski e Brad Frost, e todas as incríveis pessoas mencionadas neste artigo estão experimentando uma série de soluções e técnicas diferentes. Se serão bem ou mal sucedidas, a coisa mais importante é compartilhar o que nós – designers, desenvolvedores, estrategistas de conteúdo e membros da comunidade web – estamos fazendo para tentar resolver alguns dos desafios da comunidade do web design. Afinal, estamos todos no mesmo barco, tentando tornar a web um lugar melhor, não estamos?

Traduzido com autorização da Smashing Magazine.

Artigo original escrito por Stéphanie Walter.

Acesse o artigo original na Smashing Magazine – “The State Of Responsive Web Design” – 29 de maio de 2013.

Publicado no dia