También disponible en Inglés.
El problema
“No tenemos problemas de CSS, usamos Tailwind”. “Bootstrap se encarga de eso”. Casi todos los equipos que han adoptado un framework pronuncian alguna versión de esa frase. Generalmente, con un alivio real.
Tampoco es del todo cierto. Los frameworks resolvieron problemas reales. La cascada nunca fue uno de ellos.
Por qué existe el problema
Los frameworks se construyeron para solucionar problemas que realmente requerían atención: el marcado inconsistente de los componentes en un equipo, el tedio de crear a mano los mismos patrones de botones y tarjetas por décima vez, y una brecha de herramientas real en torno a los pasos de compilación, la depuración de estilos no utilizados y la distribución de tokens a escala. Resolver estos problemas justificó un esfuerzo de ingeniería serio. Los frameworks se ganaron su adopción de forma honesta: resolviéndolos bien.
Ninguno de esos esfuerzos afectó al origen, al orden de las capas, a la especificidad o al source order. La secuencia de resolución que esta serie explicó en su segunda fase siguió funcionando exactamente como siempre, por debajo de las clases del framework en lugar de las del propio autor. Un equipo podría adoptar la biblioteca de componentes más disciplinada del mercado y, aun así, heredar cada guerra de sobrescrituras, cada estilo base accidentalmente demasiado específico y cada interacción impredecible que esta serie ha diagnosticado a lo largo de ocho artículos. El framework cambió lo que se escribe. Nunca tocó cómo el navegador decide cuál de ellos gana.
El primer principio
La composición y la reutilización son problemas del tiempo de autoría: qué tan conveniente resulta construir la interfaz de usuario. La cascada es un problema del tiempo de resolución: cómo decide el navegador qué gana cuando hay un conflicto entre reglas.
Se trata de dos capas diferentes del mismo sistema, resueltas por dos tipos distintos de ingeniería. Un framework puede mejorar drásticamente la autoría y, al mismo tiempo, dejar la resolución igual de impredecible. Mejorar una capa nunca iba a afectar a la otra. Eso no es un defecto en los objetivos de los frameworks. Es una categoría a la que nunca estuvieron dirigidos en primer lugar.
Demostración del principio
.btn { padding: 0.5rem 1rem; }
.btn-primary { background: blue; }
Dos clases con estilo de framework, aplicadas juntas al mismo botón. Cuál de ellas gana si alguna vez hay un conflicto en la misma propiedad no se decide por nada que el framework haya introducido: sigue dependiendo del source order y de la especificidad, resueltos por la secuencia exacta explicada anteriormente en esta serie. El vocabulario cambió. El mecanismo que decide el resultado, no.
quell como caso de estudio
quell existe para abordar esa capa de resolución directamente, en lugar de ofrecer comodidad sobre una cascada que queda sin resolver por debajo.
La lección general
Este es un patrón familiar también fuera de CSS: una solución real y valiosa a un problema se confunde con la solución a un problema diferente y adyacente, simplemente porque ambos aparecieron empaquetados en la misma herramienta. Ese empaquetado no fue deshonesto. Solo significó que un problema se resolvió con tanto ruido que el otro se silenció, sin llegar a desaparecer realmente.
Las herramientas de composición y las garantías arquitectónicas no pertenecen a la misma categoría. Los próximos dos artículos trazan esa línea con mayor precisión.
Top comments (0)