Il numero di manuali e siti che si propongono di diffondere l’uso degli standard web sta aumentando di giorno in giorno. La cosa è certamente positiva, visto che qualcuno (il W3c) si è preoccupato di definire gli standard e si presuppone che qualcuno (voi) li impieghi nei propri progetti.

Se analizziamo con attenzione questi manuali e questi siti è però facile notare come le soluzioni proposte, nonché la definizione stessa di standard, non siano in realtà quelli intesi dallo stesso consorzio che li ha proposti. Molto spesso la visione presentata è molto limitata e nasce dal presupposto, quasi sempre errato, che il sito web rappresenti l’intero mondo dei contenuti e dei processi. La soluzione proposta è molte volte la stessa, ripetuta fino alla noia: Xhtml per il contenuto, i fogli di stile per il posizionamento.

Spesso e volentieri le pagine web che navighiamo sono invece il risultato di operazioni e trasformazioni precedenti, la foce di un fiume la cui sorgente si trova molto più a monte. Questo non solo influenza la produzione dei contenuti, ma anche il modo con cui adottare gli standard. Utilizzare esclusivamente gli standard per il web, senza considerare il contesto in cui si lavora è sbagliato, così come sarebbe sbagliato costruire una casa preoccupandosi solo del materiale da impiegare, senza analizzare le caratteristiche del terreno, del clima e del territorio.

C’è sito e sito

Questo articolo si rivolge a chi realizza progetti di media/alta complessità, ovvero siti i cui contenuti provengono da un sistema di gestione o Cms (per quanto semplice possa essere), e il cui aggiornamento sia periodico e composto da un buon numero di pagine. Con questo escludiamo siti di presentazione, siti aggiornati una tantum e siti completamente statici. Quindi, se l’unico progetto nel quale siete coinvolti è il vostro sito o vetrina personale, non occorre che continuiate a leggere oltre: potete infatti permettervi di adottare o escludere tutti gli standard che volete. Siete gli unici giudici del vostro lavoro e come tali potete concedervi il lusso di sperimentare in continuazione nuove soluzioni.

Cosa sono gli standard

Per capire cos’è uno standard, ci possiamo per prima cosa rifare alla definizione del dizionario Devoto Oli, dove tra l’altro si legge:

“Tipo, modello, norma, cui viene uniformata una data produzione o attività”

e anche

“Complesso di elementi che individuano le caratteristiche di una determinata prestazione o processo tecnico”.

Lo standard è un insieme di regole e metodologie da applicare per mantenere i processi di produzione conformi nel tempo. Ma perché farlo? Perché dotarsi di uno standard?

Le ragioni principali sono:

• aumentare l’efficienza e la capacità produttiva
• ridurre i costi di produzione
• aumentare la qualità del prodotto finale

Cosa sono gli standard web

Gli standard web sono di conseguenza un insieme di metodologie e regole applicate alla realtà web allo scopo di ridurre i costi di produzione del sito, velocizzare il processo creativo e al tempo stesso ottenere un prodotto di alta qualità e facilmente modificabile.

L’organo che si è preoccupato di tutto questo nel mondo internet è stato il W3c. In questi anni il lavoro del W3c è stato enorme: definire e aggiornare un insieme di standard per internet (anche se il termine è in verità improprio, in quanto il W3c rilascia “Recommendations”), un mondo che ha vissuto momenti di continua crescita, e soprattutto visite non proprio disinteressate da parte delle software house.

La nascita di questi interessi ha ben presto portato il processo di standardizzazione a livelli e risultati che non sempre soddisfano chi poi deve applicare gli standard. Documenti troppo completi in parti inutili, ma deficitari nel loro cuore, e standard in continuo mutamento, con nuove versioni che rendono subito obsoleto il lavoro di mesi. Molti sviluppatori sono preoccupati quando sentono parlare di nuove versioni degli standard, hanno paura di dover rifare per l’ennesima volta un lavoro di conversione. Vedremo tra breve che in realtà non è così.

