Sviluppare un sito con i CSS significa innanzitutto comprendere cosa possono realmente fare i CSS. Questo articolo vuole essere una breve guida in tal senso.
Introduzione
Nell'ottica di avere una sempre maggiore produttività nella realizzazione di un layout, occorre avere chiari in partenza gli obiettivi che si vogliono raggiungere, ossia occorre porsi le seguenti domande:
- Cosa voglio ottenere?
- Come lo voglio ottenere?
Il progetto: il "cosa"
Per individuare cosa vogliamo ottenere, si dovrebbero tenere in considerazione i seguenti aspetti:
- Utenti del sito.
- Contenuti del sito.
- Contesto del sito.
- Esigenze del cliente.
Come si può notare, i primi tre punti ricalcano fedelmente le tre macroaree dell'architettura dell'informazione. Il quarto punto, invece, riguarda i compromessi a cui bisogna scendere a volte per accontentare chi ci ha commissionato il sito. Vediamoli in dettaglio.
Utenti del sito
La categoria forse più sottovalutata nella realizzazione del layout di un sito sono proprio i suoi utenti. Chi si occupa del foglio di stile di un sito, dovrebbe soprattutto sapere quale browser usa la maggioranza dei propri visitatori. Fatto questo, ci si può orientare verso determinate strategie di sviluppo, di cui riassumiamo i possibili (e più probabili) scenari.
- Situazione 1: Internet Explorer, Firefox, Chrome
Questa è attualmente la situazione più probabile. Le percentuali oscillano tra un 75-80% per IE (versioni 8, 7 e più raramente 6) ed un 20-25% per Firefox e Chrome. Per lo sviluppatore ciò significa che si dovrà scrivere un foglio di stile attento agli standard del Web ma pronto a usare codice non standard per compensare i bug di Explorer (7 e 6).
- Situazione 2: Internet Explorer, Firefox, Chrome ed altri
Per altri si intendono quei browser di nicchia, come Opera, Safari e Konqueror che in genere non superano mai il tetto del 2%. In tal caso vale quanto detto sopra, ma con l'avvertenza di essere pronti ad usare soluzioni con JavaScript o lato server se dovessero presentarsi dei problemi con i browser di nicchia.
- Situazione 3: Internet Explorer
Lo scenario peggiore se le versioni sono la 7 e la 6. Se dovesse verificarsi, siate pronti a sacrificare qualcosa del vostro attaccamento agli standard ma non rinunciandovi del tutto.
Contenuti del sito
I fogli di stile nascono per la formattazione dei contenuti. Bisogna vedere che tipo di contenuti possono esservi in un sito. Diamo un breve schema riassuntivo (ovviamente non onnicomprensivo):
- Sito personale o blog
Qui vale molto la "licenza poetica", anche se nella scelta della formattazione in teoria non andrebbe dimenticata l'accessibilità (solo in teoria). De facto vi troverete a dover gestire contenuti assai eterogenei, che spaziano dal semplice testo, alle immagini fino agli elementi multimediali.
- Sito ufficiale o istituzionale
Qui è richiesta la massima accuratezza e precisione. Nessuna "licenza poetica". Dovrete gestire testo, immagini, form complessi, modulistica, e formattarli in modo accessibile, garantendo il giusto contrasto di colore ed un'adeguata spaziatura.
- Sito aziendale
Come il precedente, ma con l'unica differenza dei limiti imposti al vostro lavoro dal modello di immagine scelto dall'azienda.
- Portale
Sia che si tratti di una community che di un sito di download, qui dovrete gestire lo spazio fin nei minimi dettagli, perché in genere questi siti tendono ad avere pagine sovraccariche di contenuti.
Contesto del sito
Il contesto è fondamentale per capire in seguito quali scelte adottare nella formattazione dei contenuti. Alcuni esempi generici:
- Cultura
La sobrietà è un dictat. Qui dovrete dimostrare la vostra padronanza delle proprietà del testo, ed essere pronti a ricreare (o almeno imitare) alcuni effetti tipografici comuni, quali pull quotes, indentazioni e capolettera.
- Informazione
Qui avrete a che fare con contenuti assai eterogenei. Siate pronti ad affrontare file multimediali, articoli, immagini e tutto ciò che potete trovare nei comuni rotocalchi online.
- Intrattenimento
La fantasia e la creatività sono fondamentali. Siate pronti a soluzioni sperimentali per assecondare i desideri dei designer.
Esigenze del cliente
Le esigenze del cliente dipendono direttamente dal tipo di cliente con cui dovete lavorare. Ecco alcuni possibili tipologie di cliente.
- Il cliente ideale
Conosce bene il Web. Ha una discreta esperienza nel campo della pubblicazione elettronica. Naviga con più di un browser. Conosce le tematiche dell'accessibilità e degli standard. È disponibile ad un dialogo in caso di visioni conflittuali su alcune scelte di progettazione.
- Il cliente non proprio ideale
Conosce abbastanza bene il Web. Non ha esperienza nel campo della pubblicazione elettronica e ha scarsa conoscenza delle tematiche dell'accessibilità e degli standard. Naviga con un solo browser. Tuttavia, è disponibile al dialogo perché si rende conto di non avere abbastanza conoscenze.
- Il cliente "no comment"
Non conosce il Web. Non ha esperienza nel campo della pubblicazione elettronica. Naviga con un browser obsoleto. Non conosce né gli interessano gli standard e l'accessibilità. Nessun dialogo possibile.
Il layout: il "come"
Poste le basi del progetto, bisogna concretizzarlo in un layout. Un primo abbozzo potrebbe comprendere i seguenti passaggi:
- Idea
- Bozza
- Layout
Possiamo visualizzare questa prima fase in un semplice diagramma di flusso.
Figura 1: Idea – Bozza – Layout
Tuttavia ci accorgiamo subito che il nostro approccio risulta eccessivamente semplificato. Bisogna infatti tenere conto dei problemi che potrebbero verificarsi all'atto della pubblicazione, come per esempio un'errata visualizzazione ad una determinata risoluzione di schermo. Occorre dunque aggiungere un'ulteriore fase di test al nostro lavoro. Quindi avremo:
- Idea
- Bozza
- Layout
- Test
Ecco il nuovo diagramma.
Figura 2: Idea – Bozza – Layout – Test
Se nella fase di test ci dovessimo imbattere in un comportamento anomalo in un browser, dovremmo aggiungere un'ulteriore fase di debugging per risolvere il problema. Quindi avremo:
- Idea
- Bozza
- Layout
- Test
- Debugging
Ecco il nuovo diagramma.
Figura 3: Idea – Bozza – Layout – Test – Debugging
Come si evince dal diagramma, il nostro flusso di lavoro arriva ad un bivio prima di giungere al risultato finale. Difatti, prima di completare il nostro sviluppo è necessario:
- Creare un test efficace per isolare gli eventuali bug.
- Risolvere i bug in fase di debugging.
Test e debugging
Per creare un test efficace occorre per prima cosa:
- Validare la marcatura della pagina per assicurarci che non vi siano errori sintattici.
- Validare il foglio di stile per assicurarci che non vi siano errori sintattici.
Fatto questo dobbiamo:
- Individuare l'elemento (o gli elementi) che presentano il problema.
- Ridurre le regole di stile della pagina.
- Verificare se facendo in questo modo il bug è ancora presente.
Prima di risolvere i tre punti sopra elencati, occorre operare una distinzione tra bug ed anomalie.
Un bug è un'esplicita violazione delle regole di stile espresse ed è contrario alle
specifiche.
L'anomalia è una differente interpretazione delle regole di stile espresse ma
non è contrario alle specifiche. Al primo gruppo appartengono i noti bug di Internet
Explorer 6 (ed inferiori) con la proprietà float, mentre al secondo appartengono le differenti
interpretazioni date ad alcuni valori o proprietà non definite con precisione nelle specifiche, come ad esempio
i valori negativi per la proprietà text-indent, le immagini di sfondo per gli elementi inline
o la resa degli elementi dei form.
L'individuazione dell'elemento affetto dal problema rappresenta una fase molto delicata del processo di test. Prendiamo ad esempio le seguenti regole di stile:
.container {
margin: 0;
padding: 0;
position: relative;
font-size: 80%;
}
.container h2 {font-size: 1.2em; margin: 0;}
.left {
position: absolute;
top: 30px;
left: 10px;
width: 220px;
margin: 0;
padding: 70px 10px 10px 10px;
}
.right {
position: absolute;
top: 30px;
right: 10px;
width: 220px;
margin: 0;
padding: 70px 10px 10px 10px;
}
.center {
margin: 66px 260px 0 260px;
padding: 0.5em;
}
.breadcrumb {
margin: 0;
padding: 0;
list-style: none;
background: #efc;
color: #000;
}
.breadcrumb li {
display: inline;
padding: 0 0.2em;
}
Guardando questo esempio noteremo come i link della barra di navigazione
(elemento con classe .breadcrumb) non sono cliccabili in Firefox. Saremmo subito propensi a pensare ad un bug,
in quanto tale comportamento non viene riscontrato in altri browser. Come prima cosa, possiamo aggiungere una semplice dichiarazione
al foglio di stile per verificare il posizionamento e le dimensioni degli elementi:
* {border: 1px solid red;}
Osservando quindi il nuovo esempio, noteremo come le due colonne
(classi .left e .right) si sovrappongano con la coloro altezza alla barra di navigazione.
Poiché con il posizionamento assoluto gli elementi posizionati vengono rimossi completamente dal flusso, è possibile
che si verifichino sovrapposizioni. Rileggiamo quindi le dichiarazioni di stile delle due classi:
.left {
position: absolute;
top: 30px;
left: 10px;
width: 220px;
margin: 0;
padding: 70px 10px 10px 10px;
}
.right {
position: absolute;
top: 30px;
right: 10px;
width: 220px;
margin: 0;
padding: 70px 10px 10px 10px;
}
Poiché in questo caso l'altezza degli elementi posizionati è data dalla somma dell'area di contenuto, dai valori
della proprietà top e del padding superiore, noteremo come eliminando il valore 70px (padding-top)
il problema scompaia. In questo caso quindi non si trattava di un bug ma di un problema di sovradimensionamento.
Nel caso dei bug veri e propri occorre operare un'ulteriore distinzione tra bug noti e bug sconosciuti. I bug conosciuti sono corredati di un'ampia documentazione e sono generalmente risolvibili o parzialmente risolvibili. Diamo di seguito alcuni collegamenti a risorse significative:
- Browser bugs section – Curata da Gerard Talbot si rivela fondamentale in molti casi.
- Bug report – Curata da Peter-Paul Koch è un'indispensabile strumento di ausilio.
- Bugzilla – Il sistema di segnalazione e catalogazione dei bug dei browser basati su Gecko (Firefox, Mozilla, ecc.).
- CSS Discuss – Negli archivi di questa mailing list si possono trovare informazioni utili su bug e soluzioni.
- CSS Tests – Curati da Bruno Fassino sono estremamente utili nel debugging.
- On having layout – Risorsa fondamentale per comprendere i bug relativi ad Internet Explorer Windows. Disponibile in traduzione italiana all'indirizzo http://gabrieleromanato.altervista.org/css/onhavinglayout.html.
- Position Is Everything – Molti articoli sono stati tradotti sul presente sito o all'indirizzo http://gabrieleromanato.altervista.org/css/pie/.
Viceversa, i bug sconosciuti non sono documentati e a volte non sono risolvibili, proprio a causa della mancanza di documentazione. Occorre quindi procedere in questo senso:
- Ridurre la pagina a un test minimo.
- Documentare il bug.
- Sottoporlo ad una verifica in sede appropriata.
Per ridurre la pagina ad un test minimo si devono eliminare progressivamente tutte le dichiarazioni di stile e verificare se ad ogni regola eliminata il bug è ancora presente. Quando si individua la regola o i valori alla cui eliminazione il bug scompare, si deve salvare il proprio lavoro in una pagina e quindi passare alla fase di documentazione, specificando:
- Modalità del documento (quirks o strict).
- Elemento (o elementi) affetti dal bug.
- Proprietà o valori coinvolti.
La fase di documentazione è indissolubilmente legata alla conoscenza delle specifiche: occorre studiare le specifiche prima di asserire che il browser (o i browser) le stanno violando.
Infine, il test così ottenuto va sottoposto a verifica da parte degli sviluppatori dei browser o delle specifiche stesse. In tal caso si devono prima conoscere le regole di formato per sottoporre il test a verifica. Occorre quindi attenersi scrupolosamente a quanto indicato dalle linee guida dei siti o delle mailing list (si vedano ad esempio i requisiti di formato per le suite di test del W3C).
I bug sconosciuti possono essere affrontati molto spesso cambiando approccio al nostro layout. Se per esempio vediamo che il bug riguarda una particolarità del posizionamento assoluto, possiamo prendere in considerazione l'idea di usare il float per ottenere lo stesso effetto.