Corsi e Ricorsi storici

 

La rincorsa dei Web Designer agli standard di marcatura del linguaggio dettati da quella grande organizzazione che è il W3C continua a non avere fine. Eppure una sorta di equilibrio con l’avvento dell’XHTML e dei CSS2 lo si era trovato, un equilibrio risultante più dalla fantasia dei designer stessi che dallo stretto attenersi alle specifiche consigliate. Tutto ciò nel nome di quella “chimera” conosciuta come “cross-browser compatibility”, la compatibilità multi piattaforma, che in teoria dovrebbe permettere la stessa, o quanto meno simile, interpretazione del lingiaggio HTML nei vari browser presenti oggi sul mercato.

I tempi in cui si ricorreva a codice Javascript o a regole di eccezione negli stessi CSS per adattare determinati comportamenti o visualizzazioni del sito web a seconda del browser utilizzato dall’utente sono pressapoco terminati. Questo grazie al grande balzo in avanti che hanno fatto alcuni interpreti di browser più diffusi. Basta pensare al famigerato Internet Explorer, che nella sua versione 8 ha finalmente colmato un gap, divenuto ormai insostenibile, che lo separava da altri prodotti come Firefox, Opera e Safari.

Tale balzo e l’ottima implementazione della semantica e dei CSS2 hanno contribuito alla produzione di codice HMTL meno “cervellotico” e più manutenibile, che ha permesso agli sviluppatori, forti della loro esperienza, di avere più meno lo stesso risutlato sulle varie piattaforme, facendo risparmiare tempi di produzione in precedenza ancorati a stressanti test di compatibilità del sito web.

L’annuncio in pompa magna da parte del W3C dell’imminente approvazione delle nuove specifiche dell’HTML5 ha destato grande interesse nella comunità degli sviluppatori, interesse purtroppo anche accompagnato da un timore: rompere l’equilibrio trovato e tornare al punto di partenza. In rete si trovano tantissimi articoli sulle novità introdotte da questo aggiornamento del linguaggio, uno degli aggiornamenti che ha richiesto più tempo di tutti i precedenti e che allo stato attuale non ha ancora raggiunto lo status di raccomandazione ufficiale del W3C. Inviti a testare le nuove funzionalità multimediali e non, pongono in fermento chi si occupa di HMTL da anni e le promesse di semplificare e di oltrepassare vecchi limiti del linguaggio di marcatura contribuiscono a mitizzare questa rivoluzione annunciata. Per carità, le anticipazioni e gli esempi proposti sembrano davvero rivoluzionari, ma la domanda rimane la stessa: tutti i browser saranno capaci di supportare il nuovo linguaggio? In un immediato futuro si presuppone di sì, ma allo stato attuale delle cose c’è il rischio di tornare ai tempi in cui bisoganva trovare soluzioni fantasiose per ottenere compatibilità multi-browser, considerando anche che i test attuali dimostrano come i due browser che sono più avanti degli altri sulla rincorsa dei nuovi standard HMTL5 sono Opera e Safari; decisamente non i più diffusi.

Approfondendo questo argomento è da sagnalare un articolo su A List Apart che descrive l’utilizzo di una interessante libreria Javascript che prende il nome di Modernizr. Tale libreria una volta scaricato il pacchetto .js e incorporato nei tag <head> del documento HMTL

<!DOCTYPE html>

<html>

<head>

<meta charset=”utf-8″>

<title>My Beautiful Sample Page</title>

<script src=”modernizr-1.5.min.js”></script>

</head>

ha l’abilità di riconoscere quale browser l’utente sta utilizzando e il suo livello di compatibilità con l’HTML5. Modernizr sarà in grado di rendere attivi tutti quegli elementi CSS3 e HTML5 inseriti dallo sviluppatore, mentre se il browser scelto non è ancora compatibile con il linguaggio, le nuove regole saranno interpretate alla vecchia maniera. Tutto ciò senza preoccuparsi di inserire regole condizionali nel css a seconda del browser che si usa, in quanto è lo stesso script che rileverà l’user-agent automaticamente. Quello che bisogna fare è aggiungere una classe al tag <html> a questa maniera:

<html>

Modernizr rimpiazzerà la classe con una nominata “js” che ti permetterà di sapere nel tuo documento se è attivato lo javascript o meno. Ma non si ferma qui: aggiungerà classi per ogni proprità riconosciuta, modificando la classe con un prefisso “no-” se il browser non supporta quell’elemento o attributo. Un esempio di elemento <html> con Modernizr è il seguente:

<html class=”js canvas canvastext no-geolocation rgba hsla multiplebgs borderimage borderradius boxshadow opacity cssanimations csscolumns cssgradients cssreflections csstransforms csstransforms3d csstransitions video audio localstorage sessionstorage webworkers applicationcache fontface”>

Notare il “no-geolocation” che dovrebbe significare il non supporto di quel browser per tale proprietà HTML5. Maggiori informazioni e documentazione comunque possono essere trovate sul sito ufficiale dello script.

A prima vista parliamo di un ottimo strumento per poter sperimentare l’attuale compatibilità dei browser, ma ancora una volta si tratta di un “trick” ben lontano dalla filosofia perseguita dal W3C. Fino a che i browser non saranno tutti allineati toccherà sperimentare e sperimentare, rendendo lo sviluppo di applicazioni web sempre più contorto. In questo caso però, non mi sento di dare tutta la colpa agli sviluppatori di browser, è verò anche infatti che lo stesso W3C, fino a quando non ufficializza le nuove specifiche, implicitamente consente alle case produttrici di browser di prendersi le tempistiche che vogliono.

Il cane continua a mordersi la coda così come accadde nella metà degli anni 90 con la guerra dei browser. A farne le spese rimangono gli sviluppatori. Un potenziale cliente bada al risultato, il mezzo per raggiungerlo tecnicamente sta agli sviluppatori stessi, e in certi casi è quasi un dovere sacrificare gli standard in favore di soluzioni che non lo sono, ma che permettono di risolvere problemi di compatibilità. Tutto ciò lo sento ancor più giustificato nel momento in cui sul mercato ci sono strumenti non completi al cento per cento nel supporto di nuove tecnologie.

A tali problematiche si aggiunge quella inerente l’accessibilità dei siti web e la garanzia del supporto dell’HTML5 alla stessa. Ciò che preoccupa è che le maggiori novità introdotte da tale linguaggio si concentrano molto su elementi multimediali del web e si spera che ciò non avvenga a discapito degli elementi di usabilità di un sito, anche se pare che negli ultimi sviluppi l’importanza semantica di un documento e la sua marcatura stia facendo la parte del leone.

La corsa continua.

“…For the times they are a-changin’…” -Bob Dylan

Marco Marasco, web developer Asernet

Informazioni su redazione

www.gargano.it

Pubblicato il ottobre 25, 2010, in Comunicazione con tag , . Aggiungi il permalink ai segnalibri. Lascia un commento.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: