Cosa viene dopo Ajax?

Se lo chiede anche Dare Obasanjo, soprattutto perché quello che arriverà dopo Ajax è sicuramente benvenuto.

Sviluppare un’applicazione Ajax, infatti, è un incubo.

In primo luogo occorre mischiare standard come Html e Css che sono standard solo nella testa di quelli che li scrivono.

Le mailing list dedicate al disegno Web sono piene di richieste curiose, tipo “come faccio a mettere questo a sinistra e quello a destra?”. Non sono le domande di neofiti che non sanno come scrivere una tabella: sono le domande di professionisti che hanno rinunciato alle tabelle.

I signori del W3C, che sono convinti di avere la proprietà del Web, quelli che hanno dichiarato morto Html nel 1999 per intenderci, sono riusciti a fare dimenticare a tutti che creare pagine Web è un compito banale, anche perché i browser accettano qualsiasi schifezza nel markup uscendo vittoriosi dalle cose peggiori.

Adesso però occorre validare le pagine anche per legge per l’ottimo motivo che si vuole rendere accessibile il contenuto su Internet a tutti, anche ai disabili. In fondo – si dice – progettando le pagine con la stretta aderenza agli standard si ha anche il vantaggio di avere pagine di migliore qualità.

Però poi lungo la strada si scopre che occorrono trucchi e trucchetti a non finire per riuscire a avere una presentazione accettabile in Firefox, Internet Explorer (il 6 e il 7) e magari anche Safari.

Alla fine, poi, si scopre che è quasi impossibile creare l’applicazione dinamicamente Web 2.0 e Ajax che ha chiesto il cliente o che fa la concorrenza, che vince la gara. 

Il motivo è strutturale, non è colpa di una momentanea combinazione di eventi che si risolverà in breve tempo. Si tratta del fatto che Html è standardizzato in modo da farne un linguaggio statico che formalizza il ruolo di segmenti di testo in un documento, ma non ha nozioni di dinamica. E questo non può essere superato.

Per essere più chiaro farò un esempio: posso fare una barra di navigazione con una lista puntata, facendo due salti mortali con la formattazione Css e (aiuto!) quattro salti mortali con il posizionamento via Css fino a ottenere una barra di navigazione orizzontale.

Si può obiettare che lo sforzo è eccessivo per il risultato, ma lo hanno fatto tutti i progettisti.

Il problema è che alla fine, nessuno è in grado di dire a un lettore di schermo “guarda che questa è una barra di navigazione orizzontale”, dopo che abbiamo fatto di tutto per renderla niente altro che una <ul> di classe “navbar”.

Lo screen reader, per abile che sia vedrà solo una lista puntata. Lo stesso screen reader analizzando una form scritta in Visual Basic saprà fin dall’inizio qual è e cosa contiene la toolbar di una finestra.

La chiave dei problemi di accessibilità sta quindi nella mancanza di espressività del linguaggio: se non si può spiegare che una UL è una barra di navigazione, come farà mai uno screen reader a orientarsi?

Questo è un problema che affligge Html in quanto tale e quindi qualunque applicazione Ajax in cui un link viene usato come pulsante, come menu o chissà che altro.

Sembra difficile uscirne, senza considerare di importare nel linguaggio strumenti per descrivere l’intenzione (“questo link è un pulsante, questa è l’azione e questo è il messaggio di aiuto associato”).

Una possibile via di uscita da questo problema, quindi, sembra Html5, un lodevole sforzo di fare marcia indietro sulla purezza asettica e inutile di Xhtml alla ricerca di quella espressività che serve per creare applicazioni e non solo documenti statici.

Il gruppo di lavoro ha inviato una proposta per l’adozione dello standard al gruppo di lavoro dedicato a Html.

Anche Html5 ha qualche problema, comunque. Google, Yahoo e gli altri leader dell’innovazione Web hanno imparato a usare qualsiasi cosa in qualsiasi modo per creare pagine dinamiche e piacevoli da usare muovendosi in un territorio che non ha uno schema fisso come il toolkit Windows.

Non ci sono, cioè, pulsanti, barre di menu, elenchi a discesa, barre di strumenti, ma si usa quello che capita per pilotare l’interazione. Gli utenti hanno mostrato di apprezzare il dinamismo del Web 2.0.

Sarà difficile quindi rientrare in uno schema controllato: è troppo tardi.

E non finisce qui: sviluppare un’applicazione Ajax è un incubo perché la frammentazione non riguarda solo gli standard, ma anche gli elementi che compongono l’appliazione, che gira contemporaneamente in tante realtà diverse.

Su questo torneremo in seguito.

One thought on “Cosa viene dopo Ajax?

  1. Bisogna intanto che AJAX arrivi!

    Io ho una opinione: l’ accessibilità è Web 1.0…

    L’ accessibilità, come tu noti è quello che ha portato alla strada dell’ XHTML, seprazione netta tra forma e contenuti. Distinzione sacrosanta in ambito editoriale, non sense quando si lavora con il “Web As Platform”.

I commenti sono chiusi.