Il W3C in quasi 10 anni d’attività ha rilasciato nel tempo svariate versioni del linguaggio di marcatura HTML cercando di perfezionarlo nelle sue rappresentazioni sui dati e nella sua universalità tra le piattaforme, dalla versione 2.0 alla versione 4.0 e poi passando a XML con XHTML 1.0 e 1.1.

Nel corso di queste trasformazioni del linguaggio il W3C si è sempre dato, tra i suoi obbiettivi, quello di mantenere al meglio l’interoperabilità del linguaggio. Questo vuol dire che le versioni rilasciate, allo stato della tecnica di quel momento, dovevano rendere fruibili le informazioni “marcate” e le relative strutture dati su qualunque piattaforma di navigazione potesse accedervi o almeno questo era l’intento.

Infatti fino alla versione 4.0 si era in mezzo ad una vera e propria guerra degli standard dove i produttori di browser non guardavano in faccia a nessuno pur di accaparrarsi il mercato e inserivano liberamente all’interno dei loro browser delle marcature proprietarie che spesso non rispettavano i principi che portava avanti il W3C. Si arrivò dunque ad avere una versione 3.2 dell’HTML piena di queste marcature proprietarie. Poi nel momento di definire la versione 4.0 dell’HTML avvennero alcune piccole rivoluzioni, la guerra dei browser era oramai finita e Microsoft Internet Explorer dominava quasi interamente il mercato ma in parallelo ci si iniziava ad interrogarsi sull’incompatibilità del codice tra le piattaforme.

L’allora gruppo di lavoro dell’HTML 4.0 si trovo quindi di fronte a dover fare una scelta di separazione tra le varie marcature di HTML. In pratica si opto per mantenere una versione strict che fosse il più possibile ripulita da marcature proprietarie e fosse il più interoperabile possibile, una versione transitional che permettesse una retrocompatibilità con le marcature proprietarie o obsolete e una frameset che servisse solo a descrivere le strutture a frame che di per se non rappresentano alcun tipo di dato ma permettono delle rappresentazioni grafiche particolari.

Una seconda piccola rivoluzione si ebbe quando arrivarono le due nuove idee del W3C, il web semantico e l’iniziativa per l’accessibilità del Web, che obbligarono il W3C a ripensare i suoi linguaggi orientandoli anche verso l’accessibilità e la purezza dei dati.

Il grande lavoro svolto

Il nuovo gruppo di lavoro aveva il compito di revisionare l’HTML 4.0 in una versione più evoluta e compatibile con le due iniziative, chiamata HTML 4.01.

In questa versione globalmente si introdussero una serie di attributi atti a migliorare l’accessibilità dei documenti come gli accesskey o i tabindex, che poi furono portati anche nella versione 4.0 in una sua revisione.

Il grosso del lavoro fu invece fatto sugli elementi base dell’HTML dove fu formalmente eliminato ogni tipo di attributo o di elemento legato ad uno specifico funzionamento o rappresentazione visuale. Con questo furono messi sotto deprecated tutti gli attributi come bgcolor, align o valign inoltre furono deprecati anche gli elementi visuali come CENTER.

In pratica dopo questa revisione si ottenne un linguaggio che nella sua versione strict non contemplava nulla che non fosse orientato a strutturare i dati, e quindi mantenerne l’accessibilità e la fruibilità il più integra possibile. In più si aveva anche una versione transitional che era anch’essa ripulita, ma possedeva ancora una serie di elementi deprecati che ne potevano sporcare il codice.

Lo strict e l’accessibilità, il connubio perfetto

Se ragioniamo in un ottica di accessibilità dove si richiede che un contenuto sia percettibile, fruibile e usabile (limitiamoci qui) da qualunque utente, su qualunque piattaforma con qualunque browser in qualunque situazione (entro i rigor di logica) l’HTML 4.01 strict o ancora meglio l’XHTML 1.0 strict, che è la trasposizione in XML dell’HTML 4.01, sono la panacea a quasi tutti i mali. Infatti le strutture dati rappresentate in questo modo sono completamente libere da vincoli visuali (a condizione che si rispetti il formalismo semantico dei tag, in pratica non usare le tabelle per fare la grafica) e sono anche molto leggere in termini di peso in KiloBytes. Questo ci permette di rispettare completamente le condizioni d’accessibilità sopraccitate e soprattutto di essere completamente interoperabili non avendo alcun vincolo visuale.

Lo strict del futuro

Il W3C sta già preparando i linguaggi del futuro tra i quali ha già rilasciato l’XHTML 1.1, nel quale non ha dovuto praticamente fare alcuna modifica a livello di interoperabilità e accessibilità visto che era già completamente garantita dall’XHTML 1.0 ma in compenso ha definito la nuova via nello sviluppo dei linguaggi.

Infatti oltre ad integrarlo meglio con XML sotto l’aspetto delle versioni è stata abbandonata la filosofia del transitional e dello strict, optando per una sola versione strict che sia estendibile tramite DTD in SGML personalizzate, il che vuole dire che il linguaggio base e le informazioni da lui descritte da oggi in avanti saranno sempre accessibili e interoperabili, e se qualche sviluppatore web voglia usare elementi deprecati se li dovrà caricare tramite dei moduli a parte e se invece vorra adottare degli elementi proprietari se li dovrà implementare nella definizione del linguaggio, rischiando però di non trovare un adeguato supporto sulle varie piattaforme e nei vari browser.

Si vede che in fondo il vecchio Tim aveva ragione:

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”