Smashing Podcast Episodul 19 cu Andy Bell: Ce este CUBE CSS?

Astăzi, vorbim despre CUBE CSS. Ce este și cum diferă de abordări precum BEM, SMACSS și OOCSS? Am vorbit cu creatorul său, Andy Bell, pentru a afla.

Afișați note

• CUBE CSS
• Piccalilli
• Învață Eleventy de la zero - economisește 40%!
• Andy Bell și Piccalilli pe Twitter

Notă : ascultătorii Smashing Podcast pot economisi 40% la cursul Andy’s Learn Eleventy From Scratch folosind codul SMASHINGPOD .

Actualizare săptămânală

• „Ce ne poate învăța Vitruvius despre design web”
  de Frederick O'Brien
• „O introducere în SWR: React Hooks pentru preluarea datelor de la distanță”
  de Ibrahima Ndaw
• „Cum pot designerii web să ajute restaurantele să treacă în experiențe digitale”
  de Suzanne Scacca
• „Un ghid practic pentru testarea aplicațiilor React cu Jest”
  de Adeneye David Abiodun
• „Repere Django: dispute active statice și fișiere media (partea 4)”
  de Philip Kiely

Transcriere

Drew McLellan: Este un educator și designer web independent cu sediul în Marea Britanie și a lucrat în industriile web designerilor de peste un deceniu. În acel timp, a lucrat cu unele dintre cele mai mari organizații din lume, precum Harley-Davidson, BSkyB, Unilever, Oracle și NHS. Alături de Heydon Pickering, el este coautorul cărții Every Layout, precum și conduce Clubul Provocărilor Front-End, care se concentrează pe predarea celor mai bune practici de dezvoltare front-end prin provocări scurte și distractive.

Drew: Cea mai recentă afacere a lui este Piccalilli, un buletin informativ pentru site-ul web cu tutoriale și cursuri pentru a vă ajuta să treceți la nivel ca dezvoltator și designer front-end. Deci știm că este un dezvoltator și educator cu experiență, dar știai că a fost prima persoană care a permis să concureze la Crufts cu un panda?

Drew: Prietenii mei Smashing, vă rog bun venit, Andy Bell. Bună, Andy, ce mai faci?

Andy Bell: Sunt zdrobitor, mulțumesc. Ce mai faci?

Drew: Sunt foarte bun, mulțumesc foarte mult. Acum am vrut să vă vorbesc astăzi despre ceva ce ați postat pe site-ul dvs., Piccalilli, despre o metodologie CSS pe care ați dezvoltat-o ​​pentru dvs. în ultimii ani. În primul rând, cred că ar trebui probabil să explorăm ce înțelegem prin metodologie CSS, deoarece asta ar putea însemna lucruri diferite pentru diferiți oameni. Deci, când te gândești la metodologia CSS, ce este pentru tine?

Andy: Asta e o întrebare bună, greu de început, Drew. Apreciez asta, mulțumesc!

Drew: Bine ai venit!

Andy: Este unul complicat. Deci, pentru context, am folosit BEM de mult timp, și acesta este Block Element Modifier. Asta există de multă vreme. Felul în care privesc o metodologie CSS este că nu este un cadru, este o structură organizatorică. Așa îmi place să văd. Este aproape ca un proces. Este ca și cum ai avea o problemă pe care trebuie să o rezolvi cu CSS și folosești metodologia pentru a o rezolva pentru tine și a menține lucrurile previzibile și organizate. BEM este doar legendar pentru asta pentru că a avut un succes extraordinar.

Andy: Atunci aproape că ai putea califica lucruri precum componentele stilului și așa ceva. Aproape că poți spune că sunt orientate către metodologie, deși sunt puțin mai împletite în cadru, dar totuși, este o metodologie de a împărți lucrurile în molecule minuscule. Deci, în esență, asta încerc să fac și cu CUBE CSS. O structură de gândire, cred că am descris-o ca.

Drew: Deci este o aplicație de proces pentru modul în care arhitecți și scrieți CSS, și nu este atât de mult ceva care se bazează pe instrumente sau orice alt tip de tehnologie, este doar un fel de flux de lucru. Deci, există o mulțime de abordări diferite acolo. Ai menționat BEM. Există SMACSS, OOCSS, Atomic CSS. Și apoi aveți astfel de abordări neobișnuite ale iubirilor precum ABEM. L-ai văzut pe acela?

Andy: Da.

Drew: De ce să-l publici pe al tău?

Andy: Da, da. De ce să-ți faci singur? E o întrebare foarte bună. Cred că cei care mă cunosc bine știu că îmi place mult să navighez împotriva curentului. În principal, pentru că tind să fac și multe proiecte variate, în echipe variate. Așa că este foarte greu, am descoperit, să lucrez cu BEM cu un dezvoltator tradițional, deoarece ei sunt obișnuiți să folosească CSS pentru ceea ce înseamnă CSS: cascadă și cetera, și de aceea am cam furat asta din limbaj. .

Andy: Pe de altă parte este că metodologiile mai puțin structurate, este mai greu să lucrezi cu un programator, un fel de persoană JS, deoarece le plac structura și organizarea și componentele mici, ceea ce este de înțeles să lucrezi cu limbajul în care lucrează.

