Grunderna för Objektorienterad CSS (OOCSS)

Frontend-utvecklingen går snabbt med många nya tekniker som läggs till varje år. Det kan vara en kamp för utvecklare att fortsätta med allting. Mellan Sass och PostCSS är det lätt att gå vilse i havet av utvecklingsverktyg.

En nyare teknik är Objektorienterad CSS, även kallad OOCSS för kort. Detta är inte ett verktyg, utan snarare en CSS-skriftlig metodik som syftar till gör CSS modulär och objektbaserad.

I det här inlägget vill jag presentera kärngrunderna för OOCSS, och hur dessa idéer kan tillämpas på frontend webbarbete. Denna teknik kan inte hända med alla utvecklare, men det är värt att förstå nya koncept för att bestämma om ditt arbetsflöde kan dra nytta av det.

Vad gör CSS Objektorienterad?

Objektorienterad programmering (OOP) är ett programmeringsparadigm som fokuserar på skapa återanvändbara objekt och upprätta relationer mellan dem, i motsats till procedurprogrammering som organiserar koden i rutiner (rutiner, subrutiner eller funktioner).

OOP har blivit allmänt använd i båda JavaScript och backend språk under de senaste åren, men att organisera CSS enligt principerna är fortfarande ett nytt koncept.

De “objekt” i OOCSS avser en HTML-element eller något som hör samman med det (som CSS-klasser eller JavaScript-metoder). Du kan till exempel ha ett sidobar-widgetobjekt som kan replikeras för olika ändamål (nyhetsbrevsregistrering, annonsblock, senaste inlägg etc.). CSS kan rikta dessa objekt en-masse vilket gör skalning en bris.

Sammanfattar OOCSS 'GitHub-post kan ett CSS-objekt bestå av fyra saker:

1. HTML-noden i DOM
2. CSS-deklarationer om stilen hos dessa noder
3. Komponenter som bakgrundsbilder
4. JavaScript-beteenden, lyssnare eller metoder som är associerade med ett objekt

Generellt sett är CSS objektorienterad när den anser det klasser som är återanvändbara och rikta till flera sidelement.

Många utvecklare skulle säga att OOCSS är lättare att dela med andra och lättare att hämta efter månader (eller år) av inaktiv utveckling. Detta jämförs med andra modulära metoder som SMACSS, som har strängare regler för kategorisering av objekt i CSS.

OOCSS FAQ-sidan har en massa information om du är nyfiken på att lära dig mer. Och skaparen Nicole Sullivan talar ofta om OOCSS och hur det knyter samman med modern webbutveckling.

Separat struktur från stil

En stor del av OOCSS skriver kod som skiljer sidstrukturen (bredd, höjd, marginal, vaddering) från utseende (teckensnitt, färger, animeringar). Det här tillåter anpassad skinning att appliceras på flera sidelement utan att påverka strukturen.

Detta är också användbart för att designa komponenter som kan vara flyttade runt layouten lätt. Till exempel a “Nya Inlägg” widgeten i sidofältet ska kunna flyttas till sidfot eller över innehållet samtidigt som liknande format hålls.

Här är ett exempel på OOCSS för en “Nya Inlägg” widget som i detta fall är vårt CSS-objekt:

 / * Structure * / .side-widget width: 100%; vaddering: 10px 5px;  / * Skinning * / .recent-inlägg font-family: Helvetica, Arial, sans-serif; färg: # 2b2b2b; font-size: 1.45em;  

Lägg märke till att layout hanteras med .sida-widget klass som också kan tillämpas på flera sidofältelement, medan utseende hanteras med .Nya Inlägg klass som också kan användas för att skina andra widgets. Till exempel, om .Nya Inlägg widgeten flyttades till sidfoten, det kanske inte tar samma positionering, men det kan ha samma utseende.

Ta även en titt på det här sidfältet från CodePen. Det använder en distinkt separation av klasser för flottor och textjustering så att replikering kräver inte extra CSS-kod.

Separat behållare från innehåll

Separering av innehåll från dess behållarelement är en annan viktig princip för OOCSS.

I enklare termer innebär det bara att du bör undvika att använda barnväljare när det är möjligt. När du anpassar några unika sidelement som ankarlänkar, rubriker, blockquotes eller oorderade listor, borde du ge dem unika klasser i stället för efterföljande väljare.

Här är ett enkelt exempel:

 / * OOCSS * / .sidebar / * sidebar innehåll * / h2.sidebar-title / * speciella h2-elementstilar * / / * Non-OOCSS * / .sidebar / * samma sidfältets innehåll * / .sidebar h2 / * lägger mer specificitet än behövs * / 

Även om det inte är fruktansvärt att använda det andra kodformatet rekommenderas det starkt att följa det första formatet om du vill skriva ren OOCSS.

Utvecklingsriktlinjer

