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.

Vezi un demo la http://bitesizebugs.com/lab/jquery/tabtoggle/

Sursa la: http://github.com/oslego/tabToggle/tree/master

Problema

Exista zeci de plugin-uri de jQuery prin care se obtine comportamentul JS de tab navigation, insa majoritatea developerilor au fost prea zelosi. Desi urmaresc acelasi behavior plugin-urile pe care le-am studiat vin la pachet cu multe alte functionalitati gen efecte vizuale, ajax calls, actiuni multiple pentru acelasi click sau impun o conventie de naming de tipul: “#tab_1″ declanseaza “#tab_content_1″.

Aceste workflow-uri fie iti fac munca enervanta (naming conventions) fie inseamna fisiere inutil de greoaie (12+ kb). Toate astea cand vrei doar un meniu de tip navigation.

Ideea

Am avut nevoie de un plugin simplu de tab navigation asa ca mi l-am scris: jquery.tabToggle.js.

Cand folosesti tabToggle iti selectezi prin jQuery un set de elemente care actioneaza drept triggers (tab-urile) si le atribui un alt set de elemente care joaca rolul contiutului corespunzator fiecarui tab (targets).

Atat! Fara conventii de nume, fara obligatia de a lucra doar cu UL-uri sau alte forme de ingradire a strucurii. Singura conditie este ca numarul de triggers sa fie egal cu numarul de targets – un aspect logic, de bun simt :)

Vezi exemplul de cod de pe pagina de demo pentru detalii tehnice.

Pentru moment singurul behavior este de visibility toggle a targetului atunci cand faci click pe trigger-ul corespunzator. Am vrut ca tabToggle sa fie simplu si la obiect.

Pentru flexibilitate intentionez sa expun public in JavaScript metodele care se ocupa de managementul elementelor ca sa iti poti defini orice efect sau behavior iti doresti.

Nu vreau sa iti limitez creativitatea cu tabToggle. Vreau doar sa iti ofer functionalitatea de baza pentru un meniu de tip tab navigation. Nu intentionez sa extind tabToggle cu support pentru AJAX calls sau sa definesc animatii intre tranzitii. Exista deja plugin-uri care fac asta.

Il aveam scris de mai demult dar in cursul weekend-ului l-am curatat, l-am documentat, l-am testat si l-am dat comunitatii sub forma de cod open source. In versiunea minified codul are sub 1kb deci va lasa o urma foarte mica asupra bandwidth-ului consumat.

Git – version control

Cu ocazia asta am invatat sa folosesc si git – un sistem de version control. Am cont pe github si mi-a placut ca mi-a dat version control, wiki, si bug tracker, gratuit, in acelasi pachet.

Partea cea mai gustoasa la git este considerata usurinta in operatiunile de fork si merge ale repository-ului – o componenta cheie in proiectele la care lucreaza mai multe persoane.

Mai mult open source

Dupa ce l-am facut public am primit mai multe aprecieri din partea prietenilor. Asta m-a incurajat sa pregatesc pentru publicare si alte bucati de cod JavaScript sub forma de jQuery plugins.

Daca ai ceva de spus esti binevenit sa lasi un comentariu.
Daca observi functionalitate gresita te rog sa deschizi un issue pe github ca sa il pot investiga si/sau repara.

Licenta?

Codul e open source deci il poti folosi fara obligatii in orice proiect. Nu ma pricep la licente asa ca poti folosi acest plugin atat in proiecte personale cat si comerciale fara obligatii.

Intentionez sa public viitoare plugin-uri sub licente MIT si GPL, la fel ca licentele pentru jQuery.

Intrebare pentru cei mai priceputi juridic: exista o alternativa de licenta mai potrivita pentru acest tip de cod?

E adorabil pentru ca Apple va atinge acest numar (pe homepage) cand isi doreste, conform lui downloadcounter.js. Scriptul de JS nu face call-uri asincrone la server, nici macar ocazionale, ci ruleaza un algoritm simplu de incrementare. Singurul punct in care scriptul vorbeste cu serverul mama este la incarcarea paginii cand isi ia cea mai mare valoare atinsa dintr-un fisier text sincronizand data serverului cu cea a localelor de unde ruleaza counterul.

Apple ruleaza scriptul de incrementare pe baza unor predictii obtinute din deja aproape 1 miliard de downloads deci nu face mult rau. Totusi mi-ar fi placut sa vad din cand in cand un call de sincronizare cu numarul oficial de download-uri de la server – de dragul corectitudinii si calitatii cu care Apple isi obisnuieste audienta.

Daca lucrezi cu Prototype.js si ai nevoie de o idee pentru un algoritm de incrementare + counter sa te uiti in cel de la Apple. Daca poti citi cod JS obfuscat o sa il gasesti interesant :)

alert(“Angelo, repari tu asta sau stergi alert-ul ca sa manarim script-ul si sa ascundem eroarea. slider.js, Line 52.”)

E in codul de productie dar, sa fim cinstiti, e un alert comentat.
Distractiv!

