TABLE vs DIV

Ca sa lamurim de la (destul de) inceput de ce ma tot agit atata cu DIV-urile, si nu folosesc in schimb TABLE: este vorba de modul de incarcare a paginii, in primul rand.

Un TABLE este compus in TR-uri, compuse la randul lor din TD/TH-uri. Problema este ca IE nu poate afisa un TABLE pana cand nu a terminat de incarcat TOT continutul lui. Cu alte cuvinte, daca graffiti de pilda ar fi facut tot dintr-un singur TABLE, atunci ai sta si te-ai uita la o pagina goala, cum se tot incarca fara sa afiseze nimic, si abia la sfarsitul incarcarii s-ar afisa totul, brusc. Acum, sa fim seriosi, graffiti poate nu e cel mai bun exemplu… Du-te pe engadget.com de pilda, si vezi acolo batalie cu bandwidth-ul… Daca un site ca ala ar fi facut cu tabele, ar fi JALE.

In timp baietii de la M$ s-au gandit sa mai rezolve un pic din problema, permitand, in anumite conditii, ca afisarea sa se faca rand-cu-rand… dar tot cam degeaba – fiecare rand trebuie sa isi incarce intreg continutul inainte de a fi afisat. Crappy. Real crappy.

DIV-urile in schimb, ca sa poata fi afisate, nu au nevoie de CONTINUT, ci doar de STRUCTURA.

Asta, plus eleganta CSS-ului, ma fac un fan declarat al DIV-urilor, sau, ma rog, al modalitatilor alternative de a “taia” un layout.

DIV-uri centrate in pagina: atentie la MARGIN

Pana sa ma lamuresc de niste lucruri, am tras de google de-am ametit… De ce? Pentru ca vroiam si eu, ca tot omul, sa centrez un DIV in pagina. IE, asa simplu la minte cum e el, ma asculta orbeste… Dar FF, cu pretentiile lui puriste, nu vroia neam! Asta pana am aflat de ce.

Browserele mai normale la cap (FF included) nu iau lucrurile “de bune”. Nu gandesc prieteneste, ci matematic. Ca sa pozitionezi un element in termeni relativi, browserul trebuie sa stie exact care sunt parametrii necesari calculului acelei pozitii relative. Cum, in cazul asta, vorbim de pozitionare pe orizontala, browserul are nevoie sa stie care sunt MARGIN la stanga si la dreapta. Cu alte cuvinte, daca vreau un DIV centrat pe mijlocul paginii, e musai sa-i dau

margin-left: auto;
margin-right: auto;

Fara setarile astea, FF o sa se incapataneze sa pozitioneze orice DIV (care nu are float) la marginea din stanga a holderului (parintelui etc.) sau, indiferent de text-align-ul acelui holder.

Astea fiind zise, am cam rezolvat problema! Prea simplu? Nu conteaza, sper doar sa-ti foloseasca.

PNG cu transparenta in IE5+ si FF

Pentru cine a folosit GIF-uri si stie cat de pacatoasa e transparenta lor pe la margini, PNG-ul, cu nivelele lui de transparenta atat de dragalashe, e mana cereasca. Numai ca IE (inclusiv v.7) (ca de obicei) e atat de inapoiat incat nu poate afisa zonele transparente din PNG-uri ca transparente, ci ca un background gri, suparator. Daca chiar vrei sa obtii PNG cu transparenta in IE, trebuie musai sa bagi un filtru (filtrul = o alta inventie abominabila M$) dedicat trebii asteia, filtru care nu face decat sa afiseze, ca background, imaginea PNG setata, dupa exemplul:

filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true, sizingMethod=scale, src=img/png-file.png);

Solutia cea mai folosita de catre trupetzi in general e sa implementezi un javascript care, odata incarcata pagina, sa “caute” prin toata structura HTML dupa imagini de tip PNG si sa le inlocuiasca, cu un replace global, cu holdere in care sa introduca filtrul respectiv, preluand, evident, de la imaginile originale toti parametrii necesari afisarii corecte (latime, inaltime, url imagine). Cum solutia asta este una care tine de javascript, si cum presupune operatii asupra structurii documentului, o las aici, si continui cu ce ma intereseaza pe mine aici: aspectul CSS al problemei.

