Smashing Podcast Episódio 19 Com Andy Bell: O que é CUBE CSS?

Hoje vamos falar sobre CUBE CSS. O que é e como difere de abordagens como BEM, SMACSS e OOCSS? Falei com seu criador, Andy Bell, para descobrir.

Mostrar notas

• CUBO CSS
• Piccalilli
• Aprenda Eleventy From Scratch - economize 40%!
• Andy Bell e Piccalilli no Twitter

Nota : Os ouvintes do Smashing Podcast podem economizar 40% no curso Learn Eleventy From Scratch de Andy usando o código SMASHINGPOD .

Atualização semanal

• “O que Vitruvius pode nos ensinar sobre web design”
  por Frederick O'Brien
• “Uma introdução ao SWR: React Hooks for Remote Data Fetching”
  por Ibrahima Ndaw
• “Como os Web Designers podem ajudar os restaurantes a migrar para as experiências digitais”
  por Suzanne Scacca
• “Um guia prático para testar aplicativos React com Jest”
  por Adeneye David Abiodun
• “Django Highlights: Wrangling Static Assets and Media Files (Parte 4)”
  por Philip Kiely

Transcrição

Drew McLellan: Ele é um educador e web designer freelance baseado no Reino Unido e trabalhou nas indústrias de web designer por mais de uma década. Nesse período, ele trabalhou com algumas das maiores organizações do mundo, como Harley-Davidson, BSkyB, Unilever, Oracle e NHS. Ao lado de Heydon Pickering, ele é o coautor de Every Layout, além de administrar o Front-End Challenges Club, que se concentra em ensinar as melhores práticas de desenvolvimento de front-end por meio de desafios curtos e divertidos.

Drew: Seu mais recente empreendimento é o Piccalilli, um boletim informativo do site com tutoriais e cursos para ajudá-lo a subir de nível como desenvolvedor e designer de front-end. Sabemos que ele é um desenvolvedor e educador experiente, mas você sabia que ele foi a primeira pessoa autorizada a competir no Crufts com um panda?

Drew: Meus amigos do Smashing, sejam bem vindos, Andy Bell. Olá, Andy, tudo bem?

Andy Bell: Estou arrasando, obrigado. Como você está?

Drew: Estou muito bem, muito obrigado. Agora eu queria falar com você hoje sobre algo que você postou em seu site, Piccalilli, sobre uma metodologia CSS que você desenvolveu para si mesmo nos últimos anos. Em primeiro lugar, acho que provavelmente deveríamos explorar o que queremos dizer com uma metodologia CSS, porque isso pode significar coisas diferentes para pessoas diferentes. Então, quando você pensa na metodologia CSS, o que isso significa para você?

Andy: Essa é uma pergunta boa e difícil para começar, Drew. Aprecie isso, obrigado!

Draw: Bem vindo!

Andy: É complicado. Então, por contexto, eu usei BEM por um longo tempo, e isso é Block Element Modifier. Isso já existe há muito tempo. A maneira como eu vejo uma metodologia CSS é, não é um framework, é uma estrutura organizacional. É assim que eu gosto de ver. É como um processo quase. É como se você tivesse um problema que precisa resolver com CSS e usa a metodologia para resolvê-lo para você e manter as coisas previsíveis e organizadas. O BEM é lendário por isso porque tem sido um grande sucesso.

Andy: Então você quase pode qualificar coisas como os componentes de estilo e esse tipo de coisa. Você quase pode dizer que eles são orientados para a metodologia, embora sejam um pouco mais entrelaçados, mas ainda assim, é uma metodologia de quebrar as coisas em pequenas moléculas. Então, essencialmente, é isso que estou tentando fazer com o CUBE CSS também. Uma estrutura de pensamento, acho que a descrevi como.

Drew: Então é uma aplicação do processo de como você arquiteta e escreve CSS, e não é nada baseado em ferramentas ou qualquer outro tipo de tecnologia, é apenas uma espécie de fluxo de trabalho. Portanto, há muitas abordagens diferentes por aí. Você mencionou BEM. Há SMACSS, OOCSS, CSS Atomic. E então você tem esse tipo de abordagem incomum de filho do amor como ABEM. Você já viu aquele?

Andy: Sim.

Drew: Por que publicar o seu próprio?

Andy: Sim, sim. Por que fazer o seu próprio? Essa é uma pergunta muito boa. Acho que quem me conhece bem sabe que gosto muito de velejar contra a maré. É principalmente porque costumo fazer muitos projetos variados também, em equipes variadas. Então é muito difícil, eu descobri, trabalhar com BEM com um desenvolvedor tradicional porque eles estão acostumados a usar CSS para o que é CSS: a cascata, etc., e é por isso que eu roubei isso da linguagem .

Andy: Por outro lado, metodologias menos estruturadas, é mais difícil trabalhar com um programador, tipo JS, porque eles gostam de estrutura e organização e pequenos componentes, o que é compreensível trabalhando com a linguagem em que trabalham.

Andy: Então eu me encontrei nessas posições onde eu estava trabalhando com diferentes tipos de pessoas, diferentes tipos de projetos onde uma metodologia não estava funcionando. Ao longo dos anos, eu tenho brincado com essa ideia de como as coisas funcionam, e então há as coisas que eu e Heydon fizemos, cada layout, que meio que reforçou a grande parte disso, que é o C, a parte de composição , e então eu meio que evoluí muito rapidamente nos últimos seis meses.

Andy: A única razão pela qual escrevi um artigo sobre isso foi porque eu estava fazendo este curso e achei melhor escrever algum material suplementar para que as pessoas o entendessem, e é absolutamente explodido. Talvez ainda não tenhamos superado as metodologias, Drew.

Drew: Então o material do curso que você está montando realmente usa CUBE CSS como sua metodologia, não é?

