Problema
Aveam nevoie de o metoda prin care sa carpesc pentru IE6 si alte browsere incapabile de a folosi un atribut CSS.
Solutia
Pentru ca “browser sniffing” e o metoda gresita de a aborda astfel de probleme, mi-am scris o mica functie in JavaScript care detecteaza capabilitatile CSS ale unui browser. Functia returneaza true daca proprietatea este implementata de browser si false in caz contrar.
Mod de utilizare
browser.hasCssProperty("max-height")
Implementare
Metoda e simpla: orice propietate CSS are un corespondent in DOM via style. Ca sa verifici daca browserul implementeaza o proprietate CSS e suficient sa intrebi un element DOM daca style-ul sau accepta acea proprietate.
Diferenta in DOM este ca numele compuse ale proprietatilor sunt camel case (maxHeight) in timp ce in CSS ele sunt separate prin cratima (max-height). Pentru asta a trebuit sa fac o conversie din dash-separated in camelCase.
E important de stiut ca proprietatile pot avea nume compuse din mai mult de doua elemente, de exemplu border-bottom-style. CSS3 aduce multe astfel de nume compuse, chiar cu patru elemente.
Codul e pe github si poate fi imbunatatit. Intentia e sa abstractizez si mai mult implementarea ca sa fac atat object detection cat si css property detection.
Stiu ca acum nu refolosesc elementul de test.
Ar trebui sa fac un singleton.
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>
Denumirea claselor sau id-urilor in CSS dupa proprietatile elementului este improprie. Exemple de denumire gresita sunt:
#rounded-menu sau .blueLink
Argumentul cel mai comun adus impotriva acestor denumiri este ca face dificila mentenanta codului in sensul ca proprietatile elementelor se vor schimba in timp ce numele de clasa / id raman aceleasi. Pe termen lung denumirile de acest gen isi pierd relevanta si fac debugging-ul dificil.
Un aspect care mi se pare des pierdut din vedere este ca aceste denumiri impiedica reutilizarea usoara a codului.
De multe ori te vezi construind componente similare in structura: meniuri liniare, box-uri de search, butoane proeminente.
Daca meniul tau se cheama #rounded-menu sau #top-menu implementarea sa intr-un alt site necesita niste renaming pentru a-i da ceva relevanta daca proprietatile nu raman similare.
OOCSS este un concept foarte bun in care iti construiesti componente generice pe care le poti extinde apoi in site-urile in care le implmenetezi.
.pipe-menu sau .tab-menu mi se par mai usor de reutilizat.
.box, .box-header, .box-footer, si .box-content pot fi niste componente foarte utile pe termen lung.
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
