-
reset
- Al principio copió unas 200 líneas de los preflight styles de Tailwind desde
tailwind.css
- Llevaba mucho tiempo acostumbrada al reset de Tailwind, y la regla que aplica
box-sizing: border-box a todos los elementos hace que el ancho del elemento incluya el padding
* { box-sizing: border-box; }
- Es posible que también dependa inconscientemente de otras reglas de reset como
html {line-height: 1.5;}, y escribir CSS sin esas reglas parece requerir una gran adaptación
-
components
- La mayor parte del CSS está organizada en archivos por componente, de manera parecida a como se trabaja con componentes de Vue o React
- Cada componente tiene una clase única, para que el CSS de un componente no sobrescriba el de otro
- En la práctica, alrededor del 80% del CSS que quiere cambiar está dentro de archivos de componentes, así que al editar un componente de 100 líneas solo necesita pensar en esas 100 líneas
- Por ejemplo, un componente
.zine podría tener un HTML como este
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
- En CSS, selectores anidados agrupan dentro del componente estados como
.horizontal, .vertical y :hover
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
- No se bloqueó programáticamente la interferencia entre componentes como sí ocurriría con Web Components o
@scope, pero seguir una convención ya da la sensación de una gran mejora
-
colours
- En
colours.css se agrupan variables CSS que pueden usarse cuando haga falta
- Como el color es difícil y en esta refactorización no quería volver a replantear su uso, mantuvo el enfoque existente
- La única regla es listar en este archivo todos los colores usados en el sitio
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
-
font sizes
- En Tailwind solo había que elegir escalones de tamaño como
text-lg, xl o 2xl, sin necesidad de recordar si se usaba em, px o rem
- Para conservar eso en CSS vanilla, definió variables de tamaño tomadas de Tailwind
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
- El tamaño tipográfico se define con variables; es un poco más verboso que Tailwind, pero por ahora le resulta satisfactorio
h3 {
font-size: var(--size-lg);
line-weight: var(--line-weight-lg);
}
-
utilities
- Elementos repetidos en varios componentes, como botones, se clasifican como utilities
- Algunas clases utilitarias, como
.sr-only para elementos que solo deben mostrarse a usuarios de lectores de pantalla, se copiaron de Tailwind
- La idea es mantener esta zona pequeña y cambiarla con cuidado
-
base
- Los estilos “base” son estilos que se aplican directamente a todo el sitio
- Como no hay suficiente confianza para imponer muchos estilos a todo el sitio, esta área se mantiene muy pequeña
- Por ahora, las únicas reglas que parecen adecuadas son para
<section> y a, y la de <section> podría cambiar más adelante
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
- Lo más fácil parece ser dejar los estilos base casi vacíos al principio y, cuando aparezca algo realmente común, moverlo desde los componentes a base con un enfoque de abajo hacia arriba
-
spacing
- La forma de gestionar
padding y margin todavía no está completamente definida
- Cuando usaba Tailwind, iba agregando
padding y margin de forma improvisada en distintos lugares hasta que se veía como quería, y ahora busca un método más sistemático
- Por ahora intenta que, en la medida de lo posible, los componentes de layout externos sean responsables del espaciado
- Si se quiere dejar una separación uniforme entre hijos dentro de un
<section> con varios hijos, puede usarse esta regla
section > *+* {
margin-top: 1rem;
}
-
responsive design
- En Tailwind usaba mucho una sintaxis basada en media queries como
md:text-xl, que aplica el estilo text-xl a partir de cierto tamaño
- Ahora intenta crear layouts con CSS grid más flexibles y que no dependan tanto de breakpoints
- Con
auto-fit, una pantalla grande puede usar automáticamente dos columnas y una pantalla pequeña una sola
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
-
build system
- Durante el desarrollo no hace falta un sistema de build aparte
- CSS tiene una instrucción
@import integrada, así que los archivos pueden separarse e importarse
@import "reset.css";
@import "typography.css";
@import "colors.css";
- CSS también incluye selectores anidados de forma nativa
.page {
h2 { ...}
}
- Si se quisiera empaquetar archivos CSS para producción, se puede usar
esbuild
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
- En general evita usar sistemas de build para CSS y JS, pero considera aceptable
esbuild porque se basa en estándares web y es un binario estático en Go
- Sobre
esbuild, escribió en 2021 un artículo relacionado con esbuild y Vue
3 comentarios
¿No mejora un poco más al cambiar a zero-config?
Comentarios de Hacker News
He enseñado durante mucho tiempo HTML semántico y marcado accesible, y también he trabajado bastante con sitios y apps para lectores de pantalla; el mayor problema de Tailwind es que invierte el orden en que debes pensar HTML y CSS
HTML sirve para expresar el significado del documento, así que hay que empezar por ahí y luego aplicar estilos con CSS. Si por razones de estilo necesitas elementos adicionales, puedes usar
divospan, pero primero deberías preguntarte si existe un elemento mejorTailwind empuja a los desarrolladores a un enfoque donde CSS va primero, haciendo que antes piensen en la clase de Tailwind que quieren usar y luego agreguen otro
dival DOM solo para poder aplicar esa claseLa capacidad de un desarrollador web debería incluir crear HTML y CSS que siga siendo legible en el futuro, usable para todos los usuarios y más o menos alineado con las especificaciones de HTML/CSS, y en ese aspecto Tailwind perjudica la formación. Incluso el primer ejemplo del sitio de Tailwind usa solo
divyspan; ha sido una mala enseñanza para desarrolladores nuevos y creo que también contribuyó a la tendencia de que los LLM produzcan sopa de divs si no se les da instrucciones adicionalesCualquier herramienta se puede usar mal, y Tailwind no es la excepción. Llevo unos 20 años usando CSS y también he usado Less, SASS/SCSS, Stylus y PostCSS, pero en los últimos años me quedé con Tailwind precisamente porque permite un estilo de aplicación más sólido
No hace falta crear abstracciones excesivas de estilos/clases, poner los estilos directamente junto al marcado afectado reduce la carga cognitiva, también disminuyen los cambios accidentales causados por selectores laxos y depurar se vuelve más fácil. Salvo en sitios/apps simples, muchas veces una base de código con Tailwind es menos compleja y menos frágil que una base con un framework CSS personalizado
Si además consideras escalas consistentes de tipografías, colores y tamaños, bundles más pequeños, consistencia entre desarrolladores que conocen Tailwind, un ecosistema sólido y familiaridad con los LLM, sigue siendo una excelente opción para muchos equipos. Al final, como la mayoría de las herramientas, todo depende de quién la use: se puede usar bien o mal
Veo el caos de HTML/CSS/JS como un mal necesario cuando trabajas para navegadores, y para mí no deja de ser la capa de presentación. En el trabajo pongo mucho más énfasis en la corrección del esquema de base de datos o de la lógica de negocio del backend
Si con una capa de presentación desordenada pero mínima consigo un código razonablemente mantenible, me basta, y para ese objetivo Tailwind encaja muy bien. Los LLM lo escriben bien, los desarrolladores nuevos lo entienden rápido y después también es relativamente fácil de leer y modificar
Estoy completamente de acuerdo en que un proyecto con Tailwind no es la mejor forma de que un desarrollador nuevo aprenda HTML/CSS, pero prefiero que los desarrolladores nuevos se enfoquen en un buen esquema de base de datos, APIs intuitivas, lógica de negocio testeable, etc.
No hay nada en Tailwind que obligue a usar
divyspanen lugar de etiquetas HTML apropiadasDocumento e interfaz no son lo mismo, y Tailwind tiene mucho más sentido en una interfaz. Puedes usar Tailwind en la interfaz y selectores HTML de alcance limitado para otro tipo de contenido
Que Tailwind sea alrededor de 4 veces más rápido que escribir una base de CSS compleja y prácticamente no tenga overhead sigue siendo una ventaja, independientemente de cómo lo evalúes
En resumen, es una forma de escribir CSS según el orden de especificidad:
/scss/
├── 1-settings. <- configuración global
├── 2-design-tokens <- tipografías, colores, espaciado, etc.
├── 3-tools <- mixins de Sass, funciones CSS, etc.
├── 4-generic <- resets, box sizing, normalización, etc.
├── 5-elements <- estilos base de encabezados, botones y enlaces
├── 6-skeleton <- grid de layout, etc.
├── 7-components <- cards, carruseles, etc.
├── 8-utilities <- utilidades y clases helper
├── _shame.scss <- hacks para arreglar después
└── main.scss
ITCSS prácticamente elimina las peleas por especificidad en una base de código CSS. Normalmente, el único lugar donde entra
!importantes la capa de utilidades[1]: https://matthiasott.com/notes/how-i-structure-my-css
Si ves las librerías de componentes, incluso incluyen atributos
aria: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...Salvo que sea algo más parecido a un folleto digital, como una landing page, siempre empiezo por el marcado y luego le agrego clases CSS
Dos cosas buenas de Tailwind son que ya hay mucha información de clases en los datos de entrenamiento de IA y que no hay conflictos de estilos
Por eso, cuando la IA crea estilos nuevos, no necesita consultar una hoja de estilos existente, lo cual ayuda con la gestión de contexto
Con CSS personalizado, la IA necesita leer la hoja de estilos existente para reducir conflictos o duplicación, y las hojas de estilo grandes pueden ocupar demasiado espacio en la memoria de la IA, lo cual puede volverse un problema
Me gusta muchísimo cómo escribe Julia Evans
Escribe desde un lugar de vulnerabilidad y honestidad. Mucha gente escribe intentando parecer inteligente, pero Julia escribe con la actitud de “yo tampoco lo sé todo, pero encontré algo que quiero compartir”. Se siente casi como si estuviera compartiendo algo con personas que quiere, aunque no la conozca en persona
En la última Strange Loop presentó junto con Randall Munroe; había gente esperando para hablar con él después de la charla, pero yo estaba esperando para hablar con Julia. De verdad me da pena que pareció no entender mi broma sobre reescribir scripts de bash en Perl
No soy Julia, pero tengo casi la misma filosofía respecto a charlas públicas o presentaciones, y he tratado de inculcársela a colegas a quienes les cuesta presentar. Poder compartir con colegas y seres queridos conocimientos con los que estoy un poco más familiarizado, y que pueden ayudarles, es un gran privilegio
CSS Modules es una solución más simple al problema de la cascada. Genera nombres de clase únicos para evitar conflictos [1]
También evita dos grandes desventajas de Tailwind: legibilidad [2] y soporte de herramientas. En particular, me parece que el soporte para depurar y experimentar de forma interactiva en Chrome y FireFox DevTools es mejor
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
Lo que siempre me ha impresionado de Tailwind es que casi todos los argumentos de sus defensores terminan reduciéndose a “nunca aprendí CSS por encima de un nivel junior”
Es muy común escuchar cosas como “sin Tailwind, un archivo CSS grande y desordenado crecerá sin control y se llenará de código viejo y de
!important”, pero CSS también es una habilidad, como cualquier otra competencia técnicaSi solo aprendes lo suficiente para que se vea más o menos bien y te limitas a parchear, tu ambición supera muy rápido tu capacidad de mantener el código ordenado
Es realmente frustrante cuando hablas con alguien sobre Tailwind y CSS, y te das cuenta de que no solo no sabe qué significa “cascada”, sino que nunca se le ocurrió que ese concepto pudiera ser útil en el contexto de una hoja de estilos
He usado mucho CSS desde los 90, revisé Tailwind y, una vez que lo entendí, empecé a evitar CSS puro la mayor parte del tiempo. En cierto sentido, cambias un desastre por otro, pero personalmente prefiero lidiar con sopa de clases localizada que con una cascada superpuesta y contradictoria repartida entre varios archivos
Ambas cosas se pueden implementar de forma limpia, pero ordenar un desastre de Tailwind me parece mucho mejor que ordenar un desastre de CSS, y todo el proceso de desarrollo también me resulta más disfrutable
Yo también llevo más de 20 años programando y casi 15 haciendo desarrollo web, pero me cuesta encontrar motivación para aprender CSS en serio. Hay demasiadas habilidades técnicas que mantener al día y CSS está bastante abajo en mi lista de prioridades
Preferiría dejarlo en manos de especialistas, pero las empresas no quieren contratar desarrolladores frontend dedicados
Estoy escribiendo una guía de desarrollo web limpio enfocada en HTML y CSS que escalen bien: https://webdev.bryanhogan.com/
Tal vez le sea útil a alguien aquí. Para estilos no uso algo como Tailwind, solo frameworks modernos como Astro o Svelte junto con CSS
En todos mis proyectos tengo
reset.css,var.css,global.cssyutil.css, y el resto de los estilos queda limitado al componente o layout correspondienteBuen artículo
Me gusta eliminar dependencias de librerías externas y construir soluciones desde cero, pero en Tailwind hay una razón clara por la que decidí no hacerlo: ofrece optimización para producción y garantiza que solo se despliegue el CSS mínimo necesario
Aunque enumeres todas las opciones de colores, espaciado, etc. en
globals.csso en otro lugar, no tienes que preocuparte por si en producción se usan todas esas variantes. Si trabajas dentro de un framework como Next.js, esta etapa de minimización ocurre incluso automáticamente durante el build, y solo eso ya es razón suficiente para no migrar fuera de TailwindNunca sentí restricciones difíciles de manejar al usar CSS inline en Tailwind, ni he tenido grandes problemas para implementar grids responsivos con sus herramientas de grid. Ya resolví todos los escenarios mencionados en el artículo usando Tailwind o Tailwind combinado con CSS, y aunque es cierto que
grid-column-areasno viene por defecto, todavía no he sentido que sea una limitación importante para layouts responsivos con gridEl mayor problema de Tailwind es que toma tiempo acostumbrarse a leerlo. Nos enseñan que el CSS inline es malo y que el CSS de alcance global es bueno, y nos acostumbramos a HTML limpio, así que el código real de Tailwind, sobre todo cuando las líneas son largas, al principio de verdad se ve difícil de leer. Después de usarlo mucho me acostumbré completamente a su aspecto y terminé concluyendo que, para mí, Tailwind es más eficiente, más mantenible e incluso más legible, pero me tomó bastante tiempo
Un enfoque que últimamente me gusta mucho es usar Tailwind junto con estilos con alcance limitado (en Svelte y Vue)
Así mantienes la comodidad de Tailwind minimizando la contaminación del template:
+
{{ count }}
Para mí, Svelte y los LLM eliminaron por completo la necesidad de Tailwind
Resulta que la razón principal por la que usaba Tailwind no era una restricción autoimpuesta, sino evitar conflictos de CSS y contar con una sintaxis que me parecía más lógica
Lo mejor de Tailwind es que no necesitas inventar nombres de clase temporales. Ya no hace falta usar BEM
Opiniones en Lobste.rs
En proyectos personales, ya casi no uso frameworks de CSS/JavaScript
porque si no hay dependencias, tampoco puede haber vulnerabilidades en la cadena de suministro. Claro, esas no son el único tipo de vulnerabilidad, pero ayuda
Es el resultado de combinar el cansancio de los frameworks, la sobrecarga de
npm audity el hecho de que, gracias a los LLM, me preocupa menos la opinión ajena sobre cómo implementar algo. Por ejemplo, preguntas como “¿por qué no usas React y Tailwind?”Así es como funciona CSS, simplemente
Cuando veo que alguien usa Tailwind a ciegas sin saber esto, me dan ganas de salir a gritarle a las nubes. Para mí, el 90% de Tailwind son estilos en línea con otra sintaxis, y hasta podría decirse que está solo un escalón arriba de la etiqueta
<FONT>Esta entrada del blog explica cosas que yo realmente necesitaba saber
Tailwind funciona bastante distinto a los estilos en línea, y de hecho se parece mucho más a CSS. Como señala el artículo, muchas de las buenas prácticas que te ayudan a usar bien Tailwind también son necesarias para escribir CSS de forma efectiva. Tailwind se parece más a adjuntar a cada elemento un bloque de CSS con alcance implícito, pero usando un DSL particular
Entiendo bien cómo funciona CSS, pero el CSS puro todavía me resulta pesado y además no se me da bien el diseño gráfico, así que sigo usando Tailwind. Este artículo da ideas para estructurar CSS tomando Tailwind como punto de partida
Desde la perspectiva de alguien que no ha seguido muy bien las tendencias recientes, este artículo parece mostrar bastante bien las prácticas modernas de CSS
También me gusta que tenga muchos enlaces a artículos que lo inspiraron. Se ve como una buena lectura; por ahora solo he leído "no outer margin"
Aun así, soy algo escéptico sobre el enfoque de definir estilos base “de abajo hacia arriba”. No sé bien qué haría en su lugar, y parece algo que vale la pena probar, pero los estilos base son complicados por naturaleza
Este artículo me pareció realmente bueno
Yo también fui aprendiendo CSS poco a poco mientras hacía muchos sitios pequeños, y creo que me habría servido pensar más en sistemas desde el principio. Tengo bastante rechazo a los frameworks, pero como no los uso, aunque sepa implementar lo que quiero, muchas veces siento que todo queda flotando en el aire sin estructura
Me gusta que no sea “Tailwind apesta, así que usa CSS”, sino más bien “Tailwind es excelente, pero quizá ya no lo necesites”
Siempre me ha costado estructurar CSS a mano, y este artículo me hizo pensar en ello de una forma muy distinta
Esta técnica de estructuración me ha resultado bastante útil para organizar CSS: https://rstacruz.github.io/rscss/
En general, encaja bien con lo que jvns explica en el artículo original, y además le añade un poco más de estructura y orden