Indice

Inviare l'XHTML come text/html è ritenuto dannoso

Il presente documento è una traduzione di un articolo di Ian Hickson.

Indirizzo originale: http://www.hixie.ch/advocacy/xhtml
Autore: Ian Hickson

Autore: Ian Hickson <ian@hixie.ch> (I commenti sono ben accetti)

Riassunto

Vengono discussi alcuni problemi risultanti dall'uso del MIME type text/html in unione al contenuto XHTML. Viene suggerito che l'XHTML servito come text/html è debole e l'XHTML servito come text/xml è dannoso. Così gli autori che destinano il loro lavoro alla fruizione pubblica dovrebbero usare HTML 4.01, e gli autori che intendono usare XHTML dovrebbero servire la loro marcatura come application/xhtml+xml.

Altre versioni

Une traduction française est disponible: http://www.hixie.ch/advocacy/xhtml.fr

Il team di sviluppo di Safari ha inserito un post in merito all'argomento sul loro blog: http://webkit.org/blog/?p=68.

Contesto

Questo articolo è stato scritto originariamente nel contesto di questo post: http://ln.hixie.ch/?start=1031465247&count=1

Da allora è stato aggiornato regolarmente per correggere gli errori messi in evidenza su varie mailing list e altri forum di discussione. Come per la fine del 2004, esso ha la stessa rilevanza avuta all'epoca della sua pubblicazione.

Si noti che questo documento compara l'XHTML 1.0 conforme nell'Appendice C con l'HTML 4.01, poichè questa è l'unica variante di XHTML che può essere inviata come text/html.

Terminologia: l'Appendice C si riferisce alle cosiddette "Linee guida di compatibilità con l'HTML" della specifica XHTML che si trovano all'indirizzo http://www.w3.org/TR/xhtml1/#guidelines.

Sommario d'uso

Se usate XHTML, dovreste servirlo con il MIME type application/xhtml+xml . Se non lo fate, dovreste usare HTML4 invece di XHTML. L'alternativa, usare XHTML ma servirlo come text/html, causa numerosi problemi descritti di seguito.

Sfortunatamente, IE6 non supporta application/xhtml+xml (difatti, non supporta affatto XHTML ).

Perchè usare text/html per l'XHTML è un male

Quello che succede di solito agli autori che decidono di inviare XHTML come text/html è il seguente:

  1. Gli autori scrivono XHTML ritenuto funzionante solo per la zuppa di tag [tag soup, N.d.T.] o per i browser HTML4, e non per i browser XHTML, e lo inviano come text/html. (Le supposizioni comuni sono elencate di seguito)
  2. Gli autori vedono che tutto funziona bene.
  3. Passa il tempo.
  4. Gli autori decidono di inviare lo stesso contenuto come application/xhtml+xml, perchè, dopo tutto, è XHTML.
  5. Gli autori si trovano di fronte ad un sito orribile. (Si veda più avanti l'elenco dei motivi)
  6. Gli autori cominciano a detestare l' XHTML.

I punti da 1 a 5 sono stati riscontrati da ogni persona con cui ho parlato che è passata al MIME type XHTML. L'unico motivo per cui in questi casi non si è verificato il punto 6 è perchè si trattava di autori esperti che avevano appreso un modo per risolvere il problema col loro contenuto.

PROBLEMI SPECIFICI

I seguenti sono problemi che affliggono i documenti quando questi passano da text/html a application/xhtml+xml:

COPIA E INCOLLA

Ho il sospetto che il problema peggiore, e anche il motivo principale, per cui la maggior parte delle pagine XHTML DAVVERO non valide, stia nel fatto che gli autori, che non conoscono l'XHTML, hanno copiato e incollato il loro DOCTYPE da un altro documento. Così anche se voi scrivete XHTML valido, usando XHTML, è probabile che incoraggiate gli autori che non conoscono il modo per scrivere XHTML valido ad affermare invece che lo sanno fare.

Perchè cercare di usare XHTML e inviarlo come text/html è un male

Questi problemi non riguardano tanto gli autori che validano regolarmente le loro pagine, quanto piuttosto gli altri.

Il mito dei documenti XHTML 1.0 compatibili con l' HTML

La specifica RFC 2854 fa riferimento a "un profilo d'uso di XHTML compatibile con HTML 4.01". Non esiste una cosa simile. I documenti che seguono le linee guida nell'appendice C non sono documenti HTML 4.01 validi. Si avvicinano soltanto all'essere gestibili come zuppa di tag dai parser, proprio come molte altre pagine web.

Gli esempi più semplici sono:

Usare XHTML e inviarlo come text/html è lo stesso, da un punto di vista dell'HTML4, che scrivere una zuppa di tag (si veda Perchè i browser non possono trattare l'XHTML dato in text/html come XML below).