Andy: Sim. Então, uns bons 50% do curso são na verdade front-end, mesmo sendo um curso ilimitado. É tão, tão profundamente entrelaçado na maneira como construímos o front-end que eu não poderia simplesmente dizer: “Ah, a propósito, é assim que escrevo um bom CSS” e depois deixá-lo. Eu sei que as pessoas gostam de entrar em detalhes, então eu estava tipo, o que vou fazer é escrever este post que é muito longo e muito detalhado e, se alguém quiser se aprimorar e realmente entender o que estamos fazendo , então eles podem fazer, e o resto é a partir daí. E aqui estamos nós hoje, Drew, sentados e conversando sobre isso.

Drew: Então, se alguém já entende BEM e talvez já esteja usando BEM, como exemplo, porque essa é provavelmente uma das metodologias mais adotadas, não é? Então, se eles já entenderam o BEM e estão vindo para o CUBE, isso é algo que eles achariam fácil de adotar? Há muitas semelhanças ou é completamente diferente?

Andy: Sim. Eu diria que ir do BEM para o CUBE é provavelmente uma transição suave, especialmente do jeito que eu ainda gosto de escrever o CSS para o CUBE. Então, a maioria das coisas está acontecendo em um nível mais alto. Então está acontecendo no nível da cascata e está acontecendo CSS global, usando os utilitários para fazer muitas coisas. Mas quando você entra em detalhes, são componentes, blocos e elementos muito parecidos com BEM. A única coisa que é um pouco diferente do BEM é que, em vez de ter modificadores, usamos essa coisa chamada exceções, que é, em vez de usar classes CSS, ele se transforma em atributos de dados, o que acho que dá uma boa separação e um real exceção, que é o que um modificador deve ser.

Andy: Parte da razão pela qual eu meio que me afastei do BEM foi porque descobri que a maneira como estava trabalhando com ele, especialmente em sistemas de design, era que os modificadores eram dominados e isso se tornou um problema porque era tipo, qual é o papel do meu bloco neste momento? Porque se estou modificando-o ao ponto de ficar irreconhecível regularmente, essa metodologia ainda está funcionando como deveria funcionar?

Andy: Depois, há todo o material de token de design, o material que Jina fez com o Lightning Design System, que todos começamos a adotar agora. O material da classe utilitária realmente começou a fazer sentido com essa abordagem. Então eu meio que esmaguei todas as coisas que gosto no trabalho de outras pessoas e coloquei no meu.

Drew: Você fala sobre o BEM, o tipo de abordagem modificadora que sai do controle. Esse foi um dos principais pontos problemáticos do BEM que o CUBE tenta resolver?

Andy: Sim, absolutamente. Eu gosto da abordagem do modificador com BEM, faz sentido. O que eu gosto no BEM é algo que ainda faço, é o sublinhado duplo para um elemento e depois há o traço duplo para um modificador. Eu gosto dessa maneira de organizar as coisas. Foi apenas um caso de ok, bem, muitos dos modificadores que eu posso explicar com classes de utilidade e depois os outros bits…

Andy: Então o exemplo que eu uso no artigo é, imagine que você tem um cartão e então o cartão é virado, então o conteúdo aparece antes da imagem. Então isso faz sentido, para ver display: flex e então você inverte, inverte a ordem. Isso faz sentido, ter uma regra de exceção para isso porque é uma exceção do estado padrão do cartão, e é assim que eu gosto de ver. É como um estado afetado nesse componente, é o que é uma exceção, e isso faz sentido.

Andy: Com muitas das coisas que fiz mais recentemente, a pilha de front-end moderna com JavaScript reativo, há muitas mudanças de estado e faz sentido lidar com isso adequadamente entre CSS e JavaScript porque eles estão se tornando cada vez mais mais entrelaçados uns com os outros, quer você goste ou não. É uma linguagem comum para eles. Como você pode ver pelo meu rosto, muito não, mas lá vai. Você provavelmente está pensando: “Na verdade, tenho trabalhado bastante com o react recentemente, então sou o contrário”. Então eu posso ver isso também.

Drew: Então vamos entrar no CUBE. Então CUBE significa Composition Utility Block Exception. Isso está certo?

Andy: Sim. Esse é o único.

Drew: O que diabos isso significa?

Andy: Ah, cara, você deveria ter ouvido antes! Eu estava fazendo uma palestra no ano passado. Eu fiz uma palestra, e foi chamada Keeping it Simple with CSS that scales, e lá eu meio que apresentei uma versão anterior chamada CBEUT, que era o Cascade Block Element Utility Token. Era uma porcaria. Eu odiava o nome disso. Eu fiz isso algumas vezes, essa palestra no ano passado, e eu realmente não gostei do nome. Então, quando comecei a fazer essas coisas este ano, pensei: “Eu realmente preciso pensar sobre o que realmente é e como se chama”. Eu acho que CUBE é um pouco menos lixo. Acho que essa é a melhor maneira que posso descrevê-lo.

Andy: Mas então, nomes são sempre lixo para essas coisas, não são? Quero dizer, como BEM, que nome ruim é esse! Mas todos nós fazemos isso. Olhe para Jamstack: esse também é um nome terrível, não é?

Drew: Meus lábios estão selados!

Andy: Seu chefe está dizendo: “O quê?” É verdade. É assim que é, não é, em nossa indústria.

Drew: Parece que muitas das metodologias CSS tentam contornar alguns dos recursos do CSS, coisas como a cascata. Meu entendimento pelo que li é que o CUBE tenta fazer uso desses tipos de recursos e propriedades do CSS.

