La diferencia para lograr que nuestro grid sea responsivo es que al elemento base donde tenemos la clase de flex le agregamos flex-wrap con esto logramos que cuando uno de los elemento exceda el tamaño, ese elemento pase al siguiente renglón. Y con el uso de las pseudo-classes responsivas de sm, md, lg y xl logramos el numero de columnas deseada por tamaño de pantalla.
Al igual que con el grid responsivo anterior, agregamos en el elemento base de flex la clase de flex-wrap y de igual manera hacemos uso de las pseudo-classes responsivas de sm, md, lgy xl.
Crear grids en Tailwind usando flex es muy sencillo.
En flex podemos hacer uso de las clases de dimensiones porcentuales, algunos ejemplos son:
w-1/2, w-2/3, w-3/4, w-5/6, w-7/12,.
Estas mediciones nos facilita poder crear columnas de 2, 3, 4, 5, 6 y 12 columnas y sus combinaciones.
Por qué los Framewoks css no usan display grid? Siempre crean sus propias grillas, creo que es mejor usar grid de forma nativa así se use un framework, resulta más facil y no llenamos el HTML de div
Probablemente se deba a que al usar sus propias grillas ya tienen la lógica que hace que esas grillas se adapten de forma responsiva.
Es decir, si usaran display grid, entonces tendrías que hacer otro display grid para otro tamaño de media query, y sería muchísimo más trabajo.
Al usar una grilla hecha por un framework, ya no te tienes qué preocupar por modificar el display grid cuando el usuario usa otro media query, porque la lógica ya está hecha por el framework.
Estaba pensando lo mismo. Quiero crear un panel de administración para una plataforma y por eso empecé con el curso de Tailwind CSS, porque he visto que es el mejor para el tema del UI/UX. Pero creo que la estructura principal la voy a manejar con CSS nativo y usando display:grid, aprovechando el superpoder de los templates.
Ya para la organización de la información si usaría el sistema de grid del framework como tal.
Se podría, pero Tailwind directamente desaprueba esto debido a que se pierde el enfoque del framework, la idea es no salir del markup (Html). Pero, en caso de que sea totalmente necesario, si, se podrían agregar los estilos en la misma hoja donde agregaste las directivas de @tailwind. Si haces esto, te recomiendo usar la directiva @layer (esto te permite añadir reglas de estilos al final de alguna de las directivas que importaste), de esta manera:
Esto básicamente lo que hace es añadir las reglas que coloques dentro AL FINAL del bloque en el que decidiste que van a pertenecer, en este caso, en la hoja compilada vas a poder notar que .componente estaría declarado después de components pero antes que utilities.
Ahora, podrás estarte preocupando, ¿por qué no simplemente colocamos los estilos después de @tailwind components? Bueno, principalmente porque es una buena práctica, además de que es más tedioso en caso de que la cantidad de estilos que escribas entre estas directivas sea mucho porque las tres directivas deberían permanecer juntas.
Igualmente, una recomendación es que si escribirás directamente desde las hojas de estilo uses la directiva @apply para poder insertar utilidades de Tailwind ahí mismo, a continuación de ilustro un ejemplo:
Ahora, otra vez te podrías estar haciendo una pregunta, ¿por qué no simplemente escribimos reglas Css nativamente? Bueno, el principal objetivo de Tailwind es mantener un "design system" que en palabras fáciles significa mantener una uniformidad donde si a un componente la asignamos la clase font-thin tenga el mismo valor que cualquier otro elemento donde esta clase es aplicada, digo esto porque muchas veces solemos descartar la uniformidad inconscientemente y hay elementos que tienen un, en este caso, font-weight distinto entre si aún cuando son elementos similares, esto porque se nos olvida los valores que debemos seguir (en casos donde los estilos son muy extensos).
Espero esta explicación haya resuelto tú duda, quedo al pendiente de tú respuesta, ¡un saludo! :D
