Chrome y Safari se están peleando por el futuro del desarrollo web y por un tema bastante interesante.
Os voy a enseñar y explicar la idea de Safari y la idea de Chrome y a ver cuál de las dos os convence más.
Por un lado tenemos Safari, quieren sacar el masonry layout.
El masonry layout básicamente es esto, es como columnas, como si fuese un Pinterest,
y esto sería hacerlo, también lo hablan, se le llaman el layout encascada, no tiene nada que ver con masonería.
Básicamente sería algo muy parecido a Pinterest.
¿Cuál es el problema? Pues que esto desde hace mucho tiempo está disponible en Firefox detrás de un flag,
pero es el momento de ir hacia adelante.
Aquí podemos ver las demos y vas a ver que ahora a mí no me funciona.
¿Ves? Para ver estas demos tienes que utilizar Safari o Firefox con un feature flag.
Entonces, para ver la demo podríamos intentar, no sé si poner Safari Technology o Firefox.
Vamos a intentar Firefox, que creo que es más fácil con el feature flag.
¿Vale? Feature flag, masonry, vamos a poner esto por aquí, pero os lo voy a enseñar.
¿Veis aquí que se ven estos huecos? ¿Veis que aquí se ven huecos? Se ve mal, se ve mal.
Entonces, si aquí vamos a activar el, no sé cómo, a ver, Firefox, flags, ¿cómo se ponen los flags?
Editor de configuración, no sé qué, about config, eso, about config.
Es que ya, aceptar el riesgo y continuar, aceptar todo el riesgo.
Y aquí vamos a buscar masonry, ¿ves? Aquí lo tenemos false, vamos a ponerlo true.
Y ahora, mira, ya está, ya lo tenemos. ¿Vale? Para que veáis la diferencia.
Esto como se ve aquí en Firefox, ¿veis la diferencia?
Entonces alguien dirá, pero esto se puede hacer también en Chrome y no sé qué, con column counts y no sé qué.
No exactamente, porque esto, lo bueno que tiene es que va de arriba a abajo, izquierda a derecha, o sea, no, de izquierda a derecha, arriba a abajo.
O sea, este sería el primer elemento, segundo, el tercero, el cuarto, el quinto, y automáticamente detecta los huecos para poder hacer que queden bien.
Y esto, pues, normalmente se necesita a diferentes bibliotecas, porque las imágenes son dinámicas.
Tú con un bento grid puedes hacerlo, pero tú le tienes que indicar cuál es el tamaño.
Fijaos aquí que todas las imágenes son dinámicas y, por lo tanto, se van a ir reajustando donde queden mejor.
Fijaos que la que queda aquí detrás a veces es una, a veces es otra.
O sea, esto es más complicado de lo que parece, ¿vale? Bastante más complicado de lo que parece.
Igualmente, el tema es que esto, pues, hay diferentes demos.
Por ejemplo, esto también estaría hecho así.
También teníamos un periódico, que esto puede ser interesante para hacer un periódico también.
Para un museo, fijaos aquí con un museo.
Esto parece fácil, pero tiene su historia.
Y durante mucho tiempo se ha hecho con masonry, library, javascript.
Con librerías, como por ejemplo esta.
Esta es una muy mítica.
Entonces, lo que dice Safari es, lo que dice Safari es, a mí me gusta esta API.
Que ponemos display grid, le decimos grid template columns.
Y en el grid template rows le decimos masonry.
Bueno, esta es la apuesta tanto de Firefox como de Safari.
Pero, pero, Chrome no.
De hecho, se están peleando.
Aquí lo tenemos.
Una propuesta alternativa para la mampostería de CSS.
Gracias, API Cloud Translation, por hacer una traducción tan rara.
Dice, el equipo de Chrome desea ver una implementación.
El equipo de Chrome, obviamente, no le gusta.
Sin embargo, creemos que implementarla como parte de la especificación de la cuadrícula, o sea, de grid de CSS, sería un error.
Como lo ha propuesto WebKit.
Sería un error.
O sea, que están peleados.
Básicamente, no están de acuerdo.
El objetivo de esta aplicación es explicar por qué en Chrome nos preocupa la implementación de la albañilería.
Entiendo que son masonry, ¿vale?
Esa traducción de masonry.
Como parte de la especificación de diseño de cuadrícula de CSS.
El equipo Chrome le interesa mucho desbloquear masonry.
Agregar masonry a la especificación es problemático por motivos no relacionados con el hecho de si crees o no que sea interesante.
Y la definición fuera de la especificación no impide el uso de varios tamaños.
Lo que dicen, básicamente, la propuesta sería esta de aquí.
Display masonry, masonry template tracks, ¿vale?
Repeat, autofilm, inmax, gap, tal.
Y aquí se puede ver mejor con los números.
¿Veis los números que van?
Uno, dos, tres, cuatro, cinco, seis.
O sea, intenta ir de izquierda a derecha siempre y cuando pueda caber ese número justamente ahí.
O sea, los pone bastante cerca.
Ya veis que no va de arriba a abajo, sino de izquierda a derecha y luego de arriba a abajo.
O sea, que es bastante interesante por eso.
Porque se podría hacer con el column, se puede hacer algo similar, pero no funciona igual.
Y entonces, lo que dice la gente de Chrome es que quieren un nuevo display masonry.
O sea, tendríamos display inline, inline block, el block, el flex, inline flex, el grid y el masonry.
Y el none también.
Bueno, pues hay otro.
No sé si lo sabíais.
Aparte está el display table, que este sí que es bastante conocido.
Pero hay otro que se llama flow root.
El flow root.
Hostia, el flow root.
No está muy utilizado, pero si no me equivoco.
Mira, este tampoco, este no lo conocía.
Este run in, este es nuevo.
Ah, el subgrid, el subgrid, claro.
¿Ruby?
¿Cómo?
¿Cómo?
Madre mía.
No vamos a mirar más.
No vamos a mirar más, tengo miedo.
Pues esta es la pelea.
Mi pregunta del millón para vosotros es, ¿cuál os gusta más?
¿Display masonry?
¿O os gusta más que sea display grid?
Y el masonry tener que ponerlo como uno de los valores del template rows.
¿Cuál os gusta más?
Bueno, no sé si está feral.
Feral, ponle una encuesta.
Ponle una encuesta para que lo pongan.
Display Pinterest.
Ese sería.
Porque la verdad es que esta va a ser una pelea bastante importante.
Display grid o un nuevo display.
Me gusta más mi prima ya, pero tu prima no hace el masonry.
Bueno, igual sí que lo hace, pero no lo quiero ver con mis ojos.
Con grid ya que podrás controlar el número de columnas.
Bueno, el número de columnas también lo puedes controlar aquí.
Fíjate que aquí el masonry template tracks, como pone aquí, aquí también.
Se supone que aquí, fíjate que pone autofill, min max, no sé qué es lo cuánto.
Pero tú aquí podrías poner el número de columnas también.
Lo que pasa es que en este ejemplo encaja con eso.
Pero ves, aquí podrías hacer más cosas.
Fíjate que aquí podrías hacer diferentes.
O sea, la idea es que con el masonry template tracks podrías hacer cosas así de chulas.
La verdad, es complicado, es complicado.
Pero yo me voy a mojar.
Me voy a mojar.
Va a ser polémico, va a ser polémico porque no es la que está ganando.
Y es que, amigos, yo en este punto, visto lo visto, creo que me quedo con la gente de Chrome.
Y os voy a explicar por qué.
El problema es, me da la sensación que en grid, aunque creo que tiene sentido,
sí que me parece que está puesto un poco, como que lo complica un poco demasiado ya grid.
Y no me gusta mucho el tema de que sea grid template roads más sonry.
Es como que me choca un poco.
Y las posibilidades, además, de cómo gestionar esto, me parece que complica demasiado grid y ya es demasiado complicado.
No soy muy fan de tener un nuevo display, pero lo puedo llegar a entender.
Igual que tenemos display flex, display grid.
Y es verdad que masonry no deja de ser un tipo de caja un poco especial también,
que está cambiando el comportamiento de las cajas.
Y aunque se parece a grid, lo cierto es que no es exactamente grid.
Porque el cómo funcionan los tracks, que me gusta bastante el nombre de track, pues le veo bastante sentido.
Pero fijaos que además, ves, masonry track, me gusta bastante el hecho de no mezclar tanto grid con esto.
Como no es exactamente igual a grid, aunque se parece, pues creo que puede tener sentido este display masonry.
Y además creo que mejorará un montón el cómo se aprende, el cómo se utilizaría.
O sea, sería algo totalmente separado y que por lo tanto se podría como adaptar de una forma sin tener que mezclarlo todo en grid.
Entonces, es mi opinión.
No me patrocina Chrome.
¿Cuánto te pago?
No me pago, no me pago.
Madre mía.
¿Pero por qué?
¿Por qué?
¿Por qué?
Siempre que doy mi opinión tiene que haber pagado alguien.
Dice, ¿cuándo va a estar disponible?
Dice Fairdroid.
Esto estará disponible cuando se pongan de acuerdo.
¿Cuál es el problema de esto?
El problema de masonry es que no se han puesto de acuerdo nunca.
Nunca se ha puesto de acuerdo Chrome con Safari y ahora lo estáis viendo.
O sea que nada, hasta que no se pongan de acuerdo no lo vamos a poder ver hecho.
Y esta es la gran guerra que tienen Safari con Chrome.
Y bueno, ojalá algún día lo arreglen porque eso significará que entonces vamos a tener por fin masonry en CSS.
Me huele una cosa.
Lo van a hacer cada uno de una forma.
Me da la sensación.
¿Por qué?
Porque hace mucho, mucho, mucho tiempo que no se ponen de acuerdo.
Me da la sensación que al final cada uno lo va a hacer de una forma y me daría mucha pena.
Porque ya, ya, yo ojalá que no.
¿Qué propone Mozilla?
Mozilla se quedó con este.
Con este es el que se quedó, Mozilla.
Y la gente de Chrome ahora ha propuesto uno nuevo.
Pero yo creo que el de Mozilla ya hacía mucho tiempo.
Yo creo que estaría bien que se pusieran de acuerdo y que hagan algo.
Pero no sé, no sé, no sé, no sé qué pueden hacer, no sé qué pueden hacer.