Grundlæggende om Objektorienteret CSS (OOCSS)

Frontend-udvikling bevæger sig hurtigt med mange nye teknikker, der tilføjes hvert år. Det kan være en kamp for udviklere at holde trit med alt. Mellem Sass og PostCSS er det nemt at gå vild i havet af udviklingsværktøjer.

En nyere teknik er Objektorienteret CSS, også kaldet OOCSS for kort. Dette er ikke et værktøj, men snarere en CSS-skriftlig metode, der sigter mod lav CSS modulære og objektbaserede.

I dette indlæg vil jeg gerne introducere grundlæggende grundlæggende elementer i OOCSS, og hvordan disse ideer kan anvendes til frontend web arbejde. Denne teknik går måske ikke i vejen for hver udvikler, men det er værd at forstå nye koncepter for at afgøre, om din arbejdsgang kan drage fordel af det.

Hvad gør CSS objektorienteret?

Objektorienteret programmering (OOP) er et programmeringsparadigme, der fokuserer på skabe genanvendelige objekter og etablering af relationer mellem dem, i modsætning til procedurel programmering, der organiserer koden i procedurer (rutiner, subrutiner eller funktioner).

OOP er blevet almindeligt anvendt i begge JavaScript og backend sprog i de sidste par år, men at organisere CSS efter sine principper er stadig et nyt koncept.

Det “objekt” i OOCSS henviser til en HTML-element eller noget der er forbundet med det (som CSS-klasser eller JavaScript-metoder). Du kan f.eks. Have et sidebar-widgetobjekt, der kan replikeres til forskellige formål (nyhedsbrev, annonceblokke, seneste indlæg osv.). CSS kan mål disse objekter en masse som gør skalering en brise.

Sammenfatning af OOCSS 'GitHub-indtastning kan et CSS-objekt bestå af fire ting:

1. HTML-knudepunkter i DOM
2. CSS-erklæringer om stilen af ​​disse knuder
3. Komponenter som baggrundsbilleder
4. JavaScript-adfærd, lyttere eller metoder, der er knyttet til et objekt

Generelt er CSS objektorienteret, når den anser det klasser, der kan genbruges og målrettet til flere sideelementer.

Mange udviklere vil sige, at OOCSS er lettere at dele med andre og lettere at afhente efter måneder (eller år) med inaktiv udvikling. Dette sammenligner med andre modulære metoder som SMACSS, som har strengere regler for kategorisering af objekter i CSS.

OOCSS FAQ-siden har en masse information, hvis du er nysgerrig efter at lære mere. Og skaberen Nicole Sullivan snakker ofte om OOCSS og hvordan det knytter sig til moderne webudvikling.

Separat struktur fra stil

En stor del af OOCSS skriver kode, der adskiller sidestruktur (bredde, højde, margener, polstring) fra udseende (skrifttyper, farver, animationer). Dette tillader det brugerdefinerede afskalling der skal anvendes på flere sideelementer uden at påvirke strukturen.

Dette er også nyttigt til at designe komponenter, der kan være flyttede rundt i layoutet med lethed. For eksempel a “Seneste indlæg” widget i sidepanelet skal kunne flyttes til footer eller over indholdet, samtidig med at lignende stilarter opretholdes.

Her er et eksempel på OOCSS for a “Seneste indlæg” widget, der i dette tilfælde er vores CSS objekt:

 / * Struktur * / .side-widget bredde: 100%; polstring: 10px 5px;  / * Skinning * / .recent-posts font-family: Helvetica, Arial, sans-serif; farve: # 2b2b2b; font-size: 1.45em;  

Læg mærke til det layout styres med .side-widget klasse, der også kunne anvendes på flere sidebarelementer udseende styres med .Seneste indlæg klasse, der også kunne bruges til at beskytte andre widgets. For eksempel, hvis .Seneste indlæg widget blev flyttet til sidefoden, kan det ikke tage den samme positionering, men det kunne have det samme udseende.

Se også på dette sidefelt eksempel fra CodePen. Det bruger en klar adskillelse af klasser for flyder og tekstjustering, så det replikering kræver ikke ekstra CSS-kode.

Separat container fra indhold

At adskille indhold fra dets beholderelement er et andet vigtigt princip for OOCSS.

I enklere termer betyder det kun, at du bør undgå at bruge børnesælgere, når det er muligt. Når du tilpasser nogle unikke sideelementer som ankerlinks, overskrifter, blokeringer eller uordnede lister, skal du give dem unikke klasser frem for efterkommere.

Her er et simpelt eksempel:

 / * OOCSS * / .sidebar / * sidebar indhold * / h2.sidebar-title / * specielle h2 element stilarter * / / * Ikke-OOCSS * / .sidebar / * samme sidebar indhold * / .sidebar h2 / * tilføjer mere specificitet end nødvendigt * / 

Selvom det ikke er forfærdeligt at bruge det andet kodeformat, anbefales det stærkt at følge det første format, hvis du vil skrive rent OOCSS.

