Como funcionam as linhas na prática
Quando você começa a mexer com layout em CSS, as linhas verticais e horizontais aparecem de repente em todo lugar. O Grid do navegador desenha elas na sua cara se você ativar o devtools, e aí percebe que tudo o que você vê na tela é só um monte de retas se cruzando. Não tem mistério. Cada linha é um número. Linha 1, linha 2, linha 3. As verticais vão da esquerda para a direita, as horizontais de cima para baixo. Quando você posiciona algo no grid, você basicamente diz "vai da linha 2 até a linha 5". Pronto. Isso funciona desde o IE11 se você usar prefixos, mas quem ainda se preocupa com IE11 já deve ter outra lista de problemas pra lidar.
O problema das linhas verticais e horizontais que ninguém conta
A parte chata é quando o grid tem áreas nomeadas. Você cria um layout bonito com grid-template-areas, coloca tudo nos lugares certos, e aí resolve mudar uma coisa pequena. O navegador reclama que a área nova sobrepõe a antiga porque as linhas implícitas se movem. Eu passei duas horas num projeto real descobrindo que uma linha nomeada que eu achava fixa na verdade se deslocava quando eu adicionava uma coluna no meio do template. A solução que eu uso hoje é simples mas pouco divulgada: nunca conte com nomes de linha implícitos. Sempre nomeie explicitamente. Coloque um nome antes do número em cada linha do template. Se o designer mudar o layout depois, pelo menos você sabe exatamente qual linha é qual.
Contagem de linhas: o erro que todo mundo comete
Se você tem três colunas no grid, você tem quatro linhas. Quatro. A primeira, a última, e as duas do meio. Isso é o que causa aquele bug chato onde seu elemento sai do container porque você colocou grid-column: 1 / 3 achando que ia da linha 1 até a coluna 3, quando na verdade você pulou uma linha. No dia a dia, eu costumo desenhar o grid num papel antes de escrever o CSS. Não é preguiça, é que olhar pro código e tentar contar linhas implicitas todo dia daria muito trabalho. Com três colunas e duas linhas de altura, você tem cinco linhas verticais e três horizontais. Isso dá dezesseis interseções possíveis. Se o grid for responsivo e usar minmax(), essas contas ficam mais confusas porque as linhas implícitas aparecem e desaparecem.
Quando usar grid versus flexbox nas linhas
Flexbox não tem linhas no mesmo sentido. Ele tem eixos. Principal e transversal. Às vezes eu vejo gente usando grid quando flex seria mais simples, e vice-versa. Se o seu layout é basicamente uma fila de itens que precisam se redistribuir quando a tela aperta, flexbox resolve. Se você precisa controlar posições bidirecionais específicas, aí sim entra o grid. O detalhe prático que eu aprendi na marra: se você usar grid-auto-flow: dense, as linhas implícitas vão ser preenchidas de forma diferente do que você espera. Os itens podem pular para buracos que pareciam ocupados. Num projeto meu, isso fez um card de produto aparecer no lugar errado do grid porque o item anterior tinha uma grid-row maior que o padrão. Eu tive que remover o dense e aceitar que ficariam espaços vazios.
Devtools e a visualização das linhas
O Chrome tem um botão discreto lá em cima do painel de elementos. Um ícone que parece uma caixa com linhas. Clicando ali, você vê todas as linhas do grid desenhadas por cima do layout. Isso é utilíssimo quando algo não encaixa e você não sabe qual linha o elemento está realmente ocupando. No Firefox também tem, mas o nome do botão é diferente e às vezes demora pra carregar se a página tiver muitos grids aninhados. Eu já vi o devtools do Firefox travar por uns segundos num dashboard com mais de cinquenta grids menores. Nesses casos, desligar a inspeção visual e checar o código diretamente resolve mais rápido.
Dica técnica: você pode forçar o navegador a mostrar as linhas também via CSS com outline nas células, mas isso polui o layout e só serve pra debug. Em produção, remova. Eu já vi código sair pra staging com os outlines porque o desenvolvedor esqueceu de limpar.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Responsividade e o comportamento das linhas
Quando você muda de desktop pra mobile, as linhas não se resolvem sozinhas. O grid continua existindo, só que com colunas diferentes. Se você usou grid-template-columns: repeat(12, 1fr) no desktop e não definiu nada pro mobile, o navegador vai manter as doze colunas em telas pequenas, o que geralmente quebra o layout. A abordagem que eu uso é definir o grid principal com minmax() e deixar o navegador calcular o número de linhas implícitas. Assim, quando a tela aperta, as linhas horizontais se movem naturalmente porque o container decide quantas linhas precisa. Mas tem um preço: você perde controle fino da posição exata. Se você precisa que um elemento fique exatamente na interseção da linha 3 vertical com a linha 2 horizontal, aí precisa de media queries mesmo.
Limitações reais que você precisa saber
O grid CSS tem um problema que muita documentação não menciona: linhas de grid não são elementos DOM. Você não pode aplicar CSS direto nelas. Se quer estilizar a linha em si, precisa colocar algo no container que herde a posição da linha. Isso é frustrante quando você precisa de uma borda visual entre colunas, por exemplo. A solução comum é usar gap, mas gap não era suportado antigamente em alguns navegadores e dependendo do browser que seu usuário usa, pode não funcionar. Outro problema: se você aninhar grids, as linhas do grid filho existem independentemente do pai. Isso significa que grid-row: 1 / -1 dentro de um grid filho vai pegar as linhas daquele grid específico, não do grid pai. Eu já gastei tarde da noite descobrindo que um elemento que deveria ocupar toda a altura da seção estava limitado à altura de um grid interno porque eu não tinha considerado essa separação.
Se o seu projeto precisa de alinhamento perfeito em larga escala, considere que o grid não é a única ferramenta. Tabelas HTML antigas, sim, mas tabelas semânticas também. Em alguns casos, um display: table resolve alinhamentos verticais que no grid exigiriam hack com align-items e justify-content combinados de formas que ninguém lembra quando volta ao código seis meses depois.
Configurando grids com linha explícita
Aqui vai um exemplo prático do que eu recomendo: grid-template-columns: [sidebar-start] 250px [sidebar-end content-start] 1fr [content-end]; grid-template-rows: [header-start] 60px [header-end main-start] minmax(200px, 1fr) [main-end footer-start] auto [footer-end];
Com isso, você sabe exatamente onde cada linha está. O sidebar vai da linha sidebar-start até sidebar-end. O conteúdo principal ocupa tudo entre content-start e content-end. A linha main-start marca o início da área principal. Se amanhã o layout mudar e o sidebar precisar ser menor, você só altera o 250px e as linhas nomeadas continuam funcionando. Atenção: linhas nomeadas duplicadas se sobrescrevem. Se você nomear duas colunas como [main], a segunda sobrescreve a primeira. Isso é documentado, mas fácil de esquecer quando o template cresce.
Sobre performance
Grid com muitas linhas nomeadas não é significativamente mais lento que grid com apenas números. O navegador resolve o layout de forma similar. O ganho é na manutenibilidade, não na velocidade. Se você tiver mais de cem linhas explícitas num único container, aí sim pode notar diferença em dispositivos fracos, mas isso é caso extremo que raramente acontece em projetos reais. Para layouts complexos com múltiplos grids aninhados, o custo de reflow pode aumentar. Nesse cenário, usar contain: layout no container do grid pode ajudar o navegador a isolar o cálculo. Eu testei isso em um dashboard com quinze grids e a diferença foi visível no scroll. Sem contain, cada mudança de tamanho de janela disparava recálculos em todos os grids da página.