Andy: Așa că m-am trezit în aceste poziții în care lucram cu diferite tipuri de oameni, diferite tipuri de proiecte în care o singură metodologie nu prea funcționa. De-a lungul anilor, m-am jucat cu această idee despre cum stau lucrurile, apoi mai sunt lucrurile pe care eu și Heydon am făcut, Every Layout, care a impus o mare parte a ei, care este C, partea de compoziție. , iar apoi l-am cam evoluat foarte rapid în ultimele șase luni.

Andy: Singurul motiv pentru care am scris un articol despre el a fost pentru că tocmai făceam acest curs și m-am gândit că ar fi mai bine să scriu niște materiale suplimentare care să-l însoțească, astfel încât oamenii să-l înțeleagă și a fost absolut explodat. Deci poate că încă nu am terminat metodologiile, Drew.

Drew: Deci, materialul de curs pe care l-ați pregătit folosește de fapt CUBE CSS ca metodologie, nu-i așa?

Andy: Da. Deci, o bună proporție de 50% din curs este de fapt front-end, chiar dacă este un curs nelimitat. Este atât de profund împletit în modul în care construim front-end-ul, încât nu aș putea spune pur și simplu: „Oh, apropo, așa scriu un CSS frumos” și apoi să-l las. Știu că oamenilor le place să intre în detalii, așa că am spus, ceea ce voi face este să scriu această postare care este foarte lungă și foarte detaliată și apoi dacă cineva dorește să se dezvolte și să înțeleagă cu adevărat ce facem , atunci pot face, iar restul este de acolo. Și iată-ne astăzi, Drew, stând și vorbind despre asta.

Drew: Deci, dacă cineva înțelege deja BEM și poate că folosește deja BEM, ca exemplu, pentru că aceasta este probabil una dintre cele mai ample metodologii adoptate, nu-i așa? Așadar, dacă au înțeles deja BEM și vor veni la CUBE, este ceva ușor de adoptat? Există multe asemănări sau este complet diferit?

Andy: Da. Aș spune că trecerea de la BEM la CUBE este probabil o tranziție lină, mai ales modul în care îmi place să scriu în continuare CSS-ul pentru CUBE. Deci majoritatea lucrurilor se întâmplă la un nivel superior. Deci se întâmplă la nivel de cascadă și se întâmplă CSS global, folosind utilitățile pentru a face o mulțime de lucruri. Dar când intri în piulițe și șuruburi, sunt componente, blocuri și elemente foarte asemănătoare BEM. Singurul lucru care este oarecum diferit de BEM este că, în loc să avem modificatori, folosim acest lucru numit excepții, care este, în loc să folosim clase CSS, se apelează la atribute de date, ceea ce cred că oferă un pic de separare și un real. excepție, care este ceea ce ar trebui să fie un modificator.

Andy: O parte din motivul pentru care m-am oarecum îndepărtat de BEM a fost pentru că am descoperit că modul în care lucram cu el, în special în sistemele de proiectare, era dominația modificatorilor și a devenit o problemă pentru că era de genul: care este rolul blocului meu în acest moment? Pentru că dacă o modific până la punctul în care este de nerecunoscut în mod regulat, atunci această metodologie încă funcționează așa cum ar trebui să funcționeze?

Andy: Apoi sunt toate chestiile cu simboluri de design, lucrurile pe care Jina le-a făcut cu sistemul Lightning Design pe care am început cu toții să-l adoptăm acum. Lucrurile din clasa de utilitate au început să aibă sens cu această abordare. Așa că am zdrobit toate lucrurile care îmi plac la munca altora și le-am introdus în a mea.

Drew: Vorbești despre BEM, genul de abordare modificatoare care scapă de sub control. Acesta a fost unul dintre principalele puncte dureroase cu BEM pe care CUBE încearcă să le abordeze?

Andy: Da, absolut. Îmi place abordarea modificatorului cu BEM, are sens. Ceea ce îmi place la BEM este ceva ce încă mai fac, este liniuța dublă pentru un element și apoi există liniuța dublă pentru un modificator. Îmi place acest mod de a organiza lucrurile. A fost doar un caz de bine, ei bine, o mulțime de modificatori pe care îi pot explica de fapt cu clasele de utilitate și apoi cu ceilalți biți...

Andy: Deci exemplul pe care îl folosesc în articol este, imaginează-ți că ai un card și apoi cardul este răsturnat, astfel încât conținutul să apară înaintea imaginii. Deci, asta are sens, pentru a vedea afișajul: flexați și apoi îl inversați, inversați ordinea. Are sens, să existe o regulă de excepție pentru asta, deoarece este o excepție de la starea implicită a cardului și așa îmi place să o văd. Este ca o stare afectată pe acea componentă, este ceea ce este o excepție și asta are sens.

