Grunnleggende om Objektorientert CSS (OOCSS)

Frontend-utviklingen beveger seg raskt med mange nye teknikker som legges til hvert år. Det kan være en kamp for utviklere å holde tritt med alt. Mellom Sass og PostCSS er det lett å gå seg vill i utviklingsverktøyets sjø.

En nyere teknikk er Objektorientert CSS, også kalt OOCSS for kort. Dette er ikke et verktøy, men heller en CSS-skriftlig metode som tar sikte på å lage CSS modulære og objektbaserte .

I dette innlegget vil jeg gjerne presentere grunnleggende grunnleggende for OOCSS, og hvordan disse ideene kan brukes til frontend webarbeid . Denne teknikken kan ikke hende med hver utvikler, men det er verdt å forstå nye konsepter for å avgjøre om arbeidsflyten din kan ha nytte av det.

Hva gjør CSS Objektorientert?

Objektorientert programmering (OOP) er et programmeringsparadigm som fokuserer på å lage gjenbrukbare objekter og etablere relasjoner mellom dem, i motsetning til prosessorprogrammering som organiserer koden i prosedyrer (rutiner, subrutiner eller funksjoner).

OOP har blitt mye brukt på både JavaScript og backend-språk de siste årene, men organisering av CSS i henhold til prinsippene er fortsatt et nytt konsept.

Objektet i OOCSS refererer til et HTML-element eller noe som er knyttet til det (som CSS-klasser eller JavaScript-metoder). For eksempel kan det hende du har et sidebar-widgetobjekt som kan kopieres til forskjellige formål (nyhetsbrevoppføring, annonseblokker, nye innlegg osv.). CSS kan målrette disse objektene en masse som gjør skalering en bris.

Oppsummering av OOCSS 'GitHub-oppføring, et CSS-objekt kan bestå av fire ting:

1. HTML-node (r) av DOM
2. CSS-erklæringer om stilen til disse noderne
3. Komponenter som bakgrunnsbilder
4. JavaScript-oppførsel, lyttere eller metoder knyttet til et objekt

Generelt sett er CSS objektorientert når det vurderer klasser som er gjenbrukbare og målrettede mot flere sideelementer .

Mange utviklere vil si at OOCSS er lettere å dele med andre og lettere å plukke opp etter måneder (eller år) med inaktiv utvikling. Dette sammenlignes med andre modulære metoder som SMACSS, som har strengere regler for kategorisering av objekter i CSS.

OOCSS FAQ-siden har en haug med info hvis du er nysgjerrig på å lære mer. Og skaperen Nicole Sullivan snakker ofte om OOCSS og hvordan det knytter seg til moderne webutvikling.

Separat struktur fra stil

En stor del av OOCSS skriver kode som skiller sidestruktur (bredde, høyde, marginer, polstring) fra utseende (fonter, farger, animasjoner). Dette gjør det mulig å påføre tilpasset skinning på flere sideelementer uten å påvirke strukturen .

Dette er også nyttig for å designe komponenter som enkelt kan flyttes rundt oppsettet . For eksempel, en "Nylig innlegg" -grensesnitt i sidefeltet skal være flyttbar i bunnteksten eller over innholdet, samtidig som lignende stiler opprettholdes.

Her er et eksempel på OOCSS for en "Nylig innlegg" -grensesnitt som i dette tilfellet er CSS-objektet vårt:

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

Legg merke til at layoutet håndteres med .side-widget klassen som også kan brukes på flere sidebjelkeelementer, mens utseendet styres med klassen .recent-posts som også kan brukes til å .recent-posts andre widgets. Hvis for eksempel widgeten .recent-posts ble flyttet til bunnteksten, kan det ikke ta samme posisjonering, men det kan ha samme utseende.

Ta også en titt på dette sidebareksemplet fra CodePen. Den bruker en tydelig adskillelse av klasser for flyter og tekstjustering, slik at replikering ikke krever ekstra CSS-kode .

Separat beholder fra innhold

Å skille innhold fra beholderelementet er et annet viktig prinsipp for OOCSS.

I enklere termer betyr dette bare at du bør unngå å bruke barnvalg når det er mulig. Når du tilpasser noen unike sideelementer som ankerforbindelser, overskrifter, blokkeringer eller uordnede lister, bør du gi dem unike klasser fremfor avhengige selectors.

Her er et enkelt eksempel:

 / * OOCSS * / .sidebar {/ * sidebar innhold * /} h2.sidebar-title {/ * spesielle h2 element stiler * /} / * Ikke-OOCSS * / .sidebar {/ * samme sidebar innhold * /} .sidebar h2 {/ * legger mer spesifisitet enn nødvendig * /} 

Selv om det ikke er fryktelig å bruke det andre kodeformatet, anbefales det sterkt å følge det første formatet hvis du vil skrive rent OOCSS.

Utviklingsretningslinjer

