In que­sti ultimi tempi ho sen­tito par­lare spesso dei pro e i con­tro dell’uso delle classi seman­ti­che nell’HTML¹.

L’approccio pre­di­cato fino ad ora era sem­pre stato più o meno que­sto: non usare nomi come rosso o destra per le classi per­ché così facendo leghi l’aspetto visuale al mar­kup, che dev’essere il più pos­si­bile seman­tico, ovvero, deve avere un signi­fi­cato sle­gato dalla pre­sen­ta­zione. Una cosa con­di­vi­si­bile, almeno fin­ché si tratta di usare una classe come rosso.

Nicole Sullivan² sostiene invece che que­sto approc­cio, come diversi altri, va ripen­sato e che l’uso di classi seman­ti­che per i CSS non è una buona idea. Più pre­ci­sa­mente, se vogliamo mas­si­miz­zare il riu­ti­lizzo di stili e classi in con­te­sti diversi, i nomi devono essere in qual­che misura astratti, sle­gati dal con­te­nuto e quindi neces­sa­ria­mente non semantici.

Anch’io mi sono con­vinto di que­sta cosa: usare una classe come fattura è sba­gliato esat­ta­mente come rosso, né più né meno. Ogni layer di un sistema deve par­lare il pro­prio lin­guag­gio e il lin­guag­gio dei CSS riguarda l’aspetto visivo. Di con­se­guenza anche le classi devono rispet­tare que­sta carat­te­ri­stica. Ad es. al posto di rosso pos­siamo usare, che so, enfasi o accent-color.

Questa cosa va di pari passo con l’altra pra­tica con­si­de­rata un anti­pat­tern, la cosid­detta “clas­site”, ovvero, un abuso delle classi. Nel momento in cui dob­biamo tro­vare i con­cetti visivi giu­sti per gui­darci nella scelta dei nomi, diventa natu­rale usare più classi con meno pro­per­ties³. Questo porta ad avere ele­menti con più classi asso­ciate, una per ogni tratto visivo che vogliamo applicare.

Basta usare que­sto approc­cio per qual­che tempo per capire che i CSS risul­tanti sono molto più leg­geri e molto più riu­ti­liz­za­bili anche se non è sem­pre facile tro­vare dei nomi per le classi che sod­di­sfino al 100%.

Sì, lo so che YUI non è cool come JQuery e che, non bastasse quello, un’altro fra­mework CSS per le gri­glie non è pro­prio una noti­ziona. Ma la cosa che mi piace di più della release 3.2 di YUI¹ è pro­prio la rein­tro­du­zione delle griglie.

YUI CSS Grids è stato uno dei primi fra­mework (se non il primo?) ad offrire una solu­zione modu­lare al pro­blema dei lay­out multi-colonna. In seguito è pas­sata un po’ in secondo piano per la dif­fu­sione di altri sistemi come 960 che offri­vano mag­giore flessibilità.

Con l’ultima ver­sione è stato fatto tesoro di tutti gli avan­za­menti avve­nuti negli ultimi anni, in par­ti­co­lare, il ritorno in auge di solu­zioni “ela­sti­che”, sotto la pres­sione dell’aumento ver­ti­gi­noso dell’importanza della piat­ta­forma mobile.

Sono spa­rite le scelte delle dimen­sioni del lay­out e sono state com­ple­ta­mente ridi­se­gnate le dimen­sioni delle unità interne. Un raro caso di gua­da­gno in fles­si­bi­lità e allo stesso tempo di semplicità.

In que­sta release c’è molto, molto altro. Vale la pena dar­gli un’occhiata.

Mi è rica­pi­tato fra le mani que­sto arti­colo di Jason Santa Maria e volevo segna­larlo per­ché anche a distanza di qual­che tempo (è del 2008) rimane validissimo.

In poche parole

L’idea è molto sem­plice e con­si­ste nell’estrarre gli ele­menti di varia­bi­lità del nostro lay­out e asso­ciarvi delle classi nel foglio di stile. Così, ad esem­pio, le dimen­sioni che pos­siamo attri­buire a un’immagine diven­tano delle classi:

.one {width: 100px;}
.two {width: 210px;}

così come la loro posi­zione:

.left {float: left; margin-right: 20px;}
.right {float: right; margin-left: 20px;}

e così via.

A que­sto punto, sfrut­tando la pos­si­bi­lità di spe­ci­fi­care più classi per un dato ele­mento pos­siamo com­bi­nare quelle che ci servono.

Analogie

Questo approc­cio mi ricorda quello pre­sen­tato in Design Fast Websites; la com­po­si­zione delle classi sem­bra molto simile. A chi inte­ressa, l’autrice della pre­sen­ta­zione ha anche creato un fra­mework CSS basato sugli stessi prin­cipi, Object Oriented CSS, sca­ri­ca­bile da GitHub.

Altre appli­ca­zioni

