HTML, XHTML, CSS e JavaScript - Le basi

Incominciamo dal browser

Non importa se si chiama Microsoft Internet Explorer, Mozilla FireFox o Pinco Pallino: il browser è quel programma che, in un modo qualsiasi che qui non ci interessa considerare, riceve da un server un file di testo; ne legge il contenuto; ne interpreta il contenuto stesso in modo da individuarne quelle parti che fungono da codici di controllo su come presentare sul monitor il documento; identifica eventuali altri file aggiuntivi, come le immagini, che gli servono per costruire la pagina; richiede al server questi file; e finalmente presenta sul monitor la pagina.

Questa descrizione è talmente rudimentale da essere quasi offensiva per chi sa quanto in realtà siano complicate le cose, cionondimeno la ritengo sufficiente per affrontare i contenuti di questo capitolo.

Ad esempio, il titolo di questa sezione della pagina è costituito dalla seguente successione di caratteri:

<h2>Incominciamo dal browser</h2>

il gruppo iniziale di quattro caratteri <h2> costituisce il codice di controllo — tag — che indica al browser che inizia un titolo — heading in inglese — di secondo livello, il gruppo finale di cinque caratteri </h2> indica che il titolo è finito. Nient'altro da dire. Stop. Basta così.

Beh, non è proprio vero che non c'è nient'altro da dire, in tal caso potrei fare a meno di scrivere questo capitolo, però questa è la sostanza delle cose: tutto ciò che fa un browser è interpretare un file di testo, cioè un file composto unicamente da caratteri come "A", "a", "2" o "," e pochi altri, decidere cosa deve essere considerato "parole da leggere", cosa codici di controllo su come presentare le parole stesse — ad esempio il colore, il tipo di carattere e le dimensioni — e cosa codici di controllo per quegli elementi, accessori ma importantissimi, come le immagini, i link, i filmati in Flash e altro ancora. Dopo di che scarica dalla rete i file con le immagini e altre cose che gli servono e, finalmente, presenta la pagina sul monitor, sperabilmente come l'autore della pagina desiderava fosse presentata.

Ho scritto sperabilmente perché, per riuscire nel suo compito, il browser deve essere in grado di interpretare correttamente ed univocamente i codici di codifica della pagina e nel momento in cui scrivo, nessuno dei browser disponibili rispetta perfettamente quest'esigenza fondamentale. Anche i più aggiornati ed evoluti presentano piccole differenze nell'interpretazione e/o nell'impaginazione, a volte veramente minime, a volte più significative: ne parlerò di nuovo più avanti.

Il paragrafo subito sopra è stato scritto nell'aprile 2011, oggi, febbraio 2013, le cose, per fortuna, sono cambiate sufficientemente in meglio e stavo per cancellarlo, poi ho ripensato ad alcuni dei controlli con i vari browser che ho dovuto fare negli ultimi giorni su questo stesso sito e l'ho lasciato, perché, anche se con effetti minori del passato, il problema persiste.

La codifica HTML - HyperText Markup Language

Innanzitutto occorre chiarire che non è un linguaggio, cioè una codifica, di programmazione, ma che è una codifica di presentazione e di impaginazione del testo, testo che poi può essere ampiamente corredato di immagini e di altri elementi accessori, opportunamente disposti nella pagina.

E, soprattutto, è un linguaggio nato per gestire la struttura logica di un documento: i titoli e sottotitoli di diverso livello, i paragrafi, le liste, le tabelle e molti altri elementi HTML, chiamati, come ho già detto, tag.

Come ho scritto nel capitolo "Estetica, usabilità e accessibilità dei siti web", originariamente l'autore di una pagina web non aveva la possibilità di scegliere come presentare le proprie pagine, cioè di cambiare i colori del testo, i font usati o le dimensioni dei caratteri, mentre queste funzionalità erano — moderatamente, assai moderatamente — disponibili nella configurazione del browser usato da ogni navigatore. Però, se si sceglieva un particolare font per visualizzare il testo, ogni documento, qualsiasi ne fosse il contenuto, sarebbe stato impaginato con quel particolare font e la stessa cosa accadeva dopo la scelta di un colore per il testo o lo sfondo.

