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)
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.
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.
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.
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 ).
Quello che succede di solito agli autori che decidono di inviare XHTML come text/html è il seguente:
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.
I seguenti sono problemi che affliggono i documenti quando questi passano da text/html a application/xhtml+xml:
Agli elementi <script> e <style>
in XHTML inviati come text/html devono essere applicati gli escape
usando stringhe ridicolmente complicate.
Questo avviene perchè in XHTML, gli elementi <script> e
<style> sono blocchi #PCDATA,
non blocchi #CDATA, e quindi <!--
e --> sono realmente
tag di commento , e non sono ignorati dal parser XHTML. Per applicare gli escape agli script
in un documento XHTML che può essere gestito come HTML4 o
XHTML, si deve usare:
<script type="text/javascript"> <!--//--><![CDATA[//><!-- ... //--><!]]></script>
Per inserire un CSS in un documento XHTML gestito sia come HTML4 che XHTML, si deve usare:
<style type="text/css">
<!--/*--><![CDATA[/*><!--*/
...
/*]]>*/--></style>
Si, è abbastanza ridicolo. Se ai documenti non vengono applicati gli escape come
sopra, i contenuti degli elementi <script> e <style> cadono
letteralmente a terra se analizzati come vero XHTML.
(Per far questo si presuppone che voi vogliate far funzionare le vostre pagine sia con i vecchi browser che con i browser XHTML. Se vi preoccupate solo dei browser XHTML e HTML4, potete semplificare la cosa.)
Un foglio di stile CSS scritto per un documento HTML4 viene interpretato in modo
leggermente diverso in un contesto XHTML (per esempio, l'elemento <body>
non è magico in XHTML, e i nomi dei tag devono essere scritti in minuscolo in
XHTML). Così i documenti hanno una resa diversa se analizzati come XHTML.
Uno script basato su DOM scritto per un documento HTML4 ha una semantica leggermente diversa in un contesto XHTML (per esempio i nomi di elemento non sono sensibili alle maiuscole e alle minuscole e vengono restituiti in maiuscolo in HTML4, mentre in XHTML accade il contrario; dovete usare i metodi consapevoli del namespace in XHTML, ma non in HTML4). MA, se inviate i vostri documenti come text/html, allora essi useranno la semantica HTML4 NONOSTANTE siano XHTML! In questo modo è molto probabile che gli script non funzionino se analizzati come XHTML.
Gli script che usano document.write() non funzioneranno nei contesti XHTML.
(Dovete usare metodi DOM Core.)
I browser attuali sono, per il contenuto text/html, programmi utente HTML4 (al massimo) e di sicuro non sono programmi utente XHTML. Quindi se voi gli inviate XHTML, gli state inviando del contenuto scritto in un linguaggio che non gli è nativo, e vi affidate alla loro gestione degli errori. Poichè quest'ultima non è definita in nessuna specifica, può variare da un programma utente all'altro.
I documenti XHTML che usano la notazione "/>", come in "<link />" hanno
una semantica molto differente se analizzati come HTML4. Se ci fosse un programma utente
perfettamente conforme ad HTML4, sarebbe quasi corretto che mostrasse i caratteri
">" sulla pagina.
Per ulteriori dettagli su questo punto si veda la sezione intitolata Il mito dei documenti XHTML 1.0 compatibili con l' HTML.
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.
Questi problemi non riguardano tanto gli autori che validano regolarmente le loro pagine, quanto piuttosto gli altri.
I documenti inviati come text/html sono gestiti come zuppa di tag [1] dalla maggior parte dei browser.
Ecco la chiave di tutto: se inviate XHTML come text/html, per quanto i browser se ne preoccupino, gli state solo dando una zuppa di tag. Non importa se il codice è valido, poichè essi lo tratteranno come se fosse vecchio HTML 3.2 o una caotica spazzatura HTML.
Poichè la maggior parte degli autori testano i loro documenti usando uno o due browser, piuttosto che usare un validatore, questo significa che gli autori non testano la validità, e in questo modo la maggior parte dei documenti che dicono di essere XHTML non sono validi.
Si veda, per esempio, questo studio: http://www.goer.org/Journal/2003/Apr/index.html#results ...ma se non ci credete, siate liberi di farne uno vostro. In ogni esempio casuale di documenti che dicono di essere XHTML,
Quindi il vantaggio maggiore di usare XHTML, ossia che gli errori vengono rilevati subito perchè deve essere valido, si perde se il documento viene inviato come text/html. (Si, ho detto la maggior parte degli autori. Se siete tra i pochi autori che comprendono il modo di evitare i problemi illustrati in questo articolo e che validano la loro marcatura, allora questo articolo probabilmente non si applica a voi -- si veda l'Appendice B.)
Se farete passare i vostri presunti documenti XHTML da text/html ad application/xhtml+xml, allora è probabile che troverete molti errori XML, il che vuol dire che il vostro contenuto non sarà leggibile dagli utenti. (Si veda sopra: la maggior parte di questi documenti non passa la validazione.)
Se un utente salva un tale documento text/html su disco e poi lo riapre in locale, causando lo sniffing del tipo di contenuto, dato che i filesystem di solito non includono informazioni sul tipo di file, il documento potrebbe essere riaperto come XML, avendo come risultato potenziale errori di validazione, differenze di parsing o di stile. (Le stesse differenze che avreste se inviaste il file con un MIME type XML.)
L'unico vero vantaggio nell'uso di XHTML piuttosto che di HTML4 è che si possono usare strumenti XML Tuttavia, se vengono usati tali strumenti, essi potrebbero a loro volta produrre HTML4. In alternativa, gli strumenti potrebbero prendere SGML come input invece di XML. (SGML è più vecchio di dieci anni rispetto ad XML, e tali strumenti esistono da anni.)
HTML 4.01 contiene le stesse cose di XHTML 1.0, così vi sono pochi motivi per usare XHTML nel mondo reale. Sembra che il motivo principale sia solo quello di "saltare sul vagone di testa" ed usare l'ultima novità in arrivo.
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:
La sintassi "/>" del tag vuoto ha, de facto, un significato totalmente diverso in HTML4. (È la cartteristica di minimizzazione SHORTTAG conosciuta come NET, se ricordo bene il nome.) Nello specifico, l'XHTML
<p> Hello <br /> World </p>
...è, se interpretato come HTML4, esattamente equivalente a:
<p> Hello <br>> World </p>
...e dovrebbe essere reso come:
Hello
> World
Gli elementi di script e di stile non possono avere i contenuti nascosti dai vecchi browser. Il seguente XHTML:
<style type="text/css">
<!-- /* hide from old browsers */
p { color: red; }
-->
</style>
...è esattamente equivalente al seguente HTML4:
<style type="text/css">
</style>
...perchè i commenti non sono ignorati nei blocchi <style> di XHTML.
L'attributo xmlns non è valido in HTML4.
I DOCTYPE XHTML non sono validi DOCTYPE HTML4.
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.
I documenti dati come text/html sono trattati come zuppa di tag dalla maggior parte dei browser. Questo significa che gli autori non testano la loro validità, ed in questo modo la maggior parte dei documenti XHTML sul Web non sono validi. Un browser conforme all'XML non sarà in grado di visualizzare quei documenti che ora vengono visualizzati dai browser attuali, e quindi non vi sarà mai una condivisione rilevante del mercato tra di essi.
Non è possibile auto-individuare con sicurezza l'XHTML se dato come text/html. Ecco il motivo per cui i browser non potrebbero trattare i documenti in text/html come XML, anche se non si preoccupassero della lor usabilità (si veda il primo punto di questa sezione).
Non si può fare lo sniffing dei cinque caratteri "<?xml" poichè:
L'intestazione <?xml ... ?> è facoltativa secondo l'Appendix C, e si raccomanda di
non usarla poichè manda IE6 in modalità
quirks.
SGML può anche contenere delle PI (si veda l'esempio di seguito). (Un "PI" è
un'" istruzione di elaborazione" [Processing Instruction, PI, N.d.T.] un costrutto sintattico che inizia con i due
caratteri "<?".)
Non si inizia ad elaborare dal DOCTYPE, in quanto il W3C potrebbe introdurre nuovi DOCTYPE XHTML in futuro, e quindi non sapete quali DOCTYPE cercare. (Per non dire che i DOCTYPE sono facoltativi per i documenti XHTML ben formati, che analizzare un DOCTYPE è difficile, che i DOCTYPE possono essere nascosti nei commenti, e che il DOCTYPE sniffing è stato definito pericoloso da molte figure guida nel W3C e altrove.)
Non si può elaborare dalla stringa "<html xmlns" poichè questa
potrebbe essere presente ma nascosta in un commento (ci sarebbe bisogno di un parser XML
completo per analizzare i commenti, le PI, i sottoinsiemi interni, ecc).
per esempio, in che linguaggio è scritto questo documento text/html?:
<?xml this is not?> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [ <!-- SYSTEM "not XHTML" --> ]> <!-- -- --> This is a comment. This document is not XHTML. <html xmlns="http://www.w3.org/1999/xhtml"/> Ok, I'm done now. --> <html> <title> Need a title in HTML4! </title> <p> This is a valid HTML4 document. </html>
Anche se riusciste ad individuare l'XHTML, cosa potreste fare con un documento non ben formato (come quello del precedente esempio)? Se ripiegate su HTML4, non vi è alcun vantaggio ad usare un processore XML, e potreste sempre trattarlo come HTML4.
Il Gruppo di Lavoro HTML ha detto che i browser non dovrebbero farlo: http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html
Se inviato come application/xhtml+xml, l'XHTML ha diversi vantaggi:
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.
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.)
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 , · e ©. 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
Si veda: http://ln.hixie.ch/?start=1036767231&count=1
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.
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.
[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>>", 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
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.
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.
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 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.
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.
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.
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?
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
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.
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
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
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