Guida HTML5 - Prima Parte - "Le Basi"

Una guida operativa

Affrontare un tema vasto come quello dell'HTML5 spaventa sempre un po', soprattutto quando l'obiettivo è quello di abbracciare l'intera tecnologia sottostante le specifiche proponendo al contempo un'opera che sia fruibile e divertente da leggere. Il primo passo che abbiamo deciso di compiere nella stesura di questo progetto è stato individuare il target di lettori ai quali la guida vorrebbe rivolgersi. Abbiamo allora identificato da un lato un gruppo di sviluppatori interessati alla consultazione di specifiche referenze del linguaggio, dall'altro un insieme di lettori desiderosi di informarsi a tutto tondo sulle novità offerte dall'HTML5. A questa commistione di interessi si aggiunge una naturale segmentazione della guida secondo i due temi che maggiormente permeano le specifiche: il nuovo approccio semantico nella creazione di pagine web e il ricco set di API reso disponibile.

Il percorso si snoda in modo organico tra le due macro-sezioni alternando lezioni di stampo divulgativo, ottime per avere una visione di insieme della tematica trattata, a percorsi verticali costruiti attorno a funzionalità specifiche. Non sono previsti articoli introduttivi alla sintassi del linguaggio HTML e nemmeno approfondimenti su elementi o API già presenti nelle versioni precedenti, a meno che questi non abbiano subito un cambio radicale; se fosse necessario recuperare informazioni su tali aspetti rimandiamo alla lettura della guida HTML 4 redatta da Wolfgang Cecchin.

I progetti guida

Per questa guida abbiamo deciso di combinare i tanti piccoli esempi dedicati ad ogni lezione in un vero e proprio progetto che sappia anche mostrare come le singole funzionalità HTML5 lavorano insieme.

In realtà i progetti sono due, come due gli aspetti principali di questa specifica: al termine delle lezioni legate al nuovo supporto semantico dell'HTML5 la combinazione dei vari esempi mostrati darà vita ad un template per blog studiato per trarre vantaggio da elementi come <section> e <article>, dai nuovi content model e dalle novità in materia di form. La parte incentrata sulle API dedicate allo sviluppo di applicazioni web invece includerà tutti gli elementi necessari alla stesura di una lavagna virtuale sulla quale si potranno tracciare linee utilizzando il mouse e che darà la possibilità di salvare in locale le opere create.

Chiaramente tale scelta è stata implementata in modo da non pregiudicare l'indipendenza delle singole lezioni ma con l'idea di suggellare un ulteriore filo conduttore all'interno dell'opera.

Alcuni prerequisiti

Nella prossima lezione ci interesseremo con maggior attenzione alla timeline ufficiale HTML5, per ora basti sapere che la data di accettazione delle specifiche come standard W3C è ancora sufficientemente lontana. Nonostante questo, buona parte di quanto verrà trattato in questa guida è già disponibile sulla grande maggioranza dei browser e, come vedremo, alcuni aspetti del linguaggio sono da tempo in produzione su portali di notevoli dimensioni, come youtube.com o vimeo.com.

Esistono tuttavia ampie porzioni delle specifiche che, perché meno strategiche, di più difficile implementazione o meno mature, sono ad oggi supportate in modo superficiale e disomogeneo; per poter beneficiare al massimo delle demo e degli esempi anche per elementi o API che ricadono in questa categoria si consiglia quindi di dotarsi di un browser che utilizzi WebKit come layout engine in quanto dotato del più ampio supporto HTML5 ad oggi disponibile sia per le parti della specifica ormai consolidate sia per quelle al momento più 'sperimentali'.

In particolare, tutto il codice di questa guida è stato sviluppato e testato usando la ‘Nightly Build' di Chromium, cioè la versione speciale per fini di sviluppo che contiene ogni feature ad oggi implementata, per quanto sperimentale esso sia. La pagina per il download, disponibile per i principali sistemi operativi, è raggiungibile all'indirizzo http://build.chromium.org/f/chromium/snapshots/ seguendo il link nominato come il proprio sistema operativo e successivamente la cartella recante il numero più alto tra i presenti.

Tabella della compatibilità sui browser
Se Chromium, lo accennavamo, garantisce ad oggi il supporto più ampio alle funzionalità previste nella specifica e in via di definizione presso il W3C e il WHATWG, la maggior parte dei browser commerciali più diffusi, con ritmi e tempi diversi, si sta adeguando. Internet Explorer 9 e Firefox 5, rilasciati nella primavera di quest’anno, condividono infatti un ottimo supporto a queste specifiche.

Lo stato dell'arte relativamente al supporto HTML5 lo abbiamo tracciato in questa tabella di compatibilità che sarà via via aggiornata con l'estendersi del supporto alle feature che attualmente non sono supportate. Estratti della tabella sono inseriti anche a corredo delle lezioni dedicate a ciascun elemento.