Quindi, sin dai primi tempi del web, vennero aggiunti dei tag particolari come i seguenti:

<b>Queste parole sono scritte in grassetto <i>corsivo</i></b>

Queste parole sono scritte in grassetto corsivo

dove <b> e </b> indicano l'inizio e la fine della porzione di testo da mostrare sullo schermo, o da stampare, in grassetto — bold in inglese — mentre <i> e </i> — italic in inglese — annidati nel tag precedente, specificano che la parola "corsivo", oltre che in grassetto, deve anche essere in corsivo.

Queste nuove codifiche — unicamente presentazionali — davano la possibilità all'autore della pagina di definire come doveva essere mostrata sullo schermo la pagina stessa. Di conseguenza le pagine incominciarono ad essere sempre più complesse e arzigogolate, con effetti estetici a volte decisamente pacchiani e con pesanti difficoltà di interpretazione della codifica da parte dei diversi browser disponibili sul mercato che si rivelava sotto forma di forti differenze nella presentazione della stessa pagina. Inoltre, l'introduzione di tag destinati al controllo della presentazione, toglieva al linguaggio HTML la sua caratteristica fondamentale di descrizione della struttura logico-semantica di un documento, per farne un ibrido poco soddisfacente.

E adesso tieniti forte: lo standard HTML ha preso la sua forma definitiva nel 1998 con la major release  HTML4.0, leggermente modifica nel 2001 con la versione 4.01.

Da oltre quindici anni non sono state più apportate significative variazioni, ufficiali e definitive, allo standard del linguaggio con cui sono realizzate le pagine web.

Ciò non significa che le cose non siano cambiate — e di moltissimo — ma che i cambiamenti hanno preso strade parallele.

I fogli di stile - C(ascading) S(tyle) S(heets)

Nei primi anni '90, mentre da un lato i produttori di browser — Microsoft e Netscape — inserivano ognuno nuovi, e fra di loro incompatibili, tag presentazionali nelle varie edizioni dei loro programmi, la comunità internazionale degli studiosi proponeva un metodo alternativo per la presentazione a video delle pagine web, che tornasse a separare la codificazione logica del contenuto da quella grafica.

I Cascading Style Sheets sono troppo complessi perché possa entrare in dettagli, faccio solo un esempio:

h2 { color: green; font-weight: bold; }

questa istruzione, opportunamente posta nel codice della parte inziale della pagina web, fa sì che tutti i titoli di secondo livello della pagina vengano presentati in grassetto ed in colore verde scuro. Prima dei CSS ogni titolo doveva essere codificato singolarmente, rendendo le pagine molto più pesanti in termini di byte da far viaggiare in rete e molto più complicate da realizzare: da quel momento, se si decide di cambiare il colore dei titoli da verde a rosso, basta sostituire in un unico punto della pagina "green" con "red" e il gioco è fatto.

Ma c'è di più e di meglio: tutte le informazioni che codificano le modalità di presentazione di una pagina possono essere salvate in un file esterno alla pagina stessa — il foglio di stile appunto — che il browser scaricherà dal server dopo aver analizzato il file — si tratta proprio di una di quelle "altre cose che gli servono" di cui ho scritto più sopra. E non basta: lo stesso foglio di stile può essere collegato a tutte le pagine del sito internet, che abbiano le stesse esigenze di presentazione, poco importa se queste pagine sono cinque o cinquemila.

I vantaggi nella realizzazione e, soprattutto, manutenzione di un sito sono evidenti. Se, terminato il sito, vuoi provare l'ebbrezza di vedere tutti i titoli di secondo livello delle tue enne-mila pagine in un bel color rosa maialino invece che in verde scuro, lo puoi fare modificando un'unica istruzione e, dopo essere inorridito, puoi tornare indietro altrettanto rapidamente.

Nel dicembre 1996 il World Wide Web Consortium di Ginevra (W3C)  emetteva sotto forma di raccomandazione le specifiche CSS1. Peccato che i browser disponibili sul mercato in quel momento — praticamente solo Microsoft Internet Explorer e Netscape Navigator — non fossero in grado di interpretarle.

