Dietro le quinte del nuovo template di Fucinaweb

Temi per WordPress ne troviamo a vagoni nel web, una ricerca con google dei termini “worpress theme” ritorna più di 78 milioni di pagine e devo dire che parecchi sono anche molto belli. Se li guardiamo per il blog del nostro cliente o per il nostro primo blog ne troviamo sicuramente uno che ci piace. Se invece siamo alla ricerca di un nuovo tema per il nostro blog troviamo in ognuno una noticina stonata, manca quel tocco che lo porta alla perfezione e che lo rende adatto a vestire il *nostro* blog.

Chi ha già un proprio blog da tempo è una sensazione che sicuramente conosce (su dai ammettiamolo!) ed è la scintilla dell’idea “mi faccio il mio tema”, la motivazione per la quale sono stato coinvolto da Antonio in questa avventura che ci ha portato a rivestire Fucinaweb con un proprio tema fatto su misura.

Io ho seguito lo sviluppo del template di partenza e la declinazione della grafica in html con molta attenzione a mantenere la compatibilità Xhtml Strict e la accessibilità dei contenuti.

Il template quindi non ha tabelle ma solamente layer disposti in maniera tale da garantire il corretto flusso delle informazioni. I tag html e i loro attributi sono stati utilizzati in modo tale da identificare correttamente i vari contenuti: liste puntate (tag ul e li) per i menu, header nidificati (tag h1 h2 h3) per i titoli , paragrafi (tag p) per i contenuti di testo, immagini (tag img) identificate da title e testo alternativo.

Il compito di rendere il sito piacevole alla vista e facilmente navigabile è stato lasciato completamente al foglio di stile nel quale tutte le dimensioni sono espresse in em, unità di misura relativa che consente la scalatura del sito alle varie risoluzioni e adattabile alle dimensioni del testo impostato dal browser del navigatore.

Antonio poi nell’opera di rifinitura ha aggiunto un paio di finezze veramente interessanti come i microformat e il foglio di stile per una stampa perfetta (argomenti per i quali spero ci regalerà un articolo prossimamente).

Altri perfezionamenti e aggiustatine in corsa ce ne saranno di sicuro visto che c’è sempre qualcosa di nuovo da scoprire e noi siamo pronti a provarle e divulgarle per crescere insieme a Fucinaweb.

Chi ha paura di Xhtml 8?

Anche voi in preda alla disperazione dopo aver letto dell’incompatibilità tra Xhtml 2 e le versioni precedenti? Suvvia, fate i bravi. Sedetevi e calmatevi, ragioniamo con calma.

Probabilmente provate un misto di paura e rabbia, come è successo a Mark Pilgrim, e credete di avere gettato nella pattumiera tutto il lavoro che vi ha portato a realizzare pagine valide, aderenti agli standard, addirittura accessibili.

Questo è possibile, ma se succederà, non è colpa degli standard che evolvono. Dispiace dirlo, ma la colpa sarà probabilmente solo vostra.

Non fatevi ingannare dalle etichette

E’ meglio che vi facciate da subito il callo quando lavorate con gli standard: le vostre pagine Xhtml 1.x valide, magari che usano i Css per il layout, vivranno meno di quello che pensate.

Probabilmente non vi aspettavate che questo standard fosse messo quasi subito in discussione (e in effetti non è così). La verità è che oggi non riusciamo ad immaginare come l’Xhtml evolverà nei prossimi anni e quali cambiamenti introdurrà nel modo di concepire una pagina web.

Una soluzione per dormire sonni tranquilli esiste, e non richiede nessun tipo di tecnologia di ultima generazione: è in realtà un approccio mentale.

I vantaggi di X(ht)ml

Il primo passo consiste nell’adottare lo standard Xhtml per la costruzione delle pagine.

Perché preferire Xhtml a Html? Tra tutti i pregi, sicuramente il fatto che un documento Xhtml è anche un particolare tipo di documento Xml.

E qual è il vantaggio di Xml? Perché preoccuparsi di questo standard a prima vista esoterico? Con Xml potete definire accuratamente i dati e la struttura delle informazioni della realtà in esame (un libro, un listino prodotti, ecc.). Non solo: avete la possibilità di trasformare agevolmente un documento Xml per ottenere risultati molto diversi (una pagina web, un file di testo, un documento Pdf, un altro documento Xml). Per farlo si utilizzano le trasformazioni Xsl (Xslt), un linguaggio decisamente potente che è possibile imparare e addomesticare in poco tempo.

La facilità con cui si realizza una trasformazione è proporzionale alla qualità con cui è stato descritto il documento X(ht)ml.

