Una propuesta alternativa para la mampostería de CSS

Rachel Andrew

El equipo de Chrome desea ver una implementación de diseños de tipo de albañilería en la Web. Sin embargo, creemos que implementarla como parte de la especificación de la cuadrícula de CSS según lo propuesto en la publicación reciente de WebKit sería un error. También consideramos que en la publicación de WebKit se argumentaba en contra de una versión de la albañilería que nadie proponía.

Por lo tanto, el objetivo de esta publicación es explicar por qué en Chrome nos preocupa la implementación de la albañilería como parte de la especificación de diseño de cuadrícula de CSS, además de aclarar exactamente lo que permite la propuesta alternativa. En resumen:

• Al equipo de Chrome le interesa mucho desbloquear la mampostería, y sabemos que es algo que los desarrolladores quieren.
• Agregar mampostería a la especificación de la cuadrícula es problemático por motivos no relacionados con el hecho de si crees que la mampostería es o no una cuadrícula.
• La definición de la mampostería fuera de la especificación de la cuadrícula no impide el uso de varios tamaños de trazado para la albañilería ni el uso de propiedades, como la alineación o los espacios, ni otras características utilizadas en el diseño de cuadrículas.

¿La mampostería debería ser parte de la red?

El equipo de Chrome cree que la mampostería debe ser un método de diseño independiente, definido con display: masonry (o bien, se debería decidir un nombre más adecuado con otra palabra clave). Más adelante en esta publicación, puedes ver algunos ejemplos de cómo podría verse en el código.

Hay dos razones relacionadas por las que creemos que la mampostería se define mejor fuera del diseño de la cuadrícula: el potencial de problemas de rendimiento del diseño y el hecho de que tanto la mampostería como la cuadrícula tengan funciones que tienen sentido en un método de diseño, pero no en el otro.

Rendimiento

La cuadrícula y la mampostería son lo opuesto en términos de cómo el navegador maneja el tamaño y la ubicación. Cuando se presenta una cuadrícula, todos los elementos se colocan antes del diseño, y el navegador sabe exactamente qué hay en cada segmento. Esto habilita el tamaño intrínseco complejo que es tan útil en la cuadrícula. En la mampostería, los elementos se colocan a medida que se disponen y el navegador no sabe cuántos hay en cada pista. Esto no representa un problema con todas las pistas de tamaño intrínseco o de tamaño fijo, pero lo es si combinas pistas intrínsecas y fijas. Para solucionar el problema, el navegador debe realizar un paso previo al diseño en el que se distribuye cada elemento de todas las formas posibles a fin de obtener mediciones. Una cuadrícula grande podría generar problemas de rendimiento del diseño.

Por lo tanto, si tienes un diseño de mampostería con una definición de seguimiento de grid-template-columns: 200px auto 200px (una acción muy común en la cuadrícula), comenzarás a tener problemas. Estos problemas se vuelven exponencialmente una vez que agregas subcuadrículas.

Existe el argumento de que la mayoría de las personas no se encontrará con esto, pero ya sabemos que las personas sí tienen cuadrículas muy grandes. Si existe un enfoque alternativo, no queremos enviar un producto que tenga límites de uso.

¿Qué hacemos con las cosas que no tienen sentido en cada método de diseño?

Cuando Flexbox y la cuadrícula se convirtieron en parte de CSS, a menudo, los desarrolladores sintieron que se comportaban de manera inconsistente. La incoherencia que experimentaban se debía a suposiciones prolongadas sobre cómo funcionaba el diseño, en función del diseño de bloques. Con el tiempo, los desarrolladores comenzaron a comprender mejor los contextos de formato. Cuando pasamos a un contexto de cuadrícula o de formato flexible, algunas cosas se comportan de manera diferente. Por ejemplo, sabes que cuando estás en flexbox, no todos los métodos de alineación están disponibles, porque flexbox es unidimensional.

La agrupación de mampostería en una cuadrícula rompe este vínculo claro entre el contexto de formato y la disponibilidad de aspectos como las propiedades de alineación, que se definen en la especificación de alineación de cuadros por contexto de formato.

Si decidimos resolver el problema de rendimiento descrito anteriormente haciendo que las definiciones de pistas combinadas intrínsecas y fijas sean ilegales en la mampostería, deberás recordar que un patrón muy común en los diseños de cuadrículas no funciona en la mampostería.

También hay patrones que tendrían sentido en la albañilería, por ejemplo, grid-template-columns: repeat(auto-fill, max-content), porque no tienes restricciones cruzadas, pero deben permanecer no válidos en la cuadrícula. La siguiente es una lista de propiedades que esperamos que se comporten de manera diferente o que tengan valores válidos distintos.

