Mi è ricapitato fra le mani questo articolo di Jason Santa Maria e volevo segnalarlo perché anche a distanza di qualche tempo (è del 2008) rimane validissimo.

In poche parole

L’idea è molto semplice e consiste nell’estrarre gli elementi di variabilità del nostro lay­out e associarvi delle classi nel foglio di stile. Così, ad esempio, le dimensioni che pos­siamo attribuire a un’immagine diventano delle classi:

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

così come la loro posizione:

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

e così via.

A questo punto, sfruttando la pos­sibilità di specificare più classi per un dato elemento pos­siamo combinare quelle che ci servono.

Analogie

Questo approccio mi ricorda quello pre­sentato in Design Fast Websites; la composizione delle classi sembra molto simile. A chi interessa, l’autrice della pre­sentazione ha anche creato un framework CSS basato sugli stessi principi, Object Oriented CSS, scaricabile da GitHub.

Altre applicazioni

Possiamo usare lo stesso sistema anche per le dimensioni delle font. Oltre a specificare direttamente la dimensione del testo per un elemento, creiamo le classi corrispondenti:

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

Questo articolo su Smashing Magazine fa il punto sui lay­out fluidi e sugli accorgimenti aggiuntivi per evitare sorprese.

In due parole…

Ho letto per la prima di questo approccio su A List Apart. In sostanza, a partire dalla constatazione che i valori in em sono una misura relativa, espressa come target/context, pos­siamo estendere questo approccio per i lay­out, esprimendo le dimensioni delle sezioni in termini di rapporti.

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

Inconvenienti e rimedi

I vantaggi pos­sono essere considerevoli, soprattutto in considerazione del fatto che le dimensioni dei monitor tendono a diversificarsi. D’altra parte ci pos­sono essere problemi, come ad es. il trattamento di elementi come le immagini o gli arrotondamenti. I vari rimedi sono elencati su Smashing Magazine, con alcune chicche come Masonry, che sistema i problemi con gli elementi flottati; Smart Columns, che riarrangia il contenuto in base alle dimensioni della finestra; e l’aggancio delle dimensioni del testo sempre in base alle dimensioni della finestra.

Abbiamo già parlato della tecnica degli sprite per i CSS. Si tratta di un’ottimizzazione delle immagini per ridurre le richieste che il browser compie verso il server.

Ho sempre pensato a questa tecnica come a una cosa piuttosto semplice, senza particolari rischi o situazione “tricky”.

Ovviamente mi sbagliavo. Gli sprite pos­sono essere sì leggeri per il download, ma anche gonfiarsi a dismisura in memoria se non sono progettati accuratamente e con le immagini adatte.

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

Segnalo da 24 Ways un articolo che, sfruttando la pos­sibilità di specificare più una distanza dal suo genitore per un elemento posizionato in modo assoluto, raggiunge uno degli obiettivi che rimangono ancora (troppo) difficili da raggiungere con i CSS: colonne di altezza uguale allineate verticalmente.

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

Curiosando su CSS-tricks ho scoperto Starkers, un tema per Wordpress che consiste nel solo CSS di reset, ispirato a quello di YUI, che permette di operare da un punto di partenza “pulito”.

Già che ci sono, segnalo anche che sempre sullo stesso sito si trova uno screencast in tre parti sullo sviluppo 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 comunque utili come base di partenza, soprattutto per chi, come me, conosce poco php e ogni volta che lo vede ricorda con nostalgia i component di WebObjects (ma questo merita un post a parte).

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

Della serie “guarda che post pazzesco dopo una pausa di qualche giorno” :-D Avevo un po’ di candidati per cose più succose ma non ho tempo.

Il “body border” è in parole povere una cornice che corre lungo tutto il bordo del viewport (che è l’area visibile all’interno della finestra del browser). 
Via CSS Trick ecco un modo molto semplice e supportato dai browser più recenti per implementarlo: ci vogliono quattro div, posizionati con fixed e i giusti valori di top, bottom, left e right.

Per chi usa Safari 3.1 c’è una demo carina sulle potenzialità delle animazioni con i CSS. Forse Jobs era serio quando diceva che l’SDK per l’iPhone era Safari :-D

Scenario: serviamo una pagina in https e vogliamo inserire un link ad una risorsa esterna al sito. Come facciamo? Sempre con le URL relative ma specificate in modo leggermente diverso.

Di solito si usano queste due soluzioni: <img src='image.png' /> per le risorse interne al sito e <img src='http://host/image.png' /> per quelle esterne. Ma esiste una terza pos­sibilità: <img src='//host/image.png />.

Qual’è il vantaggio? Che, come nello scenario della domanda iniziale, tutte le risorse da un sito esterno in una pagina in https verranno caricate con questo protocollo, mentre in una pagina normale verrà usato l’http. A che serve? Ad evitare gli avvisi terroristici di Explorer quando vengono caricate risorse in http in una pagina https.

Bel trucchetto, vero?

Via: Stringify

In questo articolo viene pre­sentato un sistema per semplificare, o forse sarebbe meglio dire compattare, un form complesso.

L’idea di fondo è quella di ridurre le diverse sezioni del form in widget espandibili e contraibili a piacere per ridurre al minimo lo spazio occupato.

A mio parere si sorvola troppo sui difetti di una soluzione del genere che sono due: le opzioni disponibili non sono tutte immediatamente visibili e il numero di click neces­sari per selezionare un’opzione. So benis­simo che è proprio lo scopo dell’articolo quello di mostrare un modo per ridurre l’affollamento dello schermo ma non dobbiamo dimenticare che ogni soluzione ha i suoi pro e contro.

Nel complesso rimane comunque un approccio piuttosto efficace, calcolando il fatto che le etichette rias­suntive pre­sentate quando l’elemento è contratto pos­sono fornire informazioni sulla selezione attiva in quel momento.

Che ne pensate? Avete usato soluzioni del genere? In particolare per applicazioni web che pre­vedono inserimenti dati massicci?