Qual a diferença?

No meio do boom de possibilidades e novos recursos trazidos pelo CSS3 temos as Media Queries. E do meu ponto de vista esse novo recurso vem numa velha roupagem, trazendo junto algo que parece persistir no mundo do desenvolvimento para web.

O que são as media queries?

No CSS 2, havia a possibilidade de definir folhas de estilo diferentes para meios diferentes. O exemplo clássico é usar duas folhas distintas, uma para leitura na tela com fontes sans-serif, e uma para impressão com fontes serif, melhorando a legibilidade do conteúdo segundo onde ele for usado. O CSS 2 define alguns tipos de media, a saber:

• all
• braille
• embossed
• tv
• tty
• handheld
• screen
• print
• projection
• speech/aural

Com as media queries do CSS3 essas possibilidades foram estendidas para propriedades dos meios. Por exemplo, largura ou altura da tela (ou da folha), quantidade de cores, resolução, etc. Isso é media query.

Por que o estardalhaço com isso?

Resumidamente: por causa da expansão da internet 3G e nos dispositivos móveis capazes de navegar na internet.

Com as medias queries é possível detectar larguras, alturas, orientação da tela, etc, e com isso formatar o conteúdo de acordo, deixando um aspecto muito mais agradável e legível para as páginas. Seja num smarthphone, seja numa TV full HD de 30+ polegadas, seja numa folha A4, seja num outdoor.

Assim, agora as folhas de estilo poderão se adaptar aos dispositivos e meios onde serão mostradas, tudo sem nenhuma linha de script ou programação adicional, apenas com marcação HTML/XML e CSS.

Se essas media queries são um recurso tão legal, qual o problema?

O problema disso é a carga de trabalho para criação e manutenção, além da postura de alguns sites e entusiastas que proclamam esta solução como definitiva. Rotular algo como definitivo é um tiro no pé, e isso é duplamente verdade no mundo da tecnologia. Nada é definitivo porque ninguém pode prever o mercado dentro de 5 ou 10 anos.

Mas falando sobre o lado ruim do operacional, da hora do vamos ver, o problema é que as media queries podem adicionar trabalho de forma desnecessária e ineficiente. Explico. Ou você vai aumentar muito o tamanho dos arquivos CSS, ou vai criar algumas dezenas.

Como se fazia antes?

É engraçado notar que sites para dispositivos móveis existem a mais de 10 anos. Claro que a quantidade de sites aumentou muito com o aumento da participação do mercado na internet destes dispositivos, e com a evolução das tecnologias. O que antes era raro, agora é tendência. Antes era WAP, agora é HTML e CSS mesmo, só que mais enxuto.

Como mencionei antes, o CSS 2 já previa o uso de arquivos CSS diferentes, baseados em mídias e dispositivos diferentes. Uma das abordagens adotadas era - e ainda é - deixar um redirecionamento para um domínio específico ou uma folha de estilo específica quando acontecer do dispositivo se enquadrar na media handheld.

Para se ter uma idéia, o Yahoo!, o Youtube, o A List Apart, o McDonald's e o Walmart adotam esta solução ainda hoje.

Eles tem as tags

<!-- este faz o redirecionamento para um domínio separado -->
<link rel="alternate" href="http://m.domain.com" media="handheld" />
ou
<!-- este aponta para uma folha de estilo separada -->
<link rel="stylesheet" type="text/css" href="mobileStyle.css" media="handheld" />

Abordagens alternativas e seus pontos positivos e negativos

Estas claro que não são as únicas soluções, mas são as mais difundidas atualmente. E com as Media Queries do CSS3, surge uma leva de críticos teóricos a este modelo. Uma das críticas é que o conteúdo fica espalhado. Vários domínios, várias folhas de estilo... É ruim para o controle, etc...

Frente ao mercado atual de tecnologias disponíveis e de dispositivos/suporte, temos algumas soluções que fazem sentido e outras nem tanto.

A primeira seria usar apenas o atributo media para importar um arquivo CSS para handhelds. É uma solução muito difundida, talvez a mais difundida. É eficiente, testada, funcional. O problema é que as capacidades variam de acordo com os dispositivos móveis. Largura, altura, resolução, cores e orientação são as mais significativas em termos de design (por isso as media queries foram criadas).