Se cercate le parole “web standard” con Google e passate un po’ di tempo a visitare i siti trovati, non avrete alcun dubbio che gli standard web siano importanti.

Leggendo con un po’ di attenzione, potreste pensare che un sito standard:

• utilizzi i fogli di stile (Css) per definire il layout di pagina
• impieghi Xhtml (invece di Html) come linguaggio per i documenti web
• sia realizzato in modo tale da essere accessibile e usabile

Tutto questo è certamente vero, ma è sufficiente? Siamo cioè sicuri che non dobbiamo considerare altri fattori prima di preoccuparci della costruzione delle pagine, e che questi non influenzino le nostre decisioni per lo sviluppo di un sito? E quali standard conviene usare?

I paladini degli standard web

Attenzione a chi ponete queste domande. Se infatti avete realizzato o gestite un sito che non sfrutta completamente i fogli di stile (non solo per i colori , ma anche per il posizionamento) e magari non utilizza correttamente lo standard Html, allora è molto probabile che prima o poi qualcuno vi informi che il vostro sito è superato, obsoleto, in poche parole “sbagliato”. Questo qualcuno, con il tipico atteggiamento di chi si considera in una posizione privilegiata, non lesinerà consigli e suggerimenti volti all’adozione cieca e totale degli standard web con il fine, secondo lui, di migliorare il vostro sito in termini di usabilità, accessibilità e user experience. Come biglietto da visita, aspettatevi l’Url del suo sito, naturalmente valido, usabile, accessibile. Se ci fermiamo a capire chi è il nostro interlocutore, noteremmo che rientra in una o più di queste categorie:

• ha appena scritto un libro che parla di standard web
• si propone per una consulenza sull’adozione degli standard web
• si offre di convertire il vostro sito (brutto, retrò, sbagliato), in uno migliore (bello, standard, accessibile)
• ha partecipato alla stesura di uno standard web
• ha un sito di poche pagine (e purtroppo solo quello), realizzato in modo conforme agli standard, e lo usa come pretesto per diffondere il verbo degli standard web

Non solo: con tutta probabilità questo signore poco ne capisce della complessità di un progetto web, poiché ha visione solo di una parte, il suo lavoro: creare pagine Html.
Come potete ben immaginare la sua opinione, per quanto del tutto rispettabile e in certi termini condivisibile, è superficiale. Non c’è nulla di male nel promuoversi al ruolo di esperto nel campo degli standard, ma la realtà con cui si confronta chi realizza siti web è più complessa di quello che normalmente si crede.

Gli standard web sono una buona cosa, ma la loro adozione deve essere attentamente valutata, così da capirne l’impatto e i benefici che possono introdurre. Non solo, ogni sito è un caso a parte: lo standard che ben si presta in un’occasione, potrebbe introdurre benefici ridicoli in un’altra, tanto da sconsigliarne l’uso.

È comodo tifare per chi vuole adottare gli standard web a tutti i costi, ma non stiamo guardando una partita di calcio, stiamo lavorando.

Capita spesso di incontrare siti in cui l’autore si diverte a convertire siti esistenti non standard in versioni Xhtml e Css, così da dimostrare ai più scettici che è possibile non solo ottenere lo stesso risultato con gli standard, ma addirittura migliorarlo. L’esercizio è molto utile ai fini didattici, ma è un esercizio. In realtà queste operazioni, che molte volte interessano solo la home page, sono del tutto fuorvianti.

Come vedremo tra poco, la pagina che vedete sul vostro browser è il risultato di un numero a volte elevato di processi e trasformazioni. Fermarsi ad analizzare solo l’ultimo passo, quello che interessa il browser, è indice di miopia. Alcuni dei siti che notiamo non essere standard non lo sono per ignoranza, ma per le difficoltà (inclusi tempi e costi) incontrate nel modificare parti del sito che si trovano ben più a monte rispetto alla pagina che riceve il browser. Non è solo un problema di Html.

Un mezzo, non un obiettivo

