Una di queste situazioni è stata descritta pochi giorni fa su 456 Berea Street, e riguarda le liste HTML: i classici tag <ol> e <ul>. Quando l’aspetto della lista viene nascosto tramite fogli di stile, molti screen reader non la annunciano come tale, anche se il codice HTML dice il contrario.

Questo si verifica utilizzando gli attributi CSS:

list-style-type: none

oppure

list-style: none

In questi casi NVDA su Firefox, Orca e VoiceOver non dichiareranno la presenza di una lista. Non è un problema gravissimo, ma questo comportamento peggiora l’esperienza di navigazione degli utenti che usano uno screen reader. Non saranno infatti in grado di capire quando inizia o finisce un elemento.

Una informazione del genere ovviamente va valutata a seconda delle situazioni e del target di utenti: nessuno vi impedisce di usare list-style: none, ma se lavorate su un sito dove tenete all’accessibilità, considerate l’ipotesi di mostrare le liste come tali, senza ricorrere a immagini in background per i puntatori o stratagemmi simili.

Se vi interessa approfondire l’argomento screen reader e volete testare il vostro sito, trovate altre informazioni utili in questo post: Uno screen reader per i test.

Infatti se all’interno di un CSS ci sono delle regole contrassegnate con !important e questi valori devono essere modificati su dei nuovi elementi, non ci sono molte soluzioni. Le principali sono due:

• stravolgere il foglio di stile
• entrare in un circolo vizioso aggiungendo nuove regole con !important.

Basta capire questo per rendersi conto di come sia sempre meglio evitarne l’uso. Mi era capitato anche in passato di sfiorare l’argomento parlando degli standard del sito della BBC, dove era appunto proibito agli sviluppatori di utilizzare questa regola.

Ma quali sono le alternative? Prima di tutto pensare fin da subito a come dovrà essere organizzato il foglio di stile. Scrivere regole generiche non aiuta e molto spesso è il motivo per cui si viene tentati dall’utilizzo di !important.

Un link ad esempio avrà una sua definizione generica all’inizio del CSS:

a {...}

Ma unire a questo qualcosa come

#content a {...}

…sarà fonte di problemi dopo poco tempo, perché è una definizione troppo generica per non richiedere nuovi interventi. Per evitarlo, la cosa migliore è appoggiarsi sempre a selettori ben specifici, a seconda dell’area del sito.

In un blog potrebbero esserci ad esempio vari div contenitori all’interno dei post, con cui differenziare lo stile dei link:

#content .post_header a {...}
#content .post a {...}

O sulla sidebar invece di un generico

#sidebar a {...}

potrebbero essere definite delle aree precise come sui temi WordPress:

.widget a {...}

Eccezioni

Uno dei rari casi in cui l’uso di !important può avere senso è quando sono presenti elementi specifici che devono apparire uguali in qualsiasi punto del sito. Non sto parlando di bottoni e riquadri (che potrebbero sempre avere delle varianti), ma ad esempio di indicazioni di stato come i messaggi di errore.

Contrassegnare una classe .error nel seguente modo potrebbe essere l’unica ragione per tollerarne l’uso:

.error {color: #f00 !important;}

Se volete leggere anche un’opinione autorevole a riguardo, vi consiglio di dare un’occhiata al post When using !important is the right choice su CSS Tricks, e di leggere attentamente il commento di Jonathan Snook in risposta agli esempi citati dall’autore.

Esistono vari modi di ridimensionare il testo di una pagina web tramite CSS: in pixel, em e in percentuale.

Tramite un post di Jonathan Snook ho scoperto l’esistenza di una nuova unità di misura introdotta con i CSS3, chiamata rem. Questa unità si comporta in maniera molto simile a em, senza ereditarne i punti deboli.

Font-size con em

Prima di parlare delle novità mi sembra giusto riprendere in mano la tecnica che potrebbe essere sostituita.

Utilizzare l’unità di misura em permette già ora di superare un problema di tutte le versioni di Internet Explorer (compresa la 9): l’impossibilità di ridimensionare il testo quando il font-size è espresso in px. Con em questo inconveniente non esiste, basta usare una formula di questo tipo:

body { font-size:62.5%; }
h1 { font-size: 2em; } /* =20px */
p  { font-size: 1.4em; } /* =14px solo se non all'interno di una lista */
li { font-size: 1.4em; } /* =14px solo sul primo livello */

Il problema però è che em è un’unità di misura relativa all’elemento contenitore. Se nella pagina appare un paragrafo all’interno di un elemento li oppure ci sono due o più liste annidate, gli elementi interni aumentano progressivamente di dimensione. Una lista contenuta in un’altra lista in questo caso non sarebbe più 14px ma 20px. Aumentando di un altro livello la dimensione del testo diventerebbe 27px.

Il problema può essere evitato dichiarando per ogni livello il font-size originale, ma è un metodo scomodo e poco mantenibile.

Font-size con rem

L’unità di misura rem si comporta come em, ma fa riferimento all’elemento alla radice del documento. Rem infatti è la sigla per “root em”.

La nuova formula diventa:

html { font-size:62.5%; }
h1 { font-size: 2rem; } /* =20px */
p  { font-size: 1.4rem; } /* =14px */
li { font-size: 1.4rem; } /* =14px */

In questo modo tutti i problemi sono risolti, non esistono differenze sugli elementi annidati e il testo può essere ridimensionato senza problemi anche su IE.

Rem e il supporto dei browser

Il supporto di questa unità di misura è migliore di quanto pensassi: viene riconosciuta da tutte le ultime versioni dei browser, escluso Opera. Per non avere problemi su questo browser e garantire il supporto anche alle versioni precedenti di IE è sufficiente indicare un fallback nei CSS:

html { font-size:62.5%; }
h1 { font-size: 20px; font-size: 2rem; } /* =20px */
p  { font-size: 14px; font-size: 1.4rem; } /* =14px */
li { font-size: 14px; font-size: 1.4rem; } /* =14px */

Cosa ne pensate? Io inizierò a sperimentare questa tecnica nei miei prossimi progetti, e se non emergeranno particolari problemi penso proprio che potrebbe diventare uno standard. E’ più immediato utilizzare px come unità di misura, ma se tenete all’accessibilità dei vostri lavori basta veramente poco per fare la differenza.

[Foto di Paul Pirosca - Fotolia.com]

La parte che riguarda le CSS3 transitions è una delle più interessanti, perché consente di creare semplici effetti grafici con poche righe di codice all’interno del foglio di stile. E’ assurdo installare interi framework JavaScript per un banale effetto dissolvenza: adesso è possibile evitarlo, con alcuni compromessi.

A cosa servono le transizioni dei CSS3?

CSS Transitions allows property changes in CSS values to occur smoothly over a specified duration.

Questa è la definizione del W3C: semplice e concisa (strano, vista la fonte!). Consentono di controllare il modo in cui cambiano certe proprietà CSS, gestendo la durata della transizione.

Transizioni CSS in pratica

Il modo più semplice per imparare ad usarle è guardare un esempio:

#test a {
  background: #333;
  color: #fff;
  -webkit-transition: all .3s ease;
  -moz-transition: all .3s ease;
  -o-transition: all .3s ease;
  transition: all .3s ease;
}
#test a:hover, #test a:focus {
  background: #b00;
}

Questo codice applicato ad un semplice link consente di far sfumare il colore di sfondo al mouseover ed al focus. La proprietà deve essere ancora utilizzata con le stringhe proprietarie di ciascun browser, ma inserire la definizione standard alla fine consente di avere un codice già pronto per quando questa funzionalità diventerà ufficiale.

Sintassi

La forma sintetica, quella che ho utilizzato anche io nell’esempio, è quella più comoda. I valori sono nell’ordine:

1. la proprietà a cui applicare la transizione (all indica che la transizione si applica a tutte: colore, sfondo, ecc.)
2. la durata in secondi della transizione
3. il modo in cui la transizione cambia nel tempo. Per capire le differenze la soluzione migliore è provare i valori possibili, che sono:
   • ease (default)
   • linear
   • ease-in
   • ease-out
   • ease-in-out
   • cubic-bezier (a cui vanno passati quattro valori da 0 a 1, ad esempio cubic-bezier(0,1,1,0))
4. il ritardo espresso in secondi (facoltativo)

E’ possibile anche scomporre l’espressione per applicare la transizione solo a determinate proprietà o assegnare tempi diversi. Ad esempio il codice precedente potrebbe essere scritto:

#test a {
  background: #333;
  color: #fff;
  transition-property: background;
  transition-duration: .3s;
  transition-timing-function: ease;
}
#test a:hover, #test a:focus {
  background: #b00;
}

Non ho ripetuto le stringhe proprietarie per i vari browser, ma credo che il concetto sia chiaro: la maggior parte delle volte comunque troverete utile la formula short-hand precedente unita alla proprietà all.

Compatibilità con i browser esistenti

Comprese le transizioni dei CSS3, resta solo da capire se sia realmente possibile utilizzarle oggi. La risposta è sì, perché portano dei miglioramenti visibili sui browser più evoluti, che comunque non compromettono alcuna funzionalità e rendono più piacevole la navigazione. Meglio non esagerare comunque, non lasciatevi prendere la mano rendendo il vostro sito un incubo animato.

Nel momento in cui scrivo l’articolo, le CSS3 transitions sono supportate dalle ultime versioni di:

• Chrome
• Safari
• Opera

Saranno implementate a breve anche da Firefox 4, la cui data di uscita è prevista per il mese di Marzo.

Lato Microsoft saranno introdotte da Internet Explorer 9: niente da fare per tutti i pc con Windows XP installato, su cui IE9 non sarà disponibile.

Curiosità sulle transizioni del background

Un dettaglio interessante riguarda i cambiamenti dell’immagine di sfondo di un elemento. Se al mouseover volete cambiare il background utilizzando uno sprite CSS ed una transizione, l’immagine non avrà un effetto dissolvenza, ma scivolerà dalla posizione :link a quella :hover (come è logico che sia: nel foglio di stile viene semplicemente cambiata la posizione senza dichiarare una nuova immagine).

Questo può dare luogo ad un effetto indesiderato, ma può essere sfruttato anche a vostro vantaggio usando come immagine di sfondo un gradiente lineare, che al mouseover scivolerà progressivamente verso una tonalità differente.

Risorse utili

• Understanding CSS3 Transitions di Dan Cederholm
• Capire le CSS3 Transitions, traduzione italiana

CSS – Le linee guida

Analizzando soprattutto gli standard relativi alla scrittura dei CSS, ho trovato vari spunti interessanti che potrebbero essere presi in considerazione su molti progetti:

Principi generali

• Le pagine devono essere usabili e leggibili anche senza CSS
• I CSS devono essere validi secondo gli standard del W3C, a meno che non sia necessario soprassedere per rispettare le linee guida interne
• Se un browser non supporta determinate proprietà, deve essere messa in atto la graceful degradation (il sito continua a essere leggibile anche utilizzando software e browser obsoleti)
• L’uso di !important è proibito

Uso dei file CSS

• I file devono avere estensione .css ed essere tutti nella stessa directory
• Le dimensioni dei CSS devono essere ridotte al minimo indispensabile
• I CSS vanno inseriti usando <link> nella sezione <head> del documento, e @import non può essere usato
• Niente stili inline

Tipografia

• Deve essere sempre specificata una font-family generica come fallback (es. serif, sans-serif, monospace)
• Le dimensioni del testo non devono essere specificate in px o pt, unità di misura non ridimensionabili su Internet Explorer (anche nelle ultime versioni)

Varie

• Gli stili sui link vanno assegnati secondo il metodo LVHA (nell’ordine :link, :visited, :hover, :active)
• Deve sempre essere specificato un colore di sfondo del body, anche se bianco
• Quando viene specificato un colore per il testo, deve sempre essere indicato un colore opportuno per lo sfondo