Andy: Sim. Uma boa analogia para isso é SCSS, como Sass, é uma extensão da linguagem CSS natural, não é? Você está praticamente certo em CSS ainda. Então CUBE CSS é assim. Então é uma extensão do CSS. Então ainda devemos escrever CSS, como CSS deveria... bem, deveria ser escrito. Sejamos honestos, como deveria ser escrito, é o nome que revela: Cascading Style Sheets. Então, está abraçando isso novamente porque o que descobri é que desci até o nível de micro-otimização. Eu estive no caminho que vejo muitas pessoas indo recentemente onde... e eu mencionei isso no artigo também, onde eu posso ver... há alguma evidência disso recentemente. Eu vi pessoas criando componentes espaçadores e coisas assim, e eu entendo esse problema, eu estive nessa situação.

Andy: A maneira como consertei foi que, em vez de detalhar e tentar micro-otimizar, comecei a pensar nas coisas em um nível de composição, porque não importa quão pequenos sejam seus componentes, em algum momento eles vão para serem páginas, elas serão visualizações. Você não pode evitar isso, é assim que vai ser. Então, em vez de tentar dizer: “Certo, preciso desses pequenos ajudantes para fazer esse layout”, você diz: “Certo, tenho uma visualização de página de contato ou uma visualização de página de produto, e essa é uma composição de layout esquelética. Então, dentro disso, posso encaixar os componentes que quiser.” Temos coisas como Grid e Flexbox agora que tornam isso muito mais viável, e você pode essencialmente colocar o que quiser dentro do layout do esqueleto, não importa. Em seguida, os componentes devem, nesse ponto, se comportar como você deseja que eles se comportem, com ou sem consultas de contêiner.

Drew: Esta é a parte de composição do CUBE onde você observa as coisas em um nível mais macro, observando como os componentes podem ser compostos em uma visualização para criar o tipo de página que você precisa criar para um site ou aplicativo ou o que você tem.

Andy: Então está criando regras, essencialmente. É como orientação. Está tentando obter diretrizes para algo. Não é como uma regra rígida, tipo, você deve fazer isso, você deve fazer aquilo. Isso é essencialmente o que você está fazendo com o navegador, com essa metodologia, você está dizendo... você não está forçando-o a fazer nada. Você está dizendo: “Olha, idealmente, se você pudesse colocar assim, seria ótimo, mas eu entendo que esse pode não ser o caso, então aqui estão alguns limites e alguns níveis superiores e inferiores com os quais podemos trabalhar. Faça o que puder, e aplausos.” Então você apenas joga alguns componentes nele e deixa-o fazer o que faz. Você adiciona controle suficiente para que não pareça lixo.

Andy: Então, um bom exemplo seria… fazemos um layout em Every Layout chamado switcher, que essencialmente irá itens in-line até um certo ponto onde o cálculo que determina a largura que deve apenas empilhá-los um em cima do outro . Mas porque adicionamos margem ao in-line e ao bloco, ele funciona, independentemente do estado dele, ainda parece bom. Essa é a ideia, não estamos dizendo ao navegador para dizer: “Você deve colocar essa grade de três colunas em camadas”. Estamos dizendo: “Se você puder sobrepor uma grade de três colunas, faça-o. Caso contrário, apenas empilhe e espalhe.” Então é esse tipo de metodologia, de deixar o navegador realmente fazer seu trabalho.

Drew: Muitas das diferentes abordagens que surgiram para CSS nos últimos anos se concentraram muito no nível de componente de lidar com tudo como se fosse um componente. O CUBE não minimiza tanto esse aspecto de componente, apenas oferece esse conceito extra além de pegar esses componentes e compô-los em layouts maiores, em vez de apenas dizer que o layout é apenas mais um componente.

Andy: Sim, esse é um bom ponto, sim. Acho que a coisa a dizer sobre componentes é que eles são importantes, especialmente em coisas modernas de front-end. Fazemos muitas coisas de componentes, coisas de sistema. Mas do jeito que eu vejo um componente, é uma coleção de regras que estendem o que já foi feito.

Andy: O que quero dizer no artigo é que, no momento em que você chega ao nível do bloco, a maior parte do seu estilo já foi feita, e realmente o que seu componente está fazendo é pontilhar os Is e cruzar os Ts e está dizendo: “Certo, neste contexto…” Então, para um cartão, por exemplo, faça a imagem ter uma altura mínima de X e adicione um pouco de preenchimento aqui. Faça isso, aquilo e aquilo. Coloque um botão aqui. São apenas regras adicionais em cima do que já foi herdado do resto do CSS. Acho que essa é provavelmente a melhor maneira de descrevê-lo.

Andy: Enquanto no BEM, o componente é a fonte da verdade. Até você colocar essa classe no elemento, nada foi aplicado nesse ponto e esse método funciona. Acabei de descobrir que escrevi mais CSS fazendo isso e CSS mais repetitivo, o que não gosto de fazer.

Drew: Você consideraria que a tipografia e as cores e os ritmos verticais, espaçamentos e tudo isso faz parte da ideia de composição neste modelo?

Andy: Sim. Em um CSS global, sim, absolutamente. O ritmo vertical especialmente, e o fluxo. Fizemos um artigo sobre isso em 24 maneiras, não fizemos, há alguns anos, o componente de fluxo e ritmo. Isso também foi uma espécie de resumo dessa abordagem, onde você define um componente base que usa essencialmente o seletor de coruja lobotomizado. Não sei como vou descrever isso no rádio, mas vamos. Vamos colocar, eu acho, nas notas do programa sobre o artigo de Heydon ou algo assim. Mas essencialmente isso, ele seleciona elementos filho... desculpe, elementos irmãos.

Andy: Então ele diz: “Certo, todo elemento que segue o elemento X tem margem superior aos custos de CSS e valor da propriedade”, e a beleza disso é que você também pode definir esse valor de propriedade personalizada CSS em um contexto de composição. Então você pode dizer: "Certo, neste componente, se houver algum fluxo em movimento, definiremos o espaço de fluxo para ser dois rem porque queremos que seja bom e robusto, o espaço amplo". Então, em outro, você pode dizer: “Na verdade, quero que o espaço de fluxo seja meio rem porque quero que seja apertado”. Tudo isso está acontecendo, todo o controle vem de um nível superior e então o que você está fazendo é adicionar substituições contextuais em vez de reinventá-lo a cada vez, reinventando a mesma coisa repetidamente.

Drew: Então esse é o C, Composição. Em seguida, temos U, que é Utility. Então, o que queremos dizer com utilidade?

Andy: Então é uma classe que faz um trabalho, e faz muito bem. Isso poderia ser uma implementação de um token de design que... é um resumo de propriedades. Geralmente são cores ou estilos de tipografia, tamanhos e regras assim. A ideia é você gerar classes utilitárias que as apliquem. Então você tem um utilitário que aplicará o fundo primário, que é como a cor primária, e depois a cor primária, que é a cor do texto. Então você pode gerar alguns tokens de espaçamento para preenchimento marginal e todo esse tipo de coisa. Eles só fazem um trabalho. Eles apenas adicionam aquela regra de espaçamento, aquela regra de cor e pronto.

Andy: Mas você também tem outros utilitários. Portanto, um bom exemplo é um utilitário wrapper. O que isso fará é colocar uma largura máxima em um elemento e, em seguida, colocará margem automática esquerda e direita para colocá-lo no meio da coisa. Então, ela tem apenas um trabalho, e está apenas fazendo isso com eficiência e bem.

Andy: Então você tem seus estilos globais, você fez muitas configurações de tipografia e muito do seu espaço de piso. Sua composição está dando contexto e layout. Em seguida, os utilitários estão aplicando tokens diretamente aos elementos para dar a eles o estilo de que você precisa. Assim, como um título, por exemplo, você está dizendo: “Quero que seja desse tamanho e que tenha esse lead, e quero que tenha essa medida”. Então, nesse ponto... isso é o que eu estava dizendo sobre os blocos... então você desce na pilha e já fez a maior parte do trabalho no ponto.

Andy: Então, eles oferecem uma maneira realmente eficiente de trabalhar, e como o HTML também flui pelo cano, é muito bom abstrair a carga de trabalho em HTML em vez de CSS também, eu descobri. Eu costumava realmente entrar em classes utilitárias, como nesse tipo de velho estilo rabugento de “Ah, separação de interesses”, mas na verdade acho que é uma maneira realmente decente de trabalhar. Eu mencionei no artigo que eu realmente gosto do Tailwind CSS. Eu acho que funciona, e eu realmente gosto de usá-lo para digitação de produtos porque eu posso realmente lançar algo muito rápido. Mas acho que vai um pouco longe demais, faz Tailwind, enquanto eu gosto de chover quando vai além de apenas aplicar uma única regra em uma classe. Então é isso, eu acho. Você?

Drew: Então, sim, você fala muito no artigo sobre tokens de design, que é algo sobre o qual falamos no Smashing Podcast com Jina Anne no episódio três, acho que foi. Portanto, parece que os tokens de design são um aspecto realmente fundamental.

Andy: Sim. Oh, Deus, sim. Lembro-me tão vividamente de quando Jina estava fazendo as coisas do Lightning Design System porque eu estava construindo um sistema de design na época, ou algo que se assemelhava a um sistema de design, e estávamos lutando para obter a aprovação executiva disso. Quando o Lightning Design System foi lançado, eu literalmente apenas enviei link após link e disse: “É isso que estamos fazendo. Estamos construindo um sistema de design. É para isso que a Salesforce está usando atualmente.” Lembro-me que o trabalho dela na época realmente me ajudou a passar as coisas pela porta.

Andy: Então, o material de token de design sempre ficou comigo como sendo uma maneira muito boa de aplicar essas regras. Como sou designer de profissão, posso ver essa organização e a capacidade de organizar e criar uma única fonte de verdade sendo realmente útil porque é algo que realmente não tínhamos no design digital, especialmente no Adobe era de trabalhar com Photoshop e outras coisas, nós simplesmente não tínhamos esse luxo. Nós o tínhamos impresso com o Pantone Book, mas não o tínhamos em formato digital com códigos hexadecimais aleatórios por toda a loja.

Andy: Então é ótimo. Eu amo esse nível de controle. Na verdade, acho que ajuda na criatividade porque você não está mais pensando em coisas sem importância, está apenas pensando no que está fazendo com isso.

Drew: A implementação desses tokens de design é particularmente importante para a abordagem? É sempre propriedades personalizadas CSS?

Andy: Eu acho que esse é um ponto muito importante com o CUBE. Algumas das respostas que tive, as pessoas lutaram um pouco com isso. Não há nenhuma menção de tecnologia nele. A única tecnologia consistente é CSS. Você pode fazer como quiser. Você pode fazer tudo isso com qualquer coisa de CSS e JS que as pessoas estejam fazendo agora, ou você pode apenas com Vanilla CSS. Você poderia fazer isso com Sass. Eu faço isso com Sass. Menos, se é isso que você ainda está fazendo. Todas essas tecnologias disponíveis, pós CSS, todas essas coisas. Você pode fazer o que quiser, não importa.