Nota: questo viene trattato dal problema HTMLWG XHTML-1.0/6232.

Perchè i browser non possono trattare l'XHTML dato in text/html come XML

I vantaggi di XHTML

Se inviato come application/xhtml+xml, l'XHTML ha diversi vantaggi:

  1. Il contenuto XHTML sarà in grado di essere unito e di trovare una corrispondenza con il contenuto di altri namespace conosciuti (in particolare, MathML). Questo è il vantaggio principale per gli autori.
  2. I browsers individueranno subito gli errori nella corretta scrittura.
  3. Gli strumenti che interagiscono con i documenti XHTML garantiscono un documento ben formato.
  4. Il contenuto XHTML può essere analizzato con un parser più semplice di quello usato per una zuppa di tag, e molto più di uno SGML.

Tuttavia, nessuno di questi vantaggi si applica se un documento XHTML viene inviato come text/html, e poichè gli autori sanno che le loro pagine dovrebbero essere leggibili dal browser web più popolare, che non supporta application/xhtml+xml, non c'è alcun motivo per usare XHTML attualmente.

Conclusione

Ci sono pochi vantaggi nell'usare XHTML se lo inviate come text/html e molti svantaggi.

Inoltre, attualmente, la maggioranza (oltre il 90% secondo le statistiche più diffuse) del mercato dei browser non è in grado di rendere il vero contenuto XHTML inviato come text/xml (o altri MIME type XML). Per esempio, andate con IE su:

http://www.mozillaquestquest.com/

Solo Mozilla, i browser basati su Mozilla come Netscape 6 7, e le versioni recenti di Opera e Safari, sono in grado di rendere correttamente questo sito. (IE6 un albero del DOM!)

Gli autori che non vogliono usare i MIME type XML dovrebbero continuare a scrivere HTML 4.01 valido. Quando i programmi utente che supportano XML e XHTML dati con uno dei MIME type XML si saranno diffusi, allora gli autori potranno riconsiderare l'apprendimento e l'uso di XHTML.

(Gli autori esperti dovrebbero vedere l'Appendice B.)

Ulteriori letture

Ho scritto un altro articolo sull'argomento: le persone vogliono che i browser trattino i documenti XHTML dati in text/html come XML e non come zuppa di tag.

http://www.damowmow.com/playground/xhtml-in-uas.xhtml

Henri Sivonen ha scritto un articolo simile domandandosi quale sia l'obiettivo di XHTML. XHTML:

http://www.hut.fi/u/hsivonen/xhtml-the-point

Ci sono molti altri post in merito sulle mailing list, per esempio su www-talk. Il seguente post riassume alcuni problemi sull'uso di text/html per il contenuto XHTML con estensioni XML:

http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0046.html

Alcune persone hanno avuto i problemi citati in questo mio articolo, per esempio:

http://flrant.com/index.php?id=P21

Altri punti interessanti si trovano anche in altri post, per esempio:

> Ma Mozilla usa il suo parser xml per http://www.w3.org/ ?

No. Se lo facesse, renderebbe la pagina senza nessun riferimento esteso ad entità carattere, in quanto Mozilla non è un parser validante e quindi salta il parsing della DTD e non sa cosa sono &nbsp;, &middot; e &copy;. Per non dire che finirebbe per ignorare la sezione specifica per la stampa del foglio di stile, la quale usa nomi di elementi in maiuscolo e non troverebbe corrispondenze per gli elementi in minuscolo (riga 138 del primo foglio di stile), e userebbe un colore di sfondo non previsto per la pagina, in quanto il foglio di stile imposta lo sfondo su <body> e non su <html>, il che in XHTML porterebbe ad una resa differente rispetto all'equivalente in HTML4 (stesso foglio di stile, riga 5).

-- http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0004.html

O questo post, vicino alla fine del thread:

Sto ancora cercando un buon motivo per scrivere siti web in XHTML in questo momento, dato che la maggioranza dei browser non supporta XHTML. L'unico motivo che ho trovato (da Dan Connolly [1]) è che rende la gestione del contenuto più semplice con gli strumenti XML... ma sarebbe altrettanto semplice convertire l'XML in zuppa di tag o in HTML prima della pubblicazione, e così non sono sicuro di capirlo. Dato che XML è per la gestione dei contenuti, perchè questo implica che una minoranza di browser devono trattare il documento come XML invece che come zuppa di tag? Qual'è il vantaggio? E dato che chi usa gli strumenti XML spesso gestisce anche i siti, perchè non ci si affida ad una procedura lato server piuttosto che spingere gli autori a spendere le loro già scarse risorse nell'implementazione di uno sniffing del tipo di contenuto?

[1]

http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0031.html

-- http://lists.w3.org/Archives/Public/www-talk/2001JulAug/0005.html

Appendice A: application/xhtml+xml

Si veda: http://ln.hixie.ch/?start=1036767231&count=1

Appendice B: autori esperti

Alcuni autori esperti sono in grado di dare l'XHTML come application/xhtml+xml ai browser che lo supportano, e come text/html ai vecchi browser.

Presupponendo che usiate XHTML 1.0 conforme all'Appendice C (o che avete verificato che l' XHTML 1.0 che inviate è compatibile con i processori da zuppa di tag), allora va bene. Quello che dico è SOLO che inviare l'XHTML come text/html è pericoloso.

