Blog

Újrafelhasználható CSS

Publikálva: 2014.03.01 10:45
Újrafelhasználható CSS, OOCSS, SMACSS

Számos módszer és ajánlás létezik arra, hogy a CSS és HTML kódunk jó része újrafelhasználható legyen az újabb és újabb projektekben. OOCSS, SMACSS. Ezek nem új nyelvek, hanem a statikus CSS újragondolása. Ezen ajánlások célja, hogy ösztönözzék az újrafelhasználást, miközben a forráskódunk átláthatóbb, karbantarthatóbb lesz és a CSS-en végzett munka is felgyorsul.

Rizikófaktorok

Vegyünk számításba néhány tényezőt, amik káoszt eredményezhetnek frontend téren.
Közepes és nagy weboldalaknál probléma lehet, ha valaki nem tartja kézben a dolgokat. Az ő feladata lenne az alap stílusok meghatározása, egyeztetnie a grafikussal, hogy a lehető legtöbb elem újrafelhasználható legyen. Az idő kulcsfontosságú tényező ebben, gyakran tapasztaltam, hogy minden munka tegnapra kell és az egész tarthatatlan lett.
Továbbfejlesztésnél hasonló a probléma. Mennyivel könnyebb megnyitni a css fájlunk, legörgetni a végére, elhelyezni amit kell. Esetleg lemásolok még néhány stílus jegyet, amit korábban alkalmaztam, és máris elkezdenek ismétlődni a stílusok. Ezáltal a css állományunk hatalmasra hízik, és a káoszban előfordul, hogy beragadnak már rég nem használt css részek is.

Az idő kulcsfontosságú tényező

Az idő hiányában képesek vagyunk minden szabályt felrúgni ezáltal káoszt teremteni. Pedig megfelelő eszközökkel képesek lehetünk a munkát hamarabb elvégezni. Rengeteg hasznos segédeszköz, css lib és framework létezik. Mindenképpen használjuk őket, de csak okosan. Ne essünk át a ló túlsó oldalára azzal, hogy a css helyett használt LESS mérete kétszer akkor lesz, mint az eredeti CSS állományé. Sokszor látni rá példát.

OOCSS (Object Oriented CSS), az objektum orientált css

Az objektum orientált css az egyik ajánlás, amit szeretnék röviden ismertetni. Legfőbb alapköve, hogy csak css osztályokat használ. Így a css megtartja rugalmasságát, újrafelhasználhatóságát. Jó tervezéssel a css állományunk átlátható és karbantarthatóbb lesz. Ez az egész Nicole Sullivan nevéhez fűződik. Ő benne fogalmazódott meg 2009-ben először két egyszerű szabály:

  • A struktúrát válasszuk el a designtól
  • A konténert válasszuk el tartalomtól

Mindez a gyakorlatban annyit jelent, hogy a block és position elemeinket szétválasztjuk a háttér és szín stílusjegyektől. Vagyis készítünk egy grid rendszert, amit újrahasznosíthatunk akár más projektekben is. Saját projekten belül pedig bármelyik stílusjegy újrafelhasználható lehetőség szerint.

SMACSS (Scalable and Modular Architecture for CSS)

Rögtön át is térek a következő ajánlásra, SMACSS. Ez az egész nem más, mint az OOCSS továbbgondolása. Az SMACSS az OOCSS által nem érintett részeket is számításba veszi. Így történt az, hogy Johnatan Snook 2011-ben azt mondta, hogy a css-t kategorizáljuk és létrehozott öt kategóriát, amire a teljes css állományunk ráhúzható. A cél szintén a rugalmasság, az átlátható, karbantartható, újrafelhasználható css szemlélet volt. Így jött létre a következő öt kategória:

  • Base: vagyis az alapdefiníciók, a css reset
  • Layout: az oldalon fellelhető sorok és oszlopok beállításai. Grid css.
  • Module: az oldalunk kis részegységei. Cikk lista, cikk részletes oldal, tartalmi dobozok.
  • State. Az állapotok, hogy néhányat megemlítsek: aktív, inaktív, kinyitott, becsukott.
  • Theme: az oldal azon stílusjegyei, amitől igazán egyedi lesz az oldalunk.

Az OOCSS és SMACSS kimondja, hogy kerüljük az ID-k használatát. Csak osztályokat használunk, és az egyes osztályok nincsenek egymásra levezetve. Ahogy azt az objektum orientált programozásban megszokhattuk egy osztályt sohasem butítunk, hanem bővítünk. Így törekedni kell arra, hogy a legegyszerűbb css osztályokat hozzuk létre, és ha szükséges akkor új osztályokkal bővítsük. Használjunk beszédes osztály neveket. Az egyes modulok neve namespace-ként jelöljék az almodulokat, állapotokat, témákat. Így az könnyen azonosítható lesz, és jól fog látszódni, hogy az egyes állapotok, témák valójában melyik modulunkhoz is tartozik.

/* az egyes osztályok nincsenek egymásra levezetve.
És ahogy az látható, a modulok nevei namespace-ként 
kisirék végig az osztályokat */
.box{...}
.box-pic{...}
.box-body{...}
.box-title{...}
.box-content{...}


/* rossz példa ha elveszünk */
.datasheet-title{
    padding: 0 0 5px;
    border-bottom: solid 1px #ccc;
}
.without-border{
    padding: 0;
    border: 0;
}

/* helyette bővítsünk */
.datasheet-title{...}
.with-border{
    padding: 0 0 5px;
    border-bottom: solid 1px #ccc;
}

!important

Ha már a !important használni kell, az sok jót nem jelent. Ilyenkor már bőven benne vagyunk a fejetlenségben. Használata mindenképpen arra utal, hogy kimaradt a tervezés. Egy jól átgondolt és megtervezett fejlesztésnél nincs nyomós ok a !important használatára. Ha az osztályaink minimál stílusban készülnek, nem lesz rá szükség.

Gondolkodj, tervezz, kódolj!

Előzetes tervezéssel sok gond le fog esni a válladról. A projekt elején szánjunk egy nagyobb időt arra, hogy szépen átgondoljuk, megtervezzük, hogy a megvalósítani kívánt oldalon milyen újrahasznosítható elemeink lesznek. Ha szükséges, folytassunk további egyeztetéseket a grafikussal, és hozzuk közös nevezőre a különféle stílusjegyeket. Nem kell teljes monotonitásra gondolni, de annyira mindenképpen hozzuk a designt azonos stílusra, hogy mindig következetesek maradjunk magunkhoz. Vagyis, hogy a kosár gomb mindenhol egyforma legyen, az egyes hibaüzenetek stílusa ne tévessze meg a felhasználót, és így tovább.

Ahol csak lehet, kis dobozok és modulok szintjén, kerüljük le azt, hogy width értéket adunk. Tudom, előfordul, hogy ez nem lehetséges, de a legtöbb esetben igen. Így elérhetjük azt, hogy az oldal egyes részelemei újrafelhasználhatóak legyenek, flexibilisek.

Az előadás prezentációját is elérhetővé tettem. E cikkben próbáltam átvenni a legfőbb gondolatokat, hogy még több értelmet vigyek a slide-okba, miközben azt lapozgatjátok.

Megnézem a prezentációt!

Címke: css, html5, frontend