Andy: A ideia é que, se você seguir esse tipo de construção, ficará bem. Essa é a ideia por trás disso. É muito solto e não rigoroso como algumas das metodologias são. Eu vi isso especialmente com o BEM, as pessoas ficam realmente enraizadas nos princípios do BEM a ponto de parecer que você não está mais resolvendo o problema. Eu acho que você tem que ser flexível. Eu disse isso nesta palestra no ano passado. Eu estava tipo, “Se você mantiver suas armas com muita força, você pode realmente causar problemas para si mesmo a longo prazo, porque você tenta seguir um certo caminho e sabe que não está mais funcionando”. Você deve sempre ser flexível e trabalhar com um sistema em vez de trabalhar ao pé da letra.

Drew: Então o B, o B é Block. Você falou sobre essa ideia, que no momento em que você chega ao nível do bloco, a maior parte de tudo deve estar no lugar, e então o estilo do nível do bloco está realmente preocupado apenas com os detalhes reais de um componente específico. Geralmente, o conceito de bloco é semelhante ao que as pessoas estarão familiarizadas?

Andy: Ah, com certeza, sim. Então imagine seu componente BEM e tire todas as coisas visuais dele, e é isso que resta, essencialmente, o bloco. Foi isso que me esforcei para articular quando comecei a pensar nessa metodologia. Um bloco é na verdade um C, é uma composição, mas isso torna muito difícil porque você está em território recursivo lá e acho que o cérebro das pessoas explodiria. Mas realmente é isso que um bloco é, na verdade é outra camada de composição, mas mais como um tipo de contexto estrito, como seu cartão, seu botão, seu carrossel, se é isso que você ainda gosta de fazer, e todo esse tipo de coisa.

Andy: É como uma coisa específica, um componente, e aí dentro você está definindo regras específicas para seguir, realmente ignorando o resto para que você não… Você pode aplicar tokens nos blocos, e eu faço isso ainda, mas realmente é mais orientado ao layout, é um bloco, até onde eu trabalho com eles, ou pelo menos pegar o token e aplicá-lo de uma maneira específica, como um status de foco de botão, coisas assim. Então, na verdade, seu bloqueio deve ser pequeno quando você chegar até eles, eles não devem estar fazendo muita coisa.

Drew: Então pode ser tão pequeno quanto um hiperlink.

Andy: Sim.

Drew: Mas também poderia ser uma coleção composta de outros blocos?

Andy: Sim. Como uma espécie de módulo. Você definitivamente poderia fazer isso. Porque, novamente, isso remonta ao tipo de aspecto composicional, é que o que quer que esteja nele não deveria importar. O bom exemplo disso é como o cartão. Assim, o conteúdo de um cartão é, digamos, um título, um resumo e um botão. Você realmente não deveria ter como alvo específico esses três elementos. Você deveria estar dizendo: “Olha, qualquer coisa que se encontre no conteúdo, tenha algumas regras de fluxo e algum tipo de regra de layout de composição”, e então não importa o que você coloca lá. Você pode decidir que deseja colocar uma imagem nesse conteúdo e deve funcionar, deve ficar bem.

Andy: Esse é o objetivo de trabalhar com CSS. É uma maneira muito indulgente de trabalhar com CSS. Você está tornando sua vida muito mais fácil sendo menos rígido porque quando as coisas acidentalmente se encontram em algo, o que acontecerá, não parece horrível como poderia ser se você fosse mais específico sobre as coisas, é o que eu tenho encontrado.

Drew: Eu definitivamente preciso de muito perdão em torno do meu CSS!

Andy: Eu sei que você faz!

Drew: Saúde! Então esse é o B. A última coisa é E: E é Exception. Agora não estamos falando de mensagens de erro, estamos?

Andy: Não, não. É uma espécie de-

Drew: Não estamos falando de exceções JavaScript.

Andy: Sim, sim. Não deve haver nada disso neste momento. Espero que não de qualquer maneira, caso contrário você está realmente na floresta nesse ponto: eu não acho que serei capaz de ajudá-lo! A ideia disso é… então você criou o contexto com seu bloco, e uma exceção é exatamente isso, é como uma exceção à regra: então um cartão virado, ou pode ser um botão fantasma. Sabe aqueles botões que acabaram de ganhar uma borda e um fundo transparente? Isso seria uma exceção porque um botão provavelmente tem uma cor de fundo sólida e depois a cor do rótulo. Então está criando uma espécie de estado distinto de variação.

Andy: A razão pela qual eu faço isso com atributos de dados em vez de classes, e a razão pela qual isso é porque a) eu acho que é bom ter uma distinção. Então, quando você está examinando muito HTML, você pode ver dados, hífen algo, você fica tipo, “Certo, ok, algo definitivamente mudou neste elemento”. A outra coisa é que é muito bom dar acesso JavaScript a esse estado e vice-versa também. Então eu realmente gosto de aplicar estado com atributos de dados em JavaScript. Acho que é essencialmente para isso que servem, uma espécie de camada de comunicação. A harmonia entre eles parece funcionar muito bem.

Andy: Então, um bom exemplo é, digamos que você tenha uma mensagem de status e, em seguida, o JavaScript adicionará o estado dos dados seja sucesso, erro ou informação, ou algo assim. Você pode então se conectar a isso com seus estilos de exceção em CSS. Então você sabe que é uma exceção do componente de status e está indo contra seu estado padrão. Portanto, é apenas uma maneira realmente útil de trabalhar com as coisas. É previsível em ambas as extremidades: é previsível no CSS e também no JavaScript.

Drew: Acho que é muito bom que algo que os nomes de classe não dão seja uma propriedade e um valor. Então, se você quiser ter algo parecido com o que é o estado, e pode ser sucesso ou falha ou aviso ou o que quer que você tenha, você pode abordar especificamente essa propriedade de estado e inverter seu valor. Considerando que com uma longa lista de nomes de classes, se você estiver manipulando isso em JavaScript, por exemplo, você terá que olhar para cada um deles e adicionar aquela lógica de negócios que diz: “Eu só posso definir uma dessas”, e o que acontece se duas dessas classes forem aplicadas ao mesmo elemento? Você não pode obter isso com um atributo de dados, ele tem apenas um valor.