Andy: Cu o mulțime de lucruri pe care le-am făcut mai recent, stiva modernă de front-end cu JavaScript reactiv, există multe schimbări de stare și este logic să le gestionăm în mod corespunzător între CSS și JavaScript, deoarece acestea devin din ce în ce mai multe și mai împletite între ele, fie că vă place sau nu. Este un limbaj comun pentru ei. După cum poți vedea după fața mea, foarte mult nu, dar gata. Probabil că te gândești: „De fapt, am lucrat destul de mult cu React recent, așa că sunt invers.” Deci pot să văd și asta.

Drew: Deci să intrăm în CUBE atunci. Deci CUBE înseamnă Excepție de bloc utilitar de compoziție. Este corect?

Andy: Da. Acela este.

Drew: Ce naiba înseamnă asta?

Andy: O, amice, ar fi trebuit să fi auzit înainte! Am ținut o discuție anul trecut. Am ținut o discuție și s-a numit Keeping it Simple cu CSS care se scalează, iar acolo am cam introdus o versiune anterioară a acesteia numită CBEUT, care era Cascade Block Element Utility Token. A fost un gunoi. Am urât numele lui. Am făcut-o de câteva ori, această discuție anul trecut, și chiar nu mi-a plăcut numele. Apoi, când am ajuns să fac aceste lucruri anul acesta, m-am gândit: „Trebuie să mă gândesc la ceea ce este de fapt și cum se numește.” Cred că CUBE este un pic mai puțin gunoi. Cred că acesta este cel mai bun mod în care îl pot descrie.

Andy: Dar atunci, numele sunt întotdeauna un gunoi pentru aceste lucruri, nu-i așa? Adică, la fel ca BEM, ce nume de gunoi! Dar toți o facem. Uită-te la Jamstack: și acesta este un nume groaznic, nu-i așa?

Drew: Buzele mele sunt sigilate!

Andy: Șeful tău spune „Ce?” E adevarat. Este exact așa cum este, nu-i așa, în industria noastră.

Drew: Se pare că multe dintre metodologiile CSS încearcă să rezolve unele dintre caracteristicile CSS, lucruri precum cascada. Înțelegerea mea din ceea ce am citit este că CUBE încearcă să folosească astfel de caracteristici și proprietăți ale CSS.

Andy: Da. O analogie bună este SCSS, ca și Sass, este o extensie a limbajului natural CSS, nu-i așa? Mai ai dreptate în CSS. Deci CUBE CSS este așa. Deci este o extensie a CSS. Deci ar trebui să scriem în continuare CSS, așa cum ar trebui CSS... ei bine, ar trebui să fie scris. Să fim sinceri, că felul în care ar trebui să fie scris, este numele o dă deoparte: Cascading Style Sheets. Așa că acceptă asta din nou, pentru că ceea ce am descoperit este că am coborât până la nivelul de micro-optimizare. Am fost pe calea în care văd o mulțime de oameni coborând recent, unde... și am menționat acest lucru și în articol, unde pot vedea... există câteva dovezi în acest sens recent. Am observat că oameni au creat componente de distanțiere și chestii de genul ăsta și înțeleg problema, am fost în acea situație.

Andy: Modul în care am remediat a fost, în loc să măresc și să încerc să micro-optimizez, de fapt, am început să mă gândesc la lucruri la nivel de compoziție, deoarece nu contează cât de mici sunt componentele tale, la un moment dat vor merge. pentru a fi pagini, vor fi vizualizări. Nu poți evita asta, așa va fi. Deci, în loc să încercați să spuneți: „Bine, am nevoie de acești ajutoare minuscule pentru a face acest aspect”, spuneți „Bine, am o vizualizare a paginii de contact sau o vizualizare a paginii de produs și aceasta este o compoziție de aspect schelet. Apoi, în interiorul acestuia, pot introduce orice componente vreau acolo.” Avem acum lucruri precum Grid și Flexbox care fac acest lucru mult mai realizabil și, în esență, puteți pune orice doriți în interiorul aspectului schelet, nu contează. Apoi, componentele ar trebui, în acel moment, să se comporte așa cum doriți să se comporte, cu sau fără interogări container.

Drew: Aceasta este partea de compoziție a CUBE în care vă uitați la lucruri la un nivel mai mare de macro, uitați la modul în care componentele pot fi compuse într-o vizualizare pentru a crea tipul de pagini pe care trebuie să le creați pentru un site sau o aplicație sau ce ai tu.

Andy: Deci se creează reguli, în esență. Este ca o îndrumare. Încearcă să obțină linii directoare pentru ceva. Nu este ca niște reguli stricte, cum ar fi, ar trebui să faci asta, ar trebui să faci asta. În esență, asta faci cu browserul, cu această metodologie, spui că nu îl forțezi să facă nimic. Spui: „Uite, în mod ideal, dacă ai putea să o arăți așa, ar fi grozav, dar înțeleg că s-ar putea să nu fie cazul, așa că iată câteva limite și niște niveluri superioare și inferioare cu care putem lucra. Fă ce poți și felicitări.” Apoi aruncați niște componente și lăsați-l să facă ceea ce face. Adăugați suficient control acolo pentru ca acesta să nu arate un gunoi.

