Con toda la charla de finalmente poder usar CSS Grid, me puse a pensar: ¿Qué otras sorprendentes características de CSS puedo usar ahora? CSS Variables fue el que instantáneamente surgió en la mente.
Ha pasado un tiempo desde que escuché algo sobre CSS Variables y agrega un nuevo conjunto de herramientas y una forma de pensar al desarrollo del front-end que me entusiasma.
Las variables de CSS han estado dando vueltas durante algunos años pero no parecen tener un amplio uso. Con la popularidad de los preprocesadores, como Sass, los desarrolladores de frontend arañaron esa picazón variable hace mucho tiempo.
Primero me emocionaron las Variables CSS en 2014 y desde entonces han entrado y salido de mi esfera de interés. Solo ahora estoy considerando llevarlos a los sitios de producción y les mostraré lo simple y fácil que es su uso.
Declarar la propiedad personalizada es simple: solo necesitamos crear la propiedad que queremos y agregar dos guiones al comienzo de la misma. Estos pueden declararse en cualquier lugar, pero agregarlos a: root parece ser un buen enfoque en este momento.
--my-reusable-value: 20px;Usar la propiedad es bastante simple también. Accedemos a través de la función var () y usamos la propiedad que declaramos arriba.
padding: var(--my-reusable-value);¿No es eso simple y glorioso?
Las variables CSS son sencillas de usar y bastante fáciles de recordar. El mayor desafío con las variables de CSS (como con la mayoría de los CSS) es conocer el momento y el lugar adecuados para usarlos. Tirarlos al azar es una manera segura de crear un lío de una hoja de estilo y con estas variables lanzadas en la depuración probablemente será más difícil.
Deben tenerse en cuenta los casos de uso adecuados y las estrategias para usarlos, y es aquí donde debe enfocarse la mayoría de sus esfuerzos.
En el siguiente ejemplo, voy a mostrar un ejemplo básico de cómo actualmente creo un componente receptivo usando variables Sass. Luego, le mostraré cómo podría mejorarse con las variables CSS de una manera que no es posible con un preprocesador. Este es un caso de uso específico que no se aplica a todas las formas en que se utilizan las variables, sino que muestra cómo las Variables CSS se pueden usar de manera diferente.
Vea la pluma Variables CSS: caso de uso receptivo sin variables CSS por Adam Hughes ( @perdi mi cerebro ) en CodePen .
Cuando uso Sass hay algunas metodologías diferentes que he probado. La versión actual de ir a está colocando consultas de medios dentro de los bloques de CSS que quiero cambiar. Aquí puedo usar una variable, CSS estándar, mixin o una extensión para modificar este elemento sin dispersar los estilos para el componente en todas partes.
Un problema con esto es tener múltiples consultas de medios y muchas variables que están relacionadas pero no así. Podría usar mapas para las variables que darían más organización, pero creo que el problema principal es que estamos usando múltiples variables para definir una propiedad. Esto simplemente se siente mal.
Las variables de Sass se usan antes de tiempo, lo que significa que tenemos que planificar de todas las maneras en que las vamos a usar. Facilitan el desarrollo, pero técnicamente no nos proporcionan nuevos superpoderes.
Vea la pluma Variables de CSS: caso de uso receptivo por Adam Hughes ( @perdi mi cerebro ) en CodePen .
Las variables CSS no necesitan ser declaradas por adelantado, son dinámicas. Esto es útil de una manera muy diferente. Ahora podemos cambiar las variables de forma condicional desde cualquier lugar y en contextos específicos, como consultas de medios.
Al servir nuestros estilos de consulta de medios desde el principio, podemos reducir la cantidad de consultas de medios dispersas para un estilo receptivo. También ofrece una forma muy agradable y limpia de ver el espaciado general y el estilo de tipografía en diferentes formatos.
Creo que los diseños receptivos y la creación de temas son dos casos de uso excelentes para las variables CSS, pero hay muchas posibilidades.
Las Variables Sass y las Variables CSS son dos bestias diferentes, cada una con sus propios pros y contras.
Debido a la popularidad de Sass y a la naturaleza más programática de Sass, los patrones de organización más profundos han evolucionado con el tiempo. Me gustan especialmente los mapas sass y la combinación de variables de tipo similar en los mapas. Los colores, tamaños y accesos directos para las rutas parecen ser opciones populares para incluir en los mapas.
Debido al uso relativamente más pequeño de las variables de CSS, las mejores prácticas aún tienen que evolucionar. Los mapas y matrices no son posibles de la misma manera en CSS, por lo que estos nuevos patrones de organización tendrán que ser innovadores y resolver los problemas de una manera diferente a Sass.
Las variables CSS se manejan dinámicamente por el navegador en el tiempo de ejecución, mientras que las variables Sass se usan cuando se compila el CSS.
Este es el punto central de venta de las variables CSS para mí. Será interesante ver cómo las personas usan esta función a lo largo del tiempo y si estará a la altura de su potencial.
Personalmente soy de la opinión de que mientras más cosas podamos eliminar de Webpack , Gulp , y lo que sea-new-framework-is-out-now , mejor. Tener nuevas características de navegador interesantes significa que no tenemos que confiar en la compilación y los marcos de JavaScript para hacer las cosas que los desarrolladores consideran esenciales. Me arriesgaría a suponer que un alto porcentaje de desarrolladores de frontend usan variables en sus CSS de una forma u otra, por lo que todos los que usan esta característica central parecen ser algo sensato. Significa una cosa menos en el paso de compilación (que creo que todos podemos estar de acuerdo en que es cada vez más inmenso) y una mayor coherencia en la web.
El soporte se ve notablemente bueno con una excepción evidente: IE 11. La mayoría de los navegadores modernos admiten Variables CSS con Edge que tiene algunos errores.
En 78.11% esto es más alto que CSS Grid (al momento de escribir) pero que la compatibilidad con IE11 podría ser un problema.
Creo que el momento es ahora. Esa compatibilidad con IE11 no va a mejorar, y sabemos por versiones anteriores de Windows que a las personas les lleva mucho tiempo actualizar. Pero el soporte en los navegadores modernos es excelente, lo que significa que deberíamos buscar Variables CSS y experimentar con las posibilidades.
Sin embargo, eso no significa que no debemos olvidar nuestra responsabilidad con el soporte de un navegador más antiguo. Se debe considerar un sistema de respaldo básico que use una etiqueta de soporte, o incluso un relleno policrible, para navegadores más antiguos, más aún si el uso real del sitio es mucho más sesgado para los navegadores más antiguos.
Es un momento emocionante para el desarrollo de front-end, y por mi parte no puedo esperar para utilizar más de estas tecnologías en mis sitios de producción.