CSS que prioriza dispositivos móveis: é hora de repensar?

A metodologia de design mobile-first é ótima: ela se concentra no que realmente importa para o usuário, é bem praticada e tem sido um padrão de design comum há anos. Portanto, desenvolver seu CSS primeiro para dispositivos móveis também deve ser ótimo… certo?

Bem, não necessariamente. O desenvolvimento clássico de CSS mobile-first é baseado no princípio de sobrescrever declarações de estilo: você inicia seu CSS com declarações de estilo padrão e sobrescreve e/ou adiciona novos estilos à medida que adiciona pontos de interrupção com min-width consultas de mídia para janelas de visualização maiores (para uma boa visão geral, consulte “O que é Mobile First CSS e por que ele é incrível?”). Mas todas essas exceções criam complexidade e ineficiência, o que, por sua vez, pode levar a um maior esforço de testes e a uma base de código mais difícil de manter. Admita: quantos de nós queremos isso de boa vontade?

Em seus próprios projetos, o CSS mobile-first ainda pode ser a melhor ferramenta para o trabalho, mas primeiro você precisa avaliar o quão apropriado ele é à luz do design visual e das interações do usuário em que você está trabalhando. Para ajudá-lo a começar, veja como abordarei os fatores que você precisa observar e discutirei algumas soluções alternativas se a prioridade para dispositivos móveis não parecer adequada ao seu projeto.

Vantagens do mobile-first

Algumas das coisas que você gosta no desenvolvimento CSS mobile-first – e por que tem sido a metodologia de desenvolvimento de fato por tanto tempo – fazem muito sentido:

Hierarquia de desenvolvimento. Uma coisa que você sem dúvida obtém com o mobile-first é uma boa hierarquia de desenvolvimento – você apenas se concentra na visualização mobile e começa a desenvolver.

Experimentado e testado. É uma metodologia testada e comprovada que funciona há anos por uma razão: ela resolve um problema muito bem.

Prioriza a visualização móvel. A visualização móvel é a mais simples e sem dúvida o mais importante, pois abrange todas as principais jornadas do usuárioe muitas vezes é responsável por um maior proporção de visitas de usuários (dependendo do projeto).

Impede o desenvolvimento centrado em desktop. Como o desenvolvimento é feito em computadores desktop, pode ser tentador focar inicialmente na visualização do desktop. Mas pensar em dispositivos móveis desde o início evita que fiquemos presos mais tarde; ninguém quer perder tempo adaptando um site centrado em desktop para funcionar em dispositivos móveis!

Desvantagens de priorizar os dispositivos móveis

Definir declarações de estilo e então substituí-las em pontos de interrupção mais altos pode levar a ramificações indesejáveis:

Mais complexidade. Quanto mais você avança na hierarquia de pontos de interrupção, mais código desnecessário você herda dos pontos de interrupção inferiores.

Maior especificidade CSS. Os estilos que foram revertidos para o valor padrão do navegador em uma declaração de nome de classe agora têm uma especificidade mais alta. Isso pode ser uma dor de cabeça em projetos grandes quando você deseja manter os seletores CSS o mais simples possível.

Requer mais testes de regressão. Alterações no CSS em uma visualização inferior (como adicionar um novo estilo) exigem que todos os pontos de interrupção superiores sejam testados em regressão.

O navegador não pode priorizar downloads de CSS. Em pontos de interrupção mais amplos, o celular clássico prioriza min-width consultas de mídia não aproveitam a capacidade do navegador de baixar arquivos CSS em ordem de prioridade.

O problema das substituições do valor da propriedade

Não há nada de inerentemente errado em substituir valores; CSS foi projetado para fazer exatamente isso. Ainda assim, herdar valores incorretos não ajuda e pode ser oneroso e ineficiente. Também pode levar a uma maior especificidade de estilo quando você precisa sobrescrever estilos para redefini-los de volta aos padrões, algo que pode causar problemas mais tarde, especialmente se você estiver usando uma combinação de CSS personalizado e classes utilitárias. Não poderemos usar uma classe utilitária para um estilo que foi redefinido com maior especificidade.

Pensando nisso, estou desenvolvendo CSS com foco muito mais nos valores padrão atualmente. Como não há uma ordem específica nem cadeias de valores específicos para acompanhar, isso me libera para desenvolver pontos de interrupção simultaneamente. Eu me concentro em encontrar estilos comuns e isolar as exceções específicas em intervalos fechados de media query (ou seja, qualquer intervalo com um max-width definir).