Quindi, fintantoché realizzate dei buoni documenti Xhtml, non avete nulla da temere: potrete sempre, se lo volete, trasformare una versione nella successiva e viceversa.

Il problema è un altro: cos’è che fa di un documento Xhtml un “buon” documento Xhtml?

Ad ogni oggetto il suo nome

Appartenete a quel genere di sviluppatori che posti di fronte ad un template grafico cominciano ad immaginare tabelle, Css, regole e tag (un po’ come succedeva a Russel Crowe in A Beautiful Mind quando cercava indizi sui giornali)? Non solo siete pronti per il manicomio, probabilmente state anche sbagliando l’approccio di lavoro.

La fase di codifica della pagina, quella in cui decidete le parti in cui dividere il layout e iniziare la stesura del codice, non è il primo problema di cui preoccuparsi.

Dovete invece chiedervi: “quanti e quali sono gli oggetti che posizionerò nella pagina?“, una domanda che a prima vista suona banale. Attenzione però: non stiamo parlando di oggetti che corrispondono ad elementi dell’Xhtml. La risposta, cioè, non è “posiziono tre tabelle, una con il menù, una con il corpo centrale e una con un piè di pagina”, ma qualcosa del tipo “inserisco un menù contestuale, una lista di libri, la top ten dei più venduti”.

Perché preoccuparsi di questa fase? Perché l’unica arma a vostra disposizione per evitare l’obsolescenza delle pagine non è una corsa sfrenata agli standard di ultima generazione, ma la cura della struttura e del contenuto della pagina che state creando.

Se raggiungete un buon livello di dettaglio nel descrivere gli elementi che compongono il vostro sito sarete facilitati nell’usare il markup, e riuscirete a traghettare il significato della pagina alle future versioni degli standard.

Un piccolo e concreto esempio

Per entrare nel concreto, non è necessario ricorrere ad esempi di siti complessi. Immaginate allora di dover realizzare una semplice pagina Html che contenga un elenco di libri. Come pensate di procedere?

Il signor Rossi

Il signor Rossi sa che è importante realizzare pagine valide: da un po’ di tempo lo dicono tutti. Non ne ha però ancora capito bene il motivo. “Intanto – pensa – realizzo codice Xhtml valido. Così facendo il mio sito non invecchierà tanto facilmente”.

Un estratto della pagina realizzata da Rossi è il seguente:

  1 <table>
  2   <tr>
  3     <td width=”20%”><img src=”immagine.gif” alt=”” /></td>
  4     <td width=”80%” align=”left”>Libro 1</td>
  5   </tr>
  6   <tr>
  7     <td colspan=”2″>Cum e Cilicia decedens Rhodum venissem et eo mihi de Q. Hortensi morte esset adlatum opinione omnium maiorem animo cepi dolorem. nam et amico amisso cum consuetudine iucunda tum multorum officiorum coniunctione me privatum videbam et interitu talis auguris dignitatem nostri conlegi deminutam dolebam</td>
  8   </tr>
  9   <tr>
 10     <td colspan=”2″>Prezzo: 16 euro<br />Casa editrice: Domus</td>
 11   </tr>
 12 </table>

Il codice è indubbiamente valido (ci mancherebbe), ma privo di struttura e significato. Sono state usate delle tabelle non solo per contenere i dati, ma anche per presentarli visivamente. E’ sbagliato anche il ricorso al tag br per separare su più linee elementi dal significato diverso.

Il signor Verdi

Il signor Verdi sorride mentre osserva il lavoro del signor Rossi. “Poveretto – pensa – non ha ancora capito che queste cose si costruiscono ricorrendo ai fogli di stile”.

Sicuro di quello che fa, propone una soluzione che utilizza i Css:

  1 <div class=”librosx”>
  2   <img src=”immagine.gif” alt=”” />
  3   <div class=”titoloblu”>Libro 1</div>
  4   <div class=”txtnormal”>Cum e Cilicia decedens Rhodum venissem et eo mihi de Q. Hortensi morte esset adlatum opinione omnium maiorem animo cepi dolorem. nam et amico amisso cum consuetudine iucunda tum multorum officiorum coniunctione me privatum videbam et interitu talis auguris dignitatem nostri conlegi deminutam dolebam</div>
  5   <div>Prezzo: 16 euro<br />Casa editrice: Domus</div>
  6 </div>

Lasciate stare il risultato visivo della pagina, che non è paragonabile (e non serve che lo sia) a quello precedente. Non ci interessa neppure analizzare quello che contiene il foglio di stile.