A cosa servono le linee guida?

Sulle motivazioni tecniche dietro queste raccomandazioni c’è un’ampia spiegazione nel documento relativo, ma la questione per me è un’altra: serve davvero a qualcosa stabilire un set di regole così rigorose? Considerate che queste sono le linee guida più importanti sulla scrittura dei CSS, ma ne esistono altrettante per HTML, JavaScript, elementi audio-video, uso di cookie, design dei database, ecc.

Potrebbe sembrare una mole enorme di informazioni inutili, ma per un sito così strutturato e su cui lavorano più persone contemporaneamente non è possibile pensare a soluzioni diverse. La novità interessante, se vogliamo definirla così, è che le linee guida sono pubbliche e liberamente consultabili.

Vi è mai capitato di lavorare in progetti di grandi dimensioni? Non avere delle linee guida porta in breve tempo ad avere un codice impossibile da mantenere. Pensando in particolare ai fogli di stile diventa facilissimo scrivere regole duplicate ed aggiungere proprietà inutili.

C’è però una difficoltà da considerare: far rispettare le linee guida.

Molto spesso capita di avere documentazioni dettagliate che nessuno legge, e qui la responsabilità va suddivisa tra i singoli sviluppatori ed i loro superiori. E’ impensabile comunque che in questi casi ci sia sempre un controllore: la vera svolta si ha solamente quando tutti riescono a comprendere l’utilità di lavorare seguendo degli standard. Se per fare una minima correzione serve mezza giornata di lavoro per capire dove intervenire, significa che qualcosa non funziona.

Avete esperienze con progetti caotici da raccontare? I commenti sono a vostra disposizione.

Incredibile ma vero, nella tabella di compatibilità preparata in maniera eccellente da Quirksmode, IE9 entra infatti nel gruppo dei browser che possono utilizzare tutti i selettori più utili, compresi anche alcuni dei CSS 2.1.

I selettori supportati da Internet Explorer 9

CSS 2.1

• :before e :after
• :first-child
• :focus

CSS 3

• :empty
• :enabled, :disabled e :checked
• :first-of-type
• :last-child
• :last-of-type
• :not
• :nth-child()
• :nth-last-child()
• :nth-last-of-type()
• :nth-of-type()
• :only-child
• :only-of-type
• :root
• ::selection
• :target

In questa lista sono esclusi alcuni selettori che sono già supportati dalle versioni precedenti di IE.

Interessante notare che mentre le ultime versioni di Firefox, Safari e Chrome non hanno problemi, adesso è Opera l’unico browser ad essere rimasto indietro, con delle difficoltà di interpretazione dei selettori :nth-child() ed :nth-of-type(). Opera infatti non riesce ancora a capire il funzionamento di queste regole, utili ad esempio per evidenziare gli elementi pari di una lista, o dare alternativamente a delle immagini float:right e float:left.

Implicazioni future

Questo ovviamente non significa che con l’uscita di Explorer 9 i selettori dei CSS3 potranno essere usati senza problemi (le versioni precedenti ci faranno compagnia per molto tempo), ma ci stiamo avviando verso un futuro più semplice per gli sviluppatori. L’uso di queste regole infatti consentirà di eliminare id e classi inutili dall’HTML, alleggerendo la struttura delle pagine.

Per il momento non resta che sperimentare ed affidarsi se necessario a soluzioni come ie-css3.js, aspettando la scomparsa dei browser più obsoleti.

Come funziona box-shadow?

La proprietà può essere utilizzata su Firefox 3.5 e sui browser basati su webkit (Safari e Chrome) con i soliti prefissi:

• -moz-box-shadow per Firefox
• -webkit-box-shadow per Safari e Chrome

L’espressione è semplicemente:

box-shadow: 5px 5px 10px #000;

dove i parametri sono nell’ordine:

• la distanza dell’ombra in orizzontale ed in verticale
• il raggio
• il colore

