Miriam Suzanne es autora, artista y desarrolladora web en Denver, Colorado, y actualmente trabaja en especificaciones de CSS interesantes, como consultas de contenedores y capas en cascada.
Esta publicación forma parte de Designcember. Celebra el diseño web con web.dev.
Miriam Suzanne es autora, artista y desarrolladora web en Denver, Colorado. Es cofundadora de OddBird (una agencia web), escritora de personal para CSS Tricks, miembro del equipo principal de Sass y experto invitado de W3C en el grupo de trabajo de CSS. Últimamente, se enfocó en desarrollar nuevas funciones de CSS, como capas en cascada, consultas de contenedores y alcance. Miriam es una novelista, dramaturgo y músico. Hablamos sobre su trabajo con Sass y CSS.
Rachel: Me enteré de tu trabajo gracias al marco de trabajo de cuadrícula Susy, ¿qué te impulsó a crearlo?
Miriam: En 2008, el diseño en la Web fue una experiencia muy diferente. Los desarrolladores se habían alejado del diseño de tablas a cuadrículas flotantes más semánticas (pero aún más hackeadas). Se produjo un auge en los “frameworks de cuadrícula” de 12 columnas de talla única para todos, proporcionando una cuadrícula predefinida (por lo general, estática) con un conjunto de clases de CSS predefinidas. Si necesitabas algo más personalizable, estabas por tu cuenta. Era claro que los sitios web debían ser más responsivos, pero las consultas de medios aún no estaban disponibles y había una gran cantidad de problemas de compatibilidad con el navegador en torno a los flotantes fluidos.
Usaba el enfoque de CSS Systems de Natalie Downe, que era muy inteligente para responder a los tamaños de fuente y viewport, pero me frustraban todos los hackeos matemáticos repetitivos y el navegador necesarios. Al mismo tiempo, Sass estaba empezando a captar algo de atención, y encajaba perfectamente para lo que necesitaba. El primer borrador de Susy fue muy simple: solo un par de mezclas para hacer los cálculos y agregar los trucos que necesitaba. El objetivo era ser mínimo y mostrar solo el código esencial. Cuadrículas completamente personalizables sin clases predefinidas.
Rachel: ¿Cómo pasó de trabajar en un preprocesador de CSS a trabajar con especificaciones de CSS? ¿Consideras que trabajar en el preprocesador era una buena experiencia para escribir especificaciones?
Miriam: Según mi experiencia, hay muchas superposiciones, y todavía soy muy activa en ambos lados. Sin embargo, creo que eso se debe en gran medida al equipo de Sass, dirigido por Natalie Weizenbaum, que tiene una visión a largo plazo: trata de desarrollar herramientas que se integren sin problemas con los estándares web en desarrollo. Ir más allá de las soluciones únicas y “opinadas” y desarrollar la flexibilidad a largo plazo es esencial cuando se piensa en el futuro de los estándares principales de la Web.
¿Cómo podemos crear herramientas que respeten la diversidad de las necesidades y los enfoques de los desarrolladores y que, al mismo tiempo, fomenten y faciliten la accesibilidad y otras consideraciones importantes?
Rachel: Se agrega un montón de elementos a CSS que, básicamente, reemplazan las funciones que solían ser parte de Sass. ¿Hay buenas razones para usar algo como Sass?
Miriam: Sí, para algunas personas, pero no hay una respuesta universal aquí. Tomemos las variables como ejemplo. Las variables Sass tienen alcance léxico y se compilan en el servidor, con estructuras de datos organizadas, como listas y objetos, manipulación de color, etc. Esto es excelente para la lógica de sistema de diseño que no necesita ejecutarse en el navegador.
Las variables de CSS se superponen, pero también pueden almacenar valores, pero proporcionan un conjunto completamente diferente de fortalezas y debilidades basadas en cascada. Sass no puede administrar propiedades personalizadas, y CSS tampoco puede manejar datos estructurados. Ambos son útiles y también eficaces, pero tus necesidades específicas pueden variar.
Creo que es muy útil que las personas eliminen las herramientas que ya no necesitan, y es posible que algunos proyectos no requieran variables del servidor y del cliente. ¡Excelente! Pero es demasiado simple suponer que son idénticos y que uno solo reemplaza al otro. Siempre habrá casos de uso para que alguna lógica de diseño ocurra del lado del servidor y otra parte del lado del cliente, incluso si llegamos al punto en que los lenguajes proporcionan básicamente las mismas funciones. Los preprocesadores estarán con nosotros a largo plazo.
Rachel: ¿Hay algo que te sorprenda a medida que te involucraste más en el trabajo de creación de estándares o algo que crees que la gente generalmente no conoce sobre el proceso?
Miriam: Antes de involucrarme, el proceso de los estándares parecía una caja negra mágica y misteriosa, y no estaba seguro de qué esperar. Tenía miedo de no tener suficientes conocimientos sobre aspectos internos del navegador para contribuir, pero la realidad es que no necesitan más ingenieros de navegadores. Necesitan más desarrolladores y diseñadores que creen sitios web y aplicaciones en el entorno.
Me sorprendió descubrir que muy pocas de las personas involucradas se centran principalmente en los estándares, pero también muy pocas de ellas están principalmente desarrollando o diseñando sitios web. El W3C está formado por "voluntarios" de organizaciones asociadas (que a menudo reciben pagos de esas organizaciones, pero no como su trabajo principal) y la membresía no es económica. Eso aleja a los participantes de los diseñadores y desarrolladores cotidianos, especialmente aquellos de nosotros que trabajamos con clientes en agencias pequeñas o somos freelancers. Mi función como experto invitado sería totalmente voluntario, un pasatiempo costoso, si no hubiera encontrado financiamiento externo para ese trabajo.
En realidad, el proceso es bastante abierto y público y requiere la participación de los desarrolladores, pero siempre hay tantas conversaciones en curso que puede ser difícil encontrar tu lugar. Especialmente si no es tu trabajo de día.
Rachel: Durante muchos años, las consultas de contenedores han sido el santo grial para muchos desarrolladores web. Estoy muy emocionado de que las tengamos. Siento que mucha gente está pensando en la utilidad de las consultas de contenedores, ¿sientes que también tienen potencial para aumentar la creatividad?
Miriam: Por supuesto, aunque no los veo completamente separados. Todos tenemos un tiempo limitado y estamos tratando de escribir código que se pueda mantener y funcione. Cuando algo es difícil en la práctica, es menos probable que nos volvamos creativos con lo que es posible.
Aun así, la industria web ahora está dominada por grandes intereses corporativos, por lo que esas preocupaciones comerciales siempre tienen más tiempo de transmisión que los artistas web. Y creo que perdemos mucho si ignoramos la creatividad web como el caso de uso principal de las funciones. Estoy muy emocionado de ver a algunos de los expertos en arte de CSS jugar con el prototipo de consulta de contenedores. Jhey Tompkins creó una demostración muy inteligente e interactiva de las persianas venecianas del CSS como comentario sobre el antiguo meme antiCSS. Creo que hay mucho más por explorar en ese espacio y tengo muchas ganas de ver qué más se te ocurren.
La conversación también se centró en las consultas basadas en el tamaño, como caso de uso original, pero me entusiasma ver qué hacen las personas con las consultas de estilo: la capacidad de escribir estilos condicionales según el valor de una propiedad o variable de CSS. Es una función sumamente potente, por lo que no se ha explorado hasta ahora. Creo que ofrece incluso más oportunidades creativas.
Rachel: ¿Hay algo que no podamos hacer (o que podamos hacer próximamente) en CSS que crees que sería útil?
Miriam: Estoy muy entusiasmada por algunas otras especificaciones en las que estuve trabajando. Las capas de cascada les darán a los autores más control sobre los problemas de especificidad, y el alcance debería ayudar con una segmentación por selector más precisa. Sin embargo, ambos son problemas de arquitectura de alto nivel. El artista está más entusiasmado por cosas como los botones de activación de CSS, una forma declarativa de crear estilos interactivos o las “líneas de tiempo” del contenedor, lo que nos permite hacer una transición fluida de los valores entre puntos de interrupción multimedia o de contenedores. Esto tiene implicaciones muy prácticas para la tipografía responsiva, pero también abriría muchas oportunidades creativas para el arte y la animación receptivos.
Rachel: ¿Quién más está realizando trabajos realmente interesantes, divertidos o creativos en la Web en este momento?
Miriam: Incluso no sé cómo responder a esa pregunta. Hay muchas personas que hacen trabajos creativos en áreas tan diferentes. Hay muchos estándares emocionantes en desarrollo tanto para CSSWG como Open-UI, incluidos algunos de tus trabajos sobre la fragmentación. Pero a menudo me inspiro más en los artistas web y en cómo las personas ponen estas herramientas en producción, de maneras que no están directamente vinculadas al comercio. Personas como Jhey, Lynn Fisher, Yuan Chuan y muchas otras que superan los límites de lo que las tecnologías web pueden hacer de forma visual e interactiva. Incluso las personas que realizan trabajos más orientados a los negocios pueden aprender mucho de sus técnicas artísticas.
También valoro el arte web más conceptual de personas como Ben Grosser, que nos obliga a reconsiderar lo que queremos de la Web, y de las redes sociales en particular. Mira su nuevo minus.social, por ejemplo.
Rachel: Mantente al tanto del trabajo de Miriam sobre CSS en css.oddbird.net y descubre qué más está haciendo a través de su sitio web (miriam.codes y Twitter @TerribleMia).