Andy: Deci, un exemplu bun ar vedea... facem un aspect în Every Layout numit comutator, care, în esență, va alinia elementele până la un anumit punct în care calculul care stabilește cât de lățime le va stivui unul peste altul. . Dar pentru că adăugăm o marjă la in-line și la bloc, funcționează, indiferent de starea acesteia, încă arată bine. Aceasta este ideea, este că nu îi spunem browserului să spună: „Trebuie să stratificați această grilă cu trei coloane”. Spunem: „Dacă puteți suprapune o grilă cu trei coloane, fă-o. În caz contrar, stivuiți și spațiuți în schimb.” Deci este genul ăsta de metodologie, de a lăsa browserul să-și facă treaba cu adevărat.

Drew: Multe dintre abordările diferite care au apărut pentru CSS în ultimii câțiva ani s-au concentrat foarte mult pe nivelul de componentă de a trata totul ca și cum ar fi o componentă. CUBE nu minimizează atât de mult aspectul componentului, ci oferă acest concept suplimentar în plus față de a lua acele componente și de a le compune în machete mai mari, în loc să spună doar o altă componentă.

Andy: Da, asta e un punct bun, da. Cred că ceea ce trebuie spus despre componente este că acestea sunt importante, mai ales în chestiile moderne de front-end. Facem o mulțime de lucruri componente, chestii de sistem. Dar modul în care văd o componentă este că este o colecție de reguli care extind ceea ce a fost deja făcut.

Andy: Ideea pe care o spun în articol este că, până când ajungi la nivelul blocului, cea mai mare parte a stilului tău a fost de fapt făcută și, într-adevăr, ceea ce face componenta ta este să puncteze Is-urile și să încrucișeze T-urile și spune: „Bine, în acest context…” Deci, pentru un card, de exemplu, faceți ca imaginea să aibă o înălțime minimă de X și adăugați un pic de umplutură aici. Fă asta, asta și cealaltă. Pune un buton aici. Sunt doar un fel de reguli suplimentare pe lângă ceea ce a fost deja moștenit de la restul CSS. Cred că acesta este probabil cel mai bun mod de a o descrie.

Andy: În timp ce în BEM, componenta este sursa adevărului. Până când nu puneți acea clasă pe element, nimic nu a fost aplicat în acel moment și acea metodă funcționează. Tocmai am descoperit că am scris mai multe CSS făcând asta și mai multe CSS repetitive, ceea ce nu-mi place să fac.

Drew: Ați lua în considerare tipografia și culorile și ritmurile verticale, spațierea și toate astea, toate acestea fac parte din ideea de compoziție în acest model?

Andy: Da. Într-un CSS global, da, absolut. Ritmul vertical în special, și fluxul. Am făcut un articol despre asta la 24 de moduri, nu-i așa, acum câțiva ani, componenta flux și ritm. Acesta a fost și un fel de abstract din această abordare, în care ai setat o componentă de bază care folosește în esență selectorul de bufnițe lobotomizate. Nu știu cum voi descrie asta la radio, dar vom face. Vom pune doar, cred, în emisiune notele despre articolul Heydon sau ceva de genul ăsta. Dar, în esență, selectează elemente copil... scuze, elemente frați.

Andy: Așa că spune: „Corect, fiecare element care urmează elementului X are o marjă superioară a costurilor CSS și a valorii proprietății”, și apoi frumusețea este că puteți seta acea valoare a proprietății personalizate CSS și într-un context compozițional. Așa că puteți spune: „Corect, în această componentă, dacă există un oarecare flux în mișcare, vom seta spațiul de flux să fie de fapt doi rem, pentru că vrem să fie frumos și consistent, spațiul larg.” Apoi, într-un altul ați putea spune: „De fapt, vreau ca spațiul de flux să fie o jumătate de rem pentru că vreau să fie strâns.” Toate acestea se întâmplă, tot controlul vine de la un nivel superior și apoi ceea ce faci este să adaugi depășiri contextuale în loc să le reinventezi de fiecare dată, reinventând același lucru iar și iar.

Drew: Deci acesta este C, Compoziție. În continuare avem U, care este Utility. Deci, ce înțelegem prin utilitate?

Andy: Deci este o clasă care face o singură treabă și o face foarte bine. Aceasta ar putea fi o implementare a unui simbol de design care... este un abstract al proprietăților. De obicei, sunt culori sau stiluri de tipografie, dimensiuni și reguli de genul acesta. Ideea este să generați clase de utilitate care să le aplice. Deci, aveți un utilitar care va aplica fundalul primar, care este ca culoarea primară, și apoi culoarea primară, care este culoarea textului. Apoi ați putea genera niște jetoane de spațiere pentru umplutura marginală și tot felul de lucruri. Ei fac doar o singură treabă. Ei adaugă doar acea regulă de spațiere, acea regulă de culoare și atât.

Andy: Dar apoi ai și alte utilități. Deci, un bun exemplu este un utilitar Wrapper. Ceea ce va face este că va pune o lățime maximă pe un element și apoi va pune marginea automată din stânga și din dreapta pentru a-l așeza în mijlocul obiectului. Deci are doar o singură slujbă și o face eficient și bine.

