base.css
Reset, html, body y tokens globales.
File Responsibilities
Cada archivo del framework tiene una responsabilidad concreta. Esta página define qué debe contener cada módulo, qué no debe mezclarse dentro de él y cómo mantener el sistema claro al crecer.
Por qué importa separar responsabilidades
Un framework se vuelve confuso cuando los archivos empiezan a mezclar estructura, tipografía, utilidades y estilos de proyecto en el mismo lugar. La claridad del sistema depende de que cada archivo resuelva un problema específico.
Esta separación no es solo orden técnico. También mejora la documentación, facilita el mantenimiento y permite escalar el sistema sin convertirlo en una colección de reglas aisladas.
Resumen rápido de responsabilidades
breakpoints.css
Mapa oficial responsive y criterio de escalado del sistema.
typography.css
Escala tipográfica, line-height y jerarquía semántica base.
text.css
Color, alineación, transformación, peso y tracking.
layout.css
Containers, grid, columnas y proporciones.
sections.css
Ritmo macro entre bloques grandes.
stack.css
Flujo vertical interno entre hijos.
spacing.css
Margin y padding puntuales del sistema.
align.css
Composición flex, dirección, justify, items, wrap y gap.
width.css
Anchos internos complementarios a container.
height.css
Helpers estructurales de altura y viewport.
radius.css
Sistema de curvatura para esquinas.
visibility.css
Mostrar, ocultar y atajos responsive del sistema.
lists.css
Listas estructurales, inline, verticales y editoriales.
animations.css
Movimiento base, duraciones, delays y accesibilidad.
Archivos base
Qué sí debe contener
- Reset global.
- Box-sizing.
- Variables base del sistema.
- Configuración estructural mínima de html y body.
Qué no debe contener
- Helpers de layout.
- Clases utilitarias específicas.
- Estilos visuales del proyecto.
Qué sí debe contener
- Mapa oficial de breakpoints.
- Documentación interna del sistema responsive.
- Variables de referencia del viewport.
Qué no debe contener
- Helpers concretos.
- Reglas visuales del sitio.
- Estilos duplicados de otros módulos.
Qué sí debe contener
- Escala tipográfica.
- Line-height.
- Jerarquía semántica como title, subtitle y meta.
Qué no debe contener
- Colores visuales del proyecto.
- Spacing estructural.
- Display o layout.
Qué sí debe contener
- Helpers de texto.
- Text-transform.
- Text-align.
- Font-weight.
- Letter-spacing.
Qué no debe contener
- Jerarquía semántica base.
- Containers o grid.
- Componentes del proyecto.
Archivos de estructura
Qué sí debe contener
- Containers.
- Grid base.
- Columnas.
- Proporciones de layout.
Qué no debe contener
- Spacing direccional.
- Alineación flex.
- Tipografía.
Qué sí deben contener
- Ritmo vertical macro.
- Flujo vertical interno.
- Variantes de spacing orientadas a composición.
Qué no deben contener
- Margin y padding utilitarios.
- Grid o flex helpers.
- Estilos decorativos del proyecto.
Archivos utilitarios
Solo margin y padding del sistema. No define stack ni section.
Solo helpers flex: dirección, alineación, wrap y gap.
Helpers de ancho estructural y lectura editorial.
Helpers de altura estructural, viewport y auto.
Helpers de border-radius. No debe contener sombras ni borders.
Control responsive de visibilidad y atajos semánticos.
Listas estructurales inline, stack y editoriales.
Animación
- animations.css debe contener solo el sistema de animación reusable.
- Debe incluir duraciones, delays, keyframes y reglas de accesibilidad.
- No debe contener animaciones específicas de una página del proyecto.
- No debe mezclarse con helpers estructurales ni con layout.
Core y overrides
Qué sí debe hacer
Organizar imports, capas y orden del sistema. Es el archivo orquestador del framework.
Qué no debe hacer
No debe llenarse de reglas visuales, componentes, hacks o CSS del proyecto.
Qué sí debe contener
Ajustes específicos del sitio, estilos particulares de documentación o adaptaciones del proyecto.
Qué no debe contener
Cambios que en realidad deberían integrarse al framework base como parte del sistema.
Errores comunes
Duplicar lógica
Repetir spacing, text helpers o visibilidad en varios archivos rompe la claridad del sistema.
Mezclar proyecto y framework
Poner estilos propios del sitio dentro del núcleo hace más difícil mantener el sistema.
Crear utilidades arbitrarias
Helpers sin relación con la escala o la arquitectura general debilitan la consistencia del framework.
Mover responsabilidades
Cuando un archivo empieza a resolver problemas que pertenecen a otro, la documentación deja de ser confiable.
Regla principal
- Si una clase pertenece funcionalmente a otro archivo, no debe colocarse donde resulte más cómodo.
- Si una solución es específica de un sitio, debe ir en overrides o CSS del proyecto.
- Si una necesidad se repite y es sistémica, entonces sí se integra al framework.
Siguiente paso
Continúa con framework core para revisar el orden de imports, capas y ensamblado del sistema.