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. Então, desenvolver seu CSS mobile-first 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-widthconsultas de mídia para janelas de visualização maiores (para uma boa visão geral, consulte “ O que é o 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 teste e a uma base de código mais difícil de manter. Admita – quantos de nós querem isso de bom grado?
Em seus próprios projetos, o CSS mobile-first pode ainda 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 abordar os fatores que você precisa observar e discutirei algumas soluções alternativas se o mobile-first não parecer adequado ao seu projeto.
Vantagens do mobile-first
Algumas das coisas para gostar do desenvolvimento de 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 do mobile-first é uma boa hierarquia de desenvolvimento – você apenas se concentra na visualização móvel e começa o desenvolvimento.
Experimentado e testado. É uma metodologia testada e comprovada que funciona há anos por um motivo: resolve um problema muito bem.
Prioriza a visualização móvel . A visualização móvel é a mais simples e provavelmente a mais importante, pois abrange todas as principais jornadas do usuário e geralmente representa uma proporção maior de visitas do usuário (dependendo do projeto).
Impede o desenvolvimento centrado em desktop. Como o desenvolvimento é feito usando computadores desktop, pode ser tentador focar inicialmente na visualização desktop. Mas pensar em dispositivos móveis desde o início evita que fiquemos presos mais tarde; ninguém quer gastar seu tempo adaptando um site centrado em desktop para funcionar em dispositivos móveis!
Desvantagens do mobile-first
Definir declarações de estilo e substituí-las em pontos de interrupção mais altos pode levar a ramificações indesejáveis:
Mais complexidade. Quanto mais alto na hierarquia de pontos de interrupção você for, mais código desnecessário você herdará de 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 mais altos sejam testados por regressão.
O navegador não pode priorizar downloads de CSS. Em pontos de interrupção mais amplos, as consultas de mídia mobile-first clássicas min-widthnão aproveitam a capacidade do navegador de baixar arquivos CSS em ordem de prioridade.
O problema das substituições de valor de propriedade
Não há nada inerentemente errado em sobrescrever valores; CSS foi projetado para fazer exatamente isso. Ainda assim, herdar valores incorretos é inútil e pode ser pesado e ineficiente. Também pode levar a uma maior especificidade de estilo quando você precisa sobrescrever estilos para redefini-los de volta aos seus padrões, algo que pode causar problemas mais tarde, especialmente se você estiver usando uma combinação de CSS sob medida e classes de utilitários. Não poderemos usar uma classe utilitária para um estilo que foi redefinido com uma especificidade mais alta.
Com isso em mente, estou desenvolvendo CSS com foco nos valores padrão muito mais nos dias de hoje. Como não há uma ordem específica e nenhuma cadeia de valores específicos para acompanhar, isso me libera para desenvolver pontos de interrupção simultaneamente . Concentro-me em encontrar estilos comuns e isolar as exceções específicas em intervalos de consulta de mídia fechados (ou seja, qualquer intervalo com um max-widthconjunto).
Essa abordagem abre algumas oportunidades, pois você pode ver cada ponto de interrupção como uma lousa limpa. Se o layout de um componente parece ser baseado no Flexbox em todos os pontos de interrupção, tudo bem e pode ser codificado na folha de estilo padrão. Mas se parecer 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 de consulta de mídia fechados. Além disso, desenvolver simultaneamente requer que você tenha um bom entendimento de qualquer componente em todos os pontos de interrupção iniciais. Isso pode ajudar a trazer à tona problemas no design no início do processo de desenvolvimento. Não queremos ficar presos em uma toca de coelho criando 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 experimentá-la. Existem muitas ferramentas disponíveis para ajudar no desenvolvimento simultâneo, como Responsively App , Blisk e muitas outras.
Dito isto, não sinto que o pedido em si seja particularmente relevante. Se você se sente confortável em focar na visualização móvel, tem um bom entendimento dos requisitos para outros pontos de interrupção e prefere trabalhar em um dispositivo por vez, então continue com 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 sacudir a árvore! Pessoalmente, acho isso um pouco mais fácil ao trabalhar em um componente em pontos de interrupção, mas isso não é um requisito.
Intervalos de consulta de mídia fechada na prática
No CSS mobile-first clássico, sobrescrevemos os estilos, mas podemos evitar isso usando intervalos de consulta de mídia. Para ilustrar a diferença (estou usando SCSS para abreviar), vamos supor que existam três designs visuais:
- menor que 768
- de 768 para abaixo de 1024
- 1024 e qualquer coisa maior
Veja um exemplo simples em que um elemento de nível de bloco tem um padrão paddingde “20px”, que é substituído no tablet para ser “40px” e definido como “20px” na área de trabalho.
Clássico min-widthem primeiro lugar para dispositivos móveis.my-block { padding: 20px; @media (min-width: 768px) { padding: 40px; } @media (min-width: 1024px) { padding: 20px; } } | Intervalo de consulta de mídia fechada.my-block { padding: 20px; @media (min-width: 768px) and (max-width: 1023.98px) { padding: 40px; } } |
A diferença sutil é que o exemplo mobile-first define o padrão paddingcomo “20px” e o substitui em cada ponto de interrupção, configurando-o três vezes no total. Por outro lado, o segundo exemplo define o padrão paddingcomo “20px” e o substitui apenas no ponto de interrupção relevante, onde não é o valor padrão (nesse caso, o tablet é a exceção).
O objetivo é:
- Defina estilos apenas quando necessário.
- Não defini-los com a expectativa de sobrescrevê-los mais tarde, de novo e de novo.
Para isso, os intervalos de consulta de mídia fechados são nossos melhores amigos. Se precisarmos fazer uma alteração em qualquer visualização, fazemos isso no intervalo de consulta de mídia CSS que se aplica ao ponto de interrupção específico. Teremos muito menos probabilidade de introduzir alterações indesejadas, e nosso teste de regressão só precisa se concentrar no ponto de interrupção que realmente editamos.
Tomando o exemplo acima, se descobrirmos que o .my-blockespaçamento na área de trabalho já é contabilizado pela margem nesse ponto de interrupção e, como queremos remover o preenchimento completamente, podemos fazer isso definindo o celular paddingem um intervalo de consulta de mídia fechado.
.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 paddingpara nosso bloco é “0”, então, em vez de adicionar uma consulta de mídia de desktop e usar unsetou “0” para o paddingvalor (que precisaríamos com mobile-first), podemos envolver o celular paddingem uma consulta de mídia fechada ( já que agora também é uma exceção) para que não seja pego em pontos de interrupção mais amplos. No ponto de interrupção da área de trabalho, não precisaremos definir nenhum paddingestilo, pois queremos o valor padrão do navegador.
Agrupar versus separar o 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 (geralmente em torno de seis). Como consequência, o uso de sprites de imagem e empacotamento de CSS era a norma, com todo o CSS sendo baixado de uma só vez, como uma folha de estilo com maior prioridade.
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 benefício claro disso é que o navegador agora pode solicitar o CSS de que precisa no momento com uma prioridade mais alta do que o CSS que não precisa. Isso é mais eficiente e pode reduzir o tempo total 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. Em seguida, selecione a guia Rede e certifique-se de que a coluna Protocolo esteja visível. Se “h2” estiver listado em Protocol , significa que o HTTP/2 está sendo usado.
Observação: para visualizar o Protocolo nas ferramentas de desenvolvimento do seu navegador, vá para a guia Rede , recarregue sua página, clique com o botão direito do mouse em qualquer cabeçalho de coluna (por exemplo, Nome ) e verifique a coluna Protocolo .
Além disso, se o seu site ainda estiver usando HTTP/1… POR QUÊ?!! O que você está esperando? Há um excelente suporte ao usuário para HTTP/2 .
Dividindo o CSS
Separar o CSS em arquivos individuais é uma tarefa que vale a pena. Vincular os arquivos CSS separados usando o mediaatributo relevante permite que o navegador identifique quais arquivos são necessários imediatamente (porque eles 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 a 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 mais tarde, mas com a prioridade “Mais baixa”.
Com CSS empacotado , o 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 diferentes arquivos vinculados e marcados com o mediaatributo relevante, o navegador pode priorizar os arquivos de que precisa no momento. O uso de intervalos de consulta de mídia fechados permite que o navegador faça isso em todas as larguras, ao contrário das min-widthconsultas clássicas mobile-first, em que 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 áreas rurais, as velocidades de conexã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.
CSS empacotado<link href="site.css" rel="stylesheet">Este único arquivo contém todo o CSS, incluindo todas as consultas de mídia, e será baixado com a prioridade mais alta. | CSS separado<link href="default.css" rel="stylesheet"><link href="mobile.css" media="screen and (max-width: 767.98px)" rel="stylesheet"><link href="tablet.css" media="screen and (min-width: 768px) and (max-width: 1083.98px)" rel="stylesheet"><link href="desktop.css" media="screen and (min-width: 1084px)" rel="stylesheet"><link href="print.css" media="print" rel="stylesheet">Separar o CSS e especificar um mediavalor de atributo em cada linktag permite que o navegador priorize o que ele precisa no momento. Dos cinco arquivos listados acima, dois serão baixados com prioridade mais alta: o arquivo padrão e o arquivo que corresponde à consulta de mídia atual. Os outros serão baixados com prioridade mais baixa. |
Dependendo da estratégia de implantação do projeto, uma alteração em um arquivo ( mobile.css, por exemplo) exigiria apenas que a equipe de controle de qualidade fizesse um teste de regressão em dispositivos nesse intervalo de consulta de mídia específico. Compare isso com a perspectiva de implantar o site.cssarquivo empacotado único, uma abordagem que normalmente acionaria um teste de regressão completo.
Se movendo
A adoção do CSS mobile-first foi um marco muito importante no desenvolvimento web; ele ajudou os desenvolvedores de front-end a se concentrarem em aplicativos da Web para dispositivos móveis, em vez de desenvolver sites em desktops e tentar adaptá-los para funcionar em outros dispositivos.
Acho que ninguém quer voltar a esse modelo de desenvolvimento, mas é importante que não percamos de vista o problema que ele destacou: que as coisas podem ficar complicadas e menos eficientes se priorizarmos um dispositivo específico – qualquer dispositivo – em vez de outros. Por esta razão, focar no CSS por si só, sempre atento ao que é a configuração padrão e o que é uma exceção, parece ser o próximo passo natural. Comecei a notar pequenas simplificações em meu próprio CSS, assim como em outros desenvolvedores, e que o trabalho de teste e manutenção também é um pouco mais simplificado e produtivo.
Em geral, simplificar a criação de regras CSS sempre que pudermos é, em última análise, uma abordagem mais limpa do que andar em círculos de substituições. Mas qualquer que seja a metodologia escolhida, ela precisa se adequar ao projeto. Mobile-first pode ou não ser a melhor escolha para o que está envolvido, mas primeiro você precisa entender solidamente os trade-offs em que está se metendo.