Andy: Deci ai stilurile tale globale, ai făcut multe setări de tipografie și mult spațiu pentru podea. Compoziția ta oferă apoi context și aspect. Apoi, utilitățile aplică jetoane direct elementelor pentru a le oferi acel stil de care aveți nevoie. Deci, ca un titlu, de exemplu, spuneți: „Vreau să aibă această dimensiune și vreau să aibă această plumb și vreau să aibă această măsură.” Apoi, în acel moment... asta spuneam despre blocuri... apoi mergi mai jos în stivă și ai făcut deja cea mai mare parte a muncii la punctul respectiv.

Andy: Așa că vă oferă acest mod cu adevărat eficient de lucru și, pentru că și HTML-ul trece prin conducte, este foarte plăcut să abstrageți volumul de lucru pe HTML, mai degrabă decât pe CSS, am descoperit. Obișnuiam să intru într-adevăr la cursuri de utilitate, ca în acest tip de stil vechi de „Oh, separarea preocupărilor”, dar de fapt cred că este un mod decent de lucru. Mentionez in articol ca imi place de fapt Tailwind CSS. Cred că funcționează și îmi place foarte mult să-l folosesc pentru tastarea produselor, deoarece pot să scot ceva foarte repede. Dar cred că merge puțin prea departe, nu Tailwind, în timp ce îmi place să plouă atunci când depășește doar aplicarea unei singure reguli pe o clasă. Deci asta e tot, cred. Tu?

Drew: Deci, da, în articol vorbiți mult despre jetoanele de design, ceea ce am vorbit despre Smashing Podcast cu Jina Anne în episodul trei, cred că a fost. Deci, se pare că jetoanele de design sunt un aspect cu adevărat fundamental.

Andy: Da. Oh, Doamne, da. Îmi amintesc atât de clar când Jina făcea chestii cu sistemul Lightning Design pentru că construiam un sistem de proiectare la acea vreme, sau ceva care semăna cu un sistem de proiectare, și ne străduiam să obținem aprobarea executivului. Când a apărut sistemul Lightning Design, le-am trimis literalmente link după link și le-am spus: „Acesta este ceea ce facem. Construim un sistem de proiectare. Pentru asta îl folosește în prezent Salesforce.” Îmi amintesc că munca ei la acea vreme m-a ajutat să trec lucruri pe ușă.

Andy: Atunci, chestiile cu simboluri de design mi-au rămas mereu în minte ca fiind o modalitate foarte bună de a aplica aceste reguli. Pentru că sunt designer de meserie, așa că pot să văd că organizația și capacitatea de a organiza și crea o singură sursă de adevăr sunt foarte utile, deoarece este ceva ce nu am avut cu adevărat în designul digital, în special în Adobe. era de a lucra cu Photoshop și altele, pur și simplu nu aveam acest lux. O aveam tipărită cu Pantone Book, dar nu o aveam în format digital cu coduri hexadecimale aleatorii în tot magazinul.

Andy: Deci este grozav. Îmi place acest nivel de control. De fapt, cred că ajută la creativitate pentru că nu te mai gândești la lucruri neimportante, te gândești doar la ce faci cu ele.

Drew: Implementarea acelor jetoane de design contează în special pentru abordare? Este întotdeauna proprietăți personalizate CSS?

Andy: Cred că acesta este un punct foarte important cu CUBE. Unele dintre răspunsurile pe care le-am primit, oamenii s-au luptat puțin cu asta. Nu există nicio mențiune despre tehnologie în ea. Singura tehnologie care este consistentă este CSS. O poți face cum vrei. Puteți face toate acestea cu orice lucru CSS și JS pe care oamenii le fac acum, sau ați putea face doar cu Vanilla CSS. Ai putea să o faci cu Sass. O fac cu Sass. Mai puțin, dacă asta mai faci. Toate aceste tehnologii disponibile, post CSS, toate aceste lucruri. Puteți face oricum doriți, nu contează.

Andy: Ideea este că dacă urmați astfel de construcții, veți fi bine. Asta e ideea din spatele ei. Este un lucru foarte liber și nu strict așa cum sunt unele dintre metodologii. Am văzut-o mai ales cu BEM, oamenii se înrădăcinează cu adevărat în principiile BEM până în punctul în care parcă nici nu mai rezolvi problema. Cred că trebuie să fii flexibil. Am spus-o în această discuție anul trecut. Eram de genul: „Dacă te ții prea tare de arme, îți poți cauza probleme pe termen lung, pentru că încerci să urmezi o anumită cale și știi că nu mai funcționează.” Ar trebui să fiți întotdeauna flexibil și să lucrați cu un sistem, mai degrabă decât să lucrați la literă.

Drew: Deci B, B este Block. Ai vorbit despre această idee, că până când ajungi la nivelul blocului, majoritatea ar trebui să fie la locul lor, iar apoi stilul la nivel de bloc este preocupat doar de detaliile reale ale unei anumite componente. În general, este conceptul de bloc similar cu ceea ce oamenii vor fi familiarizați?