Nota: dare l'XHTML 1.1 come text/html non è MAI un bene. Non ci sono specifiche che lo consentono. Dare l' XHTML 2.0 ancora in sviluppo (senza test) non è MAI un bene, in quanto questa specifica non ha ancora raggiunto lo stato di Candidate Reccomendation (CR).

Si noti anche che vorrei suggerire agli autori esperti di non usare XHTML come text/html, in quanto molti autori copiano e incollano la marcatura da altri autori e questo può facilmente portare a copiare XHTML valido ma usarlo come HTML4.

Appendice C: Riconoscimenti

Grazie a Nick Boalch per l'introduzione. Grazie a Dan Connolly per la pignoleria che ha migliorato la qualità dell'articolo. Grazie a Ted Shaneyfelt, Quinn Comendant, per i miglioramenti al testo suggeriti.

Appendice D: Note a piè di pagina

[1] Il termine "trattato come una zuppa di tag" si riferisce al fatto che i browser di solito sono molto permissivi nella loro gestione degli errori, e non supportano nessuna delle caratteristiche "avanzate" di SGML. Per esempio, i browser trattano la stringa "<br/>" come "<br>" e non come " <br>&gt", essendo l'ultima quella che dovrebbe essere secondo HTML4/SGML. Allo stesso modo i browser del mondo reale non hanno problemi a gestire contenuto come "<b> foo <i> bar </b> baz </i>" anche se secondo le specifiche HTML4 non ha senso.

Gabriele Romanato | 12-2-2007

Note a Siti che funzionano 2.0

Queste note su alcuni passi del libro di Sofia Postai sono più degli spunti di riflessione che un tentativo di disamina critica. Non mancano tuttavia delle aggiunte laddove la necessità di un'approfondimento è particolarmente evidente.

Sommario

  1. La questione dell'usabilità
  2. Pagine che funzionano
  3. Viabilità del sito
  4. Tecnicaglie

1. La questione dell'usabilità

Elementi di variabilità

Anche se in questi ultimi anni i browser sono stati concepiti in modo da attenuare le differenze tra i vari sistemi e la conseguente visualizzazione delle pagine, questo sintetico elenco basterà a capire che la strada da percorrere non è quella di "bloccare" le pagine (secondo il "pregiudizio della carta") ma piuttosto quello della progettazione fluida.

- pag, 4

