Älä keitä CSS -spagettia

CSS:n osuus sivustojen kehityksessä ja ylläpidossa jää monesti vähälle huomiolle, vaikka kuitenkin CSS määrittää miltä sivustosi näyttää vierailijalle. Vaikkei tyylien kirjoittaminen olekaan sitä kuuluisaa rakettikirugiaa, niin aiheeseen liittyviä sudenkuoppia on silti syytä välttää.

Useimmissa organisaatioissa on jo hyvä tovi sitten muodostuneet toimivat, yhteisesti sovitut käytännöt mitä tulee backend -ohjelmoinnin osalle. Koodarit kirjoittavat ulkoisesti samannäköistä koodia, best practices -käytännöt toimivat ja frameworkit ohjaavat tietynlaiseen yhdenmukaiseen toteutustapaan.

Frontendin puolella tilanne taas voi olla täysin päinvastainen. CSS on tekijänsä näköistä, sinänsä toimivaa, mutta mahdollisesti hyvinkin vapaamuotoisesti sävellettyä tyylinäytettä. Ja kun tekijä vaihtuu, jatkokehitystä ostetaan ulkopuolelta, ulkoa ostettua tehdään omin voimin tai tiimi kasvaa niin ongelmat nousevat esiin.

En kerro tässä kirjoituksessa miten fronttikehitys tulisi organisoida prikulleen. Esitän muutamia yksinkertaisia ajatuksia joiden avulla voidaan kehittää työtapoja siihen suuntaan, että ylläpito, jatkokehitys ja visuaaliset täysremontit on helpompi vetää läpi ilman, että koko aiempi toteutus pitää pistää ns. shaibeksi. Ja vaikka et tekisikään suurempia toimenpiteitä, niin suoriudut nopeammin myös pienistä fikseistä.

SASS

Fronttikehittäjien työkalupakkiin kuuluva SASS lisäosineen on erinomainen työkalu, jonka hallinnasta kaikki lähtee liikkeelle. Jos SASS ei ole vielä tuttu, niin http://sass-lang.com/guide auttaa alkuun nopeasti. SASSin käytössä piilee kuitenkin muutama sudenkuoppa, joita kannattaa välttää. Seuraavat pari huomiota tulevat nopeasti vastaan SASSin parissa puuhaillessa, joten jos asia on tuttua niin ota tämä alustuksena kirjoituksen myöhempiä kappaleita silmälläpitäen.

Ensimmäinen sääntö, älä sisennä liikaa selektoreita. Mitä pidempi selektori-polku, sitä spesifisempää määrittelyistäsi tulee ja johtaa siihen, että päädyt kirjoittamaan ylikirjoittavia sääntöjä enemmän ja samalla kasvatat koodipohjaa. Esimerkiksi nav ul li a{ color:#fff; } on aivan liian spesifinen määrittely, kun taas nav a {color:#fff} on sopivan geneerinen. Tässä esimerkkitapauksessa hyötynäkökulma ei välttämättä tule täysin selväksi, mutta älä huoli palaan aiheeseen myöhemmin tässä kirjoituksessa.

Toinen ansa, johon SASSin kanssa kompastuu helposti on tyylien laajentaminen @extend -määreellä. Extendin yltiöpäinen käyttäminen johtaa melkoisen lihavaan lopputulokseen, jos tapanasi on määrittää elementin perusolemus ensin ja laajentaa tätä tyyliä elementin erityistapauksiin. Jos et usko, niin tsekkaappa CSS-koodisi ja katso millaista koodia laajennetut määrittelyt sisältävät. Parempi tapa on käyttää placeholder -määritystä, jolloin vain laajennettu tyyli generoituu, mutta placeholder ei. Tämä tekniikka toimii hienosti, mutta tässäkin kannattaa vielä käyttää malttia ja miettiä onko lopputulos tarpeeksi geneerinen ja helposti muokattava, jos puolen vuoden päästä halutaan tehdä rajuja muutoksia ulkoasuun.

KEEP IT SIMPLE

Edellisessä kappaleessa esitin pari triviaalia huomiota, joiden avulla pidät generoituvan CSS:n kevyempänä. Perusasioita, mutta olen nähnyt työssäni laajojen, mutta verrattain yksinkertaisten sivustojen perustuvan 10.000 riviseen CSS:ään. Lisäksi olen myös itse sortunut lähes vastaavaan huomatakseni kuinka tärkeää on muistaa, että yksinkertainen on aina parempaa.

Backend -ohjelmoijat pyrkivät pitämään metodit yksinkertaisina. Metodilla on yksi tehtävä ja saman toiminnon uudellenkäyttäminen eri kontekstissa tekee täsmälleen saman asian. Sivustosi CSS:n pitäisi pyrkiä samaan.

Yksinkertaistamalla CSS:äsi single responsibility ajatusmalliin pääset kertaheitolla lähemmäs kirjoituksen alussa antamaani lupausta ylläpidon, jatkokehityksen ja täysremonttien helpommaksi tekemistä.

Kärjistetty esimerkki aiheesta:


<input type="submit" class="submit-button" />

<input type="reset" class="reset-button" />

.submit-button{
   display: block;
   width: 150px;
   padding: 5px;
   background-color: #fff;
   color: #000;
}

.reset-button{
   display: block;
   width: 150px; 
   padding: 5px;
   background-color: #000;
   color: #fff;
}

Ylläoleva naiivi esimerkki korjataan näin.


<input type="submit" class="button submit" />

<input type="reset" class="button reset" />

.button{
   display: block;
   width: 150px;
   padding: 5px;
}

.submit{
   background-color: #fff;
   color: #000;
}

.reset{
   background-color: #000;
   color: #fff;
}

Tällä w3schools -tasoisella esimerkillä pyrin havainnollistamaan keskeistä, mutta yksinkertaista ajatusta single responsibilityn ja OOCSS:n takana.

Jos olet oppinut pitämään HTML:n siistinä CSS-luokista, niin haluan hieman haastaa sinua. Selaimet osaavat toimia hyvin CSS-luokkien kanssa, ihmiset osaavat lukea templateja paremmin kun class -määreet kuvaavat ulkoasun paremmin, sekä lisäksi CSS:si hajoaa huomattavasti harvemmin, kun ulkoasu perustuu luokkaan, ei elementtiin tai sen sijaintiin.

Huomaa, että voit edelleenkin määrittää elementeille perustyylin ilman luokkamäärettä, ja suosittelenkin sitä ehdottomasti. Jos tietty elementti on 90% käyttökerroista saman näköinen, ei ole syytä edellyttää "perusluokan" mukana oloa.

 

MITÄ OPIMME

  • Älä mallinna HTML-rakennetta CSS:ssä. Rikot sillä tyylien uudellenkäytettävyyden
  • Pidä CSS kevyenä, hyödyt siitä eniten itse jatkossa
  • Kun kirjoitat CSS-luokkaa, mieti onko nimi kuvaava, mutta geneerinen ja sisältö uudellenkäytettävissä

LISÄÄ AIHEESTA

http://csswizardry.com/2012/04/the-single-responsibility-principle-applied-to-css/

http://8gramgorilla.com/mastering-sass-extends-and-placeholders/

Kirjoittaja: Veli-Matti Viippola