Steven Pemberton si interessa di usabilità dagli anni '80, quando costruiva tecnologia per interfacce utente, e continua ad identificare le "persone" (o meglio, l'usabilità) come il filo conduttore che percorre tutti i suoi progetti. L'opportunità di influenzare il W3C in tale direzione si materializzò nel 1995, quando Steven divenne il primo direttore dell'HTML Working Group. Steven oggi continua a ritenere l'usabilità come il chiaro punto di convergenza per gli interessi in tecnologia, affari ed il pubblico in generale, e la sua passione negli standard è tale che ritiene che essi permetteranno la realizzazione della convergenza prevista. Steven è anche un ottimo scrittore con un raro talento nel correlare la tecnologia all'esperienza di vita di milioni di utenti del Web che non sono tecnici. Nel 2007 Steven continua a dirigere l'HTML Working Group del W3C.
- xhtml.com
- Perchè abbiamo bisogno dell'XHTML 2? Quando diventerà reale questo bisogno?
- Steven Pemberton
L'HTML rappresenta un progetto di notevole successo, è il formato documentale di maggior successo. E' diventato però una sorta di Giardino dell'Eden, con tutta una serie di linee guida "Thou Shalt Not" che ti dicono come usarlo in modo appropriato, come per l'accessibilità, l'usabilità, l'internazionalizzazione, i metadata, l'indipendenza dal dispositivo e così via. In effetti, per scrivere un HTML 'corretto' devi possedere una grande quantità di informazioni.
In aggiunta, tutte queste comunità (a molte altre ancora) si sono avvicinate all'HTML con nuove richieste. In un mondo perfetto, l'HTML sarebbe accessibile così com'è, così che i non vedenti ed i vedenti parziali (come noi tutti saremo un giorno) possano utilizzare il Web in modo semplice. Per fare un altro esempio, non è necessario scrivere il tuo sito per ogni tipo di dispositivo che diventa disponibile - se l'HTML fosse indipendente dal dispositivo dovrebbe funzionare bene su ogni dispositivo. Così l'XHTML 2 sta cercando di raccogliere richieste ed indicazioni da molte comunità e di creare un design consistente e coerente che soddisfi la maggior parte di tali richieste.
Tuttavia un buon design non è come metter insieme molte caratteristiche. Per esempio, ci è stato chiesto di aggiungere all'XHTML 2 un grosso numero di nuovi elementi, e, se li avessimo aggiunti tutti, ne sarebbe scaturito un insieme poco gestibile. Per fare un esempio estremo, ci fu chiesto di aggiungere un elemento che rappresentasse l'ironia. Molto probabilmente finiremo per costruire un design che permetta di aggiungere livelli semantici - il significato - nell'XHTML, nello stesso modo in cui i CSS permettono una presentazione con livelli. Così l'XHTML mantiene un piccolo numero di elementi per strutturare i documenti, e ognuno può aggiungere qualunque significato, come ironia, rabbia, sarcasmo, o altro che pensiamo che rappresenti una persona, un evento, un riferimento ad un libro, un composto chimico o qualunque altra cosa.
- xhtml.com
- A volte l'XHTML 2 viene considerato un linguaggio "contenitore". Puoi dare la definizione di linguaggio contenitore? Quali cose saranno "contenute" dall'XHTML 2?
- Steven
L'architettura dell'XML del W3C permette di unire differenti linguaggi di markup in un singolo documento. Per esempio potresti avere un documento con XHTML, un po' di Matematica espressa in MathML, e alcuni grafici utilizzando SVG.
Abbiamo bisogno di terminologia per distingure i linguagggi di markup che potrebbero contenere siffatti documenti (cioè fornire l'elemento radice e la struttura), e linguaggi che sono solo disegnati per essere parte di un altro documento. L'XHTML e l'SVG rappresentano esempi di linguaggi che possono sia contenere, che essere contenuti, ma XForms, per esempio, è disegnato solo per essere contenuto. Il vantaggio di questo design è rappresentato dalla sua modularità. Ne consegue che non è necesario riempire l'HTML di nuove carattetistiche per i grafici, per il multimedia, matematica, e così via: basta utilizzare l'HTML per quello che serve, gestendo l'ipertesto, e lasciare che gli altri gruppi di esperti disegnino il markup ottimale per le altre aree, così che si possa poi combinare il tutto in un solo documento.
Microsoft Internet Explorer, per esempio, possiede un'implementazione quasi perfetta di questo concetto. Infatti permette di specificare quale pezzo di codice è responsabile per quale pezzo di markup (così come identificato dai namespace), e così, il tutto funziona. E possibile quindi unire un'implementazione SVG, un'implementazione XForms, un'implementazione MathML, e tutte funzioneranno bene in un singolo documento.
Ho detto quasi perfetto: l'unico problema è che è lo stesso documento che deve affermare quale programma deve fare, e che cosa, piuttosto che lasciare decidere all'utente. Dovrebbe essere l'utente a decidere quale implementazione SVG dovrebbe essere utilizzata: il documento dovrebbe restare neutrale.
- xhtml.com
- L'XHTML 2 introduce delle nuove costruzioni di markup come le liste di navigazione, una nuova struttura per gli heading, paragrafi migliorati, nuovi modi per i riferimenti alle immagini, un nuovo modo di creare collegamenti, e molto altro. Ci puoi descrivere brevemente queste nuove costruzioni e le ragioni per le quali sono state aggiunte?
- Steven
Molte di queste servono per una migliore struttura del documento, ed inoltre danno un grosso aiuto all'accessibilità e all'indipendenza dai dispositivi. Quando partimmo con l'XHTML 2 facemmo un'analisi di migliaia di pagine HTML per verificare in che modo le persone utilizzassero l'HTML. Uno studente Tedesco analizzò, per noi, decine di migliaia di pagine per vedere quali tag, attributi e nomi di classe venivano utilizzati, e così via. Il nostro scopo era verificare come le persone utilizzavano l'HTML, e verificare se vi erano dei casi d'uso da supportare. Le liste di navigazione attirarono la nostra attenzione. Puoi intenderle in varie forme: come barra di navigazione in testa alla pagina, o di lato, o come un menù di punti di navigazione; basta andare su ogni grande sito e se ne possono vedere dozzine di questi esempi. Marcandole in modo esplicito come liste di navigazione, non solo si struttura meglio la pagina, ma automaticamente si rende la pagine più accessibile. Quando una persona vedente va alla pagina, può rendersi subito conto del contenuto della stessa. Ma una persona non vedente, che lascia leggere la pagina dal browser, deve ascoltare tutta la lista di navigazione prima di arrivare al contenuto vero e proprio della pagina. Ora che la pagina dice - in un modo standard - cos'è la lista di navigazione e cosa invece non è, il browser può saltare direttamente al contenuto, lasciando la parte relativa alla navigazione come opzione per l'utente. Lo stesso accade per l'independenza dal dispositivo: su un dispositivo con un piccolo schermo è possibile scegliere di mostrare la lista di navigazione come menù, mentre su uno schermo più grande essa può essere mostrata come barre di navigazione.
La nuova struttura degli heading è simile. Nell'HTML attuale la struttura di una pagina è spesso solo accennata dai livelli di heading che sono utilizzati. Così una persona non vedente che arriva su un elemento h2 pensa che stia iniziando una nuova sezione. Ma se la sezione è seguita da un h4 (piuttosto che da un h3), la stessa persona non sa cosa sta succedendo. L'XHTML 2 permette di marcare in modo esplicito le sezioni di una documento; E questo non rappresenta un'ottima cosa solo per l'accessibilità: permette anche di realizzare browser che mostrino o meno le sezioni (importante per aver un'anteprima, o anche in situazioni in cui si usino piccoli schermi), e va molto bene per l'uso del PHP, in quanto è possibile importare una sezione senza preoccuparsi di dove sarà importata, di quale livello di heading dovrà avere.
Potrei continuare, ma spero di aver reso l'idea.
- xhtml.com
- Perchè l'XHTML 2 lascia inalterate alcune costruzione di markup come gli heading numerati, l'elemento
img e l'elemento a? - Steven
- Esiste un grosso dibattito e tensione fra coloro che vorrebbero vedere l'XHTML 2 come un linguaggio puro con l'uso solo delle nuove caratteristiche, e coloro che invece vorrebbero avere la possibilità di continuare ad utilizzare il vecchio markup, e lasciare il nuovo linguaggio retrocompatibile. In tale situazione, dove si cerca di raggiungere consenso, l'unica opzione possibile è lasciare anche il vecchio markup: così coloro che vogliono utilizzare il vecchio markup possono farlo, mentre questo può essere ignorato dai puristi.
- xhtml.com
- Nell'HTML 4 e l'XHTML 1, i controlli dei form, come i campi di testo, caselle di controllo e pulsanti di opzione permettono agli sviluppatori Web di costruire applicazioni Web interattive. L'XHTML 2 supporterà un nuovo meccanismo per i form denominato XForms. Cosa potranno fare gli sviluppatori Web con gli XForms che non possono fare ora?
- Steven
Gli XForms possono fare tutto quello che i form HTML già fanno, ed in più permettono di dire quali campi sono richiesti, o di quale tipo, o avere alcune limitazioni (per esempio, la data di partenza deve essere antecedente della data di ritorno), o che alcuni valori devo esere calcolati da altri (come per esempio l'ammontare di un pagamento che è la somma di tutti i valori).
Permette anche di precaricare dati in un form da Internet come valore d'inizio, e sostituirlo poi con risultati, il che significa che è possibile realizzare molte applicazione in stile Ajax senza aver bisogno di utilizzare script. Quando si hanno a disposizione gli elementi di input e di output, ed un motore di calcolo, è possibile realizzare una sacco di cose che sembrano applicazioni.
XForms, naturalmente, è disegnato per essere accessibile ed indipendente da ogni dispositivo. Questo significa, per esempio, che il markup non costringe ad utilizzare controlli particolari che siano necessari per un valore: sarà possibile utilizzare pulsanti di opzione su uno schermo grande, mentre i menù andranno bene per dispositivi dallo schermo piccolo.
Sembra che la comunità di XForms scopra nuovi utilizzi di XForms ogni giorno, ma l'utilizzo che più mi ha impressionato è una versione di Google maps, realizzata con una quantità 10 volte inferiore di codice.

- xhtml.com
- La caretteristica più eccitante in XHTML 2 è di sicuro l'attributo
role. Puoi descriverci come questo attributo favorirà l'accessibilità del Web e renderà più semplice avere risultati più rilevanti quando si ricerca sul Web? - Steven
- Sembra che le cose nuove in XHTML 2 eccitino varie comunità, ma l'attributo
role è stato subito adottato da molti e differenti gruppi. Esso è parte di alcune caratteristiche, che ho descritto prima, per aggiungere semantica agli elementi. L'attributo role permette di dire cosa debba fare un elemento (hai mai visto una pagina Web che sembra essere composta solo da migliaia di div annidati?). Ciò permette al software di fare molte cose utili con il contenuto, a seconda se questi è un motore di ricerca, un browser o un server. Per l'accessibilità si potrebbe identificare quale parte della pagina è dedicata alle news ed usare uno shortcut per arrivare fin là direttamente; un server potrebbe trasformare la pagina in automatico così da renderla più fruibile per un piccolo dispositivo. - xhtml.com
Se una pagina Web XHTML 2 contiene errori nel markup, come per esempio un tag di chiusura mancante o elementi annidati in modo non corretto, la maggior parte del browser mostrerà un messaggio di XML parsing error come quello mostrato qui in basso.

Poichè ormai ci siamo abituati al fatto che i browser Web facciano aggiustamenti per il markup non valido, e di conseguenza facciano il rendering di quasi ogni cosa, incluso il "tag soup", non pensi che molti utenti trovino piuttosto spiacevole il fatto che questi browser rifiutino di rendere al meglio le pagine con markup XHTML 2 che presentino errori? E' stato discusso questo aspetto nel W3C? E quali sono le soluzioni possibili che si intravedono per migliorare l'esperienza utente?
- Steven
Esistono molte possibili risposte a questa domanda. In prima battuta dovrei dire che questo non è un requisito di XHTML 2 ma di XML. E poiché XHTML 2 è in XML, esso eredita la regola. Ma prova a guardare questa cosa sotto questo aspetto: se tutti i browser si rifiutano di mostrare le pagine non corrette, l'unica persona che non vorrebbe mai vedere tale messaggio d'errore sarebbe proprio l'autore della pagina, che così la correggerebbe subito. E questo sarebbe già un grosso miglioramento della situazione attuale. Perché? Se una pagina non è corretta, il browser la dovrebbe correggere. Ma browser diversi correggono le pagine in modo differente, così che una pagina che è stata corretta dal browser di sicuro sembrerà diversa con browser differenti. Potrei mostrarti dozzine di immagini riprese dallo schermo di pagine che funzionano solo con alcuni browser a causa degli errori di markup. Così direi che la nuova regola ha la possibilità di migliorare l'esperienza utente. Ma solo se tutti i browser sono d'accordo ad implementare la regola.
Ora, da un altro aspetto: supponi che tutti i compilatori correggano gli errori nei programmi...non è tanto male sul Web, ma è equivalente.
- xhtml.com
- Programmi promozionali come AdSense di Google al momento non funzionano quando le pagine sono servite come XML. Questi programmi sono molto popolari, e il mostrare questi banner pubblicitari sui loro siti diventa un'importante fonte di reddito per piccoli fornitori di contenuto. Cosa si sta facendo per permettere che questi programmi funzionino con XHTML 2?
- Steven
- Sono stato rassicurato sul fatto che vi sarà una modifica.
- xhtml.com
- L'XHTML 2 è in questo momento nello stato di Working Draft. Quali sono i tempi previsti per far avanzare il processo verso lo stato di Recommendation?
- Steven
- Stiamo lavorando alacremente per portare l'XHTML 2 al last call, ma dobbiamo prima rispondere a tutti i commenti, e abbiamo ricevuto migliaia di commenti! Dovremmo arrivare al last call entro quest'anno. Poi vi saranno problemi di implementazione, anche se so per certo che tre (browser, ndt) sono già pronti, così da essere ottimista su questo fronte.
- xhtml.com
- Qual è l'importanza del feedback proveniente dalla comunità esterna? A quale stato del processo di approvazione, altre persone (non membri del W3C) potranno fornire feedback a quelli che invece stanno scrivendo la specifica XHTML 2?
- Steven
- E' molto importante! Chiuque può fornire feedback ad ogni stato del processo. In effetti il raccordo con i commenti di feedback rappresenta l'attività che richiede maggior tempo. Abbiamo ricevuto diecimila commenti e dobbiamo tenerne conto e rispondere a tutti.