La raccomandazione venne recepita subito, era un'idea troppo buona, e le edizioni successive dei due browser utilizzavano i CSS. Peccato, di nuovo, che ognuna lo facesse a modo suo, esattamente come era successo con i tag presentazionali solo un paio di anni prima, e, se possibile, con ancori maggiori differenze nella resa delle pagine.

Le cose migliorarono leggermente con l'emissione delle specifiche CSS2 nel 1998, in compenso sia i committenti sia gli sviluppatori, incominciarono a chiedere sempre di più alle possibilità estetiche nelle realizzazione dei siti internet e allora incominciarono le vere grane.

Sino a pochi anni fa, era abituale leggere sulla home page di molti siti web frasi più o meno criptiche come:

Best vision with MS Internet Explorer ≥ 5.5 - Ris. 800x600 - 65k col.

e, infatti, se si navigava sul sito con Netscape o con una versione precedente del browser di Microsoft, o se la risoluzione dello schermo era minore o maggiore di quella consigliata, molte volte le pagine diventavano, non dico illeggibili, ma distorte e pasticciate.

Sovente questi problemi di visualizzazione erano frutto di errori o di ingenuità nella codifica da parte di chi realizzava la pagina, ma in molti casi, se le esigenze estetiche e di comunicazione del committente lo richiedevano, era necessario realizzare siti internet strutturati in modo da fornire ai visitatori sottositi diversi a seconda del browser usato. Ad esempio, il Gruppo Fiat realizzava tre o quattro versioni separate dei siti di presentazione dei nuovi modelli, in modo da ottenere gli stessi effetti estetici qualsiasi fosse il browser che interpretava le pagine.

Per essere precisi la maggior parte dei problemi nascevano dalla scorretta e incompleta implementazione delle specifiche CSS da parte di Microsoft, che solo con Windows Internet Explorer 9 si è adeguata ai concorrenti. Va notato però che il suo browser ha dominato il mercato, con punte superiori al 90%, almeno sino al 2005-2006, pertanto, in quel periodo, chiunque progettasse e realizzasse un sito internet doveva preoccuparsi soprattutto che tutto funzionasse bene con Explorer, stando attento ad ottimizzare il codice affinché non si comportasse troppo male con le vecchie versioni del programma o con Netscape e, successivamente, Opera e FireFox.

E adesso tieniti forte di nuovo: dal 1998 sino al 2011 non sono state più apportate variazioni ufficiali e definitive allo standard dei CSS, in quanto le specifiche CSS2.1, la cui evoluzione è iniziata alla fine dello scorso millennio, hanno raggiunto lo stato di Raccomandazione da parte del W3C solo nel mese di giugno di quell'anno.

Vedremo più sotto come le specifiche CSS3 stanno cambiando le cose, per il momento passo ad analizzare una strada parallela che lo sviluppo del web aveva preso per una dozzina d'anni.

La codifica XHTML - eXtensible HyperText Markup Language

L'altra fonte di problemi era costituita dagli errori di codifica commessi dagli sviluppatori entusiasti ed improvvisati che, soprattutto nei primi anni frenetici dello sviluppo del World Wide Web, immisero in rete un enorme quantitativo di pagine internet scritte malissimo. Qualsiasi browser doveva essere in grado di presentarle sul monitor in qualche modo, anche se piene di errori tragici, e per farlo doveva cercare di indovinare le intenzioni dello sviluppatore, e quando si tira ad indovinare...

Provo a descrivere la situazione con un'ardita metafora: un browser — quelli di quindici anni fa come i più moderni oggi disponibili — è in grado di cucinare una pietanza con praticamente qualsiasi cosa gli si metta in pentola, ma la qualità del risultato dipende ovviamente dalla qualità degli ingredienti e, soprattutto, dall'esistenza o meno di una ricetta da seguire.

