Miriam Suzanne es autora, artista y desarrolladora web en Denver, Colorado, y actualmente trabaja en especificaciones de CSS interesantes, 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), escritora del personal de CSS Tricks, miembro del equipo principal de Sass y experta invitada del W3C en el equipo de trabajo de CSS. Últimamente, se ha enfocado en desarrollar nuevas funciones de CSS, como las capas en cascada, las consultas de contenedores y el alcance. Fuera de línea, Miriam es novelista, dramaturga y música publicada. Hablamos sobre su trabajo con Sass y CSS.
Rachel: Conocí tu trabajo por primera vez gracias a tu framework de cuadrícula Susy. ¿Qué te llevó a crearlo?
Miriam: En 2008, el diseño en la Web era una experiencia muy diferente. Los desarrolladores habían dejado de usar el diseño de tablas para usar cuadrículas flotantes más semánticas (aunque seguían siendo hackeadas). Hubo un auge de los "frameworks de cuadrícula" de 12 columnas universales, que proporcionaban una cuadrícula predefinida (por lo general, estática) con un conjunto de clases de CSS predefinidas. Si necesitabas algo más personalizable, tenías que hacerlo por tu cuenta. Era evidente que los sitios web debían ser más responsivos, pero las media queries aún no estaban disponibles y había muchos problemas de compatibilidad del navegador con los elementos flotantes fluidos.
Estaba usando el enfoque de Sistemas CSS de Natalie Downe, que era inteligente para responder a los tamaños de fuente y de viewport, pero me frustraba toda la matemática repetitiva y los hacks del navegador que se requerían. Al mismo tiempo, Sass comenzaba a llamar la atención, y se ajustaba perfectamente a lo que necesitaba. El primer borrador de Susy era muy simple: solo un par de mixins para hacer los cálculos y agregar los hacks que necesitaba. El objetivo era ser minimalista y solo generar el código esencial. Cuadrículas totalmente personalizables, sin clases predefinidas.
Rachel: ¿Cómo pasaste de trabajar en un preprocesador de CSS a trabajar en especificaciones de CSS? ¿Crees que trabajar en el preprocesador fue una buena experiencia para escribir especificaciones?
Miriam: En mi experiencia, hay mucha superposición, y sigo siendo muy activa en ambos lados de esa división. Pero creo que eso se debe en gran medida al equipo de Sass en particular, liderado por Natalie Weizenbaum, que tiene una visión a muy largo plazo y trata de desarrollar herramientas que se integren sin problemas con los estándares web en desarrollo. Cuando piensas en el futuro de los estándares web principales, es fundamental ir más allá de las soluciones "dogmáticas" que se adaptan a todos y crear soluciones con flexibilidad a largo plazo.
¿Cómo podemos crear herramientas que respeten la diversidad de las necesidades y los enfoques de los desarrolladores, a la vez que fomentan y facilitan la accesibilidad y otras consideraciones importantes?
Rachel: Se incorporarán muchas funciones a CSS que reemplazarán la funcionalidad que tradicionalmente formaba parte de Sass. ¿Existen 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 colores, etcétera. Esto es ideal para la lógica del sistema de diseño que no necesita ejecutarse en el navegador.
Las variables de CSS se superponen en cierta medida, ya que también pueden almacenar valores, pero proporcionan un conjunto completamente diferente de fortalezas y debilidades basadas en la cascada. Sass no puede controlar propiedades personalizadas, y CSS no puede controlar datos estructurados. Ambas son útiles y potentes, pero tus 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! Sin embargo, es demasiado simple suponer que eso significa que son idénticos y que uno simplemente reemplaza al otro. Siempre habrá casos de uso en los que cierta lógica de diseño se ejecute en el servidor y otra en el cliente, incluso si llegamos al punto en que los lenguajes proporcionan esencialmente las mismas funciones. Los preprocesadores llegaron para quedarse.
Rachel: ¿Hay algo que te haya sorprendido a medida que te involucraste más en el trabajo de crear estándares o algo que crees que la gente en general podría no saber sobre el proceso?
Miriam: Antes de participar, el proceso de estándares me parecía una caja negra misteriosa y mágica, y no sabía qué esperar. Me preocupaba no tener suficientes conocimientos sobre el funcionamiento interno del navegador para hacer contribuciones, 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 mundo real.
Me sorprendió descubrir que muy pocas de las personas involucradas se enfocan principalmente en los estándares, pero también que muy pocas de ellas se dedican principalmente a desarrollar o diseñar sitios web. El W3C está formado por "voluntarios" de organizaciones miembro (a menudo, estas organizaciones les pagan, pero no es su trabajo principal), y la membresía no es barata. Esto sesga a los participantes y los aleja de los diseñadores y desarrolladores cotidianos, en especial a quienes trabajamos con clientes en agencias pequeñas o como freelancers. Mi rol como experto invitado sería totalmente voluntario, 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, pero siempre hay tantas conversaciones en curso que puede ser difícil encontrar tu lugar. Especialmente si no es tu trabajo diario.
Rachel: Las consultas de contenedor han sido el santo grial para muchos desarrolladores web durante años. Me entusiasma mucho el hecho de que los obtendremos. 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 las veo como completamente separadas. Todos tenemos tiempo limitado y tratamos de escribir código que se pueda mantener y que tenga un buen rendimiento. Cuando algo es difícil de hacer en la práctica, es menos probable que seamos 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 emisión que los artistas web. Creo que perdemos mucho si ignoramos la creatividad web como caso de uso principal de las funciones. Me entusiasma ver a algunas personas que crean arte con CSS experimentar con el prototipo de consultas de contenedor. Jhey Tompkins creó una demostración interactiva y particularmente ingeniosa de persianas venecianas en CSS como comentario sobre el viejo meme anti-CSS. Creo que hay mucho más para explorar en ese espacio, y no puedo esperar a ver qué más se les ocurre a las personas.
La conversación también se centró en las consultas basadas en el tamaño, como el caso de uso original, pero me entusiasma ver lo que la gente hace con las consultas de estilo, es decir, la capacidad de escribir estilos condicionales basados en el valor de una propiedad o variable de CSS. Es una función extremadamente potente y, hasta el momento, poco explorada. Creo que abre aún más oportunidades creativas.
Rachel: ¿Hay algo que no podamos hacer (o que pronto podremos hacer) en CSS que creas que sería útil?
Miriam: Me entusiasman mucho otras especificaciones en las que he estado trabajando. Las capas en cascada les darán a los autores más control sobre los problemas de especificidad, y el alcance debería ayudar a segmentar los selectores de forma más precisa. Sin embargo, ambas son inquietudes arquitectónicas de alto nivel. El artista que llevo dentro se entusiasma más con elementos como los botones de activación de CSS, una forma declarativa de crear estilos interactivos o "líneas de tiempo" de contenedores, que nos permiten realizar transiciones fluidas de valores entre los puntos de interrupción de medios o contenedores. Esto tiene implicaciones muy prácticas para la tipografía adaptable, pero también abriría muchas oportunidades creativas para el arte y la animación adaptables.
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 eso, hay muchas personas que hacen trabajos creativos en áreas muy diferentes. Tanto el CSSWG como Open-UI están trabajando en muchos estándares interesantes, incluido tu trabajo sobre la fragmentación. Sin embargo, a menudo encuentro la mayor inspiración en los artistas web y en la forma en que las personas utilizan estas herramientas en la producción, de maneras que no están directamente relacionadas con el comercio. Personas como Jhey, Lynn Fisher, Yuan Chuan y muchas otras que están ampliando los límites de lo que las tecnologías web pueden hacer visualmente y de forma interactiva. Incluso las personas que realizan un trabajo más orientado a los negocios pueden aprender mucho de sus técnicas artísticas.
También aprecio el arte web más conceptual de personas como Ben Grosser, que nos impulsa a reconsiderar lo que queremos de la Web y de las redes sociales en particular. Por ejemplo, consulta su nuevo minus.social.
Rachel: Mantente al tanto del trabajo de Miriam en CSS en css.oddbird.net y descubre qué más hace en su sitio web miriam.codes y en Twitter @TerribleMia.