De ce CSS? Poi e cam simplu… pentru ca de multe ori ai nevoie sa folosesti acel PNG in CSS, ca background-image… caz in care solutia de mai sus devine complet ineficienta.

Pentru cine nu a cetit inca articolul !important; , recomand inainte de a continua, lectura lui.

In mod normal, in CSS, definim o imagine ca background in felul urmator:


.style {
background-image: url(
img/png-file.png);
}

, treabã care merge bine in FF dar nu merge deloc in IE.
In IE in schimb, dupa cum ziceam, poti face asa:


.style {
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true, sizingMethod=scale, src=img/png-file.png);
}

Dupa cum vezi, rezulta doua proprietati diferite, care incearca sa obtina acelasi lucru. Daca ai cetit deja articolul recomandat mai sus, atunci o sa intelegi de ce solutia la problema noastra e sa aplicam un dublu !important; , in felul urmator:

.style {

background-image: url(img/png-file.png) !important;

background-image: none;

filter: none !important;

filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true, sizingMethod=scale, src=img/png-file.png);

}

In felul asta, FF o sa “vada” un background si zero filtre, iar IE o sa “vada” zero background si un filtru. Problema rezolvata. Atat pentru azi…

max-height in IE5+

Exista tot felul de proprietati si functionalitati CSS si nu numai, extrem de utile uneori, frumos implementate in FF dar deloc sau prost implementate in batranul (a se citi “decrepitul”) IE:

PNG-uri cu transparenta, transparente pur si simplu, scriere pe mai multe coloane, latimi si inaltimi minime si maxime etc.

Azi ma opresc la cele din urma, latimile si inaltimile maxime / minime.

In FF exista, foarte simplu, proprietati CSS pentru asta: max-width, min-height etc. In IE? uhhhh… nada.

Mare (?) noroc ca, de la IE 5.0 in sus, a fost implementata o chestie noua: suportul pentru expresii in CSS. Evident, nici un alt browser nu le “intelege”, si nici macar nu sunt un standard universal, asa ca expresiile astea dragute nu trec de validarile clasice. Dar, pentru cine e dispus sa renunte la validari, iata cum pot obtine un max-height de pilda, functional si in IE si in FF:

.class {
overflow:auto;
max-height: 100px;
*height:expression((this.scrollHeight > 75) ? “100px” : “auto” );
}

Observi ca am definit intai max-height in asa fel incat sa-l inteleaga FF-ul, dupa care am folosit un hack-ul cu “*” (un browser senil ca IE trece peste steluta aia, nu se incurca in ea, chiar daca ar putea fi o potentiala eroare… un browser sanatos la cap ignora complet acea definitie. In felul asta, se pot face uneori distinctii in definirea unor proprietati, de la browser la browser).

Restul se cam explica de la sine… E o expresie conditionala clasica de la care poti extrapola, daca vrei sa o adaptezi nevoilor tale.

Nota: nu recomand folosirea expresiilor. Doar IE le “vede”, restul browserelor nu. Dar, cum ATATA lume se plange de min-width si de altele asemenea lui, m-am gandit sa-i ajut un pic cu acest mic hack.

!important;

Pentru cei care nu stiu inca, exista un mic “hack” CSS care, folosit corect, nu numai ca trece de validarile clasice, dar e si foarte util. E vorba de !important;.

Cum se foloseste: in loc de width: 300px; se poate scrie width: 300px !important;. De ce si la ce foloseste? Vedem mai jos…

Functia de baza a lui !important; este de a prioritiza/ierarhiza proprietatile CSS atasate unei pagini (fie ca sunt inline sau raspandite in fisiere css externe). Din perspectiva asta, el poate fi folosit in 2 scopuri principale:

1. Primul scop, mai cunoscut si raspandit, este de a diferentia anumite proprietati in FF fatza de IE. In cazul asta, hackul se bazeaza pe faptul ca, acolo unde gaseste aceeasi proprietate de 2 ori, IE tinde sa prefere/sa ia un calcul proprietatea care nu are !important; atasat la sfarsitul ei.

Exemplu:
Sa spunem ca vrem ca un element sa aiba in IE width: 100px; iar in FF 120px; Cum facem? Simplu: scriem aceeasi proprietate de 2 ori: width: 120px !important; width: 100px;. FF va intelege din asta 120px, iar IE va intelege 100px. Simplu, la obiect si foarte util in multe cazuri.

