O grande erro de consulta de mídia CSS

Você já se sentiu estranho quando todos ao seu redor estão fazendo algo que você normalmente acha errado [ou não é o ideal, no mínimo], mas de alguma forma ninguém parece querer dizer nada por um motivo ou outro? É uma sensação muito estranha ver todo mundo fazendo sua melhor impressão de um observador infeliz. Isso meio que me lembra aquela velha fábula, “A roupa nova do imperador”.

Eu meio que sempre me senti assim sobre consultas de mídia CSS. Por que todo mundo está aceitando tanto uma tecnologia que simplesmente não parece estar fazendo o trabalho? Por que nós, como comunidade, não nos reunimos e melhoramos de uma forma real e significativa? Por que não inventamos algo melhor?

Hoje, as consultas de mídia CSS são a base funcional do web design responsivo. Mas, ele nunca foi projetado para o que todo mundo está usando hoje, e a prova está na prática. Eu ainda frequentemente tropeço em sites ao usar um tablet que a princípio parece bem projetado, mas acontece de parecer e sentir-se completamente instável quando você os coloca em seus ritmos.

Há algo fundamentalmente errado com essa abordagem de web design responsivo que ainda não abordamos adequadamente, e eu gostaria de ser uma das poucas vozes a chamar o imperador por sua nudez neste. Felizmente, porém, hoje em dia, estou feliz que há quase zero chance de ser queimado na fogueira por ter esse ponto de vista alternativo.

O que há de errado com consultas de mídia CSS

As consultas de mídia CSS foram projetadas para algo, mas essa coisa não é design responsivo da web. Com base na minha experiência, aqui estão sete (7) grandes problemas que encontrei ao tentar usá-los para trabalhar com sites:

1. Não intuitivo:

“As consultas de mídia CSS são intuitivas”, disse nenhum web designer. A maneira como você define uma consulta de mídia é bastante direta, mas nem sempre é exatamente claro como as coisas serão executadas em navegadores reais, em dispositivos reais e em uma infinidade de cenários.

 @media somente tela e (min-width: 320px) e (max-width: 480px) {
    /** Regras CSS aqui **/
}

O código acima se aplica à janela de visualização quando ela estiver entre 320 e 480 pixels. No entanto, não é exatamente definitivo [ou intuitivo] quando você deseja fazer algo mais específico, como aplicar uma regra de estilo quando o dispositivo é um tablet em modo paisagem. Não é impossível [meio que] configurar uma consulta de mídia para fazer isso, mas definitivamente não é intuitivo – ou definitivo.

2. Condicionalidade limitada:

As consultas de mídia CSS são dinâmicas e permitem que você defina instruções condicionais em seu CSS. Por exemplo, se a viewport estiver entre isso e aquilo, faça o outro. No entanto, você está limitado principalmente a considerações de viewport e há muitos outros cenários condicionais que fariam sentido no design da Web moderno.

Digamos que você esteja criando um aplicativo da web progressivo. Há momentos em que seria útil estilizar determinados elementos da interface do usuário de maneira diferente com base no sistema operacional. Por exemplo, é costume ter a barra de guias na parte inferior para dispositivos iOS, enquanto para Android ocorre o inverso. Então, como exatamente você faria isso funcionar com consultas de mídia CSS?

Você não pode, porque as consultas de mídia CSS não são criadas com nenhum recurso que permita. Além disso, existem inúmeras outras personalizações que você pode precisar fazer via CSS, mas consultas de mídia não são uma opção quando você precisa de vários graus de condicionalidade simples a avançada.

3. Não extensível nativamente:

As consultas de mídia CSS são funcionalidades incorporadas ao navegador. Isso significa que não é extensível nativamente. Em outras palavras, você não pode adicionar recursos extras e aprimorados às consultas de mídia CSS nativamente por meio da interface CSS.