Andy: Oh, absolut, da. Așa că imaginați-vă componenta BEM și scoateți toate elementele vizuale din ea și asta este ceea ce vă rămâne, în esență, blocul. Aceasta este ceea ce m-am străduit să articulez când am început să mă gândesc la această metodologie. Un bloc este de fapt un C, este o compoziție, dar asta o face foarte dificilă pentru că ești într-un teritoriu recursiv acolo și cred că creierul oamenilor ar exploda. Dar, într-adevăr, asta este un bloc, este de fapt un alt strat compozițional, dar mai mult un fel de context strict, deci cum ar fi cardul tău, butonul tău, caruselul tău, dacă asta îți place să faci în continuare și tot felul de lucruri.

Andy: Este ca un lucru specific, o componentă, iar apoi în interiorul tău stabilești reguli specifice pe care să le urmezi, ignorând cu adevărat restul, astfel încât să nu fii... S-ar putea să aplici jetoane în blocuri și fac asta totuși, dar într-adevăr este mai orientat spre aspect, este un bloc, în măsura în care lucrez cu ei, sau cel puțin iau jetonul și îl aplic într-un mod specific, cum ar fi starea de trecere a butonului, chestii de genul ăsta. Deci blocul tău ar trebui să fie mic până când ajungi la ei, ei nu ar trebui să facă deloc mare lucru.

Drew: Deci ar putea fi la fel de mic ca un hyperlink.

Andy: Da.

Drew: Dar ar putea fi și o colecție compusă de alte blocuri?

Andy: Da. Ca un fel de modul. Cu siguranță ai putea face asta. Pentru că, din nou, asta se întoarce la felul aspectului compozițional al acestuia, este că orice ar fi inclus în el nu ar trebui să conteze. Exemplul bun în acest sens este ca cardul. Deci, conținutul unui card este, să zicem, ca un titlu, un rezumat și un buton. Nu ar trebui să țintiți în mod specific aceste trei elemente. Ar trebui să spui: „Uite, orice se întâmplă să se regăsească în conținut, să aibă niște reguli de flux acolo și să aibă un fel de reguli de aspect compozițional”, și apoi nu contează ce ai introdus acolo. Ați putea decide că doriți să puneți o imagine în acel conținut și ar trebui să funcționeze, ar trebui să arate bine.

Andy: Acesta este scopul lucrului cu CSS. Este un mod foarte îngăduitor de a lucra cu CSS. Îți faci viața mult mai ușoară fiind mai puțin rigid, pentru că atunci când lucrurile se găsesc accidental în ceva, ceea ce se va întâmpla, nu arată îngrozitor așa cum ar putea fi dacă ai fi mai specific cu privire la lucruri, este ceea ce am găsite.

Drew: Cu siguranță am nevoie de multă iertare în jurul CSS-ului meu!

Andy: Știu că faci!

Drew: Noroc! Deci acesta este B. Ultimul lucru este E: E este Excepție. Acum nu vorbim despre mesaje de eroare, nu-i așa?

Andy: Nu, nu. Este un fel de-

Drew: Nu vorbim despre excepțiile JavaScript.

Andy: Da, da. Nu ar trebui să existe nimic din toate astea în acest moment. Oricum ar trebui să sper că nu, altfel chiar ești în pădure în acel moment: nu cred că o să te pot ajuta! Întreaga idee este... deci ați creat contextul cu blocul dvs. și o excepție este exact asta, este ca o excepție de la regulă: deci o carte răsturnată sau poate fi un buton fantomă. Deci știi acele butoane care tocmai au o chenar și un fundal transparent? Aceasta ar fi o excepție, deoarece un buton are probabil o culoare de fundal solidă și apoi culoarea etichetei. Deci creează un fel de stare distinctă de variație.

Andy: Motivul pentru care fac asta cu atribute de date în loc de clase și motivul pentru care asta se datorează faptului că a) cred că este frumos să existe o distincție. Așa că, atunci când scanezi o mulțime de HTML, poți vedea date, poti scrie ceva, îți spui „Bine, bine, ceva s-a schimbat cu siguranță la acest element”. Celălalt lucru este că este foarte frumos să dai acces JavaScript la acea stare și viceversa. Așa că îmi place foarte mult să aplic starea cu atribute de date în JavaScript. Cred că pentru asta sunt, în esență, un fel de nivel de comunicare. Armonia dintre ei pare să funcționeze foarte bine.

Andy: Deci, un bun exemplu este, să spunem că ai un mesaj de stare și apoi JavaScript va adăuga starea datelor este fie succes, eroare sau informații, sau ceva de genul. Puteți apoi să vă conectați la asta cu stilurile dvs. de excepție în CSS. Deci știți că aceasta este o excepție a componentei de stare și merge împotriva stării implicite. Deci este doar un mod foarte util de a lucra cu lucrurile. Este previzibil la ambele capete: este previzibil la capătul CSS și este previzibil și la capătul JavaScript.

Drew: Bănuiesc că este destul de frumos că ceva pe care numele de clasă nu ți-l oferă este o proprietate și o valoare. Deci, dacă vrei să ai ceva de genul care este statul și poate fi fie succes, fie eșec, sau avertisment sau ce ai tu, poți să te adresezi în mod specific acelei proprietăți de stat și să-i schimbi valoarea. În timp ce, cu o listă mare și lungă de nume de clase, dacă manipulați asta în JavaScript, de exemplu, va trebui să vă uitați la fiecare dintre ele și să adăugați acea logică de afaceri acolo care spune: „Pot doar seta una dintre acestea” și ce se întâmplă dacă două dintre acele clase sunt aplicate aceluiași element? Nu poți obține asta cu un atribut de date, are o singură valoare.

