Archivio > Markup, Standards > Singolo: Uno sguardo ad XHTML 2.0 (parte 2)

Uno sguardo ad XHTML 2.0 (parte 2)

Le nuove specifiche W3C, attualmente in fase di rielaborazione, per XHTML 2.0 si prospettano interessanti e piene di ottimi spunti. Negli ultimi giorni ho dato un'occhiata più approfondita alle bozze delle specifiche XHTML 2.0 attualmente in lavorazione, e per fortuna non è stato tempo perso.

Molte delle novità introdotte le conoscete già, altre forse no. In questo articolo elencherò solo quelle che a parer mio costituiscono un grande passo avanti in termini di semantica e (in parte) accessibilità.

Ruolo degli elementi

Innanzi tutto, apprezzo molto il risultato semantico ottenuto col nuovo attributo role. Secondo le specifiche:

Questo attributo descrive il ruolo (o i ruoli) che l'elemento corrente recita nel contesto del documento. E' usato dalle applicazioni e dalle tecnologie assistive per determinare il proposito dei widgets. Nel caso di una pagina web esso può dichiarare la funzione di particolari elementi, o può essere un attributo configurabile dall'autore della pagina. In più, il ruolo può essere usato per definire ogni azione che può essere eseguita su un elemento. Questo permette all'utente di essere informato, e prendere decisioni basate sulle azioni attivabili su quell'elemento stesso, in un modo indipendente dal dispositivo (supporto).

Per fare un esempio:

<div role="search">
    <!-- Modulo di ricerca //-->
</div>

In questo modo, l'user agent (o chi per lui) è in grado di capire che:

  • Il contenitore ha il ruolo di cercare stringhe di testo in uno o più documenti.
  • L'unica azione possibile nel riquadro è la ricerca di testo.

L'attributo id svolge un compito simile, sebbene il suo scopo sia quello di identificare con un nome univoco l'elemento, e non di dichiararne il ruolo nel contesto del documento.

Mappa dell'Accessibilità

L'attributo role è altrettanto utile se usato in collaborazione con l'elemento access.

Il modulo XHTML sull'accessibilità infatti, specifica un nuovo metodo per attribuire accesskeys agli elementi specificati nel documento.

L'omonimo elemento, si compone di tre attributi principali:

key

Prevede la possibilità di specificare una chiave (carattere) per raggiungere un particolare elemento nel documento.

Dalle specifiche:

Questo attributo assegna una chiave di rappresentazione per un collegamento accessibile. Un'accesskey consiste in un carattere singolo preso dal set di caratteri del documento. Gli autori dovrebbero considerare il metodo di input del potenziale lettore, quando specificano una chiave di questo tipo.

Attivando la chiave definita in un elemento, il focus verrà indirizzato, a partire da quello corrente, verso l'elemento successivo che ha quel relativo ruolo o identificativo. E' possibile associare alcuni eventi insieme al target, dando quindi la possibilità di eseguire azioni addizionali una volta che il focus è cambiato.

L'invocazione delle accesskeys dipende dalla loro implementazione. Per esempio, su alcuni sistemi è necessario premere il tasto ALT insieme alla chiave. Altri sistemi sfruttano invece la combinazione con CMD.

Il modo di renderizzare una chiave dipende dall'user agent. Consigliamo agli autori di includerla in stringhe (etichette) di testo, o in qualunque luogo sia da applicare la chiave stessa. Il valore di una chiave dovrebbe essere interpretato in un modo tale da enfatizzare il suo ruolo, distinguendo essa dagli altri caratteri (ad esempio, sottolineandola).

Il carattere assegnato ad una chiave, e la sua relazione con gli attributi role e id, sono a discrezione dell'autore. L'user agent può implementare meccanismi per sovrascrivere, disabilitare, o riassegnare chiavi. Nonostante tutto, gli assegnamenti specificati dall'utente dovrebbero avere la precedenza.

targetid
Richiama l'elemento che ha l'identificativo (id) specificato nell'attributo.
targetrole
Richiama l'elemento che ha il ruolo (role) specificato nell'attributo.

