HTML e posta elettronica: una questione di stile

All’inizio di quest’anno il W3C ha accettato di esaminare una proposta di standard sull’uso di HTML nella posta elettronica: “Conventions for use of HTML”. La proposta, presentata da Microsoft, Lotus e Qualcomm (l’azienda proprietaria di Eudora, uno dei mail reader più diffusi), ha come obiettivo non solo il mettere ordine tra i tag HTML che sempre più spesso compaiono nei messaggi, ma anche la trasformazione di uno dei più antichi strumenti della rete, la email, in una parte integrante dell’architettura Web.

Nella posta elettronica una lettera deve riuscire ad attraversare diversi gateway della rete, per poi essere letta su un sistema che può essere completamente diverso da quello sul quale è stato scritto. Finora un messaggio riesce ad essere ricevuto correttamente da tutti solo se contiene i caratteri del set ASCII “ristretto”. L’ASCII (American Standard Code for Information Interchange), che si basa su 8 bit, può rappresentare 256 caratteri, ma soltanto la codifica dei primi 128, quelli che costituiscono l’ASCII ristretto (chiamato anche Plain Vanilla ASCII o US-ASCII), è realmente universale; i codici utilizzati per gli altri caratteri, che costituiscono il cosiddetto ASCII “esteso”, possono infatti variare da sistema a sistema.
In posta elettronica, quindi, quando non si conosce con sicurezza il sistema usato dal destinatario o quando, come capita quasi sempre, non si conoscono le caratteristiche dei nodi che verranno attraversati, si usa un alfabeto molto limitato, privo ad esempio delle lettere accentate, che vengono sostituite nelle mail dal carattere non accentato seguito da un apice (per esempio: si scrive a’ invece di à).

Oltre ai numeri, alle lettere maiuscole e minuscole (senza alcun accento), ai simboli di punteggiatura, allo spazio e ad alcuni codici di controllo, L’ASCII ristretto comprende solo i seguenti caratteri di uso comune:

Se si usa un carattere non compreso nel codice ASCII ristretto, ad esempio una lettera accentata, è probabile che il destinatario della mail veda al suo posto un fastidioso codice esadecimale.
D’altra parte, gli elaboratori erano nati per eseguire solo calcoli numerici ed inizialmente era sufficiente poter esprimere dati e risultati con le dieci cifre e con pochissimi altri segni; la rudimentale mancanza di uno standard universale che consenta l’uso di un alfabeto più completo non deve quindi stupire.

La soluzione, secondo il nuovo standard proposto, sarebbe proprio l’HTML, che consentirebbe anche di inserire nei messaggi alcuni degli stili più diffusi, quali la sottolineatura e il grassetto (finora resi con solo due caratteri, underscore o asterischi, _prima_ e *dopo* la parola o la frase da evidenziare), il corsivo, o i caratteri colorati e di dimensioni diverse.

Basta con i vecchi messaggi in Plain Vanilla, dunque, senza accenti ed editati a mano per riaggiustare la lunghezza delle righe e per rendere comprensibile il quoting (le citazioni) dei testi degli altri; in futuro, secondo la nuova proposta, stili, colori, vita e storia di un messaggio saranno gestiti automaticamente, con uno standard che fonderà in un’unica interfaccia HTML, XML, MIME (Multipurpose Internet Mail Extensions, la codifica di interscambio più usata per i file da spedire in formato binario) e le tradizionali specifiche contenute in RFC 822 (l’attuale standard della email), integrando e superando anche MHTML (MIMEHTML), il protocollo proposto per incapsulare in MIME i documenti HTML.

I messaggi, infatti, hanno una storia complessa, fatta di risposte, controrisposte, citazioni di testi di più autori, date che scandiscono il ritmo del dibattito e oggetti (subject) della discussione che si intrecciano in thread (argomenti) differenti.
Nei newsgroup, i gruppi di discussione, date, citazioni e thread sono già gestiti in modo quasi completamente automatico; nella email sulle liste di discussione, invece, la “storia” di ciascun messaggio oggi viene costruita a mano da ogni singolo autore, e senza regole precise.

