Es posible que haya oído hablar de mampostería CSS. Incluso podrías estar involucrado en el debate en curso sobre cómo construirlo, con dos propuestas importantes sobre la mesa, una del equipo de Chrome y otra del equipo de WebKit.
Estas dos propuestas en competencia son interesantes por derecho propio. Chrome lanza su implementación No hace mucho, y WebKit publicó posteriormente un artículo detallado. Indique su posición (de La tercera sugerencia del Grupo de Arquitectura Técnica).
Recapitularemos algo de eso en este artículo, pero lo que es más interesante para mí es que todo el proceso es una buena ilustración de cómo el Grupo de Trabajo CSS (CSSWG), los navegadores y los desarrolladores se unen en torno a los estándares funcionales de CSS. Hay muchos factores a considerar para una característica, como la implementación técnica y la compatibilidad con versiones anteriores. Pero también puede ser un poco político.
Eso es exactamente lo que quiero hacer aquí: mirar las discusiones sobre CSS Masonry y lo que pueden enseñarnos sobre el desarrollo de nuevas funciones de CSS. ¿Qué hace el CSSWG? ¿Qué impacto tiene el navegador? ¿Qué se puede aprender de la forma en que evolucionaron las características en el pasado?
revisión de albañilería
Los diseños de mampostería difieren de diseños como Flexbox y Grid, que apilan elementos de tamaño desigual a lo largo de una sola pista que se ajusta automáticamente en varias filas o columnas según la dirección. Se llama «Diseño de Pinterest» por razones obvias, es el sello distintivo del feed de Pinterest.
Podríamos profundizar más aquí, pero discutir específicamente CSS Masonry no es el punto. Cuando Masonry entró en las discusiones del grupo de trabajo de CSS, los primeros prototipos provinieron de Firefox en 2019, basados en un borrador inicial que integraba el comportamiento de Masonry directamente en Grid.
Luego, el equipo de Chrome lanzó un nuevo display: masonry valor, considérelo como un modelo de diseño único. Creen que Masonry tiene un diseño completamente diferente al de Flexbox y Grid y merece tener su propio diseño. display valor. La configuración predeterminada de Grid no coincide con la forma en que funciona Masonry, entonces, ¿por qué obligar a los desarrolladores a aprender un montón de sintaxis adicional de Grid? Chrome impulsó la idea y Prototipado en Chrome 140:
.container {
display: masonry;
grid-template-columns: repeat(auto-fit, minmax(160px, 1fr));
gap: 10px;
}Al mismo tiempo, el equipo de WebKit propuso que la mampostería debería ser un subconjunto de Grid en lugar de su propio display tipo. Reconocieron una nueva dirección Basado en las recomendaciones del Grupo de Arquitectura Técnica (TAG) del W3C, esta recomendación gira en torno a una Proceso del proyecto unificado flex-flow y grid-auto-flow en un conjunto de propiedades. en lugar de escribir display: masonrypersistirás display: grid y usar uno nuevo item-flow Taquigrafía para colapsar filas o columnas en un diseño de estilo mampostería:
.container {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
item-flow: row collapse;
gap: 1rem;
}El debate aquí realmente se reduce a los modelos mentales y a cómo se ve la masonería. WebKit lo trata como una extensión natural de Grid, en lugar de como un sistema completamente nuevo. La idea es que los desarrolladores no necesiten aprender modelos completamente nuevos cuando la mayoría de ellos ya existen en la red. y item-flowno le estás diciendo al navegador «este es un sistema de diseño completamente nuevo», sino que estás ajustando más o menos la forma en que los elementos fluyen en un contexto específico.
Cómo evolucionaron las características de CSS
Este tipo de negociación no es nueva. Tanto Flexbox como Grid pasaron por años de borradores competitivos antes de convertirse en las especificaciones que utilizamos hoy. Flexbox, en particular, tuvo un lanzamiento difícil a principios de la década de 2010. Quienes estaban en las trincheras en ese momento tal vez recuerden Aparecen varias sintaxis conflictivas al mismo tiempo. A la versión inicial le faltaban errores y los navegadores implementaron las características de diferentes maneras, lo que resultó en todo tipo de cosas como propiedades propietarias, versiones experimentales y diferentes convenciones de nomenclatura que hicieron que la curva de aprendizaje fuera bastante pronunciada, incluso Uso tipo Frankenstein en algunas situaciones para obtener la mayor compatibilidad con el navegador.
En otras palabras, Flexbox (ni Grid, en realidad) no disfruta de una publicación fluida, pero hemos llegado a un punto en el que las implementaciones del navegador pueden interoperar entre sí. Para desarrolladores como nosotros, que a menudo hacemos malabarismos con el soporte inconsistente para varias funciones, esto es un gran problema. ups, Rob O’Leary publicó recientemente sobre la madriguera del conejo por la que viajó Intenta usar text-wrap: pretty En su trabajo, esto se considera un apoyo «básico» que está «ampliamente disponible».
Pero estoy divagando. Vale la pena señalar que Flexbox enfrentó desafíos únicos en sus inicios y la masonería se ha beneficiado enormemente de esas lecciones. Me comuniqué con los miembros del CSSWG Pestaña Atkins——Amargado Porque estaban muy involucrados en la edición. Especificaciones de la caja flexible.
«Flexbox fue el primer algoritmo de diseño moderno; cometimos muchos errores y pasos en falso mientras lo escribíamos porque estábamos tratando de descubrir cómo deberían funcionar los modelos de diseño modernos».
En otras palabras, Flexbox es una especie de canario en la mina de carbón porque CSSWG tiene en cuenta lo que debería lograr la sintaxis de diseño CSS moderna. Esto facilita enormemente el trabajo de definición de grillas CSS, ya que se han resuelto muchas cuestiones fundamentales como órbitas, tamaños intrínsecos y proporciones. Atkins-Bittner explicó además que el proceso de especificación de la red también obligó al CSSWG a reconsiderar algunas opciones de diseño para Flexbox durante el proceso.
«Descubrimos que si queríamos que muchas de las decisiones de Flexbox se aplicaran de manera más amplia, necesitábamos cambiarlas».
Esto también explica por qué Flexbox ha experimentado Modificado varias veces Después del lanzamiento inicial.
También destaca otro punto clave: Las características de CSS son siempre en constante evolución. El debate y la iteración tempranos son fundamentales porque reducen la necesidad de realizar cambios importantes. No obstante, Flexbox todavía tiene algunos errores (lo que realmente sucede) es ampliamente utilizado. Los navegadores han implementado ampliamente sus métodos y la especificación los ha alcanzado, al tiempo que intentan establecer un lenguaje coherente para ayudar a los agentes de usuario y a los desarrolladores a implementar y utilizar estas funciones, respectivamente.
Todo lo cual quiere decir: la mampostería está en un lugar mucho mejor que cuando nació Flexbox. Se beneficia de más de 15 años de contribuciones a Flexbox y Grid por parte del CSSWG, navegadores y desarrolladores. Las discusiones ahora giran menos en torno a arreglar detalles no especificados y más en opciones de diseño de alto nivel. Por lo tanto, a Masonry se le ocurrió la novedosa idea de combinar la funcionalidad de Flexbox y Grid en una nueva propuesta de Item Flow.
Muy desordenado. Y es raro. Pero así es como se hace.
El papel del CSSWG
Llegar a este punto requiere un proceso. En CSS, este proceso ocurre a través de grupos de trabajo. El Grupo de Trabajo CSS (CSSWG) se basa en el consenso: los miembros debaten abiertamente, sopesan los pros y los contras y presionan a los navegadores para que lleguen a un consenso.
Miriam Susanaun experto invitado del CSSWG (y Alumnos de consejos CSS), describe este proceso:
«La organización opera según un modelo de consenso, por lo que, en última instancia, todos tienen que llegar a un acuerdo, o al menos acordar no bloquear el camino más popular a seguir».
Pero el consenso sólo se aplica a las normas. Los navegadores aún deciden cuándo y cómo lanzar estas funciones, continuó Suzanne:
«Los navegadores deciden por sí mismos qué tan estrictamente seguir la especificación, a veces lanzando características que aún no han sido especificadas completamente. Esto puede llevar a que el grupo decida años más tarde cambiar la especificación para que coincida con lo que los navegadores realmente implementan».
Entonces, si bien el CSSWG facilita la discusión sobre las características, en realidad no impide que los navegadores publiquen esas características, y mucho menos cómo se implementan. Este es un sistema impulsado por el consenso, pero el consenso se refiere únicamente a la publicación de especificaciones. En la práctica, el impulso puede cambiar si un proveedor es el primero en lanzar o crear un prototipo de una característica.
Pero en la mayoría de los casos, el proceso de adopción de especificaciones da como resultado una propuesta general más sólida. Cuando se publican funciones, la idea es que se hayan debatido exhaustivamente, lo que en teoría reduce la necesidad de revisiones importantes que podrían conducir a cambios importantes más adelante. La compatibilidad con versiones anteriores siempre está a la vanguardia de las discusiones del CSSWG.
Los comentarios de los desarrolladores también juegan un papel importante, aunque no existe una forma unificada de solicitar, recopilar o utilizar comentarios. Para el CSSWG, CSSWG-Repositorio GitHub borrador es la principal fuente de comentarios y debates, mientras que el navegador también ejecuta sus propias encuestas y recopila comentarios a través de otros canales, como Chrome grupo de discusión técnica y kit web lista de correo.
El panorama más amplio
Los navegadores se dedican a dar forma a nuevas funciones. También les conviene por varias razones. Proponer nuevas ideas les da un asiento en la mesa. La creación de prototipos de nuevas funciones entusiasma a los desarrolladores y ayuda a perfeccionar aún más los casos extremos. La implementación de nuevas funciones (especialmente la primera) les otorga una ventaja competitiva en el mercado de consumo.
Dicho esto, crear prototipos de características antes de llegar a un consenso es un paseo por la cuerda floja.
Aquí es donde la Masonería vuelve al panorama general. Chrome lanza un prototipo de función que depende en gran medida de las primeras propuestas de nuevas funciones display: masonry valor. Otros navegadores aún no han lanzado prototipos de la competencia, pero han discutido públicamente sus posiciones. Como lo hace WebKit en una publicación de blog de seguimiento.
A primera vista, esto podría sugerir que Chrome está tomando medidas drásticas para inclinar la balanza a su favor. Pero hay mucho que me gusta de la función de prototipo, ya que demuestra su uso en el mundo real al permitir a los desarrolladores experimentar temprano.
Atkins-Bittner lo explica bien:
«La creación de prototipos antes de alcanzar el consenso es una parte importante de la creación de consenso. Obtienes retroalimentación temprana sobre la implementación y te concentras más en el problema (ingenieros de implementación en lugar de solo autores de especificaciones)».
Este compromiso «suave» impulsa la conversación y deja espacio para cambiar de dirección si es necesario en función del uso real.
Pero aquí también hay claramente tensiones. Los navegadores pueden ser los guardianes de los estándares y funciones web, pero en última instancia siguen siendo empleados por las grandes empresas que venden sus productos. Es fácil volverse cínico. Y la política.
Pero, en teoría, permitir que los navegadores adopten funciones voluntariamente les da a todos una opción: los navegadores compiten en el mercado en función de las funciones que implementan, los desarrolladores obtienen nuevas funciones que hacen avanzar la web y todos pueden elegir el navegador que mejor se adapte a sus necesidades de navegación.
Sin embargo, si una empresa controla el acceso a una gran cantidad de usuarios, estas opciones pueden parecer menos alcanzables. La formación de normas a menudo tiene que ver tanto con las fuerzas del mercado como con las ventajas tecnológicas.
Dónde estamos ahora
En última instancia, los estándares están determinados por una combinación de políticas, compensaciones técnicas y comentarios de los desarrolladores. El consenso es confuso y rara vez implica que una de las partes «gane». Con Masonry, puede parecer que Google se salió con la suya, pero en realidad los resultados reflejan las aportaciones de ambas propuestas, así como el pensamiento de la comunidad en general.
Al momento de escribir este artículo:
- La mampostería será nuevo tipo de visualizaciónpero debe contener la palabra «grid» en el nombre. Las palabras clave exactas todavía se debaten.
- El CSSWG ha decidido proceder con la propuesta
**item-flow**método. - La cuadrícula se utilizará para diseñar la plantilla y colocar elementos explícitamente dentro de ella.
- Algunos detalles, como la posible sintaxis abreviada y los valores predeterminados de la lista de canciones, aún se están discutiendo.
lectura adicional
Este es un tema enorme y profundiza mucho más que lo que cubriremos aquí. Al momento de escribir este artículo, ha surgido contenido adicional que bien vale la pena dedicarle tiempo para conocer las diversas ideas y perspectivas sobre el proceso de estándares CSS:
- Alex Russell postal Sobre el proceso de adopción de estándares en los navegadores.
- Rob O’Leary artículo sobre la lucha
text-wrap: prettyexplicando que “línea de base” no siempre significa apoyo consistente en la práctica. - David Bushell pedazo Acerca de WHATWG. No está relacionado con el CSSWG, pero cubre discusiones similares sobre políticas de navegadores y consenso de estándares.