2. Al doilea, mai putin cunoscut dar la fel de important, este de a prioritiza o proprietate pe scara ierarhica. Ce inseamna asta?

A. Stim (sau aflam) ca in CSS se pot defini Clase sau Tag-uri. Clasele sunt cazuri particulare si se prefixeaza cu un punct, iar tag-urile sunt practic redefiniri globale ale modului de afisare a tagurilor HTML. body {} redefineste un TAG, iar .body {} este o CLASA.

Ce retinem de aici e ca proprietatile unul TAG sunt superioare ierarhic proprietatilor unei clase. Daca de pilda definesc p {color: #cccccc;} si apoi in cadrul unui P vreau sa folosesc clasa .green {color: #009900;}, .green va apare gri in loc de verde, pentru ca un tag e mai general/global decat o clasa, adica P este mai general/global decat .green.

B.
Mai stim (sau aflam) ca in CSS putem defini clase complexe. De pilda, .green {} e una, .green .title {} inseamna “toate title-urile care se gasesc intr-un green“. Asta ne poate ajuta sa ierarhizam, sa detaliem si sa prioritizam foarte bine si ordonat o multitudine de clase si de cazuri particulare.

Ca sa revenim la oile noastre: concluzia din paragrafele A si B e ca in CSS ierarhia exista si e importanta.
Dar ce faci cand vrei sa faci override la ierarhie? Bagi un !important;.

Problema de mai devreme, cea cu p si .green, se rezolva asa: .green {color: #009900 !important;}. In felul asta, daca folosim un .green intr-un p, proprietatea color din .green va deveni mai importanta ierarhic si se va afisa ca atare.

Elemente pozitionate ABSOLUTE in context RELATIVE

Uneori, ca si in cazul butoanelor bogate grafic dar editabile ca text, e nevoie sa poti folosi un element html pozitionat ABSOLUT intr-un context RELATIV.
Este vorba despre proprietatea CSS “position” care poate lua una din cele 4 valori: absolute / relative / fixed / static. O sa las aici deoparte valorile fixed si static, si-o sa ma concentrez un pic asupra celor care ne intereseaza aici: relative si absolute.

tutorial-2.gifIn imaginea din stanga, pe care o folosesc ca exemplu, chenarul albastru resprezinta elementul parinte (contextul), chenarul rosu este un element pozitionat absolut, iar cel verde este un element pozitionat relativ. Elementele rosu si verde sunt incluse, evident, in cel albastru, ca si cod.

Relative – folosind proprietatea CSS position: relative; instruim browserul sa pozitioneze elementul in cauza relativ la contextul in care se afla acesta, in mod fluid. Cu alte cuvinte, fortam elementul relativ sa depinda, ca pozitionare, de tag-ul imediat superior lui DAR SI de curgerea in-line a elementelor din respectivul context. Cu alte cuvinte, sa se comporte, in termeni grosieri, ca o litera intr-un text.
Absolute – folosind proprietatea CSS position: absolute; instruim browserul sa pozitioneze elementul in cauza relativ la contextul in care se afla acesta, dar independent de curgerea in-line a celorlalte elemente din context. Cu alte cuvinte, fortam elementul relativ sa isi mentina coordonate de pozitionare fixe, exprimate in pixeli sau directii.

Cel putin in teorie.

Pentru ca, atunci cand incerci sa faci asta in practica, observi ca IE si FF o iau razna cand folosesti position:absolute, fiecare interpretand diferit LA CINE se face raportarea in pozitionare. Si acelasi element pozitionat absolut va fi afisat complet diferit in diferitele browsere.

DE CE? Pentru ca diferite browsere decid diferit daca raportarea se face la elementul html imediat superior ierarhic (parent tag) sau la BODY.

Pare absurd, stiu. Dar totul are o explicatie. Atunci cand trebuie sa pozitioneze un element ABSOLUTE, toate browserele “cauta” in sus, ierarhic, urmatorul element HTML definit ca RELATIVE. Unele considera ca acesta e parent-ul, altele ca acesta ar fi body. De aici si diferenta de prelucrare vizuala.

Rezolvarea? 🙂 e simpla: Chiar daca pare redundant, atunci cand vrei sa-l pozitionezi pe X absolut in Y, atunci defineste-l pe Y ca avand position: relative;.

Asta va forta orice browser sa inteleaga EXPLICIT la cine se face raportarea (urmatorul element superior ierarhic care este relative fiind in mod explicit definit), si sa rezolve vizual problema la fel, indiferent daca vorbim de FF, IE sau orice alt program contemporan.

Butoane bogate grafic dar editabile ca text

De multe ori se poate intampla sa ai nevoie de un buton mai bogat grafic (sa tipe Photoshopu’ din el) dar nu vrei ca la fiecare cerere a clientului sa trebuiasca sa refaci GIF-ul sau JPG-ul respectiv.

Presupunand ca fontul este unul din seria celor folosibile pe web, treaba asta e rezolvabila. Cum?

tutorial-1.gif Folosind doua tag-uri atunci cand definim elementul respectiv, fiecare cu cate un background definit din CSS pe el.

De ce doua? Pentru ca unul sa se ocupe de 2 laturi, iar celalalt de celelalte 2 laturi ale formei (in general dreptunghice) a butonului nostru.

In exemplul dat de mine aici, A-ul ar avea ca background prima imagine, mai lunga (just in case, cine stie cat text o sa fie nevoie sa intre acolo), iar LI-ul ar avea ca background a doua imagine, fiecare cu alinierile date in exemplu.

Mai ai de setat doar niste padding-uri si niste margin-i, si esti gata!

Spor! (si astept comentarii / sugestii / intrebari)

Later edit:
In urma unui comentariu foarte pertinent, Vlad a observat ca abordand asa exemplul asta, partea din dreapta a butonului ramane descoperita, “fara focus”. Asa e.
Rezolvarea vine dintr-o simpla schimbare de background-uri in css: li-ul sa primeasca ca background prima imagine, aliniata left-top, iar A-ul pe a doua, aliniata right-top. In felul asta butonul nostru devine complet acoperit de focus.

< a > vs < li >

M-a intrebat Andrei de ce lumea prefera sa foloseasca < li > – uri in loc de < a > – uri cand are de construit cate-un meniu CSS.

La intrebarea lui Andrei raspunsurile mele ar fi cam doua:

1. Pentru Google. LI = list item… adica niste A-uri in LI-uri intr-un UL il “fac” pe Google sa priceapa ca exista anumite relatii intre A-urile alea – lucru bun pentru relevantza.

2. Pentru ca deobicei pentru a defini un buton mai bogat grafic dar editabil ca text ai nevoie de cel putin 2 tag-uri unul in altul… or, cand folosesti un < A > intr-un < LI >, obtii exact asta, fara sa mai scrii
< div class= “menu” > < div class = “item” > < a href=”#” > menuitem < /a > < / div > < / div>

Impusti asa doi iepuri dintr-un foc: obtii cod mai STRUCTURAT si mai CURAT.

Iar pentru puristii care sunt atenti la orice bit optimizabil, LI e un cuvant mai scurt decat DIV, iar definirea clasei unui UL face ca definirea stilurilor elementelor din el sa devina redundanta in cod – deci o noua economie.

Exemplificare:

< div class = "menu" >
  < div class = "item" > < a href="#" >menu item 1< / a > < / div >
  < div class = "item" > < a href="#" >menu item 2< / a > < / div >
  < div class = "item" > < a href="#" >menu item 3< / a > < / div >
< / div>

vs

< ul class = "menu" >
  < li >< a href="#" >menu item 1< / a >< / li >
  < li >< a href="#" >menu item 2< / a >< / li >
  < li >< a href="#" >menu item 3< / a >< / li >
< / ul>

CSS – Introducere

(Pentru cine se bate deja pe burta cu CSS-ul, acest prim articol este bun de sarit. Nu zic nimic nou aici. Fac doar o mica introducere pentru cei care inca nu au avut onoarea de-a se bate pe burta cu dansul.)

De ceva ani buni web-ul s-a mai imbogatit cu o bijuterie de tehnologie: CSS (Cascading Style Sheets).
Pe Romaneste, CSS-ul este varianta pentru Web a Stilurilor pre-definite din batranul Word (chestiile alea ciudate pe care nu le-ai folosit niciodata: Normal, Paragraph, Heading etc.). Totally useless in Word.

De ce e bun CSS-ul pe web, atunci? Pentru ca toti parametrii de design ai unui site pot fi scrisi intr-un fisier CSS extern, incarcabil apoi din cache-ul browserului. Iar mai apoi, modificand un parametru in acel fisier css extern, modificarea se propaga in tot site-ul. Folosit corect, te ajuta sa eviti sa mai modifici un site pagina cu pagina, atunci cand clientul vine cu idei de genul “vreau si eu fontul un pic mai mic, daca se poate”.

Daca suna prea frumos ca sa fie adevarat, atunci asa si e. Ce e rau la CSS? Rau e ca fiecare browser s-a dus la alta scoala, fiecare “citeste” aceleasi reguli CSS in mod diferit. Daca nu esti atent, te poti foarte usor trezi cu un site splendid intr-un browser si varza cu carne in altul.

De-asta o sa incerc sa deschid aici o serie de mici articole / tutoriale / tips-tricks care sa te ajute sa intelegi mai bine si sa te descurci mai usor prin hatisul de reguli exceptii si hackuri CSS. Stay tuned!

Apropo de Web 2.0

– web2.0
– branding
– corporate
– wow-design
– eye-candy
….

web2.0. E ultimul buzz-word. Dac-as vrea sa vand castraveti mai bine in piata, as scrie mare pe taraba “www.castravetiWeb20.com“. As da spargere!!! Ce se ascunde in spatele acronimului? Orice scuza sferto-semi-auto-docta merge, dragilor. Puteti sa spuneti orice, prostimea pune botul. De ce? Pentru ca e mult mai bine sa aprobi decat sa pari prost.

Ce e un buzz-word? Poi as zice ca un buzz-word e orice entitate fonetica si a-semantica atat de la moda incat a nu o folosi excesiv te face sa pari neanderthalian in ochii societatii.
(pentru cine nu a inteles ce-am scris in bold mai sus: nu va obositi sa ma intrebati, articolul asta oricum nu e pentru voi. E de bine, puteti dormi linistiti.)

Sa facem un pic de istorie:

Mai an, buzz-word-ul era “Branding“. Nu erai om serios daca nu il turnai pe nerasuflate la orice coltz de covrigarie sau sales-pitch. Orice avea legatura cu designul nu mai era “la corent” daca nu se chema branding. S-a umplut peste noapte lumea de experti in branding. “www.castra-branding.com“!!!!… Am prieteni buni care s-au raliat la trendul asta trendy, unii mai rezerevati de bunul simt si de cei sapte ani de-acasa, altii mai orbeste, dar prieteneste, amical.

Inainte de asta buzz-word-ul a fost “Corporate“. Pai frate, daca nu erai in stare sa torni un “concept” suficient de “corporate”, nu erai pe nicaieri! Nu conteaza ca in Romania poti numara Corporatiile pe degetele de la maini si picioare (o persoana, va rog). TOT clientul s-a vrut “corporate”. Atunci mergea sa trantesc un “www.castraveticorporate.com“!… acum ar suna atat de fumat, zau…

Hai sa mai derulam un pic… WOW!!! Nu, nu e reactia mea. E buzz-wordul de dinainte de “corporatii”. Te duceai, acum ceva ani buni, la client, si il intrebai ce vrea de la sufletul tau de designer. Si ti-o trantea, inevitabil: un WOW-DESIGN!!! Ha? Ce-i aia neicushorule? Prutene, ne auzi? Zi-mi dom’le pe romaneste ce vrei… Daca vrei sa faci WOW, du-te matalutza la balci si casca ochii la Femeia cu Mustatza si la Omul-Shoparla… poi oameni suntem, sau fiare de calcat?

Nu mai tin minte ce a fost inainte de asta… Eram poate prea la inceputuri, si eu, ocupat sa invatz cat mai multe de la cine chiar shtia ce e de shtiut. Tin minte de mania (mult mai generala) a lui DECI… La fel de cretinoid folosit, la fel de vindecat acum…

Care mai stiti buzz-words din lumea designului, varsati aici… poate trantim de-un time-line haios 🙂 .

Later edit: cum am putut sa uit de AJAX?… mare rusine… Sau de Usability (atat de necesara, ca si concept, atat de pe nedrept data la cosul uitarii)