(Segue l'elenco degli elementi di variabilità, suddivisi in variabilità hardware e software)

1. Dal 2003, anno in cui Sofia ha scritto il libro, i cambiamenti nel mondo del Web sono stati notevoli. A livello di browser, tuttavia, le cose sono rimaste sostanzialmente le stesse, se consideriamo solo l'aspetto della rivalità tra browser come Internet Explorer (IE), Firefox ed Opera. Questa rivalità ha sostanzialmente accentuato le differenze piuttosto che attenuarle: IE ha scelto la strada delle tecnologie proprietarie, non riuscendo di fatto a risolvere problemi come hasLayout, mentre Firefox ed Opera si sono impegnati sul fronte del supporto agli standard del W3C, anche se a volte in modo confuso. Se infatti da un lato abbiamo un browser pieno di bug che costringe spesso gli autori a creare fogli di stile ad hoc, dall'altro abbiamo dei browser sostanzialmente standard compliant, ma con un supporto di proprietà non ancora ufficiali e riconosciute o addirittura estensioni proprietarie (si vedano le estensioni con prefisso -o e -moz, oppure proprietà come 'opacity' e 'box-sizing'), che sicuramente contribuiscono a generare confusione tra gli autori. La rivalità sopracitata riduce la possibilità di migliorare l'interoperabilità con il conseguente rallentamento nello sviluppo del Web.

A proposito del "pregiudizio della carta" di cui parla Michele Diodati occorre fare una precisazione: non sempre è un errore in cui precipitano gli autori, quanto piuttosto un radicato convincimento da parte dei committenti. Chi per esempio proviene dal mondo dell'editoria, spesso non coglie la differenza tra il Web (media dinamico) e la stampa (media statico), non tanto per ignoranza, quanto piuttosto per una "priorità ontologica" della carta sul Web. In altre parole, il Web e il mondo della carta stampata hanno in comune solo i contenuti, non il modo in cui essi vengono presentati.

Variabilità della piattaforma e del sistema operativo

Per quanto riguarda le versioni dei browser, e soprattutto di IE, invece, le differenze sono abissali. Explorer per PC ed Explorer per Mac sono browser nettamente differenti. Explorer 5 per Mac, al momento del lancio, era un browser ricco di prestazioni innovative (come la posssibilità di ingrandire il testo fino al 300%) che nemmeno IE 6 per PC attualmente ha. Inoltre, per esempio, il baco nel rendering del box model CSS, che Explorer per PC ha corretto solo nella versione 6, su Explorer per Mac non c'è mai stato.

- pag, 7

2. In realtà la situazione è più complessa. IE5 per Mac presentava una vasta collezione di bug, ottimamente sintetizzata su http://www.l-c-n.com/IE5tests/. Nell'articolo Internet Explorer 5 Mac: oddities troviamo alcuni filtri (o hack) per IE5 Mac. Per ulteriori approfondimenti, si consultino i test di Bruno Fassino.

La questione "estetica"

La fruizione del Web è strettamente individuale e segue percorsi di "interesse" relativi ai contenuti.

- pag. 14

3. Quando uscì CSS Zengarden si sentì un ohh di meraviglia. Credo che alcuni pensassero davvero che con i CSS si potessero creare quegli effetti strabilianti. In realtà, la proprietà più usata in Zengarden è 'background'. Tutto il resto lo fa l'uso artistico di Photoshop. In Zengarden non c'è traccia di contenuto generato o di proprietà sperimentali come 'opacity'. Da un punto di vista del design fu sicuramente un gigantesco passo in avanti, ma sotto l'aspetto dello sviluppo dello standard dei fogli di stile costituisce tutt'oggi un pericoloso esempio di prevaricazione della presentazione sul contenuto. Da allora le strade degli autori e degli sviluppatori di standard si sono pericolosamente divise: gli autori hanno cominciato ad usare ossessivamente solo alcune proprietà CSS, ricadendo di fatto nello stesso errore di chi abusava delle tabelle. Sviluppatori come David Baron hanno invano cercato di avvertire gli autori della pericolosità di quella ubriacatura estetica, che fossilizzava gli standard in un insieme ridotto di caratteristiche. In fondo, se le proprietà più usate servono solo per piazzare immagini grandiose come sfondo degli elementi, che senso hanno, ad esempio, le proprietà relative al contenuto generato o quelle dei fogli di stile acustici? Se è vero che in fondo l'ossatura del Web si basa sui contenuti, perchè non cercare un punto di equilibrio tra presentazione e contenuto? Purtroppo in questo binomio si inseriscono le richieste del committente/cliente, troppo spesso figlio di quella cultura televisiva che piazza le telecamere sotto le gonne delle ballerine e zittisce lo scrittore perchè non fa audience.

2. Pagine che funzionano

I contenuti

La cosa più importante di qualsiasi sito web è il suo contenuto. Può trattarsi di testi, immagini, filmati, musica, interattività. Può essere informazione, utilità, servizio, ricerca, interrelazione personale. C'è sempre, comunque, un motivo per cui le persone arrivano a un sito. L'apparente casualità della navigazione non è mai così casuale come potrebbe sembrare.

- pag. 24

4. Il Web è agnostico sul contenuto. Venendo da un tipo di navigazione basata esclusivamente sulla ricerca di contenuti testuali (al limite qualche immagine per il desktop) in siti prevalentemente universitari o comunque ruotanti intorno all'àmbito della cultura, faccio molta fatica ad accettare questa eterogeneità di fondo. Ma, come si è detto in precedenza, il Web è un'esperienza sostanzialmente individuale, e quindi, paradossalmente, la singola esperienza non può descrivere la totalità delle esperienze di navigazione. Tuttavia, se queste esperienze si assommano e si amalgamano, si giunge al successo di un sito. La matematica, in questo caso la statistica, ha sempre l'ultima parola.

Atomi di lettura

Un testo può (anzi deve) essere lungo quanto serve per spiegare l'argomento. Le frasi e i periodi devono però essere brevi. Dobbiamo spezzettare il testo in atomi di lettura non più lunghi di metà della finestra a disposizione.

- pag. 31

5. Il Web deve formare o informare, far pensare o divertire? Come ogni sistema logico complesso, il Web non riesce a dimostrare la propria coerenza. Da qui il bisogno di un contenuto flessibile, agnostico, finalizzato ad un determinato target. Quanto deve essere lungo un testo che descrive la propria vita? Quanto basta a spiegare l'argomento. Si può spiegare una poesia in mezza videata? In una videata? Due? Come autori web lo sappiamo, come esseri umani no.

Lo stile di scrittura

Ciascuna frase deve contenere un concetto. Il testo deve essere chiaro e concreto. Dobbiamo evitare qualunque retorica autocelebrativa. Le retoriche del Web sono altre: più easy, veloci, orientate all'utente. Evitate le frasi che suonano bene e non dicono niente. Sono controproducenti anche nella comunicazione tradizionale, ma sul Web diventano letali.

- pp. 33-34

6. Questo deve ovviamente essere riferito al contesto particolare del sito e al pubblico di destinazione. In un sito letterario, ad esempio, ci si aspetta che il livello dei contenuti sia in sintonia con il pubblico al quale ci si rivolge. Certo, è sempre possibile che un frequentatore abituale di siti pornografici legga con interesse un articolo sulle rivendicazioni femministe dei primi anni del '900, ma, consentitemi, è poco probabile. Easy e veloce mal si adatta ad un sito che invita invece alla riflessione sull'uomo e sulla società.Tuttavia, adottare una mentalità incentrata sull'utente è sempre consigliabile. La domanda è: quale tipo di utente?

Intrattenimento?

7. Come autori e sviluppatori di siti Web, dobbiamo anche noi, come Machiavelli, indossare una veste diversa allorchè ci dedichiamo ad un sito. Dobbiamo essere, in altre parole, altre persone. Dobbiamo comprendere l'altro, il diverso, quello che di solito non rientra nei nostri schemi. Se abbiamo deciso di lavorare sul Web, dobbiamo assumerne la forma mentis, ossia il totale agnosticismo. Il Web è agnostico sull'utente, poichè si parla di accesso universale alla Rete. Il Web, nella sua globalità, si rivolge a tutti. Un sito, invece, nel suo essere microcosmo nel macrocosmo della Rete, ha una sua tipologia di utenti. Spesso questa tipologia non rientra nei nostri schemi. Abbiamo quindi due possibilità: rinunciare al lavoro o accettare di confrontarci con qualcosa che non conosciamo. Per esempio, io mi occupo prevalentemente di siti a carattere culturale, quindi la mia tipologia di utenti è diversa da quella di un autore che sviluppa siti per lo scambio di MP3 o di immagini. Se mai dovessi decidere di intraprendere un'altra strada, dovrei necessariamente acquisire nuove competenze, rimettermi in gioco. E ricominciare. - pp. 74-75

3. Viabilità del sito

Le regole non scritte (standard de facto)

La più importante: le parole sottolineate sono link, le parole non sottolineate non sono link.

- pag. 110

8. Qui viene posto implicitamente anche un problema di conflitto presentazionale. Nell' HTML esiste infatti l'elemento INS, che marca un inserimento di testo aggiuntivo. Per impostazione predefinita, e secondo il foglio di stile per l'HTML 4, tale elemento viene rappresentato come sottolineato. Questo crea un conflitto presentazionale con i collegamenti ipertestuali, che di norma sono sempre sottolineati dal browser. Personalmente, ritengo che un'altra caratteristica fondamentale di un collegamento ipertestuale sia la comparsa di un puntatore diverso nell'interfaccia del browser (la classica "manina"). Molto spesso ci si accorge dell'ipertestualità di un elemento proprio da questa sua peculiare caratteristica. Non penso che la sottolineatura debba essere imposta de facto, in quanto essa, come già detto, non è la sola caratteristica di un collegamento ipertestuale a livello visivo. Certo, è più semplice identificare un collegamento ipertestuale a prima vista, ma che dire di un documento in cui l'autore ha anche inserito un elemento INS senza modificarne l'aspetto predefinito? Più che di regole non scritte, io parlerei di pratiche consigliate ma mai, comunque, imposte come standard.

4. Tecnicaglie

L'approccio laico alla tecnologia

9. Sul conflitto (presunto) tra fogli di stile ed usabilità, credo che occorra fare una precisazione. A mio avviso tale conflitto non esiste. Portare come esempio la "pericolosità" (anche Sofia usa giustamente le virgolette) delle modifiche apportate, poniamo, ad un modulo (form), semplicemente non ha consistenza tecnica. Infatti, il foglio di stile per l'HTML 4, già citato, non definisce l'aspetto predefinito dei moduli. Si limita semplicemente a dichiarare 'display: inline-block' ad esempio per l'elemento INPUT, senza fare alcun riferimento alla sua resa a video. Quello che vediamo nei browser è semplicemente una convenzione accettata de facto (non uno standard). Per esempio Firefox, nel suo foglio di stile predefinito, assegna un bordo rientrato pari a 2 pixel all'elemento INPUT, dandogli poi un colore di sistema. Internet Explorer ha un comportamento vagamente simile, mentre Opera applica invece la sua skin ai bottoni per l'invio dati. Gli autori sono liberi di cambiare l'aspetto dei moduli, perchè esso non è definito in nessuno standard.

Un modulo per l'invio dati in genere è costituito da un campo di testo e da un bottone per l'invio effettivo. Ora, se anche il colore e la forma di questi elementi venissero cambiati con i fogli di stile, vi sono altri elementi testuali che spiegano all'utente che quel "coso" serve ad una determinata funzione. Se io infatti uso l'elemento LABEL e vi scrivo "Inserisci i dati", e poi come valore dell'attributo value per l'elemento INPUT specifico "Invia", non credo che ci dovrebbero essere dei problemi per l'utente. C'è di più: a livello di accessibilità, credo che i riferimenti testuali siano più importanti di quelli semplicemente presentazionali, in quanto un non-vedente, per esempio, non sa cosa farsene dell'aspetto di un modulo, ma certamente trae beneficio dalla corretta semantica usata nella scrittura del codice. Il problema a mio avviso risiede più nella corretta etichettatura di un modulo e nella sua posizione nel contesto della pagina, piuttosto che in un abuso dei fogli di stile. - pag. 202

Gabriele Romanato | 28-1-2007

Sulla traduzione delle specifiche CSS2

La traduzione esiste perchè gli uomini parlano lingue diverse. Questa verità lapalissiana, di fatto, si basa su una situazione che può essere considerata enigmatica e che pone problemi di estrema difficoltà psicologica e storico-sociale. Perchè gli esseri umani dovrebbero parlare migliaia di idiomi diversi e reciprocamente incomprensibili? Viviamo in questa struttura pluralista sin dall'inizio della storia tramandata, e diamo per scontato il miscuglio che ne deriva.

- George Steiner, Dopo Babele

La traduzione delle specifiche CSS2 nasce appunto dal bisogno di superare un ulteriore ostacolo nel cammino della comprensione reciproca, in cui il Web gioca un ruolo fondamentale. Questo ostacolo è costituito dal divario esistente tra linguaggi settoriali e linguaggio comune, divario che nel caso delle specifiche CSS2 assume connotati paradossali. Di fatto, i CSS nascono come linguaggio semplice e dichiarativo (Bos-Lie), sviluppato per essere compreso ed usato agevolmente sia dall'uomo che dalla macchina.

Tuttavia, ad un lettore attento non sarà sfuggita la complessità del linguaggio usato nella stesura delle specifiche e la difficoltà, specialmente per il lettore italiano, di comprendere appieno i concetti di base per poter cominciare ad usare i CSS.

Nel corso degli otto anni trascorsi dalla pubblicazione delle specifiche CSS2 (maggio 1998) si è cercato di sopperire a questa difficoltà con la pubblicazione di importanti guide sull'argomento (celeberrima quella di Eric Meyer). Qui assistiamo ad un altro interessante fenomeno: cambiando il modo con cui le specifiche venivano spiegate, aumentava la facilità di comprensione. Il linguaggio usato in queste guide risulta di facile comprensione, poichè i concetti più difficili vengono mutuati co un linguaggio più accessibile.

Il problema, oltre che di didattica, è soprattutto un problema linguistico. Si è trattato di gettare un ponte tra il linguaggio settoriale ed il linguaggio comune, creando un medium tra due aree semantiche diverse. Nella traduzione italiana si è tenuto presente questo importante fenomeno, e si è cercato di continuare sulla strada intrapresa dagli autori delle sopracitate guide.

C'è da dire che non vi sono riferimenti lessicali organici per la traduzione. Manca, in altri termini, un'organizzazione centrale delle traduzioni da parte dei vari uffici locali del W3C, che dovrebbero avere il compito di stilare delle linee guida alla traduzione dei documenti, oltre ad un glossario di riferimento per i termini più comuni. Di fatto, tutto è affidato al traduttore, il cui compito è ancora più gravoso se si pensa alla fase di revisione della traduzione.

Nel cercare di rendere accessibile la traduzione, si è evitato di ricorrere a dubbi neologismi o ad anglicismi oscuri per il lettore digiuno di web publishing. Al contrario, ci si è sforzati di trovare corrispondenze nella lingua d'arrivo, ossia l'italiano. Un esempio in tal senso è la parola "riquadrato" usata per tradurre il termine "box".

Nella letteratura delle guide ai CSS la parola viene spesso conservata nell'originale inglese. Tale scelta è solo in parte corretta: infatti non si tiene conto del fatto che la parola "box" ha in italiano un significato affatto diverso dall'originale, come testimoniato dal dizionario italiano De Mauro, significato che un lettore non esperto recepisce come sinonimo di rimessa per auto o di recinto per bambini. Il termine riquadrato è invece mututato dal mondo della tipografia, e sta ad indicare una cornice con all'interno del contenuto, ed è certamente più vicino al campo semantico dell'editoria del Web. Per tutti gli altri criteri usati nella traduzione, si consulti la nota alla stessa.

In conclusione, un tassello che mancava nel mosaico tutt'altro che provinciale del web italiano ha finalmente trovato il suo posto. Con i migliori auguri a tutti gli sviluppatori, designer, webmaster e utenti d'Italia.

Gabriele Romanato | 4-11-2006

I CSS sono difficili?

Esistono sul Web numerosi e falsi miti sui CSS. Uno di essi è quello secondo il quale questo linguaggio di formattazione (o di stile) richiederebbe una perizia pari a quella necessaria per padroneggiare linguaggi di programmazione evoluti e complessi come Java o C++. Fondamentalmente. le uniche difficoltà esistenti sono quelle relative alle differenti interpretazioni nel rendering da parte dei vari browser, difficoltà ampiamente superabili mediante l'acquisizione di competenze di base.

I CSS, per ammissione dei loro stessi creatori, nascono come un linguaggio semplice e dichiarativo sin dalla loro bozza originale. Superando le resistenze di chi sosteneva che per dare stile ai documenti occorreva la potenza di un linguaggio di programmazione completo, i CSS hanno mantenuto inalterata questa loro caratteristica fino ad oggi.

Non è azzardato ritenere che si possano acquisire le sopracitate competenze di base nel volgere di poche settimane di studio metodico. E per vedere i progressi nel proprio lavoro basta semplicemente aprire i propri documenti in un browser. In altre parole, qui non si richiedono quei lunghi processi di eleborazione e di verifica di un progetto come quelli necessari alla creazione di un programma. La resa è immediata, la visione d'insieme subito disponibile.

La pretesa difficoltà dei CSS a mio avviso risiede in una serie di atteggiamenti sbagliati, come:

Concludendo, i CSS sono un linguaggio facile da apprendere e da gestire, unici in tal senso nel complesso panorama di linguaggi nati col Web.

Gabriele Romanato | 23-10-2006