Pe o nota relevanta performantei, acest mesaj dragut mananca inutil niste biti din fisier – ceea ce este gresit atunci cand rulezi un site care serveste poze si care trebuie sa fie cat se poate de rapid.

Daca nu ma plictisesc intre timp am sa revin cu un review despre aspectele legate de performanta lui picbox.ro nu despre cum a fost implementat.

Acest truc iti permite sa “furi” cateva milisecunde pretioase din timpul unui download.

Un truc poate fi aplicat cu success este sa te folosesti de onMouseOver pe controalele dintr-o galerie foto intr-un sistem de livrare prin AJAX.

Mi se pare o actiune logica sa incepi preload-ul in background a pozei determinate de un thumbnail cand ai o constructie de navigatie similara cu cea de la Flickr. Din punct de vedere al interfetei ai putine motive sa faci hover peste acele imagini daca nu doresti sa navighezi prin galerie.

Desigur, e o jonglerie de performanta. Daca lansezi prea multe download-uri bazate pe actiuni incomplete ale userului poti deteriora experienta, dar cred ca daca iti gandesti bine planul de preload iti poti face galeria sa para mai rapida (as in responsive) pentru ca te folosesti de milisecundele dintre onMouseDown() si onClick()-ul complet pentru a incarca in browser o parte din continut.

Foloseste onMouseDown cu responsabilitate!
Uneori imi dau seama ca fac un click din greseala si imi mut cursorul de pe link, apoi dau drumu butonului. Asta impiedica actiunea de click.

$.get("feeds.opml", function(data){
	var count = $(data).find('outline[type="rss"]').length;
	console.log(count);
});

In exemplu feeds.opml reprezinta fisierul tau cu feed-uri.
Poti exporta un opml cu feed-urile tale din Netbvibes din meniul “Your profile” > “Feeds”.

Mi se pare un plugin indispensabil celor care prezinta formulare care cer date / numere de telefon intr-un format inflexibil.

Acest plugin iti poate reduce numarul de useri frustrati care primesc o eroare dupa submitarea formularului pentru ca au uitat sa introduca o cratima intre prefix si numarul de telefon.

Niciodata nu ar trebui sa te bazezi pe datele prelucrate doar pe client pentru ca JavaScript-ul se poate dezactiva si cineva iti poate face ravagii pe server.

Si nu doar actiunea de throw a erorilor ci mai degraba mesajul util care sa te ajute sa identifici mult mai usor de unde vine problema.

Nicholas sustine ca ar trebui sa arunci erori in consola atunci cand metoda este susceptibila de a primi argumente neasteptate. Este impractic sa faci error checking si error throwing pe orice metoda, mai ales cand ai control asupra argumentelor pasate acesteia (vezi metode private in JS).

E un articol sanatos de citit si recomand sa urmezi sfaturile.

Recent am avut de implementat o componenta JS ceva mai complexa si din experienta stiu ca cei ce o vor implementa tind sa nu citeasca specificatiile. E ok, nici eu nu RTFM.

Este mult mai rezonabil sa arunci errori in consola browserului care descriu problema decat sa primesti email-uri si telefoane de la oameni confuzi care nu inteleg de ce nu le merge jucaria.

Implementarea poate sa fie intr-un proiect de sine statator sau intr-un demo, doar de dragul concursului. Nu exista limita la numarul de idei pe care le poti trimite.

Castigatorul primeste access gratis la SXSW Interactive 2009, mega eveniment pentru oameni creativi in domeniul IT.

Mi-as fi dorit o saptamana de joaca in compania lui jQuery UI dar timpul nu imi permite. Si la SXSW intentionez sa ajung odata in viata.

Castiga tu si trimite-mi niste poze de la SXSW!

L-am amanat in repetate randuri dar toata frustrarea din front-end trebuia sa rabufneasca la un moment dat.

Premisa
De-a lungul timpului m-am izbit de bug-uri ciudate in JavaScript, HTML, CSS, Ie6, Safari si peste tot am gasit cate ceva care nu merge asa cum scrie la carte.

Dupa ce am citit si m-am prins cum se rezolva m-am gandit ca ar fi util umanitatii daca as impartasi cate ceva din ce am inteles.

Ce o sa fie
Mi-am propus sa adun pe Bitesize Bugs toate ciudateniile in cod pe care le intalnesc in munca de zi cu zi intr-un format usor de digerat. Scurt, la obiect, cu exemple si referinte spre resurse utile.

Si pe mine ma oboseste sa citesc articole greoaie presarate cu fustrarile pline de subiectivism ale autorului cand am nevoie doar de o solutie.

E la inceput
De-abia am infiintat blogul si o sa imi ia o perioada pana cand il populez cu articole despre bug-urile pe care le-am documentat deja.

Momentan nu intentionez sa scriu despre bug-uri din afara tehnologiilor front-end pentru ca inca nu ma pricep la altceva.

Call to action
Daca vrei sa contribui si esti capabil sa sintetizezi solutia pentru un bug obscur in doar cateva randuri esti binevenit sa-mi arunci un mail la bitesizebugs [at] gmail [dots] com.

Nu intentionez sa scot profit din blogul Bitesize Bugs deci nu te pot plati pentru articole.