Mesmo que novos recursos de consulta de mídia CSS sejam aprovados pelo [longo sofrimento] processo de padrões da web, ainda leva tempo até que esses recursos se tornem utilizáveis ​​devido à onipresença. Além disso, nem todos os recursos adicionados podem ser úteis para você, então você precisa descobrir outra maneira de resolver seu desafio específico se não conseguir o que deseja.

Claro, existe uma maneira de estender CSS, mas você precisa conhecer JavaScript muito, muito bem, e não é um processo prático para a maioria dos web designers.

4. Não adequado para retrofit:

Alguns podem achar isso difícil de acreditar, mas antes que os dispositivos móveis aparecessem, havia muitos sites por aí, e nenhum deles era compatível com dispositivos móveis. Como resultado, esses sites da era desktop precisavam ser atualizados.

Infelizmente, consultas de mídia CSS não são uma opção muito boa para essa tarefa. Como esses sites foram criados antes que os dispositivos móveis fossem relevantes, muitos deles têm elementos de design que não se prestam ao design responsivo, como barras laterais, layouts baseados em tabelas, conteúdo com guias etc. Além disso, uma proporção considerável desses sites é construído em um sistema de gerenciamento de conteúdo (CMS) como WordPress, Drupal, Magento, etc., e integrar consultas de mídia CSS [front-end] efetivamente a partir do back-end é extremamente difícil ou quase impossível de coordenar.

Eu tive que adaptar sites com Magento Enterprise, WordPress e um que usava um CMS personalizado baseado em Coldfusion, e todos os projetos teriam sido absolutamente impossíveis usando consultas de mídia CSS [que é o que todos os meus clientes tentaram antes de usar nossa alternativa aproximação].

5. Não é eficiente no código:

O uso de consultas de mídia CSS para tornar uma página da Web responsiva requer a multiplicação de código em uma escala significativa. Devido à maneira como essas diretivas funcionam [com seus pontos de interrupção], você precisa definir regras de estilo individuais em cada bloco de consulta de mídia.

 seção {largura: 960px;}

/* Retrato */
@media only screen e (min-device-width: 320px) e (max-device-width: 480px) e (-webkit-min-device-pixel-ratio: 2) e (orientation: portrait) {
    seção {largura: 100%}
}
/* Paisagem */
@media only screen e (min-device-width: 320px) e (max-device-width: 480px) e (-webkit-min-device-pixel-ratio: 2) e (orientação: paisagem) {
    seção {largura: 100%;}
}

Ao escrever o código acima, minha intenção original era tornar os elementos <section> da minha página fluidos [largura de 100%] em todos os dispositivos móveis. No entanto, como não tenho capacidade nativa de detecção de dispositivos, preciso comprometer e definir uma regra de estilo em cada bloco de consulta de mídia CSS orientado a dispositivos móveis para garantir que a nova propriedade seja aplicada em todos os cenários relevantes.

Isso significa que a eficiência funcional da cascata de folhas de estilo e os bons princípios de desenvolvimento do Do-not-Repeat-Yourself , precisam ficar em segundo plano.

6. Aumenta a complexidade do fluxo de trabalho:

As consultas de mídia CSS lidam apenas com um aspecto muito específico do design da Web responsivo que é quase inteiramente focado no redimensionamento do layout. Portanto, para fazer qualquer coisa além disso, você precisa confiar no JavaScript para compensar a diferença. Isso introduz requisitos de aprendizado adicionais para código e ferramentas.

Além disso, a maneira não definitiva com que [consultas de mídia] lida com pontos de interrupção significa que você precisa gastar mais tempo [e dinheiro] testando suas páginas da Web em vários dispositivos virtuais e/ou físicos para garantir que as coisas funcionem da maneira que você pretendia originalmente . E você precisa testar tudo novamente quando fizer alterações significativas em seu layout.

Pela ação simples e intencional de usar consultas de mídia CSS, você aumenta significativamente o número de etapas necessárias para criar uma página da Web moderna.

7. Piora o desempenho:

Devido à maneira como as consultas de mídia CSS funcionam, você acabará precisando de muito mais código CSS do que de outra forma para tornar seu site responsivo / compatível com dispositivos móveis. De acordo com dados do HTTPArchive.org, os tamanhos dos arquivos CSS aumentaram 114% nos últimos cinco anos. O aumento nos tamanhos dos arquivos HTML atingiu um pico de cerca de 53% no mesmo período.

Essa situação peculiar tem implicações de desempenho para o seu site, pois é provável que ele fique mais lento após a implementação de consultas de mídia CSS [em um contexto de web design responsivo] do que nunca, especialmente para dispositivos móveis usando redes de banda larga móvel abaixo do ideal.

E, além da questão do aumento do tamanho dos arquivos, não há nenhum mecanismo interno nas consultas de mídia CSS para realmente melhorar o desempenho de sua página da web. Para isso, você terá que aproveitar as técnicas avançadas de JavaScript para habilitar esses aprimoramentos.

Por que ainda estamos usando isso?

Se eu perguntasse a você qual porcentagem de sites estava usando consultas de mídia CSS, qual seria sua resposta? Com todo o estresse que os web designers tiveram que suportar ao longo dos anos, você pensaria que provavelmente já teríamos superado a queda da adoção, mas você estaria muito errado.

A porcentagem de sites que usam consultas de mídia CSS em toda a web é de cerca de 0,2%. Compare isso com a porcentagem de sites usando jQuery em 18%. O que isso significa é que você tem 90 vezes mais chances de encontrar um site que é alimentado por jQuery do que um site responsivo [sem incluir aqueles que são ambos].

Por que um kit de ferramentas baseado em uma tecnologia central [JavaScript] que certas pessoas parecem pensar que é complicado e supérfluo estaria tão à frente de um que é aparentemente menos complexo [CSS] e destinado a resolver um problema indiscutivelmente mais importante [mobile-friendly] ? Obviamente, há algo seriamente errado aqui que está dificultando a adoção, e isso precisa ser resolvido.

As consultas de mídia CSS chegaram aos navegadores da Web para lidar com um desafio específico, mas foram elaboradas para carregar todo o peso do design da Web responsivo em seus ombros. É como praticar para um recital de flauta da 3ª série, apenas para ser magicamente transportado para o Royal Albert Hall para renderizar um solo de trombone do Messias de Handel; Não é justo!

Com todos os desafios do web design moderno, é extremamente surpreendente que ainda estejamos nesse negócio de media query. Ele não vai longe o suficiente para lidar com alguns importantes problemas legados, além de alguns novos em novos campos, como o design progressivo de aplicativos da web. Como tal, acho que é hora de pensarmos em uma alternativa. Mas, o que seria isso exatamente?

Qual é a solução?

A solução para tudo isso é realmente muito simples: JavaScript. Agora, antes de pegar aquele forcado, me dê uma chance de explicar.

JavaScript é o único componente da trindade HTML5 onde extensibilidade não é uma palavra suja. Você não pode estender a marcação HTML usando mais HTML e com certeza não pode estender CSS nativamente com CSS. No entanto, você pode estender o JavaScript nativamente usando JavaScript e pode até fazer o mesmo para CSS.

A manipulação de CSS com JavaScript é amplamente discutida no Currículo de Padrões da Web do W3C. A interface DOM document.stylesheets nos permite acessar as folhas de estilo aplicadas a uma página da web, incluindo todas as folhas de estilo externas referenciadas usando a tag <link> do HTML. Não é uma coisa fácil de fazer, mas é possível.

Portanto, devo expandir a resposta inicial: não é simplesmente JavaScript, é CSS assistido por JavaScript . JavaScript é uma plataforma incrível com funcionalidades como você não acreditaria, mas CSS é onde a maioria dos web designers trabalham. Se pudéssemos de alguma forma criar algum tipo de ponte funcional entre esses dois, onde um web designer pudesse escrever um conjunto de regras CSS para alavancar a funcionalidade JavaScript, isso seria um divisor de águas para o web design.