Possiamo usare lo stesso sistema anche per le dimen­sioni delle font. Oltre a spe­ci­fi­care diret­ta­mente la dimen­sione del testo per un ele­mento, creiamo le classi cor­ri­spon­denti:

._24, h1 { font-size: 182%; }
._21, h2 { font-size: 161.6%; }
._18, h3 { font-size: 138.5%; }
._16, h4 { font-size: 123.1%; }

Questo arti­colo su Smashing Magazine fa il punto sui lay­out fluidi e sugli accor­gi­menti aggiun­tivi per evi­tare sorprese.

In due parole…

Ho letto per la prima di que­sto approc­cio su A List Apart. In sostanza, a par­tire dalla con­sta­ta­zione che i valori in em sono una misura rela­tiva, espressa come target/context, pos­siamo esten­dere que­sto approc­cio per i lay­out, espri­mendo le dimen­sioni delle sezioni in ter­mini di rapporti.

In altre parole, al posto di spe­ci­fi­care che un div dev’essere grande 700px, pos­siamo dire che sarà pari, ad es., al 70,85% della sezione che lo con­tiene, che è pari a 988px.

Inconvenienti e rimedi

I van­taggi pos­sono essere con­si­de­re­voli, soprat­tutto in con­si­de­ra­zione del fatto che le dimen­sioni dei moni­tor ten­dono a diver­si­fi­carsi. D’altra parte ci pos­sono essere pro­blemi, come ad es. il trat­ta­mento di ele­menti come le imma­gini o gli arro­ton­da­menti. I vari rimedi sono elen­cati su Smashing Magazine, con alcune chic­che come Masonry, che sistema i pro­blemi con gli ele­menti flot­tati; Smart Columns, che riar­ran­gia il con­te­nuto in base alle dimen­sioni della fine­stra; e l’aggancio delle dimen­sioni del testo sem­pre in base alle dimen­sioni della finestra.

Abbiamo già par­lato della tec­nica degli sprite per i CSS. Si tratta di un’ottimizzazione delle imma­gini per ridurre le richie­ste che il bro­w­ser com­pie verso il server.

Ho sem­pre pen­sato a que­sta tec­nica come a una cosa piut­to­sto sem­plice, senza par­ti­co­lari rischi o situa­zione “tricky”.

Ovviamente mi sba­gliavo. Gli sprite pos­sono essere sì leg­geri per il down­load, ma anche gon­fiarsi a dismi­sura in memo­ria se non sono pro­get­tati accu­ra­ta­mente e con le imma­gini adatte.

Per saperne di più: To sprite or not to sprite.

Segnalo da 24 Ways un arti­colo che, sfrut­tando la pos­si­bi­lità di spe­ci­fi­care più una distanza dal suo geni­tore per un ele­mento posi­zio­nato in modo asso­luto, rag­giunge uno degli obiet­tivi che riman­gono ancora (troppo) dif­fi­cili da rag­giun­gere con i CSS: colonne di altezza uguale alli­neate verticalmente.

L’articolo non dice molto di nuovo rispetto a quello di A List Apart ma credo sia comun­que utile segnalarlo.

Curiosando su CSS-tricks ho sco­perto Starkers, un tema per WordPress che con­si­ste nel solo CSS di reset, ispi­rato a quello di YUI, che per­mette di ope­rare da un punto di par­tenza “pulito”.

Già che ci sono, segnalo anche che sem­pre sullo stesso sito si trova uno screen­cast in tre parti sullo svi­luppo di un sito in WordPress:

1. Designing for WordPress: Part One;
2. Designing for WordPress: Part Two;
3. Designing for WordPress: Part Three.

I primi due sono a mio parere quelli più ultimi, nel terzo si perde un po’ il filo ma pos­sono essere comun­que utili come base di par­tenza, soprat­tutto per chi, come me, cono­sce poco php e ogni volta che lo vede ricorda con nostal­gia i com­po­nent di WebObjects (ma que­sto merita un post a parte).

Non sapevo fosse pos­si­bile far rifluire il testo anche all’interno del pre…

Della serie “guarda che post paz­ze­sco dopo una pausa di qual­che giorno” :-D Avevo un po’ di can­di­dati per cose più suc­cose ma non ho tempo.

Il “body bor­der” è in parole povere una cor­nice che corre lungo tutto il bordo del view­port (che è l’area visi­bile all’interno della fine­stra del bro­w­ser). 
Via CSS Trick ecco un modo molto sem­plice e sup­por­tato dai bro­w­ser più recenti per imple­men­tarlo: ci vogliono quat­tro div, posi­zio­nati con fixed e i giu­sti valori di top, bottom, left e right.

Per chi usa Safari 3.1 c’è una demo carina sulle poten­zia­lità delle ani­ma­zioni con i CSS. Forse Jobs era serio quando diceva che l’SDK per l’iPhone era Safari :-D