Andy: Da. E un mod bun de a spune asta, da. Este foarte util, am descoperit, să lucrezi așa.

Drew: Este destul de interesant. Nu cred că am văzut alte metodologii care să adopte această abordare. Este complet unic pentru CUBE, să faci asta?

Andy: S-ar putea să fie. Nu acord prea multă atenție altor lucruri, ceea ce ar trebui să le fac. Probabil că altcineva face asta. Vă spun acum, a fost cel mai controversat aspect al lui. Unii oameni chiar nu le-a plăcut ideea de a folosi atributele datelor. Chestia este, de asemenea, și cum răspund, este să faci ce vrei. Nu vă spunem să faceți lucrurile într-un anumit fel, sunt doar sugestii. Dacă vrei să faci excepții de la clasele CSS, cum ar fi modificatorii, atunci elimină-te. Poliția CUBE nu va veni să-ți bată la ușă. Este absolut bine.

Andy: Chestia cu CUBE este o chestie de gândire, este o structură. Aplicați acea structură oricum doriți să o aplicați, cu ce instrumente doriți sau orice tehnologie doriți. Atâta timp cât păstrezi lucrurile consistente, acesta este cel mai important.

Drew: Deci nu există un CUBE pur?

Andy: Felul în care o scriu este pur CUBE, Drew. Toți ceilalți sunt doar un fals, este doar o imitație slabă.

Drew: În afară de tine, nimeni nu poate spune: „Acesta nu este manual CUBE”.

Andy: Nu, asta este. Nimeni nu poate contesta asta cu adevărat, nu-i așa? Deci, da, voi merge cu asta. Îți dă puțină influență sau ceva, cred, așa ceva.

Drew: Puteți combina și potrivi o abordare CUBE cu alte metodologii? Puteți folosi bucăți de BEM?

Andy: Da, cred că da. M-am gândit puțin la asta pentru că o să fac mai multe lucruri în curând pentru că a devenit destul de popular, așa că oamenii vor dori mai multă muncă. Un lucru pe care mă voi uita este cum să abordez folosind metodologia CUBE cu ceva existent.

Andy: Deci există două capete opuse ale scalei. O întrebare bună pe care oamenii și-au pus-o este: „Cum funcționează asta cu fiecare aspect, cu celelalte lucruri?” Eu sunt ca, practic, fiecare aspect este C. Asta este fiecare aspect, este stratul compozițional. Apoi altcineva a întrebat: „Ei bine, cum ar funcționa asta cu ceva de genul Atomic Web Design, ca lucrurile lor pe care le-a făcut Brad Frost? E ca și cum, ei bine, ai putea sparge acele bucăți și le-ai aplica la fiecare nivel. Atomic Design merge până la microdetaliu. Este abstracția asta pentru a folosi, bine, bine, ei bine, pot aplica asta cu utilități, deci moleculele, cred. Pot aplica asta cu utilitățile și traduce ceea ce știți deja în această structură de lucru ușor diferită.

Andy: Într-adevăr, este o redenumire pentru o mulțime de lucruri. Nu am inventat nimic aici, doar am furat lucruri care îmi plac, așa cum spun. Îmi place felul în care sunt gândite unele dintre lucrurile despre Atomic Design. Este o muncă inteligentă. Și BEM. Lucrurile pe care le-a făcut Harry, CSS-ul Triunghi inversat, mi s-au părut grozav. Așa că am tăiat bucăți care îmi plac de la fiecare dintre ele și le-am împletit pe toate într-o altă abordare hibridă. Urmează altele, cred.

Drew: Abordarea CUBE poate fi aplicată proiectelor existente care au deja CSS în vigoare sau este ceva cu care chiar trebuie să începeți un nou proiect?

Andy: Asta depinde foarte mult. Deci, dacă ai un job de tip bootstrap și are doar mii de linii CSS personalizate, în care am mai fost implicat cu siguranță, atunci cred că ai putea încerca să stingi focul cu o sticlă de apă. punct. 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? Despre ce este vorba?

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: Da.

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: Mi-a plăcut să fac ceva puțin diferit și să aplic cunoștințele pe care le am și să le împărtășesc cu oamenii. Întotdeauna am fost foarte deschis și am împărtășit și am vrut să oficializez asta. Așa că am creat Piccalilli pentru a scrie tutoriale, dar mai ales pentru cursurile pe care le produc: asta e principala carne și cartofi. Și apoi este buletinul informativ care este... oamenilor le place foarte mult buletinul informativ pentru că împărtășesc lucruri interesante pe care le-am găsit pe internet în fiecare săptămână. Asta e coloana vertebrală a acesteia. Merge foarte bine. În esență, acolo vreau să mă văd făcând din ce în ce mai mult cu normă întreagă, pe măsură ce anii trec, cred.