Mostre-me algum código

Nos últimos dois anos, tenho trabalhado em um novo kit de ferramentas CSS assistido por JavaScript chamado rKit. A ideia toda era construir uma ferramenta amigável ao designer para não apenas substituir consultas de mídia CSS por web design responsivo, mas para abordar alguns dos desafios conhecidos [e desconhecidos] que os web designers/desenvolvedores enfrentam ao construir sites e aplicativos web modernos.

Há muito no conceito, mas aqui está um pequeno trecho de código CSS para explicar:

 #my-element[rk="if @viewport.width entre 320 e 480"]{background-color: #0000ff;}

Com o rKit, as regras CSS parecem seletores de valor de atributo modificados. Você pode então definir uma expressão dentro da seção de valor. A sintaxe dessa expressão foi projetada para ser simples e intuitiva.

Nota : rk é um identificador de atributo constante.

O código acima é funcionalmente equivalente à consulta de mídia CSS abaixo:

 @media only screen e (min-device-width: 320px) e (max-device-width: 480px) {
    #meu-elemento {cor de fundo:#0000ff;}
}

No entanto, há muito mais que você pode fazer com o rKit. Aqui está outro exemplo rápido:

 #my-element[rk="if @self.width entre 320 e 480"]{background-color: #00ff00;}

Simplesmente alterando a referência de entidade de @viewport para @self , basicamente configuramos o que é comumente chamado de consulta de elemento. Então, o que acontece agora é que quando a largura de #my-element estiver entre 320 e 480 pixels, a declaração dada [ background-color: #00ff00 ] será aplicada.

Você também pode usar classes em vez de declarações puras:

 #my-element[rk="if @self.width entre 320 e 480 then addClass(c_mobile_320)"]{}
.c_mobile_320 {cor de fundo: #00ff00;}

Esta é apenas a ponta do iceberg embora. Com o rKit, você pode fazer coisas incríveis, como gerenciamento de eventos, observação de mutações, consultas de quantidade, roteamento, vinculação de dados [até 7 vias] e uma série de outras coisas legais, tudo usando código CSS puro e sem escrever uma única linha de JavaScript.

O rKit será gratuito e de código aberto quando for lançado. E também terá um pacote de desempenho especial que você pode instalar de uma maneira que garanta zero bloqueio de renderização, para que a página da Web seja carregada como um foguete nos trilhos.

Demorou um pouco para montar isso, mas estará aqui em breve [definitivamente antes de Godot], e estou realmente interessado em ver o que web designers [e desenvolvedores] são capazes de fazer com isso.

Conclusão

Espero que você não saia deste post pensando que estou atacando consultas de mídia CSS só porque. Eu não estou. Isso seria como bater em um tomate por terminar em uma salada de frutas. Como eu disse anteriormente, as consultas de mídia CSS nunca foram projetadas para web design responsivo. Foi cooptado por conveniência, e todos cometemos o erro de tentar usá-lo para resolver todos os problemas.

Infelizmente, nós, como comunidade da web, nunca conseguimos corrigir esse erro inicial, melhorando-o de maneira significativa ou apresentando uma alternativa melhor. Mas, infelizmente, os shows devem continuar, os sites devem ser construídos e o progresso deve prevalecer. É hora de mudar.

rKit é apenas uma opção e uma resposta. Não é o primeiro e com certeza não será o último. Mas, no mínimo, é um passo certo na direção certa. Uma oportunidade de corrigir alguns problemas do passado e, em seguida, iterar para corrigi-los no agora e no futuro. Seria interessante ver como isso se compara ao status quo.

Tudo cobrado, cometer um erro não é um fim em si mesmo; deve ser uma experiência de aprendizagem. Com alguma sorte, aprenderemos a usar a ferramenta certa para o trabalho certo da próxima vez. Quero dizer, só porque você pode andar de bicicleta em uma estrada pavimentada não significa que você deva levar uma para Nurburgring. Traga um Porsche!