CSS de ahora y del futuro.

¿En qué estado se encuentra CSS? Es una pregunta con fácil respuesta: “En constante evolución” pero que no nos aporta ningún tipo de detalle acerca del estado del desarrollo de este lenguaje.

Hace más de 20 años que salió la “última versión” de CSS, CSS3. Sí, es de 1999 y aunque esa versión fue evolucionando e incluyendo nuevas features, puede que alguien esté esperando un CSS4 que nunca llegará.

Lo cierto es que llegado un punto del desarrollo de CSS se empezaron a hacer diversificaciones hacia distintas ramas o módulos que son los que van evolucionando y ofreciéndonos nuevas herramientas en función de las necesidades que han ido surgiendo con la evolución del desarrollo de software.

Además, parece que el desarrollo es mucho más lento debido a la necesidad de dar soportes a navegadores que no implementan estas nuevas funcionalidades que CSS va creando.

A día de hoy y aunque nos duela, seguimos teniendo que dar soporte a IE11 y aunque este verano está más cerca que nunca y podremos enterrarlo… ese entierro será simbólico a todas luces, porque seguiremos teniendo que dar soporte en algún que otro proyecto.

Estado actual

La encuesta anual State of CSS siempre arroja datos que me dejan sorprendida y, en parte, me apenan porque veo que la deriva de los programadores que utilizamos CSS está cada vez más cerca de lo que yo llamo en tono jocoso FDD o Fashion Drive Development, algo de lo que adolecen otros lenguajes del front.

¿A qué me refiero con esto? Pues a datos como que hay un 16% de personas que se consideran expertos en CSS que no han oído hablar nunca de las break rules pero sí de las container queries (cuando las primeras están disponibles desde 2018 y con un amplio soporte en navegadores), mientras que de las container queries se publicó su primera versión a 10 días de acabar 2021 y no tiene soporte en navegadores (sólo disponibles de manera experimental activando un flag en las dev tools de Chrome).

No quiero sonar demagoga y sé que quizá las break rules solucionan una serie de circunstancias mucho menos habituales de lo que podrían resolver las container queries, pero hay otras “novedades” relacionadas con algo tan esencial como es la accesibilidad y que deberían estar en el foco de aprendizaje de cualquier desarrollador front que son desconocidas, como es el caso del prefers-reduced-motion y prefers-color-scheme, ambas con más de un 35% de personas que han contestado que nunca han oído hablar de ello.

Puede que no hayas tenido la oportunidad de usarlo en el desempeño profesional (aunque en temas de accesibilidad no veo por qué no) pero qué menos que conocerlo.

Por poner un ejemplo práctico: yo no pude empezar a usar grid con todo su potencial hasta hace relativamente poco tiempo en relación a cuando salió la especificación, pero lo conocía y estaba preparada para poder usarla en cuanto tuviera la menor oportunidad.

Uno de los resultados que más me sorprendió de este survey fue que casi un 50% de los encuestados no había oído hablar nunca de la propiedad will-change cuando tiene un potencial enorme y optimiza la performance de nuestro CSS al permitir que el navegador pueda prever qué cambios van a hacerse y, a grosso modo, pre-renderizarlos para hacer más fluidos esos cambios cuando se produzcan.

Otro punto caliente de CSS ¿Por qué sólo pensamos en la performance cuando se nos quedan enganchadas animaciones complejas?
¿Acaso todos navegamos con el dispositivo más moderno y con conexión 5G?

A donde quiero ir a parar es que veo que existe una deriva fashionista hacia “lo que lo va a molar todo” y aún no tenemos, a la par que desconocemos aspectos tan básicos como cómo funciona la cascada, que necesitamos conocer en profundidad para poder implementar “lo que se viene” como puede ser Cascade Layouts.

Por último, ninguno de estos resultados es especialmente sorprendente cuando, al llegar a la parte de tecnologías y frameworks, Styled-Components, CSS-Modules (CSS en JS a fin de cuentas) ya Tailwind ganan por goleada.

Ojalá en la encuesta de este año incluyan un pequeño reto de maquetación con un CSS medianamente complejo y en base a la resolución se te asignara el grado de expertise en CSS que tienes. Porque todos son maquetadores hasta que tienen que maquetar.

Lo que ya tenemos, lo que vemos en nuestra bola de cristal y con lo que aún sólo podemos soñar

Como hemos dicho anteriormente, hay funcionalidades que nos suenan desde que se proponen de manera experimental y las tenemos en nuestro foco durante toda su evolución mientras que hay otras que son relativamente nuevas que no conocemos.

A continuación voy a mencionar algunas propiedades y funcionalidades de CSS que ya podemos utilizar, otras que probablemente antes de que acabe el año ya estarán disponibles en todos los navegadores (disclaimer: como IE11 va a descontinuarse en el próximo verano, a partir de ahora cuando hablemos de compatibilidad en todos los navegadores, IE11 no estará incluido) y otras que sólo son experimentales o grandes anhelos de la comunidad maquetera adicta al CSS.

accent-color

Si te digo que hay una forma de customizar los check-boxes y los radio-buttons con sólo una propiedad CSS, ¿me creerías? Customizar los elementos de formulario siempre ha sido un dolor para los maquetadores, más cuando tenemos en el foco la accesibilidad.

Olvídate de checkboxes ocultos y pseudo-elementos, con accent-color podemos hacer visualmente más atractivos estos elementos de elección en formularios, si bien aún no podemos modificar el borde del elemento (tanto en color como grosor) poder personalizar de manera simple el estado checked es un gran avance.

Quizá no sea lo que el equipo de diseño soñó, pero podemos defenderlos como elementos con mejor performance e infinitamente más mantenibles que nuestras antiguas soluciones.

Esta propiedad tiene soporte en todos los navegadores y no nos acarrea problemas de accesibilidad, ya que no interfiere en las propiedades relacionadas con el foco en el elemento.

Aquí vemos un ejemplo de uso:

See the Pen WNdxbOp by @NoemiMS on CodePen.

cascade-layers

Ya explicamos brevemente esta feature en este post y próximamente hablaremos de ella más en detalle porque consideramos que nos traerá una nueva forma de pensar la arquitectura de nuestro CSS. Firefox ya permite su uso y Chrome y Edge lo han implementado como un flag de desarrollo, por lo que podemos dar por hecho que antes de que acabe 2022 podremos utilizarlo en nuestros desarrollos.

Funciones de color

CSS está avanzando mucho en hacer más amigables y fáciles de manejar los valores relacionados con los colores. El hexadecimal es un dialecto complejo de memorizar y más allá de los colores básicos, al ver un color en hexadecimal no sabemos muy bien qué color podemos esperar y lo mismo nos pasa con el sistema RGB.

Quizá esto os parezca algo baladí porque ya tenemos herramientas de visualización de colores en los IDEs y extensiones en navegadores que nos permiten ver rápidamente qué color es.

HSL es un sistema que cada vez se usa más porque en comparación con los dos anteriores, nos permite especificar y manipular colores muy fácilmente, y está completamente soportado por navegadores.

Podría bastarnos con HLS, pero el trabajo en los niveles 4 y 5 del módulo de color de la especificación de CSS está yendo más allá y ha propuesto nuevas funciones de color que permitirán manipular y especificar colores como nunca antes lo hubiéramos imaginado.

Las que más interesantes me parecen son:

• hwb(): hue, whiteness, blackness. Me parece muy interesante y asimilable el mezclar sobre el valor hue (entre 0 y 360) cuánto de “blancura” y de “negrura” queremos darle al color para conseguir así otros tonos. La aplicación en gradientes puede darnos unos resultados muy sorprendentes con “muy poco” trabajo.
• color-mix(): nos permitirá mezclar dos colores.
• color-contrast(): permitirá comparar un color frente a una lista de colores, seleccionando finalmente el que mayor contraste tenga de ellos. Es una funcionalidad muy interesante de cara a un mayor control de la accesibilidad en relación al color.

Actualmente, sólo Firefox incluye algunas de estas opciones con un flag de desarrollo y en Chrome no parecen estar ni se las espera. Pero dado el desarrollo que está teniendo en la especificación, cabría esperar que muchas de ellas lleguen a buen puerto, aunque no podamos aún vislumbrar una fecha concreta para ello.

Si queréis saber más sobre las funciones de color que ya tenemos, así como las nuevas que se están manejando, este post os vendrá muy bien.

subgrid

Propiedad asociada a display grid que desde que pudimos empezar a utilizar ésta y nos dimos cuenta de que en ocasiones debíamos romper la semántica para poder aplicarla, empezamos a reclamar.

Este subgrid nos permitiría que los elementos hijos de un elemento con grid hereden las propiedades de grid de su padre, tanto para columnas como para filas.

Quizá para cuando esta propiedad esté disponible, hayamos encontrado formas más respetuosas con la semántica, la accesibilidad y la experiencia de usuario que no la hagan tan necesaria pero igual que con los colores ¿Por qué no contar con nuevas herramientas que nos permitan crear interfaces más complejas aunque no sean las más habituales?

Así podríamos desterrar las ñapas que en ocasiones nos vemos obligados a hacer y tener un workbench que sería la envidia de cualquier aficionado a la bricomanía del CSS.

Firefox lo soporta desde hace casi tres años y Chromium lo implementa, de nuevo, con un flag de desarrollo. Esto nos hace pensar, como con otras propiedades, que Chrome y Edge no tardarán en ponerse con ello. Y Safari… Bueno, Safari se subirá al carro porque no le quedará otra (o eso esperamos).

:has()

La joya de la corona. El juguete más pedido en la carta de los Reyes Magos de cualquier maquetador. La pseudoclase parent selector que tantas veces necesitamos y que siempre recordamos con lágrimas en los ojos que no tenemos.

Quizá me haya pasado con la dramatización, pero la verdad es que en mis casi diez años de maquetadora, es una de las cosas que más me ha frustrado que no se pusiera en marcha.

:has() pasará a formar parte de la lista de pseudo-clases disponibles y nos permitirá seleccionar un elemento en función de sus descendientes. Puede que resumir lo que nos da esta pseudo-clase en una frase tan corta tire por tierra el hype que genera, pero las posibilidades que nos ofrece son infinitas y potentes.

Personalmente, estoy deseando poder utilizarla porque ninguna otra herramienta potenciadora de CSS (preprocesadores, postcss…) nos ha dado esta posibilidad nunca. ¡Y va a ser nativa!

Desafortunadamente es, de lejos, la funcionalidad de la que más tiempo se lleva hablando desde que se incluyó en el borrador del módulo de selectores de CSS en 2018 pero aún ningún navegador la ha implementado en sus versiones estables y sólo Safari la ha incluido en su versión experimental.

container-queries

Es la otra funcionalidad más pedida a los magos de las especificaciones CSS y el crossbrowsing. Los maquetadores con container-queries tendremos por fin un control total e hiperpreciso sobre el tamaño de nuestros elementos.

Las container-queries nos permitirán determinar el tamaño de los elementos en función de sus ancestros y no en función del tamaño del viewport, lo que se traducirá en una interpretación y manejo del diseño responsive mucho más exacto.

Chrome permite utilizarla con un flag de desarrollo, pero muchas personas que lo han probado reportan que no funciona exactamente como indica la especificación. Por ello tendremos que seguir esperando.

scroll-timeline, @where/@else y anidamiento

Para no seguir maltratando los ya de por sí maltrechos corazones de los maquetadores, mencionaré brevemente otras propiedades propuestas que están en fase experimental o incluso en fase de propuesta como scroll-timeline (nos permitiría tener un mayor control del timing de las animaciones CSS), where&else que funcionarían de manera parecida a los condicionales que tenemos en Sass y ¡nesting! que junto con las variables nativas nos harían replantearnos bastante el uso de preprocesadores en algunos proyectos.

Conclusiones

CSS es un lenguaje de programación (es 2022, creo que ya no hay debate sobre si lo es o no lo es) con un potencial brutal que no se explota lo suficiente cuando aporta el mayor valor de un producto tras el diseño: la experiencia visual y la interacción con el mismo. No quiero abrir nuevas guerras entre lenguajes, pero creo que es necesario ser un poco beligerante para poder poner al CSS en el lugar que se merece.

Quizá haya llegado el momento de redefinir qué es y qué no es el front y cuántos caminos hay en él, otorgándoles la misma importancia a todos ellos de manera igualitaria. Seguramente hablaremos de ello en un futuro no muy lejano.