Andy: Sim. Essa é uma boa maneira de dizer isso, sim. É muito útil, eu descobri, trabalhar assim.

Drew: Isso é muito interessante. Acho que não vi outras metodologias que adotam essa abordagem. Isso é completamente exclusivo do CUBE, fazendo isso?

Andy: Pode ser. Eu realmente não presto muita atenção a outras coisas, o que eu deveria fazer. Alguém provavelmente está fazendo isso. Eu vou te dizer agora, tem sido o aspecto mais controverso disso. Algumas pessoas realmente não gostaram da ideia de usar atributos de dados. A coisa é bem, e como eu respondo, é, faça o que você quer. Não estamos dizendo para você fazer as coisas de uma determinada maneira, são apenas sugestões. Se você quiser fazer exceções para classes CSS, como modificadores, então se desespere. A polícia CUBE não vai bater à sua porta. Está absolutamente bem.

Andy: A coisa do CUBE é uma coisa pensante, é uma estrutura. Você aplica essa estrutura da maneira que quiser, com as ferramentas que desejar ou com qualquer tecnologia que desejar. Contanto que você mantenha as coisas consistentes, isso é o importante.

Drew: Então não existe CUBO puro?

Andy: A maneira como escrevo é puro CUBO, Drew. Todo mundo é apenas uma farsa, é apenas uma imitação fraca.

Drew: Além de você, ninguém pode dizer: “Isso não é o livro didático CUBE”.

Andy: Não, é isso. Ninguém pode contestar isso realmente, não é? Então, sim, eu vou com isso. Dá-lhe um pouco de influência ou algo assim, eu acho, algo assim.

Drew: Você pode misturar e combinar uma abordagem CUBE com outras metodologias? Você pode usar bits de BEM?

Andy: Sim, acho que sim. Eu estive pensando um pouco sobre isso porque eu vou fazer mais coisas sobre isso em breve, porque se tornou bastante popular, então as pessoas vão querer mais trabalho. Uma coisa que vou ver é como abordar o uso da metodologia CUBE com algo existente.

Andy: Então há dois extremos opostos da escala. Uma boa pergunta que as pessoas fizeram é: “Como isso funciona com todos os layouts, as outras coisas?” Eu sou como, basicamente, todo layout é o C. Isso é o que todo layout é, é a camada de composição. Então alguém perguntou: “Bem, como isso funcionaria com algo como Atomic Web Design, como as coisas que Brad Frost fez? É como, bem, você poderia quebrar essas peças e aplicá-las em cada nível. O design atômico vai até os micro detalhes. É abstrair isso em usar, certo, ok, bem, eu posso aplicar isso com utilitários, então as moléculas, eu acho. Eu posso aplicar isso com os utilitários, e está traduzindo o que você já sabe para essa estrutura de trabalho ligeiramente diferente.

Andy: Realmente, é uma renomeação para muitas coisas. Eu não inventei nada aqui, eu meio que, como eu disse, apenas roubei coisas que eu gosto. Eu amo a maneira como algumas coisas do Design Atômico são pensadas. Isso é realmente um trabalho inteligente. E BEM. As coisas que Harry fez, o CSS Triângulo Invertido, achei muito legal. Então eu meio que cortei alguns pedaços que eu gosto de cada um deles e meio que juntei todos nessa outra coisa híbrida, abordagem. Mais para vir, eu acho.

Drew: A abordagem CUBE pode ser aplicada a projetos existentes que já possuem CSS ou é algo que você realmente precisa para começar um novo projeto?

Andy: Isso depende muito. Então, se você tem um trabalho de bootstrap e tem milhares de linhas de CSS personalizado, em que eu definitivamente estive envolvido antes, acho que você pode estar tentando apagar um incêndio com uma garrafa de água. apontar. But if you… say, for instance, if you've got a rough BEM setup and it's gone a bit layer-y, you could use CUBE to refactor and actually pull it back into shape again.

Andy: It depends, the answer to that one. But it's doable, as with everything. If you really want it to work, Drew, you can do it if you want, can't you? The world is our oyster!

Drew: Especially if your BEM site's gone layer-y.

Andy: Yeah. Nothing worse than a layer-y BEM site!

Drew: I've noticed in the examples that you've given… and I've got an eagle eye, I've seen you've been doing this for a while… a lot of your class values in the HTML attribute are wrapped in square brackets.

Andy: Oh, God, yeah. Tell you what, Drew-

Drew: What is that about? O que é isso?

Andy: I'll tell you what, if there's ever one thing that I've done in my whole career that's just been absolutely outrageously controversial… and you follow me on Twitter, you've seen what comes out of my mouth… it's those bloody brackets! My, God! People either love them or hate them. They're Marmite, they are.

Andy: The reason I do them is a grouping mechanism. So if you look at the way that they're structured, the way I do it is, block at the start and then I'll do a utilities after that. Then what I might do is, in between a block group and a utility group, there might be another block class. So a good example of that would be… we'll go back to the card again. But then say that there's a specific block called a CTA, like a call to action. You might have that applied to the card as well, and then your utilities are enforcing the design attributes, so the colors and all that business. So then you've got three groups of stuff.

Andy: When you come to it, if you've got that order in your head each time, you know, okay, right, this first group's blocks. Oh, that's looks like another block. I've got that one. Then it's like, right, they're definitely utility classes. Then what I might even do is, if there's a lot of design token implementation, have that in a separate group. So it's just very clear what each group is doing, and there's a separation inside of the classes there as well. I've found it really helpful. Some people find it incredibly offensive. It's definitely a do it if you want to do it. Definitely you don't have to do it.

