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:
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.
Am incercat sa ies cu prietenii la o bere alba nefiltrata in Bucuresti dar cum rezervarile in capitala se fac inca de pe la jumatatea saptamanii am sfarsit prin a ne aduna la iLL acasa.
Monopoly fara un zar
La om acasa ne-am pus sa jucam un Monopoly dar oroarea de pe lume a facut sa avem doar un zar fizic. Aici ne-a lovit problema existentiala:
facem inca un zar din miez de paine?
coboram si cumparam un zar de la o benzinarie?
dam cu zarul de doua ori?
Painea ar fi durat mult pana se intarea, nimeni nu avea chef sa coboare la vanatoare iar datul de 2 ori cu zarul nu ar fi fost practic.
Geeks unite!
Vlad a fost scanteia si s-a pus sa faca un script ce imita functionalitatea a doua zaruri in JavaScript pentru Monopoly, acolo la fata locului. Stiu ca iLL si Mimoza ne implorau sa cautam pe net un script de zaruri dar nu ar mai fi fost distractiv.
Vlad a scris primele linii, neoptimizat desigur + bug de random. Eu am intervenit, i-am fixat bug-ul, i-am wrap-uit codul duplicat intr-o singura metoda explicand ca se face mult mai usor debugging-ul asa (avea doar 3 linii), am bagat un total, putin markup HTML si am introdus un alt bug :)
Ne-am invartit in jurul cozii putin din caza bug-urilor, iar Vlad a fost revelatia: JS-ul il punem la capat ca sa nu mai facem event listener pe window.onload. Dracovenie!
Jamayk a intervenit si a dat personalitate paginii anoste cu niste CSS, iar eu am adaugat coltul norocos.
In incercarea de a pastra experienta zarurilor cat mai naturala, in loc sa sufli in zaruri am rezervat un colt de ecran unde poti scuipa pentru noroc. iLL nu ne-a lasat sa ii scuipam pe televizor.
Coltul norocos – televizorul e in continuare curat
Vlad a adus cireasa de pe tort si a programat “datul cu zarul” la click asa ca am folosit mouse-ul wireless pe post de trigger pentru zar pe care l-am plimbat apoi din mana in mana in jurul tablei de joc. iLL nu s-a sinchisit sa isi mute senzorul de la mouse intr-un loc mai vizibil asa ca am avut ocazia sa vedem multe acrobatii pentru a “da cu zarul”. In final a imitat efortul fizic al datului cu zarul.
Jamayk cu mouse-ul pentru zarul digial
Jocul a fost distractiv, iar Jamayk a fost un latifundiar pana la capat si ne-a lasat fara bani dupa ce am jucat 1/2 din joc dupa o regula care i-a permis sa ne usuce financiar.
Sa il ingropam in bani pe Jamayk
Demo zaruri pentru Monopoly
Rezultatul se alfa hostat la iLL si puteti apela cu incredere la radomness-ul zarului.
Scriptul arata totalul celor 2 zaruri si daca s-a dat dubla (valorile zarurilor aruncate sunt identice).
Nu este cel mai bun/optim/curat cod pe care l-am putea scrie dar ne-a rezolvat problema si a fost interesant sa ne vedem lucrand impreuna la acelasi lucru.
Da, a fost si foarte fun! Uite un slideshow cu niste poze de la Monopoly la iLL:
Urmeaza sa construim si o versiune masluita pentru a ne face putred de bogati de pe urma celor care vor rezultate preferentiale.
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