Mappa della guida

Nell'immagine seguenti è riassunta l'intera struttura dell'opera mettendo in evidenza la posizione delle singole lezioni rispetto al contenuto globale con l'obiettivo di fornire una panoramica esauriente sui temi che verranno trattati.

Ai nastri di partenza!

Bene, con questo può definirsi conclusa questa necessaria sezione introduttiva, la prossima lezione affronterà la travagliata storia che ha caratterizzato la definizione di queste specifiche, con un piccolo ma sentito cameo anche da parte dell'XHTML2.

Un po' di storia

Siete curiosi di sapere come tutto è nato? Venerdì 4 giugno 2004, in una notte buia e tempestosa, Ian Hickson annuncia la creazione del gruppo di ricerca WHAT, acronimo di Web Hypertext Application Technology in un sintetico ma ricco messaggio.

L'obiettivo del gruppo è quello di elaborare specifiche per aiutare lo sviluppo di un web più orientato alle applicazioni che ai documenti; tra i sottoscrittori di questa iniziativa si annoverano aziende del calibro di Apple, Mozilla e Opera. Questa piccolo scisma dal W3C è determinato dal disaccordo in merito alla rotta decisa dal consorzio durante un famoso convegno del 2004 dove, per un pugno di voti, prevalse la linea orientata ai documenti di XHTML2.

"XHTML 2.0 considered harmful" è il titolo di un messaggio inviato alla mailing list ufficiale del W3C datato 14 gennaio 2003 che ben riassume i sentimenti contrastanti che all'epoca si respiravano in merito a queste specifiche. La principale causa di perplessità è da ricercarsi nella decisione azzardata di non mantenere la retro-compatibilità con la versione 1.1 eliminando alcuni tag e imponendo agli sviluppatori web un controllo rigoroso nella creazione delle pagine, pena lo stop del processo di parsing e la visualizzazione a schermo degli errori di interpretazione. Nei due anni successivi i gruppi XHTML2 e WHAT proseguono i lavori sulle proprie specifiche in modo indipendente e parallelo, sollevando dubbi e confusione sia da parte dei produttori di browser che degli sviluppatori web. Emblematico in tal senso è un articolo firmato da Edd Dumbill nel dicembre 2005 intitolato The future of HTML. Il 27 ottobre 2006 in un post sul proprio blog intitolato Reinventing HTML, Tim Berners-Lee annuncia la volontà di creare un nuovo gruppo di ricerca che strizzi l'occhio al WHAT e ammette alcuni sbagli commessi seguendo la filosofia XHTML2:

Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work. The large HTML-generating public did not move, largely because the browsers didn't complain. Some large communities did shift and are enjoying the fruits of well-formed systems, but not all. It is important to maintain HTML incrementally, as well as continuing a transition to well- formed world, and developing more power in that world. Tim Berners-Lee.

Dovranno passare quasi altri due anni di competizione tra le due specifiche, questa volta entrambe interne al W3C, prima che nel luglio del 2009 lo stesso Tim sancisca di non voler riconfermare il gruppo XHTML2 per l'anno successivo preferendo di fatto la direzione intrapresa dall'HTML5. Frattanto il gruppo di ricerca, formato da una commistione di elementi del W3C e del WHAT, sotto la guida di Ian Hickson, è giunto alla 4° versione delle specifiche.

Nonostante il continuo e solerte lavoro e il grande intervallo di tempo speso nella stesura di questo documento, i passi residui necessari ad eleggere questa tecnologia al rango di 'W3C Reccomandation', relegandola così tra gli standard riconosciuti, sono ancora molti, al punto che si prevede di raggiungere l'agognato traguardo soltanto attorno al 2020.

Ricordiamo però che il consorzio si riferisce sempre all'intero universo inscritto nelle specifiche mentre alcune feature ritenute peculiari ed importanti, ad esempio il tag <video>, sono già implementate da tempo dalla totalità (o quasi) dei browser in commercio.

Che cos'è l'HTML5?

Domanda semplice solo all'apparenza; siamo sicuramente di fronte alla quinta revisione delle specifiche HTML ma anche di un vastissimo elenco di funzionalità che si sviluppano attorno al tema del linguaggio di markup: cerchiamo quindi di fare un po' di ordine.
Per prima cosa è importante ricordare che, anche in virtù della storia della sua nascita, all'interno dell'HTML5 convivono in armonia due anime: la prima, che raccoglie l'eredità semantica dell'XHTML2, e la seconda che invece deriva dallo sforzo di aiutare lo sviluppo di applicazioni Web. Il risultato di questo mix di intenti è più articolato di quanto si immagini; in prima istanza si assiste ad una evoluzione del modello di markup, che non solo si amplia per accogliere nuovi elementi, ma modifica in modo sensibile anche le basi della propria sintassi e le regole per la disposizione dei contenuti sulla pagina. A questo segue un rinvigorimento delle API JavaScript che vengono estese per supportare tutte le funzionalità di cui una applicazione moderna potrebbe aver bisogno:

salvare informazioni sul device dell'utente;
accedere all'applicazione anche in assenza di una connessione Web;
comunicare in modo bidirezionale sia con il server sia con altre applicazioni;
eseguire operazioni in background;
pilotare flussi multimediali (video, audio);
editare contenuti anche complessi, come documenti di testo;
pilotare lo storico della navigazione;
usare metafore di interazione tipiche di applicazioni desktop, come il drag and drop;
generare grafica 2D in tempo reale;
generare grafica 3D in tempo reale;
accedere e manipolare informazioni generate in tempo reale dall’utente attraverso sensori multimediali quali microfono e webcam.
Anche l'aspetto semantico a contorno del markup non è dimenticato; ecco quindi nascere le specifiche per la nuova generazione di microformati e per l'integrazione tra HTML5 e RDFa. Ma non è tutto, attorno a quello che può essere definito il nucleo autentico delle specifiche gravitano tutta una serie di altre iniziative, alcune delle quali in avanzato stato di definizione, studiate per:

accedere alle informazioni geografiche del device dell'utente (posizione, orientamento,...);
mantenere un database sul device dell'utente;
generare grafica 3D in tempo reale;
E non dimentichiamo che l'evoluzione dell'HTML viaggia di pari passo con quella dei CSS, che si avvicinano alla terza versione, e di altri importanti standard come SVG e MathML, e che ognuno di questi componenti è progettato nella sua versione più recente per recare e ricevere beneficio dagli altri.

Perché dovremmo passare all'HTML5?

Il panorama di Internet è cambiato molto dall'assunzione a 'W3C Reccomandation' della versione precedente delle specifiche, avvenuta verso la fine del 1999. In quel tempo il Web era strettamente legato al concetto di ipertesto e l'azione più comune per l'utente era la fruizione di contenuti, tipicamente in forma testuale. La mediamente bassa velocità di connessione e il limitato investimento sul media contribuivano ad una scarsa presenza di applicazioni web, più care da sviluppare ed esigenti in termini di banda.

Tutto questo era ben rappresentato da un linguaggio, HTML, principalmente orientato ad agevolare la stesura di semplici documenti testuali collegati fra loro. Negli anni successivi l'interesse intorno alla rete ha subito una brusca accelerazione e questo ha condizionato positivamente sia la diffusione che la velocità di connessione della stessa, attirando di conseguenza maggiori investimenti e ricerca. Al modello di fruizione dei contenuti si è aggiunta la possibilità per l'utente finale di divenire esso stesso creatore attraverso applicazioni web sempre più elaborate ed interessanti.

