Leggendo qua e là opinioni circa la possibilità o meno di usare HTML5 sui siti pubblici in conformità alla legge Stanca, uno degli argomenti che vedo ripetere è che non si dovrebbe usare HTML5 perché non è ancora una specifica ufficiale.

L’argomento sembra convincente, sia per il buon senso che per la lettera del regolamento attuativo della legge. In effetti:

1. non è robusto usare una specifica che non è ancora stata ufficialmente pubblicata
2. il requisito 1 dice di usare “ tecnologie definite da grammatiche formali pubblicate, nelle versioni più recenti disponibili quando sono supportate dai programmi utente”. Se HTML5 non è una grammatica formale pubblicata, non dovrebbe esser lecito usarla, giusto?

Un nuovo modo di produrre le specifiche

Questo argomento, però, non tiene conto di un paio di cose. Anzitutto, che HTML5, ma anche CSS3, è una specifica in progress che incoraggia l’implementazione delle proposte nei browser, per poter vedere cosa funziona e cosa no, cosa prende piede e cosa attecchisce fra agli sviluppatori, per modificare eventualmente le proposte e giungere dunque ad una specifica migliorata. Questo non era il modo in cui tradizionalmente le specifiche di HTML o di XHTML venivano prodotte. Certamente, la conseguenza di questo processo è quello di avere specifiche che cambiano anche brutalmente. Tuttavia, accanto a parti della specifica che cambiano, ve ne sono alcune già ben supportate e relativamente stabili tanto da essere utilizzabili (se ne può avere un’idea visionando caniuse.com). Impedire alle PA di usare le feature di HTML5 più stabili significa anche tagliarle fuori da ogni ruolo nel processo di sviluppo di questa specifica. Tanto più per gli aspetti relativi all’accessibilità che le sono propri.

Solo HTML o anche CSS?

C‘è però anche un’altra questione dubbia. Il principio di “pubblicazione ufficiale” vale solo per l’HTML o anche per i CSS? Di fatto, benché non sia una grammatica ufficiale di marcatura, CSS è pur sempre una specifica, una “grammatica formale” (ha un vocabolario ed una sintassi), ed è utilizzata per le pagine web. Avrebbe senso che lo stesso criterio di stabilità valesse per HTML, per CSS, e per qualunque linguaggio utilizzato. Si stenta a vedere una ragione per cui si dovrebbero differenziare i tipi di linguaggi.

E allora, non si può non notare che anche i CSS3 si sviluppano secondo un percorso modulare che è ben lontano dal vedere una pubblicazione definitiva. Per di più, d’ora in poi procederanno a moduli, cosicché un modulo CSS4 può diventare raccomandazione prima di un altro modulo CSS3. Non sarebbe il caso che la legge (o meglio i regolamenti attuativi) prendessero atto e dimostrassero consapevolezza di questa nuova tendenza (chiamiamola così) più realista nel processo di sviluppo delle specifiche e includessero delle formule meno stringenti, che tenessero conto soprattutto dello stato di implementazione delle feature negli user agent, che poi è quello che importa davvero a qualunque utente, disabile o meno?

E se ci fossimo sbagliati?

Certo, poi può darsi che il requisito 1 non vada inteso in senso restrittivo. E che non si riferisca a grammatiche formali pubblicate nel senso che abbiano raggiunto lo status di “raccomandazione”. Anche una bozza in “Last call” è una pubblicazione: a cambiare è il suo stato, e il requisito 1 parla di grammatiche formali pubblicate e non dello stato o della stabilità in cui devono essere.

A pensarci, potrebbe davvero essere questa l’interpretazione più sensata. Perché altrimenti c‘è da credere che tutti i siti pubblici “a norma” pubblicati prima di giugno 2011 e che facevano uso di CSS2.1, dovessero in realtà essere considerati non conformi.

Come, perché?

Perché fino a giugno 2011 CSS2.1 non era una specifica ufficiale, of course…