Outra solução é adotar um subdomínio diferente. Esta solução também é bastante popular, mas recebe duras críticas. O motivo é simples. Se para cada faixa de resolução for criado um novo subdomínio e uma nova folha de estilo, isso pode gerar um monstro dentro de alguns anos. Bem, isso é um ponto de vista dos teóricos. Na prática, esta abordagem traz alguns outros benefícios, como o lado do servidor, que pode processar e gerar respostas mais leves (usar outras imagens, remover flash, javascript, anúncios...), o que é muito interessante para quem usa dispositivos móveis, afinal é consumo de banda menor, download e processamento mais rápidos.

Usar media queries para importar diferentes estilos. A idéia queridinha do momento. Mas ninguém pensa (ou apenas ignora, ou dá importância menor) no fato de que neste caso, várias folhas de estilo são necessárias, o que representa um problema tão grande para a manutenção quanto ter um domínio separado. HTML com cabeçalho maior para TODOS os casos, e uma trabalheira muito grande para os desenvolvedores e designers.

Usar media queries dentro do arquivo CSS para criar regras específicas para determinados dispositivos. Parece interessante, mas o arquivo ficaria simplesmente gigante, com uma variação de regras repetidas várias vezes. Continua uma solução estranha, com um arquivo de CSS ruim de dar manutenção, e extremamente grande pra baixar e lento pra processar.

Usa ou não usar?

Faladas as soluções (ou futuras tendências de), hora de pesar cada coisa, e de escolher uma abordagem. Claro que isto irá variar de caso para caso, mas no geral, as minhas consideração estão abaixo.

Usar um (ou mais, caso necessário) domínio alternativo, e fazer uso de redirecionamentos com a tag link. Um para dispositivos móveis, um para desktops normais, e talvez um para monitores grandes e TVs. Eu sou a favor do uso de domínios alternativos principalmente pelo fato de poder valer-se de programação server-side e fornecer conteúdos diferentes, economizando banda e outros recursos dos clientes.

Para cada domínio, um CSS diferente. Apesar de parecer mais complicado, é mais leve, depois de um arquivo CSS pronto, basta duplicar o conteúdo e adicionar/subtrair algumas regras.

Ah sim, nestes arquivos CSS diferentes sim usar as media queries. Continua aumentando o número de regras, mas é muito mais conveniente e leve fazer desta forma, ao invés de servir um único arquivo CSS grande.

Conclusões

Media queries são um novo recurso muito interessante e poderoso sem sombra de dúvidas. Mas do meu ponto de vista ele não resolve perfeitamente a condição de ter que filtrar de alguma forma informações do cliente. Aliás, esta realidade de exibir páginas diferentes (layouts diferentes) é algo que depende do mercado de monitores, dispositivos, browsers, e não tem como servir um conteúdo único, apenas um arquivo html e um arquivo CSS, que enquadre todas as soluções de forma otimizada. No passado e no presente bibliotecas javascript serviram a este propósito, agora temos como fazer isso em CSS.

Antes não haviam padrões W3C para realizar este tipo de tarefa, e sempre que o assunto pende para este lado, surgem defensores fanáticos ressaltando todos os pontos ruins de uma solução em javascript (não é standard, e não serve para todos os dispositivos). Apesar de ter um fundo de verdade nesta afirmação, na prática 99.8% do fluxo na internet vai para navegadores que contam com esta tecnologia, daí o porque deste fanatismo ser exacerbado em meu ponto de vista (que sou um standardista).

Agora temos as media queries, um jeito W3C de fazer essa diferenciação para dispositivos diferentes. No entanto, a necessidade de ter marcações ou regras diferentes para dispositivos diferentes continua existindo, assim como o trabalho de criar regras diferentes.

O fiel da balança, junto desta necessidade de servir conteúdos/formatos diferentes, é o usuário. Se por um lado temos como servir estes conteúdos, o forma de serví-los pode não ser otimizada. Por que ter um aumento de 150% no tamanho do arquivo CSS, sendo que pode-se criar um domínio separado, e servir arquivos menores (inclusive o output HTML menor)? O que é melhor para os usuários? E para os desenvolvedores? Será que criar mais de uma folha de estilo é tão complicado assim, ou seria melhor para fazer manutenção?

Sou a favor do uso das media queries, mas não como solução única, absoluta e ótima. Cada caso deve ser analisado, e outros fatores devem sim ser levados em consideração, principalmente no que diz respeito aos usuários.
----------- keepReading