Questo nuovo livello di complessità, in termini di sviluppo, ha però dovuto scontrarsi con un set di specifiche poco inclini ad essere utilizzate per tali fini e che quindi si sono prestate al compito solo a scapito di infiniti hack e workaround. Esempi di questi 'utilizzi non premeditati' dell'HTML si possono trovare un po' ovunque, famoso il caso degli attributi rel e ref che hanno assunto nel tempo valori non previsti, (eg: nofollow) anche esterni alla loro funzione naturale (eg: l'utilizzo di questi due attributi in librerie come Lightbox).

Parallelamente il percorso di crescita del web ha fatto emergere alcune strutture di contenuto ricorrenti, ben caratterizzate dal fenomeno dei blog: informazioni di testata, menu di navigazione, elenchi di articoli, testo a pie' di pagina, ed altri. La parte dedicata al singolo articolo presenta anch'essa solitamente lo stesso set di informazioni quali autore, data di pubblicazione, titolo e corpo del messaggio. Anche in questo caso l'HTML4 non ha saputo fornire gli strumenti adatti a consentire una corretta gestione e classificazione del contenuto obbligando gli sviluppatori web a ripiegare su strutture anonime, quali <div> e

, arricchite di valore semantico con l'utilizzo di attributi quali class e id.

L'HTML5 nasce per risolvere questi problemi offrendo agli sviluppatori web un linguaggio pronto ad essere plasmato secondo le più recenti necessità, sia dal lato della strutturazione del contenuto che da quello dello sviluppo di vere e proprie applicazioni.

Grandi cambiamenti nell'ombra

La differenza principale tra le versioni correnti di HTML e XHTML risiede nella sintassi. Il linguaggio di markup creato da Tim Berners-Lee, e che ancora oggi popola i nostri browser, è stato studiato come applicazione del più generico SGML, Standard Generalized Markup Language; ne è la prova la dichiarazione di Document Definition Type che dovrebbe essere posta nella prima riga di una pagina Web ad indicare la grammatica, HTML per l'appunto, usata nel documento:

In realtà la quasi totalità dei browser ignora la definizione e interpreta il documento secondo logiche più permissive, frutto di anni di eccezioni e di esperienza accumulata su pagine malformate. L'XHTML, invece, è una versione della sintassi HTML costretta all'interno delle regole XML, a sua volta grammatica SGML: questo approccio dovrebbe implicare un maggior rigore nella pagina e l'aderenza a regole quali l'obbligo di chiusura di tutti i tag. Il parser XML inoltre dovrebbe sospendere l'interpretazione della pagina al primo errore rilevato.

L'arrivo dell'HTML5 introduce una importante novità in questo scenario, per la prima volta l'obiettivo delle specifiche è quello di definire un linguaggio ubiquo, che possa poi essere implementato su entrambe le sintassi. L'occasione è buona anche per fare un po' di pulizia e rompere definitivamente il legame tra HTML e SGML formalizzando e traducendo in standard le regole adottate da tempo nei browser. Per indicare un documento HTML5 è nata quindi la seguente semplice istruzione:


Che si affianca a quella da utilizzare in caso si intenda scrivere una pagina XHTML5:


E adesso?

Questa lezione aveva l'obiettivo di fornire un contesto storico e operativo ai temi dei quali questa guida tratterà in modo approfondito. Nelle prossime lezioni affronteremo in sequenza prima la parte legata al markup ed alla gestione della disposizione del contenuto e successivamente le principali API introdotte da queste specifiche. Il viaggio all'interno dell'universo dell'HTML5 è appena iniziato!

La sintassi di HTML5

Prima di scendere nei dettagli presentando i nuovi elementi e le nuove API definite nella specifica, è necessario spendere qualche momento per parlare delle regole sintattiche introdotte dall’HTML5, per larga misura ereditate e razionalizzate dalla precedente versione delle specifiche. In primo luogo familiarizziamo con il concetto noto di tag. Esistono tre distinte versioni di questa particella, ognuna di esse si applica selettivamente solo ad alcuni elementi:


Gli elementi HTML5 si possono dividere in tre categorie sulla base della tipologia di tag da usare per implementarli.

1. Elementi normali: sono quelli che possono racchiudere dei contenuti sotto forma di testo, commenti HTML, altri elementi HTML, etc. Sono elementi normali, dunque, i paragrafi (<p>), le liste (<ul>), i titoli (<h1>), etc. Salvo specifici casi, cui accenneremo nel seguito della lezione, gli elementi normali vengono definiti attraverso un tag di apertura (<p>) e un tag di chiusura (

).

2. Elementi vuoti: gli elementi vuoti sono quelli che non possono avere alcun contenuto. Per questi elementi si utilizza un tag ‘vuoto’. Essi sono: area, base, br, col, command, embed, hr, img, input, keygen, link, meta, param, source, track, wbr.

Per gli elementi vuoti, la chiusura del tag, obbligatoria in XHTML, è invece opzionale. Possiamo dunque definire un tag secondo le regole XHTML:


O seguendo la vecchie regole di HTML 4:


3. Elementi provenienti da altri namespace: per questi elementi sono richiesti i tag ‘autochiudenti’. Si tratta degli elementi adottati da specifiche esterne, come SVG e MathML.

Maiuscolo, minuscolo

Una delle differenze principali rispetto alle regole XHTML riguarda l'uso del maiuscolo e del minuscolo per definire un tag. In XHTML è obbligatorio usare il minuscolo. In HTML5 è consentito scrivere un tag usando anche il maiuscolo:


Casi particolari

Esistono alcune casistiche per le quali un tag classico può mancare della sua particella di apertura o di chiusura; questo succede quando il browser è comunque in grado di determinare i limiti di operatività dell’elemento. Gli esempi più eclatanti riguardano i tag ‘contenitori’, come head, body e html, che possono essere omessi in toto a meno che non contengano un commento o del testo come istruzione successiva. È quindi sintatticamente corretto scrivere un documento come segue:


Notiamo che, come mostrato nell’esempio, anche i tag p e li possono essere scritti omettendo la particella di chiusura, a patto che l’elemento successivo sia all’interno di una cerchia di elementi definita dalle specifiche. A fronte di queste opzioni di semplificazione è però errato pensare che la pagina generata dal codice di cui sopra manchi, ad esempio, dell’elemento html; esso è infatti dichiarato implicitamente ed inserito a runtime dallo user-agent.

Per un quadro dettagliato rimandiamo a questa sezione delle specifiche.

Attributi

Anche rispetto alle definizione degli attributi HTML5 consente una libertà maggiore rispetto a XHTML, segnando di fatto un ritorno alla filosofia di HTML 4. In sintesi: non è più obbligatorio racchiudere i valori degli attributi tra virgolette.

I casi previsti nella specifica sono 4.

Attributi 'vuoti': non è necessario definire un valore per l'attributo, basta il nome, il valore si ricava implicitamente dalla stringa vuota. Un caso da manuale:


Attributi senza virgolette: è perfettamente lecito in HTML5 definire un attributo senza racchiudere il valore tra virgolette. Esempio:


Attributi con apostrofo: il valore di un attributo può essere racchiuso tra due apostrofi (termine più corretto rispetto a 'virgoletta singola'). Esempio:


Attributi con virgolette: per concludere, è possibile usare la sintassi che prevede l'uso delle virgolette per racchiudere il valore di un attributo. Il codice:


Semplificazioni

In direzione della semplificazione vanno anche altre indicazioni. Ci soffermiamo su quelle riguardanti due elementi fondamentali come style e script. La sintassi tipica di XHTML prevede la specificazione di attributi accessori come type:


In HTML5 possiamo farne a meno, scrivendo dunque:


Conclusioni

Come abbiamo sperimentato, la sintassi HTML5 si caratterizza per una spiccata flessibilità e semplicità di implementazione. Le osservazioni che abbiamo snocciolato in questa lezione sono chiaramente valide a patto di implementare la serializzazione HTML; ricordiamo infatti che le specifiche prevedono anche l’utilizzo di una sintassi XML attraverso l’uso delle istruzioni:


Infine, per una migliore leggibilità del codice sorgente, consigliamo di ricorrere il meno possibile all’utilizzo di elementi impliciti, scrivendo sempre tutti i tag necessari nella loro forma completa.

Elementi disegnati per un web moderno

All’inizio erano tabelle; ricordiamo tutti bene il tedio provocato dal dover costruire strutture complesse spezzandole all’interno di una griglia fatta da infiniti <tr> e <td>: un attività noiosa, resa ancora peggiore dalla scarsa qualità e flessibilità del risultato. Poi arrivarono i <div> e fu una vera e propria rivelazione; finalmente un modello di costruzione del documento pensato per separare in modo chiaro i contenuti tipici di una pagina web. Grazie alla commistione tra questo elemento e i CSS nacquero pagine con codici HTML eleganti e leggibili come:


All’interno di un costrutto come questo è tutto molto semplice da interpretare: basta seguire il flusso dei rientri di pagina facendosi guidare dai valori semantici attribuiti a id e class.

Passarono anni e il modello cominciò a mostrare le sue prime debolezze; in primo luogo ci si accorse che da un lato non vi era una regola collettiva e quello che per uno sviluppatore era ‘body’ per l’altro poteva benissimo essere ‘corpo’; inoltre si realizzò che né il browser né tantomeno i motori di ricerca avrebbero mai potuto beneficiare di questa divisione semantica, proprio per colpa di quell’arbitrarietà che permetteva a milioni di siti web di essere organizzati in strutture simili ma sempre leggermente diverse tra loro e per questo non raggruppabili secondo schemi automatici. Emerse in questo modo uno dei più grandi problemi dell’HTML4: l’incapacità di descrivere il significato delle informazioni di una pagina web in un formato interpretabile da altri software. In un mondo sempre più caratterizzato dall’interconnessione e dall’aggregazione su base semantica dei contenuti ci si adattò inventando e condividendo convenzioni studiate per rappresentare eventi di calendario, persone e quant’altro; nacquero così diversi microformati, come ad esempio hRecipe per le ricette:


L’HTML5 nasce per gestire ed incanalare tutte queste problematiche; nelle prossime lezioni scopriremo come beneficiare di nuovi tag disegnati appositamente per le più comuni strutture di contenuto e di attributi utilizzabili per definire ulteriore contenuto semantico alle pagine. Ma per arrivare a questo prima serve fare un po’ di pulizia...

Elementi e attributi non più previsti nelle specifiche

Le specifiche HTML5 sanciscono definitivamente la fine di tutta una serie di elementi e attributi che mantengono validità formale solo per preservare la retrocompatibilità di pagine datate ma sono espressamente vietati nella creazione di nuovi documenti.

I primi a subire questo esilio sono tutti quei costrutti funzionali alla parte di presentazione e caduti ampiamente in disuso con l’introduzione dei fogli di stile. Stiamo parlando di elementi come: basefont, big, center, font, s, strike, tt e u.

Ad essi si aggiunge una moltitudine di attributi più o meno noti, tra i quali ricordiamo: align e valign, background, bgcolor, cellpadding, border, cellspacing e molti altri. In realtà alcuni tra i citati perdurano solamente su specifici elementi, per una lista completa ed esaustiva consigliamo di visionare questa pagina del W3C dedicata al tema.

Interessante notare come si sia deciso invece di mantenere elementi come i e b; trasformandoli, però, da modificatori tipografici a semplici indicatori di porzioni di testo particolari e consentendone l’uso solo come ultima risorsa.

La falce della semplificazione si è successivamente abbattuta su un piccolo elenco di elementi obsoleti: acronym (sostituibile dal più comune abbr), applet (rimpiazzato da object), isindex (già arcaico in HTML4) e infine dir, sfavorito nel confronto con ul.

Cadono, infine, anche tutti i tag che gravitano intorno al concetto dei frame, ritenuti dannosi per usabilità e accessibilità: frame, frameset e noframes.

E con questi ultimi si chiude la lista degli elementi soppressi; in loro onore terminiamo la lezione con un piccolo snippet che li omaggi:


Attributi globali

Di attributi globali (quelli cioè che si possono applicare a tutti gli elementi HTML) ce ne sono sempre stati: basti pensare al classico ‘id’, disponibile da sempre sulla totalità degli elementi. HTML5 formalizza questa definizione e arricchisce lo sparuto gruppo con nuovi membri che, come intuibile, possono essere applicati a un qualsiasi tag di queste specifiche. In questo capitolo dedicheremo qualche paragrafo ad ognuno dei nuovi arrivati, alcuni dei quali, vedrete, sono decisamente interessanti.

Modificare il contenuto di una pagina: contenteditable

TinyMCE, CKEditor e WYMeditor sono solo tre di una lunga lista di librerie studiate per offrire uno strumento di editing testuale su web che superi le classiche textarea. I risultati sono già ad oggi eccellenti, vicini a prodotti desktop come Microsoft Word, ma le soluzioni implementate fanno tutte uso di escamotage più o meno furbi per ottenere questo livello di interazione in quanto l’HTML 4 non prevede alcun modo esplicito di generare controlli del genere.

Durante la stesura delle specifiche HTML5 questo problema è stato affrontato e si è deciso di sviluppare un approccio comune al rich-editing di un documento re-introducendo un set di specifiche implementate in sordina da Microsoft nella versione 5.5 di Internet Explorer. Questo lavoro ha portato alla creazione di un nuovo attributo globale: contenteditable, che impostato a true su di un qualsiasi elemento lo rende modificabile da browser; lo stesso destino subiscono tutti gli elementi in esso contenuti a meno che non espongano un esplicito contenteditable=false.

Ma... cosa significa esattamente modificabile da browser? Che tipo di feedback visivo ci si dovrebbe aspettare? E come si comporterebbe il markup a fronte delle modifiche? Sfortunatamente qui le specifiche non sono troppo chiare e sanciscono semplicemente che qualsiasi cosa venga concessa all’utente il risultato deve comunque restare conforme all’HTML5: questa libertà operativa ha prodotto comportamenti diversi da browser a browser; ad esempio c’è chi traduce il tasto invio com un
e chi invece crea un nuovo paragrafo con <p>. Parallelamente è disponibile anche un set di API utilissime per insistere sulla zona modificabile con comandi attivati dall’esterno, come ad esempio da una toolbar. Un pulsante che volesse attivare/disattivare il grassetto sulla selezione corrente dovrebbe invocare la seguente funzione:


Prima di passare oltre sappiate che l’attributo contenteditable è stato applicato con valore true a all’intera sezione precedente con l’esclusione di questo paragrafo, permettendovi così di editarla e sperimentare l’interazione di questa nuova interessante caratteristica! (e se selezionate del testo e cliccate qui, potrete renderlo grassetto!).

Menu contestuali associati ad un elemento: contextmenu

L’attributo globale contextmenu serve ad associare a un elemento un menu contestuale; questa forma di interazione è poco comune sul web ma molto praticata sul desktop dove, ad esempio, su di una cartella di sistema ci si aspetta di poter operare azioni quali ‘copia’, ‘elimina’ e ‘rinomina’. Vediamo un esempio:


Cliccando con il tasto destro del mouse sull’immagine il browser dovrebbe mostrare un menu contenente le due azioni disponibili. Purtroppo ad oggi non esiste ancora nessuna implementazione funzionante di questa feature, che resta al momento relegata a semplice specifica.

Lʼattributo data-*

L’HTML5 predispone la possibilità di associare ad ogni elemento che compone la pagina un numero arbitrario di attributi il cui nome può essere definito dall’utente sulla base di esigenze personali, a patto che venga mantenuto il suffisso ‘data-’; ad esempio:


È inoltre interessante notare come queste informazioni, che arricchiscono e danno valore semantico all’elemento, siano accessibili anche attraverso un comodo metodo Javascript:


La fine del display:none in linea: hidden

L’attributo globale hidden è stato introdotto per offrire un’alternativa all’utilizzo del predicato ‘style="display:none"’ che ha subito una proliferazione incontrollata soprattutto a seguito della diffusione di librerie Javascript come jQuery o Prototype. Un elemento marcato come hidden deve essere considerato dallo user agent come non rilevante e quindi non visualizzato a schermo.

Spellcheck

La quasi totalità dei browser oggi in commercio contiene un motore di verifica della sintassi grammaticale. Le specifiche HTML5 introducono un meccanismo per abilitare o disabilitare il controllo della sintassi su porzioni della pagina modificabili dall’utente. L’attributo in questione si chiama spellcheck e, quando impostato a true, ordina al browser di attivare il proprio correttore sull’elemento corrente e su tutti i suoi figli.

Laddove invece non venga impostata nessuna preferenza, le specifiche prevedono che il browser utilizzi un proprio comportamento di default.

Altri attributi globali

Ci sono un paio di altri attributi globali introdotti dalle specifiche e non trattati in questa sede, draggable e aria-*; entrambi sottendono un discorso che si estende ben al di là della semplice implementazione di markup e verranno trattati più avanti nella guida.

Ecco comunque la lista di tutti gli attributi globali previsti dalla specifica:


Conclusioni

In questa lezione abbiamo appreso che la nuova configurazione di markup dell’HTML5 è stata studiata per ovviare a tutti i problemi emersi in anni sviluppo di siti web e applicazioni con la precedente versione delle specifiche. Nelle prossime lezione introdurremo il nuovo content model, pensato non più nella forma binaria ‘block’ e ‘inline’ ma articolato in una serie di modelli di comportamento complessi ed interessanti.

Un nuovo content model

Non più solo div

Ecco come si potrebbe codificare l’esempio della lezione precedente utilizzando i nuovi elementi messi a disposizione dall’HTML5:


Come si può notare, i tag introdotti hanno un nome in strettissima attinenza con il proprio contenuto; questo approccio risolve in modo elegante sia il problema dell’utilizzo dell’attributo class con valore semantico, sia la riconoscibilità delle singole aree del documento da parte di un browser. Ma non è tutto; l’introduzione di article, nav, header e altri tag che vedremo, impone anche sostanziose novità al modo in cui lo user-agent deve comportarsi nell’interpretare questi elementi.

Contenuti in una bolla di sapone

Partiamo dal seguente esempio HTML4:


Se lo visualizziamo avremo un risultato assolutamente strutturato come questo:


Supponiamo ora di voler dividere i viaggi per continente. Con il modello attuale saremmo obbligati a cambiare l’elemento h3 in h4 in modo da fare spazio alla nuova suddivisione:


Questo accade perché la gerarchia delle intestazioni è assoluta rispetto all’intero documento e ogni tag <h*> è tenuto a rispettarla. Nella maggior parte dei casi però questo comportamento è fastidioso in quanto è molto comune avere a che fare con contenuti che, come articoli o commenti, vorremmo avessero una struttura indipendente dalla loro posizione nella pagina. In HTML5 questo è stato reso possibile definendo una nuova tipologia di content model, chiamato ‘sectioning content’, al quale appartengono elementi come article e section. All’interno di tag come quelli appena citati la vita scorre come in una bolla di sapone, quindi l’utilizzo di un <h1> è considerato relativo alla sezione in cui si trova.

Riprendiamo l’esempio precedente ed interpretiamolo in salsa HTML5:


Molto meglio! Ora i singoli componenti di questo documento sono atomici e possono essere spostati all’interno della pagina senza dover cambiare la loro struttura interna. Inoltre, grazie a queste divisioni, il browser riesce a discernere perfettamente il fatto che l’ultimo paragrafo non appartenga al testo del viaggio in Kenia.

Diamo prova dell’atomicità creando un blocco dedicato all’ultimo articolo inserito: ‘Un week-end a Barcellona’:


Anche grazie a questo content model l’HTML5 introduce un nuovo e preciso algoritmo per il calcolo dell’outline del documento. La vista ad outline, tipica nei software di word processing e ancora non presente nei browser, è utilissima nella navigazione dei contenuti di una pagina. Sperimentiamo questa feature installando un’apposita estensione per Chromium:


È interessante notare come l’algoritmo non solo identifichi correttamente i vari livelli di profondità, ma per ognuno di essi sappia anche recuperare il titolo adeguato. Nell’HTML5 è vitale che il design della pagina si rispecchi in una outline ordinata e coerente, questa infatti è la miglior cartina tornasole possibile in merito al corretto utilizzo delle specifiche: ad esempio, in una prima revisione della lezione, il codice HTML precedente mancava dell’elemento hgroup, utile a raggruppare elementi che concorrono a formare un titolo. L’errore è stato individuato e corretto proprio grazie alla visualizzazione di una outline errata:


Concludiamo la trattazione di questo content model citando la presenza di alcuni elementi che, pur seguendo le linee interpretative del 'sectioning content', devono essere ignorati dall'algoritmo di outline. Tali tag sono definiti 'sectioning roots' ed il motivo della loro esclusione è legato al fatto che essi non concorrono tanto alla struttura dei contenuti della pagina quanto all'arricchimento della stessa. Fanno parte di questo elenco elementi come: blockquote, details, fieldset, figure e td. Seppur esclusi dall'outline del documento, nulla vieta agli appartenenti di questo gruppo di avere una propria outline interna.

Panoramica sui content model e presentazione del primo progetto guida

Lo scopo di questa lezione è duplice: da un lato riallacciarsi al tema del sectioning content per offrire una visione di ampio respiro in merito alle differenti tipologie di disposizione di contenuto offerte dall'HTML5, dall'altro iniziare la stesura del primo progetto guida.

Una panoramica completa

Esistono altri content model oltre a quelli trattati nella lezione precedente, alcuni implicitamente presenti anche nelle vecchie specifiche, altri nuovi di zecca, per una rappresentazione grafica rimando all'ottima infografica dello stesso W3C, fra l'altro realizzata usando la sintassi SVG (provate a scorrere il mouse sopra le varie aree dell'insieme).

Metadata content
Fanno parte di questa categoria tutti gli elementi utili alla definizione del documento nel suo insieme: a livello di presentazione o di funzionamento.

Tag: base, command, link, meta, noscript, script, style, title.

Sectioning content
Ne abbiamo appena parlato: il gruppo contiene tutti quegli elementi studiati per ospitare contenuti atomici e semanticamente ordinati. È importante utilizzare almeno un appartenente alla categoria heading content all’interno di ognuno di questi tag, questo anche per non avere un outline popolato da voci senza titolo (vedi immagine).

Tag: article, aside, nav, section.


Heading content
Tutti gli appartenenti a questo gruppo servono per definire titoli. Interessante notare come se la presenza di uno di questi elementi non sia associata ad un sectioning content questo venga definito implicitamente.

Tag: h1, h2, h3, h4, h5, h6, hgroup

Phrasing content
Incorpora il testo del documento così come tutti i modificatori tipografici e visuali dello stesso.

Tag: a (solo se contiene phrasing content a sua volta), abbr, area (se figlio di un elemento map), audio, b, bdi, bdo, br, button, canvas, cite, code, command, datalist, del (solo se contiene phrasing content a sua volta), dfn, em, embed, i, iframe, img, input, ins (solo se contiene phrasing content a sua volta), kbd, keygen, label, map (solo se contiene phrasing content a sua volta), mark, math, meter, noscript, object, output, progress, q, ruby, s, samp, script, select, small, span, strong, sub, sup, svg, textarea, time, var, video, wbr.

Embedded content
Ne fanno parte tutti quegli elementi che, come il nome del gruppo suggerisce, incorporano nella pagina oggetti esterni.

Tag: audio, canvas, embed, iframe, img, math, object, svg, video.

Interactive content
Questa categoria comprende tutto ciò specificatamente studiato per interagire con l’utente.

Tag: a, audio (con l’attributo controls presente), button, details, embed, iframe, img (con l’attributo usemap presente), input (con l’attributo type diverso da hidden), keygen, label, menu (con l’attributo type="toolbar"), object (con l’attributo usemap presente), select, textarea, video (i con l’attributo controls presente).

Come avrete notato ogni elemento può appartenere ad uno o più content models, anche a seconda della sua configurazione degli attributi. Oltre ai gruppi citati, che sono i principali, va ricordato flow, che raggruppa la quasi totalità degli elementi e alcuni gruppi creati specificatamente per i controlli dei form, che vedremo più avanti.

Progetto guida - nel tag HEAD

Cogliamo l’occasione di questa panoramica alla struttura dell’HTML5 per gettare le prime fondamenta del progetto guida: in questo capitolo vedremo come impostare e strutturare il contenitore della pagina ed il tag head. Creiamo un file index.html ed iniziamo ad inserire i primi elementi:


Fin qui, eccezion fatta per il doctype, nessuna differenza rispetto alla versione 4 delle specifiche; andiamo avanti aggiungendo alcuni tag meta e link:


Incuriositi dalla strana sintassi degli attributi media degli ultimi due <link>? State osservando una tipica media query: il CSS viene interpretato solamente se le condizioni dell’espressione sono valutate come vere dallo user agent. Le media query, profetizzate già nel 1999, consentono di identificare il corretto CSS per un dato device con un incredibile livello di dettaglio, alcuni esempi:


Bene, completiamo questo capitolo aggiungendo icone e charset:


Come potete notare è ora possibile specificare un attributo sizes per ogni icona, in questo modo lo user agent può liberamente scegliere quale icona abbia le dimensioni più adatte. Ci sono due motivi che giustificano l’inserimento della direttiva ‘charset’ in questo progetto: in primo luogo la nuova sintassi è molto più succinta della passata, seppur ancora valida:


In seconda istanza è intenzione dell’autore sottolineare come sussistano reali rischi di sicurezza legati all’assenza di questa direttiva.

Dalla prossima lezione analizzeremo nel dettaglio i singoli elementi che concorrono alla costituzione della nuova impalcatura semantica del linguaggio.

ALLA SECONDA PARTE