Essa abordagem abre algumas oportunidades, pois você pode olhar para cada ponto de interrupção como uma lousa em branco. Se o layout de um componente parecer que deveria ser baseado no Flexbox em todos os pontos de interrupção, tudo bem e pode ser codificado na folha de estilos padrão. Mas se parece que o Grid seria muito melhor para telas grandes e o Flexbox para dispositivos móveis, ambos podem ser feitos de forma totalmente independente quando o CSS é colocado em intervalos fechados de consulta de mídia. Além disso, desenvolver simultaneamente exige que você tenha um bom entendimento de qualquer componente em todos os pontos de interrupção antecipadamente. Isso pode ajudar a revelar problemas no design no início do processo de desenvolvimento. Não queremos ficar presos na toca do coelho construindo um componente complexo para dispositivos móveis e, em seguida, obter os designs para desktop e descobrir que eles são igualmente complexos e incompatíveis com o HTML que criamos para a visualização móvel!

Embora essa abordagem não seja adequada para todos, encorajo você a tentar. Existem muitas ferramentas para ajudar no desenvolvimento simultâneo, como Responsively App, Blisk e muitas outras.

Dito isto, não creio que a ordem em si seja particularmente relevante. Se você se sentir confortável em focar na visualização móvel, tiver um bom entendimento dos requisitos para outros pontos de interrupção e preferir trabalhar em um dispositivo por vez, siga a ordem de desenvolvimento clássica. O importante é identificar estilos e exceções comuns para que você possa colocá-los na folha de estilo relevante – uma espécie de processo manual de agitação de árvore! Pessoalmente, acho isso um pouco mais fácil ao trabalhar em um componente entre pontos de interrupção, mas isso não é de forma alguma um requisito.

Intervalos de consultas de mídia fechadas na prática

No CSS clássico para dispositivos móveis, sobrescrevemos os estilos, mas podemos evitar isso usando intervalos de consulta de mídia. Para ilustrar a diferença (estou usando SCSS por questões de brevidade), vamos supor que haja três designs visuais:

• menor que 768
• de 768 para abaixo de 1024
• 1024 e qualquer coisa maior

Tomemos um exemplo simples onde um elemento de nível de bloco tem um padrão padding de “20px”, que é substituído no tablet para “40px” e redefinido para “20px” no desktop.

.my-block {
  padding: 20px;
  @media (min-width: 768px) {
    padding: 40px;
  }
  @media (min-width: 1024px) {
    padding: 20px;
  }
}

