O Cenário do Web Design Responsivo

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

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 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:

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:

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:

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:

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:

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):

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:

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 viewport – vw, 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 1_vw_ é 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:

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”.

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:

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.

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:

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.

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.

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.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *