Miriam Suzanne es autor, artista y desarrolladora web en Denver, Colorado, y actualmente trabaja en interesantes especificaciones de CSS, como Container Queries y Cascade Layers.
Esta publicación forma parte de Designcember. Una celebración del diseño web, presentada por web.dev.
Miriam Suzanne es autora, artista y desarrolladora web en Denver, Colorado. Es cofundadora de OddBird (una agencia web), redactora de personal de Trucos de CSS, miembro del equipo principal de Sass y experta invitada de W3C en el Grupo de trabajo de CSS. Últimamente, se ha enfocado en desarrollar nuevas funciones de CSS, como capas en cascada, consultas de contenedores y alcance. Sin conexión, Miriam es una novelista, dramaturera y músico publicada. Hablamos sobre su trabajo con Sass y CSS.
Rachel: La primera vez me enteré de tu trabajo gracias a tu marco de trabajo de cuadrículas, Susy, ¿qué te llevó a crear eso?
Miriam: En 2008, el diseño en la Web fue una experiencia muy diferente. Los desarrolladores dejaron de lado el diseño de tablas por cuadrículas flotantes más semánticas (pero aún hackeadas). Hubo un auge en los "frameworks de cuadrícula" de 12 columnas de un tamaño único que proporcionaba una cuadrícula predefinida (generalmente estática) con un conjunto de clases de CSS predefinidas. Si necesitabas algo más personalizable, tenías que hacerlo por tu cuenta. Estaba claro que los sitios web necesitaban ser más receptivos, pero las consultas de medios aún no estaban disponibles, y había una gran cantidad de problemas de compatibilidad con los navegadores relacionados con los anuncios flotantes fluidos.
Estaba usando el enfoque de Sistemas CSS de Natalie Downe, que era inteligente cuando respondía tanto a tamaños de fuente como de viewport, pero me frustraban los cálculos matemáticos repetitivos y los hackeos del navegador que necesitaban. Al mismo tiempo, Sass estaba empezando a recibir algo de atención y se ajustaba perfectamente a lo que necesitaba. El primer borrador de Susy fue muy simple: solo un par de combinaciones para hacer los cálculos y agregar los trucos que necesitaba. El objetivo era ser mínimo y generar solo el código esencial. Cuadrículas completamente personalizables, sin clases predefinidas.
Rachel: ¿Cómo pasaste de trabajar en un preprocesador de CSS a trabajar en las especificaciones de CSS? ¿Crees que trabajar con el preprocesador fue una buena base para escribir especificaciones?
Miriam: En mi experiencia, hay muchas superposiciones, y sigo siendo muy activo en ambos lados de esa división. 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: tratar de desarrollar herramientas que se integren sin problemas con el desarrollo de estándares web. Ir más allá de un modelo universal y “orientado” soluciones y crear flexibilidad a largo plazo es fundamental cuando se piensa en el futuro de los estándares web centrales.
¿Cómo podemos crear herramientas que respeten la diversidad de las necesidades y los enfoques de los desarrolladores, sin dejar de fomentar y facilitar la accesibilidad y otras consideraciones importantes?
Rachel: Hay un montón de elementos que llegan a CSS que básicamente reemplazan la funcionalidad que tradicionalmente formaba parte de Sass. ¿Hay razones sólidas para seguir usando algo como Sass?
Miriam: Sí, para algunas personas, pero no hay una respuesta universal. Tomemos las variables como ejemplo. Las variables de Sass tienen un alcance léxico y se compilan en el servidor, con estructuras de datos organizadas, como listas y objetos, manipulación de color, etc. Eso es excelente para la lógica del sistema de diseño que no necesita ejecutarse en el navegador.
Las variables de CSS se superponen un poco, 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 no puede manejar datos estructurados. Ambas opciones son útiles y ambas son eficaces, pero sus necesidades específicas pueden variar.
Creo que es genial cuando las personas pueden eliminar las herramientas que ya no necesitan, y es posible que algunos proyectos no requieran variables del servidor y del cliente. ¡Excelente! Pero es muy simple suponer que significa que son idénticos y que uno simplemente reemplaza al otro. Siempre habrá casos de uso en los que ocurrirá algo de lógica de diseño del servidor y otros, del cliente, incluso si llegamos al punto en que los lenguajes proporcionan esencialmente las mismas funciones. Los preprocesadores están con nosotros a largo plazo.
Rachel: ¿Hay algo que te haya sorprendido a medida que te involucres más en el trabajo de creación de estándares o algo que crees que el público generalmente no está al tanto del proceso?
Miriam: Antes de involucrarme, el proceso de estándares me pareció una caja negra misteriosa y mágica, y no estaba segura de qué esperar. Tenía miedo de no tener suficiente conocimiento de los usuarios internos del navegador para contribuir, pero la realidad es que no necesitan más ingenieros de navegador. Necesitan más desarrolladores y diseñadores que estén creando sitios web y aplicaciones en un entorno real.
Me sorprendió descubrir que muy pocas personas involucradas se enfocan principalmente en los estándares, pero también muy pocas de ellas se dedican principalmente a desarrollar o diseñar sitios web. El W3C está formado por “voluntarios” de organizaciones miembros (a menudo pagadas por 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 de aquellos que trabajamos con clientes en agencias pequeñas o que son independientes. Mi función como Experto invitado sería totalmente voluntaria, un pasatiempo costoso, si no hubiera encontrado financiación externa para ese trabajo.
En realidad, el proceso es bastante abierto y público, y requiere la participación de los desarrolladores. Sin embargo, siempre hay tantas conversaciones a la vez que puede ser difícil encontrar tu lugar. Sobre todo si no es tu trabajo diario.
Rachel: Las consultas a contenedores han sido el santo grial para muchos desarrolladores web durante muchos años. Estoy muy emocionado de que las tengamos. Siento que muchas personas están pensando en la utilidad de las consultas de contenedores. ¿Crees que también tienen el potencial de desbloquear más creatividad?
Miriam: Por supuesto, aunque no los veo como algo completamente independiente. Todos tenemos poco tiempo, y estamos tratando de escribir código que se pueda mantener y que tenga buen rendimiento. Cuando algo es difícil de hacer en la práctica, es menos probable que usemos de forma creativa lo que es posible.
Aun así, la industria web ahora está dominada por grandes intereses corporativos, por lo que esas inquietudes comerciales siempre tienen más tiempo de comunicación que los artistas de la Web. Y creo que perderemos mucho si ignoramos la creatividad web como caso de uso principal para las funciones. Me entusiasma mucho ver a algunos expertos en CSS jugar con el prototipo de consulta de contenedores. Jhey Tompkins creó una demostración interactiva y inteligente de las persianas venecianas de CSS como comentario sobre un antiguo meme anti-CSS. Creo que hay mucho más para explorar en ese espacio y estoy ansioso por ver qué otras cosas se le ocurrirán.
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 en función del valor de una propiedad o variable de CSS. Es una función extremadamente eficaz, pero hasta ahora no se ha explorado mucho. Creo que abre aún más oportunidades creativas.
Rachel: ¿Hay algo que no podamos hacer (o que tengamos previsto hacer) en CSS que creas que sería útil?
Miriam: Estoy muy entusiasmada con otras especificaciones en las que estuve trabajando. Las capas en cascada le darán a los autores más control sobre los problemas de especificidad, y el alcance debería ayudar con una orientación del selector más precisa. Pero ambos son problemas arquitectónicos de alto nivel. El artista en mí está más emocionado por aspectos como los botones de activación de CSS, una forma declarativa de crear estilos interactivos o los “cronogramas” de los contenedores, que nos permiten transferir sin problemas valores entre puntos de interrupción de medios o contenedores. Eso tiene implicaciones muy prácticas para la tipografía responsiva, pero también abriría muchas oportunidades creativas para el arte responsivo y la animación.
Rachel: ¿Quién más está haciendo un trabajo realmente interesante, divertido o creativo en la Web en este momento?
Miriam: No sé cómo responder a esa pregunta. Hay muchas personas que hacen trabajos creativos en áreas tan diferentes. Hay mucho trabajo de estándares interesantes en curso, tanto del CSSWG como de Open-UI, incluido parte de tu trabajo sobre la fragmentación. Pero a menudo encuentro más inspiración de los artistas web y de cómo las personas ponen estas herramientas en producción, de maneras que no están directamente ligadas al comercio. Personas como Jhey, Lynn Fisher, Yuan Chuan y muchas otras que están desafiando los límites de lo que las tecnologías web pueden hacer de manera interactiva y visual. Incluso las personas que realizan más trabajos orientados al negocio 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 presiona constantemente para que reconsideremos lo que queremos de la Web y, en particular, de las redes sociales. Echa un vistazo a su nueva función minus.social, por ejemplo.
Rachel: Mantente al día con el trabajo de Miriam sobre CSS en css.oddbird.net y descubre qué más está haciendo a través de su sitio web en miriam.codes y la cuenta de Twitter @TerribleMia.