Miriam Suzanne é autora, artista e desenvolvedora da Web em Denver, Colorado, e atualmente trabalha em especificações CSS interessantes, como consultas de contêiner e camadas em cascata.
Esta postagem faz parte do Designcember. Uma celebração do web design, oferecida pelo web.dev.
Miriam Suzanne é autora, artista e desenvolvedora da Web em Denver, Colorado. Ela é cofundadora da OddBird (uma agência da Web), escritora da equipe do CSS Tricks, membro da equipe principal do Sass e especialista convidada do W3C no Grupo de trabalho de CSS. Recentemente, ela tem se concentrado em desenvolver novos recursos de CSS, como camadas em cascata, consultas de contêiner e escopo. Fora da Internet, Miriam é uma romancista, dramaturga e musicista publicada. Conversamos sobre o trabalho dela com Sass e CSS.
Rachel:conheci seu trabalho por causa do framework de grade Susy. O que levou você a criar isso?
Miriam:em 2008, o layout na Web era uma experiência muito diferente. Os desenvolvedores deixaram de usar o layout de tabela para usar grades flutuantes mais semânticas (mas ainda improvisadas). Houve um boom de "estruturas de grade" de 12 colunas de tamanho único, que forneciam uma grade predefinida (geralmente estática) com um conjunto de classes CSS predefinidas. Se você precisasse de algo mais personalizável, teria que se virar sozinho. Ficou claro que os sites precisavam se tornar mais responsivos, mas as media queries ainda não estavam disponíveis, e havia muitos problemas de compatibilidade do navegador com floats fluidos.
Eu estava usando a abordagem CSS Systems de Natalie Downe, que era inteligente ao responder aos tamanhos de fonte e de janela de visualização, mas fiquei frustrado com toda a matemática repetitiva e os hacks de navegador necessários. Ao mesmo tempo, o Sass começou a ganhar atenção e se encaixou perfeitamente no que eu precisava. O primeiro rascunho do Susy era muito simples: apenas alguns mixins para fazer os cálculos e adicionar os hacks de que eu precisava. O objetivo era ser minimalista e gerar apenas o código essencial. Grades totalmente personalizáveis, sem classes predefinidas.
Rachel:como você fez a transição de trabalhar com um pré-processador de CSS para trabalhar com especificações de CSS? Você acha que trabalhar no pré-processador foi uma boa experiência para escrever especificações?
Miriam:na minha experiência, há muita sobreposição, e ainda sou muito ativa nos dois lados dessa divisão. Mas acho que isso se deve principalmente à equipe do Sass, liderada por Natalie Weizenbaum, que tem uma visão de longo prazo e tenta desenvolver ferramentas que se integrem perfeitamente aos padrões da Web. É essencial ir além das soluções "opinativas" únicas e criar para flexibilidade de longo prazo ao pensar no futuro dos principais padrões da Web.
Como podemos criar ferramentas que respeitem a diversidade de necessidades e abordagens dos desenvolvedores, incentivando e facilitando a acessibilidade e outras considerações importantes?
Rachel:temos várias coisas chegando ao CSS que substituem funcionalidades que tradicionalmente faziam parte do Sass. Existem motivos fortes para ainda usar algo como o Sass?
Miriam:sim, para algumas pessoas, mas não há uma resposta universal. Por exemplo, variáveis. As variáveis Sass têm escopo léxico e são compiladas no servidor com estruturas de dados organizadas, como listas e objetos, manipulação de cores etc. Isso é ótimo para a lógica do sistema de design que não precisa ser executada no navegador.
As variáveis CSS têm alguma sobreposição, também podem armazenar valores, mas oferecem um conjunto totalmente diferente de pontos fortes e fracos com base em cascata. O Sass não processa propriedades personalizadas, e o CSS não processa dados estruturados. Ambos são úteis e eficientes, mas suas necessidades específicas podem variar.
Acho ótimo quando as pessoas podem eliminar ferramentas que não precisam mais, e alguns projetos podem não exigir variáveis do lado do servidor e do cliente. Excelente. Mas é muito simples presumir que isso significa que eles são idênticos e que um simplesmente substitui o outro. Sempre haverá casos de uso para que alguma lógica de design aconteça no lado do servidor e outra no lado do cliente, mesmo que cheguemos ao ponto em que as linguagens ofereçam essencialmente os mesmos recursos. Os pré-processadores estão conosco a longo prazo.
Rachel:há algo que surpreendeu você ao se envolver mais no trabalho de criação de padrões ou algo que você acha que as pessoas geralmente não sabem sobre o processo?
Miriam:antes de me envolver, o processo de padrões parecia uma caixa preta misteriosa e mágica, e eu não sabia o que esperar. Eu tinha medo de não ter conhecimento suficiente sobre o funcionamento interno do navegador para contribuir, mas a realidade é que eles não precisam de mais engenheiros de navegador. Eles precisam de mais desenvolvedores e designers que criem sites e aplicativos.
Fiquei surpreso ao descobrir que poucas das pessoas envolvidas se concentram principalmente em padrões, mas também que poucas delas desenvolvem ou projetam sites. O W3C é formado por "voluntários" de organizações membros (geralmente pagos por essas organizações, mas não como trabalho principal), e a associação não é barata. Isso afasta os participantes dos designers e desenvolvedores do dia a dia, especialmente aqueles que trabalham para clientes em pequenas agências ou como freelancers. Minha função como especialista convidado seria totalmente voluntária, um hobby caro, se eu não tivesse encontrado financiamento externo para esse trabalho.
Na realidade, o processo é bastante aberto e público e precisa do envolvimento dos desenvolvedores. No entanto, há sempre tantas conversas acontecendo ao mesmo tempo que pode ser difícil encontrar seu lugar. Principalmente se não for seu trabalho principal.
Rachel:as consultas de contêineres são o Santo Graal para muitos desenvolvedores da Web há anos. Estou muito feliz por isso. Parece que muita gente está pensando na utilidade das consultas de contêiner. Você acha que elas também têm potencial para despertar mais criatividade?
Miriam:Com certeza, mas não vejo essas coisas como totalmente separadas. Todos nós temos tempo limitado e estamos tentando escrever um código que possa ser mantido e tenha bom desempenho. Quando algo é difícil de fazer na prática, é menos provável que sejamos criativos com o que é possível.
Ainda assim, o setor da Web é dominado por grandes interesses corporativos, e essas preocupações comerciais sempre têm mais espaço do que os artistas da Web. Acho que perdemos muito se ignorarmos a criatividade na Web como um caso de uso principal para recursos. Fiquei muito feliz em ver algumas pessoas que trabalham com arte em CSS testando o protótipo de consulta de contêiner. Jhey Tompkins criou uma demonstração particularmente inteligente e interativa de persianas venezianas em CSS como um comentário sobre o antigo meme anti-CSS. Acho que há muito mais para explorar nesse espaço, e mal posso esperar para ver o que mais as pessoas vão criar.
A conversa também se concentrou em consultas baseadas em tamanho, como o caso de uso original, mas estou animado para ver o que as pessoas fazem com consultas de estilo: a capacidade de escrever estilos condicionais com base no valor de uma propriedade ou variável CSS. É um recurso extremamente avançado e, até agora, pouco explorado. Acho que isso abre ainda mais oportunidades criativas!
Rachel:há algo que não podemos fazer (ou que teremos uma maneira de fazer) em CSS que você acha que seria útil?
Miriam:estou muito animada com algumas outras especificações em que tenho trabalhado. As camadas em cascata vão dar aos autores mais controle sobre problemas de especificidade, e o escopo vai ajudar com uma segmentação de seletores mais precisa. Mas ambos são problemas arquitetônicos de alto nível. O artista em mim está mais animado com coisas como alternâncias de CSS, uma maneira declarativa de criar estilos interativos ou "linhas do tempo" de contêineres, permitindo que façamos a transição suave de valores entre pontos de interrupção de mídia ou contêineres. Isso tem implicações muito práticas para a tipografia responsiva, mas também abre muitas oportunidades criativas para arte e animação responsivas.
Rachel:Quem mais está fazendo um trabalho interessante, divertido ou criativo na Web agora?
Miriam:Não sei nem como responder isso. Há tantas pessoas fazendo trabalhos criativos em áreas tão diferentes. Há muito trabalho em andamento sobre padrões interessantes do CSSWG e do Open-UI, incluindo parte do seu trabalho sobre fragmentação. Mas muitas vezes encontro mais inspiração em artistas da Web e em como as pessoas estão usando essas ferramentas na produção, de maneiras que não estão diretamente ligadas ao comércio. Pessoas como Jhey, Lynn Fisher, Yuan Chuan e muitas outras que estão ampliando os limites do que as tecnologias da Web podem fazer visualmente e de forma interativa. Até mesmo pessoas que trabalham mais com negócios podem aprender muito com técnicas artísticas.
Também gosto da arte conceitual na Web de pessoas como Ben Grosser, que nos incentiva a reconsiderar o que queremos da Web e das mídias sociais em particular. Confira o novo minus.social dele, por exemplo.
Rachel:acompanhe o trabalho de Miriam em CSS em css.oddbird.net e descubra o que mais ela está fazendo no site miriam.codes e no Twitter @TerribleMia.