Anche se non considerariamo questi elementi, possiamo ugualmente dire che la situazione, rispetto a prima, è migliorata, ma solo di poco.

I problemi principali sono fondamentalmente due:

  • Il signor Verdi è convinto di usare i fogli di stile per separare la forma dal contenuto. E allora cosa ci fanno nomi di classi come librosx (libro a sinistra) e titoloblu? Cosa succede se un domani il libro va posizionato a destra, oppure il titolo diventa verde? Dobbiamo intervenire su tutte le pagine, o ci accontentiamo di una classe titoloblu che in realtà rende il testo verde?
  • Gli oggetti della pagina non sono stati etichettati con coerenza, tanto che non è facile distinguere gli elementi che la compongono. Txtnormal non dà sufficienti informazioni, sommario sarebbe stata la scelta corretta

Cercate anche di evitare facili nomi come header e footer: concentratevi su quello che contengono, non sull’uso che ne fate nel layout di pagina.

Ricordate: l’adozione dei fogli di stile quale unico strumento per comandare il layout di pagina non è una questione di moda o di immagine: non siete più bravi solo perché realizzate siti senza tabelle. La forza dei Css non è infatti quella di eliminare l’uso di elementi nati per altri scopi, ma più in generale di consentire una netta separazione tra i contenuti e la resa visiva. Sta sempre a voi scegliere il modo corretto di applicarli.

Come fare

Cercate di sforzarvi per capire quali e quanti elementi state posizionando sulla pagina. Chiamate le regole dei Css in modo che sia chiaro e univoco a quali oggetti si riferiscono. Non abbiate paura ad utilizzare due regole che producono lo stesso identico risultato, ma che si applicano ad oggetti diversi: domani possono cambiare.

Una possibile, semplice soluzione, è la seguente:

  1 <div class=”libro”>
  2   <img src=”libro1.gif” alt=”” />
  3   <h1 class=”libroTitolo”>Libro 1</h1>
  4   <p class=”libroSommario”>Cum e Cilicia decedens Rhodum venissem et eo mihi de Q. Hortensi morte esset adlatum opinione omnium maiorem animo cepi dolorem. nam et amico amisso cum consuetudine iucunda tum multorum officiorum coniunctione me privatum videbam et interitu talis auguris dignitatem nostri conlegi deminutam dolebam</p>
  5   <p>Prezzo: <span class=”libroPrezzo”>16 euro</span></p>
  6   <p>Casa editrice: <span class=”libroEditore”>Domus</span></p>
  7 </div>

Come vedete, apparentemente è cambiato ben poco. In realtà il significato della pagina ora è chiaro, non ambiguo e soprattutto coerente.

L’uso del tag div è stato ridotto allo stretto necessario, poiché si tratta di un contenitore di oggetti. Abbiamo premiato il titolo del libro, utilizzando un header h1. Tra i tanti vantaggi, uno screen reader è in grado di scorrere agevolmente queste intestazioni.

Anche il nome delle regole nel Css è più chiaro, e rispecchia gli elementi del libro.

Il contenuto la fa da padrone

Perché fare questo? Se prendete la buona abitudine di organizzare il contenuto della pagina in questo modo, un domani, quando dovete aggiornare il sito alla nuova versione di Xhtml, questa operazione sarà enormemente facilitata. Non solo: potrete riutilizzare il contenuto in scenari e ambiti diversi, al solo costo di una trasformazione.

Pensate ad un caso banale, un menù di navigazione. La versione 8 di Xhtml potrebbe prevedere, per questo tipo di menù, il tag <mn>. Poniamo il caso che oggi lo abbiate realizzato in Xhtml nella forma <div class=”menu”><span class=”menuVoce”>Voce 1</span><span class=”menuVoce”>Voce n</span></div>. Poiché la pagina è semanticamente ricca e coerente, non avrete problemi a trasformare (proprio utilizzando un banale foglio Xslt) questa versione nella successiva. (Potreste anche farlo con un trova/sostituisci, ma non sempre questa operazione risulta praticabile efficamente.)

Cosa fare invece se la prossima versione di Xhtml non consente più di utilizzare il tag acronym (come effettivamente sarà): che fare?

Potreste decidere, con una trasformazione, di cambiare ogni acronym in un tag abbr, visto che questa è la soluzione consigliata dalla specifiche. Attenzione però: state calcando una strada di non ritorno. Mentre è possibile passare da un documento ricco di markup ad uno con un ridotto numero di tag e attributi, il viceversa non è evidentemente possibile.