Il nòcciolo della questione sta proprio nella "ricetta", cioè nel fornire al browser informazioni certe sulle intenzioni dello sviluppatore della pagina, intenzioni che sovente restano al livello di "buoni propositi" ma che, se indicate, consentono al browser di identificare tutte quelle parti del codice prive di errori formali e di costringerlo a "tirare ad indovinare" solo nei casi dubbi. In effetti più che una "ricetta" il browser riceve informazioni sullo stile adottato dal cuoco: cucina eclettica, cucina americana, cucina svizzera; interrompo qui la metafora, che non è stiracchiabile oltre, spero però che si capisca che è possibile indicare al browser criteri più o meno rigidi di interpretazione del codice.

L'eXtensible HyperText Markup Language è proprio un tentativo di rendere più rigida l'interpretazione del codice da parte dei browser e, di conseguenza, di costringere gli sviluppatori a realizzare pagine in aderenza allo standard.

Peccato che... e qui inizio la lista dei peccati, lista breve ma significativa:

• Con l'inizio lavori nel 1998, XHTML 1.0 è diventato una Raccomandazione del W3C nel gennaio 2000 e la successiva e ultima revisione ufficiale XHTML 1.1 è del maggio 2001. Sono passati dodici anni ma, nonostante la gran mole di lavoro successivamente svolta, la prevista maggior revisione 2.0 non è mai stata completata. E per un buon motivo.
• XHTML è un linguaggio rigido e severo, anche se all'apparenza praticamente identico all'HTML, che nasce per consentire l'accesso a TUTTE le informazioni di una pagina web a  dei programmi, non solo a dei lettori umani. Il rispetto delle regole deve — dovrebbe — essere assoluto, altrimenti la risposta del browser potrebbe essere più o meno la seguente: "Quel cretino che ha composto la pagina ha commesso un microscopico errore del tipo X1Y2Z3, quindi non ti faccio vedere proprio niente, nemmeno le parti perfettamente codificate, e non ti spiego in termini umani qual è l'errore, perché tanto non lo capiresti".

Ecco cosa è successo: i produttori di browser si sono semplicemente rifiutati di andare in una direzione così penalizzante, sia per gli autori sia per i navigatori di un sito web, tanto, se c'è realmente la necessità di passare informazioni strutturate ad un programma, esiste la codifica XML, che lo consente e dalla quale XHTML traeva tutte le sue rigidità.

Ho scritto "traeva tutte le sue rigidità" perché, di fatto, XHTML è un ramo morto, senza un futuro prevedibile.

Il linguaggio di programmazione JavaScript

Tieni duro, caro lettore, perché c'è ancora solo un argomento prima di passare alle conclusioni di questo capitolo, indispensabile ma così lungo e, temo, così poco digeribile.

Questo è un vero linguaggio di programmazione, non di definizione della struttura logico-semantica di un documento come l'HTML o di formattazione della pagina come CSS. Ci sono indubbiamente strumenti di sviluppo molto più adatti per questo scopo, ma niente vieterebbe di usare JavaScript per realizzare un programma di contabilità.

Sul web è usato soprattutto per consentire l'interazione del navigatore con i componenti della pagina, ad esempio per la validazione dei dati inseriti nei moduli e per generare effetti speciali, a volte utili come menù a tendina complessi, a volte molto meno utili perché unicamente decorativi.

Sarebbe necessario dare molti altri dettagli ma non credo proprio che siano fondamentali per i destinatari di questo mio sito internet, per come li ho definiti nel capitolo "Gli scopi di questo sito internet ", c'è però un'informazione indispensabile da aggiungere.

Qualsiasi errore in un programma JavaScript ne arresta l'esecuzione, ad esempio, basta una minima imprecisione ortografica come scrivere — qualsiasi cosa ciò significhi — "getElementByid" invece di "getElementById" — la "i" è minuscola invece che maiuscola — per rendere inutilizzabili decine o centinaia di righe di codice scritte perfettamente. E in molti casi un evento del genere toglie funzionalità estetiche o di comunicazione fondamentali per il corretto uso della pagina.

Mi dirai che scrivere codice senza errori è compito dei programmatori, che sono pagati apposta, ma la buona programmazione richiede tempo e, soprattutto, costa e in molti casi i problemi vengono, come al solito, da sfumature della diversa implementazione del linguaggio sui diversi browser, compresi disgraziatamente i più moderni ed aggiornati.

