Modeliranje CSS-a kao softverski inžinjer

Korisnici često shvataju CSS kao nešto trivijalno i vrlo lagano, sto jeste istina na nekom nivou. Ali pravljenje velike, skalabilne aplikacije nije isto.

Uporediću ulogu developera koji pravi CSS i  softverskog inženjera koji pravi softver. Vrlo suludo zvuči ali postoji dosta sličnosti.

Objedinjeni jezik za modelovanje

UML (Unified Modeling Language) - objedinjeni vizuelni jezik za
poslovno i softversko modelovanje u svim fazama razvoja i za sve
tipove sistema, kao i za generalno modelovanje kojim se definišu
statičke strukture i dinamičko ponašanje.

Oni koji nisu upoznati sa terminom, ovo je osnovni korak svakog softverskog inženjera, vizuelno prikazivanje objektnog modela. Na žalost veb developeri ne potpadaju u kategoriju softverskih inženjera, tako da oni ne mogu da koriste ovaj UML dijagram? Pa nije baš tako.

Ono gde se softver i veb spajaju

Ono što je zajedničko za softver i sajt jeste da je potrebno planiranje. Zvuči smešno? Ovo zvuči smešno u oba sveta ako se radi o malim, ne skalabilnim aplikacijama.

Smešno bi bilo crtati UML dijagram za kalkulator koji sabira brojeve, više vremena bi se utrošilo u crtanje no u programiranje samog kalkulatora. To isto važi i za veb, neće niko da planira sajt koji ima 3-4 vrlo proste stranice i to je to.

Zašto planirati CSS

Ceo ovaj članak zvuči suludo ali kada otkucate 20 000 linija u jednom CSS fajlu, shvatićete da ste se i sami izgubili u svom kodu.

Ono što smo sigurno bar jednom uradili je slepo kopiranje. To izgleda nekako ovako:

Floatovi nemaju visinu? Aha, odemo do google-a, potražimo rešenje.
Našli smo rešenje clearfix, iskopiramo kod u sred koda.
Par meseci kasnije desi se isto, zaboravimo klasu clearfix, napravimo novo rešenje za floatove, sad u klasi cf.

Upravo smo napravili dupli kod, koji je odmah teži za održavanje. Videćemo kako da rešimo te probleme.

Dizajn je vrlo bitan

Lepo je kad neko ima inspiraciju odmah uskoči u HTML i CSS i počne da radi bez dizajna. Dizajn treba gledati kao pod-UML dijagram.

Dizajn kao pod-dijagram

UML dijagram treba konstruisati iz dizajna. Gde su jedinstveni stilovi, objekti (komponente), a polja objekta njeni pod elementi.

Evo jednog primera koji se često javlja, "avatar box".

Grupisanje komponenti

Kao što vidimo gore imamo tri različite komponente, ustvari, ove tri komponente su iste i možemo da ih obuhvatimo jednom klasom.

UML dijagram avatar komponente

Klase će se zvati .avatar-box, kao podelemente saržaće sliku, naslov i opis. Slika je sa leve strane, naslov i opis sa desne, to je normalan izgled.
U slučaju da želimo okrugli avatar, u imenu klase dodamo modifikator --okrugla. Klase sada izgledaju ovako .avatar-box .avatar-box--okrugla gde će u CSS-u .avatar__slika imati border-radius: 50%.

Isti taj princip primenimo za dobijanje trećeg primera, dodamo modifikator --blok. Klase sada izgledaju ovako .avatar-box .avatar-box--blok gde će u CSS-u .avatar__slika imati display: block i tekst će biti centriran.

Pokazali smo da dobro planiranje može da nam uštedi vreme i prostor.

Zaključak

Naučili smo da tri vizuelno različita ali strukturno slična elementa možemo spojiti u jedan i tako izbeći pisanje više klasa.
Šta više, za primer iznad mogli smo dodati modifikatore za veličinu tako da imamo avatar sa velikom, malom i srednjom slikom.

Moja preporuka je kada imate dizajn da dobro sagledate koje su to komponente i na koji ćete ih način struktuirati, ako su strukture slične, verovatno ih možete obuhvatiti jednom klasom.