.my-block {
  padding: 20px;
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

The subtle difference is that the mobile-first example sets the default padding to “20px” and then overwrites it at each breakpoint, setting it three times in total. In contrast, the second example sets the default padding to “20px” and only overrides it at the relevant breakpoint where it isn’t the default value (in this instance, tablet is the exception).

The goal is to: 

• Only set styles when needed. 
• Not set them with the expectation of overwriting them later on, again and again. 

To this end, closed media query ranges are our best friend. If we need to make a change to any given view, we make it in the CSS media query range that applies to the specific breakpoint. We’ll be much less likely to introduce unwanted alterations, and our regression testing only needs to focus on the breakpoint we have actually edited. 

Taking the above example, if we find that .my-block spacing on desktop is already accounted for by the margin at that breakpoint, and since we want to remove the padding altogether, we could do this by setting the mobile padding in a closed media query range.

.my-block {
  @media (max-width: 767.98px) {
    padding: 20px;
  }
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

O padrão do navegador padding para nosso bloco é “0”, então, em vez de adicionar uma consulta de mídia de desktop e usar unset ou “0” para o padding valor (que precisaríamos com mobile-first), podemos agrupar o mobile padding em uma consulta de mídia fechada (já que agora também é uma exceção), para que não seja detectada em pontos de interrupção mais amplos. No ponto de interrupção da área de trabalho, não precisaremos definir nenhum padding estilo, pois queremos o valor padrão do navegador.

Agrupamento versus separação do CSS

Antigamente, manter o número de solicitações no mínimo era muito importante devido ao limite de solicitações simultâneas do navegador (normalmente em torno de seis). Como consequência, o uso de sprites de imagem e agrupamento de CSS era a norma, com todo o CSS sendo baixado de uma só vez, como uma folha de estilo com prioridade mais alta.

Com HTTP/2 e HTTP/3 agora em cena, o número de solicitações não é mais o grande problema que costumava ser. Isso nos permite separar o CSS em vários arquivos por consulta de mídia. O claro benefício disso é que o navegador agora pode solicitar o CSS de que precisa atualmente com uma prioridade mais alta do que o CSS que não precisa. Isso tem melhor desempenho e pode reduzir o tempo geral de bloqueio da renderização da página.

Qual versão HTTP você está usando?

Para determinar qual versão do HTTP você está usando, acesse seu site e abra as ferramentas de desenvolvimento do seu navegador. A seguir, selecione o Rede guia e certifique-se de que Protocolo coluna está visível. Se “h2” estiver listado em Protocolosignifica que HTTP/2 está sendo usado.

Nota: para visualizar o Protocolo nas ferramentas de desenvolvimento do seu navegador, acesse o Rede aba, recarregue sua página, clique com o botão direito em qualquer cabeçalho de coluna (por exemplo, Nome) e verifique o Protocolo coluna.

Além disso, se o seu site ainda usa HTTP/1... POR QUÊ?!! O que você está esperando? Há excelente suporte ao usuário para HTTP/2.

Dividindo o CSS

Separar o CSS em arquivos individuais é uma tarefa que vale a pena. Vinculando os arquivos CSS separados usando o relevante media O atributo permite que o navegador identifique quais arquivos são necessários imediatamente (porque bloqueiam a renderização) e quais podem ser adiados. Com base nisso, ele atribui a cada arquivo uma prioridade apropriada.

No exemplo a seguir de um site visitado em um ponto de interrupção móvel, podemos ver que o CSS móvel e padrão são carregados com prioridade “Mais alta”, pois são atualmente necessários para renderizar a página. Os arquivos CSS restantes (impressão, tablet e desktop) ainda são baixados caso sejam necessários posteriormente, mas com prioridade “Mais baixa”.

Com CSS empacotadoo navegador terá que baixar o arquivo CSS e analisá-lo antes que a renderização possa começar.
Embora, como observado, com o CSS separado em arquivos diferentes vinculados e marcados com o relevante media atributo, o navegador pode priorizar os arquivos de que precisa atualmente. O uso de intervalos de consulta de mídia fechados permite que o navegador faça isso em todas as larguras, em oposição ao clássico mobile-first min-width consultas, onde o navegador de desktop teria que baixar todo o CSS com prioridade mais alta. Não podemos presumir que os usuários de desktop sempre tenham uma conexão rápida. Por exemplo, em muitas zonas rurais, as velocidades de ligação à Internet ainda são lentas.

As consultas de mídia e o número de arquivos CSS separados variam de projeto para projeto com base nos requisitos do projeto, mas podem ser semelhantes ao exemplo abaixo.

Dependendo da estratégia de implantação do projeto, uma alteração em um arquivo (mobile.csspor exemplo) exigiria apenas que a equipe de controle de qualidade fizesse testes de regressão em dispositivos nesse intervalo específico de consulta de mídia. Compare isso com a perspectiva de implantar o pacote único site.css arquivo, uma abordagem que normalmente acionaria um teste de regressão completo.

Seguindo em frente

A adoção do CSS mobile-first foi um marco realmente importante no desenvolvimento web; ajudou os desenvolvedores front-end a se concentrarem em aplicativos da web para dispositivos móveis, em vez de desenvolver sites em desktops e depois tentar adaptá-los para funcionar em outros dispositivos.

Não creio que alguém queira voltar a esse modelo de desenvolvimento, mas é importante não perdermos de vista o problema que ele destacou: que as coisas podem facilmente ficar complicadas e menos eficientes se priorizarmos um dispositivo específico – qualquer dispositivo – em detrimento de outros. Por esse motivo, focar no CSS por si só, sempre atento ao que é a configuração padrão e o que é exceção, parece o próximo passo natural. Comecei a notar pequenas simplificações no meu próprio CSS, assim como no de outros desenvolvedores, e que o trabalho de teste e manutenção também está um pouco mais simplificado e produtivo.

Em geral, simplificar a criação de regras CSS sempre que possível é, em última análise, uma abordagem mais limpa do que andar em círculos de substituições. Mas seja qual for a metodologia que você escolher, ela precisa se adequar ao projeto. A prioridade móvel pode – ou não – ser a melhor escolha para o que está envolvido, mas primeiro você precisa entender solidamente as compensações em que está entrando.