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 snarere 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 web arbeid. 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å skaper gjenbrukbare objekter og etablere relasjoner mellom dem, i motsetning til prosedyreprogrammering som organiserer koden i prosedyrer (rutiner, underrutiner eller funksjoner).
OOP har blitt mye brukt i begge deler JavaScript og backend språk i de siste årene, men å organisere CSS i henhold til prinsippene er fortsatt et nytt konsept.
De “gjenstand” i OOCSS refererer til en 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ål disse objektene en masse som gjør skalering en bris.
Oppsummering av OOCSS 'GitHub-oppføring, et CSS-objekt kan bestå av fire ting:
- HTML-node (r) av DOM
- CSS-erklæringer om stilen til disse noderne
- Komponenter som bakgrunnsbilder
- JavaScript-oppførsel, lyttere eller metoder knyttet til et objekt
Generelt sett er CSS objektorientert når den vurderer klasser som er gjenbrukbare og målrettes 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 tillater tilpasset skinning å brukes på flere sideelementer uten å påvirke strukturen.
Dette er også nyttig for å designe komponenter som kan være flyttet rundt oppsettet enkelt. For eksempel a “Siste innlegg” Widget i sidefeltet bør være flyttbart i bunnteksten eller over innholdet mens du opprettholder lignende stiler.
Her er et eksempel på OOCSS for a “Siste innlegg” widget 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 det oppsett håndteres med .side-widget klasse som kan brukes til flere sidebar elementer også, mens utseende håndteres med .Siste innlegg klassen som også kan brukes til å skape andre widgets. For eksempel, hvis .Siste innlegg widgeten ble flyttet til bunnteksten, det kan ikke ta samme posisjonering, men det kan ha samme utseende.
Ta også en titt på dette sidebareksemplet fra CodePen. Det bruker en tydelig adskillelse av klasser for flyter og tekstjustering slik at replikering vil ikke kreve ekstra CSS-kode.
Separat beholder fra innhold
Separerer 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 ankerkoblinger, overskrifter, blokkeringer eller uordnede lister, bør du gi dem unike klasser i stedet for etterkommere.
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 ren 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:
- Jobbe med klasser i stedet for IDer for styling.
- Prøv å avstå fra klassen spesifisitet av flere nivåer etterkommere med mindre det trengs.
- Definere unike stiler med repeterbare klasser (f.eks. flyter, clearfix, unike fontstabler).
- Utvid elementer med målrettede klasser heller enn foreldre klasser.
- Organiser stilarket ditt inn i seksjoner, vurdere å 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 bli replikert siden ID-er er unike identifikatorer. Hvis du bare bruker klasser for styling da arv blir mye lettere å forutsi.
Videre kan klasser sammenkobles 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 “offisielt” anbefaling. 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 @forlenge 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 med å skrive og hjelp automatiser OOCSS prosessen.
Husk også det 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 evne til å dele det med noen, selv deg selv på et senere tidspunkt, og være i stand til å plukke det opp med letthet.
Prestasjonshensyn
OOCSS er ment å operere jevnt og uten mye forvirring. Utviklere prøver sitt beste ikke å gjenta seg ved 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 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 skriving 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