Andy: It's quite funny, when I published that article, so many people finished halfway through to ask me, “What is it with these brackets?” I was like, “Did you finish the article? Because there's a big section at the end where it explains exactly what they're doing,” to the point where I actually had to write a bit in the middle of the article of, “If the brackets are essentially doing your head in, click here and I'll skip you all the way down to that explanation bit so you can just read about them.” It can be quite controversial.

Andy: When I've worked on really, really complex front-ends… and we did a little bit of stuff together, didn't we, last year?

Drew: Sim.

Andy: You've seen the sort of design implementation on that project that we were on. It requires that sort of grouping because there's just so much going on at the time, there's so much different stuff happening. I've just found it really, really useful over the years, and also get lots of questions about it, to the point where I was almost going to write just one page on my website that I could just fire people to to answer the question for them.

Drew: Slash, what's with the brackets?

Andy: Yeah. Slash, brackets. Have you seen that new Hey Email thing that's just come out? They've bought a domain of itsnotatypo.com, just to answer the whole Imbox, like im with an M rather than an in. Basically, I was like, “I think I need to do that,” like, whatswiththebrackets.com, and just do a one-pager about it.

Drew: It strikes me that the approach with brackets actually could be something that might be useful when using things like Tailwind or something that has a lot of classes because that can-

Andy: Yeah. Oh, God, yes.

Drew: You have classes that are addressing your break points and what have you, and then you'll have things that are for layout, things that are for color or type, or what have you. So it might also be a useful way of dealing in situations like that.

Andy: I'd definitely agree with that. A good analogy… not analogy. A good bit of info about Tailwind is that I actually quite like Tailwind. I've used that on very big projects. The one thing that really opened my eyes to Tailwind though was when I saw a junior developer try to work out what was going on, and it was really, really eye-opening because they just didn't have a clue what was happening.

Andy: I think that's one problem I've found with these sort of over-engineered approaches, which I think it's fair to say Tailwind is, is that there's a certain skill level that is required to work with it. I know the industry tends to have an obsession with seniority now, but there's still people that are just getting into the game that we need to accommodate, and I think having stuff that's closer to the language itself is more helpful in those situations because they're probably learning material that is the language as it is. So I think it's just a bit more helpful. Especially having a diverse team of people as well. Just food for thought for everyone.

Drew: People might look at all the different methodologies that are out there and say, “This is evidence that CSS is terrible and broken, that we need… all these problems have to be solved by hacking stuff on top. We need tools to fix bits of CSS. We need strict procedures for how we implement it, just to get it to work.” Should the platform be adapting itself? Do we need new bits of CSS to try and solve these problems or are we all right just hacking around and making up funny acronyms?

Andy: I think the power of CSS, I think, is its flexibility. So if you're going to program CSS, a lot of the knowledge is less of the syntax and more of the workings of a browser and how it works. I think that might be a suggestion, that the problem is that people might not have learnt CSS quite as thoroughly as they thought they might have learnt it, who created these problems. I've seen that in evidence myself. I spotted a spacing mechanism that had been invested, which was very complicated, and I thought, “This person has not learnt what padding is because padding would actually fix this problem for them, understanding how padding works and the box model.” That's not to be snidey about it.

Andy: We work in an industry now that moves at an even faster pace than it has done previously and I think there's a lot less time for people to learn things in detail. But, on that front, I think CSS still does have work to do in terms of the working group, who I think do a bloody good job. A great, shining example of their work was the Grid spec which was just phenomenal. The way that rolled out in pretty much every browser on day one, I thought that was so good.

Andy: But we've got more work to do, I think, and I think maybe the pace might need to increase a little, especially with stuff like container queries, we all love talking about them. Stuff like that I think would help to put CSS in a different light with people, I think. But I think CSS is brilliant, I love it. I've never had a problem with it in lots of years really. I do find some of the solutions a bit odd, but there you go.

Drew: What's the response been like to CUBE since you published the article?

Andy: Mind-blowing. I honestly published it as just supporting material, and that's all I expected it to be, and it's just blown up all over the place. A lot of people have been reading it, asking about it, been really interested about it. There's definitely more to come on it.

Andy: I did say in the article, I said, “Look, if people are actually quite interested in this, I'll expand on this post and actually make some documentation.” I've got bits of documentation dotted around all over the place, but to sort of centralize that, and then I was thinking of doing some workshops and stuff. So there's stuff to go. It's how Every Layout started as well. We both had these scattered ideas about layout and then we sort of merged them together. So something like that, I suppose, will come in the future.

Drew: Are there any downsides that you're aware of to using CUBE? Are there problems that it doesn't attempt to solve?

Andy: Yeah. This accent, Drew, it just won't go way, no matter what I do! In all seriousness, I think CUBE's got as close as I can get to being happy with the front-end, which is saying a lot, I think. You never know, things might change again. This has evolved over more recent years. Give it another five years, I'll probably be struggling with this and trying something else. I think that's the key point, is to just keep working on yourself and working on what you know and how you approach things.

Andy: This definitely won't work for everyone as well, I know that for a fact. I know that from my comments. I don't expect it to work for everyone. I don't expect anything to work for everyone. It's the same with JavaScript stuff: some people like the reactive stuff and some people don't. It is what it is. We're all people at the end of the day, we all have different tastes. It's all about communicating with your teammates at the end of the day, that's the important thing.

Drew: I know you as a very talented designer and developer and you, like many of us, you're just working on real projects all day, every day. But you've recently started publishing on this site, Piccalilli, which is where the CUBE CSS introduction article was. So Piccalilli is kind of a new venture for you, isn't it? What's it all about?