Gli standard web non sono un santo a cui votarsi, non si presta opera di fede incondizionata senza aspettarsi un ritorno pratico e immediato, che abbiamo definito essere una maggiore produttività unita a un livello qualitativo adeguato. Adottare i più disparati standard web solo per fregiarsene a piè di pagina rischia non solo di essere pacchiano, ma addirittura controproducente.

In dipendenza del tipo di sito da realizzare, infatti, alcuni standard sono più adatti di altri. Per questo motivo è anche inutile proporre sterili liste congratulandosi con i siti che hanno compiuto il grande passo, da sito a tabella con codice non standard a foglio di stile per il layout e codice standard compliant. Ogni sito è diverso, l’equazione “sito costruito secondo gli standard = sito migliore” non funziona, ma va analizzata caso per caso.

È inoltre fuori discussione che l’utilizzo gli standard web nella costruzione di un sito può aiutare a migliorarne l’accessibilità e l’usabilità. Ma si tratta di una condizione che non è né necessaria, né sufficiente. Posso infatti creare un sito completamente aderente agli standard, ma frustrante per chi lo utilizza e tutt’altro che accessibile, come posso realizzare un sito a tabelle realmente usabile e accessibile.

Se il vostro obiettivo è costruire un sito usabile o accessibile state quindi attenti: rischiate di gettarvi a capofitto nella codifica del sito quanto il vostro problema sta a monte. Non solo, tenete presente che come abbiamo avuto modo di dire in altra sede, l’accessibilità di un sito ha un ciclo di vita che comincia con l’analisi dei requisiti.

Quali standard usare

Abbiamo detto che gli standard non sono ricette preconfezionate da consumare sempre e ovunque. La scelta degli standard da adottare è invece il frutto di un’attenta analisi, e dipende da numerosi fattori:

• Dipende dagli obiettivi
  • Quali sono gli obiettivi aziendali e quelli degli utenti? Esistono degli standard che possono aiutare ad incontrare queste aspettative?
  • Quali benefici possono portare questi standard nell’immediato?
  • Quali benefici possono portare questi standard nel medio/lungo periodo?
• Dipende dai limiti
  • Il tempo (e quindi il costo) necessario per utilizzare lo standard
  • Le controindicazioni e i compromessi nell’adottare lo standard (funzionalità che si vengono a perdere o modificare)
  • Limiti della tecnologia
    • Sistemi automatici o semiautomatici (es. Cms) che non producono codice standard
    • Parti del sito che non sono in nostro controllo (es. Banner), e che quindi potrebbero non essere standard-compliant
  • Limiti del contenuto, come contenuti pregressi da convertire
• Dipende dal tipo di sito
  • Sito web
  • Applicazione web

Tutt’altro che impiegare una scatola chiusa, quindi. Da questo elenco è facile capire come la decisione se e come adottare uno standard web non riguarda necessariamente (anzi, quasi mai) solo chi si occupa di realizzare il template delle pagine (Html e Css), ma coinvolge l’intero team di sviluppo. Ecco perché la bontà di un sito web riguardo l’aderenza agli standard non può mai essere valutata “a distanza”, se non in casi idilliaci.

Prendere e criticare un sito web senza conoscerne le complessità e peculiarità è senza dubbio comodo, ma non aiuta chi l’ha realizzato a migliorarlo. Il numero di fattori che influenzano la scelta può infatti essere di tale portata che quello che si vede “sullo schermo” non è sufficiente per esprimersi in una critica costruttiva.

Nell’ultimo punto della lista si parla di differenza tra sito web e applicazione web. Cosa vuol dire, o meglio, cosa intendiamo per sito e applicazione web?

Per lo scopo di questa discussione un sito web è un insieme di pagine realizzate da una persona o da un piccolissimo team di persone, ognuna con competenze che spaziano dalla realizzazioni di pagine Html alla programmazione (senza raggiungere livelli estrema). Il risultato è solitamente un sito di modeste dimensioni, con nessun aggancio ad altre realtà (Cms, applicazioni legacy, database, ecc.). In questa categoria, come dicevamo all’inizio, rientrano i siti vetrina.