Det er vanskelig å spikre ned eksakte spesifikasjoner fordi utviklere stadig diskuterer formålet med OOCSS. Men her er noen forslag som kan hjelpe deg med å skrive renere OOCSS-kode :

• Arbeid med klasser i stedet for ID for styling.
• Prøv å avstå fra klassen spesifisitet på flere nivåer, med mindre det er nødvendig.
• Definer unike stiler med repeterbare klasser (f.eks. Flyter, clearfix, unike fontstabler).
• Utvid elementer med målrettede klasser fremfor foreldreklasser.
• Organiser stilarket i seksjoner, vurder å legge til en innholdsfortegnelse.

Merk at utviklere fortsatt bruker ID-er for JavaScript-målretting, men de er ikke påkrevd for CSS fordi de er for spesifikke . Hvis ett objekt bruker en ID for CSS-styling, kan den aldri replikeres siden ID-er er unike identifikatorer. Hvis du bare bruker klasser for styling, blir arv mye enklere å forutsi .

Videre kan klasser legges sammen for ekstra funksjoner. Et enkelt element kan ha 10+ klasser knyttet til det. Mens 10+ klasser på ett element ikke er noe jeg personlig vil anbefale, tillater det utviklere å samle et bibliotek med gjenbrukbare stiler for ubegrensede sideelementer.

Klassenavnene i OOCSS er noe kontroversielle, og ikke satt i stein. Mange utviklere foretrekker å holde klasser kort og til poenget.

Camel saken er også populær, for eksempel .errorBox i stedet for .error-box . Hvis du ser på klassenavn i OOCSS dokumentasjon, vil du legge merke til at kamelhallen er den "offisielle" anbefalingen. Det er ikke noe galt med bindestrek, men det er som regel å følge OOCSS-retningslinjene.

OOCSS + Sass

De fleste webutviklere elsker allerede Sass, og det har raskt overhalet frontend-fellesskapet. Hvis du ikke allerede har prøvd Sass, er det verdt å gi det et skudd. Det lar deg skrive kode med variabler, funksjoner, nesting og kompilering metoder som matematiske funksjoner.

I kompetente hender kunne Sass og OOCSS være en kamp i himmelen. Du finner en utmerket writeup om dette på The Sass Way blogg.

For eksempel, ved hjelp av Sass @extend direktivet kan du bruke egenskapene til en klasse til en annen klasse. Egenskapene blir ikke duplisert, men i stedet blir de to klassene kombinert med en kommavalg. På denne måten kan du oppdatere CSS-egenskaper på ett sted.

Hvis du stadig skriver stilark, vil dette spare timer for å skrive og hjelpe automatisere OOCSS-prosessen .

Husk også at kodevedlikehold er en stor del av OOCSS . Ved å bruke Sass blir jobben enklere med variabler, mixins og avanserte linting-verktøy som er bundet inn i arbeidsflyten.

En nøkkelattributt til stor OOCSS-kode er evnen til å dele den med noen, selv selv på et senere tidspunkt, og kunne plukke det opp med letthet.

Prestasjonshensyn

OOCSS er ment å operere jevnt og uten mye forvirring. Utviklere prøver sitt beste for ikke å gjenta seg i hver tur, faktisk er det grunnlaget bak DRY-utviklingen. Over tid kan OOCSS-teknikken føre til hundrevis av CSS-klasser med individuelle egenskaper brukt mange ganger i et gitt dokument.

Siden OOCSS fortsatt er et nytt emne, er det vanskelig å argumentere for emnet for oppblåsthet. Mange CSS-filer blir oppblåst med liten struktur, mens OOCSS gir stiv struktur og (ideelt sett) mindre oppblåsthet. Den største ytelsesproblemet vil være i HTML-koden der enkelte elementer kan samle en håndfull forskjellige klasser for layoutstruktur og design.

Du finner interessante diskusjoner om dette emnet på nettsteder som Stack Overflow og CSS-Tricks.

Min anbefaling er å prøve å bygge et utvalgsprosjekt, og se hvordan det går. Hvis du blir forelsket i OOCSS, kan det radikalt endre hvordan du koder nettsteder. Alternativt, hvis du hater det, lærer du fortsatt en ny teknikk og tenker kritisk på hvordan den fungerer. Det er vinn-vinn uansett hva.

Få opptatt skrive OOCSS

Den beste måten å lære noe på i webutvikling er å øve. Hvis du allerede forstår grunnleggende om CSS, er du bra på vei!

Siden OOCSS ikke krever forhåndsbehandling, kan du prøve det med en online IDE, for eksempel CodePen. Enkle prosjekter er de beste for å komme i gang, og forbedre kunnskapen din derfra.

Ta en titt på disse ressursene for å fremme din forskning i det utviklende feltet OOCSS.

• OOCSS offisielle nettsted
• Objektorientert CSS: Hva, hvordan og hvorfor
• OOCSS + Sass = Den beste måten å CSS
• En introduksjon til objektorientert CSS