Prompt y contexto
Una biblioteca de componentes utiliza propiedades personalizadas como --accent, --progress y --card-size. Los requisitos de diseño exigen transiciones fluidas, pero las variables son cadenas de texto sin tipo, los valores no válidos se propagan silenciosamente y los componentes secundarios heredan accidentalmente los valores del tema. Explica cuándo registrarlas con CSS @property, incluyendo valores predeterminados, valores no válidos, herencia y compatibilidad con navegadores.
Esto encaja en entrevistas de frontend, sistemas de diseño y rendimiento web. La prueba consiste en comprender el límite de la CSS Properties and Values API, no en registrar cada variable. Cubre sintaxis, valores iniciales, herencia, interpolación, alcance, mejora progresiva y pruebas.
Qué está evaluando el entrevistador
Una respuesta sólida afirma que las propiedades personalizadas ordinarias se calculan como cadenas de texto y se heredan por defecto; las propiedades registradas declaran un tipo, un valor inicial y un comportamiento de herencia, con valores no válidos comprobados en el momento del valor calculado (computed-value time). Explica que syntax y inherits son descriptores obligatorios, que la sintaxis no universal normalmente necesita un initial-value computacionalmente independiente, y cuándo la animación, las restricciones de tipo y el estado de componente no heredado justifican el registro. No presentes @property como estado de JavaScript ni como una garantía automática de rendimiento.
Preguntas para aclarar primero
- ¿Qué tipo contiene la variable: color, longitud, ángulo, número o una cadena de token abierta?
- ¿Necesita una interpolación fluida o solo un cambio de tema discreto?
- ¿Debería heredarse en los elementos secundarios o el límite del componente debería aislarla?
- Ante un valor no válido, ¿el resultado debería ser el valor inicial, un valor heredado o ninguna declaración?
- ¿Cuáles son los navegadores de destino, la ruta de renderizado en servidor, el fallback y el proceso de publicación de tokens de diseño?
Una respuesta de 30 segundos
“Las propiedades personalizadas ordinarias son cadenas que se heredan y funcionan bien para tokens abiertos. Yo registraría una propiedad cuando necesite verificación de tipos, un valor predeterminado no heredado o una interpolación fluida. El registro debe especificar syntax, inherits y un initial-value computacionalmente independiente, haciendo que las asignaciones no válidas sean predecibles. Los navegadores más antiguos mantienen la variable ordinaria como fallback, y las pruebas de componentes cubren la herencia, los valores no válidos, la animación y los cambios de tema; no se asume que el registro en sí sea más rápido.”
Respuesta paso a paso
Paso 1: Separar las variables ordinarias de las propiedades registradas
Un --name ordinario participa en la cascada y se hereda por defecto; el navegador trata su valor como una secuencia de tokens. Eso es útil para colores, tokens de espaciado y composiciones abiertas, pero el navegador no sabe si un valor debería ser un color o una longitud. @property añade metadatos de tipo, herencia y valor predeterminado a la misma variable.
Paso 2: Elegir una sintaxis explícita
Registra solo los valores que requieran restricciones o interpolación. Usa los tipos de sintaxis CSS de color, número y ángulo para los valores correspondientes. No fuerces un valor experimental de múltiples tokens en un solo tipo solo para parecer estricto; de lo contrario, los valores de tema válidos se descartarían.
Paso 3: Configurar inherits e initial-value
Haz que inherits sea explícito. Un color de tema usualmente se hereda; el tamaño interno de un componente o el progreso de una animación tal vez no. La sintaxis no universal requiere un initial-value computacionalmente independiente, como una unidad fija en lugar de un porcentaje que dependa de un padre. La falta de descriptores requeridos invalida el registro.
Paso 4: Comprender los valores no válidos y el fallback
Las propiedades registradas se validan en el momento del valor calculado. Un valor con el tipo incorrecto no se aplica y la propiedad se resuelve mediante su valor inicial registrado, herencia u otro resultado de cascada válido, dependiendo de inherits y de la ubicación de la declaración. Las palabras clave globales como initial, inherit, unset y revert siguen teniendo una semántica especial y necesitan pruebas independientes.
Paso 5: Utilizar animación interpolable
Las propiedades personalizadas no registradas generalmente cambian de forma discreta porque el navegador no puede interpolar cadenas de texto arbitrarias. Una vez registrada como color, longitud o número, el navegador sabe cómo interpolar degradados, progreso y rotación. Aun así, prueba la duración, la composición, el comportamiento con movimiento reducido (reduced-motion) y el costo real de actualizar muchos elementos.
Paso 6: Controlar los límites de los componentes
Nombra los tokens de tema globales por separado del estado interno. Los valores heredados son útiles para temas; una propiedad no heredada permite que un componente use su propio valor inicial y evita que una variable con el mismo nombre en un padre contamine la animación interna. Si una propiedad cruza el Shadow DOM o los límites del contenedor, define el espacio de nombres y la API pública antes de decidir registrarla.
Paso 7: Ofrecer mejora progresiva
Envía primero una propiedad personalizada ordinaria y un estado final estático, de modo que los navegadores sin @property sigan renderizando una interfaz de usuario utilizable. Los navegadores compatibles pueden añadir restricciones de tipo e interpolación. No hagas que el diseño crítico dependa únicamente del registro; utiliza @supports (property: --x) o detección de capacidades al seleccionar la ruta de mejora.
Paso 8: Verificar errores y el comportamiento del navegador
Prueba valores válidos, tipos incorrectos, valores iniciales faltantes, alternancias de herencia, anulaciones de temas, actualizaciones a mitad de animación y el primer pintado renderizado en servidor. Revisa navegadores antiguos, valores calculados en las herramientas de desarrollo y regresiones visuales. MDN señala que el registro se valida en el momento del valor calculado y que una regla mal formada puede ignorarse por completo, por lo que tanto las verificaciones de compilación como los ejemplos en tiempo de ejecución son importantes.
Compensaciones y límites
El registro añade costos de mantenimiento de declaraciones y tokens de diseño, y los colaboradores no familiarizados con la API pueden asumir que todos los valores siguen siendo libremente reemplazables. Registra valores con un tipo claro, necesidad de animación, valor predeterminado o límite de herencia; mantén los tokens de contenido abiertos como propiedades personalizadas ordinarias.
La verificación de tipos no es un límite de seguridad ni una garantía de consistencia entre navegadores. El soporte, los tiempos de análisis y la composición de animaciones aún requieren que se pruebe la matriz de navegadores de destino. Los estados de accesibilidad críticos necesitan estilos estáticos y una ruta para movimiento reducido.
Plan de despliegue y evidencia
Realiza una prueba piloto con un componente de progreso o color. Registra el propósito de cada variable, tipo, política de herencia y fallback. Utiliza ejemplos válidos y no válidos para verificar los resultados calculados, y luego compara la fluidez de la animación, el recálculo de estilos y el comportamiento en navegadores antiguos antes y después del registro. Una vez superada la prueba piloto, incluye los registros, la documentación de tokens y la regresión visual en las comprobaciones de versión de la biblioteca de componentes.
Trata cada cambio de syntax o inherits como un cambio de comportamiento e inspecciona las anulaciones secundarias, el cambio de temas y las capturas instantáneas persistidas. Si los usuarios reportan un salto de color o un fallback de tamaño, inspecciona los valores calculados y las rutas de capacidades antes de cambiar la duración de la animación.
Errores comunes y preguntas de seguimiento
Registrar todas las variables CSS
Los tokens abiertos, los valores compuestos y las cadenas experimentales pueden no tener una sintaxis estable. Registra únicamente los valores que necesiten tipo, valor predeterminado, control de herencia o interpolación.
Olvidar la independencia computacional de initial-value
Para una sintaxis no universal, el valor inicial no puede depender del contexto. Un porcentaje o em puede invalidar el registro; utiliza una unidad computacionalmente independiente o acepta restricciones más débiles con una sintaxis universal.
Asumir que los valores no válidos conservan la declaración válida anterior
Las propiedades registradas se validan en el momento del valor calculado. Una asignación no válida puede resolverse en un resultado inicial o heredado en lugar del valor antiguo adyacente. Prueba los estilos calculados, no solo el orden en el código fuente.
Tratar inherits como un aislamiento completo de cascada
inherits: false controla la herencia por defecto; los autores aún pueden escribir inherit, y otro token puede transferir un valor principal al componente. El nombrado, la documentación y las pruebas deben reforzar el límite en conjunto.
¿Cómo dar soporte a navegadores sin @property?
Mantén una variable ordinaria con un estado final estático y un valor predeterminado razonable, y luego añade el registro y la animación como mejora. Utiliza @supports o detección de capacidades para rutas críticas y prueba el primer pintado, los temas y el movimiento reducido en la matriz de navegadores de destino.