Andy: Very kind of you to say, Drew. You've actually worked with me, so that's high praise. But the Piccalilli thing is an evolution. So I'm a freelancer. I do client work, but I think this has become apparent with the pandemic, that that is not the most sustainable thing in the world in some industries. I think freelancing can be very, very tough, as a developer and designer. It's something that I've been doing it for so long now, 10 years… well, 12 years now actually.

Andy: Eu queria fazer algo um pouco diferente e aplicar o conhecimento que tenho e realmente compartilhá-lo com as pessoas. Sempre fui muito aberto e compartilhado, e queria formalizar isso. Então criei Piccalilli para escrever tutoriais, mas principalmente para cursos que estou produzindo: essa é a principal carne e batata. E depois tem a newsletter que é… as pessoas estão gostando muito da newsletter porque eu compartilho coisas legais que encontrei na internet toda semana. Essa é a espinha dorsal disso. Está indo muito bem. Isso é essencialmente onde eu quero me ver fazendo cada vez mais em tempo integral, com o passar dos anos, eu acho.

Drew: Então, o que vem a seguir para Piccalilli? Você tem alguma coisa que você tem saindo?

Andy: Obrigado pela porta aberta, Drew! Quando esta gravação sair, o primeiro curso estará ao vivo: Aprenda Eleventy From Scratch, e é aí que aprendemos a construir um site Gatsby! Não, você aprende a construir um site Eleventy. Então você começa com um diretório completamente vazio, não há nada nele, está vazio e, no final, você termina com este site de agência muito bonito. Aprendemos todos os tipos nele. Você aprende a realmente ir à cidade com Eleventy. Extraímos dados remotos de lugares. Usamos CUBE CSS para construir um front-end muito bom para ele.

Andy: Se você quer entrar no Jamstack e quer entrar em geradores de sites estáticos, ou apenas como construir um bom site, é apenas um curso muito útil, espero, para isso. Atualmente está sendo editado dentro de uma polegada de sua vida enquanto estamos falando. Vai ser legal, espero, e útil. Mas isso é um acúmulo de muitas coisas que tenho feito nos últimos dois anos. Então deve ser divertido.

Andy: Então compre, e eu vou fazer um código de desconto, como smashingpod com 40% de desconto, e você pode obtê-lo quando sair.

Drew: Incrível. Ligaremos isso. Você já descobriu como soletrar Piccalilli de forma confiável?

Andy: Eu estava com Chris e Dave no ShopTalk Show e eu disse lá: “Se há uma coisa que você quer me contratar é para escrever Piccalilli à mão pela primeira vez sem nem pensar nisso”, porque eu escrevi essa palavra tantas vezes que sei exatamente como soletrar de cor. Então a resposta para sua pergunta é sim.

Drew: Bem, eu ainda estou lutando, eu vou te dizer isso!

Andy: É difícil. Oh Deus. Eu simpatizo totalmente. Levei muito tempo para aprender a soletrar, mas é uma daquelas palavras do nosso vocabulário. Este ano estou tentando soletrar necessário sem cometer um erro de ortografia!

Drew: Então eu tenho aprendido tudo sobre CUBE CSS. O que você tem aprendido ultimamente, Andy?

Andy: Você sabe o quê? Isso vai surpreendê-lo, Drew. MySQL é o que eu tenho aprendido recentemente. Então, basicamente, Piccalilli é totalmente autopublicado. É um site Eleventy, mas tem uma API por trás dele, e tem um banco de dados MySQL por trás dele. O material que dá às pessoas o conteúdo que elas compraram requer algumas consultas bastante pesadas. Então eu realmente investi corretamente em alguns MySQL... especialmente a diferença entre junções, que eu realmente não percebi que havia uma diferença entre cada tipo de junção. Então isso tem sido muito útil e resultou em algumas interações bastante rápidas com o banco de dados.

Andy: Eu costumava rodar essa coisa chamada Front-End Challenges Club e quando eu o lancei pela primeira vez ele simplesmente desmoronou e morreu porque o MySQL era de má qualidade para dizer o mínimo. Então, eu realmente tenho aprendido a fazer isso porque não sou uma pessoa de back-end, sou um empurrador de pixels. Então definitivamente não é da minha alçada. Isso é mais o seu pescoço da floresta, não é? Acho muito legal, MySQL. Na verdade, eu gosto muito de escrevê-lo. É uma linguagem instrutiva muito legal, não é?

Drew: É, é ótimo. Aprendi SQL na escola.

Andy: Uau!

Drew: Estamos falando de 20 anos atrás.

Andy: Eles tinham computadores naquela época?

Drew: Eles fizeram, sim. Tivemos que vento-

Andy: Você teve que escrever à mão?

Drew: Tivemos que dar corda neles! Nós fizemos. Mas, eu digo a você, para um desenvolvedor, é como aprender suas tabuadas: uma daquelas coisas que parece um pouco trabalhosa, mas uma vez que você é fluente, torna-se útil uma e outra vez.

Andy: Sim. Com certeza. Há diferenças realmente tangíveis também. Você realmente vê a diferença na velocidade. Eu realmente gosto de trabalhar com Node porque é muito rápido, mas Node e MySQL são apenas... não uma escolha muito comum, mas acho que é uma escolha muito boa. Acho que funciona muito, muito bem. Então estou feliz com isso. Como você sabe, eu não gosto de escrever PHP. Então isso nunca vai ser uma opção.

Drew: Se você, querido ouvinte, gostaria de ouvir mais de Andy, você pode segui-lo no Twitter onde ele está em hankchizljaw. Você pode encontrar Piccalilli em piccalil.li, onde também encontrará o artigo que descreve o CUBE CSS, e também adicionaremos links para todos eles nas notas do show, é claro.

Drew: Obrigado por se juntar a nós hoje, Andy. Você teve alguma palavra de despedida?

Andy: Fique seguro e use sua máscara.