Det är svårt att spika ner exakta specifikationer eftersom utvecklare ständigt diskuterar syftet med OOCSS. Men här är några förslag som kan hjälpa dig att skriva renare OOCSS-kod:

• Arbeta med klasser istället för ID-skivor för styling.
• Försöka avstå från klassnivå specificitet på flera nivåer om inte behövs.
• Definiera unika stilar med repeterbara klasser (t.ex. floats, clearfix, unika typsnittstaplar).
• Utöka elementen med riktade klasser snarare än förälderklasser.
• Organisera ditt stilark i sektioner, överväga att lägga till en innehållsförteckning.

Observera att utvecklare fortfarande ska använda ID för JavaScript-inriktning, men de är inte nödvändiga för CSS eftersom de är för specifika. Om ett objekt använder ett ID för CSS-styling kan det aldrig replikeras eftersom ID-er är unika identifierare. Om du bara använder klasser för styling då arv blir mycket lättare att förutsäga.

Dessutom kan klasser sammanfogas för extra funktioner. Ett enda element kan ha 10 + klasser kopplade till det. Medan 10+ klasser på ett element inte är något jag personligen rekommenderar, tillåter det utvecklare att samla ett bibliotek med återanvändbara stilar för obegränsade sidelement.

Klassnamn inom OOCSS är något kontroversiella och inte i sten. Många utvecklare föredrar att hålla klasserna korta och till den punkten.

Camel fallet är också populärt, till exempel .errorBox istället för .error-box. Om du tittar på klassnamn i OOCSS dokumentation kommer du att märka att kamelväska är “officiell” rekommendation. Det finns inget fel med bindestreck, men som regel är det bäst att följa OOCSS-riktlinjerna.

OOCSS + Sass

De flesta webbutvecklare älskar redan Sass och det har snabbt tagit fram frontendgemenskapen. Om du inte redan har försökt Sass, är det värt att ge det ett skott. Det låter dig skriva kod med variabler, funktioner, nestnings- och kompileringsmetoder som matematiska funktioner.

I behöriga händer kan Sass och OOCSS vara en match gjord i himlen. Du hittar en utmärkt skrivning om detta på The Sass Way blogg.

Till exempel använder Sass @förlänga Direktivet kan du tillämpa en klassens egenskaper på en annan klass. Egenskaperna dupliceras inte, men i stället kombineras de två klasserna med en kommandoväljare. På så sätt kan du uppdatera CSS-egenskaper på en plats.

Om du ständigt skriver stilark skulle det spara timmar av typning och hjälp automatisera OOCSS-processen.

Kom också ihåg det kodunderhåll är en stor del av OOCSS. Genom att använda Sass blir ditt jobb enklare med variabler, mixins och avancerade linsverktyg som är knutna till arbetsflödet.

En nyckelattribut av stor OOCSS-kod är förmåga att dela den med någon, även dig själv vid ett senare tillfälle och kunna hämta det med lätthet.

Prestanda överväganden

OOCSS är tänkt att fungera smidigt och utan stor förvirring. Utvecklare försöker sitt bästa inte att upprepa sig vid varje tur, i själva verket är det förutsättningen för DRY-utvecklingen. Med tiden kan OOCSS-tekniken leda till hundratals CSS-klasser med enskilda egenskaper som används tiotals gånger i ett visst dokument.

Eftersom OOCSS fortfarande är ett nytt ämne är det svårt att argumentera för ämnet bloat. Många CSS-filer hamnar uppblåst med liten struktur, medan OOCSS ger styv struktur och (idealiskt) mindre uppblåst. Den största prestationshänsynen skulle vara i HTML där vissa element kan ackumulera en handfull olika klasser för layoutstruktur och design.

Du hittar intressanta diskussioner om detta ämne på webbplatser som Stack Overflow och CSS-Tricks.

Min rekommendation är att försöka bygga ett provprojekt och se hur det går. Om du blir kär i OOCSS, kan det radikalt ändra hur du kodar webbplatser. Alternativt, om du hatar det, lär du dig fortfarande en ny teknik och tänker kritiskt på hur det fungerar. Det är win-win oavsett vad.

Få upptagen skrivande OOCSS

Det bästa sättet att lära sig något i webbutveckling är att öva. Om du redan förstår grunderna i CSS så är du väl på väg!

Eftersom OOCSS inte kräver förbehandling kan du prova det med en online IDE, till exempel CodePen. Enkla projekt är det bästa för att komma igång, och förbättra din kunskap därifrån.

Ta en titt på dessa resurser för att fortsätta din forskning inom OOCSS utvecklingsfält.

• OOCSS officiella hemsida
• Objektorienterad CSS: Vad, Hur och Varför
• OOCSS + Sass = Det bästa sättet att CSS
• En introduktion till objektorienterad CSS