De basisprincipes van objectgerichte CSS (OOCSS)

Frontend-ontwikkeling gaat snel en er worden elk jaar veel nieuwe technieken toegevoegd. Het kan een uitdaging zijn voor ontwikkelaars om alles bij te houden. Tussen Sass en PostCSS kun je gemakkelijk verdwalen in de zee van ontwikkeltools.

Een nieuwere techniek is Object-Oriented CSS, ook wel afgekort tot OOCSS. Dit is geen hulpmiddel, maar eerder een CSS-schrijfmethodologie die ernaar streeft maak CSS modulair en object-gebaseerd.

In deze post wil ik het kernfundamentals van OOCSS, en hoe deze ideeën kunnen worden toegepast op frontend webwerk. Deze techniek kan niet bij elke ontwikkelaar aansluiten, maar het is de moeite waard om nieuwe concepten te begrijpen om te bepalen of uw workflow hier baat bij zou kunnen hebben.

Wat maakt CSS Object-Oriented?

Object-oriented programming (OOP) is een programmeerparadigma dat zich richt op het maken van herbruikbare objecten en relaties leggen tussen hen in, in tegenstelling tot procedurele programmering die de code in procedures (routines, subroutines of functies) organiseert.

OOP is in beide veel gebruikt geworden JavaScript en back-endtalen in de afgelopen jaren, maar het organiseren van CSS volgens zijn principes is nog steeds een nieuw concept.

De “voorwerp” in OOCSS verwijst naar een HTML-element of iets dat daarmee samenhangt (zoals CSS-klassen of JavaScript-methoden). U kunt bijvoorbeeld een widgetobject in de zijbalk hebben dat voor verschillende doeleinden kan worden gerepliceerd (aanmelding voor nieuwsbrieven, advertentieblokken, recente berichten, enz.). CSS kan richt deze objecten massaal waardoor schalen een fluitje van een cent wordt.

Als je het GitHub-item van OOCSS samenvat, kan een CSS-object uit vier dingen bestaan:

1. HTML-knooppunt (en) van de DOM
2. CSS-verklaringen over de stijl van die knooppunten
3. Onderdelen zoals achtergrondafbeeldingen
4. JavaScript-gedrag, luisteraars of methoden die aan een object zijn gekoppeld

Over het algemeen is CSS objectgeoriënteerd als het overweegt klassen die herbruikbaar zijn en richtbaar op elementen met meerdere pagina's.

Veel ontwikkelaars zouden zeggen dat OOCSS gemakkelijker te delen is met anderen en gemakkelijker op te halen is na maanden (of jaren) van inactieve ontwikkeling. Dit is vergelijkbaar met andere modulaire methoden zoals SMACSS, die strengere regels heeft voor het categoriseren van objecten in CSS.

De OOCSS FAQ-pagina bevat veel informatie als u meer wilt weten. En de maker Nicole Sullivan praat vaak over OOCSS en hoe het aansluit bij moderne webontwikkeling.

Afzonderlijke structuur van stijl

Een groot deel van OOCSS is het schrijven van code die de paginastructuur (breedte, hoogte, marges, opvulling) scheidt van uiterlijk (lettertypen, kleuren, animaties). Dit staat toe op maat villen worden toegepast op meerdere pagina-elementen zonder de structuur aan te tasten.

Dit is ook handig voor het ontwerpen van componenten die kunnen zijn verplaatst rond de lay-out met gemak. Bijvoorbeeld a “recente berichten” widget in de zijbalk moet in de voettekst of boven de inhoud kunnen worden verplaatst met behoud van vergelijkbare stijlen.

Hier is een voorbeeld van OOCSS voor een “recente berichten” widget die in dit geval ons CSS-object is:

 / * Structuur * / .side-widget width: 100%; opvulling: 10px 5px;  / * Skinning * / .recent-posts font-family: Helvetica, Arial, sans-serif; kleur: # 2b2b2b; font-size: 1.45em;  

Let erop dat lay-out wordt beheerd met de .side-widget klasse die ook zou kunnen worden toegepast op meerdere zijbalkelementen, terwijl verschijning wordt beheerd met de .recente berichten klasse die ook kan worden gebruikt voor het omhullen van andere widgets. Bijvoorbeeld, als de .recente berichten widget werd verplaatst naar het voettekst, het zou niet dezelfde positionering kunnen hebben, maar het zou dezelfde look en feel kunnen hebben.

Neem ook een kijkje in dit zijbalkvoorbeeld van CodePen. Het maakt gebruik van een duidelijke scheiding van klassen voor drijvers en tekstuitlijning, zodat replicatie vereist geen extra CSS-code.

Gescheiden container van inhoud

Inhoud scheiden van het containerelement is een ander belangrijk principe van OOCSS.

In eenvoudiger bewoordingen betekent dit alleen dat je kinderselectors niet moet gebruiken wanneer dat mogelijk is. Wanneer u unieke pagina-elementen zoals ankerlinks, headers, blockquotes of ongeordende lijsten aanpast, moet u ze unieke klassen geven in plaats van afstammingskiezers.

Hier is een eenvoudig voorbeeld:

 / * OOCSS * / .sidebar / * zijbalkinhoud * / h2.sidebar-title / * speciale h2-elementstijlen * / / * Non-OOCSS * / .sidebar / * zelfde zijbalkinhoud * / .sidebar h2 / * voegt meer specificiteit toe dan nodig * / 

Hoewel het niet afschuwelijk is om het tweede codeformaat te gebruiken, wordt het sterk aanbevolen om het eerste formaat te volgen als je schone OOCSS wilt schrijven.

Ontwikkelingsrichtlijnen

Het is moeilijk om exacte specificaties vast te leggen, omdat ontwikkelaars voortdurend het doel van OOCSS bespreken. Maar hier zijn enkele suggesties die u kunnen helpen schonere OOCSS-code te schrijven:

• Werk met klassen in plaats van ID's voor styling.
• Probeer onthouden van multi-level nakomeling klassespecificiteit tenzij nodig.
• Bepalen unieke stijlen met herhaalbare klassen (bijvoorbeeld drijvers, clearfix, unieke lettertypestapels).
• Elementen uitbreiden met gerichte klassen in plaats van ouderlessen.
• Organiseer uw stylesheet in secties, overweeg een inhoudsopgave toe te voegen.

Houd er rekening mee dat ontwikkelaars nog steeds ID's moeten gebruiken voor JavaScript-targeting, maar deze zijn niet vereist voor CSS, omdat ze zijn te specifiek. Als een object een ID gebruikt voor CSS-styling, kan het nooit worden gerepliceerd, omdat ID's unieke ID's zijn. Als je dan alleen klassen voor styling gebruikt erfenis wordt veel gemakkelijker te voorspellen.

Bovendien kunnen klassen aan elkaar worden gekoppeld voor extra functies. Aan een enkel element kunnen er meer dan 10 klassen aan verbonden zijn. Hoewel meer dan 10 klassen op één element niet persoonlijk worden aanbevolen, kunnen ontwikkelaars een bibliotheek van herbruikbare stijlen voor onbeperkte pagina-elementen verzamelen.

Klasse namen binnen OOCSS zijn enigszins controversieel en niet in steen gehouwen. Veel ontwikkelaars geven er de voorkeur aan de lessen kort en to the point te houden.

Camel case is ook populair, bijvoorbeeld .errorBox in plaats van .error-box. Als je kijkt naar de naamgeving van de klassen in de documentatie van OOCSS, zul je merken dat camel case de “officieel” aanbeveling. Er is niets mis met streepjes maar in de regel is het het beste om de OOCSS-richtlijnen te volgen.

OOCSS + Sass

De meeste webontwikkelaars zijn al dol op Sass en het heeft de frontend-gemeenschap snel overvallen. Als je Sass nog niet hebt geprobeerd, is het de moeite waard om het te proberen. Hiermee kunt u code schrijven met variabelen, functies, nesten en compilatiemethoden, zoals wiskundige functies.

In competente handen kunnen Sass en OOCSS een match zijn in de hemel. Je vindt hier een uitstekende beschrijving van op het blog van The Sass Way.

Bijvoorbeeld het gebruik van de Sass @uitbreiden richtlijn kunt u de eigenschappen van een klasse toepassen op een andere klasse. De eigenschappen worden niet gedupliceerd maar in plaats daarvan worden de twee klassen gecombineerd met een kommaselectie. Op deze manier kunt u CSS-eigenschappen op één locatie bijwerken.

Als u constant stylesheets schrijft, bespaart u dit uren typen en helpen automatiseer het OOCSS-proces.

Onthoud dat ook code onderhoud is een groot deel van OOCSS. Door Sass te gebruiken, wordt uw taak eenvoudiger met variabelen, mixins en geavanceerde pluisgereedschappen die zijn gekoppeld aan de workflow.

Een belangrijk kenmerk van de geweldige OOCSS-code is de mogelijkheid om het met iedereen te delen, zelfs jezelf op een later tijdstip, en in staat zijn om het gemakkelijk op te pikken.

Overwegingen bij de uitvoering

OOCSS is bedoeld om soepel en zonder veel verwarring te werken. Ontwikkelaars doen hun best niet om zich bij elke draai te herhalen, sterker nog, dat is het uitgangspunt achter DRY-ontwikkeling. In de loop van de tijd kan de OOCSS-techniek leiden tot honderden CSS-klassen met individuele eigenschappen die tientallen keren zijn toegepast in een bepaald document.

Omdat OOCSS nog steeds een nieuw onderwerp is, is het moeilijk om te debatteren over het onderwerp bloat. Veel CSS-bestanden zijn opgeblazen met weinig structuur, terwijl OOCSS een stijve structuur en (idealiter) minder opgeblazenheid biedt. Het grootste probleem met de prestaties zou zijn in de HTML, waarbij sommige elementen een handvol verschillende klassen kunnen verzamelen voor lay-outstructuur en ontwerp.

Je vindt interessante discussies over dit onderwerp op sites zoals Stack Overflow en CSS-Tricks.

Mijn aanbeveling is om te proberen een voorbeeldproject te maken en te kijken hoe het gaat. Als je verliefd wordt op OOCSS, kan dit de manier waarop je websites codeert radicaal veranderen. Als alternatief, als je het haat, ben je nog steeds bezig met het leren van een nieuwe techniek en kritisch nadenken over hoe het werkt. Het is win-win, wat er ook gebeurt.

Krijg druk met het schrijven van OOCSS

De beste manier om iets te leren in webontwikkeling is door te oefenen. Als je de basisprincipes van CSS al begrijpt, ben je goed op weg!

Omdat OOCSS geen voorverwerking vereist, kunt u het proberen met een online IDE, zoals CodePen. Eenvoudige projecten zijn het beste om aan de slag te gaan en uw kennis van daaruit te verbeteren.

Bekijk deze bronnen om uw onderzoek in het zich ontwikkelende veld van OOCSS te bevorderen.

• Officiële OOCSS-website
• Object-georiënteerde CSS: wat, hoe en waarom
• OOCSS + Sass = De beste manier om CSS te gebruiken
• Een inleiding tot op Object georiënteerde CSS