Uma proposta alternativa para alvenaria do CSS

Rachel Andrew

Publicado em: 30 de abril de 2024. Última atualização: 13 de fevereiro de 2026

A equipe do Chrome quer ver uma implementação de layouts do tipo alvenaria na Web. No entanto, acreditamos que implementá-lo como parte da especificação do CSS Grid, conforme proposto na postagem recente do WebKit, seria um erro. Também achamos que a postagem do WebKit argumentou contra uma versão de alvenaria que ninguém estava propondo.

Portanto, esta postagem tem como objetivo explicar por que nós do Chrome temos preocupações sobre a implementação do masonry como parte da especificação do CSS Grid Layout e esclarecer exatamente o que a proposta alternativa permite. Resumindo:

• A equipe do Chrome quer muito desbloquear o masonry, sabemos que é algo que os desenvolvedores querem.
• Adicionar alvenaria à especificação da grade é problemático por outros motivos além de se você acha que alvenaria é uma grade ou não.
• Definir alvenaria fora da especificação da grade não impede vários tamanhos de faixa para alvenaria, o uso de propriedades como alinhamento ou lacunas ou qualquer outro recurso usado no layout de grade.

A alvenaria deve fazer parte da grade?

A equipe do Chrome acredita que o masonry deve ser um método de layout separado, definido usando display: masonry (ou outra palavra-chave, caso um nome melhor seja decidido). Mais adiante nesta postagem, você vai encontrar alguns exemplos de como isso pode ser feito em código.

Há dois motivos relacionados para acreditarmos que o masonry é mais bem definido fora do layout de grade: o potencial de problemas de desempenho de layout e o fato de que tanto o masonry quanto a grade têm recursos que fazem sentido em um método de layout, mas não no outro.

Desempenho

A grade e o alvenaria são opostos em termos de como o navegador lida com o dimensionamento e o posicionamento. Quando uma grade é criada, todos os itens são colocados antes do layout, e o navegador sabe exatamente o que está em cada faixa. Isso permite o dimensionamento intrínseco complexo, que é muito útil na grade. Com o masonry, os itens são colocados conforme são dispostos, e o navegador não sabe quantos estão em cada faixa. Isso não é um problema com todas as faixas de tamanho intrínseco ou fixo, mas é um problema se você misturar faixas fixas e intrínsecas. Para resolver o problema, o navegador precisa fazer uma etapa de pré-layout de cada item de todas as maneiras possíveis para obter medições. Em uma grade grande, isso contribui para problemas de desempenho do layout.

Portanto, se você tiver um layout em alvenaria com uma definição de faixa de grid-template-columns: 200px auto 200px, algo muito comum em grade, você começará a ter problemas. Esses problemas se tornam exponenciais quando você adiciona subgrades.

Há um argumento de que a maioria das pessoas não vai se deparar com isso, mas já sabemos que as pessoas têm grades muito grandes. Não queremos lançar algo que tenha limites de uso quando há uma abordagem alternativa.

O que fazemos com as coisas que não fazem sentido em cada método de layout?

Quando o flexbox e o grid passaram a fazer parte do CSS, os desenvolvedores muitas vezes sentiram que eles se comportavam de maneira inconsistente. A inconsistência que eles estavam enfrentando era devido a suposições antigas sobre como o layout funcionava, com base no layout de bloco. Com o tempo, os desenvolvedores começaram a entender os contextos de formatação. Quando mudamos para um contexto de formatação de grade ou flexível, algumas coisas se comportam de maneira diferente. Por exemplo, você sabe que, quando está no flexbox, nem todos os métodos de alinhamento estão disponíveis, porque o flexbox é unidimensional.

Agrupar alvenaria em grade quebra essa ligação clara entre o contexto de formatação e a disponibilidade de coisas como propriedades de alinhamento, que são definidas na especificação de alinhamento de caixa por contexto de formatação.

Se decidirmos lidar com o problema de desempenho descrito anteriormente tornando ilegais as definições mistas de faixa intrínseca e fixa em alvenaria, você terá que lembrar que um padrão muito comum para layouts de grade não funciona para alvenaria.

Há também padrões que fariam sentido em alvenaria, por exemplo, grid-template-columns: repeat(auto-fill, max-content), porque não há restrições cruzadas, mas precisam permanecer inválidos na grade. A seguir, há uma lista de propriedades que esperamos que se comportem de maneira diferente ou tenham valores válidos diferentes.

