Il W3C è forse il più importante consorzio per quanto riguarda la definizione degli standard utilizzati su internet, come ad esempio HTML, CSS e JavaScript. Le indicazioni del W3C non sono legge, ma linee guida che i produttori di software dovrebbero seguire in fase di progettazione dei prodotti, o meglio ancora dovrebbero contribuire a definire collaborando con il W3C.
Ogni azienda, agenzia o singolo sviluppatore ha la libertà di scegliere se e come aderire agli standard W3C: alcune aziende hanno ignorato questi standard per anni, altre hanno sempre prestato la massima attenzione alle indicazioni del consorzio. Le linee guida del W3C mirano soprattutto a fornire suggerimenti a chi realizza software su larga scala, in primis i produttori dei web browsers, e non tanto al singolo sviluppatore. E' importante sottolineare quanto appena detto: gli standard del W3C impattano il lavoro dello sviluppatore solo di riflesso, mediante una sorta di side-effect. Lo sviluppatore lungimirante rispetta gli standard perché i produttori di software potrebbero, un domani, aderire a dettami del W3C che oggi sono rispettati solo parzialmente. Seguire una pratica prima che essa diventi un standard di fatto serve a garantire la longevità del codice, riducendo il bisogno di manutenzione. In parole più semplici potremmo dire che molti sviluppatori usano gli standard del W3C per “tirare ad indovinare” come saranno i browser del futuro, e giocare così in anticipo.
Da questo punto di vista, chi sviluppa del codice per un progetto medio-piccolo è più libero, rispetto ad un grosso produttore, di ignorare (o meglio “aggirare”) gli standard W3C. Onde evitare di essere fraintesi, vediamo un esempio concreto: la dichiarazione dei fogli di stile in una pagina HTML.
Il consorzio W3C suggerisce di definire tutti i link ai fogli di stile nella sezione head, prima del body della pagina. In alcuni casi, soprattutto se parliamo di design reattivo (o responsive design), può essere necessario caricare un foglio di stile a runtime, che potrebbe dipendere dalle azioni svolte dall'utente. In situazioni come questa è normale porsi una domanda: è meglio definire tutti i possibili fogli di stile nella sezione head, come suggerisce il W3C, oppure ignorare lo standard e definirli nella sezione body della pagina, all'interno di un blocco condizionale JavaScript?
Per quanto sia corretto porsi domande come questa, ciò indica una comprensione parziale delle motivazioni che portano alla definizione di uno standard. Gli standard W3C indicano come andrebbe scritta una pagina HTML, definite le proprietà CSS, sviluppato il codice JavaScript ecc. Ciò significa che è bene aderire agli standard soprattutto quando ci concentriamo su un'unica tipologia di risorse, ovvero quando stiamo scrivendo del codice HTML “puro” o un blocco di codice JavaScript “astratto”. Nella pratica, per nostra fortuna, le cose non sono mai distinte ma operano in concerto, come discusso in questo articolo.
Volendo fare un'analogia, potremmo dire che HTML, CSS e JavaScript sono le “portate” di un pranzo, ad esempio primi piatti, secondi piatti e dessert. Un buon libro di ricette (il consorzio W3C) può indicarci come preparare un primo piatto, cucinare un secondo piatto o preparare un dolce, ed è bene seguirne le indicazioni. Ma quando si tratta di preparare un menu, ovvero mettere insieme diverse portate, gli standard possono essere aggirati per ottenere il risultato che ci serve.
In termini più rigorosi ciò significa che gli standard HTML, CSS e JavaScript non vanno confusi con gli standard DHTML, che sono invece le linee guida da seguire quando mettiamo insieme diverse tecnologie per creare una pagina ricca e funzionale.
Tornando al nostro caso concreto (la definizione dei fogli di stile), vediamo come passare dalla teoria alla pratica. Chiedersi se aderire rigidamente ad uno standard o se ignorarlo è un po' come ragionare in bianco e nero, senza considerare le sfumature di grigio. Invece di scegliere tra due soluzioni estreme, una via d'uscita potrebbe essere quella di aggiungere il foglio di stile all'albero del DOM, in modo da caricarlo esattamente “dove” suggerisce lo standard, ma di farlo a runtime, mediante un codice come questo
linkElement = document.createElement("link");
linkElement.rel = "stylesheet";
linkElement.href = "foglio_di_stile.css";
Questo dovrebbe spiegare perché parliamo di “aggirare” lo standard anziché ignorarlo. Qui sopra stiamo lavorando in modo tutto sommato corretto, perché non abbiamo inserito alcun link al foglio di stile dentro il body HTML della pagina. Rispettiamo lo standard anche perché, dal punto di vista del DOM, ogni cosa è al suo posto.
La soluzione qui sopra non è l'unica possibile, ma dovrebbe chiarire come vanno interpretati gli standard. Il modo corretto di chiedersi se il codice qui sopra è conforme alle indicazioni del W3C non è quello di confrontare il codice con gli standard HTML, CSS o JavaScript, bensì di controllare quali sono le linee guida DHTML per operazioni di questo tipo.
L'esempio dovrebbe suggerire un diverso approccio alla questione. Con l'avvento di Ajax, il web 2.0 e le Rich Internet Application è piuttosto raro trovare delle pagine HTML davvero statiche: la maggior parte degli sforzi di sviluppo va esattamente nella direzione contraria, ovvero creare pagine reattive, dinamiche e flessibili. Si potrebbe dire che lo scopo di uno sviluppatore, nel momento in cui tira in ballo JavaScript, jQuery, Prototype o altri strumenti di lavoro, è proprio quello di “rompere” la rigidità di una pagina, dove per “rompere” si intende cambiare o ristrutturare, e non distruggere.
Ciò significa che è corretto aderire agli standard finché lavoriamo su una tipologia omogenea, come ad esempio un template HTML, che verrà poi trattato e arricchito da altre tecnologie. Quando invece ci troviamo davanti il prodotto finale, dove diverse tecnologie cooperano assieme, a volte è bene usare l'approccio opposto. Invece di aderire rigidamente agli standard a priori, può essere conveniente aggiustare le cose a posteriori. Ovviamente ciò non significa ignorare gli standard per principio, ma permettersi qualche piccolo “know problem” per non bloccare gli sviluppi. Possiamo procedere con la validazione delle pagine o dell'applicazione durante la fase di sviluppo, in un momento che potrebbe collocarsi prima dell'alpha release (se lavoriamo in “catena di montaggio”), oppure giorno dopo giorno (se usiamo un approccio agile). Questo è possibile grazie alla precisione degli strumenti di validazione del W3C, che ci dicono cosa sistemare in modo specifico e mirato, e diventa addirittura conveniente se gli elementi da sistemare sono numericamente pochi (rispetto alle dimensioni del progetto).