Ho notato che tra i browser webkit la resa è migliore su Safari: Chrome pur visualizzando l’ombra ha qualche problema con gli angoli ed il loro arrotondamento.

La soluzione per Internet Explorer

La cosa interessante, scoperta per caso sul blog di Nick Dunn, è che con alcuni hack è già possibile sfruttare questa proprietà per ottenere un risultato valido anche su Internet Explorer.

Esistono infatti alcuni filtri proprietari della Microsoft che in queste circostanze sono l’unica soluzione possibile. Era già successo per i .png trasparenti su IE6, e la situazione è analoga anche in questo caso. Combinando i filtri Glow e Shadow, o ancora meglio utilizzando solamente Shadow è possibile ottenere un’ombra molto simile su tutte le versioni di Explorer, a partire dalla 5.5.

Il codice necessario è il seguente, da inserire in un commento condizionale:

filter:
    progid:DXImageTransform.Microsoft.Shadow(color=#eeeeee,direction=0,strength=7)
    progid:DXImageTransform.Microsoft.Shadow(color=#dddddd,direction=90,strength=10)
    progid:DXImageTransform.Microsoft.Shadow(color=#dddddd,direction=180,strength=10)
    progid:DXImageTransform.Microsoft.Shadow(color=#eeeeee,direction=270,strength=7);

Color e strenght dell’ombra possono ovviamente essere modificati secondo le necessità.

Demo

Ho realizzato una pagina dimostrativa di questo effetto.

Il risultato cambierà leggermente a seconda del browser utilizzato, ma resterà comunque coerente. La soluzione non è esente da difetti, ma è un buon compromesso per aggiungere dettagli in più ad un design senza appesantirlo con delle immagini. C’è anche da considerare che spesso è complicato dare un’ombra ad un contenitore, soprattutto se questo ha delle dimensioni variabili: l’unica soluzione è utilizzare del codice html superfluo o adottare questo metodo.

I difetti principali che ho riscontrato sono:

• CSS non valido
• niente ombra su Firefox < 3.5 e su Opera
• uso di hack per Internet Explorer

A voi la scelta se adottare questa soluzione: è una possibilità da tenere in considerazione, ma la sua efficacia è da valutare a seconda del progetto. Niente vieta comunque di adottare anche solo la soluzione per Firefox come progressive enhancement, offrendo un’esperienza migliore di navigazione ad alcuni utenti.

:focus {
	outline: none;
}

Potrà sembrare una soluzione elegante, ma ai fini dell’accessibilità di un sito è assolutamente sconsigliato, perchè senza outline diventa impossibile navigare tramite tastiera, o comunque con dispositivi diversi da un mouse.

Non pensate che riguardi solo una minoranza di utenti: sono tanti coloro che scorrono il contenuto di una pagina premendo il tasto tab. In molti ad esempio si spostano tra i campi di un form in questo modo: eliminando l’outline sul focus rendete il vostro sito inaccessibile.

Lo stesso Eric Meyer, autore di uno dei più famosi CSS Reset, pur azzerando questo stile raccomanda di definirne altri per sostituirlo. Il mio consiglio è di lasciarlo inalterato per evitare problemi: perchè complicarsi la vita?

Una soluzione alternativa

A volte potrebbe comunque capitare di essere obbligati a modificare lo stile dei link, ad esempio su richiesta di un cliente particolarmente insistente. Un’alternativa in questi casi è lasciare il focus inalterato ed eliminare l’outline dallo stato active:

a:active {
	outline: none;
}

Così non apparirà il bordo tratteggiato al clic, ma la navigazione da tastiera resterà comunque possibile. Non è una soluzione ottimale, ma in situazioni particolari potrebbe essere un compromesso accettabile.

Foto: Macbook Keyboard by alcomm

Il codice CSS

La teoria è semplice: dato un contenitore e degli elementi al suo interno, questi potranno adattarsi allo spazio vuoto. Considerando come html di base:

<div class="container">
    <div class="box"></div>
    <div class="box"></div>
</div>

Il CSS necessario per far adattare verticalmente i due div interni sarà:

.container {
    display: box;
    box-align: stretch;
    box-orient: vertical;
}
.box {
    box-flex: 1;
}

N.B.: Per lo stretch orizzontale, basta usare box-orient: horizontal.

In realtà per effettuare dei test è ancora necessario utilizzare i prefissi -moz- e -webkit-, visto che le proprietà standard non sono ancora supportate.

Esempi pratici

Per capire ancora meglio la dinamica di questo modulo, gli esempi che trovate su css3.info sono meglio di qualsiasi descrizione testuale, a patto che stiate utilizzando le ultime versioni di Firefox, Safari o Chrome. Il W3C infatti sta ancora lavorando sul documento, e per adesso solo i motori di rendering Gecko e Webkit hanno delle istruzioni proprietarie adatte allo scopo.

Da notare che i due motori presentano risultati differenti, pur rendendo chiaramente l’idea dell’utilità della proprietà. A mio parere l’interpretazione corretta è quella di Webkit, ma finchè le specifiche non saranno definitive diventa difficile stabilirlo.

Un altro articolo interessante a riguardo è sul blog di Alex Russel, che ha preparato un foglio di stile su misura per avere già pronte tutte le classi necessarie.

Perchè parlarne?

Se le specifiche per il Flexible Box Layout Module sono ancora così indietro, ha senso parlarne? La risposta è sì, come nel caso di tutte le altre proprietà dei CSS3 che non sono ancora supportate. Pur non potendo utilizzarle nei propri progetti, per un web designer non è mai troppo presto per sperimentare: quando arriverà il momento sarà un grande vantaggio conoscerle.

Purtroppo l’ostacolo è rappresentato dalla lentezza del W3C e dal normale ciclo di vita dei browser: finchè esisteranno sul mercato delle versioni che non supportano queste nuove proprietà, sarà ancora presto per utilizzarle.

Escludendo qualche rara eccezione, la maggior parte delle proprietà hanno nomi diversi e sono supportate in maniera differente a seconda del browser: questo non semplifica il lavoro degli sviluppatori. Basti pensare ad una proprietà ormai diffusa su tutti i browser (escludendo il solito Internet Explorer): border-radius. Su Firefox è necessario utilizzare il prefisso “moz-”, su Safari e Chrome bisogna anteporre “webkit-” , ed ognuna di queste forme ovviamente non è riconosciuta dal W3C.

Il risultato è che se si desidera utilizzare i CSS3 per dare ad una parte dei propri utenti una migliore esperienza di navigazione, non sarà possibile validare il foglio di stile.

Come comportarsi in questo caso? L’unica soluzione è trovare un compromesso. Su questo sito ad esempio l’unica proprietà particolare che ho utilizzato è text-shadow, ben supportata nella sua forma standard. Ho invece trascurato proprio border-radius e altre proprietà simili, che però utilizzo su altri progetti come il mio blog personale, dove sono meno rigido per quanto riguarda la validazione dei CSS.

La colpa di questa situazione è da attribuire soprattutto alla lentezza del W3C, perchè i produttori di browser stanno dimostrando una grande attenzione alle novità. Supportare certe funzionalità è comunque motivo di vanto sulla concorrenza. Non è possibile però chiedere ai produttori di utilizzare fin da subito la forma standard delle proprietà: le specifiche potrebbero cambiare prima del raggiungimento della loro forma standard.

Proprio sull’uso dei CSS3 sarei curioso di conoscere anche il vostro punto di vista: li utilizzate? Vi preoccupate della validazione del foglio di stile?

Uno dei migliori suggerimenti sull’argomento, segnalato su CSS3.info, riguarda una possibile modifica al validatore del W3C. La soluzione ideale infatti sarebbe vedere segnalate come “experimental” o “warning” le proprietà dei CSS3 ancora sperimentali, consentendone l’uso senza problemi. Gli errori sparirebbero per la felicità di tutti, ma è una speranza probabilmente troppo ottimista.