- A WebKit está pedindo feedback de designers e desenvolvedores no processo de padronização do layout masonry/waterfall, há muito tempo difícil no CSS, como parte do CSS Grid Level 3
- O modelo proposto funciona sobre
display: grid com grid-template-rows: masonry para desativar a criação de linhas e preencher os espaços vazios com o conteúdo como se fossem tijolos
- A Apple considera que esse recurso deve ficar dentro do Grid para poder combinar com capacidades já existentes, como
fr, minmax(), max-content, spanning, posicionamento explícito e subgrid
- Uma abordagem separada com
display: masonry pode simplificar a separação do tipo de layout, mas, nas discussões, pode acabar limitada a colunas de mesma largura e dificultar o uso da capacidade de dimensionamento de trilhas do Grid
- Após a atualização de outubro de 2024, o CSS Working Group concluiu que vale a pena incluir trilhas de largura variável, posicionamento explícito, spanning e subgrid no masonry, e que a implementação com bom desempenho é viável, embora a discussão sobre a sintaxe continue
Situação atual do CSS Grid Level 3
- Após a atualização de outubro de 2024, foi criado o Working Draft oficial do W3C para o CSS Grid Layout Module Level 3, documentando como o layout masonry deve funcionar
- Os membros do CSS Working Group concluíram que vale a pena incluir os seguintes recursos no layout masonry e que eles podem ser implementados com bom desempenho
- trilhas de largura variável
- posicionamento explícito
- spanning
subgrid
- Mesmo assim, a disputa sobre a sintaxe continua em aberto, e a WebKit dá continuidade ao tema em outro texto, Help us choose the syntax for Masonry in CSS
Por que o layout masonry é necessário
- O CSS Grid Level 1 foi introduzido em 2017 para reduzir a carga de dimensionamento e posicionamento dos layouts baseados em float, e o Grid Level 2 trouxe o Subgrid
- Mas mesmo depois da chegada do CSS Grid, a pergunta “como escrever um layout masonry em CSS” ficou sem uma resposta clara por 7 anos
- O layout masonry é um padrão em que o conteúdo é encaixado como tijolos ou pedras em um muro, e também é conhecido como waterfall layout
- Como ele consegue lidar com conteúdos com proporções diferentes, reduz a necessidade de cortar ou encolher tudo para caber no mesmo retângulo
- Como o conteúdo fica distribuído por toda a página, a ordem de leitura se mantém de forma natural durante a rolagem, e é possível adicionar conteúdo no fim com lazy-load sem mover o que já está na página
Histórico da proposta e debate de padronização
- O mecanismo para criar layouts masonry em CSS foi proposto pela Mozilla pela primeira vez em janeiro de 2020 como uma extensão do CSS Grid, e implementado no Firefox Nightly como recurso experimental atrás de flag
- A Apple começou a implementar a proposta do CSS Grid Level 3 no Safari Technology Preview em 2022, e atualmente ela vem ativada por padrão
- Dentro do CSS Working Group houve divergências sobre a direção básica
- alguns defendiam que masonry deveria ser um tipo de
display separado, e não parte do CSS Grid
- alguns não tinham certeza de que esse layout era realmente necessário para a web nem de que sites conhecidos o usariam
- A WebKit entende que, para os navegadores lançarem esse recurso, é preciso antes haver consenso no CSS Working Group
Uso básico: Grid só com colunas, sem linhas
- O layout masonry/waterfall clássico pode ser escrito aplicando
display: grid ao elemento main, definindo as colunas e especificando o valor masonry no eixo das linhas
main {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
gap: 1rem;
grid-template-rows: masonry;
}
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr)) cria repetidamente colunas flexíveis com largura mínima de 14remgap: 1rem cria um espaçamento de 1rem entre colunas e itensgrid-template-rows: masonry instrui o navegador a não criar linhas e preencher o conteúdo em um padrão masonry/waterfall- Este exemplo cria um layout flexível que se adapta a vários tamanhos de tela com apenas quatro linhas de CSS, sem media queries nem container queries
- O nome do valor
masonry ainda pode mudar antes do lançamento nos navegadores
Por que preservar a capacidade do Grid de definir colunas
- Para mostrar por que o masonry deve fazer parte do CSS Grid, a WebKit criou quatro demos que podem ser testadas em webkit.org/demos/grid3
- As demos podem ser vistas em navegadores com suporte ao Grid Level 3
- O CSS Grid oferece várias opções para definir colunas
- tamanhos fixos em várias unidades, como
px, em, rem, cqi, lh, ch, ic, cap, vw, svh
max-content, min-content- unidade
fr
minmax()- tamanhos em
%
auto
- Por exemplo, é possível deixar a primeira e a última colunas com largura fixa de 14ch e criar no meio colunas flexíveis com mínimo de 28ch
main {
display: grid;
grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch;
grid-template-rows: masonry;
gap: 1rem;
}
- A combinação de
fr com minmax() permite criar uma flexibilidade em dois estágios, em que as colunas crescem e encolhem em momentos diferentes
max-content e min-content fazem o tamanho das colunas acompanhar o tamanho do conteúdo, permitindo arranjos diferentes daqueles em que o conteúdo é forçado a se adaptar à coluna- Também é possível criar colunas com larguras diferentes usando a sequência de Fibonacci, como em
grid-template-columns: 1fr 1fr 2fr 3fr 5fr 8fr;
- O exemplo de mega menu usa
grid-template-columns: repeat(auto-fill, minmax(max-content, 30ch)); para que cada coluna fique larga o suficiente para acomodar o texto dos links sem quebra de linha
- A WebKit entende que a discussão sobre um
display: masonry separado caminha para algo que, como o multicolumn layout de hoje, permitiria apenas colunas de mesmo tamanho
Spanning, View Transitions e columnar grid
- O CSS Grid permite que itens ocupem várias colunas, o que também possibilita composições visuais variadas em um layout masonry
- No exemplo, é possível fazer com que cada quinta imagem ocupe duas colunas, enquanto as demais ocupam apenas uma
- Também é possível atribuir a classe
wider a imagens com proporção mais larga para que ocupem várias colunas, além de variar isso com cantos quadrados ou reduzindo o espaçamento para 0
- A demo Photos combina isso com View Transitions: quando o usuário clica ou toca em uma foto, ela cresce ocupando várias colunas e o navegador anima a transição automaticamente
- Essa demo requer Safari Technology Preview 192 ou superior
- A WebKit considera que o núcleo do Grid Level 3 não é exatamente o padrão específico chamado “masonry”, mas sim um mecanismo para desativar as linhas
- Essa abordagem cria um columnar grid composto apenas por colunas, em contraste com o modular grid, em que linhas e colunas ficam alinhadas e que o CSS Grid Level 1 produz muito bem
Diferença entre modular grid e columnar grid
- O modular grid é um Grid em que o conteúdo se alinha tanto às colunas quanto às linhas, e o CSS Grid Level 1 é adequado para esse tipo de arranjo
- Os layouts baseados em float também incentivavam o uso de modular grid, porque era preciso alinhar a altura do conteúdo para que os floats se organizassem corretamente
- Em sites reais, é comum igualar a proporção das imagens, ajustar o comprimento dos textos ou encaixar o conteúdo em caixas idênticas por política de CMS, recorte em CSS ou reticências
- O columnar grid permite deixar o conteúdo manter o tamanho que ele deseja e fazer o layout se adaptar a esse conteúdo
- A WebKit considera que até conteúdos centrados em texto podem ganhar uma apresentação mais dinâmica, por exemplo ao fazer a matéria mais recente ocupar quatro colunas, algumas matérias recentes ocuparem duas e conteúdos mais antigos ocuparem uma só
Combinação com Subgrid e posicionamento explícito
- O subgrid do CSS Grid Level 2 é suportado pela maioria dos navegadores
- No exemplo da página de museu, em vez de listar os metadados dos cartões de obras em uma única coluna alinhada à esquerda, o
subgrid posiciona o ano e o número de catálogo à direita de cada cartão e os alinha com os mesmos dados dos outros cartões
- Se o masonry entrar no CSS Grid Level 3, as ferramentas de desenvolvedor existentes também poderão ser reaproveitadas
- é possível testar
grid-template-rows: masonry no Grid Inspector do Safari Technology Preview
- Com um tipo de display separado, os benefícios do subgrid não estariam disponíveis
- O posicionamento explícito do CSS Grid Level 1 também pode ser usado junto; no exemplo,
grid-column: -3 / -1 posiciona o cabeçalho no canto superior direito da página, nas duas últimas colunas
- A WebKit considera que, com poucas linhas de código de layout, dá para combinar recursos dos Grid Levels 1, 2 e 3 e criar layouts em que o número de colunas muda conforme o espaço disponível, sem media queries nem container queries
Pontos de debate com display: masonry
- A WebKit e a Apple veem o Masonry como um recurso que expande o CSS Grid para permitir criar não só modular grids, mas também columnar grids
- Nessa direção, seria possível usar junto recursos do Grid como definição de colunas, spanning de trilhas, posicionamento explícito e
subgrid
- Quem prefere um tipo de display separado entende que isso permite separar os tipos de layout de forma mais limpa
display: block;
display: inline;
display: flexbox;
display: grid;
display: masonry;
- O CSS Working Group ainda não discutiu a sintaxe de um tipo de display Masonry separado, mas a WebKit cita como exemplo uma sintaxe parecida com Multicolumn layout ou uma sintaxe limitada similar à do Grid
main {
display: masonry;
columns: 28ch;
}
main {
display: masonry;
masonry-columns: repeat(5, minmax(28ch, 1fr));
/* where only one repeating width is allowed */
}
- Um tipo de layout separado evitaria o trabalho necessário para manter Grid e Masonry funcionando juntos continuamente
- o modelo de layout ficaria mais simples
- a implementação nos navegadores seria mais fácil
- haveria menos chance de armadilhas de desempenho
- os conjuntos de recursos de Grid e Masonry poderiam divergir
- Por outro lado, a WebKit considera que, se os dois tipos de layout Grid permanecerem conectados, o CSS Working Group tenderá a definir recursos futuros para modular grid e columnar grid ao mesmo tempo
- Por exemplo, se o CSS Grid Level 4 adicionar recursos como estilização de grid area e grid line, cor de fundo de trilhas e rule line do gap, seria melhor que tudo isso funcionasse desde o início nos dois tipos de Grid
Como enxergar “Grid”
- Quem apoia um
display: masonry separado às vezes entende que o CSS Grid é essencialmente um alinhamento bidimensional, e que o masonry não seria Grid porque alinha em apenas uma direção
- A WebKit considera que, na história do design gráfico, o grid sempre foi uma ferramenta para alinhar texto, imagens e conteúdo em padrões regulares e melhorar legibilidade e usabilidade
- Antes mesmo de os modernistas europeus e americanos do século 20 enfatizarem o alinhamento por colunas e linhas como o “verdadeiro” grid do design gráfico, vários tipos de grid já eram usados
- Mark Boulton via o columnar grid simétrico como formal e monótono, e defendia o uso de compound grids assimétricos no web design
- O CSS Grid Level 1 facilitou a criação de grids assimétricos e compound grids, mas hoje isso só vale quando esse Grid é um modular grid
- A WebKit considera que tanto modular grid quanto columnar grid são grids, e que o CSS Grid também deveria ter a capacidade de criar columnar grids
Feedback solicitado a desenvolvedores e designers
- A WebKit pede que desenvolvedores e designers criem demos por conta própria, publiquem opiniões em blogs ou redes sociais e deixem comentários nas issues do CSS Working Group
- As perguntas para feedback são as seguintes
- “masonry”/“waterfall” deveria fazer parte do CSS Grid?
- são necessários recursos de columnar grid que incluam
subgrid, spanning, posicionamento explícito e vários tipos de track sizing?
- basta ter apenas o layout masonry clássico com colunas de mesmo tamanho?
- você realmente usaria esse recurso, e o que conseguiria construir com ele?
- há links para demos criadas por você?
- existe algo que este modelo não consegue fazer?
- A equipe da WebKit trabalha em Masonry há um ano e meio, e o recurso foi ativado por padrão no Safari Technology Preview 163 em fevereiro de 2023
- Eles querem lançar o recurso em breve, mas detalhes como o nome e questões mais fundamentais ainda precisam ser resolvidos antes
Discussão sobre o nome: masonry, waterfall, off
- A WebKit considera bastante possível que
masonry não seja o melhor nome para o novo valor
- Nomes em CSS costumam ser palavras simples que descrevem diretamente o resultado, como
center, contain, clip, wrap, smooth
masonry é uma metáfora que exige contexto, o que pode torná-la difícil de memorizar para desenvolvedores que não usam inglês- Em algumas regiões, esse layout é mais conhecido como
waterfall, então grid-template-rows: waterfall também pode ser um candidato viável
- A WebKit entende que esse recurso está mais próximo de um mecanismo do tipo “crie um Grid, mas não crie linhas” do que propriamente de um layout estilo Pinterest
grid-template-rows: none; poderia fazer sentido semanticamente, mas none já é o valor padrão de grid-template-* com o sentido de “sem linhas explícitas, apenas linhas implícitas”, então não pode ser usado- Como alternativa, foi proposto
grid-template-rows: off;
main {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
grid-template-rows: off;
}
- O CSSWG está discutindo o nome nesta issue
- No momento, o Safari Technology Preview e as demos usam o valor
masonry de acordo com o Editor’s Draft, mas o nome pode mudar no futuro
1 comentários
Opiniões no Hacker News
O contexto é que os responsáveis por relações com desenvolvedores do CSSWG dos fornecedores de navegadores vêm discutindo como incluir oficialmente o layout Masonry no CSS. É uma discussão que vem acontecendo pelo menos desde 2020, quando o Firefox fez a primeira proposta
A novidade aqui é que o lado do WebKit trouxe essa discussão a público e pediu uma ação a designers e desenvolvedores, algo como “postem nas redes sociais, escrevam posts em blogs”
Por fora, pode parecer um procedimento formal, mas pode se tornar um precedente importante. O ponto central é decidir se todas as opções de layout devem ser tratadas como parte do CSS Grid, ou se novas propriedades CSS Display devem continuar sendo adicionadas conforme a necessidade
A primeira opção tornaria a especificação já complexa do CSS Grid ainda mais complexa; a segunda poderia inchar a especificação CSS com novas propriedades e subpropriedades. Nenhuma das duas é tão simples quanto parece
Grid primeiro posiciona todos os itens na grade, por exemplo em algo como
col:2,row:3, e só depois determina o tamanho da grade. Masonry, idealmente, quer primeiro determinar o tamanho das trilhas e depois posicionar os itens nessas trilhasA primeira implementação do Firefox e a especificação da época basicamente diziam que, exceto pela primeira linha e algumas regras complexas, os itens Masonry não eram considerados no cálculo do tamanho das trilhas; por isso era muito fácil um item transbordar a trilha
A especificação atual exige tentar posicionar todos os itens em todas as trilhas possíveis. No pior caso, que também é bastante comum, isso resulta em desempenho quadrático de O(N_tracks * N_items), e desempenho quadrático é ruim[1]; praticamente não há nada assim em outros algoritmos de layout
Com aninhamento, o desempenho piora de forma quase exponencial, e isso não é bom mesmo com CPUs rápidas. Pode-se dizer que esses casos não são comuns, mas em modos de layout CSS as pessoas sempre testam os limites, então ele precisa ser rápido por padrão
Em Grid, como um item define seu próprio tamanho de forma diferente dependendo de qual trilha ele ocupa, é necessário tentar posicioná-lo em todos os lugares possíveis. Para mitigar esse problema, Masonry talvez precise de outro algoritmo para cálculo de tamanho das trilhas, mas o post do blog não trata essa questão suficientemente. Poderia ter existido uma versão do cálculo de tamanho de Grid sem dependência da posição dos itens, mas esse barco já zarpou
[1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...
Em geral, basta usar
grid-row-template: masonrye o restante continua funcionando bem. Isso é bom, e não acho que torne o layout Grid mais difícil de usar do que já éA desvantagem fica principalmente para autores de engines de navegador. O padrão para “suporte completo a CSS Grid” fica mais alto. Também se diz que uma implementação que precisa dar suporte a todos os recursos de Grid consegue evitar armadilhas de desempenho que poderiam tornar alguns layouts Grid mais lentos do que quando a especificação era mais simples
Se houvesse um modo display separado, seria preciso repetir a especificação de
grid-columnpara o layout Masonry, e isso seria uma penaNão tem relação direta com CSS Masonry, mas recentemente prototipei a segunda iteração de uma interface com uma tensão parecida. A questão era se deveríamos aumentar o número de tipos semelhantes, mas diferentes, no modelo de dados, ou aumentar as nuances dentro dos tipos existentes para permitir refinamentos
No começo, eu preferia fortemente a segunda opção, mas, ao explorar as opções na prática, acabou sendo muito mais simples consumir a interface “inchada” e, a partir dela, raciocinar sobre o código da aplicação
Não tenho uma posição forte sobre CSS Masonry, mas pode haver uma surpresa parecida entre a tensão que as pessoas percebem intuitivamente e a sensação no uso real. No CSS, em especial, talvez seja difícil justificar o “inchaço”, ou seja, o aumento de semânticas específicas por caso de uso, mas usuários também podem tender a achar uma API densa como Grid mais difícil
Testei no Firefox e no Safari desde o ano passado e não tenho reclamações sobre a implementação. Há quem reclame da posição e do nome das propriedades, mas é preciso reconhecer que provavelmente não existe uma solução perfeita e implementar de forma pragmática
Recuso usar JavaScript como implementação alternativa. Por isso, o fallback envolve bastante CSS feio que não consegue manter a ordem corretamente, mas isso não é um grande problema para o projeto em que estou trabalhando. Hoje, a maioria provavelmente usaria JavaScript como fallback, mas, se a solução para layout é JavaScript, você já está começando em desvantagem
Não gostei nem um pouco da demo de megamenu <https://webkit.org/demos/grid3/megamenu/>, e usar Masonry ali parece totalmente inadequado. Bagunça a direção do fluxo e quebra bastante as expectativas
Ordem de leitura esperada: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2....
Ordem que a demo real sugere: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... Isso afeta a ordem de leitura correta e o índice de tabulação. Usuários visuais, na prática, quase sempre acabam lendo na ordem “errada”
No fim, isso mostra que não há estrutura, é apenas uma sacola desestruturada com links. Mas, se você seguir a ordem dos números, parece que havia uma ordem bastante lógica, que foi completamente arruinada pela aplicação inadequada de Masonry
Nas capturas de tela, ativei “mostrar números dos itens”. Normalmente, parece uma coluna comum sem fundo
A implementação deveria ter usado colunas, adicionando
break-inside: avoida cada seção. A demo deixou isso passarTambém fico um pouco desconfiado da demo de jornal por motivos parecidos, mas é um problema bem menor
Quando se trata de blocos mais independentes, como mídia do tipo imagens, em que a ordem de leitura não está tão profundamente embutida, o layout Masonry funciona melhor. Ainda assim há algumas ambiguidades em torno do índice de tabulação, mas já não é algo claramente errado
Em um layout Masonry, a expectativa de usuários visuais não é que haja continuidade entre colunas, mas que ela siga as linhas visuais. A ordem apresentada como “inesperada” também segue isso
O problema parece estar no fato de a ordem de tabulação ignorar a ordem original do conteúdo e tentar imitar o visual; quase certamente é um resquício da implementação atual
O ponto positivo desse recurso é que, mesmo ao ver a demo em navegadores sem suporte — ou seja, todos os navegadores estáveis atuais sem ativar flags especiais —, como ela foi criada diretamente sobre Grid layout, aparece em um formato de linhas fixas bastante razoável: https://webkit.org/demos/grid3/
Em cada caso, um layout Masonry adequado ficaria muito melhor, mas, mesmo sem isso, continua perfeitamente utilizável. Se não gostar, também dá para fazer detecção de recurso e oferecer uma apresentação alternativa melhor
Gosto muito da aparência e da sensação geral de layouts Masonry/em cascata. Talvez por ter crescido lendo jornal impresso, e ainda ler hoje, layouts baseados em colunas parecem uma forma intuitiva de dividir uma página
Ainda assim, gostaria que houvesse uma alternativa ao alinhamento Masonry padrão. Pelo que sei, a regra básica é algo como “colocar o próximo item na coluna em que ele possa ficar mais alto”, e por causa disso, a partir da segunda linha, a ordem da esquerda para a direita fica bastante embaralhada
O que imagino como uma abordagem melhor é um layout que preserve mais o fluxo de leitura da esquerda para a direita — ou, se a direção preferida for da direita para a esquerda, esse fluxo. Por exemplo: “colocar o próximo item na coluna à direita do item anterior; se já estiver na mais à direita, colocá-lo na mais à esquerda; e, se o novo fundo não ficar muito abaixo do limite inferior da coluna à esquerda, permitir colocar um segundo item na mesma coluna”
Isso é mais flexível do que uma ordem esquerda→direita estrita, estraga menos o alinhamento e ainda consegue preservar em certa medida o significado da direção de leitura esquerda→direita
Masonry não conseguirá acomodar todas as fórmulas que alguém poderia preferir, mas, para conteúdo em que a ordem importa ao menos um pouco — talvez não Pinterest, mas algo como um diário ou revista —, eu veria isso como um padrão mais razoável do que a regra clássica de Masonry
Em um layout no estilo revista, não se lê primeiro de cima→baixo em uma coluna e depois da esquerda→direita? Em CSS, isso já é possível com
columnsou Flexbox em direção verticalOutro problema desse layout Masonry é que a parte de baixo fica irregular. Em uma revista, provavelmente ela seria alinhada de forma uniforme, e isso também pode ser feito com colunas ou Flexbox
Na Web, parece haver a suposição oculta de conteúdo com rolagem infinita, então o formato da parte inferior da página não importaria. Se for isso, não é exatamente uma suposição que valha a pena incentivar
{ /* ao atualizar, mover elementos no máximo 2 colunas para a esquerda ou direita */ grid-template-max-horizontal-shift: 2 col; }Se pudéssemos criar um sistema sem compatibilidade retroativa para substituir o CSS, como deveríamos fazer?
Existe algum livro ou artigo sobre como criar um sistema de layout consistente?
E alternativas como Qt, Tk, SwiftUI? Nunca usei nada além de CSS. Se existe algum sistema melhor entre os que são amplamente implementados na prática, o que o torna melhor?
Quero um sistema que ofereça uma interface melhor para desenvolvedores, mas não sei como chegar lá. Se pudéssemos começar do zero, quais deveriam ser os princípios de design?
As propriedades deveriam ser mais explícitas e separadas. Deveríamos acabar com gambiarras como margens negativas, e todas as distâncias deveriam ser em múltiplos estágios. Por exemplo, algo como
padding = max(el.paddings[])As caixas de contorno deveriam ser explícitas, e as bordas deveriam virar elementos de verdade. O modelo de caixa em si não é ruim; o CSS é que fez uma implementação horrível dele. Está cheio de magias frágeis em que 99% quebra cada vez que você mexe, e de limitações absurdas, que por sua vez geram mais problemas e “soluções”
É uma abordagem projetada para resolver mudanças de tamanho e formato de tela. A Apple migrou para o SwiftUI e talvez tenha deixado essa abordagem para trás
Flutter e XAML também parecem candidatos que valeria a pena analisar
Repostando como comentário de nível superior para ficar mais visível
Tenho um site de fotografia e não uso JavaScript para o layout. Ao criá-lo, avaliei bibliotecas JavaScript de Masonry, mas os resultados não me agradaram
Um layout Masonry de verdade, que preenche todo o espaço disponível, corta algumas imagens. Para manter a proporção sem cortar, é preciso deixar espaços em branco ao redor das fotos. A única forma de não fazer isso é com rolagem infinita, que talvez seja o que as máquinas corporativas de vício querem, mas não é o que quero no meu site
Fiz assim:
https://yakubin.com/photography/albumless/
https://yakubin.com/photography/album/kenya-2023/
Para obter esse resultado, usei
display:inline-block, tratando as fotos como texto que deve refluir para uma nova linha. Estou muito satisfeito com o resultado e prefiro isso à forma como as bibliotecas Masonry fazemO problema é a ordem. Se a ordem não for importante, as soluções só com CSS atuais funcionam bem. Mas, pelo que me lembro, podem deixar um formato estranho na parte inferior das colunas
Relacionado a isso, criei uma demonstração interativa que aborda os princípios de Grid:
https://cssprinciples.com/3/grid/
Já existem os floats tradicionais e também os layouts modernos Flexbox e Grid; fica a dúvida se faz sentido continuar adicionando opções de “layout” ao CSS.
Se ainda houver casos que não são cobertos, talvez uma solução melhor seja ter um último sistema baseado em restrições que cubra todos os casos de layout, mesmo que isso aumente a complexidade. Assim, frameworks CSS e bibliotecas utilitárias poderiam criar coisas como a próxima geração de Masonry Grid em cima dele
Ainda assim, a proposta de layout do Houdini é a que chega mais perto dessa ideia. Ela passa o layout para um contexto JavaScript isolado: https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
Mas, sinceramente, como Flexbox, Grid e recursos como containment já resolveram muitos problemas, a demanda por melhorias ficou bem menor do que na era anterior ao Flexbox
display: grid;grid-template-rows: masonry;Mas fica limitado ao WebKit. Cheguei a implementar isso no modo galeria do meu feed de notícias pessoal, mas já removi em outubro de 2023
Um sistema baseado em restrições parece que ficaria em algum ponto meio estranho entre Grid e JavaScript, então não sei se ajudaria muito
Já estou usando isso. No Firefox, ativo nas opções e uso nos favoritos. No mobile, como tudo simplesmente fica empilhado de cima para baixo, não é um problema. No mobile não há
about:configA última imagem está com a opção desativada
https://imgur.com/a/o7OyZEW
Por isso, ao redimensionar a janela, a ordem dos favoritos deve mudar
Mais contexto e os argumentos do lado contrário — ou seja, a discussão de que
display: masonryé melhor do quedisplay:grid+grid-template-rows: masonry— podem ser vistos em detalhes aqui: https://github.com/w3c/csswg-drafts/issues/9041