Un’applicazione web è invece, alla stregua di un programma per computer, un prodotto di ingegneria. In questo caso la distinzione tra le competenze del team di sviluppo è più marcata (ma non netta, questo non lo deve mai essere). In questo caso, più che per pagine, si ragiona per template. Ogni template può produrre più pagine con lo stesso look & feel, ma dal contenuto anche profondamente diverso. Generalmente, ma non è una regola, un’applicazione web è composta da un sito dinamico (collegato ad un database) e ad un certo numero di moduli (community, ecommerce, ricerche) sviluppati come veri e propri prodotti software. In questo caso il browser che riceve la pagina è l’appendice di tutto il processo dell’applicativo. È un po’ come un iceberg: quello che spunta dall’acqua è quello che vede il browser: una piccolissima parte di quella che in realtà è tutta l’applicazione.

Va notato come non usiamo il termine sito “statico” in paragone a “dinamico”, in quanto l’enfasi non è sul risultato del lavoro (posso avere siti complessi e statici, e siti composti di due pagine dinamici), ma sulle competenze richieste per portarlo a compimento e soprattutto sulla complessità del progetto.

In che modo l’adozione degli standard viene influenzata dal tipo di progetto (applicazione o sito web) che intendiamo realizzare? In realtà, più complesso e spaziato è il progetto che andiamo a realizzare, più ampia è la rosa degli standard che possiamo impiegare. Non solo, all’aumentare della complessità del progetto, si riduce il peso che il browser ha all’interno di tutta l’applicazione.

Attenzione: questo non vuol dire che possiamo inviare al browser pagine non standard, senza preoccuparci della resa visiva, tutt’altro. Vuol però dire che la trasformazione e presentazione dei contenuti non deve per forza di cose avvenire sempre e comunque lato browser, ma può essere realizzata a monte ricorrendo ad altri standard, che hanno il pregio di essere completamente slegati dalla periferica di output, e generalmente più potenti.

Non credete a chi vi dice che le stesse operazioni possono essere compiute dal browser, che non ha senso caricare inutilmente i server per problemi di prestazioni: l’hardware non è quasi mai un problema. Probabilmente chi si rifiuta di sfruttare la potenza dei server semplicemente non lo sa fare.

Gli standard caso per caso

Può sembrare strano, ma anche l’efficacia di uno standard varia in relazione al contesto nel quale viene applicato. Vediamo in che modo con un paio di esempi.

Il sito vetrina di un’azienda di abbigliamento sportivo

Immaginate di essere coinvolti nello sviluppo di un sito vetrina, con alcune pagine di presentazione di un’azienda e un elenco prodotti rivolti al pubblico giovanile.

Una tra le possibili soluzioni è quella di impiegare Xhtml Strict per la codifica delle pagine e i Css per la costruzione dell’intero sito. La scelta è condivisibile. Benché esistano dei limiti alla soluzione, questi sono facilmente superabili, mentre i vantaggi sono evidenti:

• separare lo strato di presentazione dal contenuto, così da consentire in futuro il recupero del contenuto senza dover intervenire manualmente
• rendere più facile e immediata la modifica del layout (come spostare velocemente le barre di menù e la navigazione
• possibilità di inviare lo stesso contenuto a dispositivi diversi (come personal computer,cellulari e palmari)
• coerenza visiva delle diverse sezioni del sito
• diminuire il peso della pagina

Il sito di una rivista online

Immaginate adesso di dover realizzare un sito per un’importante rivista, dove sono caricati giornalmente 20 articoli. Sono inoltre presenti una vetrina per abbonarsi e un’area di community precedentemente utilizzati per un’altra rivista del gruppo.

Non pretendiamo che da soli siate in grado di realizzare tutto il sito, quello che è interessante capire è che in questo caso la realizzazione delle pagine è solo una parte (per quanto importante) dell’intero processo.

Se cominciate subito a realizzare template Xhtml, fogli stile e menù di navigazione non siete sulla buona strada. In realtà quello che avete bisogno di capire è che cosa avete a disposizione per lavorare, cercando di capire:

• da dove saranno prelevati i contenuti
• in che formato sono
• a quali piattaforme si rivolge il sito (computer, palmari, ecc.)
• quali devono essere le funzionalità degli altri servizi

Anche per un sito statico avete bisogno di sapere queste cose, ma in questo secondo caso la produzione dei contenuti entra a pieno titolo nel processo di realizzazione del sito web, e dovete conoscere perfettamente il suo funzionamento.

Per questo secondo progetto potremmo decidere di comportarci in modo diverso rispetto al sito vetrina, e infatti codifichiamo il sito utilizzando Xhtml transitional per le pagine e i fogli di stile unicamente per i caratteri, i colori e i margini.

Potremmo pensare che abbiamo agito in modo non corretto: perché non usare i Css anche per il posizionamento, dopo tutti i vantaggi che abbiamo elencato e visto che la costruzione del sito parte da zero?

La scelta non è legata ai problemi di compatibilità dei fogli di stile: questi infatti sono normalmente visualizzati con molti limiti nei browser non recenti. In effetti, trattandosi di business, l’azienda che ha commissionato il sito vorrebbe mantenere il bacino di utenza il più ampio possibile. Però ripetiamo: questa non è la causa della nostra decisione.

Per capire il perché di questa scelta, analizziamo come avverrà il processo di pubblicazione del sito. I redattori utilizzano un sistema di gestione dei contenuti (Cms) che gli consente di redigere gli articoli da pubblicare, inserendo non solo il corpo, ma il titolo, sommario, occhiello, le foto, riferimenti ad articoli correlati, ecc. Gli articoli sono memorizzati in un database in un formato Xml.

Ecco che siamo giunti al cuore della questione: esiste uno standard non legato direttamente al sito e che viene utilizzato per memorizzare le informazioni da pubblicare. Questa informazione è a fondamentale per capire quali standard utilizzare per strutturare il sito.

D’accordo con il team di sviluppo software, la soluzione proposta è la seguente:

• realizzare i template in formato Xhtml, suddividendo le pagine in diverse parti a seconda delle esigenze
• i menù e le barre di navigazione saranno realizzati in parte autonomamente, in parte manualmente secondo necessità, e la redazione sarà in grado con pochi clic di spostarli da una parte all’altra dello schermo
• trasformare i template Xhtml in documenti Xslt, che verranno usati per trasformare il dato Xml dell’articolo nella pagina da inviare

In questa nuova ottica, sono anche ridimensionati i vantaggi della soluzione adottata per il sito vetrina. Rivediamoli sotto questa nuova luce:

separazione lo strato di presentazione dal contenuto

Separare la presentazione dal contenuto rende più semplice la manutenzione della pagina. Ma il vero problema è: dove finisce il contenuto e dove comincia lo strato di presentazione? Nel caso più semplice, quello precedente, il contenuto era rappresentato dalla pagina Xhtml e la presentazione dal file Css. In questo secondo caso, però, la visuale è cambiata. Tutti i contenuti provengono da un sistema per la gestione dei contenuti (Cms).

La presentazione è ora data dal template, che verrà opportunamente riempito dai dati provenienti dal database. Vi ricordate il discorso che facevamo poco fa a proposito dell’iceberg? In questo secondo caso potremmo dire che per noi lo strato di presentazione è l’intero flusso diretto al browser, mentre il contenuto è quanto presente nel database. Nel database e nel formato Xml lo strato di presentazione è già totalmente separato dal contenuto, tanto che lo stesso articolo potrebbe finire non solo nel sito, ma anche sulle pagine cartacee della rivista.

personalizzazione del look & feel per l’utente

Con i Css è possibile aiutare l’utente a modificare velocemente la presentazione del sito. Nel primo caso questo si spinge fino al posizionamento, mentre nel sito della rivista esiste comunque la possibilità di modificare font, colori e margini. Questo non vuol però dire che i redattori non abbiano questa possibilità: per come sono stati strutturati i template, infatti, la personalizzazione avviene interamente utilizzando il sistema di pubblicazione, tanto che i componenti possono essere in qualunque posizione, possono essere comuni a tutto il sito, oppure solo ad una sezione, senza intervenire minimamente sul codice. E utilizzando delle trasformazioni Xsl, anche cambiare il layout è estremamente semplice.

possibilità di inviare lo stesso contenuto a dispositivi diversi

Certo è vero, con i Css è teoricamente possibile servire un maggior numero di dispositivi. Tutto bene fin che si tratta di browser, ma provate ad immaginarvi mentre leggete la pagina di un sito in un monitor grande come il display di un cellulare. Non basta presentare l’informazione in modi alternativi, ma essere in grado di trasformarla (anche ridurla). Nel nostro caso, al browser verrà inviato l’intero articolo, mentre al cellulare solo il titolo, il sommario e un abstract.

Nessun problema comunque: abbiamo infatti scelto di adottare lo standard Xsl e quindi, con semplicissime trasformazioni riusciamo a rendere disponibili diverse interfacce di fruizione. Non solo, mentre con i Css possiamo variare la presentazione, ma il contenuto rimane lo stesso (possiamo al limite cercare di nasconderlo), con opportune trasformazioni l’utente può decidere quali informazioni ricevere, e in che ordine. Riusciamo quindi non solo a presentare in modi diversi le informazioni con documenti Xslt diversi, ma anche a filtrarle in modo da presentare ad un palmare solo la versione essenziale, al posto di quella completa.

coerenza delle diverse sezioni del sito

I Css sono lo strumento migliore per garantire una coerenza visiva all’interno del sito. Anche l’attenta creazione di un template a tabella può però produrre gli stessi risultati. Se la pagina è ben definita e studiata, ad esempio, è possibile suddividerla in più porzioni (include) indipendenti l’una dall’altra, tenute insieme da una semplice struttura a tabella. Il vantaggio di questa soluzione è duplice:

• la modifica a un include si ripercuote su tutto il sito
• il team di sviluppo può suddividersi le parti di lavoro (include di ricerca, menù, contenuto, ecc.)

diminuire il peso della pagina

Qui c’è poco da fare: se usate correttamente ed efficacemente i fogli di stile per il posizionamento degli elementi, il peso della pagina è sicuramente minore rispetto al corrispettivo in tabella. Usare i Css per il testo e il colore partecipa a rendere la pagina più leggere, ma il risultato non sarà comunque paragonabile. Attenzione però a non legare il peso della pagina con la velocità di visualizzazione nel dispositivo ricevente: i due elementi sono correlati, ma un sito ben realizzato può essere percepito come veloce anche se il peso della pagina è elevato.

A queste considerazioni va anche aggiunto che la gestione dei fogli di stile da parte degli odierni browser è deficitaria, tanto da richiedere accorgimenti e trucchi anche nei casi di template mediamente complessi. Questo non vuol dire che va scoraggiato l’uso dei fogli di stile per il posizionamento (anche perché le sorprese tra diversi browser non manca neppure nei layout a tabella), ma che nel caso di siti di alta complessità, la prima preoccupazione dev’essere quella di memorizzare correttamente l’informazione da produrre. Fatto questo, possiamo presentare questa informazione a chiunque intervenendo semplicemente nei fogli di trasformazione. Il che vuol anche dire che domani, quando uscirà la versione 8 delle specifiche per i Css o di Xhtml, saremmo pronti ad usarli con poco sforzo.

Quello che abbiamo visto è solo un esempio, che prende in esame i fogli di stile e lo standard Xhtml. In realtà la stessa situazione sarebbe replicabile in altri ambiti con le stesse conclusioni: prima di applicare uno standard è bene conoscere le realtà nel suo complesso.

Conclusione

Chi realizza pagine web non lavora in solitaria. Le soluzioni che propone, non solo dal punto di vista grafico, ma anche di standard adottati, dipendono dal contesto nel quale opera. Con due semplici esempi abbiamo visto come l’impiego degli standard web vada attentamente valutato in base al sistema di produzione dei contenuti, nonché dell’audience e delle aspettative degli utenti.