Udviklingsretningslinjer

Det er svært at negle nøjagtige specifikationer, fordi udviklere konstant diskuterer formålet med OOCSS. Men her er nogle forslag, der kan hjælpe dig med at skrive renere OOCSS kode:

• Arbejde med klasser i stedet for id'er til styling.
• Forsøge at afholde sig fra flere niveau efterkommere klasse specificitet medmindre det er nødvendigt.
• Definere unikke stilarter med gentagelige klasser (f.eks. floats, clearfix, unikke skrifttypestabler).
• Udvid elementer med målrettede klasser snarere end forældre klasser.
• Organiser dit stylesheet i sektioner, overvej at tilføje en indholdsfortegnelse.

Bemærk, at udviklere stadig skal bruge ID'er til JavaScript-målretning, men de er ikke påkrævet for CSS, fordi de er for specifikke. Hvis et objekt bruger et ID til CSS-styling, kan det aldrig replikeres, da ID'er er unikke identifikatorer. Hvis du kun bruger klasser til styling så arv bliver meget lettere at forudsige.

Desuden kan klasser kædes sammen for ekstra funktioner. Et enkelt element kunne have 10 + klasser knyttet til det. Mens 10+ klasser på ét element ikke er noget, jeg personligt vil anbefale, tillader det udviklere at samle et bibliotek med genanvendelige stilarter til ubegrænsede sideelementer.

Klassenavne inden for OOCSS er noget kontroversielle og ikke sat i sten. Mange udviklere foretrækker at holde klasser kort og til det punkt.

Camel sagen er også populær, for eksempel .errorBox i stedet for .fejl-box. Hvis du kigger på klasse navngivning i OOCSS 'dokumentation, vil du bemærke kamel tilfælde er “officiel” henstilling. Der er ikke noget galt med bindestreger, men det er som regel bedst at følge OOCSS retningslinjerne.

OOCSS + Sass

De fleste webudviklere elsker allerede Sass, og det har hurtigt overhalet frontend-fællesskabet. Hvis du ikke allerede har prøvet Sass, er det værd at give det et skud. Det giver dig mulighed for at skrive kode med variabler, funktioner, nesting og compilation metoder som matematiske funktioner.

I kompetente hænder kunne Sass og OOCSS være en kamp lavet i himlen. Du finder en glimrende writeup om dette på The Sass Way blog.

For eksempel ved hjælp af Sass @forlænge Direktivet kan du anvende egenskaberne af en klasse på en anden klasse. Egenskaberne er ikke dupliceret, men i stedet kombineres de to klasser med en kommavælger. På den måde kan du opdatere CSS-egenskaber på ét sted.

Hvis du konstant skriver stylesheets dette ville spare timers skrivning og hjælp automatisere OOCSS processen.

Husk også det kode vedligeholdelse er en stor del af OOCSS. Ved at bruge Sass bliver dit job lettere med variabler, mixins og avancerede linting-værktøjer, der er bundet i arbejdsgangen.

En vigtig egenskab af stor OOCSS kode er evnen til at dele det med nogen, selv selv på et senere tidspunkt, og være i stand til at hente det med lethed.

Overvejelser om præstationer

OOCSS er beregnet til at fungere glat og uden forvirring. Udviklere forsøger deres bedste ikke at gentage sig ved hver tur, faktisk er det forudsætningen bag DRY-udvikling. Over tid kan OOCSS-teknikken føre til hundredvis af CSS-klasser med individuelle egenskaber, der er anvendt snesevis af gange i et givet dokument.

Da OOCSS stadig er et nyt emne, er det svært at argumentere for emnet for opblussen. Mange CSS-filer ender op med små strukturer, mens OOCSS giver stiv struktur og (ideelt set) mindre opblussen. Den største ydeevne bekymring ville være i HTML, hvor nogle elementer kan akkumulere en håndfuld forskellige klasser til layout struktur og design.

Du finder interessante diskussioner om dette emne på websteder som Stack Overflow og CSS-Tricks.

Min anbefaling er at forsøge at opbygge et stikprøveprojekt, og se hvordan det går. Hvis du bliver forelsket i OOCSS, kan det ændre sig radikalt, hvordan du kode websteder. Alternativt, hvis du hader det, lærer du stadig en ny teknik og tænker kritisk på, hvordan den fungerer. Det er win-win uanset hvad.

Få travlt at skrive OOCSS

Den bedste måde at lære noget på i webudvikling er at øve. Hvis du allerede forstår det grundlæggende i CSS, så er du godt på vej!

Da OOCSS ikke kræver forudbehandling, kan du prøve det med en online IDE, som f.eks. CodePen. Enkle projekter er de bedste for at komme i gang, og forbedre din viden derfra.

Kig på disse ressourcer for at fremme din forskning i OOCSS 'udvikling.

• OOCSS officielle hjemmeside
• Objektorienteret CSS: Hvad, hvordan og hvorfor
• OOCSS + Sass = Den bedste måde at CSS
• En introduktion til objektorienteret CSS