Quando você cria uma layout, imagem ou componente, a ordem das dimensões importa mais do que a maioria pensa
A pergunta é simples e aparece em praticamente todo projeto: na hora de definir o tamanho de algo, você escreve a altura antes da largura ou o contrário? A resposta curta é que depende do contexto, mas a resposta longa é onde mora o problema que eu levei uns dois anos pra resolver no meu primeiro emprego de desenvolvimento frontend. Vou direto ao ponto. Em CSS com aspect-ratio, por exemplo, a ordem não muda nada funcionalmente porque o navegador calcula o valor proporcional de qualquer jeito. Mas isso é apenas um cenário. A maioria das pessoas que fazem essa pergunta estão lidando com algo mais concreto do que um simples div no meio de uma página.
altura ou largura primeiro: o que acontece no mundo real
No design de interface, especificamente quando se trabalha com grids responsivos, a largura vem primeiro porque é ela que define como o elemento se comporta nas diferentes quebras de breakpoint. O height normalmente é derivado, seja por padding-bottom hack, seja por aspect-ratio. Isso não é uma regra universal, mas é o padrão que a maioria dos frameworks segue justamente porque a largura é o fator de dependência primária em layouts fluidos. Já em impressão e diagramação, a coisa inverte. A altura da folha ou da coluna é o limitador mais restritivo. Eu tive um projeto de um catálogo de produtos onde as dimensões dos cards eram definidas em centímetros e precisei ajustar manualmente 340 thumbnails porque o designer tinha feito tudo em largura fixa e a altura de cada imagem estourava o container em aproximadamente 12% em média. A solução foi scriptar um redimensionamento usando o Pillow com a altura como âncora e auto-width, o que resolvia 95% dos casos. Os 5% restantes eram imagens que precisavam de crop manual.
Isso me leva a um ponto que pouca gente leva a sério: em componentes reutilizáveis, definir a ordem das props ou parâmetros afeta diretamente a legibilidade do código e a frequência com que você vai errar ao chamar a função. Se você cria uma função criarCard(altura, largura) e em outro lugar chama com os argumentos invertidos, o bug é silencioso. O card simplesmente fica com tamanho errado e ninguém percebe na primeira olhada porque a proporção geral parece aceitável.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Onde a maioria erra
O erro mais comum é tratar a ordem como irrelevante e padronizar de qualquer jeito sem documentação. Eu já vi código onde um mesmo time usava (largura, altura) em um arquivo e (altura, largura) em outro, ambos para o mesmo tipo de componente. Isso gera bugs difíceis de rastrear porque o problema não é funcional — o código roda — só que o resultado visual não bate com o que foi planejado. A correção mais prática é nomear explicitamente: criarComponente({ largura: 400, altura: 300 }) em vez de depender de posição posicional. Outro ponto: em SVG, a ordem padrão do viewBox é largura-antes-da-altura. viewBox="0 0 800 600" significa 800 pixels de largura e 600 de altura. Isso é padrão da especificação desde 1999, mas gente nova muitas vezes assumes o contrário e acaba com ícones espremidos ou distorcidos. Se você está gerando SVG dinamicamente, confirme sempre se a ferramenta que você está usando segue esse padrão ou se inverte os eixos.
Quando a ordem realmente não importa
Elementos com dimensões fixas e absolutas, como um banner HTML que carrega uma imagem de fundo com tamanho declarado, não sofrem influência da ordem de definição. O browser lê o CSS e aplica as propriedades independentemente de qual veio primeiro no arquivo. Isso é diferente de propriedades que dependem de herança ou de contexto de formatação, onde a ordem no documento pode alterar o cálculo final. Em Flexbox, por exemplo, a propriedade flex-direction é o que determina qual dimensão é considerada primária para o alinhamento, não a ordem em que width e height foram escritos. Um item com width: 200px; height: 100px; flex-direction: column; vai se comportar de forma completamente diferente do que se a direção fosse row, mesmo que as dimensões sejam idênticas. A ordem das declarações CSS é irrelevante aqui; o que importa é a propriedade estrutural que redefine o eixo principal.
Minha recomendação prática
Se você está construindo algo que vai ser mantido por outras pessoas ou evoluído ao longo do tempo, use nomes explícitos. Evite funções com parâmetros posicionais para dimensões. Em CSS, siga a convenção do seu projeto — se não existe convenção, adote largura primeiro como padrão e documente isso num README ou num arquivo de style guide, porque consistentemente diferente é melhor do que consistentemente certo em contextos isolados. O problema real de altura ou largura primeiro não é técnico. É de comunicação. Sempre que duas pessoas precisam interpretar as mesmas dimensões de formas diferentes, o atrito aparece. O workaround que funciona na prática é padronizar no nível do projeto e revisar o padrão quando o projeto muda de contexto — o que funcionou para web pode não funcionar para print, e vice-versa. Eu mudei meu padrão duas vezes nos últimos cinco anos e cada mudança resolveu um problema específico que eu estava enfrentando, então não tenha medo de revisitar a decisão se o contexto pedir.