Drew: Deci, ce urmează pentru Piccalilli? Ai ceva ce ai ieșit?

Andy: Mulțumesc pentru ușa deschisă acolo, Drew! Până la sfârșitul acestei înregistrări, primul curs va fi live: Learn Eleventy From Scratch, și acolo învățăm cum să construim un site web Gatsby! Nu, înveți cum să construiești un site Eleventy. Așa că începi cu un director complet gol, nu este nimic în el, este gol, iar apoi, la sfârșit, vei termina cu acest site de agenție foarte frumos. Învățăm tot felul în ea. Înveți cum să mergi cu adevărat în oraș cu Eleventy. Extragem date de la distanță din locuri. Folosim CUBE CSS pentru a construi un front-end foarte frumos pentru acesta.

Andy: Dacă vrei să intri în Jamstack și vrei să intri în generatoare de site-uri statice, sau doar cum să construiești un site web frumos, este doar un curs foarte util, sper, pentru asta. În prezent, este editat într-un centimetru de viață, în timp ce vorbim. Va fi tare, sper, și util. Dar aceasta este o acumulare a multor lucruri pe care le-am făcut în ultimii doi ani. Deci ar trebui să fie distractiv.

Andy: Așa că cumpără-l și voi face un cod de reducere, fac ca smashingpod cu o reducere de 40% și îl poți obține când va ieși.

Drew: Uimitor. Vom lega asta. V-ați dat seama cum să scrieți Piccalilli în mod fiabil?

Andy: Am fost cu Chris și Dave la ShopTalk Show și i-am spus acolo: „Dacă vrei vreodată să mă angajezi pentru un lucru, este să scriu Piccalilli de mână prima dată fără să mă gândesc la asta”, pentru că am am scris acel cuvânt de atâtea ori încât știu exact cum să-l scriu pe de rost. Deci răspunsul la întrebarea dvs. este da.

Drew: Ei bine, încă mă lupt, atât îți spun!

Andy: Este greu. Oh Doamne. empatizez total. Mi-a luat mult timp să învăț cum să scriu, dar este unul dintre acele cuvinte din vocabularul nostru. Anul acesta încerc să scriu necesar fără să greșesc de ortografie!

Drew: Așa că am învățat totul despre CUBE CSS. Despre ce ai învățat în ultima vreme, Andy?

Andy: Știi ce? Asta te va surprinde, Drew. MySQL este ceea ce am învățat recent. Deci, practic, Piccalilli este total autopublicat. Este un site Eleventy, dar are un API în spate și o bază de date MySQL în spate. Lucrurile care oferă oamenilor conținut pe care l-au achiziționat necesită niște interogări destul de intense. Așa că, de fapt, am investit corect în unele MySQL... în special diferența dintre alăturari, despre care nu mi-am dat seama că există o diferență între fiecare tip de alăturare. Așa că a fost cu adevărat util și a dus la niște interacțiuni destul de rapide cu baza de date.

Andy: Obișnuiam să conduc chestia asta numită Front-End Challenges Club și când l-am lansat prima oară, s-a prăbușit și a murit de la sine pentru că MySQL era cel puțin prost. Așa că am învățat cu adevărat cum să fac asta pentru că nu sunt deloc o persoană backend, sunt un pixel-pusher. Deci cu siguranță nu este în atribuțiile mele. Asta-i mai mult gâtul tău de pădure, nu-i așa? Mi se pare foarte tare, MySQL. Chiar îmi place foarte mult să o scriu. Este un limbaj foarte frumos, de instruire, nu-i așa?

Drew: Este, este grozav. Am învățat SQL la școală.

Andy: Uau!

Drew: Vorbim acum 20 de ani.

Andy: Aveau computere în acele vremuri?

Drew: Au făcut-o, da. A trebuit să vânt-

Andy: A trebuit să-l scrii de mână?

Drew: A trebuit să le terminăm! Noi am facut. Dar, vă spun că, pentru un dezvoltator, este asemănător cu a vă învăța tabelele de multiplicare: unul dintre acele lucruri care pare o corvoadă, dar odată ce sunteți fluent, devine util din când în când.

Andy: Da. Desigur. Există și diferențe cu adevărat tangibile. Chiar vezi diferența de viteză. Îmi place foarte mult să lucrez cu Node pentru că este foarte rapid, dar Node și MySQL sunt doar... nu o alegere foarte comună, dar cred că este o alegere destul de bună. Cred că funcționează foarte, foarte bine. Deci sunt fericit cu asta. După cum știți, nu-mi place să scriu PHP. Deci asta nu va fi niciodată o opțiune.

Drew: Dacă tu, dragă ascultător, ai dori să afli mai multe de la Andy, îl poți urmări pe Twitter, unde este la hankchizljaw. Puteți găsi Piccalilli pe piccalil.li, unde veți găsi și articolul care descrie CUBE CSS și vom adăuga, de asemenea, link-uri către toate acestea în notele emisiunii, desigur.

Drew: Vă mulțumim că v-ați alăturat astăzi, Andy. Ai avut cuvinte de despărțire?

Andy: Stați în siguranță și purtați masca.