La nuova proposta, definita anche di “HTML Threading”, vorrebbe incorporare in ciascun messaggio la descrizione del dibattito in corso.

Il quoting, oggi viene realizzato con l’aggiunta, spesso gestita automaticamente dai programmi di posta, di un carattere (di solito “>” o “:”). Ad ogni quoting successivo viene aggiunto un altro carattere, ma questo meccanismo non riesce a fornire un’informazione precisa. Ad esempio, un riga che inizia con “>>” indica solo che il testo è una risposta a una risposta, e la presenza di righe con un differente numero di simboli consente soltanto di sapere che i testi che si stanno leggendo sono stati scritti da autori diversi, senza sapere quali. Gli utilizzatori delle mailing list hanno imparato che occorre aggiungere il nome dell’autore in testa ad ogni citazione, ma si tratta di una regola informale. Questo sistema un po’ rudimentale crea inoltre dei conflitti con il wrap automatico (la gestione automatica della lunghezza delle righe) e con l’uso di font proporzionali o di qualsiasi testo privo di ritorni a capo fissi in ogni riga.

Il Threading HTML risolverebbe questi problemi inserendo in ogni messaggio informazioni o in formato HTML, oppure come XML embedded in HTML, o sotto forma di link ad un URL esterno, o ancora come file MIME allegato e come fogli di stile in CSS.

Se questa nuova proposta fosse approvata dal W3C, si potrebbe usare uno stile diverso per ogni citazione, distinguendo gli autori, e ciascun messaggio consentirebbe di risalire alle mail precedenti, alle pagine Web dei loro autori e alla data di ricezione di ciascuno dei testi citati.

La proposta di HTML Threading non richiede grosse modifiche agli standard esistenti: l’unica novità degna di rilievo è l’introduzione di un nuovo attributo, CITE, nelle specifiche di HTML 4.0.

Resta da capire se questo nuovo standard sia veramente indispensabile in una rete dove i newsgroup, come si è detto, hanno già dei meccanismi automatici di gestione dei thread e in cui le liste di discussione continuano ad essere legate ad un’ostinata tradizione di semplicità. Le mailing list, in particolare, vogliono continuare ad essere accessibili a tutti, anche a chi dispone ancora di quello che la proposta di Threading HTML definisce sbrigativamente come software “low”, di basso livello. Dare oggi una risposta a questa domanda non è facile; si può comunque ricordare ancora una volta che la lotta per il predominio nel mercato dei browser sta diventando sempre più accesa e che la posta elettronica tradizionale, gestita in quello che alcuni chiamano scherzosamente “Pain Vanilla”, senza HTML e XML, non favorisce né Microsoft o Qualcomm né Netscape.

Mentre lo standard è ancora in fase di studio, le ultime versioni di molti mail reader, come Eudora 4.0, consentono già di inserire HTML nel testo, in modo del tutto trasparente per l’autore, che spesso produce tag senza accorgersene, ad esempio con una semplice sottolineatura. Se chi riceve il messaggio usa dei mail reader meno aggiornati (di solito più piccoli, più comodi e privi di data di scadenza), il testo risulta poco leggibile e sulle liste di discussione nascono proteste e piccoli litigi. I puristi amanti delle spartane interfacce a carattere di Unix e di Linux sono ancora più drastici: di solito cestinano le mail scritte in HTML senza neppure provare a decifrarle.

Per il momento, quindi, quasi tutte le mailing list sconsigliano l’uso degli accenti o di altri caratteri appartenenti all’ASCII esteso, non amano l’HTML (il cui uso nei messaggi, URL a parte, è considerato da newbie, da principianti) e vietano sia gli allegati in formato MIME sia l’inserimento di immagini nel testo. I newsgroup, dal canto loro, adottano di solito delle policy analoghe e altrettanto restrittive. In attesa dell’approvazione e soprattutto della diffusione del nuovo standard, è meglio adeguarsi a queste “vecchie” regole, per non sembrare maleducati o inesperti. Questione di stile…