Per questo motivo, il consiglio è di preservare quanto più possibile la semantica del documento originario. Invece di passare da acronym a abbr, ad esempio, potreste valutare la possibilità di inserire qualche attributo di aiuto, che vi aiuti a capire quello che una volta era un tag acronym. Una soluzione potrebbe essere quella di usare una classe dei fogli stile (ad esempio class=”acronym”), oppure di impiegare un elemento neutro, come uno span (<abbr title=”File Transfer Protocol”><span class=”acronym”>Ftp</span></abbr>).

Fatevi aiutare da chi sa

Come vedete, l’idea per rinvigorire il vostro codice è semplice: cercare di descrivere con un buon livello di dettaglio il contenuto della pagina.

Non è però affatto facile individuare e descrivere gli oggetti che utilizzerete nel sito, come non lo è la valutazione dell’efficacia di una soluzione rispetto ad un’altra. Potreste trovarvi, un domani, a recriminare sull’opportunità di alcune vostre scelte.

Ma avete diverse fonti da cui attingere prima di tuffarvi nel difficile compito di modellare la realtà su una pagina web.

Se il sito per il quale realizzerete i template si basa su un database per la generazione delle pagine, potreste coinvolgere uno sviluppatore e chiedere che vi illustri il diagramma entità/relazione delle tabelle.

Tabelle di un diagramma Entità Relazione

Non è nostra intenzione entrare nel dettaglio di queste tecniche, ma è facile intuire come la struttura del database trovi un riflesso negli elementi della pagina Html. Se il database ha una tabella Libri, con i campi Titolo e Pagine, è molto probabile che anche la vostra pagina si comporti allo stesso modo. Cercate di capire quanto più possibile quello che avete a disposizione per descrivere gli oggetti del sito.

Da dove cominciare

Css, codice valido, Xml, Xsl, semantica, database…costruire una pagina web richiede molte competenze variegate.

Da dove partire? Meglio abbandonare subito le tabelle ed immergersi a capofitto nello studio dei fogli di stile? Non proprio.

Il vostro obiettivo principale è realizzare pagine valide, possibilmente utilizzando lo standard Xhtml (quale versione, lasciamo a voi scegliere).

A questo punto cercate di convertire una vostra pagina in una pagina che descriva correttamente gli oggetti che rappresenta, ricorrendo ad un modesto uso dei Css. E’ senza dubbio meglio se già li conoscete a fondo, ma anche se continuate ad usare tabelle per il layout può andare bene ugualmente all’inizio. Anzi, piuttosto di applicarli come il signor Verdi nell’esempio precedente, concentratevi sugli oggetti e per il momento lasciate perdere il layout via Css.

Solo quando avete capito come descrivere una pagina potete affrontare l’uso avanzato dei fogli di stile.

E infine, per far quadrare il cerchio, dovreste cominciare ad affrontare le trasformazioni Xsl, scegliendo uno dei manuali consigliati nelle nostre recensioni.

Probabilmente non donerete al sito il segreto dell’eterna giovinezza, ma se non altro gli garantirete una felice vecchiaia.

Mastering Xhtml Premium Edition

Convertire un documento Html in uno Xhtml è un procedimento che nella maggioranza dei casi non richiede interventi particolarmenti complessi, come abbiamo detto in un nostro precedente articolo.

Se però vi state avvicinando per la prima volta al mondo dell’Html, vale oggi la pena di cominciare direttamente da Xhtml, soprattutto considerando che:

  • i due standard non sono troppo diversi l’uno dall’altro
  • è molto probabile che in un prossimo futuro vi troviate a convertire i vostri documenti Html in Xhtml

Questo manuale è rivolto proprio a chi sa poco o nulla di Html e Xhtml e desidera cominciare con il piede giusto nella costruzione di pagine per il web.

È un testo molto corposo, che funge sia da manuale, sia da guida di riferimento. A questo proposito è interessante l’inclusione di un Cd-Rom che contiene la versione elettronica della guida, così da facilitare la ricerca durante le ore di sviluppo.

Tra gli argomenti trattati:

  • come costruire un documento Xhtml, inserire i link e le immagini
  • tabelle e form
  • pagine a frame
  • come convertire Html in Xhtml (manualmente o via software)
  • usare i Css e Javascript

Pro

  • una guida completa che non lascia nulla di sottintesto
  • un’ottima guida di riferimento in appendice al testo

Contro

  • pochi esempi di una certa complessità

Informazioni

Mastering Xhtml – Premium Edition ¤ di Ed Tittel, Chelsea Valentine, Lucinda Dykes, Mary Burmeister ¤ lingua inglese ¤ pagine 1260 con Cd-Rom ¤ prezzo: 49.99 dollari ¤ edito da Sybex ¤ lingua: inglese