Ciao, e benvenuto nell'ottava puntata dell'undicesima stagione. Abbiamo parlato molto di standard, celebrandoli come il collante che tiene insieme il Web. Ma finora li abbiamo trattati come qualcosa di dato. Oggi guardiamo dietro le quinte, e ci facciamo una domanda che pochi si pongono: come nasce, concretamente, uno standard del Web? Chi decide? Come si passa da un'idea a una regola che tutti i browser rispettano? È un processo affascinante, lento, a volte litigioso, che assomiglia più alla politica e alla diplomazia che all'ingegneria pura.
Partiamo da un punto sorprendente: creare uno standard è difficilissimo, molto più che scrivere del codice. Perché uno standard deve mettere d'accordo attori diversi, spesso rivali, ciascuno con i propri interessi: le aziende che fanno i browser, gli sviluppatori che li useranno, gli esperti, gli utenti. Deve prevedere ogni caso possibile, essere così preciso da non lasciare spazio a interpretazioni diverse, e al tempo stesso restare realizzabile da tutti. Scrivere una regola che sia chiara, giusta, precisa e accettata da tutte le parti in causa è un lavoro immane di scrittura, negoziazione e pazienza. Uno standard è, prima di tutto, un accordo faticosamente costruito tra persone.
Vediamo, a grandi linee, come si svolge questo processo, perché la sua forma è istruttiva. Di solito comincia con una proposta: qualcuno, magari un'azienda o un esperto, avanza l'idea di una nuova capacità per il Web. Questa proposta viene poi discussa in gruppi di lavoro, dove le varie parti si confrontano, la criticano, la migliorano, la modificano, in un lungo dialogo. Si cerca il consenso, cioè un accordo abbastanza largo da soddisfare tutti gli attori principali. E poi, passaggio cruciale, la proposta deve essere realizzata davvero in più browser, per dimostrare che funziona nella pratica e che tutti la interpretano allo stesso modo. Solo dopo tutto questo diventa uno standard maturo.
Fermiamoci su quest'ultimo punto, perché è geniale e poco conosciuto: uno standard non è vero finché non è realizzato. Non basta scriverlo bene sulla carta; deve funzionare davvero, in più browser indipendenti, in modo identico. Questa regola, che richiede realizzazioni multiple e concordanti prima di considerare una cosa standard, è una salvaguardia preziosa. Impedisce che si approvino regole belle in teoria ma impossibili in pratica, e garantisce che ciò che diventa standard sia davvero universale e interoperabile. È il Web che pretende prove concrete, non solo buone intenzioni. La realtà, e non la carta, è il giudice ultimo.
Naturalmente, un processo che cerca l'accordo tra rivali è pieno di tensioni, e sarebbe disonesto nasconderle. C'è una tensione costante tra due esigenze opposte. Da un lato la voglia di andare veloci, di introdurre subito le novità, perché il Web corre e aspettare è frustrante. Dall'altro il bisogno di andare cauti, di raggiungere un vero consenso e verificare bene, perché uno standard sbagliato o affrettato resta poi per sempre, difficile da correggere. Veloci ma rischiosi, o cauti ma lenti: è un equilibrio delicatissimo, che genera continui dibattiti su quanto in fretta si debba procedere. Chi spinge per la velocità e chi frena per la prudenza sono in perenne, e sana, tensione.
Questa tensione ha prodotto, a un certo punto, una vera frattura storica, che vale la pena raccontare. A un dato momento, alcune aziende dei browser, frustrate da un processo che ritenevano troppo lento e astratto, presero una strada più pratica e veloce, dando vita a un modo diverso di fare gli standard, più vicino ai bisogni concreti di chi costruiva i browser. Nacque così una tensione, e poi una convivenza, tra approcci diversi alla creazione degli standard: uno più formale e prudente, uno più pragmatico e rapido. Col tempo si arrivò a un assetto in cui il linguaggio principale del Web viene curato in modo continuo e pragmatico. Fu una lezione su come, a volte, il processo stesso debba evolvere per restare utile.
C'è un altro concetto che racconta bene le difficoltà pratiche: le funzioni sperimentali marcate come tali. Quando un browser voleva provare una capacità nuova non ancora standardizzata, per un periodo la offriva con un'etichetta di avvertimento: attenzione, funzione sperimentale, solo di questo browser, potrebbe cambiare. L'idea era buona, ma nella pratica creò confusione, perché gli sviluppatori cominciarono a usare quelle funzioni come se fossero definitive, ricreando frammentazione. Un esperimento istruttivo su quanto sia difficile gestire il confine tra sperimentazione e standard.
Voglio chiudere collegando tutto al carattere degli standard. Il processo che abbiamo descritto, lento, negoziato, prudente, può sembrare frustrante, e per molti versi lo è. Ma quella lentezza è, in parte, una virtù. Il Web deve durare decenni, e le sue regole servono miliardi di persone: un certo attrito è il prezzo della solidità. Costruire cose destinate a durare richiede pazienza, non fretta. Gli standard sono lenti perché fatti per durare, e questa è una forma di rispetto verso il futuro.
Per oggi ci fermiamo qui. Creare uno standard è più diplomazia che ingegneria: una proposta, discussa in gruppi di lavoro alla ricerca del consenso, e poi realizzata davvero in più browser, perché uno standard non è vero finché non funziona identico ovunque. Il processo è attraversato dalla tensione tra andare veloci e andare cauti, che ha prodotto fratture e nuovi approcci, e da esperimenti istruttivi come le funzioni marcate. Ma la sua lentezza è in parte una virtù: gli standard sono lenti perché fatti per durare. Nella prossima puntata affrontiamo la grande questione del presente: l'era mobile e la nuova concentrazione. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.