È opportuno quindi usare solo il minimo indispensabile di programmazione JavaScript nelle proprie pagine, in base al solido principio: "Tutto quello che non c'è non si rompe e, soprattutto, non si deve pagare".

Anche qui, a febbraio 2013, devo fare un sostanzioso aggiornamento ai paragrafi che hai appena letto: tutto quanto ho scritto sopra è ancora perfettamente vero, compresa la battuta finale sui costi di JavaScript. Ciò che è radicalmente cambiato è la misura di quel "minimo indispensabile" a cui facevo riferimento.

La necessità di rendere fruibile un sito web sui dispositivi mobili, smartphone e tablet, e quindi di progettarlo secondo i principi del Responsive Web Design, obbliga ad usare con precisione ed accuratezza JavaScript per ottenere alcune funzionalità indispensabili in quel contesto. Queste funzionalità, però, non sono quelle di tipo puramente decorative di cui si faceva, e si fa,  abuso in molti casi: servono a garantire la corretta visione del sito su schermi di ogni dimensione e con tutte le versioni di MS Internet Explorer a partire dalla 6.0, e in questo sito sono ampiamente usate.

Cosa diavolo hanno fatto allora negli ultimi dodici anni?!

Questa domanda sorge inevitabile, se si riflette sul fatto che per un lasso di tempo lungo oltre dieci anni non sono state ufficializzate novità significative negli standard di sviluppo, ebbene negli ultimi dodici anni sono successe molte cose che, però, hanno preso concreta applicazione solo nel 2012, restando prima quasi solo a livello di "buone intenzioni".

È stata preparata la revisione CSS3 dei fogli di stile, come naturale evoluzione di CCS2 e CSS2.1, essa, a differenza delle precedenti versioni, non è un corpo unico, ma è divisa in numerosi moduli, solo alcuni dei quali hanno raggiunto lo stato di "raccomandazione" da parte del W3C. In generale CSS3 — almeno nelle sue parti più utili — è supportato piuttosto bene dalle ultime versioni di tutti i browser, compresi MS IE9 e MS IE10, ma non è quasi per nulla implementato nelle precedenti versioni di MS IE.

È stata preparata la bozza — draft — di HTML5 come successiva di HTML4 e sostitutiva di XHTML2, che non vedrà mai la luce. HTML5 aggiunge molte fantastiche novità allo standard e tornerà a rendere più facile lo sviluppo dei siti, in compenso non sarà supportato dalle vecchie versioni dei browser di Microsoft ancora in circolazione, fortunatamente è possibile aggiornarne il comportamento usando le complesse applicazioni JavaScript a cui ho fatto cenno più sopra.

Uniti insieme, HTML5, CSS3 e le librerie di applicazioni JavaScript come jQuery, consentono prestazioni tecniche ed estetiche formidabili. In particolare hanno consentito di sviluppare nel 2012 i principi del Responsive Web Design, a cui ho dedicato l'omonimo capitolo di questo manuale che ti ti invito caldamente a leggere, se ti interessa sapere come rendere fruibile e navigabile — con costi accettabili — il tuo sito web sia sui dispositivi fissi, di casa e di ufficio, sia su quelli mobili, smartphone e tablet.

È in bozza un capitolo tecnico, proseguimento di questo lunghissimo che hai appena finito di leggere, in esso cercherò di fornirti qualche indispensabile dettaglio sui problemi da affrontare per realizzare un sito "responsive".

---

Se hai trovato utile questa pagina, potrebbero interessarti anche:

• Estetica, usabilità e accessibilità dei siti web
• Creare un'home page efficace per il tuo sito
• A chi serve un sito web fatto con Flash
• L'uso delle immagini nei siti web
• Bibliografia (molto) ragionata

Se desideri essere informato sulla pubblicazione di nuovi capitoli, puoi iscriverti alla newsletter, sarai sempre libero di cancellarti dalla mailing-list se quanto scrivo non ti piacerà.