html, pdf e la mania del dialetto

Niente paura, non intendo scrivere un post in bergamasco.
Del resto non lo conosco abbastanza bene, perderei un sacco di tempo a cercare i codici per dieresi e accenti strani e, soprattutto, mi capirebbero in due o tre.

Il dialetto a cui mi riferisco è quello in cui vengono declinati, da un po' di tempo a questa parte, i linguaggi e i formati che erano nati con lo scopo opposto.
Html e Pdf avevano un obiettivo ben preciso: rappresentare un oggetto, generalmente un testo impaginato o un ipertesto, in modo che l'aspetto fosse identico indipendentemente dal sistema utilizzato. In quest'ottica si stabiliva un linguaggio (html o pdf) in cui descrivere l'oggetto e un reader che trasformasse tale descrizione in una immagine. L'indipendenza dal sistema era ottenuta implementando un reader per ogni architettura disponibile.
L'idea era geniale: una pagina html o un documento pdf apparivano in modo identico indipendentemente dalla macchina (Win PC, Mac, Linux...) e, perdipiù, il reader era gratuito. Questo permetteva di distribuire documenti (pdf) o ipertesti (html) senza doversi preoccupare del fatto che si potessero leggere e sicuri che tutti li vedessero e stampassero allo stesso modo. Senza l'implementazione di questa visione probabilmente internet non sarebbe mai esistita come la concepiamo oggi.

Perché parlo al passato? Perché oggi non è più così.

Chi come me realizza web apps sa benissimo quanti switch occorra mettere nel codice per adeguarlo ai differenti comportamenti dei vari browser di oggi (spesso anche tra varie versioni dello stesso browser). E nel mondo pdf non andiamo meglio: chi non si è trovato di fronte ad un file pdf giudicato corrotto dal proprio reader e che, invece, era solo stato realizzato con una versione successiva di Acrobat?
Capisco benissimo la necessità di evolvere questi linguaggi (oggi scrivere pagine html senza css è inconcepibile, ad esempio) ma tale evoluzione deve procedere secondo passi ben formulati e, soprattutto, standardizzati per tutti da un ente che li formalizzi. Ente che dovrà essere estremamente reattivo alle esigenze ed estremamente severo con chi non rispetta le sue direttive.
Badate bene, non intendo un grande fratello del www, ma un grande coordinatore.

In un mondo che mette in primo piano la virtualizzazione mi viene difficile pensare che per visualizzare una nuova property css sia necessaria una specifica marca di browser e non semplicemente la versione aggiornata di uno qualsiasi.
Ancor più difficile da concepire è che la stessa property abbia comportamenti diversi laddove sia implementata.

Oggi chi realizza pagine html ha solo tre possibilità: codificare in html puro (si torna ai tempi di Berners-lee), riempire il codice di switch o scriversi un framework che li contenga (panico in sede di manutenzione) o utilizzare strumenti di sviluppo (panico al quadrato in sede di manutenzione).

Ovviamente le istruzioni del tutto sono in pdf. Ma per aprirle occorre la nuova versione del reader perché altrimenti...