• grid-template-areas: no masonry, só é possível especificar a linha inicial na direção não masonry.
• grid-template: o atalho precisaria considerar todas as diferenças.
• Rastreie valores de dimensionamento para grid-template-columns e grid-template-rows devido a diferenças nos valores legais.
• grid-auto-flow não se aplica a alvenaria e masonry-auto-flow não se aplica a grade. A fusão deles criaria problemas de itens inválidos devido ao método de layout em que você está.
• A grade tem quatro propriedades de posição (grid-column-start e assim por diante), e o masonry tem apenas duas.
• O Grid pode usar todas as seis propriedades justify-* e align-*, mas o Masonry usa apenas um subconjunto, como o flexbox.

Também será necessário especificar o que acontece em todos os novos casos de erro causados por desenvolvedores que usam um valor inválido em "grid-with-masonry" ou "grid-without-masonry". Por exemplo, é válido usar grid-template-columns: masonry ou grid-template-rows: masonry, mas não os dois ao mesmo tempo. O que acontece se você usar os dois ao mesmo tempo? Esses detalhes precisam ser especificados para que todos os navegadores façam a mesma coisa.

Tudo isso se torna complicado do ponto de vista da especificação, agora e no futuro. Precisamos garantir que tudo leve em consideração a alvenaria e se ela funciona ou não. Também é confuso do ponto de vista dos desenvolvedores. Por que você precisa lembrar que, apesar de usar display: grid, algumas coisas não funcionam por causa do uso de alvenaria?

Uma proposta alternativa

Como já mencionado, a equipe do Chrome quer definir o masonry fora da especificação de grade. Isso não significa que ele se limitaria a um método de layout muito simples com tamanhos de coluna idênticos. Todas as demonstrações na postagem do WebKit ainda seriam possíveis.

Layout de alvenaria clássico

Quando a maioria das pessoas pensa em alvenaria, elas imaginam um layout com várias colunas de tamanho igual. Isso seria definido usando o seguinte CSS, que precisa de uma linha a menos de código do que a versão agrupada da grade equivalente.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
}

Usar dimensionamento de faixa do tipo de grade para diferentes larguras de coluna

Além do problema mencionado anteriormente com dimensionamento misto de faixa intrínseca e fixa, você pode usar todo o dimensionamento de faixa que adora da grade. Como o exemplo da postagem do blog do WebKit, um padrão de colunas estreitas e mais largas que se repetem.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr);
  gap: 1rem;
}

Dimensionamento adicional de faixas para alvenaria

Há outras opções de dimensionamento de faixa que não permitimos na grade porque ela é um método de layout bidimensional. Isso seria útil em alvenaria, mas seria confuso se não funcionasse em grade.

Preenchimento automático de faixas de tamanho max-content.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, max-content);
  gap: 1rem;
}

Preenchimento automático de faixas de tamanho auto, que cria faixas do mesmo tamanho, dimensionadas automaticamente para acomodar a maior.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
  gap: 1rem;
}

Permitir que o conteúdo abranja colunas e colocar itens no layout em alvenaria

Não há motivo para não ter conteúdo abrangendo colunas em uma especificação de alvenaria separada. Isso pode usar uma propriedade masonry-track, sendo uma abreviação de masonry-track-start e masonry-track-end, já que você só tem uma dimensão para abranger as coisas em um layout de alvenaria.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
}

.span-2 {
  masonry-track: span 2; /* spans two columns */
}

.placed {
  masonry-track: 2 / 5; /* covers tracks 2, 3, and 4 */
}

Subalvenaria ou subgrade adotando trilhos de alvenaria

Isso pode ser compatível com uma especificação de alvenaria separada, novamente com a ressalva de que faixas de tamanho intrínseco e fixo misturadas não são permitidas. É necessário definir exatamente como isso vai ser. Não vemos motivos para que isso não funcione.

Conclusão

Gostaríamos de chegar a um ponto de uma especificação que possa ser enviada de forma interoperável. No entanto, queremos fazer isso de uma forma que funcione bem agora e no futuro, e que possa ser confiável para os desenvolvedores. A única maneira de lidar com os problemas de desempenho descritos seria piorar o segundo problema, que é ter partes da grade ilegais em alvenaria. Não achamos que essa seja uma boa solução, especialmente quando é possível ter todos os recursos de grade que você quer, mantendo as coisas diferentes claramente separadas.

Se você tiver algum feedback, participe da discussão no problema 9041.

Agradecemos a Bramus, Tab Atkins-Bittner, Una Kravets, Ian Kilpatrick e Chris Harrelson pela revisão desta postagem e pelas discussões que a embasaram.