In ultima vreme am acordat o atentie deosebita pentru CSS Image Sprites incercand sa gasesc solutia optima pentru proiectul la care lucrez. Pe drum am descoperit niste resurse interesante:
- Am gasit pe blogul Mozilla Webdev un articol foarte bun referitor la pozitia si logica aranjarii imaginilor intr-un sprite – foarte informativ, il recomand.
- In libraria imagemagick exista functia montage care permite imbinarea automatizata de surse intr-o singura imagine; are multe moduri de customizare si o gasesc foarte utila atunci cand lucrezi cu multe spre foarte multe imagini de acelasi dimensiuni (icons) iar sprite-ul evolueaza des prin adaugarea sau eliminarea de imagini.
- Google e foarte nazist in materie de CSS Image Sprites in sensul ca optimizeaza la maxim spatiul utilizat dar foloseste niste metode “nu-prea-web-standards” pentru a afisa continutul imaginii: elemente <span> in scop decorativ, goale, fara continut:
<span class="csb ch" style="background-position:-76px 0;
margin-right:34px;width:66px"></span>
Folosind aceasta metoda developer-ul nu isi mai face griji pentru imagini care apar din greseala ca background din cauza supradimensionarii elementului caruia ii este atasat sprite-ul. Asta se intampla fiindca are control fin asupra dimensiunilor acelui <span> decorativ.
<flame> Nu sunt neaparat impotriva acestei metode dar cred ca trebuie sa echilibrezi performanta si usurinta in mentenanta a template-ului cu izbucnirile iubitorilor inflacarati ai standardelor web care vor spune ca trebuie sa scrii markup semantic, iar un span gol, cu scop pur decorativ, este o incalcare flagranta a tot ceea ce este sfant si pur in HTML. </flame>
Stiai ca atunci cand deschizi un iFrame pe pagina dependintele acesteia (CSS, JS, imagini) intarzie declansarea evenimentului de onload() pe window si ca se calculeaza din liniile paralele de download de resurse (connection pool) ale paginii gazda? (2 simultane in IE6, 6 simultane in Firefox 3)
Eu nu stiam asta, dar am aflat dintr-un articol de pe blogul lui Steve Souders.
Articolul e un fragment dintr-un capitol al cartii Even Faster Web Sites care va fi publicata in cursul acestei veri. Daca esti preocupat de performanta site-urilor pe care le construiesti aceasta carte e o resursa foarte buna pentru tine. Intre timp poti consulta editia mai veche, dar foarte informativa, High Performance Web Sites.
Suna profan in lumea CSS dar Nicole Sullivan propune ceva foarte sanatos: sa iei conceptele din programarea orientata pe obiecte si sa le aplici in dezvoltarea fisierelor tale de CSS.
In termeni simpli propunerea consta in a-ti scrie module generice pe care le vei reutiliza in paginile tale. Aceste module generice se vor extinde prin adaugarea mai multor clase.
Necesitatea OOCSS o vei simti atunci cand lucrezi la site-uri de talie mare cu multe pagini. Desi un site simplu poate beneficia de principiile OOCSS, atunci cand ai de intretinut zeci, sute de pagini suna mult mai rational sa iti standardizezi CSS-ul.
Prin standardizare nu ma refer la validare ci la construirea de elemente cu aspect general similar peste tot in paginile site-ului tau. In principiu nu ar trebui sa scrii CSS suplimentar pentru fiecare modul nou pe care il adaugi decat daca acesta este radical diferit de ceea ce ai deja la dispozitie.
In general developerii de front-end nu au incredere si prefera sa nu foloseasca din codul scris de ceilalti inaintea lor.
Nicole propune un framework (4kb !) construit pentru a ilustra principiile OOCSS pe care le sustine in aceasta prezentare:
Poti sa iti iei framework-ul OOCSS de pe github
Nicole Sullivan este un Perfomance Engineer de la Yahoo! care se ocupa si de tool-urile de la Exceptional Performance
