Sembra un paradosso o forse più una provocazione ma è questa, in sintesi, la spiegazione del perché l’ottava release del browser made in Redmond collezioni un misero 20/100.
Dopo tanto parlare dei concorrenti, tra cui Opera e Safari, che superano a pieni voti oppure ci vanno molto vicini (Chrome), la posizione di Gates e soci rischia di apparire non solo una voce fuori dal coro ma più una scusa per cercare di giustificare i ritardi accumulati nei confronti proprio dei competitor citati.
Eppure, secondo le dichiarazioni di un evangelist Microsoft Australia, il nocciolo della questione verte su un’argomentazione molto semplice: Internet Explorer 8 non supera l’Acid Test 3 perché quest’ultimo non è completamente basato su standard ratificati.
Nonostante le parole di Nick Hodge possano sembrare un attacco frontale alla metodologia forse più in voga negli ultimi tempi per stabilire un giudizio qualitativo dei browser e dei motori di rendering associati, appare chiaro come la scelta sia stata meditata e compiuta scientemente durante il percorso di sviluppo e miglioramenti che ha coinvolto IE8.
Resta da capire se la strategia parzialmente “contro corrente” sia effettivamente quella corretta per interpretare i principi che ispirano il W3C e quali sono invece le preoccupazioni in merito (anche in chiave commerciale e di business) da parte di Microsoft stessa.
Prima però bisogna rispondere ad una banale domanda: è vero che le modalità le quali compongono la terza versione dell’Acid Test comprendono anche tecnologie non ancora approvate?
Per risolvere il quesito dobbiamo necessariamente fare un passo indietro.
Che cosa significa il termine “standard”?
Nella letteratura informatica rappresenta la piattaforma comune, un insieme di caratteristiche codificate per la realizzazione di tecnologie che siano compatibili ed interoperabili; in italiano anche per la forte tradizione giuridica si utilizza come sostituta la parola “norma”.
Esistono poi diversi enti internazionali (il più famoso dei quali è probabilmente l’ISO di cui avrete già sentito parlare) che si occupano di discutere e ratificare le norme che in questo caso definiscono il cosiddetto standard “de iure“; si tratta cioè di un’astrazione in primis creata dal diritto che solo successivamente diventa prodotto commerciale.
Ma proprio come avviene nella giurisprudenza, da cui è stata mutuata l’espressione, il processo può essere anche inverso, dal basso verso l’alto.
Può accadere cioè che, per vari motivi, una tecnologia o una sua particolare implementazione diventi standard di fatto; de facto (dall’originale latino) perché è la prassi che si sostituisce in qualche modo all’ente regolatore nella sua funzione di creazione.
L’esempio più immediato è lo stack di protocolli TCP/IP (protocolli, ovvero insieme di regole; quindi ritorna la parola “norma” che viene sostituita a “standard”).
La distinzione fino a qui sembra piuttosto chiara; c’è però un fattore di complicazione da aggiungere.
Nel processo di creazione di uno standard de iure esistono diversi stadi intermedi precedenti alla ratificazione vera e propria. Come è normale che sia, la decisione passa attraverso fasi di dialogo tra bocciature, revisioni parziali di bozze e la necessità di approvare di volta in volta, a seconda dell’ente preso in esame, con un proprio sistema di votazioni.
Il meccanismo è talmente complesso per cui accade non di rado che le aziende, in un contesto di time to market ristretto, utilizzino specifiche non ancora definitive nei propri prodotti.
E’ questo ad esempio il caso del protocollo 802.11 n, il quale si spera entro uno o due anni possa arrivare a definitivo compimento. Ma ci sono casi in cui possono rimanere “bozze” per decenni.
Ogni organizzazione documenta inoltre le fasi di approvazione con nomenclature ad hoc. Riguardo ai protocolli di rete di cui si occupa l’IETF si vede spesso l’acronimo RFC (Request For Comments) che delinea solitamente le specifiche del protocollo stesso.
Nel contesto di cui ci occupiamo, ovvero il Web, il consorzio W3C applica un suo iter normativo, il quale culmina con la Recommendation (o REC), la fase cioè che sancisce la ratificazione di uno standard.
E’ bene sottolineare la scelta non casuale del termine poiché la sua decisione in materia, a differenza di altri organismi, non ha carattere vincolante; mentre per costruire o montare ad esempio apparati energetici (quali la caldaia) occorre seguire le indicazioni definite nelle varie norme ISO ad hoc altrimenti si rischia con tutta probabilità di entrare nella sfera dell’illegalità, uno sviluppatore può benissimo rilasciare un’applicazione web che non sia aderente ai formati o protocolli descritti nella documentazione W3C.
Dopo questa forse noiosa ma necessaria digressione, torniamo dunque alla domanda iniziale: l’obiezione Microsoft ha fondamento? E’ vero che l’ Acid 3 non prevede esclusivamente test basati sulle W3C REC?
Sì, è vero. In particolare, alcune specifiche dei CSS 3 si trovano ancora nello stato di working draft. Idem dicasi per il tanto discusso HTML 5.
Nick Hodge sottolinea come IE8 raggiunga il 100/100 per quanto riguarda l’Acid 2 il quale, al contrario, sì utilizza prove sviluppate secondo standard pienamente codificati; l’evangelist australiano, e questa è tutto sommato una sorpresa considerato che stiamo parlando di una voce ufficiale (e non da ieri) Microsoft, aggiunge che è stato l’insegnamento della versione 6 di Internet Explorer e del fatto che il suo cattivo rendering sia stato dannoso per tutti i webdev a guidare questa scelta nello sviluppo del software.
Afferma infatti:
– “We passed Acid2 with 100 percent which tests against recommendations from the W3C. Acid2 is about recommended standards, standards that are locked and loaded. Microsoft has to think about the future rather than getting 100 out of 100 and make ourselves look like heroes. Our learning comes from IE6. With IE6 we adopted some non-recommended standards and interpreted them in a certain way. The end result of that has been painful web development.” –
E’ interessante notare l’ammissione di parte delle responsabilità per aver fomentato l’attuale situazione di caos e di difficile interoperabilità, così necessaria in un’epoca dominata dagli accessi sempre più mobili.
Un cambio di rotta che è stato collocato in una nuova strategia ed apertura sia verso la filosofia Open Source sia più in generale nel seguire standard codificati senza imporre a tutti i costi la propria visione del mondo IT, utilizzando che quel che già esiste e tutto sommato funziona.
A questo proposito Hodge aggiunge:
– “Microsoft is looking at being pragmatic, we passed Acid2 recommendations, and as standards evolve and become recommendations we will adopt them,” Microsoft’s Hodge said.” –
Qui potete leggere l’intero dibattito.
L’Acid3 è dunque criticabile e certo non va preso come oro colato o come unico banco di prova attendibile per la valutazione della validità di un browser; qualche mese fa lo stesso Web Standards Project, gruppo di professionisti responsabili del test, ha messo in guardia i navigatori fa della necessità di non ridurre il tutto ad un punteggio o una competizione a premi.
Va però aggiunto che se ci sono formati e protocolli non ancora ratificati nelle ultime revisioni raggiunte, alcuni di questi sono utilizzati all’interno dell’Acid3 nella loro forma di Recommendation che Internet Explorer avrebbe potuto rispettare, risultando essere maggiormente standard-compliant di quanto non lo sia ora.
Ed è il caso della tanto criticata assenza di SVG versione 1.1sufficiente a far superare positivamente proprio l’Acid3. Non ci resta che seguire l’evolversi della vicenda.
