-
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
1 comentarios
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