• grid-template-areas: En mampostería, solo puedes especificar la fila inicial en la dirección que no es de albañilería.
• grid-template: La abreviatura debería tener en cuenta todas las diferencias.
• Haz un seguimiento de los valores de tamaño de grid-template-columns y grid-template-rows debido a las diferencias en los valores legales.
• grid-auto-flow no se aplica a mampostería y masonry-auto-flow no a la cuadrícula. La combinación crearía problemas de elementos que no son válidos debido al método de diseño en el que te encuentras.
• La cuadrícula tiene cuatro propiedades de posición (grid-column-start, y así sucesivamente), la albañilería solo tiene dos.
• Grid puede usar las seis propiedades justify-* y align-*, pero Masonry solo usa un subconjunto como flexbox.

También habrá un requisito para especificar lo que sucede en todos los casos de error nuevos que generan los desarrolladores que usan un valor que no es válido en cuadrícula con mampostería o cuadrícula sin mampostería. Por ejemplo, es válido usar grid-template-columns: masonry o grid-template-rows: masonry, pero no ambos al mismo tiempo. ¿Qué sucede si usas ambos a la vez? Estos detalles deben especificarse para que todos los navegadores hagan lo mismo.

Todo esto se complica desde el punto de vista de las especificaciones, ahora y en el futuro. Deberemos asegurarnos de que todo tenga en cuenta la mampostería y si esta funciona o no. También es confuso desde el punto de vista de los desarrolladores. ¿Por qué es necesario tener en cuenta que, a pesar de usar display: grid, algunas cosas no funcionan debido a la mampostería?

Una propuesta alternativa

Como ya se mencionó, al equipo de Chrome le gustaría definir mampostería fuera de la especificación de la cuadrícula. Esto no significa que se limitaría a un método de diseño muy simple con tamaños de columna idénticos. Todas las demostraciones en la publicación de WebKit serían posibles.

Diseño de mampostería clásica

Cuando la mayoría de las personas piensan en mampostería, piensan en un diseño con varias columnas del mismo tamaño. Esto se definiría con el siguiente CSS, que necesita un código sin líneas que la versión empaquetada de cuadrícula equivalente.

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

Utiliza el tamaño de pista de tipo de cuadrícula para diferentes anchos de columna.

Aparte del problema mencionado anteriormente con un tamaño mixto de pistas intrínsecas y fijas, puedes usar todos los tamaños de pistas que te encantan de la cuadrícula. Como el ejemplo de la entrada de blog de WebKit, un patrón de repetición de columnas estrechas y más anchas

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

Tamaño de vías adicionales para mampostería

Hay opciones adicionales para ajustar el tamaño de las pistas que no permitimos en la cuadrícula, ya que es un método de diseño bidimensional. Serían útiles en la mampostería, pero sería confuso si después no trabajaran en cuadrícula.

Autocompletar pistas con tamaño de max-content

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

Autocompletar segmentos con tamaño auto, lo que creará segmentos del mismo tamaño y ajustará su tamaño automáticamente para adaptarse al más grande.

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

Permitir que el contenido abarque columnas y coloca elementos en el diseño de albañilería

No hay motivo para no tener contenido que abarque columnas en una especificación de albañilería separada. Esto podría usar una propiedad masonry-track, que es una abreviatura de masonry-track-start y masonry-track-end, ya que solo tienes una dimensión para abarcar elementos en un diseño de mampostería.

.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 */
}

Submampostería o subred con carriles de mampostería

Esto podría admitirse con una especificación de albañilería independiente, una vez más con la condición de que no se permitan combinaciones de pistas de tamaño intrínseco y fijo. Tendrá que definir exactamente cómo se ve. No vemos razones para que esto no funcione.

Conclusión

Nos encantaría llegar a un punto de una especificación que se pueda enviar de manera interoperable. Sin embargo, queremos hacerlo de una manera que funcione bien ahora y en el futuro, y en la que los desarrolladores puedan confiar. La única forma de abordar los problemas de rendimiento descritos es hacer que el segundo problema (el de tener partes de la red ilegales en la mampostería) empeore. No creemos que esa sea una buena solución, en especial cuando es posible tener todas las funciones de cuadrícula que deseas y, al mismo tiempo, mantener las cosas que son diferentes y claramente separadas.

Si tienes algún comentario, únete a la conversación en el Error 9041.

Gracias a Bramus, Tab Atkins-Bittner, Una Kravets, Ian Kilpatrick y Chris Harrelson por revisar esta publicación y los debates que la informaron.