Qualche esempio:

<!-- Punta al contenuto principale (elemento con role="main") //-->
<access key="m"
    title="Contenuto principale" 
    targetrole="main" />

<!-- Punta ad un elemento con id="username" //-->
<access key="u" 
    title="Username" 
    targetid="username" />

Gestori di eventi

Dite pure addio a script, perchè da adesso in poi si parlerà dell'modulo handler (vedi la voce Javascript ed Eventi su Wikipedia).

ll Modulo Handler definisce elementi che sono utilizzati per contenere informazioni pertinenti all'implementazione di un gestione di eventi, generalmente incluso nel linguaggio di scripting.

Questo elemento può apparire più volte sia nell'head che nel body di un documento XHTML.

L'handler può essere definito dentro al contenuto dell'elemento, o in una risorsa esterna. Se l'attributo src ha un valore URI, gli user agents devono ignorare il contenuto e recuperare il gestore di eventi via URI. Nota che l'attributo encoding si riferisce al set di caratteri dell'handler designato dall'attributo src, e non al contenuto dell'elemento stesso.

Un user agent deve interpretare un elemento handler in base a queste regole di precedenza:

  1. L'user agent prima deve provare a processare l'elemento handler, ma non il contenuto annidato.
  2. Se l'user agent non è capace di processare l'elemento per qualsiasi ragione (non è configurato per questo, non supporta il tipo di handler specificato in type, non c'è alcuna risorsa esterna, ecc.), deve provare a processare il contenuto.
  3. Se il contenuto è un altro elemento handler, il suo contenuto deve essere processato in accordo alle regole sopra descritte.
  4. Altrimenti, il contenuto viene interpretato come dati del tipo di handler dell'elemento handler contenitore (superiore).

Apparte qualche descrizione un pò contorta, possiamo riassumere il tutto dicendo che questo elemento si proporrà come strumento per aggiungere un pizzico di dinamicità alla pagina, ed interazione con l'utente, avvalendosi dei più importanti linguaggi di scripting attualmente conosciuti.

Il tipo MIME (vedi la lista dei content-types attualmente registrati) viene specificato nell'attributo type, così come è sempre avvenuto.

Nel working draft viene fatto notare che:

Il modello processionale di XML non permette l'uso del metodo DOM document.write in XHTML 2.0. Per generare contenuto dinamico, e affinchè esso sia analizzato (vedi Parsing su Wikipedia), è necessario aggiungere elementi utilizzando chiamate all'albero DOM.

Il che in parte è un bene (maggior aderenza agli standards), e in parte un male (premesso che l'albero DOM è complesso, ho qualche serio dubbio in termini di crossbrowsing).

Esempio:

<html xmlns="http://www.w3.org/2002/06/xhtml2" xml:lang="en">
 <head>
  <title>Documento con handler</title>
  <handler type="text/x-vbscript" src="http://example.org/progs/vbcalc">
   <handler type="text/javascript">
   <!-- JavaScript inline //-->
   </handler>
  </handler>
 </head>
 <body>
    <handler type="text/x-perl">
    <!-- Script Perl //-->
    </handler>
 </body>
</html>

Blocchi di codice e testo preformattato

Un'altra particolare caratteristica delle nuove specifiche consiste nell'inclusione dell'elemento blockcode, che si accoda all'elemento blockquote per specificare particolari blocchi di testo, diversi da quelli formati - ad esempio - da paragrafi e liste.

La cosa curiosa è che gli autori hanno deciso di mantenere nel nuovo namespace anche il tag pre, spiegando che:

Questo elemento indica che lo spazio bianco nel testo annidato ha valenza semantica.

L'esempio da loro allegato era:

<pre>
              Se
          Io     avessi
       del         talento
        Mi piacerebbe
          essere un
             poeta
</pre>

Notare che qualcosa di simile era stato già scritto nelle precedenti specifiche HTML 4.01: io avevo dimenticato questo significato, sinceramente.

Sezioni e intestazioni

Fin troppe persone hanno - giustamente - fatto notare la nuova sintassi per scomporre la pagina in specifici livelli di importanza: l'elemento section e l'elemento h specificano rispettivamente una sezione e un'intestazione che la descrive.
XHTML 2.0 mantiene ancora la vecchia pratica delle intestazioni numerate, sebbene io (per quanto possa valere il mio parere) consigli di utilizzare il nuovo metodo strutturale.

Attualmente, infatti, per suddividere la pagina in più sezioni usiamo il fatidico contenitore div, insieme all'attributo id o all'attributo class. Questa non è ovviamente una scelta sbagliata, ma guardiamo al futuro: abbiamo la possibilità di sfruttare un modulo più semantico e preciso rispetto al passato, e questa è - secondo me - una delle maggiori innovazioni della nuova versione di XHTML.

A rigor di logica, ed a parità di casi, un elemento section semanticamente rende più di un elemento id. Vediamolo con un esempio.

<section id="stats">
    <!-- Statistiche varie ed eventuali //-->
</section>

<div id="stats">
    <!-- Statistiche varie ed eventuali //-->
</div>

La differenza?
Se un eventuale user agent analizzasse la nostra pagina, andrebbe incontro a diverse interpretazioni, legate rispettivamente agli esempi sopra mostrati.

  1. Primo esempio: Sezione con identificativo stats. La sezione contiene delle statistiche.
  2. Secondo esempio: Contenitore con identificativo stats. L'elemento contiene delle statistiche.

Ecco dove sta la differenza. Nel primo caso aggiungiamo un significato semantico al codice, che tuttavia non ritroviamo nel secondo. Ciò equivale a una perdita di informazioni, o sbaglio?

Le specifiche, d'altronde, recitano:

L'elemento div, in congiunzione con gli attributi id, class e role, offre un meccanismo generico per aggiungere una struttura extra (addizionale) al documento. Questo elemento non definisce alcun idioma presentazionale sul contenuto.

Per certi versi, quindi, in XHTML 2.0 l'utilizzo di contenitori generici per definire ciò che in realtà funziona come sezione potrebbe rivelarsi ridondante. Una sezione infatti non è addizionale, ma necessaria ai fini della semantica di un documento.

Abbreviazioni o acronimi?

Come mi aveva giustamente fatto notare Andrea, è bene fare un pò di chiarezza sul concetto di acronimo e abbreviazione.

Direttamente dal De Mauro, il dizionario della lingua italiana:

Acronimo

nome costituito da una o più lettere iniziali di altre parole (per es., radar, dall’ingl. ra(dio) d(etection) a(nd) r(anging)

nome costituito dalle lettere iniziali di una parola e dalle finali di un’altra (per es. motel, da mo(to–) e (ho)tel)

Abbreviazione

troncamento, contrazione grafica di una parola

In particolare, nelle relative specifiche HTML 4.01 viene precisato che:

abbr
Indica una forma abbreviata (es. WWW, HTTP, URI, Mass., ecc.)
acronym
Indica un acronimo (es. WAC, radar, ecc.)

Quindi, mentre un'abbreviazione viene recitata/scandita lettera per lettera, l'acronimo viene letto completamente come una normale parola.

L'errore di confondere abbreviazioni ed acronimi è molto comune (lo faccio e continuo a farlo anch'io). E' per questo che in XHTML 2.0 troviamo solo ed esclusivamente l'elemento abbr:

L'elemento abbr indica che un frammento di testo è un abbreviazione (es. W3C, XML, Inc., Ltd., Mass., ecc.); questo include anche gli acronimi.

Niente più breaks, ma solo righe

Curiosa, infine, anche l'introduzione dell'elemento l, creato per rappresentare semanticamente una linea di testo (una riga di codice o il verso di un poema, volendo).

L'esempio proposto dagli autori è:

<blockcode class="program">
<l>program p(input, output);</l>
<l>begin</l>
<l>   writeln("Hello world");</l>
<l>end.</l>
</blockcode>

Questa sostituzione probabilmente inciterà la suddivisione in paragrafi del testo: quante volte abbiamo - in passato - usato <br /> per spaziare i periodi, o anche solo far andare a capo una frase? Personalmente, tante.

Anche in questo articolo ho usufruito del break per interrompere una riga di testo e cominciare di nuovo dalla successiva. Questa scelta è legata a una logica che segue dei concetti a livello di presentazione: tutti (o quasi tutti) mandano a capo del testo per migliorarne la leggibilità. Tutti (o quasi tutti) evidentemente sbagliano nel farlo.

Conclusioni?

Non ho il tempo e sinceramente non ritengo ai fini dell'articolo necessario analizzare altre caratteristiche incluse in questa seconda versione di XHTML. Tempo fa avevo già accennato a XFORMS e segnalato un articolo su IBM.com, dove potete trovare maggiori informazioni sull'argomento.

Le scelte adottate a livello di codice mi entusiasmano particolarmente: in particolare, trovo maggior coerenza nella sintassi, e nel raggruppamento di elementi con funzioni simili fra loro (vedi per esempio il modulo object per ogni tipo di risorsa multimediale). Il namespace è stato semplificato ulteriormente (l'elemento edit riassume i compiti che prima erano di ins e del), e forse per la prima volta XHTML non è più solamente frutto di rimozioni (specialmente di tag ed attributi realizzati per fini di presentazione), ma di aggiunte (a livello di semantica ed accessibilità).

Ora, come ciliegina sulla torta, vi presento la prima pagina al mondo scritta in XHTML 2.0.

Gustatevela, poi chiudete gli occhi, e cominciate a sognare.

Approfondimenti

L'articolo è stato di tuo gradimento? Puoi controllare che vi sia altro di tuo interesse nelle categorie e , oppure iscriverti al notiziario RSS e seguirmi su per restare sempre aggiornato sulle ultime pubblicazioni.

Pubblicato domenica 14 gennaio 2007.

Discussione [1]

  1. Andre aggiunge:

    [Immagine] Segue l'intervento di Andre

    Gran bell'articolo, complimenti!

    In generale, a loro modo sono tutte innovazioni piuttosto stuzzicanti. Oltre a quelle che hai citato (in particolare l'attributo role e l'elemento access), è interessante l'accoppiata section - h, per definire la struttura della pagina.

    In particolare, l'uso degli headings che oggi usiamo si perderebbe un po', in favore di un generico h cui può essere associato uno stile mediante CSS ricorrendo a regole del tipo section section section h { font-size: 2.5em; }.

    Di certo, come fanno notare le specifiche stesse, usando l'elemento h (cui peraltro è possibile applicare anche un attributo href), non si può più incorrere in quei "salti" di headings (tipo h1-h3-h2 e simili), non esattamente corretti dal punto di vista della semantica.

    Infine, una mini riflessione su XHTML 2.0 e la pagina che hai linkato. Diciamo che per la prima volta nella sua storia, il linguaggio viene un minimo stravolto. Ci sono cose che prima non c'erano, attributi nuovi che richiedono modifiche sostanziali dei browser.

    La stessa pagina che hai linkato usa XSL per convertire il documento da XHTML 2.0 a XHTML 1.0 Strict; per quanto sia eccitato dalla bellezza di ciò che XHTML 2.0 porterà con sé, temo che la transizione comporterà tempi lunghi.

    In sostanza, XHTML 1.0 è un linguaggio bene o male interpretato da tutti i browser. Per la versione 2.0 ci sarà molto più lavoro da fare, e il risultato è che, come avviene per l'utilizzo delle nuove funzioni dei CSS, le differenze tra browser giocheranno ancora un role :P determinante per l'effettiva applicazione diffusa del linguaggio.

    Ok che i browser si aggiornano più o meno tutti, però lo fanno a scadenze tutte particolari. In più non è detto che le persone decidano di usare le nuove versioni.

    Lungi da me il voler fare da guastafeste, ma di sto passo l'accoppiata XHTML 2.0 + CSS3 la vedremo, mmm..., nel 2015? :P

Discuti

Il blog è in sola lettura.

Paginatura: