Introduzione

All'incirca nel 1990, Tim Berners-Lee svilupp� tre specifiche che formarono la base del progetto World Wide Web: l'HyperText Markup Language (HTML) fu sviluppato come un formato di documento per il Web; gli Universal Resource Locators (URL) furono aggiunti per rappresentare i collegamenti tra i documenti; e l'HyperText Transfer Protocol (HTTP) fu sviluppato per trasferire i documenti tra le macchine su Internet [Berners-Lee 1999]. Sia le specifiche che le implementazioni furono rese liberamente disponibili dal CERN.

Il Web rapidamente prese slancio. Con l'uscita del browser Mosaic del National Center for Supercomputing Applications (NCSA) nel 1993 [Andreessen 1993a], gli utenti all'improvviso ebbero un browser attraente per navigare un insieme di documenti collegati tra loro in continuo aumento. Con un numero crescente di utenti, sempre pi� autori furono attratti dal Web, e il contenuto prolifer�.

All'inizio l'HTML era un semplice formato di documento strutturato con tag di marcatura aggiunti tra le stringhe di testo per indicare il ruolo del testo. Per esempio, una stringa di testo poteva essere marcata come un paragrafo, mentre un'altra stringa come un collegamento cliccabile. Gli elementi nel primo HTML erano logici piuttosto che presentazionali. Per esempio, l'HTML avrebbe marcato del testo come un titolo ma non avrebbe descritto come il titolo doveva essere rappresentato. La presentazione del testo – inclusi quale font, colore e dimensione da usare – era principalmente stabilito dal browser.

Struttura contro presentazione

Gli ambienti scientifici come il CERN valorizzano la logica, la struttura e il contenuto pi� che l'estetica, le immagini e lo stile. Questo senso della struttura si riflette nell'HTML. Ogni paragrafo � marcato come tale e ai titoli viene dato un livello numerato per indicare la loro collocazione nella struttura del documento.

Quando il Web cominci� ad attrarre l'attenzione al di fuori degli ambienti scientifici, gli autori cominciarono a lamentarsi del fatto di non avere abbastanza influenza sull'aspetto delle loro pagine. Una delle domande pi� frequenti degli autori nuovi al Web era come poter cambiare i font e i colori degli elementi. Questo passaggio tratto da un messaggio inviato alla mailing list www-talk [www-talk] all'inizio del 1994 [Andreessen 1994a], da il senso della tensione esistente tra autori e sviluppatori di browser In questo capitolo ho citato un messaggio inviato ad una mailing list per la comunit� degli sviluppatori, e lo far� molte volte nei capitoli successivi. Le mailing list erano fondamentali per tenere insieme la comunit� del Web nei primi anni, e gli archivi ipertestuali delle mailing list si ampliarono rapidamente nei primi anni '90. Oggi, dieci anni dopo, questi archivi forniscono uno sguardo interno di valore al web design e allo sviluppo web. :

Infatti, per me � stata una constante fonte di piacere durante lo scorso anno sentirmi continuamente dire, da orde (letteralmente) di persone che – tenetevi forte, ci siamo – volevano controllare il layout dei loro documenti in modi che sarebbero banali in TeX, Microsoft Word, e ogni altro comune ambiente di eleborazione testuale,: "Spiacente, sei fregato."

L'autore del messaggio era Marc Andreessen, uno dei programmatori del browser NCSA Mosaic. In seguito divenne co-fondatore di Netscape, che soddisf� le richieste degli autori introducendo tag presentazionali nell'HTML. Il 13 ottobre 1994, Netscape annunci� [Andreessen 1994b] la prima versione beta del loro browser. Il browser Netscape supportava un insieme di nuovi tag HTML presentazionali (per esempio CENTER per centrare il testo) e altri sarebbero seguiti in breve.

Livelli di astrazione

Aggiungendo tag presentazionali all'HTML, il linguaggio si evolse dall'essere un linguaggio di marcatura astratto e strutturato dove gli autori marcavano le differenti regole logiche del testo (paragrafi, intestazioni, elenchi e cos� via) in un concreto linguaggio di presentazione dove l'enfasi � posta sulla presentazione della forma finale dei documenti (font, colori e layout).

Nella tradizionale pubblicazione cartacea, il lettore riceve un prodotto di forma finale. Ogni lettera sulla pagina stampata ha una posizione fissa, forma, dimensione e colore che non possono essere cambiate dal lettore. I documenti elettronici, tuttavia, sono prodotti non finiti che devono essere assemblati prima di poter essere presentati al lettore umano. Nel processo di assemblaggio – meglio noto come formattazione – vengono fatte molte scelte sulla presentazione del documento. Per esempio, il browser deve selezionare i font e i colori da usare quando presenta il documento su uno schermo a colori. Il livello di eleborazione richiesto da un documento elettronico varier� a seconda del formato di documento usato. Come tali, i documenti elettronici sono simili ai mobili: alcuni mobili giungono pre-assemblati, mentre altri vengono comprati in scatole e il proprietario deve eseguire l'assemblaggio finale. Se un formato di documento richiede molta eleborazione, si dice che ha un alto livello di astrazione. Se il formato di documento richiede poca eleborazione, si dice che ha un basso livello di astrazione.

Determinare il giusto livello di astrazione � una parte importante dello sviluppo di un formato di documento. Se il livello di astrazione � alto, il processo di authoring e il compito di formattare il documento divengono pi� complessi. L'autore deve far riferimento a concetti astratti non-visibili. Dal lato della ricezione, il browser deve trasformare oggetti astratti in oggetti concreti e questo compito � pi� complesso se gli elementi sono altamente astratti. Il beneficio di un alto livello di astrazione � che il contenuto pu� essere riutilizzato in molti contesti. Per esempio, un'intestazione pu� essere presentata a grandi lettere su fogli stampati, e con voce pi� forte in un sistema di letture vocale del testo.

Di contro, un basso livello di astrazione render� il processo di authoring e di formattazione pi� facili (fino a un certo punto). Gli autori possono usare strumenti orientati al WYSIWYG (What You See Is What You Get), e il browser non deve eseguire trasformazioni estese prima di presentare il documento. L'inconveniente di usare formati di documento orientati alla presentazione � che il contenuto non � facilmente riutilizzabile in altri contesti. Per esempio, pu� essere difficile rendere disponibili documenti orientati alla presentazione per un dispositivo con una diversa dimensione dello schermo, o per una persona con menomazioni visive.

Quando si trasformano i documenti da un formato ad un altro, vi � la possibilit� che i due formati siano su diversi livelli di astrazione. In generale, � possibile trasformare documenti da un livello di astrazione pi� alto ad uno pi� basso, ma non il contrario. La scala di astrazione viene introdotta in questa tesi come un modo per misurare il livello di astrazione.

HTML presentazionale

L'introduzione dei tag presentazionali in HTML fu un passo indietro nella scala d'astrazione. Diversi nuovi elementi (per esempio BLINK) avevano senso solo per particolari dispositivi di output (come viene visualizzato il testo lampeggiante su un sistema di sintesi vocale?). I creatori dell'HTML volevano che tale linguaggio fosse utilizzabile per molte impostazioni ma i tag presentazionali minacciavano l'indipendenza dal dispositivo, l'accessibilit� e il riutilizzo del contenuto.

Lo sviluppo dell'HTML verso un linguaggio orientato alla presentazione cambi� anche l'equilibrio di potere tra autori e utenti. I documenti strutturati devono essere formattati dal browser prima della presentazione, e – in una certa misura – il processo di formattazione pu� essere influenzato dall'utente. Tuttavia, quando il browser riceve un documento nella sua forma finale, il processo di formattazione � completo � non pu� pi� essere influenzato dall'utente.

Gli autori web avevano chiesto pi� influenza sulla presentazione del documento e accolsero di buon grado questo sviluppo, ma vi era anche una resistenza nella comunit� del Web. Molti erano consapevoli del fatto che il Web aveva il potenziale per realizzare pubblicazioni personalizzate dove il lettore aveva il controllo – piuttosto che l'editore –. Il contenuto dovrebbe essere selezionabile secondo le preferenze del lettore, e il media e la forma di presentazione dovrebbero anch'essi essere una scelta del lettore. Trasformando l'HTML in un linguaggio di presentazione c'era il rischio di perdere i gradi di libert� necessari a realizzare un modello di pubblicazione incentrato sull'utente.

Fogli di stile

I fogli di stile furono proposti come alternativa all'evoluzione dell'HTML da linguaggio strutturale a linguaggio presentazionale. Il termine foglio di stile viene usato nella pubblicazione tradizionale come un modo per assicurare consistenza [Chicago 1993] nei documenti. Nel processo di pubblicazione tradizionale, un manoscritto � accompagnato da un foglio di stile che serve da resoconto corrente delle regole di stile e di uso del linguaggio adottate da un particolare manoscritto [Br�ggemann-Klein&Wood 1992].

Negli anni '80 la pubblicazione cambi� drasticamente con l'introduzione dei personal computer per l'uso nella preparazione dei manoscritti. La pubblicazione elettronica offriva strumenti per semplificare tutte le fasi della pubblicazione, dalla progettazione, all'editazione e alla strampa. Nella pubblicazione elettronica, il termine foglio di stile venne a significare un insieme di regole su come presentare il contenuto, piuttosto che regole su come scrivere il contenuto. I fogli di stile sarebbero stati specificati dal designer e inviati al compositore prima della stampa. Di solito avrebbero descritto il layout visivo di un documento incentrato sul testo, inclusi i font, i colori e lo spazio bianco.

In questa tesi, il termine foglio di stile si riferisce ad un insieme di regole che associano propriet� stilistiche e valori a elementi strutturali in un documento, ossia esprimendo come presentare un documento. I fogli di stile di solito non contengono contenuto, sono collegabili dai documenti e sono riutilizzabili. Questa definizione consente che il termine venga usato per la pubblicazione elettronica dentro e fuori il Web.

I fogli di stile erano disponibili sui sistemi di pubblicazione elettronica sin dal 1980 (si veda il capitolo 2 e 3). Combinati con i documenti strutturati, i fogli di stile offrivano un late binding [Reid 1989] di contenuto e presentazione dove contenuto e presentazione sono combinati dopo che la fase di progettazione � completa. Questa idea attrasse gli editori per due ragioni. Per prima cosa, si poteva raggiungere uno stile consistente attraverso un insieme di pubblicazioni. Secondariamente, l'autore non doveva preoccuparsi della presentazione della pubblicazione ma poteva concentrarsi sul contenuto.

Alcuni autori trovarono liberatorio non doversi preoccupare di dettagli presentazionali nel processo di progettazione [Cailliau 1997]. Tuttavia la maggioranza degli autori fin� con l'usare sistemi di progettazione che enfatizzano la presentazione piuttosto che la struttura [S�rgaard 1996].

WYSIWYG – un modello in gara

WYSIWYG – What You See Is What You Get – � un modello in gara per la progettazione di documenti. Le applicazioni WYSIWYG aggiornano costantemente una presentazione della forma finale. Man mano che l'autore digita sulla tastiera, lo schermo � aggiornato per riflettere il layout di pagina che risulterebbe se il documento venisse stampato in quel momento.

Invece del late binding tra presentazione e contenuto, usato dai documenti strutturati e dai fogli di stile, il WYSIWYG offre un instant binding [legame istantaneo, N.d.T.]; tutte le operazioni di editazione risultano nelle istantanee modifiche visive fino alla presentazione finale. Questo approccio si ha nei documenti in cui gli autori enfatizzano la presentazione finale – di solito un documento stampato – piuttosto che la marcatura logica.

Diverse applicazioni provano a combinare il concetto di documenti strutturati con l'editing WYSIWYG, fra cui FrameMaker di Adobe [FrameMaker], Microsoft Word [MS-Word] e Amaya del W3C [Amaya]. Di solito queste applicazioni offrono all'autore diverse visuali del documento di cui una � WYSIWYG e altre che sono pi� strutturali. Questo rende possibile scrivere documenti strutturati con un tool WYSIWYG. Tuttavia c'� un rischio associato all'uso di strumenti WYSIWIG: consentono anche gli autori di eseguire modifiche puramente presentazionali che possono non essere relazionabili con la struttura del documento.

Caratteristiche del Web

La ricerca ha dimostrato che quando i documenti sono progettati con la copia stampata come obiettivo finale � difficile motivare gli autori a lavorare su un livello logico piuttosto che su uno visuale [Sandahl 1999]. Con l'affermazione del Web, tuttavia, aumentano le possibilit� per il riutilizzo del contenuto. Invece di stampare e distribuire i documenti su carta, i documenti web sono trasferiti elettronicamente sul computer dell'utente. Lo spostamento verso la distribuzione elettronica dei documenti ha diverse caratteristiche chiave che influenzano sia il processo di progettazione che i linguaggi di stile.

• Il late binding diviene later binding: sul Web, i documenti sono trasmessi in forma elettronica sul computer dell'utente. Il late binding fra contenuto e presentazione della pubblicazione elettronica diviene later binding sul Web. Il binding [legame, N.d.T.] non ha pi� luogo nel luogo di pubblicazione ma, piuttosto, nel computer dell'utente. Questo aumenta la libert� di presentazione ma pone anche una nuova sfida di esecuzione, poich� il binding ha luogo quando l'utente � in attesa. Ancora: l'autore non � presente per assicurarsi che la presentazione sia corretta.
• La pubblicazione incetrata sulla carta diviene incentrata sullo schermo: Prima dell'avvento del Web, gran parte dei documenti elettronici finivano come documenti stampati. Erano editati ed elaborati su schermi di computer ma, assai spesso, il tipo di media finale era la stampa. Sul Web, la maggioranza degli utenti vede i documenti sullo schermo.
• Un output singolo si trasforma in output multipli: Sebbene gli schermi siano il tipo di media principale sul Web, esistono molti altri tipi. Gli autori non conoscono il tipo di dispositivo di output che verr� usato da un utente. Non c'� pi� una sola presentazione di forma finale, ma ve ne sono molte. Perci� � importante che i fogli di stile possano descrivere presentazioni per dispositivi di output multipli.
• Il controllo dell'autore diviene influenza condivisa tra autore e utente: Poich� il legame tra contenuto e presentazione ha luogo sul computer dell'utente, le influenze provenienti da fonti diverse possono essere combinate per formare una presentazione. Data questa libert�, sembra ragionevole che l'utente – come l'autore – dovrebbe poter influenzare la presentazione. Diventano possibili presentazioni basate sui bisogni e le preferenze dell'utente. Ci� si distingue da altri ambienti di pubblicazione, dove gli autori hanno il controllo completo della presentazione.
• Documenti autonomi divengono collegati ipertestualmente: Il Web � un grande insieme di documenti collegati ipertestualmente e l'informazione precedentemente espressa come riferimenti testuali pu� ora essere espressa come ipercollegamenti attivi.
• La distribuzione sicura diviene incerta: Le risorse web sono distribuite su molti computer interconnessi e la possibilit� che una risorsa non sia disponibile � considerevole. Un altro cambiamento sta nel fatto che � pi� probabile che il Web fallisca rispetto ai sistemi di pubblicazione tradizionali. È naturale rendere disponibile il foglio di stile sul Web, ma la risorsa pu� non essere sempre disponibile per l'utente.

Cos�, con l'introduzione del Web, il campo dei fogli di stile si � spostato dall'essere uno strumento per gli autori nel processo di progettazione all'essere uno strumento per il riutilizzo del contenuto dopo la sua generazione. I fogli di stile sul Web sono potenzialmente pi� importanti di quelli della pubblicazione incentrata su carta poich� la possibilit� del riutilizzo del contenuto � maggiore. Come la natura dei fogli di stile � cambiata dalla pubblicazione cartacea a quella elettronica, cos� la natura dei fogli di stile � cambiata nuovamente per la pubblicazione web.

Meccanismi del foglio di stile per il Web

Una rozza forma di fogli di stile fu inserita nel primo WWW client implementato sulla macchina NeXT al CERN. Tuttavia, non fu scritta alcuna specifica per i fogli di stile e non fu proposta alcuna sintassi per un linguaggio di stile; si consider� un problema di ciascun browser decidere come far visualizzare le pagine agli utenti.

I potenziali benefici dell'uso di fogli di stile sul Web sono significativi. Un meccanismo di foglio di stile ben sviluppato fornirebbe agli autori un vocabolario stilistico pi� ricco rispetto all'evoluzione possibile dell'HTML. Ancora: l'HTML rimarrebbe un linguaggio di marcatura strutturato che funziona su un'ampia gamma di dispositivi.

Per questi motivi, molte persone sulla mailing list www-talk [www-talk], che era il luogo di incontro elettronico della prima comunit� web, concordarono che il Web avrebbe tratto beneficio dai fogli di stile. Tuttavia, c'era un disaccordo sul fatto che il Web richiedesse o meno un nuovo linguaggio di stile oppure se fosse pi� adatto uno gi� esistente, concepito principalmente per la pubblicazione cartacea.

Diversi linguaggi di stile per il Web furono proposti nel 1993 (si veda il Capitolo 4: proposte di fogli di stile per il Web) ma nessuno prese slancio. Ci� era principalmente dovuto alla carenza di supporto nei browser; poich� Mosaic – di gran lunga il browser pi� popolare dei suoi tempi – non support� i fogli di stile, gli autori erano poco motivati a scriverli. Ancora: nesssuna delle proposte raggiunse lo stato di stabilit�. Un linguaggio di stile di successo per il Web doveva essere abbastanza convincente per essere implementato dagli sviluppatori di browser e per essere usato dagli autori.

CSS

Tre giorni prima che Netscape annunci� il suo nuovo browser, l'autore pubblic� la prima proposta sui CSS (denominata Fogli di stile a cascata per l'HTML – una proposta) [Lie 1994] sul Web. Oltre a descrivere font, colori e layout di documenti – gi� fatto in precedenza da diverse proposte – i CSS introducevano una nuova funzionalit� per tener conto delle differenze di pubblicazione imposte dal Web. Il concetto di cascata consentiva sia agli autori che agli utenti di influenzare la presentazione di un documento:

Lo schema proposto fornisce al browser un elenco ordinato (cascata) di fogli di stile. L'utente fornisce il foglio iniziale che pu� richiedere un controllo totale della presentazione, ma – pi� verosimilmente – gestisce l'influenza sui fogli di stile che si riferiscono al documento fornito.

Il negoziato tra i bisogni e i desideri dei lettori e degli autori era una delle principali ambizioni dei CSS. In caso di successo, gli autori avrebbero avuto la loro influenza sulla presentazione e non si sarebbero sentiti costretti a usare l'HTML presentazionale e altri trucchi. I lettori, da parte loro, avrebbero avuto dei documenti in una forma in cui potevano scegliere se accettare la presentazione suggerita dall'autore o specificarne una propria.

In molti casi non vi sarebbe stato conflitto tra autore e lettore. Nessuno dei due, ad esempio, potrebbe voler specificare la presentazione del documento. In questi casi, � importante che il browser abbia un foglio di stile predefinito che descriva la presentazione predefinita dei documenti HTML. I CSS, dunque, definiscono tre fonti possibili per i fogli di stile: autori, lettori e browser. I CSS sono in grado di combinare i fogli di stile da queste tre fonti per formare la presentazione di un documento. Il processo che combina diversi fogli di stile – e risolve i conflitti se questi ricorrono – � conosciuto come cascata.

Lo sviluppo dei CSS

La prima proposta sui CSS fu inoltrata nello spirito del libero scambio di idee su come il Web avrebbe dovuto svilupparsi, e le discussioni ebbero luogo sulle mailing list pubbliche. Un certo numero di persone rispose alla proposta [Bos 1994][Behlendorf 1994][Wei 1994] e la bozza fu ulteriormente sviluppata. Durante il 1995, furono pubblicate circa otto revisioni. L'ultima, del dicembre 1995, fu dichiarata stabile e i produttori di browser furono incoraggiati a usarla come base per le implementazioni [Lie 1996].

Con qualche piccola eccezione, la sintassi della bozza del dicembre 1995 � rimasta stabile e la prima sezione delle specifiche pu� ancora servire da introduzione ai CSS :

Sviluppare semplici fogli di stile � facile. C'� solo bisogno di conoscere un p� di HTML e la terminolgia di base della pubblicazione desktop. Per esempio, per impostare il colore del testo degli elementi 'H1' sul blu, si pu� scrivere:

  H1 { color: blue } 

L'esempio consiste di due parti principali: il selettore ('H1') e la dichiarazione ('color: blue'). La dichiarazione ha due parti, propriet� ('color') e valore ('blue').

Le specifiche CSS1 divennero una Raccomandazione W3C [CSS1 1996] nel dicembre 1996. Nel maggio 1998 i CSS2 divennero una Raccomandazione W3C [CSS2 1998]. Il capitolo 6 (Fogli di stile a cascata) descrive lo sviluppo delle Raccomandazioni con pi� dettagli.

Dieci anni dopo la pubblicazione della prima proposta CSS, tutti i maggiori browser supportano i CSS e la maggioranza della pagine web li usa. Pu� ancora essere prematuro valutare appieno i CSS e il loro impatto sul Web, ma � possibile studiare lo sviluppo dei CSS e compararlo con altri linguaggi di stile e proposte di linguaggi di stile.

Sommario e conclusioni

Questo capitolo introduce alcuni concetti chiave della tesi. L'HTML fu sviluppato come un semplice formato di documento strutturato per il Web. Poich� gli autori chiedevano pi� influenza sulla presentazione dei loro documenti, l'HTML cominci� a divenire un linguaggio presentazionale piuttosto che strutturale. Per fermare questo passo indietro nella scala d'astrazione, i CSS furono sviluppati come un linguaggio di stile per il Web. I fogli di stile avevano avuto un ruolo nella pubblicazione elettronica sin dagli anni '80. Sul Web, il campo dei fogli di stile si � spostato dall'essere uno strumento nel processo di progettazione a quello di uno strumento per il riutilizzo del contenuto dopo che il contenuto � stato generato.

La tesi esplora in dettaglio perch� il Web richiede differenti linguaggi di stile rispetto ad altri tipi di pubblicazione, e come tali linguaggi possono essere sviluppati. Prima di ci�, tuttavia, � necessario discutere due altri argomenti. In primis, i documenti strutturati devono essere compresi affinch� i fogli di stile vi siano applicati. In secundis, i linguaggi di stile sviluppati prima dell'avvento del Web devono essere studiati per determinare se si addicono al Web. Questo viene fatto rispettivamente nel capitolo 2 e 3.

Documenti strutturati

I linguaggi di stile e i documenti strutturati sono reciprocamente dipendenti l'uno dall'altro. Senza i fogli di stile, i documenti strutturati non possono essere presentati, e senza i documenti strutturati non v'� nulla da presentare per i fogli di stile. A causa della forte relazione tra i due, � importante comprendere i documenti strutturati quando si studiano i linguaggi di stile. Alcuni sistemi di documento strutturato che hanno influenzato di pi� i linguaggi di stile sono discussi in questo capitolo.

In un'opera fondamentale intitolata Structured Documents [Andr�, et al. 1989], l'argomento � definito  come:

Un documento pu� essere descritto come un insieme di oggetti con oggetti di livello pi� alto formati da oggetti pi� primitivi. Le relazioni tra oggetti rappresentano le relazioni logiche tra i componenti del documento. Per esempio, il presente documento � descritto come un libro al livello pi� alto. Il libro � suddiviso in capitoli, ogni capitolo in sezioni, sottosezioni, paragrafi e cos� via. Tale organizzazione del documento � conosciuta come rappresentazione di documento strutturato.

Un'importante caratteristica della rappresentazione di documento stratturato � che essa ha un certo livello di astrazione. Il livello di astrazione � particolarmente importante quando il documento strutturato � combinato con un foglio di stile per formare una presentazione. Perci�, la prima parte di questo capitolo discute i livelli di astrazione nei documenti strutturati e propone una scala di astrazione per misurare il livello di astrazione nei formati di documento per il Web.

La seconda parte del capitolo descrive i fondamentali sistemi di documenti strutturati, ossia Scribe, LaTex, Open Document Architecture (ODA), Standard Generalized Markup Language (SGML), HyperText Markup Language (HTML); e Extensible Markup Language (XML). Ognuno di questi sistemi � descritto brevemente dal punto di vista storico e tecnico, con speciale rilievo sulle loro relazioni con i linguaggi di stile.

Una terza parte discute la relazioni tra linguaggi trasformazionali e linguaggi di stile sul Web.

Livelli di astrazione

Nel suo libro, Language in Action, Hayakawa [Hayakawa 1940] introduce il concetto di scala linguistica di astrazione. Alla base della scala d'astrazione vi � un oggetto. Come esempio, Hayakawa usa una mucca chiamata Bessie. La mucca � composta di muscoli, ossa, pelle e altre parti biologiche. Come primo gradino salendo la scala, tralasciamo la biologia della mucca ma manteniamo le sue propriet� fisiche – per esempio il suo colore, dimensione e forma – e la chiamiamo Bessie. Bessie � solo una dei molti oggetti che possono essere classificati come mucche. Nella fattoria in cui vive Bessie, ci sono molte altre specie di animali a cui ci si pu� riferire come bestiame. La salita sulla scala di astrazione pu� continuare fino alle attivit� della fattoria e alla sua ricchezza. Il concetto � illustrato nella Figura 1.

Un esempio simile di livelli di astrazione pu� essere trovato nel campo delle reti di computer. Nel 1983, la International Standards Organization (ISO) svilupp� un modello di network chiamato Open Systems Interconnection (OSI) Reference Model che definiva una struttura per le comunicazioni tra computer. L'ISO/OSI Reference Model ha sette strati, ciascuno dei quali ha un diverso livello di astrazione. I sette strati sono: fisico, collegamento dati, rete, trasporto, sessione, presentazione e applicazione.

Credo che il concetto di una scala di astrazione sia utile quando si valutano i formati di documento. L'altezza di un certo formato di documento sulla scala determiner� la complessit� della formattazione del documento all'atto della presentazione. Poich� la formattazione di un documento � specificata da un foglio di stile, il livello di astrazione � una caratteristica decisiva per il successo dei fogli di stile.

La natura verticale di una scala corrisponde al modo in cui si descrivono i livelli di astrazione come alti o bassi. Le caratteristiche tipiche dei formati di documento che sono alti sulla scala di astrazione sono:

• L'informazione ha bisogno di elaborazione per essere presentata. Per esempio, per rendere visivamente un documento HTML le parole devono essere divise in righe, i font devono essere selezionati, e i caratteri devono essere convertiti in glifi rasterizzati.
• L'informazione pu� essere elaborata e presentata in molti modi diversi. Presentare un documento visivamente � solo una tra diverse possibilit�; le altre comprendono la resa acustica e il braille.
• L'informazione � rappresentata in modo compatto. Rappresentare un carattere con una codifica a otto bit � pi� compatto che rappresentare un'immagine dello stesso carattere.

Di contro, i documenti scritti in formati che sono bassi sulla scala di astrazione richiedono meno elaborazione per essere presentati, hanno meno flessibilit� nella presentazione e sono meno compatti.

Un'altra importante osservazione � che � generalmente possibile trasformare i documenti su livelli pi� bassi nella scala, ma � molto pi� difficile fare il contrario [Lie&Saarela 1999]. Per esempio, i browser web grafici – in collaborazione col sistema a finestre – rasterizzano i documenti HTML in pixel e perci� spostano l'informazione in basso sulla scala di astrazione. Il software Optical Character Recognition (OCR) cerca di salire la scala trasformando le immagini in testo, ma i sistemi OCR funzionano solo sotto determinate condizioni e sono inclini agli errori. Similmente, � impossibile progettare un algoritmo che converta i documenti scritti in un linguaggio Turing-complete a causa del problema dell'arresto [Connolly 1994a].

Nel contesto dei formati di documenti web, credo che si possano usare i seguenti criteri per determinare i gradini nella scala di astrazione:

• Il testo � leggibile dall'uomo? Ossia, se il documento viene presentato ad un lettore umano, lui/lei sar� in grado di leggere il documento?
• Il testo � leggibile dalla macchina? Ossia, il formato ha una nozione di caratteri numerati o rappresenta il testo come immagini – nel qual caso il testo non � disponibile?.
• L'ordine logico del testo � preservato? Ossia, i documenti scritti in tale formato hanno una nozione dell'ordine logico di lettura del contenuto?
• Il documento � scalabile? Ossia, si pu� zoomare il documento senza introdurre artefatti visibili?
• Il riflusso � possibile? Ossia, si pu� far rifluire il testo in righe, colonne e pagine di differenti dimensioni?
• Si possono rappresentare le regole dei vari elementi testuali? Per esempio, l'autore pu� marcare parte del testo come un'intestazione, un paragrafo, o come il nome di una variabile in un programma di computer? Essere in grado di distinguere tra queste regole � importante. Quando si rendono disponibili i documenti in braille, per esempio, parte del testo dovrebbe essere contratta (per esempio le intestazioni), mentre altre parti non dovrebbero esserlo (per esempio i nomi di variabili) [Lorimer 1996].
• Il formato � indipendente dal dispositivo? Ossia, i documenti scritti nel formato dato possono essere resi su diversi dispositivi (per esempio stampanti, schermi, stampanti braille e sintetizzatori vocali) oppure sono concepiti per un solo tipo di dispositivo?
• Il formato contiene semantica per una specifica applicazione? L'HTML � un generale formato di documento che non cerca di descrivere la semantica di pi� campi specialistici, per esempio la matematica e la chimica, e perci� non contiene semantica per una specifica applicazione. I formati che la contengono tendono ad essere pi� alti nella scala di astrazione.

La tabella 1 mostra le relative posizioni dei vari formati di documento sulla scala di astrazione. Alcune note alla tabella:

• GIF [GIF 1990] e PNG [PNG 1996] sono formati di immagine bitmap piuttosto che formati di documento, ma le immagini sono spesso usate per rappresentare documenti. La trasmissione dei fax � un esempio comune fuori del Web.
• PDF [Adobe 1993] � un formato di documento sviluppato dalla Adobe Systems. PDF � un formato orientato alla presentazione e non ha, per esempio, alcuna nozione di paragrafi ed intestazioni. Molti utenti lo hanno scoperto quando hanno provato a copiare il contenuto da documenti PDF suddivisi in diverse colonne. Quando si seleziona il testo, la selezione si estender� su colonne multiple e perci� mischier� il testo preso da diverse parti del documento nella stessa selezione. Versioni recenti di PDF hanno introdotto una funzionalit� per mantenere la struttura logica del documento in PDF [Adobe 2001].
• XSL-FO si riferisce a un documento che consiste in oggetti di formattazione come definito nella Raccomandazione XSL [XSL 2001]. XSL-FO � discusso pi� avanti in questo capitolo.
• XML [XML 1998], in cui sono scritti diversi formati emergenti, � anch'esso incluso nella tabella e si riferisce a documenti pubblicati usando vocabolari XML privati dove la semantica non � universalmente conosciuta.
• La classificazione dell'HTML � basata su uno scenario ideale in cui l'autore fa uso di elementi semantici e non altera l'ordine di lettura degli elementi usando caratteristiche come il posizionamento o le tabelle. Si pu� osservare come la maggioranza dei documenti HTML non segue queste convenzioni.
• MathML � una raccomandazione W3C per la notazione matematica [MathML 1998].

Dopo aver stabilito la scala di astrazione come strumento di misurazione dei formati di documento strutturato, la sezione seguente discute i sistemi di documento strutturato in dettaglio.

Sistemi di documento strutturato

A partire dal 1980, ci fu un'attiva comunit� di ricerca nel campo della pubblicazione elettronica e dei documenti strutturati. La comunit� pubblic� i suoi risultati nel corso delle conferenze sulla Electronic Publishing, nel periodico Electronic Publishing – Origination, Dissemination and Design [Electronic Publishing], e la Cambridge University Press pubblic� una serie di libri sull'argomento. Richard Furuta elenca molte delle opere importanti in Important papers in the history of document preparation systems: basic sources [Furuta 1992].

I ricercatori erano per lo pi� d'accordo sui benefici dei formati di documento neutrali rispetto al produttore, per facilitare lo scambio di documenti. I benefici dei documenti strutturati erano anch'essi ben compresi. Vi erano, tuttavia, diversi approcci ai documenti strutturati, e furono sviluppati formati in gara tra loro. Questa sezione descrive e discute quattro di loro.

Una linea di sviluppo cominci� alla fine degli anni '70, quando Brian Reid svilupp� Scribe [Reid 1980]. Scribe precorse il concetto di documenti strutturati ed introdusse una distinzione tra marcatura logica e modelli presentazionali nel processo di progettazione. La filosofia di Scribe fu portata avanti da LaTeX di Leslie Lamport, rilasciata nel 1985 [Lamport 1986]. LaTeX � un pacchetto macro incluso nel programma TeX di Donald Knuth e serve da formattatore a basso livello [Knuth 1984].

Open Document Architecture (ODA) � un insieme di standard ISO per facilitare lo scambio elettronico di documenti [ODA]. I documenti ODA possono rappresentare sia la rappresentazione logica che presentazionale di un documento.

Lo Standard Generalized Markup Language (SGML) [SGML 1986] e il suo predecessore GML fu sviluppato da Charles Goldfarb e dai suoi colleghi durante gli anni '70 e '80 [Furuta, et al. 1982]. SGML divenne uno standard ISO nel 1986.

Questi sei sistemi (Scribe, LaTeX, ODA, SGML, HTML e XML) sono descritti in questa sezione. Prima di discutere ciascuno di essi, pu� essere utile elencare le ambizioni e i traguardi percepiti dei sei sistemi. si veda la Tabella 2.

Per una tassonomia pi� formale dei formati di documento, si veda The Origin of (Document) Species [Khare&Rifkin 1998].

In aggiunta ai traguardi elencati nella Tabella 2, tutti i sistemi hanno ispirato autori e programmatori nel vedere i benefici dei documenti strutturati.

Le discussioni dei vari sistemi di documento strutturato riportate di seguito non seguono uno schema rigido. I sistemi variano molto per quanto riguarda la loro comprensione, il loro uso, e l'informazione attualmente disponibile su ciascuno di essi. L'obiettivo primario delle descrizioni non � quello di effettuare un'analisi comparativa, quanto piuttosto quello di discutere gli aspetti di questi linguaggi che l'autore trova interessanti nel contesto dei fogli di stile.

Scribe

Il sistema Scribe fu sviluppato alla fine degli anni '70 da Brian Reid alla Carnegie-Mellon University [Reid 1980]. Scribe � importante per aver precorso l'approccio strutturato alla progettazione. Incoraggia gli autori a lavorare con oggetti logici predefiniti, e gli autori di solito producono documenti nella loro forma finale senza dover specificare alcuna formattazione.

Il sistema Scribe � cambiato nel corso degli anni. La discussione in questo capitolo si basa su Scribe come descritto nello Scribe Introductory User's Manual del 1980 [Reid&Walker 1979]. La descrizione cerca di dare uno sguardo generale su Scribe, e non tutte le caratteristiche sono discusse.

Un semplice documento

Un documento Scribe pu� essere notevolmente semplice:

@Make(Text)
@Device(Diablo)
@Heading(Comrades and Strangers)

L'esempio di cui sopra usa tre concetti chiave di Scribe: tipi di documento, comandi, e ambienti di formattazione. La prima riga sceglie un particolare tipo di documento (Text) da un insieme di diversi tipi di documento. La seconda riga � un comando che specifica che il documento deve essere stampato su uno specifico dispositivo. La terza riga specifica che una data stringa (Comrades and Strangers) � l'intestazione del documento.

Tipi di documento

Un installazione di Scribe avviene con un database di tipi di documento. La documentazione di Scribe elenca 11 diversi tipi di documento: Text (predefinito), Article, Report, Manual, Thesis, Brochure, Guide, Letter, Letterhead, ReferenceCard, e Slides. Un documento Scribe di solito inizia selezionando il tipo di documento da usare:

@Make(Thesis)

Ci si aspetta che l'amministratore di sistema modifichi il database per adattarlo a esigenze locali. Per esempio, i requisiti di formattazione di una dissertazione variano da un'universit� all'altra, e le differenze possono essere tenute in conto nel tipo di documento Thesis. In teoria, gli autori possono scrivere le loro dissertazioni senza pensare ai requisiti di formattazione e concentrarsi piuttosto sul contenuto.

I tipi di documento influenzano sia il modello di contenuto che la presentazione di un documento. Per esempio, il tipo di documento Thesis consente che siano usati TitlePage e altri ambienti:

@Make(Thesis)
@Device(Diablo)
@Begin(TitlePage)
  @TitleBox(Comrades and Strangers)
  @CopyrightNotice(Michael Harrold)
@End(TitlePage)

Per gli autori � possibile modificare sia il modello di contenuto che la presentazione dei loro documenti, ma ci� � scomodo. Scribe incoraggia ad usare una modalit� dove l'amministratore locale mantiene il controllo – e la responsabilit� – per e su i vari tipi di documento usati nell'organizzazione.

Comandi Scribe

In aggiunta al contenuto stesso, un file sorgente Scribe contiene comandi Scribe. Essi corrispondono a quello che conosciamo come marcatura nella terminologia SGML/HTML/XML. Ci sono circa 35 comandi. Possono essere divisi in cinque gruppi principali:

• Comandi di classificazione: @Begin e @End sono usati per marcare l'inizio e la fine degli ambienti, e @Make � usato per dichiarare un tipo di documento.
• Comandi di variabile: Per gestire contatori (@Set, @Tag), riferimenti incrociati (@Ref), e variabili di tipo stringa(@String, @Value) che possono ampliarsi, per esempio, nella data e nel nome utente.
• Comandi visivi: Per marcare interruzioni di pagina (@NewPage), aggiungere spaziatura verticale (@BlankSpace), gestire interruzioni di tabulazione (@Tabset, @TabDivide, @TabClear) o cambiare stile (@Style) o font (@SpecialFont).
• Comandi per il contenuto fuori dal flusso: Per etichettare un determinato contenuto fuori dal flusso, per esempio note a pi� di pagina (@Foot), intestazioni correnti (@PageHeading) e pi� di pagina (@PageFooting).
• Comandi di sistema: Per importare altri file (@Import), specificare il dispositivo di output (@Device), e mandare in output un messaggio alla console (@Message).

La classificazione in gruppi � fatta dall'autore.

La documentazione Scribe descrive i comandi come non-procedurali. Tuttavia, alcuni comandi possono essere considerati come procedurali, soprattutto @BlankSpace e @NewPage. In un approccio strutturato, le interruzioni di pagina sono unite a elementi strutturati (per esempio un'intestazione) piuttosto che all'uso di un comando separato. Scribe supporta anche l'approccio strutturato attraverso l'Attributo di ambiente Pagebreak.

Similmente, i comandi @Style e @SpecialFont, che sono usati per impostare preferenze stilistiche e dei font, possono essere messi in dubbio poich� non sono uniti a elementi strutturati.

Un altro comando facilmente contestato � @Device, usato per specificare il dispositivo di stampa per l'output. Gli autori web non sapranno mai in anticipo quale dispositivo di stampa ha l'utente (se ne ha uno). Tuttavia Scribe era usato soprattutto con la carta come forma finale, e includere comandi come @Device � una scelta pragmatica.

Ambienti di formattazione

I comandi usati pi� di frequente in Scribe sono @Begin e @End che, rispettivamente, marcano l'inizio e la fine degli ambienti di formattazione. Un ambiente di formattazione corrisponde all'incirca ad un elemento nella terminologia SGML/HTML/XML, e i comandi @Begin e @End corrispondono ai tag. Gli ambienti di formattazione sono anche detti ambienti di formattazione nominati o semplicemente ambienti. Ecco un semplice frammento tratto dalla documentazione di Scribe. La citazione � tratta da Oscar Wilde: The Soul of man under Socialism, 1895:

@Begin(Quotation) 
On mechanical slavery, on the slavery of the machine, 
the future of the world depends.
@End(Quotation)

Al testo all'interno dell'ambiente Quotation viene dato uno spazio extra su tutti i lati. Il testo pu� anche essere posto negli ambienti con una sintassi abbreviata:

@Quotation(On mechanical slavery, on the slavery of the machine, 
the future of the world depends.)

Gli ambienti possono essere annidati l'uno dentro l'altro:

@Quotation(On mechanical slavery, on the slavery of the @i[machine], 
the future of the world depends.)

L'esempio di cui sopra mostra come differenti coppie di caratteri possono essere usate nei delimitatori. I delimitatori esterni usano i caratteri (), mentre quelli interni [].

Tutti i sistemi Scribe offrono un'insieme comune di ambienti ad uso degli autori. Si veda la Tabella 3.

Tenendo a mente l'importanza avuta da Scribe nella promozione della marcatura logica, � da notare come circa la met� degli ambienti abbiano regole presentazionali piuttosto che logiche.

Non tutta la struttura in un documento Scribe deve essere marcata esplicitamente. Scribe � in grado di identificare i paragrafi dallo spazio bianco nel documento sorgente. Si consideri questo esempio:

@begin(enumerate)
The first item of three.

The second item. 

The last item.
@end(enumerate)

L'elenco numerato risultante consiste di tre voci. L'ambiente Multiple pu� essere usato per sovrascrivere l'individuazione automatica della struttura:

@begin(enumerate)
The first item of three.

@begin(multiple)
The second item. 

The second item has two paragraphs.
@end(multiple)

The last item.
@end(enumerate)

Un beneficio dell'individuazione automatica della struttura � che la marcatura nei documenti sorgente pu� essere minimizzata.

Cambiare e aggiungere ambienti

Come detto in precedenza, il database di tipi di documento e di ambienti di formattazione di Scribe � gestito dall'amministratore di sistema. Tuttavia, un autore pu� anche cambiare o aggiungere ambienti per adattarli ai suoi bisogni. Ecco un semplice esempio:

@Modify(Description, Leftmargin 0.5in, Indent -0.5in)

In questo esempio, il margine sinistro e l'indentazione dell'ambiente Description vengono cambiati. Il comando @Modify deve comparire all'inizio del documento. Possono essere definiti anche nuovi ambienti:

@Define(InsetHead=Subheading, Leftmargin 0.5in)

In questo esempio, viene creato l'ambiente InsetHead. Esso copia tutte le propriet� da Subheading tranne che per il margine sinistro. Gli ambienti possono anche essere creati da zero. La documentazione lo sconsiglia, ma specifica la forma generale: :

@Define(Newname, <list of attribute-value paris>)

Ancora: la documentazione elenca un insieme di circa 40 propriet� che definiscono la presentazione degli ambienti.

In effetti, la definizione di ambienti in Scribe comprende sia i fogli di stile che la Document Type Definition (DTD) di SGML.

Scribe nel contesto

Scribe precorse la distinzione tra struttura e stile e consent� agli autori di scrivere documenti senza pensare alla loro formattazione. Il database di tipi di documento ed ambienti di formattazione � gestito dall'amministratore di sistema, ma gli autori che vogliono modificare gli ambienti o aggiungerne di propri sono liberi di farlo. Come tale, Scribe offre il meglio dell'HTML (c'� un insieme predefinito di tag e di convezioni sulla loro presentazione), dei CSS (c'� un insieme predefinito di convenzioni presentazionali che possono essere modificate), e dell'XML (possono essere creati nuovi elementi). Scribe pu� cos� essere stato un'ispirazione migliore per l'HTML che per SGML. Bisogna anche notare che Scribe forn� questa funzionalit� pi� di 15 anni prima di divenire disponibile agli autori sul Web.

Scribe non � pi� disponibile per l'uso da parte degli autori, ma il suo impatto storico sullo sviluppo dei documenti strutturati � significativo. Non ci sono riferimenti a Scribe nello sguardo d'insieme del W3C sui sistemi che hanno influenzato lo sviluppo dell'HTML [W3C 2003], ma gli sviluppatori di SGML si riferiscono a Scribe [Goldfarb 1991] il che � un'influenza indiretta. Il pi� grande traguardo di Scribe pu� essere stato la sua influenza su LaTeX. Leslie Lamport, creatore di LaTeX, cita Scribe nella prima edizione Lamport rimosse il riferimento a Scribe nella seconda edizione del suo libro per ragioni legali. Scrive del suo libro: Ho rimosso ogni riferimento a Scribe nella seconda edizione del libro su LaTeX perch� fui informato che la persona che comprava Scribe da Brian Reid avrebbe gradito trovare qualcuno da citare in tribunale per aver infranto il brevetto o il diritto di autore di Scribe. Mi dispiaceva di non poter ringraziare Brian, ma non volevo sfidare le sorti legali. [Lamport 1986]. [Lamport 2003]

Fondamentale per LaTeX � l'idea dello stile del documento che determina come il documento debba essere formattato – un'idea rubata dal sistema di formattazione testuale Scribe di Brian Reid.

LaTeX � discusso nella prossima sezione.

LaTeX

Il sistema di composizione automatica TeX fu sviluppato da Donald Knuth per la creazione di bellissimi libri [Knuth 1984]. Il suo lavoro inzi� alla fine degli anni '70 e TeX divenne il formato preferito per la pubblicazione scientifica negli anni '80. Sviluppato da un matematico, TeX ha speciali caratteristiche per la formattazione della matematica ma il suo modello di formattazione si adatta a molti tipi di documenti. TeX � stato usato principalmente in ambienti dove la carta � la destinazione finale. I comandi in TeX di solito descrivono relazioni spaziali tra gli elementi e sono cos� presentazionali. Ecco un semplice frammento TeX:

{\narrower\smallskip\noindent
This paragraph will have narrower lines than surrounding paragraphs.
\smallskip}

Molti dei comandi in TeX sono macro che vengono ampliate in comandi base dall'interprete TeX. TeX permette agli utenti di creare le loro macro, e sono stati pubblicati diversi pacchetti macro per TeX. LaTeX � uno di questi pacchetti macro che permette agli autori di creare formati di documento strutturato.

L'autore di LaTeX, Leslie Lamport, era un utente Scribe che voleva rendere LaTeX una sorta di Scribe per TeX [Lamport 2003]. Molte delle caratteristiche in LaTeX furono copiate da Scribe ma, durante lo sviluppo, alcune caratteristiche di Scribe furono eliminate e vennero introdotte nuove funzionalit�. Ecco un semplice frammento LaTeX:

\documentclass{book}
  \title{Comrades and Strangers}
  \author{Michael Harrold}
\begin{document}
  \maketitle
  \chapter{Red Carpet in Paradise}
\end{document}

La prima riga nell'esempio dichiara che il documento diventer� un libro. Altre classi di documento includono: report, lettera, articolo e slide. La scelta della classe del documento influenzer� la presentazione finale del documento, cos� come il tipo di elementi disponibili (o ambienti come LaTeX e Scribe li chiamano). Per esempio, l'elemento chapter, usato pi� avanti, � disponibile in un libro ma non in un articolo. Le successive due righe dichiarano il titolo e l'autore della pubblicazione. La prima parte del codice – fino all'inizio del documento – � chiamata preambolo ed � simile all'elemento HEAD nell'HTML.

Il corpo del documento � contenuto nell'ambiente document. Il comando \maketitle � un modo comune per iniziare i documenti; a seconda della classe del documento e della meta-informazione dichiarata nel preambolo, verr� generato un titolo consono. L'ultimo elemento nell'esempio � un'intestazione di capitolo.

Ci sono molte similarit� tra Scribe e Latex:

• Come in Scribe, le funzionalit� di LaTeX possono essere suddivise in tre gruppi: classi di documento (chiamati tipi di documento in Scribe), comandi e ambienti (chiamati anche ambienti di formattazione in Scribe).
• Molti dei nomi di ambiente sono gli stessi: enumerate, itemize, quotation, description, verbatim, center, flushleft e flushright.
• Entrambi i linguaggi sono legati ad uno specifico formattatore e non si sono candidati per la standardizzazione.
• Sia Scribe che LaTeX forniscono un insieme di base di classi di documento e ambienti che possono essere estesi dagli amministratori locali di sistema o dagli autori.
• Le ambizioni dei due sistemi sono quasi le stesse: dovrebbe essere possibile progettare documenti strutturati senza dover descrivere la loro presentazione, mentre si ha ancora la stampa su carta come obiettivo finale.

Ci sono anche notevoli differenze tra i due sistemi:

• La sintassi � differente; LaTeX usa differenti delimitatori rispetto a Scribe.
• LaTex d� accessso ai comandi TeX. Questo rende possibile controllare la formattazione di un documento a un livello molto basso, ma rende anche difficile – se non impossibile – convertire documenti LaTex in altri formati.

LaTeX � stato un sistema di progettazione di grande successo ed ha avuto molto seguito principalmente negli ambienti accademici. Per il suo successo, LaTeX ha probabilmente fatto molto pi� per i documenti strutturati di ogni altro linguaggio, eccetto l'HTML.

Standard Generalized Markup Language (SGML)

Come � stato detto nella precedente sezione, lo Standard Generalized Markup Language (SGML) non � un formato di documento. SGML � invece un sistema usato per creare nuovi formati di documento. In altre parole, SGML non � – a dispetto del suo nome – un linguaggio di marcatura in s�, ma � usato per definire altri linguaggi di marcatura.

La prima bozza di lavoro di SGML fu pubblicata nel 1980 [SGMLUG 1990] e SGML divenne uno standard ISO nel 1986 [SGML 1986].

SGML � basato su GML (Generalized Markup Language) che fu sviluppato da IBM dall'inizio fino alla met� degli anni '70 [Furuta, et al. 1982]. In [SGMLUG 1990] vengono descritte le persone e le motivazioni dietro GML:

Insieme con Edward Mosher e Raymond Lorie [Charles Goldfarb] invent� lo Generalized Markup Language (GML) come un mezzo per permettere l'editazione del testo, la formattazione, e sistemi di distribuzione dell'informazione per condividere i documenti

GML divenne disponibile per l'uso generale nel 1978 [Furuta, et al. 1982]. Un documento GML appare leggermente differente da un documento SGML poich� esso non usa le ora familiari parentesi angolari per definire i tag. Ecco un semplice frammento da [Furuta, et al. 1982]:

:body.
:h2.The Formatting Problem
:p.In order to discuss formatters and their functions...

Uno dei creatori di GML, Charles Goldfarb, continu� il lavoro che port� a SGML [SGMLUG 1990]:

Dopo il completamento di GML, Goldfarb continu� la sua ricerca sulle strutture del documento, creando concetti aggiuntivi, come brevi riferimenti, processi di collegamento e tipi di documento correnti, che non erano parte di GML ma che in seguito furono sviluppati come parte di SGML.

È da notare come nessuna delle caratteristiche di SGML citate sopra siano state usate. Uno di essi, la caratteristica LINK (descritta di seguito), fu motivata dal bisogno di competere con ODA offrendo un modo per unire informazioni presentazionali ai documenti.

SGML � uno standard complesso e va oltre l'�mbito di questa tesi dare uno sguardo d'insieme di tutte le sue caratteristiche. Di seguito � riportata la descrizione di tre caratteristiche che sono interessanti nel contesto dei fogli di stile; tutte e tre le caratteristiche possono portare potenzialmente informazioni di stile.

Document Type Definition (DTD)

Una Document Type Definition (DTD) � un insieme di regole che definiscono la sintassi di un linguaggio di marcatura. Le DTD sono di centrale importanza per SGML e tutti i linguaggi di marcatura basati su SGML hanno una DTD che descrive gli elementi, gli attributi, le entit� – e la relazione tra di essi. Ecco un semplice frammento dalla DTD dell'HTML4:

<!ELEMENT UL - - (LI)+>

Nell'esempio, si dichiara che l'elemento UL richiede un tag di apertura e di chiusura (rispettivamente, i due trattini), e il modello di contenuto � impostato su (LI)+. Il modello di contenuto descrive che tipo di contenuto � consentito all'interno dell'elemento dichiarato. Nell'esempio, il segno pi� indica che gli elementi UL possono contenere uno o pi� elementi LI. Il frammento che segue aggiunge pi� informazioni sull'elemento LI:

<!ENTITY % inline "A | #PCDATA">
<!ELEMENT LI - O (%inline)*>

La prima riga dell'esempio dichiara un'entit� riferita alla seconda riga: l'elemento LI deve avere un tag iniziale, ma il tag finale � facoltativo. L'elemento LI contiene contenuto in riga, che – secondo la prima riga – sono elementi A o #PCDATA. #PCDATA sta per contenuto testuale. In HTML4, il modello di contenuto per LI � leggermente pi� complesso.

La DTD � anche usata per dichiarare attributi sugli elementi.

La DTD dell'HTML4 usa nomi di entit� come heading, inline e block per raggruppare vari elementi. Questi nomi, tuttavia, non hanno un significato vero e proprio; dal punto di vista di SGML essi sono stringhe casuali. Tuttavia, nelle menti dei creatori della DTD, i nomi hanno un significato che reca in s� sia regole logiche che informazioni presentazionali.

Sebbene per concezione originaria le DTD recano informazioni solo ad un livello sintattico, si possono facilmente aggiungere informazioni presentazionali. Per esempio, questa sintassi estesa descriverebbe il modello di contenuto, insieme con le informazioni sui font preferiti:

<!ELEMENT UL - - (LI)+ 11pt sans-serif>

Il sistema Scribe, discusso in precedenza, usa questo approccio quando definisce nuovi ambienti. Ancora: la proposta di fogli di stile SSP, discussa nel capitolo 4, combina informazioni sintattiche e presentazionali.

Istruzioni di elaborazione

Una Istruzione di elaborazione (PI, Processing Instruction) � un costrutto sintattico di SGML che pu� essere usato per mantenere le informazioni su come il documento dovrebbe essere elaborato, inclusa la sua formattazione. In un messaggio a www-talk [Connolly 1994b], Dan Connolly propose di usare le istruzioni di elaborazione per descrivere la formattazione dei documenti HTML:

Suggerisco di introdurre un intero insieme di istruzioni di elaborazione, cosicch� le persone possono marcare la formattazione dei loro documenti senza influenzarne la struttura. Per esempio, invece dell'elemento <BR>, suggerirei un'istruzione di elaborazione <? linebreak>, e un'entit� &br; come forma abbreviata.

SGML impone poche restrizioni sul contenuto delle istruzioni di elaborazione, e sono possibili un'ampia gamma di istruzioni di elaborazione:

<? the next element should be green  >
<? background=white >
<? p { color: black } >

Una raccomandazione W3C descrive come si possono usare le istruzioni di elaborazione per collegarsi ai fogli di stile dai documenti XML. Si veda la sezione su XML pi� avanti.

LINK

Le specifiche SGML definiscono due tipi di caratteristiche LINK: LINK impliciti e LINK espliciti. I secondi sono poco compresi, e la discussione in questa sezione riguarda solo i LINK espliciti.

Come le istruzioni di elaborazione, la caratteristica LINK fu aggiunta per coadiuvare l'elaborazione dei documenti SGML. Proprio come le istruzioni di elaborazione, uno degli usi della caratteristica LINK � quello di aggiungere informazioni di formattazione ai documenti SGML. Vi sono, tuttavia, diverse differenze tra i due:

• I LINK sono posizionati in dichiarazioni link separate ed esterne, invece di essere inseriti nel documento.
• I LINK definiscono l'elaborazione di un determinato elemento, invece di essere solo un segnaposto per qualsiasi informazione di elaborazione.

Lo scopo principale del meccansimo LINK � di aggiungere attributi agli elementi. Ecco un semplice estratto da una dichiarazione LINK:

<!LINK #INITIAL  table [ ALIGN="right" ]>

La dichiarazione LINK di cui sopra aggiunger� l'attributo ALIGN="right" a tutti gli elementi table.

Un esempio leggermente pi� avanzato mostra come i LINK possono essere usati per aggiungere attributi in modo contestuale:

<!LINK #INITIAL  ul  #USELINK uldef
                    ol  #USELINK oldef>
<!LINK uldef     li  [ mark="bullet" ]>
<!LINK oldef     li  [ mark="digit" ]>

Si consideri questo semplice documento:

<UL>
  <LI>number unknown
    <OL>
      <LI>number one
      <LI>number two
    </OL>
</UL>

Quando la dichiarazione LINK di cui sopra viene applicata al precedente documento, produce il seguente documento:

<UL>
  <LI mark="bullet">number unknown
    <OL>
      <LI mark="digit">number one
      <LI mark="digit">number two
    </OL>
</UL>

Come si pu� vedere dall'esempio precedente, la caratteristica LINK possiede qualcuna delle propriet� di un linguaggio di stile (ossia sintassi e selettori, come descritto nel capitolo 3). Ancora: la caratteristica LINK � un meccanismo generico che pu� essere usato per distribuire ogni sorta di informazione fintanto che l'informazione pu� essere rappresentata in attributi. Tuttavia, la caratteristica LINK manca della nozione di formattazione. Per esempio non vengono proposti propriet�, valori o un modello di formattazione. Perci�, la caratteristica LINK non pu� essere considerata come un linguaggio di stile.

SGML nel contesto

SGML � uno degli standard che ha pi� influenzato il Web, e sia l'XML che l'HTML devono molto del loro sviluppo a SGML. SGML port� con successo importanti problematiche, quali la progettazione dei documenti, la conservazione e lo scambio dei formati, all'attenzione delle comunit� della tecnologia dell'informazione. In particolar modo, SGML mise in evidenza:

• la marcatura logica, piuttosto che la marcatura procedurale;
• che la conservazione dell'informazione e lo scambio dei formati devono essere separati dal software e dall'hardware, per far si che i dati sopravvivano ai sistemi di computer.

Tuttavia, al di fuori di una ristretta comunit�, SGML non ebbe mai il successo che i suoi sostenitori speravano. L'autore crede che vi siano diverse ragioni per questo:

• Lo standard SGML divenne troppo complesso. Il SGML handbook, che � una versione commetata dello standard SGML, ha 664 pagine numerate [Goldfarb 1991]. Sebbene esso includa tutorial e altri testi non essenziali, pu� essere indicativo della complessit� di SGML. Solo un ristretto gruppo di esperti sono in grado di capire nella loro interezza le specifiche SGML. Oltre a non essere compreso, molte delle sue caratteristiche avanzate non furono supportate dalle implementazioni.
• SGML risolse solo in parte i problemi per cui i suoi utenti cercavano delle soluzioni. Esso pu� definire con successo i linguaggi di marcatura, ma poche persone lo fanno realmente. Piuttosto, gli autori hanno bisogno di un vocabolario di elementi e modi per includere la grafica. SGML non cerc� di risolvere questi problemi.
• Mancanza di un linguaggio di stile. Quando SGML divenne uno standard ISO nel 1986, non erano disponibili linguaggi di stile standard per formattare i documenti SGML. La Formatting Output Specification Instance (FOSI; si veda il capitolo seguente) divenne presto disponibile na fu considerata una soluzione temporanea in attesa del Document Style Semantics and Specification Language (DSSSL). Ci vollero circa 10 anni prima che DSSSL fu completato nel 1996. Una soluzione semplice basata su una DTD estesa o una sintassi PI, come discusso in precedenza, possono anche aver reso i documenti SGML pi� facili alla presentazione.

Pu� essere prematuro dare un giudizio su SGML, ma l'autore crede che il successo maggiore di SGML � stato quello di aver inspirato HTML e XML.

HyperText Markup Language (HTML)

Le specifiche HTML sono, insieme con le specifiche HTTP e URL, uno dei mattoni fondamentali del Web. L'HTML ha avuto un impatto a lungo raggio sul modo in cui il contenuto elettronico viene progettato, conservato, trasmesso e elaborato. La progettazione dell'HTML � probabilmente uno dei motivi principali del successo del Web.

Questa sezione discute la progettazione e lo sviluppo dell'HTML in riferimento ai fogli di stile.

L'originale progettazione dell'HTML

L'origine dell'HTML � descritta nel documento W3C Some early ideas for HTML [W3C 2003]:

[Nel 1989] molte persone usavano TeX e PostScript per i loro documenti. Pochi usavano SGML. Tim cap� che c'era bisogno di qualcosa di pi� semplice per tenere testa sia ai semplici terminali che alle workstation X Windows ad alta risoluzione grafica. L'HTML fu concepito come una soluzione molto semplice, da coniugarsi con un protocollo di rete molto semplice come l'HTTP.

Infatti, la progettazione originale dell'HTML era semplice. La prima descrizione dell'HTML disponibile pubblicamente fu un documento chiamato HTML Tags [Berners-Lee 1991a], annunciato e commentato in uno dei primi messaggi [Berners-Lee 1991b] sulla mailing list www-talk nell'ottobre 1991. Mi riferisco a questo documento come a HTML-0. Descrive 22 elementi che costituiscono la progettazione iniziale dell'HTML. In ordine di apparizione gli elementi sono: TITLE, NEXTID, A, ISINDEX, PLAINTEXT, XMP (descritto indirettamente), LISTING, P, H1, H2, H3, H4, H5, H6, ADDRESS, HP1, HP2, DL, DT, UL, MENU e DIR. 13 di questi elementi esistono ancora nell'HTML4 [HTML4 1997], 3 sono stati deprecati (ISINDEX, MENU, DIR), e 6 sono stati rimosssi (NEXTID, PLAINTEXT, XMP, LISTING, HP1, HP2).

È da notare che HTML-0 non includeva alcun elemento presentazionale. Ossia, HTML-0 consisteva solo di elementi logici. Questa fondamentale scelta di progettazione � confermata in una comparazione tra la caratteristica rich text di MIME [Borenstein 1994] e l'HTML [Berners-Lee 1992a]:

Comparando il rich text di MIME e l'HTML, vedo che mancano gli attributi BOLD e ITALIC di formattazione dei caratteri, ma d'altro canto mi accorgo che il nostro modo di trattare i livelli logici di intestazione e le altre strutture � molto pi� potente e ha dimostrato di fornire una formattazione pi� flessibile su piattaforme differenti che si riferiscono esplicitamente in modo parziale alle dimensioni dei font. Ci� deriva da tutti quei sistemi che usano di preferenza stili nominati per la formattazione esplicita, LaTeX o altre macro invece di TeX, ecc, ecc.

I fogli di stile vengono citati una volta in HTML-0 nella descrizione dell'elemento P:

Questo tag indica un nuovo paragrafo. La sua esatta rappresentazione (indentazione, interlinea, ecc.) non � qui definita, e pu� essere una funzione di altri tag, fogli di stile ecc.

Cos�, il concetto di fogli di stile era conosciuto allo sviluppatore HTML. La libreria di programma libwww [Nielsen&Lie 1994] che era una implementazione di HTTP e HTML liberamente disponibile al CERN, supportava i fogli di stile lato-client. Ossia, i fogli di stile erano inseriti nel client per supportare la presentazione dei documenti HTML e non erano considerati come risorse da mettere sul Web. Come tali, i fogli di stile giocarono un ruolo minore nell'iniziale progettazione del Web.

Questo punto di vista � supportato dal fatto che non vi erano discussioni sui fogli di stile nella mailing list www-talk fin dal suo inizio nell'ottobre 1991 finch� Robert Raisch non fece la sua proposta ( RRP, discussa nel prossimo capitolo) nel giugno 1993 [Raisch 1993a].

Struttura contro stile

Sebbene i fogli di stile in s� non fossero discussi su www-talk, il termine stili venne usato poche volte nel contesto dello sviluppo HTML. In un messaggio a www-talk, Berners-Lee sostenne che una struttura annidata sarebbe stata preferibile alla struttura relativamente superficiale che HTML-0 offriva [Berners-Lee 1991b]:

Nello scrivere un nuovo parser generico, mi chiedevo se l'oggetto testuale conserver� la struttura annidata di un documento. Attualmente, il documento � una sequenza lineare di stili: non si possono avere elenchi all'interno di elenchi, ecc. Idealmente, dovrebbe essere in grado di gestirlo - sebbene sia pi� difficile per uno scrittore umano gestirlo mentre formatta il documento. Preferirei infatti, invece di <H1>, <H2> ecc. per le intestazioni [esse provengono dalla AAP DTD], avere un elemento annidabile <SECTION>..</SECTION>, e un generico <H>..</H> che a qualsiasi livello all'interno delle sezioni produrrebbe il livello richiesto di intestazione.

Questo problema � riproposto in un altro messaggio otto mesi dopo [Berners-Lee 1992b]:

Cos� se cerchiamo di ottenere un HTML annidabile, che sarebbe pi� chiaro per quelli che apprezzano la ricorsivit�, dovremmo avere un editor ipertestuale che renda visibile la struttura. Non ho abbastanza esperienza per sapere se coloro che forniscono l'informazione reale (ad esempio segretari) avrebbero familiarit� nel generare elementi annidati – forse gli stili sono utili per conservare l'attuale 'metafora dell'intefaccia utente' degli elaboratori testuali.

Queste affermazioni sostengono che gli elementi in HTML non dovrebbero in generale essere annidati, anche se le strutture annidabili sono pi� chiare. Uno degli argomenti contro gli elementi annidabili � che essi non si combinano con una sequenza lineare di stili. Berners-Lee fa queste affermazioni dopo aver implementato un parser e formattatore HTML della libreria libwww [Nielsen&Lie 1994]. Il conflitto avvertito tra elementi annidabili e stile � probabilmente dovuto ai limiti nell'implementazione. I CSS in seguito affrontarono questo problema introducendo i selettori contestuali.

HTML e SGML

Come i fogli di stile, SGML era conosciuto agli sviluppatori di HTML ma ricopriva un ruolo minore, nel senso che HTML-0 non era formalmente specificato nei termini di SGML. In un certo senso, HTML-0 era incompatibile con SGML [Berners-Lee 1991b]:

<PLAINTEXT> � usato per indicare che il resto del file � di fatto solo ASCII. Annulla completamente il parsing SGML. Per ora � una soluzione di ripiego, finch� non avremo la negoziazione del formato di documento.

Berners-Lee non incoraggiava gli sviluppatori di browser a usare rigidi metodi formali nell'elaborazione di documenti HTML [Berners-Lee 1993c]:

Appoggio completamente Marc nella sua decisione di far lavorare al meglio Mosaic quando viene dato HTML non valido. La massima � che si dovrebbe essere
- conservatori in ci� che si fa
- liberali in ci� che ci si aspetta.

L'autore crede che questo messaggio sia stato infelice. Se Mosaic fosse stato pi� severo nel parsing dell'incipiente HTML, la marcatura potrebbe essere stata molto pi� chiara di oggi.

La filosofia di SGML era, tuttavia, una fonte di ispirazione. In un documento che descrive lo sviluppo di HTML-0 dal titolo Design Constraints, Berners-Lee scrive [Berners-Lee 1992d]:

Si richiede che l'HTML sia un linguaggio comune tra tutte le piattaforme. Ci� implica una marcatura che non sia specifica per un dispositivo, o nulla che richieda un controllo sui font e i colori, ad esempio. Questo si conforma all'ideale SGML.

Diversamente dai fogli di stile, SGML divenne presto un argomento di discussione su www-talk. Dei 31 messaggi postati sulla lista nel 1991 (la lista era iniziata nell'ottobre di quell'anno) otto citavano SGML. Nel 1992, 466 messaggi furono postati sulla mailing list, di cui 138 citavano SGML.

Dan Connolly promosse molte delle discussioni sostenendo che l'HTML dovesse essere definito nei termini di SGML. Nel giugno 1992 egli pubblic� una DTD per l'HTML [Connolly 1992]. Nel messaggio di accompagnamento, spieg� perch� questo era necessario:

C'� bisogno di una DTD SGML affich� si possa analizzare l'HTML usando qualcosa oltre alla pubblica implementazione del WWW, cos� da poter verificare i documenti convertiti da altri sistemi di authoring come GNU info, EZ di Andew, o FrameMaker.

Quasi due anni dopo, Connolly raggiunse la stessa conclusione in un messaggio intitolato Toward Closure on HTML [Connolly 1994b]:

I costi ed i benefici del uso di [sic] SGML per definire l'HTML sono stati discussi a lungo. Sono state suggerite semplificazioni [...] ma a questo punto, sembra che ci sia l'evidente requisito secondo cui un documento HTML debba essere un documento conforme a SGML.

Il messaggio di Connolly gener� forti discussioni su www-talk e molti erano contrari all'idea di rendere SGML parte integrante del Web. La resistenza a SGML si fondava su due argomenti principali. In primis, SGML era percepito come un qualcosa di troppo complesso [Raggett 1993b]:

Ho la sensazione che molte persone trovino SGML difficile da seguire nei dettagli. Il resoconto di Goldfarb su SGML sembra quasi prendersi la briga di rendere difficile la vita per il principiante.

In secundis, si sostenne che l'introduzione di SGML in questa fase non era realistica poich� non rifletteva lo stato del Web a quel tempo [Davis 1994] :

Dan, questo non � un flame, ma tu hai bisogno di guardare in faccia la realt�. Voglio dire, devi osservare ci� che la gente fa VERAMENTE, non ci� che tu VORRESTI facessero. Come hai osservato, la gente non usa un parser SGML per validare i loro documenti. Non c'� motivo di credere che inizieranno mai a farlo. Questa � la realt�.

Nonostante la controversia, HTML2 fu formalmente definito nei termini di SGML e fu pubblicato come RFC 1866 nel novembre 1995 [HTML2 1995].

HMML, HTML+ e HTML3

Mentre HTML2 muoveva lentamente i suoi passi verso la standardizzazione, la comunit� www-talk propose nuove caratteristiche per l'HTML. Fra quelle pi� popolari c'era il supporto per le immagini e il multimedia [Berners-Lee 1993a]:

HMML � di fatto gi� un'estensione di HTML per il multimedia di O'Reilly. Ci sono estensioni simili di NCSA. Dobbiamo solo renderli standard per la prossima DTD che definiremo. L'HTML � gi� stato controllato cos� da non doverlo rendere un target mobile. NCSA Mosaic (gi� rilasciato) per X gestisce le immagini inserite nell'ipertesto, come Viola di O'Reilly (non rilasciato).

La precedente citazione solleva importanti domande sullo sviluppo dei linguaggi di marcatura per il Web: chi dovrebbe essere incaricato dello sviluppo, quali caratteristiche dovrebbero essere supportate, e come dovrebbe essere chiamato il linguaggio? L'acronimo HMML sta per HyperMedia Markup Language [Adie 1993] e ci� indica una preferenza per un nuovo linguaggio con un miglior supporto multimediale.

Pochi giorni dopo, Dave Raggett annunci� che stava scrivendo la nuova versione di HTML [Raggett 1993a]:

In una recente conversazione al telefono, Tim Berners-Lee mi sugger� di assumere l'incarico di scrivere una nuova DTD per le estensioni alle specifiche attuali. Non preoccupatevi - i tag HTML esistenti continueranno ad esistere e non saranno toccati.

Raggett esprime una preferenza sul continuare ad usare il nome HTML cos� come gli elementi HTML esistenti. Un mese dopo spiega il problema del nome in questo modo [Raggett 1993f]:

HMML � il nome di una DTD interna e sperimentale sviluppata da Pei Wei. Tuttavia, le cose divennero confuse quando Tim Berners Lee cominci� ad usare "HMML" per la proposta sostituzione della DTD HTML originale. Per evitare confusioni chiamo la nuova DTD "HTML+", che mette anche in evidenza il fatto di essere un sovrainsieme del formato attuale.

Inoltre, sottolinea il bisogno di una compatibilit� a ritroso con HTML, nel senso che gli elementi HTML continueranno ad esistere e non saranno toccati [Raggett 1993e]:

Il mio obiettivo principale � la compatibilit� a ritroso con l'HTML esistente.

Dale Dougherty di O'Reilly voleva creare un nuovo acronimo ed un nuovo linguaggio [Dougherty 1993]:

Mi piacerebbe vedere delle discussioni sul fatto che HMML sia compatibile a ritroso con HTML. Penso che sia un errore considerarlo solo un obiettivo di sviluppo. Ci sono anche le domande su come i parser WWW lavoreranno nel futuro. Preferirei vedere congelato l'HTML, e HMML come la successiva generazione.

Tuttavia, la discussione sperata da Dougherty non ebbe luogo e Raggett pubblic� le specifiche compatibili a ritroso nel maggio 1993. Alle specifiche ci si rifer� come a HTML+ [Raggett 1993d] e questo nome fu usato fino alla met� del 1994 quando la proposta fu ridenominata HTML 3.0.

HTML+ introdusse diversi nuovi concetti che in seguito divennero parte di HTML; le pi� importanti di queste erano le tabelle e i form [HTML+ 1993]. Fra le caratteristiche proposte da HTML+, ma che non divennero parte di HTML, c'erano le formule matematiche.

HTML+ aggiunse diverse caratteristiche per migliorare la presentazione dei documenti. Alcuni esempi:

• Il proposto elemento FIG accettava l'attributo align che consentiva al testo di fluire vicino alla figura.
• L'elemento FOOTNOTE consentiva alle note a pi� di pagina di essere marcate.
• L'elemento MARGIN indicava note a margine.

La maggior parte della marcatura aggiuntiva offerta da HTML+ era logica in natura, ma con una presentazione che aveva la potenzialit� di arricchire l'aspetto dei documenti HTML.

HTML+ non supportava i fogli di stile. Tuttavia, in A Review of the HTML+ Document Format [Raggett 1995a], Dave Raggett prevede che i fogli di stile sarebbero stati parte di HTML+ in futuro:

Chi fornisce informazioni � interessato a far apparire i propri documenti con uno stile particolare che li possa far differenziare da altre fonti di informazioni. Si sta lavorando per vedere come HTML+ possa supportare l'informazione di stile senza limitarsi all'indipendenza dalla piattaforma. I suggerimenti di stile potrebbero essere espressi come parte dell'intestazione del documento e coprire aspetti come le famiglie di font, il colore e la dimensione del testo, e l'uso dello spazio bianco attorno agli elementi. L'uso di immagini, e l'opportunit� di impostare il colore e la trama dello sfondo offrono ulteriori modi di creare uno stile unico.

Quando HTML+ progred�, fu rinominato HTML 3.0. A questo punto, il lavoro sui fogli di stile per il Web aveva fatto passi in avanti e HTML 3.0 introdusse la funzionalit� per associare i documenti con i fogli di stile [Raggett 1995b]:

HTML 3.0 si basa su informazioni di stile collegate, per dare agli autori il controllo sulla presentazione dei documenti. Tali informazioni sono poste in un foglio di stile collegato, o, come modo di sovrascrittura, nell'intestazione del documento HTML, usando l'elemento STYLE. L'attributo generico CLASS pu� essere usato per creare sottoclassi di elementi quando volete usare uno stile diverso dal normale, per esempio potreste usare <h2 class=bigcaps> per le intestazioni con le lettere maiuscole pi� grandi.

HTML+ e HTML 3.0 non furono mai citate come versioni ufficiali di HTML, ma le specifiche precorsero funzionalit� che, in seguito, hanno avuto un uso esteso sul Web.

HTML 3.2

Diversi implementatori consideravano HTML 3.0 troppo lontano dalle loro implementazioni e volevano che le successive specifiche HTML codificassero i comportamenti attuali piuttosto che sperimentare nuove soluzioni. Questo conflitto era noto sin dallo sviluppo di HTML 2.0. Le specifiche stesse descrivono lo sviluppo:

HTML 3.2 mira a catturare quelle pratiche raccomandate fin dagli inizi del 1996 e come tali da essere usate in sostituzione dell'HTML 2.0. Vengono inclusi gli attributi di rendering pi� impiegati, allorch� si siano dimostrati essere interoperabili.

HTML 3.2 fa anche due riferimenti al non ufficiale HTML 3.0, ma la maggior parte delle nuove caratteristiche di HTML 3.0 non furono incluse. Il nome da dare alle specifiche divenne perci� un problema: dare alle specifiche un nome della serie 2.x sarebbe stato probabilmente pi� corretto a livello tecnico, ma fornire un numero inferiore sarebbe stato difficile. D'altro canto, dare alle specifiche un nuovo numero maggiore (per esempio 4.0) avrebbe promesso pi� di quello che le specifiche potevano mantenere. Perci� fu raggiunta una soluzione di compromesso con 3.2. Un brano dei verbali delle discussioni nell'Editorial Review Board del W3C � incluso nei Riconoscimenti di questa tesi.

HTML 3.2 divenne una Raccomandazione W3C nel gennaio 1997, quasi un mese dopo che i CSS1 raggiunsero il medesimo status. Il divario temporale non era abbastanza grande affinch� l'HTML 3.2 potesse descrivere l'impatto dei fogli di stile, ma la DTD includeva un elemento STYLE che rendeva possibile validare documenti con all'interno dei fogli di stile [HTML 3.2 1997]:

SCRIPT e STYLE sono inclusi per facilitare l'introduzione di script lato-client e dei fogli di stile. I browsers dovrebbero evitare di mostrare il contenuto di questi elementi. Altrimenti [sic] il supporto per essi non � richiesto.

HTML 3.2 fu la prima specifica HTML ad essere pubblicata come Raccomandazione W3C. Come tale, si trattava di un test importante per vedere come differenti organizzazioni membre del W3C, tra cui Netscape e Microsoft, potevano lavorare insieme per raggiungere un consenso su delle specifiche tecniche.

HTML 4

HTML4 divenne una Raccomandazione W3C nel dicembre 1997 [HTML4 1997], meno di un anno dopo che HTML 3.2 aveva raggiunto lo stesso status. HTML4 aggiungeva importanti funzionalit�, soprattutto nell'area dell'internazionalizzazione.

HTML4 � la prima versione standard del linguaggio HTML che descrive come i fogli di stile e i documenti HTML vengono combinati. Vengono descritti tre meccanismi:

• l'elemento STYLE
• l'attributo STYLE
• l'elemento LINK

Questi meccanismi erano stati precedentemente descritti in una Bozza di Lavoro W3C separata [WD-style 1997] e in una certa misura nelle specifiche CSS1 ma, senza un'indagine ufficiale sull'HTML, era impossibile per gli autori usare i fogli di stile aderendo alle Raccomandazioni W3C.

HTML nel contesto

HTML si � sviluppato in modo significativo dalla sua prima versione disponibile nel 1991. Lungo il cammino, sono state aggiunte molte funzionalit� assicurando al contempo la compatibilit� a ritroso. Il principio di incoraggiare la marcatura logica piuttosto che quella presentazionale, � rimasto nonostante le resistenze da parte degli sviluppatori e degli autori. Di conseguenza, i fogli di stile divennereo necessari ed in seguito trovarono il loro posto sul Web.

Ancora: HTML ha resistito alla tentazione di salire troppo in alto nella scala di astrazione. Tim Berners-Lee descrive il difficile equilibrio in un messaggio a www-talk [Berners-Lee 1993b]:

HTML e HTML [sic] hanno uno status a met� tra linguaggio di formattazione e applicazione specifica. Come linguaggio di distribuzione per un uso molto ampio, i tag devono essi stessi essere generici. STRONG come enfasi o EMphasis non � un istruzione di formattazione, � semantico. Ma non � semantico come PROHIBITION o LOCSHELFNUMBER o MICASHEETTHICKNESS.
HTML+ deve, come HTML, evitare di cadere nell'errore di essere troppo legato alla marcatura o ad una specifica applicazione.

(Credo che volesse scrivere HTML e HTML+ nella prima frase.)

L'autore ritiene che l'HTML abbia il giusto livello di astrazione: alto abbastanza per supportare la presentazione su un'ampia gamma di dispositivi, e basso abbastanza per far facilmente afferrare alle persone il significato degli elementi. Sfortunatamente, l'HTML � spesso scritto ad un livello troppo basso di astrazione.

L'HTML ha avuto un profondo impatto sul modo in cui l'informazione elettronica viene scritta, conservata, trasmessa ed elaborata. Se l'HTML non avesse avuto successo, avremmo potuto ancora vivere quei brutti giorni andati [Berners-Lee 1996]:

Chiunque appiccichi su una pagina Web un'etichetta che recita 'questa pagina si vede meglio col browser X' sembra rimpiangere quei brutti giorni andati prima del Web, quando si aveva solo una minima possibilit� di leggere un documento scritto su un altro computer, un altro word processor o un'altra rete.

XML

L'uso di HTML e del Web crebbe rapidamente intorno al 1995. Molti sostenitori di SGML sostenevano che HTML fosse una soluzione temporanea e che il futuro della pubblicazione web fosse SGML. Questo estratto da un messaggio postato sul newsgroup comp.text.sgml � rappresentativo di questo punto di vista [Nicol 1995]:

... alla fine, HTML sar� usato soprattutto per pubblicare home page et similia, e (SGML|RTF|PDF|e qualsiasi altro formato) sar� usato per tutto il resto. Grandi documenti di lunga durata saranno quasi certamente in SGML (o qualcosa di simile)

Tuttavia, molti della comunit� SGML capirono anche che SGML, come descritto in [SGML 1986], non era adatto ad essere usato sul Web. Nel giugno 1996, il W3C annunci� ai suoi membri la formazione della Web-SGML activity [Connolly 1996]. Cito dall'annuncio:

L'obiettivo principale dell'attivit� � lavorare in collaborazione con gli attuali sforzi posti in ISO/IEC JTC1, SGML Open, e in IETF per fornire i tasselli richiesti per completare il mosaico di specifiche che renderanno la pubblicazione web in grado di usare SGML generico.

Il termine SGML generico si riferisce a marcatura generica che usa tag sconosciuti al destinatario.

Il documento costitutivo del SGML Working Group

Nel suo primo messaggio al SGML Working Group, il presidente Jon Bosak elenc� tre obiettivi che ci si attendeva dal gruppo [Bosak 1996b]. Primo: il gruppo voleva produrre una forma di SGML concepita per la trasmissione su Internet:

Le specifiche di un profilo di applicazione che definiscano una forma di SGML concepita per la trasmissione su Internet e l'elaborazione da parte dei programmi utente. A scopi di discussione, al formato cos� definito � stato dato il nome temporaneo di lavoro di Extensible Markup Language (XML).

Secondo: il gruppo doveva lavorare sulle specifiche di tipi di collegamento di base ipertestuali per XML [Bosak 1996b]. Questo lavoro in seguito si trasform� in XLink [XLink 2001] e non viene ulteriormente discusso nella tesi.

Terzo: l'obiettivo era far funzionare DSSSL nel contesto di Internet [Bosak 1996b]:

Le specifiche di estensioni e di testi pubblici richiesti per far funzionare DSSSL nel contesto di Internet. Per esempio, deve essere aggiunto un meccanismo a DSSSL per fare in modo che il testo scorra attorno agli oggetti.

È da notare che il gruppo aveva in programma di dedicarsi a tutte e tre le aree. In precedenza, la comunit� SGML si era organizzata per lavorare su ciascuna di queste tre aree ma in gruppi distinti, il che aveva avuto come conseguenza il fatto che le specifiche non fossero sincronizzate. Assegnando ad un solo gruppo il compito di lavorare su tutte e tre le aree, si poteva produrre un coerente insieme di specifiche nel medesimo arco di tempo.

Alla fine, tuttavia, il lavoro sul collegamento e i fogli di stile fin� in gruppi di lavoro separati e le loro rispettive specifiche furono ultimate pi� di tre anni dopo che XML divenne una Raccomandazione W3C [XSL 2001][XLink 2001].

Le specifiche XML

La prima bozza di lavoro ufficiale di XML fu pubblicata nel novembre 1996 [WD-XML 1996]. Alla riga uno del sommario si legge:

Extensible Markup Language (XML) � un dialetto estremamente semplice di SGML. Tale dialetto � descritto compiutamente in questo documento.

Entrambe le parti della frase precedente sono significative. La prima parte afferma che XML � estremamente semplice. Paragonata con lo standard SGML la prima bozza XML era relativamente semplice, ma definirla estremamente semplice � fuorviante e quest'espressione fu cambiata nella Raccomandazione finale W3C [XML 1998]:

Lo Extensible Markup Language (XML) � un sottoinsieme di SGML, compiutamente descritto in questo documento.

La seconda parte della frase, rimasta immutata tra la prima bozza e la Raccomandazione, afferma che XML � compiutamente descritto in questo documento. Era importante per XML differenziarsi da SGML, nel senso che conoscere SGML non era un requisito per l'uso di XML. A SGML si fa riferimento nella Raccomandazione XML, ma non � tra i riferimenti normativi. Poich� XML ha sei riferimenti normativi si pu� sostenere che XML non sia compiutamente descritto in questo documento come afferma la Raccomandazione.

La frase introduttiva della Raccomandazione XML precisa anche i due compiti principali dell'XML Working Group: il gruppo doveva selezionare quali caratteristiche di SGML andavano supportate da XML, e quindi descrivere l'insieme di tali caratteristiche in maniera leggibile. Il primo compito fu influenzato dai bisogni degli utenti SGML. Dan Connolly divise le caratteristiche in due gruppi: quelle solide a livello di architettura, e quelle inserite a scopo di transizione [Connolly 2000]:

La mia esperienza mi porta a credere che alcune parti di XML siano solide infrastrutture [sic] architettoniche a lungo termine: tag, attributi, e namespace. Ma altre parti sono li per gestire la transizione da esistenti basi software: DTD, entit�, istruzioni di elaborazione, e non raccomando di farci affidamento a meno di non essere costretti in qualche modo dal software esistente.

I namespace, che Connolly includeva nel gruppo di caratteristiche di solida architettura, non facevano parte della Raccomandazione XML, ma sono descritte in una Raccomandazione W3C separata, che segu� dopo un anno la Raccomandazione XML [XML-names 1999].

Tim Bray, uno dei curatori delle specifiche XML, propose in seguito di usare un simile raggruppamento delle caratteristiche XML e di rimuovere le DTD e le entit� dalle future versioni di XML [Bray 2002]. Un motivo per mantenere le istruzioni di elaborazione (che Bray propone) � che esse vengono usate per puntare ai fogli di stile.

XML e fogli di stile

La Raccomandazione XML non fa riferimento ai fogli di stile in alcun modo. Per usare i fogli di stile con i documenti XML c'� bisogno di un modo per collegare il documento ad un foglio di stile. Nel giugno 1999, il W3C pubblic� una Raccomandazione intitolata Associating Style Sheets with XML Documents [XML-stylesheet 1999] che descrive come ottenere questo risultato usando le istruzioni di elaborazione di XML. Per esempio, per collegare un foglio di stile CSS a un documento XML, si pu� inserire la seguente riga nel documento:

<?xml-stylesheet href="mystyle.css" type="text/css"?>

L'uso delle istruzioni di elaborazione per questo scopo era in qualche modo controverso, e la Raccomandazione includeva un avvertimento sul futuro delle istruzioni di elaborazione:

L'uso di istruzioni di elaborazione XML in queste specifiche non dovrebbe essere preso come un precedente. Il W3C non anticipa la raccomandazione sull'uso delle istruzioni di elaborazione in alcuna specifica futura.

Tuttavia, la Raccomandazione [XML-stylesheet 1999] � largamente implementata e le istruzioni di elaborazione saranno, di conseguenza, una probabile parte di ogni futura versione di XML.

XML nel contesto

Il proposto obiettivo della Raccomandazione XML era di rendere il SGML generico in grado di essere servito, ricevuto e elaborato sul Web nel modo che � ora possibile con l'HTML [XML 1998]. Riferendoci strettamente a questo obiettivo, XML non � stato un successo; l'uso di SGML/XML generico sul Web � oggi limitato. Ancora: la maggioranza dei documenti sul Web sono scambiati in HTML e non in XML. Ossia, XHTML – che � HTML scritto secondo le regole di XML – non ha rimpiazzato il tradizionale HTML.

XML � stato un successo, tuttavia, ma forse in un settore che i suoi creatori non si aspettavano. Mentre la Raccomandazione XML descrive documenti XML, Dan Connolly notava nella fase di esordio che l'XML poteva anche essere usato per lo scambio di dati. Quando descriveva l'XML nella newsletter W3C nel marzo 1997, presentava l'XML come un linguaggio di marcatura per l'interscambio di documenti strutturati, na faceva anche notare [Connolly 1997]:

Ci si aspetta che l'interscambio a livello di database e lo scambio di dati strutturati tra componenti software e programmi utente saranno usi comuni.

Infatti, l'impatto di XML sullo scambio dei dati � stato pi� significativo del suo impatto sullo scambio di documenti.

Il ruolo dei linguaggi trasformazionali

Un linguaggio trasformazionale � un linguaggio che esprime trasformazioni da una struttura in un altra. Nel contesto dei documenti strutturati, le strutture sono tipicamente strutture ad albero contenenti contenuto testuale. Per esempio, un linguaggio trasformazionale pu� trasformare un documento scritto in un vocabolario privato XML in un documento XHTML.

In questa tesi, i linguaggi trasformazionali sono interessanti per due motivi:

• I linguaggi trasformazionali sono usati lato server per convertire il contenuto in contenuto per il Web. Di solito una trasformazione sposter� il contenuto in basso sulla scala d'astrazione; per muovere il contenuto in alto, � necessaria l'informazione esterna al documento. È importante che esistano flessibili, potenti ed efficienti linguaggi trasformazionali in modo che il contenuto sia generato al giusto livello di astrazione.
• Una scuola di pensiero nei linguaggi di stile sostiene che il processo di formattazione di un documento pu� e dovrebbe essere espresso come trasformazione. I linguaggi di stile che seguono questa tradizione sono linguaggi trasformazionali cos� come sono linguaggi di stile. In questa tesi, ci si riferisce ad essi come a linguaggi di stile basati sulla trasformazione (TBSSL).

L'ultimo punto � l'argomento di questa sezione. Ritengo che sebbene trattare la formattazione come trasformazione abbia determinati vantaggi, vi sono motivi significativi per non adottare questo approccio sul Web.

Adornare l'albero

La maggior parte dei linguaggi di stile non sono linguaggi trasformazionali. Invece di trasformare la struttura del documento in una struttura di presentazione, questi linguaggi di stile adornano la struttura del documento con informazione presentazionale. Per esempio, si consideri il seguente foglio di stile:

H1 { color: red }

Esso afferma che tutti gli elementi H1 dovrebbero essere rossi. L'informazione sul colore (ed altre propriet� presentazionali) � unita all'elemento H1. Con vari meccanismi di trasmissione di valore, tutti gli elementi nel documento hanno valori per tutte le propriet� presentazionali. Esempi di linguaggi di stile che usano questo approccio sono i CSS, P94 e FOSI.

Le implementazioni di questi linguaggi di stile possono ottimizzare le strutture di memoria, cosicch� non tutti i valori sono conservati su ciascun elemento ma, di principio, la conoscenza del valore di ogni combinazione elemento/propriet� dovrebbe essere nota. Ancora: alcune implementazioni possono scegliere di usare internamente due diverse strutture ad albero, una per la struttura logica ed un'altra per la struttura presentazionale. Tuttavia, a livello concettuale questo comportamento non � necessario.

Trasformare l'albero

I linguaggi di stile basati sulla trasformazione non adornano l'albero, bens� trasformano la struttura logica in una struttura presentazionale. DSSSL e XSL sono linguaggi di stile che ricadono in questa categoria.

Spesso ci si riferisce a questi linguaggi come a linguaggi trasformazionali piuttosto che a linguaggi di stile. Nel caso di XSL, il linguaggio trasformazionale ha un suo proprio nome, XSLT (dove 'T' sta per trasformazione). Di seguito riporto un esempio di come XSLT pu� essere usato per convertire un elemento XML in un elemento HTML. Si consideri un elemento XML scritto in un vocabolario privato:

<ChapterHeading>The headline</ChapterHeading>

Per trasformare l'elemento ChapterHeading in un elemento H1, si pu� usare questo frammento XSLT:

<xsl:template match="ChapterHeading">
  <H1>
    <xsl:apply-templates/>
  </H1>
</xsl:template>

L'output della trasformazione �:

<H1>The headline</H1>

Si noti che l'HTML risultante � ad un livello abbastanza alto di astrazione e che l'indipendenza dal dispositivo e l'accessibilit� sono preservate. Quello che manca � l'informazione su come presentarlo. XSL svolge questo compito con gli oggetti di formattazione.

Oggetti di formattazione

Per far si che i linguaggi basati sulla trasformazione siano anche linguaggi di stile, viene di solito definito un insieme di elementi presentazionali. Gli elementi presentazionali servono come blocchi costitutivi della struttura presentazionale. In DSSSL gli elementi presentazionali sono detti oggetti di flusso e in XSL oggetti di formattazione. Gli oggetti di flusso DSSSL sono discussi con pi� dettagli nel capitolo seguente, e il resto di questa sezione si concentra sugli oggetti di formattazione XSL (XSL-FO) [XSL 2001].

XSL-FO � un vocabolario XML usato per descrivere la presentazione dei documenti. Un semplice foglio di stile XSL che trasforma l'elemento ChapterHeading in un oggetto di formattazione � il seguente:

<xsl:template match="ChapterHeading">
  <fo:block font-size="1.3em" margin-top="1.5em">
    <xsl:apply-templates/>
  </fo:block>
</xsl:template>

L'output della trasformazione � XSL-FO:

<fo:block font-size="1.3em" margin-top="1.5em">
  The headline
</fo:block>

Il risultante oggetto di flusso � ad un livello di astrazione pi� basso dell'elemento HTML dato come output nel precedente esempio. Quando viene trasformato in HTML, la semantica dell'elemento XML (ChapterHeading) � preservata, poich� l'elemento H1 � riconosciuto in toto come un'intestazione di livello 1. Quando viene trasformato in XSL-FO, la semantica si perde e viene rimpiazzata da propriet� presentazionali (font-size, margin-top, e margin-bottom mutuate dai CSS) che sono in basso sulla scala di astrazione.

L'uso esteso di XSL-FO sul Web sarebbe una minaccia all'accessibilit�. Si consideri come esempio la resa braille: poich� i caratteri braille usano molto spazio, le parole sono spesso contratte per far entrare pi� testo su una sola pagina. Tuttavia, alcune parole – per esempio le variabili di programma – non dovrebbero essere contratte. L'HTML offre la possibilit� di esprimere ci� (usando l'elemento VAR) e questo � fondamentale per migliorare la resa braille. XSL-FO, invece, da accesso al testo ma senza l'informazione che pu� essere usata per decidere se una parola pu� essere contratta o meno.

Conservare sia la semantica che la presentazione

I linguaggi trasformazionali come XSLT possono essere usati anche per generare un output che conservi il livello di astrazione contenendo al contempo informazioni presentazionali. Di seguito riporto un esempio dove XML � trasformato in un elemento HTML con propriet� stilistiche CSS associate:

<xsl:template match="ChapterHeading">
  <H1 STYLE="font-size: 1.3em; margin-top: 1.5em">
    <xsl:apply-templates/>
  </H1>
</xsl:template>

L'output della trasformazione �:

<H1 STYLE="font-size: 1.3em; margin-top: 1.5em">
   The headline
</H1>

Il risultato preserva sia la semantica (nella forma degli elementi HTML) che l'informazione presentazionale (come valori nell'attributo STYLE). Quando si scrivono i CSS, normalmente le regole di stile dovrebbero apparire in un foglio di stile separato e non in un attributo STYLE come nel precedente esempio. Avere fogli di stile separati semplifica la gestione dei siti e rende i documenti pi� leggeri. Tuttavia, entrambe le forme sono valide e possono essere automaticamente convertite tra di loro.

La semantica pu� essere ancor pi� preservata usando l'attributo CLASS dell'HTML. Si consideri questo esempio:

<xsl:template match="ChapterHeading">
  <H1 CLASS="ChapterHeading" 
      STYLE="font-size: 1.3em; margin-top: 1.5em">
    <xsl:apply-templates/>
  </H1>
</xsl:template>

L'output della trasformazione �:

<H1 CLASS="ChapterHeading" 
    STYLE="font-size: 1.3em; margin-top: 1.5em">
   The headline
</H1>

Nel precedente esempio, l'attributo CLASS � usato per conservare la semantica del vocabolario XML privato. Poich� questo vocabolario XML non � universalmente compreso, l'aggiunta dell'attributo CLASS non eleva il livello di astrazione del documento sul Web. Tuttavia, l'attributo CLASS fa si che l'autore possa ritrasformare il documento HTML nel documento originale.

Stile contro trasformazione

Come discusso in precedenza, i linguaggi di stile basati sulla trasformazione hanno un differente approccio al processo di formattazione rispetto agli altri linguaggi di stile. Invece di adornare una struttura logica del documento, questi linguaggi trasformano i documenti in una struttura presentazionale di oggetti di formattazione, scendendo in basso nella scala di astrazione. Nel contesto del Web, la trasformazione pu� aver luogo sia lato server che lato client. Ciascuna opzione ha un notevole svantaggio:

• Se la trasformazione ha luogo lato server e gli oggetti di formattazione (per esempio XSL-FO) sono trasmessi sul Web, ci sar� una perdita di semantica, poich� il contenuto trasmesso � ad un livello di astrazione pi� basso rispetto al contenuto trasmesso in HTML.
• Se la trasformazione ha luogo lato client, il browser non sar� in grado di supportare la resa progressiva del contenuto quando il contenuto viene visualizzato in piccoli segmenti al momento del download. Poich� la trasformazione pu� specificare che l'ultimo elemento nella struttura logica dovrebbe venire prima nella struttura presentazionale, l'intero documento deve essere scaricato prima che la trasformazione abbia luogo.

In un ambiente di pubblicazione tradizionale, tuttavia, dove l'output � il materiale stampato, le caratteristiche di cui sopra non sono necessariamente impedimenti, e l'approccio basato sulla trasformazione ha un senso. Ci sono tre motivi per questo:

• Gli autori invieranno spesso materiale in formati differenti che hanno bisogno di una qualche forma di trasformazione prima di essere formattati.
• Poich� il risultato finale � su carta, la perdita di semantica comprensibile dalla macchina � connesso al tipo di media usato.
• La resa progressiva non � un problema se la carta � il risultato finale.

Ergo i linguaggi di stile basati sulla trasformazione possono essere adatti ad ambienti di pubblicazione tradizionali, ma non al Web. Va sottolineato che la discussione in questa sezione riguarda i linguaggi di stile basati sulla trasformazione, non i linguaggi trasformazionali in generale.

Sommario e conclusioni

I sistemi di documenti strutturati sono stati un'area di ricerca e di sviluppo sin dal 1980. Il concetto di separare la struttura dalla presentazione � ora saldamente stabilito. I linguaggi di stile sono un requisito per la presentazione di documenti strutturati, ma diversi formati di documenti strutturati furono sviluppati senza essere accompagnati da un linguaggio di stile. Come risultato, i benefici dei formati di documenti strutturati sono stati limitati.

La scala di astrazione � un metodo proposto per la misurazione dei livelli di astrazione dei formati di documento strutturato. Il livello di astrazione di un formato di documento � un fattore importante quando si vuol determinare se il formato � adatto all'uso sul Web: i formati con un livello alto sulla scala di solito richiedono pi� elaborazione – inclusa la trasformazione e l'applicazione di stili – prima della presentazione. I formati di documento con un livello basso sulla scala di astrazione richiedono meno elaborazione, e possono essere non adatti all'uso sul Web per motivi di accessibilit�. Poich� il linguaggio di stile � una parte importante dell'elaborazione dei documenti prima della presentazione, il livello di astrazione � molto rilevante nel determinare l'adattabilit� di una particolare combinazione linguaggio di stile/formato di documento.

Diversi sistemi di documenti strutturati furono sviluppati negli anni '80 e '90. Scribe, LaTex, ODA, e SGML furono sviluppati prima del Web e nessuno di essi ha avuto largo uso sul Web. HTML e XML furono sviluppati per il Web, e vedono ancora un attivo sviluppo. HTML � il pi� popolare linguaggio di marcatura strutturato per il Web, e – se usato correttamente – � un formato di documento indipendente dal tipo di media, ossia � riconosciuto da tutti i browser web. Come tale, l'HTML ha stabilito un livello di semantica universale per i documenti web. Un'importante caratteristica dell'HTML � che non ha bisogno di estese trasformazioni lato client prima della presentazione. I browser, perci�, possono supportare la resa progressiva dei documenti.

Un'alternativa all'HTML � usare l'XML generico, ossia un vocabolario XML privato. A seconda del formato, il documento pu� richiedere un'estesa trasformazione lato client. Questo rende la presentazione pi� flessibile (per esempio gli elementi possono essere riordinati) ma la resa progressiva diventa impossibile. Ancora: il documento non � pi� compreso universalmente. I linguaggi di stile basati sulla trasformazione non sono perci� adatti al Web.

Differenti formati di documento servono a scopi differenti e ad un pubblico differente. Non c'� nessun formato di documento o livello di astrazione che sar� ideale per tutti gli scopi ed il Web deve essere in grado di ospitare una vasta gamma di formati. La sfida � trovare un formato che abbia un livello abbastanza alto di astrazione tale da essere utile in molti contesti, pur non richiedendo troppi sforzi da parte dell'autore n� troppa trasformazione da parte del programma utente. L'HTML, se usato correttamente, si avvicina ad essere un formato ideale per una vasta gamma di documenti.

Dopo aver stabilito il bisogno di un linguaggio di stile per presentare i documenti, i fogli di stile sono l'argomento dei prossimi due capitoli.

Fogli di stile prima del Web

Una delle pi� interessanti caratteristiche dei documenti strutturati � che il contenuto pu� essere usato in molti contesti e presentato in modi diversi. Una variet� di differenti fogli di stile pu� essere unita alla struttura logica per soddisfare bisogni differenti. Tuttavia, la flessibilit� che i documenti strutturati offrono ha un prezzo, poich� si richiede un meccanismo di fogli di stile per rendere il contenuto disponibile agli utenti.

Affinch� il contenuto nei documenti strutturati sia presentato, � necessario applicare un insieme di regole stilistiche – che descrivono, ad esempio, i colori, i font ed il layout –. Un insieme di regole stilistiche � detto foglio di stile. I fogli di stile, nella forma di documenti scritti, hanno una lunga storia di uso da parte degli editori e dei tipografi per assicurare la consistenza della presentazione, la sillabazione e la punteggiatura. Nella pubblicazione elettronica, il termine foglio di stile � usato soprattutto nel contesto della presentazione visuale, piuttosto che della sillabazione e della punteggiatura. In questa tesi, si definisce foglio di stile un insieme di regole che associano propriet� stilistiche e valori con elementi strutturali di un documento, esprimendo con questo come il documento debba essere presentato.

Nel passato si � fatto riferimento ai fogli di stile con altri nomi. P94 li chiama schemi di presentazione. Interleaf e Xerox Star si riferiscono ad essi come a fogli di propriet�. Microsoft Word li chiama stili. FOSI e DSSSL usano il termine caratteristica per indicare quello che i CSS chiamano propriet�, mentre P94 a volte lo definisce parametro. Poich� varie proposte usano differenti termini per indicare la stessa cosa, per facilitare una comparazione questa tesi usa termini CSS nelle discussioni.

In questo capitolo vengono discussi tre fondamentali linguaggi di stile sviluppati prima del Web. Due di essi (FOSI e DSSSL) furono sviluppati dai comitati per gli standard al fine di essere usati con SGML. Il terzo (P94) fu sviluppato da un progetto di ricerca a scopo sperimentale. I tre sistemi furono scelti poich�:

• aggiungono nuove caratteristiche al concetto di fogli di stile;
• separano i fogli di stile dal documento;
• possono, di principio, essere usati con diversi tipi di sistemi di documento strutturato;
• non sono legati a nessuna particolare applicazione o formattatore;
• furono sviluppati prima del Web. Sebbene lo sviluppo di DSSSL e P94 ebbe in parte luogo dopo il lancio del Web, i linguaggi di stile non mostrano alcuna influenza presa dal Web.

Questo capitolo non copre i sistemi di stile proprietari (come Microsoft Word, FrameMaker, Interleaf, Panorama, Lector, ViewPort e ReportLab's RML2PDF), n� discute sistemi descritti in articoli ma non usati nella pratica (come [Br�ggemann-Klein&Wood 1992] e [Weitzman&Wittenberg 1994]). Ancora: due sistemi di progettazione (Scribe, LaTex), aventi anch'essi linguaggi di stile associati, sono discussi nel precedente capitolo e non qui.

Ogni analisi inizia con una breve descrizione del contesto storico del linguaggio, seguito da una descrizione tecnica. Le analisi non sono esaustive, ma danno uno sguardo d'insieme generale di ogni linguaggio e discutono man mano i punti di interesse. Documenti e frammenti di foglio di stile sono usati estesamente nelle discussioni, poich� credo che i linguaggi di stile si comprendano meglio guardando gli esempi.

Componenti di un linguaggio di stile

Prima di valutare i linguaggi di stile in s�, � necessario stabilire dei criteri comuni con cui giudicare i linguaggi. Suggerisco che un linguaggio di stile abbia sei componenti richiesti:

• Sintassi: un linguaggio di stile ha bisogno di una sintassi per essere espresso in un modo comprensibile dalla macchina. Tutti i linguaggi analizzati in questa dissertazione hanno una sintassi di tipo testuale per renderli pi� facili da leggere e da scrivere per gli umani. Inoltre, la sintassi di un linguaggio di stile pu� essere specificata in una sintassi standard (FOSI � scritto in SGML), oppure presa da altri linguaggi ( DSSSL si basa sul linguaggio di programmazione Scheme), o ispirata da altre sintassi (SSP, discussa nel prossimo capitolo, � ispirata dalle risorse X11 [X11]).
• Selettori: i selettori specificano quanli elementi devono essere influenzati dalla regola di stile. Come tali, i selettori sono il collante tra la struttura del documento e le regole stilistiche nei fogli di stile. Alcuni linguaggi esprimono la selezione solo attraverso selettori (CSS, SSP), altri eseguono una selezione nelle dichiarazioni associate con elementi potenziali (DSSSL, FOSI, P94). Nel secondo caso, un semplice linguaggio di selettori basato sui tipi di elemento � di solito combinato con un linguaggio di espressione.
• Propriet�: tutti i linguaggi di stile hanno un qualche concetto delle propriet� cui possono essere dati valori per cambiare un aspetto della resa di un elemento. font size e font weight sono tipici esempi di propriet�. Alcuni linguaggi raggruppano le propriet� (per esempio tutte le propriet� relative ai font) in categorie (FOSI) o consentono a diverse propriet� di essere impostate con una sintassi abbreviata (CSS). Le propriet� per impostare lo spazio bianco e i bordi possono essere relative alla direzione di scrittura (before/after/start/end), o assolute (top/bottom/left/right e inside/outside). Molti linguaggi di stile hanno propriet� di entrambi i tipi (l'indentazione dei paragrafi � sempre relativa, e i margini di pagina sono di solito assoluti) ma tendono a preferire un solo tipo di propriet�.
• Valori e unit�: le propriet� cambiano la resa di un elemento dopo che gli viene assegnato un certo valore. Il valore pu� essere una stringa, una parola chiave, un numero, o un numero con un identificatore di unit�. Ancora: i valori possono essere elenchi o espressioni che coinvolgono diversi dei sopracitati valori. Un tipico valore in un foglio di stile visuale � una lunghezza; per esempio, 3.1cm che consiste di un numero (3.1) e di un unit� (cm). Le unit� possono essere assolute (per esempio cm) o relative a qualche altra misura (per esempio em, che � relativo alla dimensione del font). Alcuni linguaggi consentono anche di usare espressioni come valori.
• Meccanismo di trasmissione di valore: per evitare di dover specificare esplicitamente tutti i valori per tutte le propriet� e su tutti gli elementi, i linguaggi di stile hanno meccanismi per trasmettere i valori automaticamente. Il beneficio principale della trasmissione di valore sono fogli di stile meno prolissi. Eredit�, valori iniziali e cascata sono esempi di meccanismi di trasmissione di valore.
• Modello di formattazione: tutti i linguaggi di stile supportano un tipo di modello di formattazione. Tutti i linguaggi di stile discussi in questa tesi hanno un modello di formattazione visuale e alcuni supportano anche un modello di formattazione acustico per ragioni di accessibilit�.

  In un modello di formattazione visuale gli elementi logici sono trasformati in oggetti di formattazione durante il processo di formattazione. Spesso gli oggetti di formattazione sono riquadri rettangolari rappresentati uno dopo l'altro o annidati l'uno dentro l'altro. Differenti modelli di formattazione visuale hanno diversi tipi di oggetti di formattazione; per esempio, generati da elementi a livello di blocco, in riga, flottanti e tabelle. Modelli di formattazione visuale possono essere classificati come box model (dove le gerarchie di riquadri vanno l'una dentro l'altra) o come sequence model [modello a sequenza, N.d.T.] (dove le aree sono poste in sequenza nell'area di layout). Inoltre la formattazione pu� essere outside-in (dove gli elementi genitori impostano la dimensioni dei loro figli) o inside-out (dove gli elementi figli determinano le dimensioni del loro genitore).

  La formattazione per un dispositivo acustico � molto diversa dalla formattazione visuale, ma i concetti di fogli di stile, propriet�, valori e unit� sono ancora applicabili.

I componenti di cui sopra sono presenti in tutti i linguaggi di stile. Molti linguaggi di stile hanno anche funzionalit� nei seguenti componenti opzionali:

• Contenuto generato: i linguaggi di stile pi� avanzati hanno modi di aggiungere testo e altro contenuto alla presentazione del documento. I fogli di stile non contengono contenuto sostanziale e il contenuto generato � limitato a brevi passaggi, tra cui semplici stringhe, virgolette, contatori, indicatori a croce, intestazioni/pi� di pagina, regole orizzontali e tavola dei contenuti.
• Meccanismo di collegamento: per avere effetto, un foglio di stile deve essere collegato ad un documento. Il collegamento pu� essere specificato nel documento, nel foglio di stile o dall'utente umano. Il meccanismo di collegamento spesso non fa parte del linguaggio di stile ma viene descritto nelle proposte di linguaggio di stile. Alcuni linguaggi di stile hanno modi per importare un foglio di stile in un altro.

Formatting Output Specification Instance (FOSI)

SGML (come discusso nel Capitolo 2, Documenti strutturati) definisce la sintassi per specificare la struttura e il contenuto di un documento. Tuttavia, SGML non descrive la presentazione dei documenti. Nel 1986, quando SGML divenne uno standard ISO, gli utenti di solito usavano sistemi proprietari per produrre presentazioni umane dei documenti SGML.

Nel 1987, lo US Department of Defense (DoD) organizz� un gruppo per studiare come SGML poteva soddisfare il bisogno dell'interscambio di documenti. Un anno dopo lo DoD adott� SGML come componente di documentazione dell'iniziativa CALS (Continuous Acquisition and Life-cycle Support). L'acronimo CALS in origine stava per Computer-Aided Logistics Support, poi per Computer-aided Acquisition and Logistics Aupport finch� fu cambiato nell'attuale Continuous Acquisition and Life-cycle Support Per i dieci anni successivi, CALS fu un attivo sostenitore delle tecnologie basate su SGML [SGMLUG 1990] [Goldfarb et al.1997].

Oltre a rappresentare la struttura e il contenuto – che SGML supportava – CALS aveva anche bisogno di un modo, neutrale rispetto ai produttori di software, di presentare i documenti SGML. Poich� lo standard non esisteva, CALS ne cre� uno suo. Uno di essi, il CALS Table model, influenz� il table model HTML [Bingham 2000][Raggett 1995c]. In [Kidwell&Richman 1997], la storia � cos� raccontata:

Poich� SGML � indipendente dalla presentazione, erano necessari alcuni mezzi per descrivere la presentazione di un sistema di composizione dei documenti. Sfortunatamente, il linguaggio che la comunit� internazionale degli standard stava sviluppando per soddisfare questo requisito, chiamato Document Style Semantics and Specification Language (DSSSL), fu pubblicato per la prima volta in forma di bozza alla fine del 1994, e fu poi pubblicato come standard ufficiale ISO alla fine del 1997 - otto anni dopo l'identificazione del requisito di CALS. Durante questo periodo, il DoD decise di stabilire una caratteristica ad interim per CALS, basata su SGML, che soddisfacesse i requisiti per la composizione.

La caratteristica ad interim � la Output Specification descritta in [FOSI 1997]. Un foglio di stile scritto seguendo la Output Specification � detto Formatting Output Specification Instance, o FOSI in breve. Le specifiche sono anche comunemente dette FOSI e questo termine � usato nella tesi, sebbene esse si riferiscano a se stesse come ad OS.

Per quasi 10 anni, FOSI fu l'unico metodo neutrale rispetto al produttore per specificare la presentazione dei documenti SGML. Le specifiche FOSI ebbero tre grandi revisioni durante quel periodo e maturarono lungo il cammino. Come con tutte le specifiche di quest'area, FOSI conteneva delle ambiguit� che portarono ad implementazioni non interoperabili [Harvey 2000][ManTech 1997], e alcune delle caratteristiche avanzate non furono ampiamente supportate. Al tempo in cui maturarono le specifiche, ancor prima che DSSSL divenne uno standard, erano rimasti solo due implementatori: Arbortext e Datalogics [Harvey 2002].

Per questi motivi, FOSI fu controverso. Nel 1994, lo United States Postal Service sollecit� un sistema per editare manuali tecnici, e stampare copie dei vari manuali in diverse dimensioni e formati, o generare copie elettroniche attraverso l'uso di un manuale elettronico [USPS 1994]. La sollecitazione specific� che si doveva usare SGML per il contenuto e i fogli di stile FOSI per rendere tale contenuto. Esprimendo grande fiducia in un futuro DSSSL, la sollecitazione afferm� che FOSI definisce l'aspetto di un documento SGML determinando il formato di ogni tag descritto in una DTD. FOSI � ... lo standard governativo riconosciuto per il formato finch� [Document Style Semantics and Specification Language (DSSSL)] non venga approvato come il principale standard internazionale. Interleaf, una societ� di software SGML, protest� contro diversi aspetti della sollecitazione, includendo il requisito di una soluzione per supportare FOSI. Interleaf afferm� che FOSI non � uno standard; l'interpretazione dipende dal sistema ed � di fatto proprietario. Ancora: Interleaf afferm� che lo USPS avrebbe avuto bisogno di personale tecnico e altamente qualificato per costruire i FOSI perch� il processo � complesso, e non intuitivo. Lo USPS difese l'uso di FOSI e la protesta fu respinta [USPS 1994].

FOSI � ancora in uso (2004) e supportato da implementazioni commerciali. Non ho avuto accesso all'implementazione FOSI mentre scrivevo questa analisi, ma in compenso ho avuto utili discussioni con Paul Grosso e Pamela Gennusa che sono stati di centrale riferimento nello sviluppo di FOSI. Le specifiche iniziali FOSI, chiamate MIL-M-28001, furono in origine rilasciate nel febbario 1988; le versioni MIL-M-28001A e MIL-M-28001B furono rispettivamente rilasciate nel luglio 1990 e nel giugno 1993. L'analisi tecnica che segue si basa sull'ultima versione delle specifiche FOSI, MIL-PRF-28001C, pubblicate nel 1997 [FOSI 1997].

Sintassi

Un foglio di stile FOSI descrive la presentazione di un documento SGML. Anch'esso � scritto in SGML. Perci�, FOSI � un primo esempio dell'uso di un linguaggio di marcatura per memorizzare dati (ossia regole stilistiche) piuttosto che documenti. Ecco un frammento FOSI di esempio:

<e-i-c gi="h1">
 <charlist inherit="1">
  <font size="14pt" weight="bold">
 </charlist>
</e-i-c>

L'elemento e-i-c (che sta per element in context) � un meccanismo selettore di FOSI. Nel precedente esempio, tutti gli elementi H1 sono selezionati (gi sta per generic identifier che � un termine SGML per i nomi di elemento).

L'elemento successivo � charlist che contiene un elenco di propriet� stilistiche e valori per gli elementi h1. L'attributo inherit in charlist indica se i valori di propriet� devono essere ereditati dall'elemento genitore o meno. In FOSI i valori booleani sono rappresentati da 1 e 0. Per impostazione predefinita, l'eredit� non � attivata. FOSI ha un meccanismo elaborato per l'eredit� e il default (descritto pi� avanti), ma nell'esempio di sopra tutte le propriet� ereditabili assumono i loro valori dall'elemento genitore ad eccezione della dimensione e del peso dei font.

Selettori

I selettori in FOSI sono espressi come attributi dell'elemento e-i-c. Nel semplice esempio della precedente sezione, tutti gli elementi di un certo tipo (h1) erano selezionati indipendentemente dal loro contesto. Ecco un esempio pi� avanzato che seleziona gli elementi nel contesto (e perci� rende giustizia al nome e-i-c):

<e-i-c gi="li" context="ol">
   <charlist>
     <font posture="italic">
   </charlist>
</e-i-c>

Il selettore di cui sopra esprime due requisiti; per gli elementi da selezionare, essi devono essere di tipo li e avere un elemento ol come genitore. L'attributo context esprime relazioni parentali, e pu� – aggiungendo il carattere asterisco nella tradizione UNIX – esprimere anche relazioni di progenitura.

<e-i-c gi="li" context="* ol">
   <charlist>
     <font posture="italic">
   </charlist>
</e-i-c>

Nell'esempio di cui sopra l'elemento li deve avere un antenato di tipo ol, ma ol non deve essere il genitore.

Le specifiche FOSI descrivono in dettaglio come viene determinata la specificit� di un selettore contestuale (determinare quale percorso contestuale seleziona pi� specificamente il percorso corrente nella terminologia FOSI). La strategia per determinare la specificit� � simile a quella definita nei CSS.

L'attributo occur aggiunge pi� restrizioni ai selettori specificando che l'elemento dovrebbe essere il fratello only, first, last, middle (tutti gli elementi eccetto first e last), notlast, o notfirst. Ancora: all (che � il valore predefinito) � ammesso. Ecco un semplice esempio:

<e-i-c gi="P" occur="first">
 <charlist>
    ...
 </charlist>
</e-i-c>

Gli elementi possono anche essere selezionati in base all'esistenza o al valore di un attributo. FOSI lo fa in due fasi: prima l'elemento � selezionato in base al suo nome, poi vengono selezionati gli attributi. Si consideri questo esempio:

<e-i-c gi="NOTE">
  <att>
    <specval attname="WARNING" attval="#ANY">
    <charsubset>
      ...
    </charsubset>
  </att>
</e-i-c>

Nell'esempio di cui sopra, gli elementi att e specval indicano che solo gli elementi NOTE con un attributo WARNING dovrebbero essere selezionati.

Propriet�

FOSI ha un ricco insieme di propriet� che sono raggruppate in categorie. Ogni categoria � rappresentata da un elemento, e ogni propriet� � un attributo. Si consideri questo esempio:

<e-i-c gi="h1">
   <charlist inherit="1">
     <font size="14pt" weight="bold">
     <textbrk startln="1" endln="1">
     <presp minimum="4pt" nominal="6pt" maximum="8pt">
     <postsp minimum="14pt" nominal="18pt" maximum="18pt">
   </charlist>
</e-i-c>

Le categorie nell'esempio di sopra sono font, textbrk, presp e postsp. Le categorie sono sempre figlie di charlist. Oltre ad essere un contenitore per le categorie, l'elemento charlist determina anche se l'eredit� deve essere attivata per i suoi figli. Il concetto dell'eredit� in FOSI � discusso con maggiori dettagli pi� avanti.

FOSI ha alcune propriet� che sono relative alla direzione di scrittura, e altre che sono assolute. Le propriet� per impostare i margini verticali sugli elementi (dette presp e postsp, abbreviazione per prespace e postspace) sono relative, mentre le propriet� per impostare i margini orizzontali sono assolute (leftind, rightind).

Alcune propriet� sono interdipendenti. Nell'esempio di sopra, presp e postsp avranno effetto solo quando startln e endln sono impostate sull'elemento textbrk.

La Tabella 4 da uno sguardo d'insieme di tutte le categorie FOSI.

In aggiunta alle categorie elencate sopra, FOSI ha diverse categorie per la formattazione delle tabelle.

Valori e unit�

I valori in FOSI possono essere parole chiave, interi e lunghezze.

Le unit� di lunghezza in FOSI sono: pi (pica), pt (punti), in (pollici), mm (millimetri), cm (centimetri), em (spazio em). Si nota che manca un'unit� pixel, e questo indica che FOSI � indirizzato soprattutto per l'output di stampa. L'unica unit� relativa � l'unit� em che i CSS hanno adottato in seguito. L'unit� pica � detta pi, non pc come nei CSS.

I valori possono contenere semplici espressioni, ma unit� relative e assolute non possono essere combinate. Le combinazioni di unit� sono consentite. Per esempio, per specificare 5 pica pi� 3 punti si pu� scrivere:

5pi 3pt

Lo spazio che separa i due valori � facoltativo. La sottrazione si ottiene aggiungendo un valore negativo:

5pi -3pt

I valori interi sono usati per rappresentare valori booleani [FOSI 1997]:

Zero � definito come 0, false, no, e off. Non-zero � definito come 1, true, yes, e on.

Alcune categorie hanno propriet� per definire valori minimi, massimi e nominali:

<e-i-c gi="title" context="chapter">
   <charlist>
     <font inherit="1" size="14pt" weight="bold">
     <leading lead="16pt">
     <quadding quad="center">
     <presp minimum="4pt" nominal="6pt" maximum="8pt">
     <postsp minimum="14pt" nominal="18pt" maximum="18pt">
     <keeps next="1">
     <textbrk startln="1" endln="1">
     <span span="1">
   </charlist>
</e-i-c>

Trasmissione di valore

FOSI ha un modello elaborato per l'eredit� e il defaulting. Alcune propriet� in FOSI sono ereditabili, ma anche le propriet� ereditabili non vengono ereditate finch� l'eredit� non viene abilitata esplicitamente. L'eredit� pu� essere abilitata su di una base per-categoria, ed essa � abilitata mediante l'attributo inherit:

<e-i-c gi="TITLE">
  <charlist>
    <font inherit="1" size="20pt">
  </charlist>
</e-i-c>

Nell'esempio di sopra, tutte le propriet� nella categoria font usano il valore ereditato tranne size che imposta il valore esplicitamente. Impostando l'attributo inherit sull'elemento charlist, l'eredit� sar� abilitata per tutte le propriet� ereditabili:

<e-i-c gi="h1">
   <charlist inherit="1">
     <font size="14pt" weight="bold">
     <textbrk startln="1" endln="1">
     <presp minimum="4pt" nominal="6pt" maximum="8pt">
     <postsp minimum="14pt" nominal="18pt" maximum="18pt">
   </charlist>
</e-i-c>

L'attributo inherit sull'elemento charlist da effettivamente il valore predefinito per tutte le categorie ereditabili al suo interno, e quindi il singolo attributo inherit su ogni categoria ereditabile pu� sovrascriverlo.

Le specifiche descrivono anche un attributo envname sull'elemento charlist [FOSI 1997].

Se l'eredit� non � abilitata per questa categoria, le caratteristiche in questa categoria cui non sono esplicitamente assegnati valori, ottengono i loro rispettivi valori dall'ambiente indicato dall'attributo del nome d'ambiente (envname) della charlist.

In pratica, tuttavia, envname non � mai usato nei fogli di stile FOSI [Grosso 1993].

L'Immagine 2 � una delle poche immagini nelle specifiche FOSI. Descrive il flusso d'informazione nel meccanismo di eredit� e di defaulting.

Modello di formattazione visuale

FOSI supporta un ricco modello di formattazione, inclusi tabelle, layout multi-colonna, aree di intestazione e pi� di pagina, e note a pi� di pagina. Ecco un semplice esempio su come impostare i margini di pagina.

<pagedesc>
  <pagespec>
    <topmarg nomdepth="1.5in">
    <botmarg nomdepth="1.4in">
    <leftmarg width="1.5in">
    <rightmarg width="1.5in">
  </pagespec>
</pagedesc>

Il modello di formattazione di FOSI su basa su una sequenza di aree che confluiscono nell'area di layout. Normalmente gli elementi a livello di blocco sono posizionati relativamente all'area di layout. Tuttavia, FOSI fornisce anche un modo di far riferimento alla posizione dell'elemento genitore per creare una parvenza di box model [FOSI 1997]:

La sintassi per le indentazioni consente per le specifiche [..], rispetto al margine del testo determinato dall'indentazione dell'elemento genitore, per esempio "@+2pi" o "@�2pi". Il delimitatore "@" pu� essere usato per specificare che l'indentazione � relativa al margine di testo stabilito dal genitore dell'elemento, inclusa ogni altra indentazione che pu� essere stata applicata.

Ecco un esempio dell'uso di questa caratteristica:

<e-i-c gi="BLOCKQUOTE">
 <charlist>
   <indent firstln="*" leftind="@+1em" rightind="@+1em">
 </charlist>
</e-i-c>

(In FOSI l'indentazione della prima riga deve essere impostata esplicitamente sul valore speciale * per darle la stessa indentazione del resto del paragrafo.)

Gli elementi sono impostati a blocco o in riga con la categoria textbrk:

<e-i-c gi="BLOCKQUOTE">
 <charlist>
      <textbrk startln="1" endln="1"> 
 </charlist>
</e-i-c>

Le propriet� startln e endln indicano che ci dovrebbe essere un'interruzione di riga rispettivamente prima e dopo l'elemento.

Meccanismo di collegamento

Il pi� delle volte i fogli di stile FOSI non sono direttamente associati con i documenti. Il foglio di stile � associato invece con una DTD e i documenti si riferiscono alla DTD tramite la dichiarazione di doctype SGML. Come viene stabilita l'associazione tra DTD e foglio di stile dipende dall'implementazione.

Contenuto generato

FOSI ha un elaborato sistema per il contenuto generato. Ecco come aggiungere una stringa e un contatore prima di un elemento:

<e-i-c gi="H1">
  <charlist>
    <font weight="medium" size="20pt">
    <enumerat increm="1" enumid="chaptercounter">
    <usetext placemnt="before" source="\Chapter \,chaptercounter,\: \">
    </usetext>
  </charlist>
</e-i-c>

Il contenuto generato � specificato sull'attributo source dell'elemento usetext. I caratteri "\" sono in effetti virgolette per delimitare stringhe di testo. La stringa chaptercounter � il nome di un contatore dichiarato altrove.

Per dare al testo generato uno stile distinto, si pu� usare l'elemento subchars:

<e-i-c gi="H1">
  <charlist>
    <font weight="medium" size="20pt">
    <enumerat increm="1" enumid="chaptercounter">
    <usetext placemnt="before" source="\Chapter \,chaptercounter,\: \">
      <subchars>
        <font weight="bold">
      </subchars>
    </usetext>
  </charlist>
</e-i-c>

Altri contesti di formattazione

Non proposti.

FOSI nel contesto

FOSI fu il primo linguaggio di stile ad essere standardizzato e, come tale, � stato un precursore nell'area dei linguaggi di stile. Le specifiche FOSI sono lunghe e difficili da leggere (per esempio, manca una tavola dei contenuti), ma i fogli di stile FOSI possono essere notevolmente intuitivi, concisi e potenti.

Essendo un precursore, FOSI mostra innovazioni in molte aree. Tra le caratteristiche innovative vi sono:

• L'uso di SGML come base sintattica. Si potrebbe dire che SGML fu inteso per creare linguaggi di marcatura e non di stile, ma la sintassi FOSI resta accessibile sia per gli autori che per i lettori.
• Il meccanismo di eredit�/default. Sebbene sia troppo complicato per essere usato appieno, � un precoce tentativo di affrontare il problema delle fonti multiple per le informazioni stilistiche. Come tale pu� essere paragonato alla cascata nei CSS.
• Il semplice ma potente meccanismo dei selettori. ( La sintassi, tuttavia, � leggibile solo per lo studioso.)

Oltre a essere innovative, le specifiche hanno un �mbito di applicazione ragionevolmente ristretto. Le propriet� sono state scelte con cura per produrre effetti tipografici comuni senza essere eccessive.

Il lato negativo � che alcune caratteristiche descritte nelle specifiche non sono state implementate ed usate. Ancora: il numero delle implementazioni � limitato e supportano sottoinsiemi diversi delle specifiche. Per questo motivo, i fogli di stile FOSI hanno la reputazione di non essere interoperabili [Harvey 2002].

Mentre la comunit� SGML stava aspettando DSSSL, FOSI fece davvero un buon lavoro nella stampa di documenti SGML. Se fossero stati messi in atto maggiori sforzi in specifiche pi� mature, ordinando caratteristiche inusate e affrontando i problemi di maggior importanza per la comunit� SGML (per esempio il testo multidirezionale), penso che FOSI avrebbe prevalso.

DSSSL

Quando FOSI fu adottato da CALS nel 1989, lo si percep� come una soluzione ad interim [Kennedy 1997]. La comunit� SGML si aspettava che DSSSL [DSSSL 1996] fosse una soluzione permanente. Affinch� una soluzione permanente fosse accettabile per la comunit� SGML era necessario:

• che fosse approvata da ISO, la stessa organizzazione che pubblic� lo standard SGML; e
• che supportasse la tipografia multidirezionale. Per il progetto CALS questo aspetto di un linguaggio di stile non era stato importante, poich� tutti i loro documenti erano scritti in inglese.

Il lavoro su DSSSL inizi� nel 1986-87, sovrapponendosi con i ritocchi finali di SGML [Adler 2002]. DSSSL divenne uno standard ISO dieci anni dopo, nel 1996 [DSSSL 1996]. Alte erano le aspettative al momento del rilascio di DSSSL. [ManTech 1997]:

Abbiamo motivo di credere che l'enorme interesse e anticipazione per DSSSL nell'arena SGML non sia senza motivo, e ci aspettiamo che DSSSL sia l'indiscussa (probabile e logica) specifica di scelta nella pubblicazione SGML, sia per una distribuzione cartacea che elettronica.

DSSSL � la specifica pi� complessa esaminata in questa tesi. È difficile da leggere ed ha pochi esempi. La comunit� DSSSL, tuttavia, ha prodotto un corpus di documentazione su DSSSL e il tutorial di Paul Prescod [Prescod 1997a] � stato di particolare aiuto nell'esame di DSSSL.

Tali specifiche constano di due parti principali: il linguaggio di stile ed il linguaggio trasformazionale. Solo il linguaggio di stile sar� argomento di questa dissertazione, e il linguaggio trasformazionale non viene discusso. Il linguaggio di stile in DSSSL pu� anche essere usato come linguaggio trasformazionale, tramite un'estensione supportata da Jade [Clark 1998], un'implementazione DSSSL.

Sintassi

DSSSL si basa sul linguaggio di programmazione Scheme, e ci� si riflette nella sintassi come funzionalit�. Scheme � un esempio di linguaggio di programmazione funzionale che enfatizza la valutazione delle espressioni, piuttosto che l'esecuzione di comandi [Hutton 2002]. Mentre la maggior parte degli altri linguaggi di stile non sono Turing-complete, DSSSL � invece un linguaggio di programmazione Turing-complete. Le stesse specifiche DSSSL [DSSSL 1996] lo minimizzano:

I linguaggi delle specifiche DSSSL sono dichiarativi. Non vogliono essere linguaggi di programmazione completi, sebbene contengano costrutti normalmente associati con tali linguaggi.

(L'espressione linguaggi delle specifiche DSSSL si riferisce al linguaggio di stile DSSSL e al linguaggio trasformazionale DSSSL.)

Jon Bosak spiega come DSSSL sia differente dagli altri linguaggi di programmazione [Bosak 1997]:

Si commette un errore mettendo DSSSL nel mucchio dei linguaggi di scripting. Si, DSSSL � Turing-complete e si, � un linguaggio di programmazione. Ma un linguaggio di scripting (almeno nel modo in cui io uso tale termine) � procedurale, mentre DSSSL non lo � proprio. DSSSL � completamente funzionale e privo di effetti collaterali. Non succede mai nulla in un foglio di stile DSSSL. Il foglio di stile � una macro-funzione il cui valore � una descrizione astratta, non dipendente dal dispositivo e procedurale, del documento formattato, che viene fornita come specifica (una dichiarazione, se volete) delle aree di visualizzazione costituitesi dopo i processi di resa.

Paul Prescod [Prescod 1997a] allarga il concetto dell'essere privo di effetti collaterali:

Il "linguaggio di espressione" di DSSSL � un linguaggio di programmazione dalle caratteristiche complete, che pu� fare la maggior parte delle cose che gli altri linguaggi di programmazione fanno. Esso, comunque, � un linguaggio privo di effetti collaterali. Ci� significa che non si pu� leggere o scrivere file, aprire o chiudere finestre, inizializzare variabili o qualsiasi altra cosa se non trasformare o formattare un documento SGML.

La scelta di Scheme come base per DSSSL fu elogiata da Erik Naggum [Naggum 1994] :La mancanza delle normali maiuscole in questa citazione � una scelta dell'autore originale.

il vantaggio pi� ovvio di usare Scheme � che il team di DSSSL si � basato sulle decine di anni di esperienza che portarono a Scheme, non dovendo inventare un loro linguaggio. il secondo vantaggio pi� ovvio di usare Scheme � che diversi grandi produttori usano gi� linguaggi della famiglia LISP nei loro prodotti, se non Scheme stesso, e che ha una sintassi semplice che si pu� imparare in mezz'ora.

Ci furono pochi dissenzienti nei riguardi della scelta di basare DSSSL su Scheme. Paul Prescod present� qualche idea eretica in un messaggio postato sulla mailing list DSSSL [dssslist] nel maggio 1997. Una delle questioni era la sintassi [Prescod 1997a]:

Una sintassi inferiore a Lisp? Forse una sintassi come quella dei CSS? Sono fortemente a favore della gi� esistente sintassi di DSSSL per la sua intera costituzione, ma non voglio disgustare i Dirty Perl Hackers.

A questo punto, comunque, DSSSL era gi� divenuto uno standard ISO e non era prossimo al cambiamento.

Ecco un semplice frammento DSSSL:

(element H1
  (make paragraph
      font-size: 14pt
      font-weight: 'bold))

L'esempio di cui sopra dichiara che gli elementi di tipo H1 sono di blocco con il testo in grassetto di 14pt. Nella terminologia DSSSL, una Specification of a Sequence of Flow Objects (altrimenti nota come sosofo) � restituita dalla regola di costruzione dell'elemento ogni volta che si incontra un elemento H1 nel sorgente. La sequenza specificata nella precedente regola contiene solo un offetto di flusso, ossia l'oggetto di flusso paragraph.

La precedente regola � composta di due parti:

• la parte selettore (descritta di seguito nella sezione "Selettori");
• l'espressione di costruzione, ossia la funzione "make" che crea l'oggetto di flusso (descritta di seguito nella sezione "Propriet�").

Due propriet� vengono impostate nella precedente espressione: font-size e font-weight. La prima propriet� riceve un valore di lunghezza (14pt) e la seconda una parola chiave ('bold). Le parole chiave in DSSSL sono precedute da ' per indicare che non dovrebbero essere valutate in seguito.

Poich� DSSSL � un linguaggio di programmazione, le operazioni comuni si possono astrarre in una funzione separata. Si consideri questo esempio:

(define (create-heading heading-font-size)
  (make paragraph
        font-size: heading-font-size
        font-weight: 'bold))

(element h1 (create-heading 24pt))
(element h2 (create-heading 18pt))

Nell'esempio precedente, viene definita la funzione create-heading. Essa riceve un solo argomento, ossia la dimensione dell'intestazione. Richiamando la funzione con argomenti differenti, gli elementi h1 e h2 avranno differenti dimensioni dei font, ma saranno entrambi in grassetto.

Sebbene la sintassi di DSSSL sia basata su Scheme, i fogli di stile DSSSL sono tecnicamente documenti SGML e hanno bisogno di un DOCTYPE SGML per essere riconosciuti come tali.

<!DOCTYPE style-sheet system "style-sheet.dtd" >

(element P
  (make paragraph
    first-line-start-indent: (* 2 (actual-font-size))))

Selettori

I selettori in DSSSL sono semplici. A differenza dei CSS, gran parte della logica di DSSSL usata per impostare i valori di propriet� su uno specifico elemento si trova nelle dichiarazioni piuttosto che nei selettori. I selettori formano la prima parte delle regole di costruzione. Ci sono cinque tipi di regole di costruzione e ciascuna � descritta di seguito.

Per un dato elemento in un documento, solamente una regola di costruzione pu� essere eseguita. Ci� si differenzia dai CSS, dove diversi selettori possono selezionare un elemento. Come i selettori CSS, le regole di costruzione DSSSL hanno una specificit� per determinare quale costruzione deve essere usata.

Regola di costruzione degli elementi

Le regole di costruzione degli elementi sono il tipo pi� comune di regole di costruzione. Gli elementi sono selezionati in base al loro tipo:

(element h1 (make paragraph ...))

Ancora: i selettori contestuali possono essere scritti come regole di costruzione degli elementi:

(element (ol li) (make paragraph ...))
(element (html body div h1) (make paragraph ...))

Il primo selettore nell'esempio seleziona gli elementi li figli degli elementi ol. Il secondo selettore elenca tre elementi che devono essere gli immediati antenati dell'elemento h1 per poter selezionare.

Per scrivere query pi� complesse si pu� usare Standard Document Query Language di DSSSL insieme con espressioni condizionali. Ecco un semplice esempio che seleziona gli elementi in base all'esistenza di un attributo:

(element NOTE
   (if (not (node-list-empty? (attribute "WARNING")))
     ...
     ...))

Nell'esempio di sopra, vengono selezionati gli elementi NOTE con un attributo WARNING. Ecco un altro esempio che seleziona tutti gli elementi P che sono primi figli:

(element P
   (if (absolute-first-sibling? (current-node))
     ...
     ...))

Combinando il linguaggio di query con le espressioni matematiche offerte da DSSSL, si possono costruire dei selettori interessanti:

(element TR
   (if (= (modulo (child-number) 2)
          0)
     ...   ;even-row
     ...)) ;odd-row

L'esempio di sopra consentir� ai fogli di stile di impostare i valori su ogni altra riga in una tabella HTML.

Regola di costruzione della radice

La regola di costruzione della radice seleziona l'elemento radice, indipendentemente dal suo nome. Un esempio:

(root (sequence
    font-family-name: serif-font-family))

Regola di costruzione predefinita

La regola di costruzione predefinita � usata per impostare regole per tutte le propriet�. Si consideri questo esempio:

(default (sequence
    font-family-name: serif-font-family))

Regola di costruzione di query

La regola di costruzione di query non � supportata dalla principale implementazione DSSSL (Jade [Clark 1998]) e perci� non � ampiamente usata. La regola di costruzione di query non deve essere confusa con il linguaggio di query profondo che � stato implementato ed � in uso. Ho trovato solo un esempio (da [Martin 1999]) che usa le regole di costruzione di query:

(query q-class 'pi )
   (make paragraph
       literal "Processing instruction: "
       (node-property 'system-data
            (current-node))
   )
)

Il codice precedente selezioner� tutte le istruzioni di elaborazione (pi) in un documento e stamper� i loro nomi preceduti dalla stringa Processing instruction. Prescod afferma che ... si possono usare le espressioni condizionali per fare praticamente le stesse cose con maggior lavoro [Prescod 1997a]. Si veda Regola di costruzione degli elementi per gli esempi.

Regola di costruzione di ID

La regola di costruzione di ID si usa per selezionare gli elementi in base al loro ID. Si consideri questo esempio HTML:

<P ID="x678y">An S-expression is a list
   of function calls and their arguments.</P>

L'elemento P dell'esempio pu� essere selezionato con questa regola di costruzione di ID:

(id ("x678y")
  (make paragraph))

Propriet�

DSSSL fornisce un nutrito insieme di oltre 200 propriet� (dette caratteristiche nella terminologia DSSSL) per descrivere la resa del contenuto. L'autore ha contato complessivamente 213 propriet�, escluse quelle usate solo negli oggetti di flusso matematici.

Come in altri linguaggi di stile, non tutte le propriet� si applicano a tutti gli elementi. In DSSSL, ogni tipo di oggetto di flusso accetta un sottoinsieme di propriet�. Per esempio, l'oggetto di flusso paragraph accetta tutye le propriet� relative ai font (tra le altre) mentre l'oggetto di flusso simple-page-sequence accetta le propriet� per impostare i margini di pagina. A livello concettuale, gli oggetti di flusso DSSSL sono simili agli oggetti di formattazione XSL discussi nel precedente capitolo, ma non vi � una sintassi XML per gli oggetti di flusso DSSSL.

Nella Tabella 5, gli oggetti di flusso DSSSL sono elencati insieme con le propriet� che accettano. Va oltre l'�mbito di questa tesi descrivere in dettaglio gli oggetti di flusso e le propriet� associate, ma la tabella fornir� un'indicazione della complessit� di DSSSL. Un punto interrogativo dopo il nome di una propriet� indica che la propriet� accetta solo un valore true/false.

La maggior parte delle propriet� in DSSSL sono relative alla direzione di scrittura, piuttosto che essere assolute. Per esempio, le propriet� dei margini per l'elemento di flusso paragraph sono dette start-margin e end-margin piuttosto che margin-left e margin-right che usano i CSS. Tuttavia, i margini di pagina sono impostati con propriet� assolute, tra cui left-margin e right-margin.

Valori e unit�

DSSSL offre un semplice insieme di valori e unit� che troviamo anche in altri linguaggi di stile, cos� come la possibilit� che i valori siano elenchi e espressioni avanzate.

I valori usati pi� di frequente in DSSSL sono:

• parole chiave (per esempio 'bold): le parole chiave iniziano con un apostrofo (') per indicare che non deve essere eseguita nessuna ulteriore elaborazione;
• valori booleani: true/false sono rappresentati rispettivamente da #t e #f;
• valori di lunghezza: l'unit� di lunghezza di base per DSSSL � il metro, m. Unit� derivate predefinite sono: cm, mm, in, pt, pica.

Ecco un semplice esempio di valore e unit� in DSSSL:

(element H1
  (make paragraph
      font-size: 20pt))

Nell'esempio di sopra, la dimensione del font degli elementi H1 � impostata su una dimensione fissa.

Si noti come dall'elenco delle unit� manchino le unit� relative, per esempio l'unit� em usata in FOSI (e in seguito nei CSS). Jon Bosak presenta un modo di supportare l'unit� em in DSSSL [Bosak 1996a]:

(define %visual-acuity% "normal")
;; (define %visual-acuity% "presbyopic")
;; (define %visual-acuity% "large-type")

(define %bf-size%
  (case %visual-acuity%
(("normal") 10pt)
(("presbyopic") 12pt)
(("large-type") 24pt)))

(define-unit em %bf-size%)

Nell'esempio di cui sopra, un em � impostato come misura assoluta uguale all'altezza di un font di base. La dimensione del font di base dipende dalla variabile visual-acuity. Questa definizione di em lo rende un'unit� assoluta.

Di solito, tuttavia, l'unit� em � relativa alla dimensione del font dell'elemento stesso o alla dimensione del font dell'elemento genitore. Ci� si pu� anche esprimere in DSSSL. Si consideri questo esempio:

(element H1
  (make paragraph
      font-size: (* 2 (inherited-font-size))))

L'espressione (* 2 (inherited-font-size)) si riferisce alla dimensione del font ereditata dall'elemento genitore e la moltiplica per due prima di assegnarla all'elemento H1. Questo esempio mostra come DSSSL usi le espressioni per operazioni abba stanza semplici e che tali espressioni possono essere molto potenti. Le espressioni in DSSSL si estendono ben oltre le unit� pi� avanzate. Si consideri questo esempio:

(element H1
  (make paragraph
      font-size: (+ 4pt (inherited-font-size))))

L'esempio di sopra imposta la dimensione del font dell'elemento di 4pt pi� grande di quella dell'elemento genitore. Questi tipi di valore non sono possibili senza le espressioni.

Trasmissione di valore

DSSSL ha un semplice modello per la trasmissione di valore. Le propriet� sono classificate come ereditate o non-ereditate. Tutte le propriet� ereditate hanno un valore initial, e tutte le propriet� non-ereditate hanno un valore default che serve al medesimo scopo. In generale, DSSSL e i CSS concordano su quali propriet� sono ereditate.

Modello di formattazione visuale

DSSSL ha un ricco modello di formattazione, con particolare riguardo sulla produzione di un output per la stampa. Un foglio di stile DSSSL pu� specificare layout multicolonna, note a pi� di pagina, note a margine, tabelle e altri construtti avanzati. Centrale per il modello di formattazione DSSSL � la nozione di oggetti di flusso e aree.

Oggetti di flusso

DSSSL definisce l'aspetto visivo di un documento formattato in termini di valori di propriet� uniti ad un albero di oggetti di formattazione, chiamati oggetti di flusso in DSSSL. Il primo passo nel processo di formattazione � costruire l'albero di oggetti di flusso dal documento sorgente. Questo processo � un processo di trasformazione dell'albero, e non � un caso che DSSSL sia anche un linguaggio di trasformazione dell'albero.

DSSSL definisce 35 tipi di oggetti di flusso (inclusi oggetti di flusso per le tabelle e la visualizzazione online, esclusa la matematica). Gli oggetti di flusso DSSSL e le relative propriet� sono elencati nella sezione "Propriet�". Due oggetti di flusso comunemente usati sono paragraph (visto nei precedenti esempi) e simple-page-sequence. Di seguito riporto un semplice esempio dell'uso di simple-page-sequence per impostare i margini sulle pagine:

(root
  (make simple-page-sequence
        left-margin:            1in
        right-margin:           1in
        top-margin:             1in
        bottom-margin:          1in
(process-children)))

L'esempio � tratto da [Germ�n 1997]. Oggetti di flusso pi� avanzati consentono al contenuto, ad esempio, di essere presentato in un layout multicolonna, in note a margine o a pi� di pagina. Una caratteristica che manca � quella delle immagini flottanti col testo intorno.

Gran parte del lavoro su DSSSL si � svolto per assicurare che gli oggetti di flusso supportino il testo multi-direzionale.

Aree

La seconda parte del processo di formattazione � produrre una sequenza di aree rettangolari dall'albero degli oggetti di flusso. Le specifiche DSSSL affermano di non descrivere completamente le aree (La natura di queste aree non � specificata completamente da questo International Standard [DSSSL 1996]), ma sembrano essere descritte con un livello di dettagli paragonabile ad altri linguaggi di stile.

Le aree hanno larghezza ed altezza fisse. Ci sono due tipi di aree: aree in riga che sono parte delle righe, e aree di visualizzazione che non sono parte delle righe. Di solito le aree di visualizzazione sono contenitori a livello di blocco per altro contenuto.

Meccanismo di collegamento

N� SGML n� le specifiche DSSSL descrivono come collegare i fogli di stile ai documenti. Di solito, le implementazioni DSSSL cercano istruzioni di elaborazione SGML nel documento sorgente. Per esempio Jade [Clark 1998] riconosce due tipi di istruzioni di elaborazioni:

  <?stylesheet href="sysid" type="text/dsssl">
  <?dsssl sysid>

Nell'esempio di sopra, sysid is a identificatore di sistema che di solito � il nome di un file.

Contenuto generato

DSSSL possiede una robusta funzionalit� per il contenuto generato. Attraverso le espressioni, diversi spezzoni di vari stili possono essere associati con qualsiasi elemento. Ecco un semplice esempio tratto da [Prescod 1997a]:

(element note (make paragraph font-size: 12pt
    (make sequence
        font-weight: 'bold
        (literal "Warning:"))
    (process-children)))

L'esempio di sopra aggiunge la stringa Warning prima del contenuto dell'elemento note.

Altri contesti di formattazione

Non proposti.

DSSSL nel contesto

DSSSL fu accolto con entusiasmo dagli esperti SGML quando fu rilasciato nel 1996. Erik Naggum scrisse [Naggum 1994]:

� la cosa migliore accaduta nel mondo di SGML fin dai tempi di SGML stesso, � forse anche di pi� [...] � un ottima cosa. merita di divenire un International Standard [...] DSSSL � un lavoro robusto.

Tuttavia, l'esperienza di implementazione e l'uso effettivo di DSSSL sono stati limitati [DuCharme 2001]. Ci sono, credo, due importanti motivi per questo: le specifiche stesse e il mondo esterno.

In primis, le specifiche stesse sono difficili da leggere a meno di non essere un esperto di SGML. La terminologia usata nelle specifiche � precisa, ma concisa. Un'esempio della terminologia DSSSL � l'acronimo sosofo, che sta per specification of sequence of flow objects.

Ancora: il linguaggio basato su Scheme usato per dare forma ai fogli di stile � scoraggiante per i non-programmatori. Il linguaggio usa parentesi annidate in modo esteso e per impararlo dovete smettere di aver paura delle parentesi [Radestock 2004]. Alcuni esperti SGML non consideravano la sintassi come un problema [Milowski 1997]:

Il fatto che Perl abbia avuto successo con una sintassi piuttosto criptica suggerisce che non � la sintassi ma ci� che il linguaggio fa a far avere successo a qualcosa. Se posso trasformare i miei documenti con poche righe di codice DSSSL e con parentesi a profusione, ho la meglio su altri linguaggi in cui � richiesta maggiore applicazione! (rima non voluta) Il nostro obiettivo dovrebbe essere quello di ampliare le –chiare e semplici descrizioni delle cose da fare– di DSSSL, e non un cambiamento della sintassi.

In secundis, quando DSSSL emerse nel 1996 dopo dieci anni di sviluppo, il mondo esterno era cambiato. Stampare documenti SGML non era pi� la sfida primaria per i documenti strutturati. Invece, l'HTML ed il Web erano gi� arrivati, ma DSSSL non era rivolto al Web. Non poteva esprimere comuni presentazioni HTML (per esempio lo stile dei link visitati e attivi). Fu sviluppato un profilo di DSSSL concepito per il Web (chiamato DSSSL Lite, discusso nel prossimo capitolo) ma non ebbe molto successo.

Considerando l'uso che ne venne fatto, DSSSL non ebbe successo come linguaggio di stile. Tuttavia, le specifiche DSSSL hanno infleunzati altri linguaggi di stile, soprattutto nell'area del layout multi-direzionale. La comunit� DSSSL ha da allora sviluppato XSL [XSL 2001] all'interno del W3C.

P94

Il linguaggio P fu sviluppato da Vincent Quint e Ir�ne Vatton come parte delle loro ricerche sui documenti strutturati presso INRIA a Grenoble [Thot 2001]. Complessivamente, il linguaggio 'T' (che sta per Trasformazione), il linguaggio 'S' (che sta per Struttura) e quello 'P' (che sta per Presentazione) formano i linguaggi Thot. Sono supportati da una libreria software nota come libreria Thot. Lo scopo della libreria Thot � di facilitare la creazione di applicazioni incentrate sul documento e basate sul concetto di documenti strutturati attivi.

Il lavoro su Thot inizi� nel 1983 e i risultati iniziali furono pubblicati per la prima volta nel 1986. Seguirono diverse collaborazioni a livello industriale e Thot form� il nucleo di diversi prodotti commerciali, tra cui Grif e Symposia. Nel 1995 INRIA divenne l'host europeo del World Wide Web Consortium, e Vincent Quint e Ir�ne Vatton si unirono allo staff W3C nel 1996. Il lavoro su Thot prosegu� nell'editor Web Amaya del W3C, che usa la libreria Thot. Amaya � l'applicazione usata come banco di prova per le specifiche W3C, e i CSS, XHTML, SVG, MathML e XML sono sperimentalmente supportati da Amaya. Di solito Amaya aggiunge il supporto ad una nuova specifica traducendo il linguaggio esterno in uno dei linguaggi interni (P, S o T). Il formattatore di Amaya � costruito sul linguaggio P e la formattazione predefinita dei linguaggi di marcatura supportati da Amaya � descritta in P. Ancora: Amaya supporta i CSS generando regole P che sono poi interpretate dal formattatore.

Per il supporto dei CSS in Amaya era necessario estendere il linguaggio P in alcune aree. Per esempio, tutte le unit� di lunghezza CSS sono ora supportate in P ed � stato aggiunto un insieme di propriet� per supportare padding, bordi e margini intorno agli elementi. A scopo di ricerca, � interessante studiare il linguaggio P prima dell'influsso dei CSS e del Web. La discussione che segue � perci� basata sul linguaggio P come esisteva nel 1994 e ci si riferisce ad esso come a P94 [Quint 1994].

Sintassi

I fogli di stile in P94 sono chiamati schemi di presentazione. Essi hanno due parti principali: dichiarazioni e regole. Ecco un piccolo, ma abbastanza avanzato, foglio di stile in P94:

PRESENTATION HTML;
COUNTERS
   H2Counter : Set 0 on H1 add 1 on H2;
DEFAULT
        BEGIN
        Size: Enclosing =;
        Weight: Enclosing =;
        END;
RULES
  H2:
        BEGIN
        Size: Enclosing + 4 pt;
        Weight: Bold;
        END;
END

La prima riga dichiara il tipo di documenti a cui si applica il foglio di stile. Il foglio di stile di cui sopra si applica ai documenti HTML. La stringa HTML � arbitraria; � compito del sistema Thot associare il foglio di stile al documento.

L'esempio ha solo una dichiarazione; la sezione COUNTERS specifica che il contatore chiamato H2Counter � impostato a zero quando trova un elemento H1, ed � incrementato di uno quando trova un elemento H2 in un preordine trasversale dell'albero del documento. ( Il contatore viene qui solo dichiarato, e non � realmente usato.)

Nell'esempio precedente, ci sono due sezioni che contengono regole: DEFAULT e RULES. Un blocco di regole inizia con la parola BEGIN e termina con END;. Il primo blocco contiene due regole. La prima specifica che la dimensione del font deve essere ereditata dall'elemento genitore, e la seconda specifica che il peso del font deve essere ereditata dall'elemento genitore. Le regole nella sezione DEFAULT si applicano a tutti gli elementi a meno di non essere sovrascritte da altre regole nella sezione RULES. Nell'esempio la sezione RULES contiene regole che si applicano solo agli elementi H2. La prima specifica che la dimensione del font deve essere di 4pt pi� grande di quella dell'elemento genitore, e la seconda imposta il peso del font sul grassetto.

P94 � un linguaggio non sensibile alle maiuscole e alle minuscole. Per convenzione, propriet� e valori sono scritti con la iniziale maiuscola, mentre altre parti del linguaggio sono scritte in maiuscolo.

In modi diversi, la sintassi di P94 � simile al linguaggio di programmazione Pascal [Munson 1996]. Enfasi viene posta nel dichiarare i valori prima di usarli per esempio i contatori), e nel rafforzare una struttura di blocco (vengono usate le parole chiave Pascal BEGIN e END).

Selettori

Come in DSSSL, i selettori in P94 sono semplici. Solo i nomi di elemento e i nomi/valori di attributo possono essere usati come selettori. Eccon un semplice esempio:

H1: Size: 20 pt;

Il selettore nell'esempio � H1 che seleziona tutti gli elementi H1 nel documento � imposta la dimensione del font a 20 punti. (Le parole chiave BEGIN e END usate nei precedenti esempi possono essere omesse, poich� vi � una sola dichiarazione associata con il selettore H1.)

I selettori basati sui nomi/valori di attributo vengono scritti nella sezione ATTRIBUTES del foglio di stile. Per esempio, per impostare la dimensione del font di tutti gli elementi con attributo warning si pu� scrivere:

ATTRIBUTES
  warning:
    Size: 25 pt;

Si possono scrivere anche query pi� complesse in P94, ma la logica viene posta nelle dichiarazioni piuttosto che nel selettore. Per esempio, per impostare i valori su tutti gli elementi LI all'interno di un elemento OL, si pu� scrivere:

LI: BEGIN
  if within OL Size: 10 pt;
END;

Propriet�

P94 ha due tipi di regole: quelle che contengono un paramentro di presentazione e quelle che contengono una funzione di presentazione. I parametri di presentazione sono simili alle propriet� CSS e sono discussi in questa sezione. Le funzioni di presentazione sono usate per creare riquadri di presentazione e sono discussi pi� avanti nella sezione sul Contenuto generato.

La Tabella 6 da uno sguardo d'insieme delle propriet� in P94.

Con poco pi� di 20 propriet�, l'insieme di propriet� di P94 � molto pi� esiguo rispetto a quelli di FOSI o DSSSL. Ma P94 � un linguaggio di stile altamente funzionale che, per diversi aspetti, offre pi� funzionalit� degli altri linguaggi. Ci sono diverse spiegazioni per questa apparente discrepanza. In primis, P94 spesso combina in una sola propriet� delle funzionalit� che gli altri separano in diverse propriet�. Per esempio, la propriet� Style in P94 descrive sia il peso del font che la sua postura. In secundis, il box model di P94, basato sulle restrizioni, � in grado di ridurre il numero delle propriet� esprimendo come valori relazioni geometriche abbastanza complesse. Da ultimo, alcune funzionalit� di propriet� intensiva offerte da altri linguaggi non sono disponibili in P94. Gli esempi includono i bordi degli elementi (oltre le semplici regole orizzontali e verticali), colori di sfondo e del testo, spaziatura tra lettere e parole.

Valori e unit�

I valori e le unit� in P94 si possono dividere in una parte tradizionale e in una parte nuova. La parte tradizionale comprende le parole chiave e le unit� di lunghezza che sono simili a quelle usate in altri linguaggi di stile. La parte nuova � costituita da valori che sono in grado di esprimere restrizioni tra gli elementi e da valori elastici.

Unit� di lunghezza

Le unit� di lunghezza (dette unit� di distanza in P94) possono essere assolute o relative. Le unit� assolute sono: centimetri (cm), pollici (in) e punti tipografici (pt, 1/72 di pollice).

P94 ha anche un unit� relativa simile all'unit� em in FOSI e nei CSS. Ci� viene espresso con un numero senza un identificatore di unit�:

H2: Width: 20;

L'esempio imposta la larghezza dell'elemento H2 a 20 volte l'altezza del font in uso.

Nella propriet� Size, che descrive la dimensione del font dell'elemento, un numero privo di unit� ha un altro significato. Size accetta un valore intero compreso tra 1 e 6 (incluso) che fa riferimento ad una tabella delle dimensioni dei font tenuta dall'applicazione.

H2: Size: 3;

P94 non ha il concetto di valori iniziali. L'applicazione � responsabile dell'impostazione di un valore iniziale qualora non esista un valore predefinito.

Restrizioni

Le restrizioni formano una parte importante dei valori in P94. La maggior parte dei linguaggi di stile sono in grado di esprimere alcune forme di restrizioni. Per esempio, una semplice restrizione pu� impostare la dimensione del font di un elemento del 50% pi� grande dell'elemento genitore.

Un altro tipo di restrizione supportata da P94 riguarda i valori massimi e minimi accettati dalla propriet� Size. Si consideri questo esempio:

LI: 
  Size : Enclosing - 2pt Min 7;
H1:
  Size : Enclosing + 2 Max 5;

La prima regola nell'esempio afferma che la dimensione del font degli elementi LI � di 2 punti minore di quella dell'elemento genitore, e che non pu� essere inferiore a 7 punti. La seconda regola afferma che la dimensione del font degli elementi H1 deve essere di due dimensioni pi� grande del testo circostante, ma non pi� grande di 5. In entrambi gli esempi, i valori che vengono dopo Min/Max assumono la stessa unit� del valore prima di Min/Max.

Valori elastici

P94 il concetto di autorizzare l'utente a scegliere le dimensioni per alcuni elementi. I valori di lunghezza possono essere influenzati dagli utenti e sono chiamati valori elastici. Le propriet� Width e Height accettano la parola chiave Userspecified in aggiunta ad un valore di lunghezza.

GraphElem: BEGIN
  Width: 2 cm Userspecified;
END

L'esempio dice che gli elementi GraphElem hanno una larghezza di 2cm come valore predefinito, ma gli utenti possono cambiare la larghezza.

I valori elastici possono essere considerati una forma di cascata; un solo foglio di stile da all'utente il controllo su taluni aspetti della formattazione. Tuttavia, i valori elastici sono usati in P94 solo in modo limitato. Il controllo dato dal foglio di stile all'utente � inteso come un'interazione con l'utente piuttosto che come un foglio di stile separato.

Trasmissione di valore

P94 offre tre meccanismi per evitare di impostare tutti i valori per tutte le propriet� e su tutti gli elementi. Primo: la sezione DEFAULT del foglio di stile contiene dichiarazioni usate come predefinite. Secondo: l'eredit� pu� trasferire i valori per le propriet� testuali dagli elementi vicini. Terzo: restrizioni geometriche possono essere stabilite tra riquadri e quindi si possono trasferire valori da un riquadro all'altro.

Si consideri questo esempio:

DEFAULT
  Depth: 0;
  Size: Enclosing =;

La sezione DEFAULT dell'esempio contiene due regole. La prima imposta il valore predefinito di Depth a zero. La seconda rende la dimensione predefinita di tutti gli elementi uguale alla dimensione dell'elemento genitore (Enclosing nella terminologia P94). Ossia: la regola dichiara che la propriet� Size � ereditata.

P94 si affida all'eredit� meno della maggior parte di altri linguaggi di stile. Nessun valore � ereditato automaticamente e l'eredit� pu� essere specificata solo per alcune propriet� (Justificy, LineSpacing, Font, Style, Size, Visibility, e Indent). I valori possono essere ereditati dall'elemento genitore (Enclosing) cos� come dall'elemento figlio (Enclosed) e da un precedente fratello (Previous).

L'eredit� in P94 segue la struttura logica degli elementi, perci� il contenuto generato non pu� trasmettere nessun valore per eredit�.

Ecco un esempio di come si eredita un valore da un elemento figlio:

RULES
  PRE: Width: Enclosed . Width;

Nell'esempio la larghezza dell'elemento PRE � impostata sulla larghezza del riquadro racchiuso in esso. Ossia, la larghezza dell'elemento PRE sar� determinata dal suo contenuto, secondo la cosiddetta formattazione inside-out. Mentre l'elemento PRE non ha figli nella struttura logica degli elementi, i contenuti dell'elemento PRE formano un riquadro a cui si pu� far riferimento.

Le restrizioni geometriche tra riquadri sono il terzo tipo di meccanismo di trasmissione di valore in P94. Questo meccanismo usa alcune delle stesse parole chiave (Enclosing, Enclosed, Previous) del meccanismo dei eredit� e, perci�, pu� confondere. Mentre l'eredit� funziona solo per le propriet� testuali, le restrizioni geometriche sono usate per posizionare i riquadri. Ancora: le restrizioni geometriche possono riferirsi agli elementi Next e Referred. In una descrizione del linguaggio P del 1993 [Grif 1993], il valore � scritto come Refered. Questo errore � simile alla scrittura di "Referer" nell'HTTP, con la sola eccezione che l'errore � rimasto nell'HTTP fino ad oggi [HTTP 1999].

Per un esempio di restrizione geometrica, si veda il Modello di formattazione visuale di seguito.

Modello di formattazione visuale

Il modello di formattazione di P94 si basa su una gerarchia di riquadri rettangolari. Ci sono tre tipi di riquadri:

• riquadri che corrispondono agli elementi nella struttura del documento;
• riquadri di presentazione che vengono generati;
• riquadri del layout di pagina.

I riquadri che corrispondono agli elementi nella struttura del documento formano una struttura ad albero identica alla struttura del documento. Questo albero esprime le relazioni di inclusione tra i riquadri: un riquadro include tutti i riquadri del suo sotto-albero.

I riquadri di presentazione rappresentano elementi che non si trovano nella struttura logica del documento ma che vengono aggiunti sulla base dell'esistenza di elementi logici. Ci� corrisponde all'incirca agli pseudo-elementi nei CSS. Per esempio, un riquadro di presentazione si pu� usare per aggiungere Capitolo prima di ogni elemento H1. Si veda la sezione sul Contenuto generato.

I riquadri del layout di pagina sono riquadri creati di solito dalle regole del layout di pagina. Queste regole indicano come i contenuti di un elemento strutturato debbano essere divisi in righe e pagine. Contrariamente ai riquadri di presentazione, questi riquadri di pagina e di riga non dipendono dalla struttura logica del documento ma, piuttosto, dalle restrizioni fisiche dei dispositivi di output: dimensione dei caratteri, altezza e larghezza della finestra sullo schermo o del foglio di carta.

Il modello di formattazione di P94 supporta caratteristiche di formattazione avanzate, come note a pi� di pagina, change marks, tabelle e matematica. Una caratteristica che manca � quella delle immagini flottanti con del testo intorno.

Meccanismo di collegamento

Nel linguaggio S, si pu� specificare un foglio di stile predefinito per ciascun tipo di documento. Quando l'utente crea un nuovo documento di quel tipo, l'editor usa il foglio di stile predefinito. L'utente pu� specificare un altro foglio di stile, e l'editor riformatter� il documento di conseguenza. Quando l'utente salva il documento, i fogli di stile correnti vengono memorizzati nel documento stesso.

Contenuto generato

P94 possiede una ricca funzionalit� per generare contenuto in aggiunta al contenuto nel documento. Per esempio, ecco il codice per aggiungere il testo Chapter x: prima di tutti gli elementi H1 (dove x � sostituito da un numero di capitolo incrementale):

COUNTERS
ChapterNumber: set 0 on BODY add 1 on H1;
BOXES
ChapNumBox: BEGIN
  Content: (text 'Chapter ' value(ChapterNumber, Arabic) text':');
  ...
END;
RULES
H1: BEGIN
  CreateBefore (ChapNumBox);
  ...
END;

Il riquadro da generare prima di ogni elemento H1 � descritto nella sezione BOXES del precedente esempio. La creazione del riquadro � inizializzata dalla funzione di presentazione CreateBefore.

Nell'esempio il numero di capitolo � aggiunto prima di ogni elemento H1. P94 offre un insieme di espressioni logiche per indicare che la funzione di presentazione deve essere richiamata solo in determinate condizioni. Si consideri questo esempio:

Column:
  BEGIN
  CreateBefore (VertRule);
  IF LAST CreateAfter(VertRule)
  Width: 2.8cm;
  Height: Enclosed.Height;
  VertPos: Top = Enclosing.Top;
  HorizPos: Left = Previous.Rightl
  END;

In questo esempio, la funzione di presentazione CreateBefore � richiamata per ogni elemento Column, ma la funzione CreateAfter � richiamata solo se l'elemento Column � l'ultimo in un insieme di fratelli. P94 offre circa 30 diverse condizioni da testare prima di richiamare una funzione di presentazione.

Altri contesti di formattazione

Vedute

Centrale in P94 � il concetto di vedute. Le vedute possono essere pensate come diversi fogli di stile in uno, ed un foglio di stile P94 pu� descrivere diverse vedute. Esempi di vedute comunemente usate sono la veduta di formattazione, la veduta del codice sorgente e la tabella dei contenuti. Per esempio, Amaya pu� mostrare al contempo differenti vedute (per esempio il documento formattato pu� essere mostrato in una finestra, e la tabella dei contentui in un'altra), e l'utente pu� editare tutte le vedute.

PRESENTATION HTML;

VIEWS
   Formatted_view,
   Table_of_contents;

COUNTERS
   H2Counter : Set 0 on BODY add 1 on H1;
   H2Counter : Set 0 on H1 add 1 on H2;

DEFAULT
        BEGIN
        Size: Enclosing =;
        Weight: Enclosing =;
        END;

H1:        BEGIN
        Size: Enclosing + 6 pt;
        Weight: Bold;
        IN Table_of_contents
                Size: Enclosing + 2 pt;
        END;

H2:        BEGIN
        Size: Enclosing + 4 pt;
        Weight: Bold;
        IN Table_of_contents
                Visibility: 0;
        END;
END

L'esempio di sopra aggiunge una seconda veduta. In aggiunta a Formatted_view ( che � la predefinita in quanto viene per prima), � stata aggiunta una veduta chiamata Table_of_contents. In questa veduta, la dimensione del font degli elementi H1 � di 2pt maggiore di quella del genitore ( in opposizione a quella di 6pt maggiore del genitore nella normale veduta), e gli elementi H2 non sono visibili. In Thot, le vedute all'interno di uno schema di presentazione sono sincronizzate quasi in tempo reale: quando si seleziona un elemento in una veduta, le altre vedute vengono automaticamente scrollate per mostrare lo stesso elemento.

È anche possibile scrivere diversi schemi di presentazione per lo stesso documento [Quint 1994]:

Si ricordi che � possibile scrivere diversi schemi di presentazione per la stessa classe di documenti o di oggetti. Ci� consente agli utenti di scegliere per un documento l'aspetto grafico che pi� si adatta al loro lavoro o al loro gusto personale.

Di solito uno schema definisce un corposo insieme di vedute che possono risultare utili per eseguire una particolare operazione. Per eseguire differenti tipi di operazioni (tracciare i contorni, scrivere, creare una buona presentazione per la messa a punto di un programma, rivedere un documento ecc.) si potrebbero scrivere differenti insiemi di vedute, ergo differenti schemi.

P94 nel contesto

P94 � stato un potente linguaggio di stile nel 1994. Combinato con i linguaggi 'S' e 'T', ha costituito un potente pacchetto per l'elaborazione dei documenti strutturati. Il linguaggio P offre un ricco insieme di funzionalit� stilistiche basato su semplici relazioni tra elementi. Fra tutti i linguaggi di stile descritti in questo capitolo, � quello che pi� si avvicina ad esprimere il layout in termini di restrizioni tra elementi.

P94 fu sviluppato per una sola applicazione (Thot) e non fu mai standardizzato come linguaggio di stile per l'uso da parte di altre applicazioni. Credo che P94 sarebbe stato un buon linguaggio di stile per SGML verso il 1990 e che si sarebbe rivelato adatto all'uso sul Web. Il linguaggio � semplice abbastanza per essere compreso dagli autori, ma al contempo sufficientemente potente per esprimere una tipografia avanzata. La sintassi, che pu� essere non intuitiva, pu� essersi rivelata come un argomento contro l'uso di P94. Tuttavia, il motivo principale per cui P94 non entr� mai in competizione con altri linguaggi di stile � che i suoi creatori non ne proposero mai l'uso al di fuori di Thot.

Il linguaggio P si � evoluto a partire dal 1994. P ha ora propriet� per descrivere i bordi intorno agli elementi, i colori del testo e dello sfondo, la bidirezionalit�, la tratteggiatura e altro ancora. Queste propriet� sono state aggiunte per supportare specifiche W3C come i CSS e SVG. P continua a svolgere egregiamente il suo compito di essere un banco di prova per nuove specifiche.

Sommario e conclusioni

Tutti i linguaggi di stile condividono un insieme di componenti comuni. Propongo i seguenti sei componenti come requisiti di un linguaggio di stile: sintassi, selettori, propriet�, valori e unit�, meccanismo di trasmissione di valore e modello di formattazione. La maggior parte dei modelli di formattazione sono visuali, ma quelli acustici e tattili sono a loro volta possibili. Inoltre molti linguaggi di stile supportano il contenuto generato e un meccanismo di collegamento.

I fogli di stile esistevano prima del Web, e questo capitolo ha esaminato tre sistemi fondamentali: FOSI, DSSSL e P94. Scopo principale di questi linguaggi era la stampa di documenti strutturati. Tutti questi sistemi soddisfano i criteri stabiliti all'inizio del capitolo.

Il prossimo capitolo discute i linguaggi di stile per il Web, valutando nove diverse proposte secondo i criteri usati nel presente capitolo.

Proposte di fogli di stile per il Web

Il precedente capitolo ha descritto i linguaggi di stile sviluppati e usati prima del Web. Questo capitolo tratter� i linguaggi di stile proposti specificamente per il Web. Ogni proposta verr� valutata secondo i criteri stabiliti nel precedente capitolo.

Il Web venne lanciato senza un linguaggio di stile in uso. La libreria libwww del CERN [Nielsen&Lie 1994], che costitu� la base per molti dei primi browser, aveva un concetto di fogli di stile, ma questi erano inseriti nell'applicazione e non potevano essere modificati dagli autori o dagli utenti. Per concentire agli autori e agli utenti di influenzare la presentazione dei documenti, � necessario un linguaggio di stile. Tuttavia, nel 1993 non vi erano candidati al ruolo di linguaggio di stile per il Web. Come abbiamo visto nel precedente capitolo, DSSSL era ancora in fase di sviluppo, FOSI aveva un uso limitato e P94 non fu proposto per l'uso sul Web. A differenza dei documenti strutturati, dove SGML era stato la base naturale per lo sviluppo dell'HTML qualche anno prima, nessun linguaggio di stile aveva raggiunto uno status simile.

La prima proposta di un linguaggio di stile per il Web apparve nel 1993 e da allora l'argomento dei fogli di stile divenne un motivo di discussione ricorrente sulla mailing list www-talk. Nel periodo 1993-1995, otto diversi linguaggi di stile furono proposti sui forum, soprattutto sulla mailing list www-talk [www-talk]. Nel 1996 un linguaggio venne proposto in una pubblicazione accademica [Munson 1996]. Le nove proposte sono analizzate in ordine cronologico in questo capitolo. Le analisi si basano sulle proposte stesse, discussioni su www-talk e altre mailing list e comunicazioni personali con gli autori. Alcune delle proposte sono state implementate, ma io non ho avuto disponibili tali implementazioni mentre scrivevo le analisi.

Nell'agosto del 1997, il W3C ricevette Una proposta per XSL da diversi suoi membri [NOTE-XSL 1997]. Come risultato si ebbe la formazione di un gruppo di lavoro su XSL e XSL divenne una Raccomandazione W3C nel 2001 [XSL 2001]. Nel Capitolo 2, XSL � stato brevemente discusso nel contesto dello stile contro la trasformazione. Tuttavia XSL non sar� analizzato ulteriormente in questo capitolo poich� va oltre l'intervallo di tempo delle altre proposte.

Proposta di Robert Raisch (RRP)

Questa proposta [Raisch 1993a] fu pubblicata nel giugno 1993 da Robert Raisch della O'Reilly & Associates Inc. Fu la prima proposta di linguaggio di stile concepito per il Web. Parte dell'introduzione fu usata per sostenere il perch� il Web avesse bisogno di un linguaggio di stile:

Vi � il bisogno, all'interno del WWW, di poter essere in grado di specificare la resa di peculiari informazioni insieme col contenuto racchiuso tra i tag di un documento WWW. Non � appropriato usare l'HTML per questo scopo, poich� uno dei primi principi dell'HTML � quello di codificare oggetti all'interno di un documento, non come essi debbano essere resi in un particolare ambiente.

RRP venne inclusa in toto nel messaggio inviato alla mailing list www-style. Il messaggio di testo � di circa 700 righe e include – oltre alla descrizione delle propriet� e dei valori – un foglio di stile d'esempio per l'HTML e pseudo-codice per un'implementazione di RRP.

Sintassi

La sintassi di RRP � sviluppata specificamente per la proposta. Essa � compatta (per ridurre il tempo richiesto per caricare e interpretare i fogli di stile), ma non facile da leggere a prima vista per gli esseri umani. Ecco un frammento del Foglio di stile d'esempio fornito nell'appendice di RRP:

@BODY fo(fa=he,si=18)

Nell'esempio, due propriet� nella categoria font ( fo) sono impostate sull'elemento BODY. La famiglia di font (fa) � impostata su helvetica (he) e la dimensione del font (si) su 18 punti.

L'esempio � tipico di RRP e tutte le asserzioni seguono la medesima struttura: un selettore � seguito da una o pi� coppie di propriet�/valore. Tutte le categorie, propriet� e parole chiave sono rappresentate da codici di due lettere.

Selettori

RRP ha un semplice meccanismo di selezione che seleziona gli elementi in base al loro nome. Gli elementi non possono essere selezionati in base ad altri criteri, come il loro contesto o i loro attributi. I selettori hanno la forma:

@<element-name>

Oltre ai nomi di elemento, vi � un selettore che imposta i valori predefiniti:

@DEFAULT fo(fa=ti,sp=pr,si=14,we=me,sl=ro,fo=in,bo=in,li=no,nu=1,fn='')

I possibili conflitti di namespace tra DEFAULT e un futuro elemento HTML con quel nome non vengono affrontati. Tutti i selettori sono scritti in maiuscolo negli esempi dati in RRP, ma l'essere sensibile alle maiuscole e alle minuscole non viene definito in RRP. Come tale, RRP � immaturo, ma non pi� delle prime versioni delle altre proposte di fogli di stile.

Propriet�

RRP definisce 35 propriet� raggruppate in otto categorie di propriet�. Le propriet� coprono un'ampia gamma di funzionalit�: descrivono sia i dati primitivi fondamentali di formattazione (come il font e i colori di un elemento) e supportano anche alcune caratteristiche avanzate. La Tabella 7 mostra le categorie, le loro propriet� associate e il titolo descrittivo delle categorie.

Diversi nomi di propriet� (per esempio before, after) sono usati in differenti categorie (per esempio vert, link, mark) e hanno un significato differente in ciascuna categoria. Il raggruppamento delle propriet� � quindi necessario per evitare ambiguit�. Si consideri questo esempio:

@LI ve(af=10) ma(af=5) li(af=st)

Tre propriet�, tutte chiamate after sono state impostate nel precedente esempio. La prima regola imposta lo spazio verticale dopo un elemento LI a 10 unit� (si veda di seguito la discussione sulle unit�). La seconda regola imposta la distanza tra un marcatore (ossia il marcatore della voce di elenco) e il testo dell'elemento. La terza regola descrive i collegamenti che compaiono all'interno degli elementi LI; la regola dichiara che i link devono avere una stella (*) dopo di essi. RRP elenca molti possibili marcatori (tra cui la stella). Tuttavia, la proposta non specifica la parola chiave per riferirsi ai marcatori, e il valore st nell'esempio � di conseguenza una congettura.

Il concetto di raggruppare le propriet� in categorie di RRP � simile al raggruppamento in FOSI. La Tabella 8 elenca tutte le categorie RRP insieme con le categorie FOSI similari, e la Tabella 9 compara la categoria font di RRP e FOSI.

Ci sono diversi indizi che mostrano che RRP � influenzato da FOSI. Il raggruppamento delle propriet� in categoria � simile ed anche l'uso degli stessi nomi. Ancora: molti dei nomi usati per le propriet� e i valori sono spesso identici.

Valori e unit�

RRP ha quattro differenti tipi di valori:

• parole chiave di due lettere
• stringhe
• colori espressi come cifre esadecimali
• interi (chiamati UNITS)

Ecco un esempio dell'uso dei quattro tipi di valori:

@P fo(fa=ti fo='black' ba=0xffffff) co(nu=2,wi=10)

Come prima cosa, tre valori sono impostati nella categoria font. La famiglia di font � impostata su times (che � uno dei quattro differenti valori per la famiglia di font), il colore del testo � impostato su black (che � uno dei diversi nomi di colore citati nella proposta), e il colore di sfondo sul bianco (espresso in numeri esadecimali). Quindi il numero di colonne � impostato su 2, e la larghezza della colonna � impostata su 10.

L'interpretazione del valore intero dipende dalla propriet� in questione, cos� come il tipo di oggetto che il valore descrive. Per esempio, nella descrizione della propriet� per la larghezza della colonna, si afferma:

Nel caso di un oggetto di testo, UNITS potrebbe rappresentare i caratteri, mentre nel contesto di un oggetto grafico, UNITS potrebbe rappresentare elementi dell'immagine (pixel.)

La motivazione di usare un valore intero e passare tra differenti modi di interpretare il valore sta nella semplificazione della sintassi. Per alcune propriet� questa pu� essere una soluzione accettabile, ma per altre propriet�, dove il numero di unit� differenti (per usare la terminologia CSS) � alto, tale soluzione � insufficiente. Per esempio, in RRP la dimensione dei font pu� essere espressa solo in punti tipografici, mentre altri linguaggi offrono un certo numero di differenti unit�.

Trasmissione di valore

RRP fornisce tre meccanismi per la trasmissione di valore. Primo: i fogli di stile possono specificare regole predefinite per le combinazioni elemento/propriet� non specificate esplicitamente. Il foglio di stile di esempio contiene questo frammento per impostare i valori predefiniti:

@DEFAULT fo(fa=ti,sp=pr,si=14,we=me,sl=ro,fo=in,bo=in,li=no,nu=1,fn='')
  ju(st=le,hy=0,ke=0) co(nu=1,wi=80) br(lo=af,ob=it)
  ma(ob=it,pr=no,be=0,re=no,su=no,af=0)
  ve(be=0,af=0,sp=0,of=0) in(le=0,ri=0,fi=0)
  li(lo=in,ma=no,li=un,nu=1,be=no,af=no,hi=0)

Secondo: ogni propriet� ha un valore iniziale definito nelle specifiche. La maggior parte dei valori impostati nel precedente esempio sono ridondanti, poich� i valori sono impostati sui valori iniziali.

Terzo: l'eredit� pu� essere specificata su due propriet�: foreground e background. Si consideri questo estratto dal precedente esempio (con una minima correzione: bo � stato cambiato in ba):

@DEFAULT fo(fo=in,ba=in)

In questo esempio, i colori del testo e dello sfondo sono impostati su inherit. In effetti, questo trasforma le propriet� foreground e background in propriet� ereditate. Sorprendentemente, il valore inherit (in) non � consentito in propriet� diverse da foreground e background.

Il concetto di eredit� (propriet� non-ereditate, con un valore inherit esplicito) � simile al modello di eredit� di FOSI.

Modello di formattazione visuale

RRP abbozza un semplice modello di formattazione visuale. La proposta non � abbastanza completa per avere una piena comprensione del suo funzionamento e non vi sono abbastanza informazioni per classificare RRP in un modello a box o in un modello a sequenza.

Diverse propriet� di interruzione possono essere settate per descrivere la ricorrenza delle interruzioni di riga. In questo modo, gli elementi appariranno in riga o a blocco e si potr� impostare la quantit� di spazio prima e dopo l'elemento.

Una caratteristica avanzata offerta da RRP sono i layout multicolonna. Le propriet� column number e column width possono essere usate, ad esempio, per descrivere una pagina a due colonne:

@BODY co(nu=2,wi=40)

Tuttavia non vi � modo di impostare lo spazio tra le colonne. La proposta, perci�, non � in grado di descrivere casi comuni di layout a pi� colonne.

Meccanismo di collegamento

RRP suggerisce di usare l'elemento LINK per puntare a fogli di stile esterni, offrendo cos� agli autori la possibilit� di collegare i loro documenti a fogli di stile di loro gradimento. Ecco la sintassi proposta:

<LINK STYLE={URL}>

I fogli di stile utente non facevano parte della proposta e non vi � una discussione sulle preferenze degli autori contro le preferenze del lettore. Tuttavia, la proposta limita i fogli di stile al ruolo di consigli o suggerimenti che potrebbero essere usati [Raisch 1993a]:

Piuttosto, questo � un insieme di CONSIGLI o SUGGERIMENTI per il programma che render� il documento, un insieme che potrebbe essere usato per visualizzare oggetti HTML particolari nel modo concepito in origine dall'autore del documento.

Questa politica lascia spazio al rispetto delle preferenze dell'utente in combinazione con i fogli di stile dell'autore.

Contenuto generato

Non proposto.

Altri contesti di formattazione

Non proposti.

RRP nel contesto

RRP fu la prima proposta di un linguaggio di stile specifico per il Web. Come tale, la proposta � pionieristica e merita credito per la sua data di pubblicazione. Dopo la sua pubblicazione nel giugno 1993, la proposta venne brevemente discussa sulla mailing list www-talk. Tuttavia, essa non venne ulteriormente sviluppata e la personale implementazione dell'autore non fu mai pubblicata.

RRP � ambiziosa sotto diversi aspetti. Vengono descritti argomenti avanzati quali i contatori e i layout a pi� colonne. Tuttavia, le descrizioni sono abbastanza dettagliate per produrre delle consistenti implementazioni. Inoltre RRP � semplicistica nel suo approccio allo stile dei documenti web. Il problema pi� grande � probabilmente la mancanza di unit� per i valori numerici. Come prima bozza, tuttavia, la proposta merita considerazione.

Sembra chiaro che RRP fu influenzata da FOSI. Il raggruppamento delle propriet�, i nomi di propriet�, e il concetto simile di eredit� indicano che l'autore conosceva FOSI. Tuttavia nella proposta non si fa riferimento a FOSI.

RRP apparve nel periodo in cui il team di sviluppo del browser Mosaic era molto attivo. Se fosse stato assunto da Mosaic nella sua fase iniziale, � probabile che gli elementi HTML orientati alla presentazione (come gli elementi FONT e CENTER) non sarebbero apparsi. Invece, sarebbero stati aggiunti molte pi� propriet� e valori al linguaggio di stile RRP. In tal senso � un peccato che RRP non fu implementato dai browser di quel periodo.

Proposta di Pei Wei (PWP)

Nell'ottobre del 1993, quattro mesi dopo la pubblicazione della proposta di Robert Raisch, Pei Wei pubblic� una breve proposta per un linguaggio di stile su www-talk [Wei 1993a]. Come architetto e programmatore del browser ViolaWWW Pei Wei era in una posizione favorevole per implementare un linguaggio di stile. Il browser ViolaWWW fu lanciato nel 1992 [Wei 1992] e fu tra i primi browser grafici.

Come Robert Raisch, Pei Wei lavorava per O'Reilly ed era naturale per la comunit� di www-talk chiedere della relazione tra le due proposte [Andreessen 1993b]:

From: Marc Andreessen ([email protected])
Date: Fri, 22 Oct 93 23:48:42 -0700

Qual'� la relazione tra questa
e la proposta di Rob Raisch di quest'estate? (Rob, ci sei? :-)

Saluti,
Marc

Il messaggio dimostra che gli sviluppatori di Mosaic stavano seguendo lo sviluppo dei fogli di stile. La risposta di Robert Raisch a Marc Andreessen [Raisch 1993b] fu che aveva lasciato O'Reilly e che ulteriori domande dovevano essere indirizzate a loro. Pei Wei invi� questa risposta [Wei 1993b]:

B�, dopo che Rob ha lasciato O'Reilly, io ho di fatto ereditato
il problema dei fogli di stile, ossia finire lo sviluppo, 
il prototipo e l'implementazione finale.
Poich� Rob ha fatto il bel lavoro di scrivere la proposta iniziale,
cercher� di riutilizzare quanto pi� materiale possibile.
Ma c'erano e ci saranno cambiamenti dalla presentazione di Rob di quest'estate.

Come testimonia la Figura 3, i fogli di stile vennero implementati in ViolaWWW.

Il documento [Wei 1993d] mostrato nella Figura 3 illustra come funzionava PWP. Insieme con i fogli di stile che descrivevano la sua presentazione, tale documento fa parte della proposta PWP per rendere quest'ultima pi� completa. Ci si riferisce ad esso come al documento di esempio.

Sintassi

PWP comprende un foglio di stile d'esempio abbastanza breve da essere riprodotto in toto:

(HEAD,BODY              fontSize=normal
                    BGColor=white
                    FGColor=black
    (H1                 fontSize=largest
                    BGColor=red
                    FGColor=white)
    (H2                 fontSize=large)
    (P)
    (A                  FGColor=red)
    (CMD,KBD,SCREEN,LISTING,EXAMPLE fontFamily=fixed)
    (BOLD,EMPH,STRONG           fontWeight=bold)
    (I                  fontSlant=italic)
    (ADDRESS
        (P              fontSlant=italic))
    (OL
    (LI             numStyle=roman
        (LI                 numStyle=number
        (LI         numStyle=alpha)
        )
    )
    )
    (FOOTNOTE               fontSize=small
    (P)
    )
)

La caratteristica pi� notevole della sintassi � l'uso delle parentesi. La sintassi di PWP �, come DSSSL, basata su Lisp con le sue parentesi multi-livello. A differenza di DSSSL, tuttavia, le parentesi in PWP non esprimono funzioni, quanto piuttosto selettori contestuali nella struttura del documento. Sebbene avere selettori contestuali sia una potente caratteristica, la lettura umana dei fogli di stile inevitabilmente ne risente quando si introducono parentesi multi-livello nella sintassi. Anche la scrittura dei fogli di stile ne risente, poich� le parentesi devono essere equilibrate per scrivere validi fogli di stile.

Pei Wei probabilmente si aspettava una certa resistenza alla sintassi proposta, e quando chiese feedback la sintassi venne esplicitamente menzionata:

In particolare, ci sono problemi con la sintassi del linguaggio di stile?

Il problema della sintassi fu uno dei motivi per cui Steve Heaney scrisse una proposta alternativa ( discussa di seguito), ma non ci furono ulteriori commenti sulla sintassi su www-talk.

Poich� un foglio di stile PWP evidenzia la struttura di un documento, pu� quindi essere usato anche per ordinarne la struttura. Per esempio, oltre a descrivere lo stile degli elementi H1 all'interno dell'elemento BODY, il precedente frammento di foglio di stile pu� anche affermare che gli elementi H1 devono apparire solo all'interno dell'elemento BODY. In SGML, le DTD vengono usate per esprimere restrizioni strutturali, ma PWP si avvicina all'essere in grado di sostituire le DTD. Questo pu� essere ci� che l'autore intende quando afferma: I semplici "(P)" appaiono l� per far si che i rispettivi tag <P> si trovino in quei particolari contesti. [Wei 1993a]

Selettori

Come discusso in precedenza, i selettori sono intrinsecamente inseriti nella sintassi PWP. Usando parentesi multi-livello, si possono facilmente esprimere selettori contestuali. Nel foglio di stile d'esempio gi� visto, alle voci di elenco vengono dati stili numerici a seconda del loro livello nella struttura: il primo livello � numerato nello stile roman, il secondo nello stile number, e il terzo nello stile alpha.

Sebbene non esplicitamente descritto in PWP, � chiaro che i selettori contestuali esprimono relazioni di progenitura, non relazioni genitore-figlio. Si consideri questo frammento:

(BODY
    (BOLD,EMPH,STRONG           fontWeight=bold))

Data la struttura dell'HTML, � chiaro che BODY � un antenato di BOLD, EMPH, e STRONG piuttosto che un genitore (anche se BOLD e EMPH non sono elementi HTML).

Come visto in precedenza, i selettori possono essere elenchi di nomi di elemento separati da virgola. Non ci sono possibilit� di selezionare gli elementi in base a criteri diversi dal nome e dal contesto.

Propriet�

Una significativa differenza tra RRP e PWP � la nomenclatura e il raggruppamento delle propriet�. PWP usa nomi di propriet� pi� lunghi e pi� leggibili, e le propriet� non sono raggruppate. Questo rende i fogli di stile pi� leggibili.

La proposta iniziale non contiene un elenco di propriet� ma le seguenti propriet� vengono usate nel foglio di stile di esempio: fontSize, fontWeight, fontSlant, fontFamily, numStyle, BGColor, FGColor.

Il numero di propriet� supportate da Viola sembra essere aumentato col tempo. Nei fogli di stile che descrivono il documento di esempio (Figura 3), vengo usate queste propriet� aggiuntive: fontSpacing, align, border, BDColor, blink, blinkColorOn, blinkColorOff.

L'insieme delle propriet� elencate � sufficiente per un'implementazione come proof-of-concept per il browser ViolaWWW, ma non � adattabile per un linguaggio di stile di ampio uso sul Web. Per esempio, non ci sono propriet� per descrivere i margini e l'indentazione, ma viene tuttavia descritto il comportamento lampeggiante in tre propriet�.

Valori e unit�

I fogli di stile PWP usano solo due tipi di valori: parole chiave e interi.

Le parole chiave sono di gran lunga le pi� comuni e il foglio di stile d'esempio [Wei 1993a] usa solo valori a parole chiave. Per esempio, i valori a parole chiave rappresentano le dimensioni del font (small, normal, large, largest), nomi di colore (red, maroon, grey70), e tipi di numero di elenco (roman, number, alpha). In generale, i valori a parole chiave sono comprensibili intuitivamente. L'elenco di nomi di colore � preso da X11 [X11].

I valori interi sono usati su due propriet�: border e blink. Si consideri questo estratto da [Wei 1993d]:

(BODY,HPANE,INPUT,P
  (SECTION              border=1)
  (P                    blink=1000))

La proposta non descrive appieno come interpretare questi valori. Il valore di border pu� rappresentare la larghezza del bordo in pixel, mentre il valore di blink pu� rappresentare l'intervallo di lampeggiamento in millisecondi.

Come per le propriet�, l'insieme dei valori disponibili richiederebbe un ulteriore sviluppo.

Trasmissione di valore

PWP usa l'eredit� per trasmettere i valori dagli elementi genitori ai figli. Da [Wei 1993a]:

Si noti che le propriet� sono ereditate seguendo l'albero del documento dall'alto in basso, a meno che non vengano sovrascritte. [..] Avere questo comportamento ereditario aiuta a mantenere breve la descrizione, poich� molte delle informazioni possono essere derivate dal contesto nella struttura ad albero.

Inoltre ogni propriet� ha un valore iniziale nell'implementazione di ViolaWWW, ma questo non � descritto nella proposta.

Modello di formattazione visuale

La descrizione del modello di formattazione visuale in PWP non � sufficientemente completa per essere analizzata in toto. Tuttavia, alcune informazioni possono essere ottenute analizzando la resa del documento di esempio nella Figura 3. ViolaWWW usa un modello basato su box (gli elementi P all'interno dell'elemento SECTION sono racchiusi dal bordo unito all'elemento SECTION). PWP � anche in grado di allineare il testo all'interno di elementi di blocco sul lato destro o sinistro. Non � chiaro cosa renda gli elementi di blocco pi� stretti del loro blocco contenitore (per esempio il box blu con l'elemento ADDRESS al suo interno). PWP non descrive come classificare gli elementi (se in riga o a livello di blocco).

Meccanismo di collegamento

PWP usa l'elemento LINK dell'HTML per puntare a fogli di stile esterni. La proposta � indecisa su dove gli elementi LINK dovrebbero essere consentiti:

Un documento usa un <LINK REL="STYLE" HREF="URL_to_a_stylesheet"> per associarsi ad un foglio di stile. Resta aperta la domanda se consentire o meno fogli di stile multipli in un documento, e dove questo collegamento possa essere specificato (solo una volta, in <HEAD>?).

ViolaWWW consentiva agli elementi LINK di apparire all'interno del corpo del documento. Ecco un (in qualche modo abbreviato) frammento tratto dal documento d'esempio:

<HTML>
<HEAD>
<LINK REL="style" HREF="../../viola/sgml/styles/HTML_sodium.stg">
</HEAD>
<BODY>
<H1>Simple stylesheets test</H1>
<LINK REL="style" HREF="../../viola/sgml/styles/HTML_address1.stg">
<P>Second stylesheet in effect starting from here. The text inside
the address paragraphs should be blinking.
<ADDRESS>
<P>[email protected]
<P>Digital Media Group, O'Reilly & Associates
</ADDRESS>
</BODY>
</HTML>

Lo scopo di avere elementi LINK inframezzati nel contenuto � quello di applicare stili specifici a particolari parti del documento. Gli stessi risultati possono essere raggiunti in un modo pi� chiaro (ma forse meno conveniente) ristrutturando il documento (per esempio usando elementi DIV) e applicando i fogli di stile agli elementi risultanti.

Quando i collegamenti ai fogli di stile furono in seguito aggiunti all'HTML, furono ristretti all'elemento HEAD.

Contenuto generato

Non proposto.

Altri contesti di formattazione

Non proposti.

PWP nel contesto

ViolaWWW fu il primo browser a supportare i fogli di stile collegati ai documenti. Questo fu quasi un successo, specie se si considera il fatto che una singola persona realizzava il design e la programmazione. I linguaggi di stile successivi usarono i concetti anticipati da PWP, incluso l'uso dell'elemento LINK per puntare a fogli di stile sul Web. Come era lecito aspettarsi da un'applicazione sperimentale, non tutti gli aspetti dei fogli di stile di PWP ebbero successo e la proposta era abbastanza immatura quando venne pubblicata nel 1993.

Se ci si basa sullo scambio di email tra Pei Wei e Marc Andreessen citato prima, si potrebbe concludere che PWP fu un evoluzione di RRP. Tuttavia, questo non sembra essere il caso. Le due proposte differiscono molto. In particolare la sintassi, il meccanismo dei selettori, la trasmissione di valore e i nomi dei valori/propriet� di ciascuno sono fondamentalmente diversi.

ViolaWWW non raggiunse mai il largo uso ottenuto da Mosaic, ma fu un'applicazione influente che ispir� altri sviluppatori. Se i fogli di stile fossero stati supportati da ViolaWWW quando questi fu rilasciato nel 1992, Mosaic e altri browser emergenti avrebbero potuto accettare il concetto di fogli di stile in una fase precedente.

Proposta di Steve Heaney (SHP)

Quattro giorni dopo che Pei Wei pubblic� PWP, Steve Heaney post� un messaggio su www-talk [Heaney 1993] dove sosteneva che si sarebbe dovuto riutilizzare FOSI piuttosto che re-inventare la ruota. La proposta di Steve Heaney (SHP) consiste di un foglio di stile che esprime quasi le stesse regole stilistiche del foglio di stile di PWP, ma espresse in FOSI. Inoltre, SHP discute i benefici e gli svantaggi di usare un sottoinsieme di FOSI. Si tratta di un abbozzo piuttosto che di una proposta completa, e la seguente valutazione � perci� limitata.

Sintassi

Il foglio di stile di esempio di SHP � abbastanza breve da essere riprodotto in toto:

<outspec>
  <docdesc>
    <charlist>
      <font size="12pt" bckcol="white" fontcol="black">
    </charlist>
  </docdesc>
  <e-i-c gi="h1"><font size="24pt" bckcol="red", fontcol="white"></e-i-c>
  <e-i-c gi="h2"><font size="20pt" bckcol="red", fgcol="white"></e-i-c>
  <e-i-c gi="a"><font fgcol="red"></e-i-c>
  <e-i-c gi="cmd kbd screen listing example"><font style="monoser"></e-i-c>
  <e-i-c gi="bold emph strong"><font weight="bold"></e-i-c>
  <e-i-c gi="i"><font posture="italic"></e-i-c>
  <e-i-c gi="p" context="address"><font posture="italic"></e-i-c>
  <e-i-c gi="li" context="ol"><counter style="romanlc"></e-i-c>
  <e-i-c gi="li" context="ol li ol"><counter style="alphalc"></e-i-c>
  <e-i-c gi="footnote"><font size="10pt"></e-i-c>
</outspec>

La proposta includeva solo una breve spiegazione della sintassi:

(Il tag e-i-c � un elemento in contesto - spero che il resto sia ragionevolmente autoesplicativo).

La maggior parte dei partecipanti alla mailing list www-talk, tuttavia, non erano familiari con FOSI, cosicch� il resto del foglio di stile non era autoesplicativo. Per esempio, non � intuitivamente chiaro quale sia il ruolo degli elementi docdesc e charlist. SHP cita FOSI due volte, ma FOSI non viene spiegato e non ci sono riferimenti bibliografici alle specifiche FOSI.

SHP elenca anche i vantaggi e gli svantaggi di usare una sintassi standard basata su SGML. Secondo SHP, i vantaggi includono la validazione, l'uso di strumenti esistenti, e la capacit� di potersi espandere nella piena funzionalit� FOSI. Gli svantaggi principali sono che il linguaggio � meno facile da leggere e meno facile da scrivere senza assistenza.

Selettori

I selettori in SHP si basano sul nome e sul contesto degli elementi. In FOSI ci� viene espresso rispettivamente negli attributi gi e context. FOSI pu� anche esprimere selettori pi� avanzati, (per esempio basati sugli attributi) ma questi non sono inclusi in SHP.

Propriet�

SHP � una diretta risposta a PWP. Il foglio di stile del primo usa solo propriet� che sono simili a quelle in PWP. Inoltre SHP elenca alcuni degli attributi inclusi nella DTD di FOSI: presp, postsp, indent, boxing, textbrk, quadding. Come tale, SHP � soprattutto un argomento per il riutilizzo di un sottoinsieme di FOSI piuttosto che una proposta per una funzionalit� richiesta dal Web.

Valori e unit�

Il foglio di stile d'esempio di SHP usa un sottoinsieme di valori definiti in FOSI. La maggior parte dei valori usati nei fogli di stile d'esempio di PWP sono parole chiave per le quali esiste un equivalente in FOSI. Per esempio, roman in PWP diventa romanlc in SHP. Alcune delle parole chiave non possono essere tradotte; le parole chiave per le dimensioni dei font in PWP ("small", "normal", "large", "largest") sono state tradotte in valori di lunghezza ("10pt", "12pt", "20pt", "24pt") in SHP.

Aggiungere parole chiave per rappresentare le dimensioni dei font in SHP sarebbe semplice, ma cos� facendo SHP non sarebbe pi� un sottoinsieme di FOSI.

Trasmissione di valore

Non discussa.

Modello di formattazione visuale

Non discusso.

Meccanismo di collegamento

Non discusso.

Contenuto generato

Non discusso.

Altri contesti di formattazione

Non discussi.

SHP nel contesto

La risposta a SHP fu varia. Un partecipante appoggi� fortemente l'uso di SGML come base sintattica [Burnard 1993]:

Vorrei davvero appoggiare il concetto di usare SGML come notazione per qualunque tipo di meccanismo di stile tu voglia eventualmente decidere di sviluppare. Non mi importa molto se � un sottoinsieme di FOSI, o se � simile a DSSSL, o se � una DTD fatta in casa, ma se usa almeno il formalismo di SGML...

La risposta di Pei Wei [Wei 1993c] fu pi� contenuta:

L'idea era quella di creare un tipo di rapidi suggerimenti di stile sul modello di ASAP, piuttosto che qualcosa di cos� vasto come FOSI. Ma credo che questo possa essere un reale sottoinsieme di FOSI. Personalmente preferisco ancora la semplice sintassi tipo LISP, ma capisco le tue ragioni... Se portiamo avanti FOSI, qualcuno dovrebbe editare la DTD di FOSI. Cos� com'� non possiamo usarla.

Se qualcuno avesse raccolto la sfida di definire un sottoinsieme di FOSI e di scrivere delle specifiche leggibili, FOSI sarebbe potuta essere la base per un linguaggio di stile per il Web. Sfortunatamente, nessuno lo fece.

Fogli di stile a cascata per l'HTML (CHSS)

Nell'ottobre del 1994 pubblicai una proposta per i Fogli di stile a cascata per l'HTML [Lie 1994]. Nel corso di diversi anni i CHSS si svilupparono nei CSS, ma la proposta iniziale (detta CHSS) ha un interesse storico ed � discussa in questa sezione. Dal canto suo i CHSS non sono una proposta completa. Piuttosto, fanno riferimento ad altre proposte per una descrizione di propriet� e valori (per esempio fanno riferimento a RRP) e descrivono nuove caratteristiche reputate necessarie in un linguaggio di stile per il Web. Fra di esse vi sono l'influenza condivisa tra autore/utente, il supporto per tipi di media visuali e non, e le variabili d'ambiente.

Sintassi

Nella sua forma pi� semplice, la sintassi dei CHSS � una variazione delle Risorse X11 [X11]. Ecco un semplice esempio:

font.family = times
h1.font.family = helvetica

La prima riga nell'esempio imposta la famiglia di font di tutti gli elementi su times. La seconda riga � un'asserzione pi� specifica che si applica solo agli elementi H1; gli elementi H1 dovrebbero usare invece la famiglia di font helvetica. Poich� la seconda asserzione � pi� specifica della prima, sovrascriver� l'impostazione per tutti gli elementi H1.

La sintassi CHSS non distingue tra propriet� ed elementi; senza conoscere in anticipo le propriet� e gli elementi, un parser non sar� in grado di operare una distinzione tra di essi. Il lavoro del parser � ulteriormente complicato quando vengono aggiunti tipi di media opzionali alla sintassi:

speech.em.weight = 40db

Nell'esempio speech � il tipo di media, em � l'elemento, e weight la propriet�.

CHSS supporta un influenza condivisa tra autori e utenti. Ciascuna delle due parti pu� indicare la propria influenza come percentuale sull'influenza totale. Ecco un esempio:

h2.font.size = 20pt 40%

La regola dell'esempio richiede il 40% dell'influenza sulla dimensione del font degli elementi H2. I fogli di stile utenti hanno la priorit� quando viene assegnata l'influenza, e i fogli di stile dell'autore vengono per secondi. La proposta prevede che l'utente [..] pu� richiedere il controllo totale della presentazione, ma – pi� probabilmente – gestisce la maggior parte dell'influenza [dell'autore] .

La sintassi di CHSS include anche espressioni logiche che riguardano variabili d'ambiente per determinare quando e se una regola deve essere applicata. Le variabili d'ambiente sono parametri dell'ambiente dell'utente, ossia non del documento stesso. La sintassi di queste espressioni � derivata dal linguaggio di programmazione C [Kernighan&Richie 1978]. Ecco un esempio:

AGE > 3d ? background.color = pale_yellow : background.color = white

L'espressione potrebbe essere cos� riscritta: se il documento � pi� vecchio di tre giorni, il colore di sfondo dovr� essere giallo pallido, altrimenti dovr� essere bianco.

Cos� la semplice sintassi derivata dalle Risorse X11 � stata estesa in diversi modi per adattarsi al concetto CHSS dell'influenza condivisa, dei tipi di media e delle espressioni.

Selettori

CHSS offre un semplice insieme di selettori tradizionali cos� come selettori pi� sperimentali. I selettori tradizionali, che combinano dichiarazioni di stile con elementi strutturali nel documento, si basano sui nomi degli elementi:

h1.font.size = 12pt

Omettendo il nome dell'elemento, tutti gli elementi sono selezionati:

font.size = 12pt

CHSS offre anche due alias per selezionare pi� facilmente gruppi di elementi:

head.space.above = 15pt
list.space.first = 1cm

Nell'esempio, head seleziona tutti gli elementi di intestazione (H1-H6 in HTML), e list seleziona tutti gli elenchi (UL, OL, e DL in HTML). Il conflitto nominale tra l'alias head e l'elemento HEAD non � discusso nella proposta.

I selettori sperimentali offerti da CHSS ricadono in due categorie. Con la prima, il selettore window aggiunge dichiarazioni ad un elemento (ossia la finestra del browser) che non fa parte del documento:

window.margin.left = 2cm
window.margin.right = 2cm
window.margin.above = 2cm
window.margin.below = 2cm

Con la seconda, i tipi di media e le espressioni si comportano come selettori aggiungendo restrizioni a proposito di quando una regola debba essere usata. Questi tipi di selettori sono meta-selettori nel senso che lavorano unitamente ai selettori tradizionali, ma ad un pi� alto livello. I tipi di media sono discussi con pi� dettagli nella sezione Altri contesti di formattazione. Ecco alcuni esempi di espressioni:

AGE > 3d ? background.color = pale_yellow : background.color = white
DISPLAY_HEIGHT > 30cm ? http://NYT.com/style : http://LeMonde.fr/style
RELEVANCE > 80 ? h1.font.size *= 1.5

L'esempio � preso dalla proposta CHSS e dimostra che le espressioni possono essere diverse. AGE rappresenta il tempo da quando il contenuto � stato scritto ed � usato per dare al contenuto pi� vecchio uno sfondo giallo pallido. DISPLAY_HEIGHT � una caratteristica del dispositivo di output, che l'autore non ha modo di conoscere in anticipo. RELEVANCE � un numero che rappresenta quanto � rilevante un documento comparato col profilo personale dell'utente.

Propriet�

La proposta CHSS afferma specificamente che non � una definizione formale del linguaggio di stile e che l'elenco specifico di valori di stile � meno interessante degli altri argomenti. Si fa riferimento a RRP come ad un ragionevole elenco di propriet�.

Gli esempi in CHSS usano i nomi di propriet� con i punti. Questo schema di nomenclatura indica un raggruppamento di propriet� dove, per esempio, font � il nome del gruppo di propriet� e family e size sono propriet� individuali. Questa organizzazione � simile al raggruppamento di propriet� in FOSI e RRP.

La maggior parte dei nomi di propriet� che descrivono lo spazio intorno agli elementi sono assoluti piuttosto che relativi alla direzione di scrittura. Si consideri questo esempio:

space.left = 0pt
space.right = 0pt
space.above = 4pt
space.below = 4pt
space.first = space.left + 0.5cm 

Nell'esempio, le prime quattro propriet� usano nomi assoluti (left, right, above e below), mentre l'ultima propriet� (first) � relativa alla direzione di scrittura.

Valori e unit�

Come abbiamo visto nella precedente sezione, CHSS non contiene un elenco di valori di stile che possa essere paragonato con altre proposte. Tuttavia gli esempi e il testo descrivono diversi tipi di valori:

• valori di lunghezza numerici con identificatori di unit� (le unit� suggerite sono: pt, px, mm, cm)
• un valore numerico di sonorit� (discusso in "Altri contesti di formattazione")
• parole chiave (per esempio bold, italics, e proportional)
• semplici espressioni

Espressioni

Le espressioni meritano una discussione. Come prima cosa, le espressioni possono coivolgere variabili d'ambiente:

window.height = REAL_HEIGHT - 50px

Nell'esempio, REAL_HEIGHT probabilmente si riferisce all'altezza del dispositivo di output e l'asserzione fa si che la dimensione della finestra sia inferiore di 50 pixel.

Un altro tipo di espressione coinvolge il valore precedente della stessa combinazione di elemento/propriet�:

h1.font.size *= 1.5

Per calcolare la dimensione del font degli elementi H1, un programma utente dovrebbe per prima cosa calcolare la dimensione del font come se la regola non esistesse e quindi moltiplicare il vecchio valore per 1.5 al fine di trovare il nuovo valore. Inoltre il risultato finale deve essere scalato secondo l'influenza assegnata della regola. Il beneficio di questo approccio sta nel fatto che una regola pu� esprimere una restrizione relativa ad un'altra regola, possibilmente sconosciuta. Tuttavia l'algoritmo per trovare il valore effettivo � complesso.

Un terzo tipo di espressione riguarda i riferimenti ad altre propriet�. Ecco un semplice esempio:

space.first = space.left + 0.5cm 

Nell'esempio, l'indentazione della prima riga � la stessa dello spazio sul lato sinistro dell'elemento pi� 0.5cm. Questo � un altro esempio della descrizione di una restrizione che verr� risolta in futuro piuttosto che impostare un valore direttamente. La restrizione nell'esempio sta nel fatto che space.left venga calcolato prima di space.first per evitare restrizioni circolari. The em unit in CSS offers a similar feature and restriction: em units are relative to a value determined in the future, and the font-size must be computed before other length units.

Valori di fusione

Il concetto dell'influenza condivisa sullo stile � una caratteristica fondamentale di CHSS. Per principio, un numero qualsiasi di fogli di stile pu� richiedere, e ottenere, un'influenza su ogni combinazione di propriet�/elemento. Se pi� di una regola cerca di influenzare un valore, CHSS calcoler� un valore di mezzo basato su una media ponderata. La proposta descrive alcuni dei problemi che ricorrono quando si fondono i valori:

Per i valori continui, per esempio la dimensione del font, mescolarele influenze non � problematico – si calcola semplicemente la media ponderata se differiscono. Per i valori discreti, per esempio la famiglia di font, pu� non essere ovvio come mescolare 40% di helvetica e 60% di times. Alcuni sosterranno che le famiglie di font possono certamente essere parametrizzate e mescolate, altri che si dovrebbe selezionare la richiesta con l'influenza pi� alta. Il problema merita una ricerca maggiore dello spazio concesso in questa proposta.

La ricerca citata nell'ultima fase non si � ancora concretizzata. Per le propriet� che accettano valori numerici, per esempio font-size, � facile calcolare i valori della media ponderata. Anche se il valore � specificato in termini relativi (pi� grande del testo circostante) o come parola chiave (huge), si pu� trovare un valore numerico che si adatti ai calcoli. Tuttavia, altre propriet� accettano altri tipi di valore che sono pi� difficili da calcolare:

• valori booleani
• valori come parole chiave uni-dimensionali
• valori come parole chiave multi-dimensionali

I tipi di valore sopra elencati sarebbero stati pi� difficili da calcolare e anche se si fossero individuati gli algoritmi per trovare il valore calcolato, i risultati non sarebbero stati belli o intuitivi. La proposta di fondere i fogli di stile a livello di propriet� fu perci� abbandonata nella prima fase di sviluppo dei CSS, mentre il concetto di combinare i fogli di stile fu mantenuto.

La differenza tra CHSS, CSS e altre proposte su questo problema pu� essere descritta lungo un asse uni-dimensionale di granularit�. CHSS � la proposta con la granularit� pi� fine, che permette alle preferenze di essere calcolate su di una base sub-propriet� (ossia, diverse fonti possono influenzare il calcolo di una singola combinazione di elemento/propriet�). I CSS non hanno la medesima finezza nella granularit�, e permettono solo un influenza condivisa su di una base per-propriet�. La maggior parte delle altre proposte � ancora pi� monolitica, permettendo un'influenza condivisa solo su di una base per-foglio di stile (ossia un solo foglio di stile viene selezionato per descrivere la presentazione di un documento).

Trasmissione di valore

CHSS offre due meccanismi per la trasmissione di valore. Primo: le regole possono impostare i valori predefiniti per le propriet�. Si consideri questo esempio:

font.weight = normal

Omettendo il selettore dalla regola dell'esempio, il peso del font � impostato su normal per tutte le combinazioni media/elementi/propriet�.

Secondo: CHSS introduce il concetto di cascata che pu� essere considerato un meccanismo di trasmissione di valore. Ecco come viene descritta la cascata:

Lo schema proposto fornisce al browser un elenco ordinato (cascata) di fogli di stile. L'utente fornisce il foglio di stile iniziale, che pu� richiedere un controllo totale sulla presentazione, ma, – pi� verosimilmente – ha la maggior parte dell'influenza sui fogli di stile che fanno riferimento al documento.

Oltre ai fogli di stile degli utenti e degli autori, il browser pu� anche fornire un suo foglio di stile. Di solito il browser fornir� un foglio di stile di base che include descrizioni convenzionali delle presentazioni HTML. Una di queste convenzioni � quella secondo cui gli elementi H1 vengono mostrati con font pi� grandi del testo all'interno degli elementi P.

Affidandosi al fatto che il browser ha disponibile un foglio di stile di base, gli utenti e gli autori non devono ripetere tutte le regole stilistiche desiderate. Invece, possono semplicemente descrivere le differenze tra le convenzioni accettate e la presentazione desiderata. Cos�, la cascata riduce la lunghezza dei fogli di stile poich� le convenzioni accettate non devono essere ripetute.

Modello di formattazione visuale

CHSS non descrive un modello di formattazione visuale completo. Il codice di esempio indica che lo spazio bianco attorno agli elementi pu� essere descritto in propriet�. Tuttavia, non vi � una discussione su quale tipo di oggetti di formattazione vengano supportati dal linguaggio di stile, n� come gli elementi vengano classificati in differenti oggetti di formattazione.

Meccanismo di collegamento

CHSS propone di usare l'elemento LINK di HTML per puntare a fogli di stile esterni:

<LINK REL="style" HREF="http://NYT.com/style">

L'elemento LINK � usato per indicare l'URL del foglio di stile. Fogli di stile multipli possono essere indicati dallo stesso documento, aggiunti alla cascata e quindi uniti quando vengono incontrati.

Nell'elenco dei problemi irrisolti, � stato notato che consentire gli elementi LINK solo nell'HEAD del documento � una limitazione. Avendo un modo di aggiungere e sottrarre fogli di stile dall'interno del documento, si potrebbero dare stili diversi a differenti parti del documento. Questa idea � simile alla funzionalit� incontrata in PWP.

Contenuto generato

Non proposto.

Altri contesti di formattazione

CHSS pone l'accento sul fatto che la proposta pu� essere usata sia per i tipi di media visuali che non. Un esempio nella proposta imposta i valori di propriet� per il media acustico:

speech.*.weight = 35db
speech.em.weight = 40db

Similmente, la proposta contiene esempi con regole speciali per la stampa. Esempio:

print.head.align.style = right

Cos� come head � un alias per gli elementi H1-H6 in CHSS, la parola chiave print � anch'essa un alias per due specifici tipi di media: print_mono e print_color. Usando direttamente i tipi di media pi� specifici, un foglio di stile pu� descrivere le presentazioni per stampanti monocromatiche o a colori.

CHSS nel contesto

Lo sviluppo dei CSS inizi� sulla base della proposta CHSS. Molte delle idee di CHSS non sono sopravvissute nei CSS, ad esempio le variabili d'ambiente, gli alias dei selettori, e la fusione dei valori. Inoltre la sintassi dei CSS � diversa da quella proposta in CHSS.

Tuttavia, tre importanti aspetti di CHSS vengono usati nei CSS. Primo: la "C" nei CSS sta per cascata che fu descritta per la prima volta in CHSS. Sebbene il meccanismo di cascata in CHSS � differente da quello dei CSS, il concetto dell'influenza condivisa � lo stesso. Secondo: l'abilit� di usare informazioni al di fuori del documento stesso nella presentazione del documento fu introdotta in CHSS. I CSS non hanno variabili d'ambiente, ma le pseudo-classi sono basate sullo stesso concetto. Terzo: la nozione di tipi di media dei CSS2 fu proposto per la prima volta in CHSS.

Proposta di Joe English (JEP)

La proposta di Joe English, Style Sheets for HTML [English 1994a], venne annunciata alla mailing list www-html [English 1994b] nel novembre 1994. La mailing list www-html fu creata [Berners-Lee 1994] nel maggio 1994 per ospitare discussioni su questioni relative all'HTML. I fogli di stile erano tra i nuovi argomenti.

La proposta � la pi� estesa rispetto alle altre sui fogli di stile, e contiene ricche discussioni su argomenti difficili. Questo indica che l'autore vi aveva lavorato per diverso tempo. Tuttavia, quando la bozza fu pubblicata, l'autore annunci� anche che l'avrebbe abbandonata in favore di DSSSL Lite (discusso pi� avanti), e perci� la proposta non fu molto discussa su www-talk.

Sintassi

Ecco un semplice foglio di stile JEP:

<stylesheet>
  <style gis = "body"
    fontfam = normal
    fontsize = normalsize>
  </style>
  <style gis = "h1"
    fontfam = heading
    fontsize = large>
  </style>
</stylesheet>

Come FOSI e SHP, JEP � scritto in SGML. Semplici selettori sono specificati come valori per l'attributo gis, � ogni propriet� � un attributo per proprio conto. Nell'esempio, le propriet� fontfam e fontsize sono impostate su BODY e sugli elementi H1.

Le propriet� JEP e i loro valori sono abbastanza leggibili in questa sintassi, ma il selettore per l'attributo non � intuitivo a meno di non avere familiarit� con la terminologia SGML. I nomi di elemento in SGML sono chiamati Generic Identifiers (GI). Diversi GI diventano gis. FOSI usa l'attributo gi per lo stesso scopo.

Selettori

L'attributo gi nell'esempio � un semplice modo per selezionare gli elementi in base al loro nome. Esso accetta un elenco di nomi di elemento separati da uno spazio come valore:

<style gis = "h1 h2 h3"
  fontfam = heading>
</style>

Nell'esempio, la propriet� fontfam � impostata su tutti gli elementi H1, H2, e H3.

JEP descrive anche due meccanismi per selezionare gli elementi in modo contestuale, ossia in base alla loro posizione nella struttura del documento. Il primo � avere un insieme di stile applicato dalla propriet� useset. Gli insiemi di stile possono essere pensati come fogli di stile autonomi. Si consideri questo esempio:

<styleset id=inheading> 
  <style gis="em" fgcolor=red></style> 
</styleset>
<style gis="h1" useset = inheading></style>
<style gis="em" fgcolor=blue></style>

Nell'esempio, gli elementi EM sono rossi quando si trovano all'interno di un elemento H1, e blu altrove. Ci� � dovuto al fatto che la propriet� useset sull'elemento H1 dichiara che l'insieme di stile inheading debba essere usato all'interno dell'elemento H1.

Il secondo meccanismo, pi� convenzionale, � usare una sintassi di corrispondenza pattern simile a quella di X11 [X11]:

  <style context = "h1 * em" fgcolor=red></style>

La sintassi del secondo metodo � simile all'approccio adottato da CHSS e SSP.

Propriet�

JEP comprende un insieme di 28 propriet�. Combinate tra loro, tali propriet� sono in grado di descrivere gran parte delle convenzioni di resa dell'HTML 3.2 con l'eccezione delle tabelle e dei contatori. La Tabella 10 elenca le propriet� JEP.

Le propriet� JEP corrispondono all'incirca a quelle dei CSS1 [CSS1 1996]. Sia i CSS1 che JEP sono in grado di descrivere lo stile di base dei font, dei colori e della spaziatura. Possono inoltre disegnare riquadri intorno agli elementi ed eseguire trasformazioni maiuscolo-minuscolo. Nessuno di loro descrive tabelle, contatori, testo generato o tratteggiatura. La nomenclatura JEP delle propriet� � simile a FOSI (entrambi usano pre/right/left per descrivere quello che i CSS chiamano top/right/bottom/left) e si fa riferimento a FOSI nelle note (ma non nell'elenco dei riferimenti).

Per alcune delle propriet�, la proposta descrive il valore iniziale. JEP distingue anche tra propriet� ereditabili e non ereditabili.

JEP ha poche e semplici propriet� relative ai font rispetto ad altre proposte. Le tre propriet� dei font sono fontfam, fontsize, e fontshape. La propriet� fontfam accetta solo una tra quattro differenti parole chiave (normal, heading, fixed, alternate) le quali esprimono una famiglia di font logica. Similmente, la propriet� fontsize (attraverso parole chiave o, in alternativa, interi da 0 a 7) esprime una dimensione logica. Da ultimo, la propriet� fontshape accetta solo una di sei parole chiave che descrivono il peso (normal o bold), l'inclinazione (normal o slanted), la variante (normal o small-caps), e le dimensioni del glifo (proportional o monospace). Le sei parole chiave sono plain, bf (bold), it (italic), bi (bold italic), sc (small caps) e tt (monospace). Avendo solo sei parole chiave ci sono molte combinazioni che non possono essere espresse. Per esempio, � impossibile selezionare un font bold monospace, o un italic small-caps. La strategia per i font � descritta nella proposta:

Questo schema fornisce una limitata palette logica di font da scegliere per i designer, e i lettori sono in grado di selezionare i caratteri effettivi e le dimensioni a cui corrispondono i font logici.

Cos�, la proposta prevede che al lettore venga data la scelta finale dei font da usare fornendo una correlazione dal font logico al font effettivo. La proposta suggerisce anche un modo di descrivere questa correlazione:

<fontdesc fontfam=normal fontsize=normal fontshape=it> 
  <fontspec notation=XLFD> 
    -adobe-times-medium-r-normal–*-120-*-*-*-*-iso8859-1 
</fontspec>

Combinando i fogli di stile dell'autore con gli elementi FONTDESC del lettore, pu� essere raggiunta una semplice forma di cascata. Tuttavia, la proposta osserva nello specifico che solo un foglio di stile � concesso e che l'elemento FONTDESC � inteso per gli autori.

Un altro motivo per semplificare la specifica dei font in tre propriet� sta nel fatto che la proposta non supporta stili di font cumulativi [English 1994a]:

Alcuni autori possono aspettarsi che le specifiche bold e italic abbiano un effetto cumulativo, ossia che una frase italic all'interno di in testo bold dovrebbe essere resa come bold italic. [[L'utilit� di tutto questo mi ha sempre confuso, ma ogni programma Mac, o applicazione di desktop publishing, e anche LaTeX2e sembrano ritenere che la selezione dei font dovrebbe funzionare in questo modo. Credo che il concetto secondo cui si possano eseguire calcoli aritmetici sui font in tal modo sia fuorviante: Times Bold Italic non � semplicemente Times Roman pi� bold pi� italic.]]

(L'autore nella proposta usa doppie parentesi quadre per marcare i commenti.)

JEP �, come si fa notare, quasi la sola a non supportare stili di font cumulativi. La maggior parte degli altri linguaggi di stile supportano gli stili di font cumulativi fornendo propriet� dei font indipendenti ed ereditabili.

Valori e unit�

Forse le parti pi� innovative di JEP sono gli elenchi di valori e unit�. JEP supporta tre tipi principali di valori: lunghezza, colore e parola chiave. Di queste, i valori di lunghezza sono particolarmente interessanti.

Valori di lunghezza

Diversamente da molte altre proposte, JEP cita poco la possibilit� di valori di lunghezza assoluti (pt, mm, cm ecc.) ma descrive un numero di interessanti unit� di lunghezza relative. Le unit� di lunghezza relative si dividono in due categorie: unit� relative ai font e unit� relative al display.

Le unit� relative ai font sono:

• em, en, ex. JEP definisce em come l'ampiezza della lettera "M" maiuscola nel font in uso (mentre molti altri sistemi la definiscono come l'altezza del font in uso). Un interessante restrizione sull'unit� em � che pu� essere usata solo in contesti orizzontali.
• lh (line height): l'unit� � definita come la distanza normale tra riga di base e riga di base (inclusa l'interlinea) del font in uso.

Le unit� relative al display sono:

• pcd (per cent of display): l'unit� � relativa alla dimensione del display. Il campo d'applicazione va da 0 a 100 incluso.
• nlh (normal line height): l'unit� � definita come la distanza normale da riga di base a riga di base del corpo normale del font a dimensione normale. Mentre 1lh pu� avere diversi significati in differenti punti di un documento, 1nlh si riferisce sempre alla stessa altezza senza badare al font in uso.
• p: Un valore di 1p ( un p) rappresenta lo spessore di un hairline, ossia della pi� piccola quantit� di spazio visibile all'occhio umano.

Con la sola eccezione delle unit� comunemente usate em, en, ed ex, le unit� di lunghezza relative descritte in JEP non sono state riprese dalle successive proposte di linguaggi di stile. Credo che questa sia stata una scelta infelice.

Come in FOSI, i valori di lunghezza possono riferirsi ai margini del blocco contenitore. In questo modo i valori possono esprimere maggiori restrizioni. Si consideri questo esempio:

<style id=s1 lmargin="+3em" >

Mettendo come prefisso al valore il segno '+' o '-', il valore � relativo al blocco contenitore piuttosto che assoluto (presumibilmente rispetto all'area di visualizzazione). Per indicare un valore assoluto negativo, JEP suggerisce di usare '='.

Valori di colore

JEP richiede i fogli di stile per definire i nomi dei colori che vengono usati. Ecco un esempio di definizione e di uso del colore:

<colors> 
  <color id=red rgb="#F00"> 
  <color id=green rgb="#00FF00"> 
  <color id=blue rgb="#000000000FFFFF"> 
</colors>
<style gis = "code kbd pre" fgcolor=blue>
</style> 

In questo modo i nomi dei colori servono a rendere i fogli di stile pi� leggibili. A differenza degli altri linguaggi di stile, JEP non ha colori predefiniti.

Immagini

Le immagini che rappresentano marcatori di voci di elenco sono gestite in modo simile ai nomi dei colori. Ecco un semplice estrayyo dalla proposta:

<image id = kilroy
  url = "http://www.art.com/bitmaps/stupid-kilroy-gif.gif">

<style gis="hr" icon=kilroy  preskip=2p postskip=2p>
</style>

Definendo un nome di immagine con l'elemento image, si pu� usare un nome pi� familiare all'utente invece di un URL.

Valori chiave

I valori chiave in JEP sono abbastanza tradizionali. Ecco un esempio:

<style gis = "h1"
  fontfam = heading 
  fontshape = bf
></style>

La prima parola chiave usata, heading, si riferisce ad un font logico definito altrove (diverse opzioni sono discusse nella proposta). Non consentendo riferimenti a nomi di font reali come valori, JEP non ha bisogno di distinguere tra valori chiave e valori stringa, e questo semplifica la sintassi.

La seconda parola chiave, bf, � un abbreviazione per boldface. Molti dei valori chiave in JEP consistono di due lettere.

Trasmissione di valore

JEP ha due meccanismi principali per la trasmissione di valore: eredit� e cascata. Entrambi sono differenti dall'eredit� e dalla cascata nei CSS; l'eredit� in JEP � pi� complessa che nei CSS, mentre la cascata (JEP non usa questo termine) � pi� semplice.

Eredit�

L'eredit� � usata per trasferire i valori da elementi genitori e elementi figli nell'albero degli elementi. Per alcune propriet�, JEP descrive i valori iniziali (chiamati default in JEP), ma la proposta sembra aspettarsi che la maggior parte dei valori iniziali siano impostati sull'elemento radice (o un elemento prossimo alla radice) e usa l'eredit� per trasmettere il valore:

Per specificare propriet� di stile iniziali o globali, i designer possono usare un elemento STYLE da applicare all'elemento HTML o BODY. Le propriet� ivi specificate saranno ereditate da tutti gli altri elementi del documento.

Oltre all'eredit� di valori di propriet� da genitore a figlio, gli elementi STYLE possono ereditare valori l'uno dall'altro per evitare dichiarazioni duplicate. Si consideri questo esempio:

<stylesheet>
  <style id=headings 
    fontfam = heading 
    fontshape = bf 
    align = left
  ></style> 
  <style gis="h1" inherit=headings 
    fontsize=huge
    align=center> 
  </style>
  <style gis="h2" inherit=headings 
    fontsize=big> 
  </style>

Gli attributi inherit negli ultimi due elementi STYLE indicano che le dichiarazioni nel primo elemento STYLE si devono applicare anche agli elementi H1 e H2.

L'attributo useset descritto nella sezione sui "Selettori" � simile all'attributo inherit, e pu� essere considerato un altro meccanismo di trasmissione di valore.

Cascata

Oltre a CHSS, JEP � l'unico a proporre un meccanismo per negoziare tra le preferenze dell'autore e del lettore. JEP non usa il termine cascata ma il meccanismo proposto � simile:

I browser sono incoraggiati a fornire agli utenti la possibilit� di configurare il foglio di stile predefinito. Inoltre � auspicabile che gli utenti possano selettivamente sovrascrivere parti di un foglio di stile esterno senza trascurare l'intera specifica. Per far questo, i fogli di stile possono specificare un peso per ogni attributo. Il peso � un intero da 1 a 3 per i fogli di stile esterni, e da 0 a 4 per le configurazioni dell'utente. Un peso differente pu� essere specificato per ogni attributo di stile.

Fornendo all'utente una gamma pi� ampia di pesi, l'utente ha l'ultima parola. Questa � una soluzione semplice ad un problema molto discusso. La proposta, tuttavia, non suggerisce alcuna sintassi per esprimere i pesi.

Modello di formattazione visuale

JEP descrive un modello di formattazione abbastanza complesso ponendo l'accento sulle presentazione basate su schermo. Diversi argomenti avanzati (per esempio layout multi-colonna e layout di tabella) sono inoltre discussi senza proporre una soluzione. La Tabella 11 mostra come JEP ordini gli elementi HTML in categorie:

Paragonata ai CSS, JEP ha pi� tipi di elementi a livello di blocco: CSS1 distingue tra elementi a livello di blocco e voce di elenco, mentre JEP ha blocchi, paragrafi, elenchi, visualizzazione a blocco, intestazioni e divisioni. Il nome delle categorie indica che il motivo alla base dell'ordinamento degli elementi � semantico. Per esempio, sapere se un elemento � un'intestazione o no ha valore semantico, ma non dovrebbe – credo – limitare la presentazione dell'elemento. JEP, tuttavia, unisce a differenti categorie altrettante capacit� presentazionali. Per esempio, solo gli elementi di intestazione possono essere presentati come run-in. Ci� � simile a come differenti propriet� si applicano a differenti classi di oggeti di flusso in DSSSL.

JEP descrive per gli elementi un sequence model piuttosto che un a box model. I valori di margine possono riferirsi al limite delle aree cos� come al limite del blocco contenitore. Ci� � simile al modello di formattazione di FOSI.

JEP pu� descrivere separatori avanzati tra gli elementi, tra cui barre e spaziatura. Si consideri questo esempio:

<sepspec id=chapsep>
  <hrule thick = 3p width = 100pcd align = center>
  <vspace vskip = 3p> 
  <hrule thick = 1p width = 100pcd align = center> 
  <vspace vskip = 4nlh> 
</sepspec>
<style 
  gis = "h1" 
  fgcolor = blue 
  presep = chapsep 
  postskip = 3nlh> 
</style>

L'elemento SEPSPEC nell'esempio descrive un separatore che comprende due regole orizzontali HRULE) con spazio verticale (VSPACE) sopra e sotto di esse. Si fa riferimento al separatore nella propriet� presep dell'elemento STYLE cosicch� tutti gli elementi H1 avranno un separatore prima di essi.

Meccanismo di collegamento

JEP propone di collegare i fogli di stile esterni con l'elemento LINK nell'intestazione del documento, o in un'intestazione HTTP quando ci carica il documento. HTML e CSS hanno in seguito usato lo stesso approccio per collegare i fogli di stile.

JEP supporta anche un modo di far riferimento direttamente agli elementi STYLE attraverso l'attributo style nel documento. Ecco un semplice esempio:

In HTML, they are all marked up as <code
style=html-elem>CODE</code> elements, but
it would be useful...

Affinch� l'attributo style abbia effetto, il foglio di stile esterno deve avere un elemento STYLE con un corrispondente attributo ID:

<style id=html-elem 
  fontshape=tt 
  fgcolor=red>
</style>

Contenuto generato

JEP discute i requisiti per il testo generato, ma non contiene una proposta concreta.

Altri contesti di formattazione

La proposta descrive solo un contesto di formattazione visuale, ma richiede specificamente feedback su come supportare presentazioni non-visuali.

JEP nel contesto

JEP � una proposta di linguaggio di stile sia tradizionale che innovativa. JEP � tradizionale nel senso che usa una sintassi basata su SGML simile a FOSI. Inoltre l'autore fa riferimento e prende in prestito diverse caratteristiche da altri linguaggi esistenti, tra cui DSSSL e LaTeX. JEP � anche innovativo. In particolare, le unit� di lunghezza relative al display (pcd, nlh, p) sono un contributo notevole.

Quando JEP fu pubblicato, il suo autore scrisse:

Ho continuato a lavorare sulla proposta di fogli di stile per diversi mesi, ed ora � sul punto di essere pubblicata. Tuttavia, probabilmente ora la abbandoner�. Ci sono altri lavori in corso d'opera – soprattutto la proposta DSSSL Lite – che sembrano di gran lunga migliori.

Non sono d'accordo con l'autore sulla qualit� del suo lavoro: personalmente trovo che JEP sia una proposta pi� adatta di DSSSL Lite.

Abbozzo di Simple Formatting Primitives (SSFP)

Il titolo di questa proposta suggerisce che si tratti di un semplice progetto di propriet� stilistiche. Infatti la proposta abbozza, pi� che definire in toto, un semplice insieme di tipi primitivi di formattazione, ma non si limita solo ai tipi primitivi (che � il termine che SSFP usa per propriet�). SSFP delinea un completo linguaggio di stile che include la sintassi, i selettori, propriet�, valori e unit�. L'autore della proposta ha opinioni chiare su come i fogli di stile debbano essere collegati ai documenti, e va oltre la maggior parte delle altre proposte descrivendo il comportamento dei collegamenti. Perci�, nonostante il titolo, la proposta merita di essere discussa in questo capitolo.

SSFP � datata settembre 1994 e fu pubblicata per la prima volta sulla mailing list www-talk nel novembre 1994 [Sperberg-McQueen 1994a]. Il messaggio che annunciava la proposta [Sperberg-McQueen_1994b] contiene informazioni aggiuntive che sono importanti per l'interpretazione della proposta. Allo scopo di valutare SSFP, il messaggio di annuncio � perci� considerato parte della proposta.

Sintassi

SSFP afferma che la notazione non � qui specificata, ma varie opzioni sono ovviamente adatte. La proposta usa una sintassi ispirata a LISP in tutti gli esempi. Ecco un esempio:

(style a
    (block #f)     ; format as inline phrase
    (color blue)   ; in blue if you've got it
    (click (follow (attval 'href)))  ; and on click, follow url

La prima riga seleziona gli elementi A, mentre il resto del foglio di stile assegna valori alle propriet�. Gli elementi selezionati sono impostati come in riga, e gli viene assegnato un colore blu. L'ultima riga descrive il comportamento dei collegamenti ipertestuali: se l'elemento viene cliccato, il valore dell'attributo href deve essere seguito. Descrivendo il comportamento ipertestuale, SSFP – insieme con SSP – va oltre il normale ambito dei linguaggi di stile.

Selettori

SSFP supporta solo un semplice tipo di selettore. Gli esempi nella proposta selezionano gli elementi solo in base al loro nome. Ecco un esempio:

(style h1
    (block #t)
    (vspace '24pt '8pt)
    (shape 'centered)
    (font-size 'vlg)
    (font-style 'bold)
    (flow #f))

L'autore della proposta � ben consapevole del bisogno di selettori pi� avanzati, e il problema � discusso nel messaggio d'annuncio [Sperberg-McQueen 1994b]:

Critico al fine di rendere utile l'apparato logico � un ragionevole insieme di funzioni primitive per ricercare la locazione degli elementi nel documento SGML.

La ragione per cui non vengono inclusi selettori pi� avanzati sta forse nel fatto che la proposta era specificamente indirizzata al relativamente semplice linguaggio HTML. Questa ipotesi trova riscontro nel messaggio di accompagnamento, dove si afferma che la proposta descrive solo il comportamento dei browser HTML come descritto nelle specifiche HTML.

Propriet�

SSFP descrive 13 propriet� e questo � l'insieme di propriet� pi� semplici tra le proposte discusse in questo capitolo. La Tabella 12 elenca le propriet� insieme con gli equivalenti CSS.

Tre delle propriet� della tabella offrono una funzionalit� senza corrispettivo nelle altre proposte di questo capitolo, e metitano una menzione particolare:

• La propriet� shape � elencata ma non descritta nelle specifiche. A giudicare dall'elenco di valori chiave, questa propriet� determina i margini orizzontali degli elementi, l'allineamento del testo all'interno dell'elemento, ed anche le virgolette nel margine dell'elemento.
• La propriet� display-level non � descritta in dettaglio nella proposta ma, a giudicare dal nome, sembra simile alla propriet� Visibility di P94 [Quint 1994]. Cos� � un modo di creare vedute evidenziate del documento, dando per esempio alle intestazioni valori pi� alti rispetto ai paragrafi. Alzando o abbassando la soglia di visualizzazione, gli elementi diventano visibili o invisibili.
• La propriet� click descrive il comportamento dei collegamenti. La proposta elenca due modi di descrivere il comportamento dei collegamenti HTML per l'elemento A:

  (style a (click (follow (attval 'href))))
  (style a (click 'follow-URL 'HREF))
  

  La propriet� click � descritta in una sezione chiamata Azioni dove � anche citata la possibilit� di avere una propriet� double-click.

I nomi delle propriet� SSFP non spiegano se esse sono relative alla direzione di scrittura o no. Si consideri questo esempio:

(style address
    (margins '+10pica '0))

La propriet� margins assume due valori, ma non � chiaro se i valori sono assoluti (left/right) o relativi alla direzione di scrittura. I valori della propriet� shape usano nomi assoluti (per esempio indent-left, indent-twice-left), mentre i due valori della propriet� vspace sono descritti come spazio verticale prima e dopo l'elemento. SSFP sembra perci� usare un modello misto senza una chiara preferenza per nomi assoluti o relativi.

Valori e unit�

I valori e le unit� in SSFP sono simili a quelli usati in DSSSL:

• la parole chiave hanno come prefisso un apostrofo
• i valori true/false sono rappresentati rispettivamente da "#t" e "#f"

Ci sono, tuttavia, alcune differenze nei valori tra DSSSL e SSFP:

• i valori di lunghezza SSFP hanno come prefisso un apostrofo; in DSSSL no
• i nomi di colore SSFP non hanno come prefisso un apostrofo; in DSSSL si

L'elenco di valori di lunghezza non � definito nelle specifiche ma gli esempi usano le seguenti unit�: pt, pica, e l. L'ultima unit� pu� riferirsi all'interlinea ma questo non � descritto nella proposta.

Trasmissione di valore

SSFP ha due meccanismi per la trasmissione di valore: valori iniziali (detti valori predefiniti), e eredit�.

Sebbene le specifiche elenchino solo il valore iniziale per quattro propriet�, � ragionevole supporre che una proposta pi� sviluppata avrebbe elencato i valori iniziali per tutte le propriet�.

L'eredit� non ricorre automaticamente in SSFP. Tuttavia, tutte le propriet� accettano il valore CURRENT che specifica che la propriet� deve essere ereditata. INHERIT � dato come sinonimo di CURRENT.

Modello di formattazione visuale

Dato che la proposta descrive solo 13 propriet�, il modello di formattazione visuale di SSFP � abbastanza semplice. Gli oggetti di formattazione sono sia di blocco che in riga. Gli oggetti di blocco hanno:

• una forma, come descritto nella sezione sulle Propriet�
• spazio verticale prima e dopo l'elemento
• margini su ciascun lato dell'elemento

Come FOSI e JEP, i valori di lunghezza in SSFP possono essere preceduti dai segni '+' o '-'. Ci� indica che SSFP supporta un modello ad area simile a FOSI, dove i valori con prefisso si riferiscono ai limiti del blocco contenitore e gli altri invece ai limiti dell'area. Il testo, tuttavia, non tratta questo problema.

Meccanismo di collegamento

La proposta sostiene con forza che non si dovrebbe far riferimento ai fogli di stile dal documento stesso, ma piuttosto usando un header HTTP:

Vorrei sottolineare il punto finale con maggior vigore: non si dovrebbe affatto far riferimento ai fogli di stile dal *documento* HTML; il collegamento dovrebbe essere esterno al documento, stabilito nell'header HTTP, non all'interno del documento HTML.

Contenuto generato

Nonostante la sua semplicit�, SSFP supporta il contenuto generato con la propriet� content. La propriet� content pu� assumere uno fra tre valori. Il valore content() si riferisce al contenuto dell'elemento stesso ed � il valore iniziale. Il valore attval(NAME) nomina un attributo il cui valore sar� usato al posto del contenuto dell'elemento. Il valore string literal permette al foglio di stile di impostare il contenuto dell'elemento. I CSS2 hanno una propriet� con lo stesso nome e con valori simili.

SSFP comprende anche una discussione sul supporto ai contatori.

Altri contesti di formattazione

Non proposti.

SSFP nel contesto

SSFP � una semplice proposta con debiti verso FOSI e DSSSL. La proposta si preoccupa dei browser web a basso livello e delle implementazioni di livello pi� alto, presumibilmente prodotti basati su SGML. Pu� essere visto come un tentativo di gettare un ponte tra il Web e SGML.

La principale debolezza della proposta sta nella sua immaturit� ed incompletezza.

Il suo punto di forza principale � la descrizione di funzionalit� avanzate – in primis contatori, comportamento dei collegamenti e testo generato – in una semplice proposta.

Un altro importante traguardo di SSFP � che la proposta � ancora disponibile all'indirizzo originario del 1994 ( http://tigger.cc.uic.edu/~cmsmcq/style-primitives.html).

DSSSL Lite

Nel novembre 1994 la conferenza SGML '94 si tenne a Tysons Corner (Virginia, USA). Alla conferenza partecip� un gruppo di persone per discutere la possibilit� di definire un sottoinsieme del Document Style Semantics and Specification Language (DSSSL). Come discusso nel precedente capitolo, DSSSL � una complessa specifica e vi sono poche speranze che i browser web la supportino in toto. Definendone un sottoinsieme, chiamato DSSSL Lite, l'obiettivo era quello di creare un linguaggio di stile che fosse semplice ma abbastanza potente da fornire una base per l'interscambio di fogli di stile sul Web [Magliery 1994].

Nel dicembre 1994 l'Annuncio di DSSSL Lite fu inviato a varie mailing list e newsgroup [Magliery 1994]. Si incoraggiavano le persone ad unire i loro sforzi per creare un sottoinsieme delle specifiche DSSSL che fosse indirizzato all'uso sul Web, e il messaggio fu inoltrato da Tom Magliery che era un programmatore nel team di NCSA Mosaic.

James Clark scrisse la prima bozza. La versione analizzata in questo capitolo � datata 24 novembre 1994 [Clark 1994]. È scritta per lettori che hanno familiarit� con DSSSL e non cerca di promuovere o insegnare DSSSL Lite ad un pubblico pi� ampio.

Lo scopo dell'opera era che DSSSL Lite fosse un sottoinsieme di DSSSL [Magliery 1994]. Tuttavia, vi sono diverse discrepanze tra DSSSL Lite e DSSSL standard. Per esempio, diverse propriet� elencate nella proposta DSSSL Lite non esistono in DSSSL. Questo � probabilmente dovuto al fatto che lo standard DSSSL non era ancora al suo stadio finale nel 1994.

La proposta DSSSL Lite non contiene nessun esempio esteso sull'uso del linguaggio. Vengono mostrati solo piccoli frammenti di codice, e questo rende difficile l'analisi della proposta. Ho cercato di scrivere gli esempi secondo la proposta.

Sintassi

DSSSL Lite si basa su DSSSL e usa la sintassi DSSSL. Ecco un semplice esempio:

(element H1
  (paragraph font-size: 20pt))

Nell'esempio, gli elementi H1 sono selezionati e trasformati in paragrafi con dimensione del font di 20pt. Un paragrafo � uno dei 14 diversi oggetti di flusso in DSSSL Lite. Diversamente da DSSSL, DSSSL Lite non richiede la parola chiave make prima del nome di un oggetto di flusso.

Selettori

DSSSL Lite offre quattro tipi di selettori:

• selettori di tipo selezionano gli elementi in base al loro tipo. L'esempio nella sezione precedente usa un selettore di tipo.
• selettori contestuali selezionano gli elementi in base al tipo e agli antenati. Ecco un esempio che seleziona gli elementi LI figli di UL:

  (element (UL LI)
     (labeled-item)
  

  I selettori contestuali in DSSSL Lite sono simili a quelli nei CSS.

• selettori di id selezionano gli elementi in base al loro identificatore unico (in HTML, questo � il valore dell'attributo ID).
• il selettore di radice seleziona l'elemento radice.

Non � possibile selezionare gli elementi in base ai loro attributi. Tuttavia, gli elementi possono essere trattati in modo differente sulla base dei loro attributi o antenati usando il linguaggio di espressioni e di query:

(element NOTE 
  (if (attribute "WARNING") 
      font-weight: 'bold))

L'asserzione if � una delle espressioni supportate da DSSSL Lite. Sono supportate anche altre espressioni logiche, come and e or.

La funzione attribute ricerca gli attributi dell'elemento. DSSSL Lite descrive tre funzioni per la ricerca degli attributi:

• attribute: restituisce un attributo dell'elemento corrente, o false se l'elemento corrente non ha tale attributo;
• inherited-attribute: restituisce un attributo dell'elemento corrente o dell'antenato pi� prossimo in cui l'attributo � presente;
• ancestor-attribute: restituisce l'attributo dell'antenato pi� prossimo di un dato tipo.

Per gestire i contatori sono definite queste funzioni di query:

• child-number: restituisce il numero del figlio dell'elemento corrente, ossia, il numero dei fratelli precedenti dello stesso tipo restituisce il numero del figlio dell'antenato pi� prossimo di un dato tipo.
• ancestor-child-number: restituisce il numero del figlio dell'antenato pi� prossimo.
• hierarchical-number: restituisce un elenco di numeri di figlio per un dato elenco di tipi di elemento. Per ogni tipo di elemento, l'elenco restituito descrive l'antenato pi� giovane dell'elemento corrente.
• hierarchical-number-recursive: restituisce un elenco di numeri di figlio per un dato tipo di elemento. La lunghezza dell'elenco restituito riflette il numero di elementi di quel tipo tra gli antenati.
• element-number: restituisce il numero degli elementi con lo stesso tipo dell'elemento corrente, comparendo prima dell'elemento corrente.
• element-number-list: restituisce il numero dell'elemento per un dato elenco di tipi di elemento.
• first: restituisce true se l'elemento corrente non ha un fratello precedente dello stesso tipo.

Propriet�

La proposta DSSSL Lite elenca 27 propriet� (dette caratteristiche in DSSSL). La Tabella 13 elenca le propriet� nell'ordine con cui appaiono nella proposta:

Valori e unit�

La proposta non elenca valori e unit�.

Trasmissione di valore

La proposta definisce le propriet� come ereditate o no. I valori iniziali delle propriet� non sono discussi.

Modello di formattazione visuale

DSSSL Lite descrive un semplice modello di formattazione visuale adatto per presentazioni su stampante e su schermo. Il modello � molto pi� semplice rispetto a DSSSL:

• DSSSL Lite elenca 14 oggetti di flusso rispetto ai 35 di DSSSL (esclusi gli oggetti di flusso DSSSL per le formule matematiche);
• DSSSL Lite elenca 27 rispetto alle oltre 200 di DSSSL (esclusi gli oggetti di flusso DSSSL per le formule matematiche).

I principali limiti di DSSSL Lite rispetto a DSSSL sono:

• solo colonna singola;
• nessuna nota a pi� di pagina
• intestazioni e pi� di pagina possono avere solo una riga.

Gli oggetti di flusso proposti per DSSSL Lite, in ordine di apparizione, sono: root, paragraph, labeled-item, character, rule, leader, external graphic, table, table-part, table-row, inline-table-cell, display-table-cell e iconify.

Inoltre, viene discussa, ma non nominata, una semplice variante dell'oggetto di flusso page-sequence. Pi� probabilmente, il lavoro su DSSSL Lite per simple-page-sequence fu aggiunto a DSSSL.

Meccanismo di collegamento

Come DSSSL, DSSSL Lite non specifica come i fogli di stile vengono collegati ai documenti.

Contenuto generato

Altri contesti di formattazione

Non proposti.

DSSSL Lite nel contesto

Il lavoro su DSSSL Lite ottenne un considerevole supporto dalle persone importanti nella comunit� web. Nel gennaio 1995, Dave Raggett aggiunse l'elemento STYLES, l'elemento STYLE e l'attributo CLASS alla bozza di HTML 3.0 in fase di sviluppo. Scrisse nella bozza:

Un foglio di stile pu� essere associato al documento usando l'elemento LINK, per esempio <LINK rel=stylesheet href="housestyle.dsssl">. Le sovrascritture di stile possono essere inserite nell'intestazione del documento usando l'elemento STYLES, per esempio

<styles notation=dsssl-lite>
  <style class=bigcaps>(dsssl-lite-stuff)
  <style class=para17>(more dsssl-lite-stuff)
</styles>

Nel maggio 1995, Dan Connolly del W3C scrisse un email personale a Tim Berners-Lee, David Raggett e me:

DSSSL-Lite, dalle mie ricerche, sembra essere proprio "il pi� semplice possibile, e non pi� semplice." Non � del tutto chiaro quale sia il vantaggio delle altre proposte.

Le altre proposte sono in seguito descritte:

Da quello che ho visto delle proposte di Bert Bos ed Hakon Lie, stanno reinventando DSSSL usando la sintassi X Resource piuttosto che le espressioni-s di lisp.

La sua conclusione �:

Suggerisco quindi che il futuro sviluppo dei fogli di stile sia basato su DSSSL-Lite. Non � giustificato spendere risorse per un meccanismo che non � compatibile.

DSSSL Lite aveva anche un forte supporto nella comunit� SGML. Joe English, la persona che propose JEP, abbandonata poi a favore di DSSSL-Lite, scrive in una retrospettiva email personale [English 2002]:

Pensavo che DSSSL-Lite sarebbe stato il "vincitore" – la comunit� SGML aveva anticipato le specifiche DSSSL per anni (letteralmente!) con enormi aspettative. Come poi risult�, DSSSL non fece fuoco e fiamme, ma all'epoca pensavamo tutti che lo avrebbe fatto...

Anche le societ� commerciali erano coinvolte nello sviluppo di DSSSL Lite. Almeno una compagnia annunci� progetti per supportarlo [EBT 1997]:

GMUNDEN, AUSTRIA (SGML EUROPE '95) 16 maggio 1995 – Come ulteriore esempio della sua filosofia basata sugli standard, la Electronic Book Technologies Inc. (EBT, Booth # 25) ha annunciato oggi piani per includere il supporto al Document Style Semantics and Specification Language (DSSSL) nella prossima versione di DynaText(tm), il sistema di pubblicazione online basato sugli standard della EBT. EBT ha anche in programma di supportare "DSSSL Lite," attualmente proposto come linguaggio di stile per il World-Wide Web (Web) ...

Nell'ottobre del 1995, il nome dello sforzo per creare un sottoinsieme di DSSSL fu cambiato da DSSSL Lite a DSSSL Online Application Profile, comunemente chiamato DSSSL-O. Uno dei motivi per abbandonare il nome DSSSL Lite fu che 'Lite' � il celebre nome di un tipo di birra particolarmente insipida [Bosak 1995].

DSSSL-O fu completato nel 1996, quasi nello stesso periodo in cui DSSSL divenne uno standard ISO. James Clark era un architetto ed editore di entrambe le specifiche, e sembra chiaro che il lavoro su DSSSL Lite e DSSSL-O influenz� lo sviluppo finale di DSSSL.

DSSSL-O fin� per essere molto pi� complesso della proposta DSSSL Lite esaminata in questo capitolo. La Tabella 14 compara il numero delle classi di oggetti di flusso e propriet� nelle tre specifiche DSSSL.

La complessit� di DSSSL-O pu� essere un motivo per il quale non venne mai implementato da nessun browser e non vide mai alcun uso reale sul Web. La comunit� DSSSL ha da allora sviluppato XSL [XSL 2001].

Proposta di fogli di stile basati sul flusso (SSP)

Nel marzo 1995, Bert Bos pubblic� una proposta chiamata Proposta di fogli di stile basati sul flusso (SSP) [Bos 1995]. L'autore sottolinea il bisogno di un linguaggio di stile che possa presentare i documenti in modo progressivo appena vengono scaricati dal Web nel browser, donde il nome basati sul flusso. La proposta comincia con la discussione su come le precedenti proposte si comportino rispetto a tale requisito. Fra di esse, diverse sono in grado di rendere il contenuto in modo progressivo (tra cui RRP, PWP e CHSS). Le uniche proposte tralasciate per non essere basate sul flusso sono DSSSL e DSSSL Lite.

Un'altra caratteristica sottolineata in SSP � la capacit� di applicare i fogli di stile ai documenti SGML oltre che a quelli HTML.

Sintassi

Ecco un frammento di un foglio di stile d'esempio di SSP:

HTML.justify: full
*H1.justify: center
*OL.LI.label: A

Ogni riga nell'esempio � una regola stilistica con un selettore, una propriet� e un valore. La sintassi � mutuata dai file di risorsa X11 [X11]. SSP sostiene che la sintassi del file di risorsa X11 sia semplice, leggibile e scrivibile dall'uomo, e che supporti le strutture ad albero. Inoltre il software per l'analisi della sintassi � gi� disponibile.

SSP distingue i nomi di elemento e le propriet� in base al caso (maiuscolo/minuscolo): i nomi di elemento sono scritti in maiuscolo e le propriet� (e i tipi di media) in minuscolo.

Selettori

Nell'esempio, il nome dell'elemento (per esempio H1) � preceduto da un carattere di asterisco (*) per selezionare tutti gli elementi nell'albero. Senza l'asterisco, viene selezionato solo l'elemento radice (HTML nell'esempio citato). Questa sintassi sottolinea la natura strutturata del contenuto di destinazione e ricorda agli autori che i fogli di stile si applicano a documenti strutturati. Questo approccio � simile a quello di Pei Wei, di sicuro con una sintassi pi� leggibile.

I selettori possono anche esprimere relazioni parentali e ancestrali:

*OL*OL.LI.label: A

In questo esempio, vengono selezionati gli elementi LI con un genitore OL e un altro elemento OL come antenato.

SSP propone anche di estendere i selettori per esprimere i tipi di media:

b&w*A.textcolor: white
b&w*A.textbackground: black
monochrome*A.textcolor: black
monochrome*A.textbackground: gray80

Nell'esempio, le prime due regole si applicano a dispositivi in bianco e nero, mentre le ultime due a dispositivi monocromatici. Questo metodo per supportare differenti tipi di media � simile a CHSS.

I selettori in SSP possono anche riguardare il valore degli attributi ID:

*id: !ID
@p101.size: 1

Nell'esempio, la prima riga stabilisce che, per tutti gli elementi, la propriet� id trova il suo valore dall'attributo ID (il punto esclamativo indica un riferimento ad attributo). Quando si � stabilito che l'attributo ID contiene il valore della propriet� id, i selettori che selezionano valori ID possono essere scritti facendoli precedere da un carattere '@'. La seconda riga dell'esempio seleziona ogni elemento con questo attributo: ID="p101"

Quindi la semplice sintassi del file di risorsa X11 � stata estesa per esprimere selettori ID. Introducendo ancora pi� simboli, la sintassi del selettori si sarebbe potuta estendere ulteriormente. SSP, tuttavia, sceglie di aggiungere espressioni logiche nelle dichiarazioni piuttosto che nei selettori. Si veda la sezione sui Valori pi� avanti. Questo approccio � simile a P94 e DSSSL.

Propriet�

Le propriet� proposte da SSP sono elencate nella Tabella 15. Il raggruppamento delle propriet� � stato fatto dall'autore di questa tesi.

Alcune delle propriet� sopra elencate meritano un ulteriore discussione:

• emphasis: questa propriet� assume un valore intero che va da zero in su per esprimere i livelli di enfasi. La propriet� non dice come debba essere formattato il livello di enfasi, lasciando questo problema al browser. Cos� questa propriet� � pi� semantica che presentazionale. Ci� � inusuale in un linguaggio di stile. Quando � in conflitto con altre propriet� pi� orientate alla presentazione, essa viene sovrascritta.
• prebreak/postbreak: queste propriet� indicano la quantit� minima di spazio bianco sopra/sotto l'elemento. Il concetto di spazio minimo (piuttosto che spazio esatto) � usato anche nei CSS.
• minimized: se � vera, questa propriet� indica che l'elemento � rimpiazzato da un marcatore. Se cliccato, il marcatore mostrer� il contenuto dell'elemento. Questa caratteristica � un esempio di comportamento interattivo che non � stato ripreso da altri linguaggi di stile.
• noindent: questa propriet� sopprime l'indentazione della prima riga di testo sul paragrafo successivo. Di solito tale indentazione viene soppressa sui paragrafi che seguono un'intestazione e, poich� � pi� facile selezionare gli elementi di intestazione piuttosto gli elementi che seguono un'intestazione, questa propriet� semplifica la specifica di stile.
• empty/id: la propriet� empty indica se un elemento � vuoto o no, e la propriet� id nomina l'attributo che contiene l'ID degli elementi. In SGML questa informazione � conservata nella DTD. I browser SGML hanno pochi motivi per consultare la DTD se non per trovare gli elementi vuoti e quale attributo sia l'attributo ID. Conservando l'informazione in un foglio di stile, SSP sfida il bisogno delle DTD.
• title/stylesheet: queste propriet� identificano rispettivamente gli elementi che contengono titoli e fogli di stile. Usando queste propriet� � possibile trasformare qualsiasi elemento SGML in un elemento TITLE o STYLE dell'HTML. I valori della propriet� stylesheet permettono ai fogli di stile di essere fusi in vari modi. Questa caratteristica � descritta in dettaglio nella sezione Trasmissione di valore pi� avanti.
• target/anchor/anchorshape/anchorcoords: queste propriet� identificano le ancore e le destinazioni nei documenti sorgente, rendendo cos� possibile l'ipercollegamento. Esse vanno oltre i tradizionali fogli di stile descrivendo il comportamento dei documenti in aggiunta alla loro presentazione.

Valori e unit�

SSP offre una gamma di valori dal semplice al complesso. Nella pratica – dove la pratica � definita dai fogli di stile d'esempio nella proposta – i valori semplici coprono la maggior parte dei bisogni, mentre quelli avanzati risolvono problemi specifici.

Ci sono quattro tipi diversi di valori semplici (detti valori espliciti) in SSP: intero, numero decimale, parola chiave e stringa. Ogni propriet� accetta solo un tipo di valore semplice. Si consideri questo esempio:

*H2.size: 1
*HR.rulethickness: 0.1
*H2.justify: left
*H2.familyname: Gill Sans

La prima regola nell'esempio assegna un valore intero alla propriet� size per gli elementi H2. La propriet� size accetta solo valori interi (che servono da indici in una tabella definita dal browser) e, perci�, non c'� bisogno di identificatori di unit�. La seconda regola assegna un numero reale (non un intero) alla propriet� rulethickness. Il valore � relativo all'interlinea. Nella terza regola, alla propriet� justify � assegnato il valore left. Il valore nella quarta regola � il nome di una famiglia di font, e poich� l'elenco di nomi di font � open-ended, il valore � una stringa e non una parola chiave. Tuttavia, poich� la propriet� accetta solo un tipo di valore semplice, non c'� bisogno di differenziare sintatticamente le stringhe dalle parole chiave.

In aggiunta ai valori semplici, SSP ha tre valori avanzati: riferimenti ad attributo, riferimenti a propriet�, e la funzione ifmatch.

Riferimenti ad attributo

Ecco un esempio di come usare i riferimenti ad attributo:

*IMG.width: !WIDTH

In questo esempio, alla propriet� width � assegnato il valore dell'attributo WIDTH dell'elemento IMG. In HTML, l'elemento IMG ha un attributo WIDTH che assume un intero come valore. Poich� la propriet� width in SSP accetta anche un valore intero rappresentante i pixel, la semplice regola trasferisce informazioni presentazionali dalla marcatura al linguaggio di stile. Una regola simile pu� essere scritta per l'altezza.

La semplice bellezza del precedente esempio, tuttavia, impone anche una rigida restrizione: solo un tipo di valore pu� essere trasferito (in questo caso pixel). Il sistema non � in grado di gestire valori percentuali che sono validi secondo l'HTML.

Riferimenti a propriet�

I riferimenti a propriet� sono descritti brevemente nella proposta, ma viene dato solo un esempio incompleto. Il seguente esempio � costruito dall'autore di questa tesi:

PRE.width: $width

Il valore nell'esempio � il nome della propriet� (width) preceduto da un segno $, che indica che il valore deve essere preso dall'elemento genitore. L'effetto � far si che la propriet� width erediti per gli elementi PRE.

Funzioni incorporate

Il valore pi� avanzato in SSP � la funzione incorporata ifmatch. Si consideri questo esempio (che � il solo esempio con ifmatch nella proposta):

*IMG.ismap: @ifmatch(!ISMAP, "ISMAP", true, false)

Uno scopo della funzione ifmatch � quello di affrontare i limiti dei riferimenti ad attributo descritti sopra. Il riferimento ad attributo (!ISMAP) restituisce solo il valore di un attributo. Se il valore di attributo non corrisponde esattamente ai valori accettati da un elemento, essi possono essere trasformati dalla propriet� ifmatch. Nell'esempio, la propriet� ismap accetta true e false e questo � ci� chela funzione ifmatch restituisce. La funzione restituisce true se il valore dell'attributo ISMAP � uguale all'espressione regolare data come secondo argomento della funzione. Altrimenti � restituito false.

La funzione ifmatch � un valore complesso, sia per gli autori che per le implementazioni. Nessun altro linguaggio di stile usa espressioni regolari come valori, e l'autore di SSP cambi� poi idea su questo argomento [Bos 1998].

Trasmissione di valore

SSP si basa su due meccanismi familiari di trasmissione di valore: eredit� e valori iniziali. C'� anche un meccanismo per combinare diversi fogli di stile.

Per ogni propriet�, la proposta specifica se � ereditata o meno. Le propriet� non ereditate possono essere messe in grado di ereditare tramite i riferimenti a propriet� descritti sopra.

La propriet� stylesheet dichiara che l'elemento contiene un foglio di stile. Il foglio di stile contenuto nell'elemento pu� fondersi con altri fogli di stile, rimpiazzarli o sovrascriverli. Questo meccanismo ha una qualche somiglianza con la cascata, nel senso che � in grado di combinare regole di stile prese da diversi fogli di stile. Tuttavia, la fusione � intesa come una semplice concatenazione di due fogli di stile, dando al primo foglio di stile la priorit� in caso di conflitto. Inoltre tale meccanismo non ha la nozione dell'origine del foglio di stile (utente/autore/browser).

Modello di formattazione visuale

Rispetto ad altre proposte discusse in questo capitolo, SSP descrive un modello di formattazione avanzato. Oltre ai fondamentali elementi in riga o a livello di blocco, vengono discussi elementi flottanti, tabelle e didascalie.

SSP usa un box model dove gli elementi figli sono all'interno del loro genitore.

Sorprendentemente, non c'� una propriet� che distingua esplicitamente i due fondamentali tipi di elemento: a livello di blocco e in riga. Invece alcune propriet� implicano che un elemento sia a livello di blocco. Ossia, se una di queste propriet� (per esempio prebreak, ruleafter, leftindent) ha un valore non di default l'elemento diviene di blocco, altrimenti � in riga.

Gli elementi flottanti sono supportati tramite le propriet� track e flush. SSP definisce tre tracce – left, center e right – in cui un elemento pu� essere inserito. Quando gli elementi vengono inseriti nelle tracce di destra o di sinistra, gli elementi nella traccia centrale scorreranno attorno ad essi. La propriet� flush indica se un elemento pu� stare o meno vicino al contenuto flottato. Ecco un esempio del suo uso:

*IMG.track: right
*H1.flush: full

Qui gli elementi IMG sono flottati a destra mentre gli elementi H1 saranno sempre posti sotto un elemento flottante. I CSS hanno adottato il modello SSP per gli elementi flottanti, ma usano differenti nomi di propriet�.

Le tabelle in SSP sono ottenute classificando gli elementi in righe, celle e contenuto di tabella principale:

*TR.tablerow: true
*TD.tablecell: true
*TABLE.table: true

L'esempio di sopra correla gli elementi di tabella HTML alla formattazione di tabella di SSP.

Meccanismo di collegamento

SSP fornisce un modo di inserire i fogli di stile nei documenti. Si consideri questo esempio:

<DOCUMENT>
  <STYLE>
    *STYLE.stylesheet: true
  </STYLE>
</DOCUMENT>

Qui la regola all'interno dell'elemento STYLE dichiara che l'elemento STYLE contiene un foglio di stile. Per il parser, tuttavia, l'informazione della propriet� stylesheet giunge troppo tardi – per comprendere la regola di stile, il parser deve sapere che l'elemento contiene un foglio di stile.

La proposta considera i collegamenti ai fogli di stile esterni come al di fuori del proprio �mbito ma, nondimeno, descrive vari modi di collegamento. Le opzioni discusse sono:

• Nel tag LINK dell'HTML. Questo � insoddisfacente per diversi motivi: (1) � troppo tardi, il documento � gi� iniziato prima che il collegamento sia trovato; (2) non funziona per i documenti non-HTML.
• In una nuova riga dell'header del protocollo HTTP. È meglio, ma dipende dal fatto che si usi HTTP.
• Come parte di un documento MIME/multipart.
• Nell'URL. Una cattiva idea, non solo perch� lo stile non 'appartiene' realmente al documento, ma anche perch� l'URL diverrebbe troppo lungo.
• Altro modo: un ipercollegamento che contenga non l'URL del documento, ma del suo foglio di stile, che in caso si riferisce al documento (in una nuova propriet� 'document').
• Come attributo di A: <A HREF="doc.html" STYLE="doc.sty">

Contenuto generato

SSP supporta un semplice modo di aggiungere testo all'inizio o alla fine degli elementi. Si consideri questo esempio:

*Q.insertbefore: `
*Q.insertafter: '

Due propriet�, insertbefore e insertafter, contengono il testo da aggiungere. Non c'� modo di attribuire uno stile al testo generato diverso dal contenuto dell'elemento.

Altri contesti di formattazione

La proposta discute brevemente la possibilit� di supportare altri dispositivi di output, ma nessun meccanismo viene proposto.

SSP nel contesto

Sebbene SSP sia una proposta abbastanza breve e semplice, va oltre le altre proposte di fogli di stile per il Web in due settori. In primis, descrive un modello di formattazione relativamente sofisticato con tabelle, elementi flottanti e margini verticali minimi (in opposizione a quelli esatti).

In secundis, i fogli di stile SSP contengono informazioni non-stilistiche in misura maggiore rispetto agli altri linguaggi. Per esempio vengono rappresentate le informazioni sulla lingua del contenuto, il comportamento dei link, quale attributo contenga il valore ID, e se un elemento � vuoto o meno. In una certa misura, SSP sfida la DTD SGML fornendo una sintassi alternativa – e molto pi� semplice – per la stessa informazione.

SSP � manifestamente esiguo nel numero delle unit� suggerite. Le unit� sono legate alle propriet� e ai valori e, perci�, non hanno bisogno di identificatori di unit�. Le unit� di lunghezza si limitano agli em, lines e pixel.

L'autore di SSP, Bert Bos, in seguito si un� al W3C per lavorare con l'autore sui fogli di stile. SSP ebbe una forte influenza sullo sviluppo dei CSS.

Come SSFP, le specifiche SSP sono ancora disponibili all'URL originale.

PSL96

PSL � un linguaggio per specifiche di presentazione sviluppato da Ethan Munson e dal suo team presso l'universit� di Wisconsin-Milwaukee [Munson 1996] [Marden&Munson 1998]. Il linguaggio PSL � ispirato dal – e basato sul – linguaggio P discusso nel precedente capitolo. A differenza delle altre proposte descritte in questo capitolo, PSL non venne proposto per essere discusso sulle mailing list di www-talk. Al contrario, PSL, come P, fu descritto in pubblicazioni di ricerca, e le implementazioni vennero rese disponibili nella forma di una libreria di codice sorgente chiamata Proteus.

Il linguaggio PSL si evolse nel tempo. La descrizione iniziale di Proteus, in una pubblicazione del 1992 [Graham, et al. 1992], descriveva un linguaggio per schemi di presentazione ma non usava l'acronimo PSL. La sintassi di PSL nel 1992 era molto simile a quella di P, e la stessa sintassi � usata nella tesi di Munson del 1994 [Munson 1994]. Tuttavia, una pubblicazione del 1996 [Munson 1996] descrive una sintassi evoluta e PSL � proposto come linguaggio di stile per il Web. Per descrivere questo linguaggio dalle precedenti versioni, si far� riferimento ad esso come a PSL96. Un'altra pubblicazione del 1998 [Marden&Munson 1998] descrive ulteriormente PSL96 e fornisce esempi di codice. Inoltre il titolo della pubblicazione del 1998 (PSL: Un approccio alternativo ai linguaggi di stile per il World Wide Web) promuove PSL96 come linguaggio di stile per il Web.

Entrambe le pubblicazioni sono scritte in stile scientifico. Questo da ai lettori una panoramica del linguaggio, ma non serve a rendere tali documenti proposte complete. Per esempio, nessuna delle pubblicazioni fornisce un elenco delle propriet� proposte.

Sintassi

PSL96, nella sua forma pi� semplice, appare simile ai CSS. Ecco un semplice frammento:

H1 {
  fontSize: 20;
}

Questo sarebbe stato un valido foglio di stile CSS se la propriet� fosse stata font-size, e il valore avesse avuto un identificatore di unit� (per esempio px).

PSL96 usa le parentesi graffe per indicare i blocchi, mentre P94 usa le parole chiave begin e end. Come tale, PSL96 assomiglia al linguaggio di programmazione C mentre P94 si rif� a Pascal. La sintassi PSL96 � pi� facile da leggere ed � anche simile ai CSS.

L'esempio precedente non � in s� un foglio di stile completo. Un foglio di stile PSL96 consiste di quattro sezioni: HEADER, DEFAULT, ELABORATIONS, e RULES. Ecco un semplice foglio di stile con una sezione DEFAULT e RULES:

DEFAULT {
    lineHeight = Self.fontSize * 1.5;
}
RULES {
  P {
    fontFamily = "times";
    fontSize = 14;
  }
}

La regola nella sezione DEFAULT � applicata agli elementi se nessuna altra regola imposta il valore per lineHeight. La regola dice che l'interlinea � uguale alla dimensione del font dell'elemento stesso (Self) moltiplicata per 1.5. Questo � un esempio di restrizione che esprime una relazione tra due valori sullo stesso elemento. PSL96 pu� anche esprimere restrizioni tra valori su differenti elementi, e restrizioni geometriche tra box circostanti di differenti elementi. Le restrizioni geometriche hanno la loro sintassi:

LI {
   VertPos: Top = LeftSib . Actual Bottom;
}

L'esempio dice che la posizione verticale (VertPos) di un elemento LI � descritta da una restrizione: la parte superiore (Top) dell'elemento deve trovarsi nella stessa posizione di quella effettiva inferiore (Actual bottom) del fratello di sinistra LeftSib, ossia il fratello pi� vecchio). La distinzione tra posizioni effettive e specificate � una delle differenze tra P94 e PSL96.

Selettori

PSL96, come DSSSL e P93, usa semplici selettori del nome di elemento. Ecco un semplice esempio per attribuire uno stile ad un elemento A nel modo in cui Mosaic [Mosaic] visualizza i collegamenti:

A {
  fgColor = "blue";
  underlineNumber = 1;
}

In HTML, solo gli elementi A con attributo HREF sono collegamenti. Ci� pu� essere descritto in PSL96 aggiungendo un'espressione logica all'interno del blocco:

A {
  if (getAttribute(self, "href") != "") then
    fgColor = "blue";
    underlineNumber = 1;
  endif
}

Mentre le parentesi graffe marcano il blocco esterno, il blocco interno � marcato da parole chiave (then, endif).

Propriet�

PSL96 ha un concetto di schemi che possono variare da un media all'altro [Munson 1996]:

La grammatica per tutti gli schemi PSL � la stessa, ma i dettagli (tipi primitivi, attributi, e dimensioni) cambiano tra i media.

PSL96 non definisce un'insieme di propriet� (chiamati attributi nella precedente citazione) ma delega questa caratteristica agli schemi associati con un tipo di media [Munson 1996]:

Per esempio, il testo medio di Ensemble ha attualmente 15 attributi che controllano i font (FontFamily, Size, Bold, e Italic), la tratteggiatura (Hyphenate, MinHyph, MinLeft, MinRight), la giustificazione, l'indentazione, la spaziatura tra le righe, la visibilit�, il colore di primo piano e il colore di sfondo.

Il sistema Ensemble [Graham 1992] supporta anche i media video e graphics, che hanno le loro propriet�. Per esempio, graphics ha le propriet� StrokeWidth e Rotation [Munson 1996].

Valori e unit�

Come gi� descritto, PSL96 non descrive le propriet� ma lascia questo compito agli schemi di presentazione. Tuttavia, per questa discussione, l'autore della tesi presuppone che gli schemi di testo siano parte del linguaggio PSL96.

Ogni propriet� PSL96 accetta uno di questi valori: booleano, stringa, reale, o enumerazione specifica dell'applicazione. Il valore pu� essere esplicito, oppure pu� essere un'espressione che restituisce un valore.

I valori espliciti in PSL96 sono abbastanza generici. Alcuni esempi:

HTML {
  fontFamily = "times";
  fontSize = 14;
  fgColor = "black";
  visible = No;
}
H1 { 
  fontFamily = "helvetica";
  fontSize = 18; 
  visible = Yes;
}

PSL96 non supporta differenti unit� di lunghezza. Solo i numeri sono accettati come valori, ed � compito dell'applicazione interpretare il valore [Munson 2003].

Espressioni

Il linguaggio di espressione � ci� che rende i valori in PSL96 interessanti. Le espressioni in PSL96 si basano su P94, ma vanno oltre permettendo di descrivere restrizioni tra elementi arbitrari. Il formato delle espressioni �:

  <property> = <node expression> . <property>

Lo scopo dell'espressione di nodo � di identificare un elemento da cui ricavare un valore di propriet�. PSL96 fornisce un insieme di funzioni che possono essere combinate per formare un espressione di nodo: Parent, LeftSib, RightSib, FirstChild, LastChild, NthChild, Root, AncestorOfType, Creator, e AllChildren. Alcuni esempi:

P { fontSize = Root . fontSize }
UL { Width = AllChildren . Width }
TD { HorizPos: Left = LeftSib . Right }
P { fontSize = FirstChild(LeftSib(Parent)) . fontSize }

Il primo esempio imposta la dimensione del font degli elementi P uguale alla dimensione del font dell'elemento radice. Il secondo esempio rende la larghezza dell'elemento UL uguale a quella di tutti i suoi figli. Il terzo esempio fa si che il limite sinistro di un elemento TD sia uguale al limite destro del suo fratello di sinistra, visualizzando perci� gli elementi TD orizzontalmente. Il quarto esempio dimostra come le espressioni di nodo possano divenire complesse; gli elementi P sono impostati in modo da avere la stessa dimensione del font del primo figlio del fratello di sinistra del loro genitore.

Le espressioni PSL96 possono anche comprendere operatori matematici comuni a linguaggi di programmazione generici tra cui operatori aritmetici, di comparazione e booleani. Inoltre sono disponibili funzioni matematiche comuni (come min, max, e round) e funzioni trigonometriche. Ecco un esempio che impila gli elementi LI l'uno sulla parte superiore dell'altro, eccetto per l'elemento di mezzo che da inizio ad un nuovo livello di elementi impilati alla destra dell'elemento esistente:

LI {
   if (ChildNum(Self) == round(NumChildren(Parent) / 2 + 1)) then
      VertPos: Top = Parent.Top;
      HorizPos: Left = LeftSib.Left + Self.Width;
   else
      VertPos: Top = LeftSib.Actual Bottom;
      HorizPos: Left = LeftSib.Left;
   endif
}

Valori specificati contro valori effettivi

PSL96 riconosce la differenza tra valori specificati e effettivi e permette restrizioni geometriche per riferirsi ad entrambi. Si considerino queste due regole:

  UL { Width = AllChildren . Width }
  UL { Width = AllChildren . Actual Width }

Nella prima regola, la larghezza dell'elemento UL � impostata sulla larghezza specificata dei suoi figli (ossia non tenendo conto del loro contenuto). La seconda regola si riferisce alla larghezza effettiva dei suoi figli, che pu� essere minore, in quanto il contenuto degli elementi figli pu� non coprire l'intera larghezza specificata. Questo esempio mostra anche una differenza tra i modelli di formattazione di PSL96 e dei CSS: gli elementi a livello di blocco nei CSS copriranno, a meno che non venga specificato diversamente, l'intera larghezza del loro genitore senza badare al contenuto. Questo non sembra essere il caso di P94/PSL96.

Trasmissione di valore

PSL96 ha quattro meccanismi per la trasmissione di valore. In ordine discendente di precedenza, essi sono:

• restrizioni geometriche: le espressioni possono dichiarare restrizioni geometriche esplicite tra i riquadri e, con ci�, trasmettere i valori;
• regole predefinite esplicite: queste sono le regole elencate nella sezione DEFAULT del foglio di stile;
• regole predefinite implicite: nei casi in cui la regola predefinite esplicita fallisce o non esiste, verra� usata la regola predefinita implicita. Per esempio, la regola predefinita implicita pu� impostare le propriet� come ereditate usando una regola con la forma: Property = Partent . Property.

Modello di formattazione visuale

Il modello di formattazione visuale di PSL96 � simile a P94. Entrambi si basano su una gerarchia di riquadri rettangolari, alcuni dei quali corrispondono agli elementi nel documento sorgente.

Oltre alle possibilit� di P94, PSL96 pu� eseguire la resa out-of-order. Si pu� affermare che la resa out-of-order non � una caratteristica del modello di formattazione stesso ma, piuttosto, la trasformazione tra una struttura logica ed una presentazionale. Tuttavia, nel caso di PSL96, la formattazione out-of-order � cos� strettamente integrata nella geometria del modello di formattazione visuale da meritare una discussione in questa sezione.

Il ruolo dei linguaggi trasformazionali nel contesto dei fogli di stile � stato discusso nel Capitolo 2. I linguaggi di stile generalmente si possono dividere in due gruppi: quelli che sono linguaggi trasformazionali e quelli che sono basati sul flusso. Il maggior vantaggio dell'essere un linguaggio trasformazionale � che il contenuto pu� essere riordinato: il contenuto non deve essere presentato per essere ricevuto. Lo svantaggio sta nel fatto che la resa progressiva non pu� pi� essere supportata.

PSL96 � un interessante punto d'incontro tra linguaggi trasformazionali e linguaggi basati sul flusso. PSL96 supporta la presentazione out-of-order del contenuto senza divenire con questo un linguaggio pienamente trasformazionale. Ci� viene ottenuto inserendo sugli elementi delle restrizioni geometriche. Esempio:

<TABLE>
  <CAPTION>The table's caption</CAPTION>
  <TR><TD>1</TD><TD>2</TD></TR>
  <TR><TD>3</TD><TD>4</TD></TR>
</TABLE>

L'elemento CAPTION � il primo figlio di TABLE. In alcuni casi si pu� volere che la didascalia sia mostrata sotto il contenuto della tabella e questa presentazione si ottiene facilmente in PSL96:

CAPTION { VertPos: Top = Parent . Bottom }

Meccanismo di collegamento

Ogni foglio di stile PSL96 ha una sezione HEADER che dichiara il tipo di media descritto dal foglio di stile (gli esempi comprendono Text e Mosaic), il nome della veduta e il linguaggio del documento a cui si applica il foglio di stile. Ecco una sezione HEADER di esempio:

MEDIUM mosaic;
PRESENTATION links FOR html;

Nell'esempio, il tipo di media � Mosaic (che, in un certo periodo, era sinonimo di Web). Il nome della veduta � links e il foglio di stile si pu� applicare ai documenti HTML.

Contenuto generato

PSL96 ha un ricco supporto per il contenuto generato. Il modello di base � simile a P94, ma PSL96 usa nomi diversi e offre delle funzionalit� arricchite. Il contenuto generato viene detto elaborazioni dell'albero e viene descritto in una sezione del foglio di stile chiamata ELABORATIONS. Ecco un esempio:

ELABORATIONS {
  linebreak : Markup ("<BR>") {
    visible = Yes;
  }
  arrow : Markup ("<IMG src=arrow-grey.gif>") {
    visible = Yes;
  }
  url : Content (getAttribute(creator, "href")) {
    visible = Yes;
    fontSize = 12;
  }
}

A {
  if ( getAttribute(self, "href") != "" ) then
    visisble = Yes;
    fgColor = "blue";
    underlineNumber = 1;
    createRight (arrow, url, linebreak);
}

Il foglio di stile dell'esempio descrive una presentazione dei collegamenti in cui il contenuto dell'elemento A � mostrato in blu col testo sottolineato. L'ultima regola del foglio di stile crea un insieme di riquadri alla sinistra del testo del collegamento: prima una freccia, poi l'URL e quindi un'interruzione di riga. La freccia e l'interruzione di riga sono descritti inserendo della marcatura HTML nella struttura presentazionale. Il concetto di marcatura generata piuttosto che di contenuto generato conferisce a PSL96 una funzionalit� di norma associata con i linguaggi trasformazionali senza con questo divenire a sua volta un linguaggio trasformazionale.

Altri contesti di formattazione

Uno degli obiettivi alla base della ricerca di PSL � quello di ricercare come i fogli di stile possano essere usati per descrivere presentazioni su differenti media. (Il concetto � simile ai tipi di media nei CSS.) Munson [Munson 1994] descrive come il sistema Proteus sia stato adattato per tre differenti tipi di media: testo, grafica bidimensionale e video digitale. Per supportare un nuovo tipo di media, gli elementi di un media devono essere conosciuti. Secondo [Munson 1994], gli elementi di un tipo di media sono: l'insieme di tipi di oggetto primitivi, un insieme di dimensioni in cui gli oggetti sono rappresentati e un insieme di operazioni di formattazione parametrizzate. Questa idea � ulteriormente sviluppata in [Munson&Pfeiffer 1999], che definisce il linguaggio MSPEC per descrivere un tipo di media.

PSL96 nel contesto

Il linguaggio PSL96 fu sviluppato in un ambiente di ricerca per oltre dieci anni a partire dal 1990. Il linguaggio � strettamente correlato al linguaggio P (di cui viene descritta la versione del 1994 nel precedente capitolo). Esso riutilizza tutte le parti principali di P94.

PSL96 usa una sintassi pi� leggibile rispetto a P94. Sebbene non pienamente consistente, l'uso delle parentesi graffe in luogo delle parole chiave e dei due punti (abusato in P94) rende PSL96 un linguaggio pi� accessibile per gli umani. Inoltre PSL96 offre nuove funzionalit� rispetto a P94 e ad altri linguaggi di stile:

• PSL96 offre un linguaggio di espressione di nodo usato per dichiarare restrizioni tra elementi arbitrari. Questo permette ai fogli di stile PSL96 di presentare il contenuto fuori dall'ordine senza aver bisogno di un linguaggio trasformazionale. Tuttavia, la resa out-of-order rende difficile, se non impossibile, la resa progressiva.
• La maggior parte dei linguaggi di stile supporta il contenuto generato, ma PSL96 � il primo a proporre che il foglio di stile debba essere in grado di generare la marcatura. Questa caratteristica � un altro esempio di come PSL96 fornisca funzionalit� di solito associate con i linguaggi trasformazionali, senza essere realmente un linguaggio trasformazionale.
• PSL96 riconosce la differenza tra valori specificati ed effettivi e consente restrizioni geometriche per riferirsi ad entrambi.

In diverse pubblicazioni, PSL96 fu proposto come linguaggio di stile per il Web [Munson 1996] [Marden&Munson 1998] [Marden&Munson 1999]. Pur contenendo caratteristiche che risulterebbero utili nel contesto web, il linguaggio ha problemi che andrebbero risolti prima di poter essere implementato in modo interoperabile sul Web. Il problema pi� rilevante � che PSL96 � pi� un framework per definire linguaggi di stile per differenti media che un linguaggio di stile ben definito per il Web. PSL96 non ha un elenco di propriet� e valori definiti chiaramente da cui gli implementatori possano iniziare a lavorare. Ci� viene lasciato agli schemi dei tipi di media. It leaves this to media-type schema. Se lo schema text � considerato parte del linguaggio PSL96 (come nella precedente discussione), � il solo ad avvicinarsi ad una proposta completa.

Tuttavia permane il problema dell'estensibilit�. Una delle caratteristiche di PSL96 � che pu� essere esteso: le applicazioni client possono offrire accesso a funzionalit� che altrimenti non sono parte del linguaggio PSL96. Pi� spesso, tuttavia, l'estensibilit� va in conflitto con l'interoperabilit�, poich� un linguaggio estensibile risulter� in molti dei differenti profili d'uso. Un linguaggio di stile, che � generalmente usato per esprimere presentazioni non-vitali, si adatta forse meglio a differenti profili della maggior parte degli altri linguaggi. A mio avviso, tuttavia, sembra migliore l'idea di definire le funzionalit� nelle specifiche piuttosto che affidarle alle applicazioni.

Gli autori di PSL96 osservano [Munson 1996] che mentre vi � una lunga storia nella ricerca sugli editor di documenti strutturati, � stata fatta poca ricerca sui linguaggi di stile (o linguaggi di specifica della presentazione come li chiama PSL96). In un altro articolo [Marden&Munson 1999] questa idea � esposta con termini pi� forti: I linguaggi di stile sono terribilmente poco investigati. Sebbene PSL96 non abbia avuto grande uso al di fuori delle comunit� di ricerca, la ricerca portata avanti – e promossa – dal team di PSL � stata un significativo contributo alla comprensione dei linguaggi di stile.

Sommario e conclusioni

Nel periodo 1993-1996 nove differenti linguaggi di stile furono proposti per il Web, e l'HTML � il principale linguaggio per tutte le proposte. Con l'eccezione di PSL96, tutte le proposte erano abbastanza semplici sovrainsiemi o sottoinsiemi di linguaggi di stile sviluppati prima del Web. (PSL96 � un'eccezione perch� estende P94, piuttosto che semplificarlo.) Nessuno di questi linguaggi vide mai un uso reale sul Web, ma due di essi (CHSS e SSP) formarono la base per i CSS.

Questo capitolo ha esaminato le proposte secondo i criteri stabiliti nel precedente capitolo. Il prossimo capitolo illustra come tutti i linguaggi di stile sin qui esaminati, sviluppati prima del Web e per il Web, soddisfino i requisiti del Web.

Requisiti del Web

Nei precedenti due capitoli, i linguaggi di stile e le proposte sono stati valutati secondo i criteri stabiliti nel Capitolo 3. Queste analisi hanno stabilito che i linguaggi sono di fatto dei linguaggi di stile e che le proposte avrebbero potuto svilupparsi in altrettanti linguaggi di stile. Tuttavia, non si � valutato il grado di conformit� al Web di questi linguaggi. Questa valutazione � l'argomento di questo capitolo.

Caratteristiche del Web formulate come requisiti

Per valutare la conformit� all'uso sul Web si deve stabilire un insieme di requisiti. Sei caratteristiche chiave che possono influenzare lo sviluppo dei linguaggi di stile per il Web sono elencate nel Capitolo 1. Esse sono di seguito riviste e riformulate come requisiti per i linguaggi di stile del Web.

• Il later binding richiede fogli di stile basati sul flusso: Sul Web, il contenuto e il foglio di stile si combinano in presentazione solo in una fase molto tarda, ossia sul computer dell'utente. I browser web attuali usano la resa progressiva per visualizzare l'informazione quando questa viene scaricata dal Web, ed � importante che l'introduzione di un foglio di stile non rallenti la presentazione. Perci�, come requisito i fogli di stile devono essere applicati ai documenti all'atto del download. Una delle proposte esaminate deve il suo nome (Proposta di fogli di stile basati sul flusso) a questo requisito.
• La pubblicazione incentrata su schermo richiede il supporto per propriet�, valori e unit� basati su schermo: Stampa e schermo sono entrambi tipi di media visuali e possono riutilizzare molti degli stessi valori, propriet� ed unit�. Tuttavia, per ottimizzare le presentazioni per gli schermi di computer, � necessario il supporto a valori, unit� e propriet� extra. Per esempio, impostare lo sfondo di un elemento testuale � comune nei design basati su schermo, � un'unit� pixel � richiesta per assicurare che un bordo sia esattamente largo un pixel.
• L'influenza condivisa autore/utente richiede la negoziazione tra preferenze di stile in conflitto: L'aggiunta flessibilit� del later binding rende possibile sia agli autori che agli utenti di influenzare la presentazione, e sembra ragionevole rendere questo aspetto un requisito per i linguaggi di stile sul Web. Un modo di supportare la negoziazione presentazionale � quello di combinare i fogli di stile da fonti diverse.
• Output multipli richiedono fogli di stile specifici per il tipo di media: Il contenuto web � rappresentato su diversi tipi di dispositivi di output, e i fogli di stile devono essere in grado di esprimere le presentazioni su questa vasta gamma. Per esempio, vi sono propriet� per i media non-visuali? Le unit� sono adatte a differenti tipi di dispositivi di output? Da ultimo, il foglio di stile sa indicare che esso dovrebbe essere applicato solo ad alcuni tipi di media?
• I documenti ipertestuali richiedono uno stile per i collegamenti: Gli utenti si aspettano che i browser ricordino quei collegamenti che sono stati visitati. Un modo di differenziare i collegamenti ipertestuali visitati da quelli non visitati � quello di assegnargli uno stile diverso. Per presentare i collegamenti ipertestuali, il browser deve perci� usare l'informazione contenuta al di fuori del documento, ossia nei fogli di stile stessi.
• La distribuzione incerta richiede robustezza. Internet � un tipo di media incline al fallimento e i linguaggi di stile devono, come altri meccanismi web, essere sviluppati in questa mentalit�. Se un foglio di stile non pu� essere visualizzato, il contenuto dovrebbe essere tuttavia presentabile all'utente. La robustezza � perci� un requisito. Un modo di ottenere la robustezza � quello di avere valori di ripiego presentazionali ridondanti. I valori di ripiego devono andare oltre i semplici valori predefiniti per ogni propriet�. Per esempio, i valori predefiniti non sono in grado di distinguere tra elementi in riga o a livello di blocco.

Quando sono cominciate le discussioni sui linguaggi di stile, questi requisiti non sono stati formulati in uno scritto, come del resto accade quando si intraprendono nuovi sforzi verso la standardizzazione. Scrivere tali requisiti retrospettivamente permette che venga usata una maggiore esperienza nella loro formulazione. Chiamarli requisiti, tuttavia, pu� essere eccessivo. Infatti nessuno dei requisiti � assoluto nel senso che un linguaggio di stile pu� essere giudicato inadatto allorch� non vengano soddisfatti in pieno. Per esempio, � impossibile soddisfare l'ultimo requisito per documenti scritti in XML generico, dato che di norma il meccanismo di ripiego si basa su una conoscenza comune che, per definizione, non esiste per l'XML generico.

Inoltre si pu� dire che sia scorretto valutare i linguaggi di stile secondo requisiti per cui essi non sono stati sviluppati. Per esempio, i linguaggi di stile sviluppati prima del Web non hanno bisogno di un meccanismo per aumentare la robustezza, poich� il processo di formattazione non inizier� fino a che sia il documento che il foglio di stile sono disponibili. Perci�, si dovrebbe notare che un linguaggio di stile pu� essere perfettamente adatto per l'uso al di fuori del Web anche se i requisiti discussi in questo capitolo non vengono soddisfatti.

Allo scopo di questa tesi, tuttavia, � necessario e importante valutare i linguaggi di stile prima del Web e le proposte di linguaggi di stile per il Web secondo i requisiti del Web. Ci� viene fatto nella Tabella 16.

Come si pu� vedere nella Tabella 16, nessuno dei linguaggi di stile sinora esaminati soddisfa tutti i requisiti del Web. L'unico che pi� si avvicina � CHSS, che fallisce solo nello stile per i collegamenti. CHSS si svilupparono poi nei CSS e lo stile per i collegamenti fu aggiunto nel processo. I CSS sono l'argomento del prossimo capitolo e una valutazione dei CSS, simile alla Tabella 16, si trova nella Tabella 21.

Sommario e conclusioni

Il Web aggiunge diversi nuovi requisiti per i linguaggi di stile. Per aver successo sul Web un linguaggio di stile dovrebbe:

• essere basato sul flusso, in modo che il contenuto sia presentato progressivamente;
• supportare propriet�, valori e unit� basate su schermo;
• essere in grado di combinare fogli di stile multipli;
• supportare fogli di stile per media specifici;
• offrire uno stile per i collegamenti, in modo da distinguere tra quelli visitati e non visitati;
• essere robusto, nel caso in cui il foglio di stile collegato non appaia.

Si pu� dire che i requisiti aggiuntivi dati dal Web cambino la progettazione dei fogli di stile tanto che il termine fogli di stile non � pi� appropriato. Trovare un nuovo nome potrebbe far diminuire le tensioni tra le comunit� di sviluppo di linguaggi per il Web e di linguaggi concepiti prima di esso. Per ora, tuttavia, fogli di stile � stabilmente riconosciuto.

Nessuno dei linguaggi di stile prima del Web n� le proposte di linguaggi di stile soddisfano i requisiti sinora descritti. Per soddisfare tali requisiti, si doveva sviluppare un nuovo linguaggio di stile. Il prossimo capitolo descrive lo sforzo in tal senso.

Fogli di stile a cascata

Nei precedenti capitoli, sono stati descritti i linguaggi di stile prima del e per il Web. Tuttavia, come concluso nell'ultimo capitolo, nessuno di essi soddisfaceva i bisogni del Web. In questo capitolo i Fogli di stile a cascata sono presentati e valutati secondo gli stessi criteri usati per valutare gli altri linguaggi e proposte.

I CSS furono sviluppati in parte dall'autore della tesi, insieme con Bert Bos, i Gruppi di Lavoro W3C sull'HTML e CSS e la comunit� di www-style. Due delle proposte discusse nel Capitolo 4, CHSS e SSP, formarono la base per lo sviluppo dei CSS e molte persone diedero il loro contributo di idee lungo il cammino.

I CSS sono definiti nelle Raccomandazioni W3C. Il W3C ha avuto due specifiche CSS principali: i CSS1 furono rilasciati nel dicembre 1996, e i CSS2 nel maggio 1998. Entrambi i livelli si basano sulla stessa sintassi e i CSS1 (con eccezioni minori) sono un sottoinsieme dei CSS2. La discussione che segue si riferisce ai CSS2, tranne dove indicato diversamente.

Sintassi

I CSS usano una sintassi semplice. Esempio:

H1 { font-size: 2em }

La regola dell'esempio consiste di due parti principali: un selettore (H1) e una dichiarazione (font-size: 2em). La dichiarazione ha due parti: una propriet� (font-size) e un valore (2em). Sebbene l'esempio influenzi solo una delle propriet� usate per rendere un documento, esso � qualificato come foglio di stile. Combinato con altri fogli di stile, esso determiner� la presentazione finale del documento.

Diverse dichiarazioni possono essere raggruppate in un blocco di dichiarazioni:

BODY { 
  margin: 3em; 
  font-family: "Gill Sans", sans-serif;
}

Le dichiarazioni all'interno del blocco di dichiarazioni (racchiuso da parentesi graffe) sono separate da punti e virgola. L'ultima dichiarazione � facoltativamente seguita da un punto e virgola. La prima dichiarazione nell'esempio di cui sopra imposta il margine intorno all'elemento BODY su 3em. L'unit� em si riferisce alla dimensione del font dell'elemento. In questo caso, si avr� come risultato che i margini attorno all'elemento BODY siano tre volte pi� grandi della dimensione del font dell'elemento BODY. La propriet� margin � un esempio di propriet� abbreviata che imposta i valori per diverse propriet� individuali un'unica volta (in questo caso le propriet� individuali sono margin-top, margin-right, margin-bottom e margin-left).

La seconda dichiarazione nell'esempio precedente ha un elenco di famiglie di font separate da virgole come valore. Se il primo valore non pu� essere usato (ossia, se il font Gill Sans non � disponibile), si prover� col valore successivo, e cos� via. Solo alcune propriet� CSS accettano elenchi come valori.

I selettori possono essere raggruppati in elenchi separati da virgole:

H1, H2 { 
  font-weight: bold;
}

Nell'esempio precedente, il blocco di dichiarazioni si applica sia agli elementi H1 che H2.

Gran parte della logica dei CSS � espressa nei selettori. Ecco un esempio pi� ambizioso:

DIV.ingress P:first-line {
  text-transform: uppercase;
}

In parole semplici, la regola di cui sopra dice: la prima riga di tutti gli elementi P all'interno degli elementi DIV con classe ingress deve essere trasformata in lettere maiuscole. Selettori avanzati come questo sono descritti in maggior dettaglio di seguito.

Parsing compatibile nel futuro

Le specifiche CSS descrivono due tipi di grammatiche. In primis, esse descrivono le regole di parsing per il rispettivo livello di CSS (ossia CSS1 e CSS2). In secundis, esse descrivono una grammatica che � valida per tutti i livelli dei CSS: passati, presenti e futuri. Lo scopo del parsing compatibile nel futuro � quello di permettere a futuri livelli dei CSS di includere nuove funzionalit� assicurando al contempo che le vecchie implementazioni riescano ad analizzare [parse N.d.T.] i nuovi fogli di stile. La vecchia implementazione non comprenderà le nuove caratteristiche ma riconoscer� quelle parti del foglio di stile che non comprende.

Per rispettare la compatibilit� a ritroso, i futuri livelli dei CSS devono seguire certe regole quando aggiungono una nuova funzionalit�. I nuovi selettori, propriet� e valori possono essere facilmente aggiunti poich� le regole di parsing compatibili nel futuro istruiscono i parser a ignorare le regole con parti sconosciute. Ecco un esempio:

  :foo { color: red }
  P { foo: red }
  P { color: foo }
  P { color: blue }

Le prime tre regole non sono valide nei CSS1 e CSS2 (a causa, rispettivamente, del selettore, della propriet� e del valore). Le implementazioni conformi ai CSS1/CSS2 ignoreranno, grazie alle regole di parsing compatibili nel futuro, tutte le regole non valide e riprenderanno il normale parsing dopo la parentesi graffa di destra (}). L'ultima regola � valida e avr� il normale effetto.

Parole chiave-a

Le regole di parsing compatibili nel futuro consentono anche l'introduzione di costrutti pi� avanzati tramite le parole chiave-a. Una parola chiave-a inizia con un segno '@', immediatamente seguito dal nome della parola chiave. Le regole di parsing compatibili nel futuro affermano che una regola-a consiste di tutto quello che si trova fino al punto e virgola successivo (;) compreso, o fino al blocco successivo, qualsiasi cosa venga prima [CSS2 1998]. Questa regola consente l'introduzione di nuove strutture sintattiche nei CSS.

I CSS1 usano una parola chiave-a per importare un foglio di stile in un altro:

@import "mystyle.css";

I CSS2 usavano il meccanismo dell'estensione della parola chiave-a e aggiungevano quattro parole chiave-a:

@charset "ISO-8859-1"; 
@font-face {
  font-family: "Robson Celtic";
  src: url("http://www.example.com/fonts/rob-celt");
}
@page { 
  size: 8.5in 11in;
}
@media print {
  BODY { font-size: 10pt }
}

Le quattro parole chiave-a descrivono, rispettivamente il set di caratteri usato nel foglio di stile, le risorse di font scaricabili, i media impaginati e i fogli di stile dipendenti da un media specifico.

Lo scopo delle regole di parsing compatibili nel futuro � quello di assicurare che i futuri livelli dei CSS possano introdurre nuove caratteristiche senza compromettere le vecchie implementazioni.

Selettori

I CSS hanno un ricco insieme di selettori e gran parte della logica CSS pu� essere scritta nei selettori. Altri linguaggi, per esempio DSSSL, P94 e PSL96 hanno semplici meccanismi di selettori, ma espressioni pi� complesse.

Per esempio, quando si seleziona un elemento in base al suo tipo (NOTE nell'esempio seguente) e sull'esistenza di un attributo (WARNING), i CSS esprimono questo in un selettore:

NOTE[WARNING] { ... }

DSSSL, dal canto suo, metter� solo il tipo di elemento nei selettori e esprimer� il requisito di attributo all'interno di un asserzione if.

(element NOTE
   (if (not (node-list-empty? (attribute "WARNING")))
     ...
     ))

Due aspetti dei selettori CSS meritano un'ulteriore discussione: il concetto di selettori semplici contro selettori contestuali, e pseudo-selettori. Essi vengono discussi di seguito, seguiti da una panoramica dei selettori nei CSS1 e CSS2.

Selettori semplici e contestuali

I CSS1 distinguono tra selettori semplici e contestuali. Un selettore semplice seleziona un elemento in base al suo tipo e/o agli attributi, ma non in base alla posizione dell'elemento nella struttura del documento.

Di contro, un selettore contestuale seleziona un elemento in base alla sua posizione nella struttura del documento. Un selettore contestuale consiste di diversi selettori semplici.

Per supportare i selettori contestuali, i browser devono tenere uno stack degli elementi aperti in modo da valutare tutti i selettori semplici del selettore contestuale. Questo compito si complica ulteriormente quando un elemento � presente secondo la DTD ma i tag corrispondenti non compaiono nel documento. Per esempio, questo � spesso il caso dell'elemento BODY in HTML, e le implementazioni devono, perci�, conoscere la DTD HTML. La maggior parte dei primi browser web non tenevano uno stack degli elementi aperti e perci� non potevano supportare i selettori contestuali.

Una ragione per cui i relativamente avanzati selettori contestuali erano presenti nell'altrettanto relativamente semplice specifica CSS1 era per impostare i bordi intorno alle immagini cliccabili. Il browser Netscape supportava questa caratteristica attraverso estensioni proprietarie e si sent�, perci�, il bisogno che questo fosse un requisito anche dei CSS1. Ecco una citazione dall'Appendice A della Raccomandazione CSS1:

/* setting the anchor border around IMG elements
   requires contextual selectors */

A:link IMG { border: 2px solid blue }
A:visited IMG { border: 2px solid red }
A:active IMG { border: 2px solid lime }

Un altro motivo per cui i CSS1 richiedevano il supporto per i selettori contestuali era quello di aumentare la consapevolezza tra gli implementatori che i tag HTML rappresentavano la struttura del documento e non le istruzioni di formattazione.

Retrospettivamente, pu� essere stato un errore rendere i selettori contestuali come parte delle specifiche CSS1. Le implementazioni non supportarono questa caratteristica in modo interoperabile se non diversi anni dopo, e questo ritard� lo sviluppo dei CSS1. D'altro canto, con i selettori contestuali, i CSS contribuirono alla comprensione dell'HTML come di un linguaggio di marcatura strutturato.

I CSS2 estesero ulteriormente la gamma dei selettori contestuali. Si vedano le Tabelle 17 e 18.

Pseudo-elementi e pseudo-classi

I CSS1 introducono il concetto di pseudo-elementi e pseudo-classi con i loro peculiari selettori.

Il modello generale dei CSS � quello di legare propriet� di stile agli elementi trovati nel documento sorgente. Un foglio di stile CSS adorna l'albero sorgente con impostazioni stilistiche. Questo consente l'editing WYSIWYG del documento: le strutture sullo schermo corrispondono direttamente agli elementi nel documento sorgente.

Questo semplice sistema di correlazione tra elementi del sorgente e oggetti di visualizzazione, tuttavia, esclude alcuni comuni effetti tipografici cos� come alcuni effetti dinamici che si rivelano utili nei documenti interattivi. Per esempio, non vi � un elemento che corrisponda alla prima riga di testo cos� come viene formattata sullo schermo, e non vi � un attributo che descriva se un collegamento � stato visitato o no.

I CSS hanno due estensioni per risolvere questi problemi: pseudo-elementi e pseudo-classi. Uno pseudo-elemento � una parte di un elemento che non corrisponde ad un reale elemento nel documento sorgente, ma che corrisponde ad un oggetto di visualizzazione. Nei CSS1 vi sono due pseudo-elementi: la first-letter di un elemento e la first-line cos� come appaiono sullo schermo.

Le pseudo-classi riflettono il fatto che lo stesso elemento a volte deve avere uno stile differente, a seconda dell'informazione esterna che non si trova nel documento. Per esempio, un ipercollegamento � di solito visualizzato con uno stile diverso dopo che l'utente lo ha visitato, anche se nulla � cambiato nel documento sorgente. I CSS1 hanno tre pseudo-classi: link, visited e active.

Gli pseudo-elementi e le pseudo-classi permettono ad un designer di arricchire la struttura di un documento sorgente senza dover usare un linguaggio trasformazionale. I CSS2 hanno aggiunto nuove pseudo-classi e nuovi pseudo-elementi.

Selettori nei CSS1

La Tabella 17 da una panoramica dei selettori disponibili nei CSS1.

Selettori nei CSS2

In aggiunta ai selettori dei CSS1, I CSS2 hanno aggiunto diversi tipi di selettori. Si veda la Tabella 18.

I selettori aggiunti nei CSS2 conferiscono espressivit� e rendono i CSS applicabili a linguaggi diversi dall'HTML.

Propriet�

I CSS1 descrivono un insieme di base per la formattazione visuale. I CSS2 estendono tale insieme aggiungendo nuove propriet�, specie nelle aree delle presentazioni acustiche e per la stampa.

Per alcune propriet�, i CSS forniscono una sintassi abbreviata per impostare diversi valori in una sola dichiarazione. Esempio:

P { font: 10px/12px sans-serif }

In questo esempio, il valore di sei propriet� individuali (font-style, font-weight, font-variant, font-size, line-height, e font-family) sono impostate con l'uso di un'unica propriet� abbreviata (font). Il beneficio delle propriet� abbreviate � quello di ridurre la lunghezza dei fogli di stile rendendoli pi� leggibili. Inoltre le propriet� abbreviate forniscono un raggruppamento di propriet� (simile a FOSI) incoraggiando i designer a raggruppare i valori correlati.

Le propriet� abbreviate sono a volte criticate per il fatto di rendere pi� difficile la scrittura di parser. Lo '/' usato nell'esempio � preso dalla tipografia tradizionale, ma il carattere non � usato in altre propriet�. Perci�, i parser CSS devono aggiungere un codice speciale per gestire la sintassi delle propriet� abbreviate. Inoltre, con l'introduzione delle API del DOM [DOM1 1998] per la lettura/scrittura dei valori delle propriet� CSS, le propriet� abbreviate pongono un problema aggiuntivo.

La Tabella 19 elenca tutte le propriet� nei CSS1. Nella colonna dei valori, viene usata una sintassi formale per indicare la sintassi valida dei valori: Una barra (|) separa una o pi� alternative, ed esattamente una di esse deve essere presente; Una doppia barra (||) separa due o pi� opzioni; una o pi� di una devono essere presenti in qualsiasi ordine.

Significativo � il fatto che un gran numero di propriet� (22 su 53) descrivono i box intorno agli elementi (le aree di margine/bordo/padding). L'elevato numero risulta dall'avere propriet� separate per ogni area su ciascuno dei quattro lati del box [riquadro N.d.T.]. Inoltre gli stili e i colori del bordo possono essere descritti per ogni lato e vi sono propriet� abbreviate per impostare in una sola volta i margini, bordi e padding per tutti e quattro i lati.

In altre aree il numero delle propriet� CSS1 � tenuto al minimo. Per esempio, la propriet� background-position, che descrive una coppia di coordinate, � una propriet� singola. Come soluzione alternativa si sarebbe potuto scrivere (poniamo) background-position-x e background-position-y, aumentando il numero delle propriet�, e cos� i valori sulle propriet� individuali sarebbero stati pi� semplici da analizzare per un parser. Eliminando la propriet� abbreviata, il parsing dei CSS sarebbe divenuto pi� semplice ma i fogli di stile si sarebbero allungati con maggiore difficolt� nella scrittura.

Altre propriet� furono aggiunte nei CSS2 e la Tabella 20 elenca tutte le propriet� presenti nei CSS2 ma non nei CSS1. Inoltre vengono elencate le propriet� display e list-style-type, poich� i loro valori sono stati significativamente estesi nei CSS2.

Gran parte delle propriet� aggiunte ai CSS2 estendono il modello di formattazione visuale. Per esempio, le propriet� position e z-index aggiungono elementi posizionati in modo relativo e assoluto. Inoltre alcune propriet� sono state aggiunte per migliorare il supporto a determinati tipi di media, in particolare le presentazioni acustiche e di stampa.

Valori e unit�

I CSS offrono un ricco insieme di valori e unit�. In particolare, le unit� di lunghezza relative sono potenti. Vi sono sei tipi di valori di base:

• parole chiave: Tutte le propriet� accettano uno o pi� valori a parole chiave. La parola chiave inherit � accettata da tutte le propriet� CSS2 e la maggior parte delle propriet� ha anche altre parole chiave tra i valori accettati. Tra le parole chiave comunemente usate vi sono normal, none, auto, left, e right. I CSS evitano le parole chiave binarie (come yes/no e true/false) per lasciare pi� facilmente spazio a valori addizionali nel futuro.
• stringhe: Le stringhe sono racchiuse tra virgolette doppie o singole. I valori stringa si usano quando il namespace � illimitato e le parole chiave, perci�, sono troppo limitate. La differenza tra parole chiave e stringhe � resa confusa dal fatto che la propriet� font-family accetta nomi di font arbitrari senza richiedere virgolette attorno ad essi.
• numeri (per esempio 3): I numeri possono essere sia interi che reali. Alcune propriet� accettano solo valori interi (per esempio la propriet� orphan) mentre altre accettano sia numeri interi che reali (per esempio line-height).
• numeri con unit� (per esempio 3em): I numeri con unit� sono soprattutto usati per esprimere lunghezze, ma possono anche esprimere angoli (per esempio 90deg), misurazioni temporali (per esempio 10ms), e frequenze (per esempio 3kHz) per le propriet� acustiche. Le unit� di lunghezza sono descritte in dettaglio di seguito.
• percentuali (per esempio 30%): I valori percentuali sono simili alle unit� di lunghezza relative, nel senso che essi sono relativi ad un altro valore. Ogni propriet� che accetta un valore percentuale definisce anche a quale altro valore � relativa tale percentuale. La maggior parte dei valori percentuali si riferiscono alla larghezza dell'antenato di blocco pi� prossimo, ma alcuni si riferiscono anche ad altri valori, come per esempio la dimensione del font dell'elemento genitore. Per questo motivo, i valori percentuali sono stati accusati di essere inconsistenti e ci� viene discusso di seguito.
• funzioni (per esempio counter(chapter)): Alcune propriet� avanzate accettano una notazione funzionale per i valori. Questo � di solito il caso dei valori che si riferiscono ad un oggetto arbitrario oppure quando non � possibile (o naturale) usare un valore stringa. Per esempio, la propriet� content nei CSS2 usa una funzione per riferirsi al nome di un attributo. Il valore stringa non pu� essere usato a tale scopo, poich� le stringhe hanno un altro significato per questa propriet�.

Alcune propriet� accettano diversi valori, sia separati da spazio (nei casi in cui i valori sono complementari), sia separati da virgola (nei casi in cui i valori sono alternativi).

Unit� di lunghezza

Le unit� di lunghezza CSS possono essere classificate in assolute e relative.

Le unit� assolute sono:

• in: pollici
• cm: centimetri
• mm: millimetri
• pt: punti (nei CSS un punto � uguale a 1/72 di pollice)
• pc: pica (1 pica � uguale a 12 punti)

Le unit� relative sono:

• em: la dimensione del font dell'elemento corrente
• ex: la x-height del font dell'elemento corrente
• px: si riferisce ai pixel (si veda la discussione di seguito)

Nessuna delle unit� di lunghezza � peculiare dei CSS. La definizione dell'unit� px, tuttavia, � nuova. Sebbene px si riferisca al termine pixel, l'unit� � definita formalmente come un determinato angolo di visuale dalla prospettiva dell'utente, piuttosto che come la larghezza di un pixel. Il motivo di no usare la definizione pi� semplice ed ovvia sta nel fatto che la larghezza di un pixel varier� considerevolmente da un dispositivo all'altro. Inoltre, poich� la risoluzione dei dispositivi di output aumenta nel tempo, i fogli di stile non dovrebbero (idealmente) dover cambiare di conseguenza.

I CSS definiscono quindi un pixel di riferimento e prescrivono che i dispositivi di output, laddove le dimensioni dei pixel sono molto differenti, aggiustino l'unit� px di conseguenza. Il pixel di riferimento � l'angolo visivo di un pixel su un dispositivo con una densit� di pixel di 90 dpi, ed una distanza dal lettore della lunghezza di un braccio. Per una lunghezza nominale di un braccio pari a 28 pollici, l'angolo visivo � di circa 0.0227 gradi.

Le specifiche CSS incoraggiano l'uso delle unit� di lunghezza relative affermando che le unit� di lunghezza assolute sono utili solo quando le propriet� fisiche del media di output sono conosciute. Usando unit� di lunghezza relative, i documenti scaleranno meglio su differenti ambienti utente.

In un certo senso, la mancanza nei CSS di espressioni logiche (paragonati per esempio a DSSSL e P94) e le restrizioni generali (paragonate a PSL96) sono compensate dal repertorio di valori di lunghezza relativi. Tuttavia, i valori relativi sono stati criticati per il fatto di essere irregolari. Gli autori di PSL96 [Marden&Munson 1998] scrivono:

Quasi ogni propriet� CSS ha differenti regole per i valori posti sul lato destro del blocco di dichiarazioni, e non � esagerato dire che ogni propriet� ha un suo proprio linguaggio specializzato. Questo punto viene illustrato dalla propriet� line-height. Essa non accetta le parole chiave che possono essere usate con font-size e, inoltre, le percentuali sono interpretate come relative alla dimensione del font dell'elemento corrente, piuttosto che relative all'interlinea dell'elemento genitore. Per esempio, questa regola

  EM { line-height: 200%; }

specifica che l'interlinea per gli elementi EM dovrebbe essere due volte pi� grande della dimensione del font. Questo � un modo naturale di specificare l'interlinea, ma non � consistente con il trattamento delle percentuali in altre parti del linguaggio.

È corretto dire che i valori percentuali nei CSS si riferiscono a differenti valori. Per esempio, le percentuali possono riferirsi alla dimensione del font dell'elemento genitore (per esempio font-size), alla dimensione del font dell'elemento corrente (per esempio line-height), e alla larghezza del blocco contenitore (per esempio margin-left). Tuttavia, l'autore della tesi sosterr� che, molto spesso, i valori di riferimento sono la scelta giusta e che i limiti descritti limitation not has hindered, but rather helped, non hanno impedito, ma piuttosto aiutato gli autori a realizzare fogli di stile pi� facili da scrivere.

Trasmissione di valore

I CSS hanno tre meccanismi principali per la trasmisione di valore: cascata, eredit� e valori iniziali. Insieme, questi tre meccanismi assicurano che ogni combinazione di elemento/propriet� abbia sempre un valore.

La relativa forza dei tre meccanismi � differente. La cascata � il meccanismo pi� forte: se il processo di cascata produce un valore, esso verr� usato. Se la cascata non produce un valore (o produce il valore inherit) verr� usato il valore dell'elemento genitore. Il valore iniziale viene come terzo, e sar� usato solo se nessuno degli altri due meccanismi produce un valore (o se essi producono il valore iniziale).

Cascata

Il meccanismo di cascata nei CSS ha diversi aspetti e serve a diversi scopi. Questa sezione inizier� col descrivere il suo funzionamento di base, ossia come il meccanismo a cascata operi una scelta tra diverse dichiarazioni in conflitto per una data combinazione elemento/propriet�. Poi verranno discussi due modi diversi di usare il meccanismo a cascata di base: la risoluzione dei conflitti tra autori e utenti e la combinazione dei fogli di stile parziali con il foglio di stile predefinito del browser.

Il meccanismo a cascata di base

Quando pi� di una dichiarazione di stile cerca di impostare un particolare valore di propriet� su uno specifico elemento, il meccanismo a cascata prender� una sola dichiarazione vincente. La dichiarazione vincente avr� il pieno controllo del valore in questione. Il meccanismo a cascata in CHSS era differente; si propose di fondere diversi valori in un solo valore risultante.

La sfida � scegliere la dichiarazione giusta. Ogni volta che viene individuato un conflitto tra dichiarazioni, la dichiarazione vincente si trova comparando tre fattori: l'origine, la specificit�, e l'ordine di apparizione nel foglio di stile. I tre fattori sono ordinati nel senso che la specificit� � rilevante solo se l'origine non produce una dichiarazione vincente, e l'ordine � a sua volta rilevante solo se la specificit� non produce una dichiarazione vincente.

Vi sono tre possibili origini nei CSS: autore, utente e browser. Per impostazione predefinita, le dichiarazioni dell'autore vincono sulle dichiarazioni dell'utente, e le dichiarazioni dell'utente vincono su quelle del browser. Tuttavia, le dichiarazioni possono anche essere marcate come !important e vincono perci� su altre dichiarazioni. Nell'esempio seguente, la prima dichiarazione vincer� sulla seconda perch� � marcata come !important:

H1 { 
  font-size: 3em !important;
  font-size: 2em; 
}

Se marcate come !important, le dichiarazioni dell'utente vincono su quelle dell'autore, dando perci� agli utenti l'ultima parola sulla presentazione dei documenti.

L'apparentemente semplice soluzione tecnica descritta in precedenza ha causato non pochi problemi nella storia dei CSS. Mentre la bozza iniziale CHSS descriveva un modello dove gli utenti avrebbero mantenuto il controllo, le prime bozze CSS contenevano un costrutto !legal che dava agli autori l'ultima parola [CSS draft1 1995]. La logica alla base di !legal era che vi erano situazioni in cui gli autori erano di norma obbligati a presentare il contenuto in un determinato modo. Capendo che i CSS non avrebbero mai potuto garantire nulla sulla presentazione finale del contenuto, il costrutto !legal fu rimossso nei CSS1. Tuttavia all'autore era ancora data l'ultima parola, poich� le sue dichiarazioni marcate !important vincevano, nei CSS1, sulle dichiarazioni dell'utente a loro volta marcate !important. Dopo un'intensa discussione all'interno del Gruppo di Lavoro sui CSS, l'ordine fu cambiato nei CSS2 in modo che l'utente avesse di nuovo l'ultima parola. In pratica, il cambiamento ha avuto scarso effetto sulla presentazione dei documenti, poich� il costrutto !important non � ampiamente usato, ma dare comunque agli utenti l'ultima parola fu un cambiamento importante che sottolinea la differenza tra il Web e gli ambienti di pubblicazione tradizionali.

Se l'origine non produce una dichiarazione vincente, si deve calcolare la specificit� del selettore associato con le dichiarazioni. Si consideri questo esempio:

* { color: silver }
LI { color: red }
UL LI { color: blue }
LI.warning { color: green }

Le quattro dichiarazioni nell'esempio precedente hanno ciascuna un selettore associato. Il primo selettore (*) � il pi� generale: seleziona tutti gli elementi nel documento ed � chiamato selettore universale. È intuitivamente chiaro che il secondo selettore � pi� specifico del primo poich� seleziona solo gli elementi LI. Gli ultimi due selettori selezionano ciascuno un sottoinsieme di elementi LI; uno seleziona gli elementi LI con un attributo warning, e l'altro seleziona gli elementi LI con un antenato UL. Non � intuitivamente chiaro quale di questi selettori abbia la specificit� pi� alta.

I CSS descrivono una formula per calcolare la specificit� dei selettori:

• si conti il numero di attributi ID nel selettore (= a)
• si conti il numero degli altri attributi e pseudo-classi nel selettore (= b)
• si conti il numero dei nomi di elemento nel selettore (= c)
• si ignorino gli pseudo-elementi.

Concatenando i tre numeri a-b-c (in un sistema numerico a base ampia) si ha la specificit�. Per il selettore OL LI, i valori sono: a=0, b=0, c=2, e la specificit� � 2. Per il selettore LI.warning, i valori sono: a=0, b=1, c=1, e la specificit� � perci� 11.

Se pi� dichiarazioni in conflitto hanno al stessa specificit�, l'ordine in cui le dichiarazioni appaiono nei fogli di stile determina infine il vincitore. Le dichiarazioni successive vincono su quelle precedenti.

Fonti multiple: fogli di stile dell'utente contro fogli di stile dell'autore

Nel suo ruolo pi� controverso, il meccanismo a cascata serve come negoziatore tra utente ed autore. Il ruolo � controverso, poich� si crede spesso che i due gruppi abbiano interessi opposti; agli utenti piacerebbe mantenere il controllo finale sulla presentazione, e cos� pure gli autori (o ai loro rispettivi curatori e editori). Questo � un punto di vista semplicistico, e per due motivi. In primis, la maggior parte degli utenti � felice di accettare la presentazione suggerita dall'autore. Spesso infatti la presentazione � un'importante parte dell'esperienza di lettura offerta dalla pubblicazione, e non un mero contenitore posto intorno al contenuto. In secundis, sul Web utenti e autori non sono due gruppi distinti. Il Web ha abbassato la soglia della pubblicazione e molti utenti sono anche autori e viceversa.

Tuttavia, vi sono situazioni in cui gli autori e gli utenti hanno interessi diversi e opposti. Un esempio sono le clausole nei contratti; il testo deve esserci per ragioni legali, ma l'autore non vuole necessariamente portarlo all'attenzione dell'utente. L'utente, d'altro canto, pu� essere particolarmente interessato a leggere quello che l'autore vuole nascondere.

Diversi browser supportano i fogli di stile definiti dall'utente e sono in grado di combinare questi ultimi con i fogli di stile dell'autore. Tuttavia, pochi utenti scrivono i loro fogli di stile. Ci sono probabilmente diversi motivi per questo: il meccanismo non � stato promosso; scrivere fogli di stile � una sfida per la maggior parte delle persone; ed � quasi impossibile scrivere un solo foglio di stile utente che si adatti bene alla cascata delle pagine dell'autore. L'ultimo problema pu� essere affrontato consentendo l'uso dei fogli di stile utente su una base per-sito e per-pagina. L'onere di scrivere fogli di stile per tutti i siti e le pagine possibili pu� essere troppo grande per un singolo utente, ma � possibile per gli utenti condividere i fogli di stile, per esempio su una base peer-to-peer.

Il meccanismo a cascata non � necessariamente legato ai fogli di stile CSS. Ossia, un browser pu� offrire un modo all'utente di impostare una preferenza (per esempio la dimensione del font preferita) attraverso una sintassi da interfaccia utente grafica (GUI) usando al contempo il meccanismo a cascata per risolvere i conflitti tra le impostazioni dell'utente e (poniamo) i fogli di stile dell'autore. Dando alle preference dell'utente un posto ben definito nella cascata, i browser possono offrire una prevedibile risoluzione dei conflitti.

Negoziare tra utenti e autori pu� essere l'uso meglio conosciuto del meccanismo a cascata, ma tale uso � raro se paragonato ad un altro ruolo di negoziazione: combinare i fogli di stile degli autori con il foglio di stile predefinito del browser.

Combinare fogli di stile parziali con il foglio di stile predefinito del browser

Oltre ai fogli di stile degli autori e dei lettori, i CSS riconoscono una terza fonte di informazioni di stile, ossia il browser. Un browser che supporta i CSS ha un foglio di stile predefinito che si combina con i fogli di stile dell'autore e/o del lettore. Fogli di stile d'esempio sono elencati nelle specifiche CSS e – con qualche variazione minore – le implementazioni usano i fogli di stile d'esempio. In questo modo, i fogli di stile degli autori/utenti non devono essere completi, ma possono essere parziali. Autori e utenti possono concentrarsi nella descrizione delle differenze tra la presentazione convenzionale (come descritta nel foglio di stile predefinito) e la presentazione preferita.

Combinare i fogli di stile degli autori con il foglio di stile predefinito del browser � una caratteristica ampiamente usata della cascata. Una significativa precentuale di documenti sul Web usa attualmente i CSS, ma pochi dei fogli di stile usati sono completi. Cos�, essi si rifanno al meccanismo a cascata per combinare il foglio di stile parziale dell'autore con il foglio di stile predefinito del browser per ottenere una presentazione completa.

I browser gi� facevano questo, ad un livello molto semplice, prima che i CSS fossero proposti nel 1994. Per esempio, gli utenti di XMosaic poyevano modificare la presentazione dei documenti usando le risorse X11. Combinati con un foglio di stile HTML incorporato nel browser, essi formavano la presentazione dei documenti.

Si pu� dire che tutti i linguaggi di stile supportano la nozione di fogli di stile parziali poich� tutti usano i valori iniziali e l'eredit�. Questi due meccanismi rendono possibile abbreviare i fogli di stile e, perci�, renderli parziali. Il meccanismo a cascata, tuttavia, � pi� potente poich� i valori possono essere impostati sui tipi di elemento piuttosto che su una base per-propriet�. Questo � un importante aumento di funzionalit� su cui gli autori web devono fare affidamento. Per esempio, il suggerito foglio di stile predefinito per l'HTML [CSS2 1998] comprende una regola che rende gli elementi STRONG con font in grassetto. Poich� il foglio di stile dell'autore si combina col foglio di stile predefinito del browser, l'autoe non deve specificare la resa degli elementi STRONG in tutti i fogli di stile. Similmente, se il colore del testo � il solo problema importante per l'autore, essere sollevati dal dover specificare il valore della propriet� display per ogni elemento � certamente utile.

Eredit�

Come in DSSSL, le propriet� CSS sono classificate come ereditate o non-ereditate. I DSSSL e i CSS concordano soprattutto su quali propriet� sono ereditate. Tutte le propriet� CSS accettano la parola chiave inherit che specifica esplicitamente che il valore deve essere preso dal genitore. Se inherit � specificato sull'elemento radice, viene usato invece il valore iniziale.

I CSS distinguono tra valori specificati, calcolati ed effettivi. I valori specificati si trovano nei fogli di stile. I valori calcolati vengono elaborati nella misura possibile senza rappresentare il documento. I valori effettivi sono quelli realmente usati per rendere il documento. Come regola generale, � il valore calcolato di una propriet� ad essere ereditato. Le propriet� possono, tuttavia, specificare che altri tipi di valori devono invece essere ereditati. Per esempio, la propriet� line-height eredita il valore specificato se � un numero.

Valore iniziale

Ogni propriet� CSS ha un valore iniziale che diviene valore risultante se la cascata e l'eredit� non producono un valore. Inoltre il valore iniziale pu� essere esplicitamente specificato con la parola chiave initial che tutte le propriet� accettano.

Modello di formattazione visuale

Questa sezione offre uno sguardo complessivo, e la ratio che ne � alla base, del modello di formattazione visuale CSS (VFM) [Visual Formatting Model, N.d.T.]. Per una maggiore leggibilit�, vengono fatti due presupposti per semplificare la descrizione. In primis, si presuppone che il linguaggio del documento sia scritto orizzontalmente, sia da sinistra a destra (per esempio la scrittura latina), sia da destra a sinistra (per esempio l'arabo e l'ebraico). Il secondo presupposto � che il dispositivo di output sia continuo, in opposizione ai media impaginati. Il modello di pagina nei CSS � descritto nella sezione Altri contesti di formattazione in questo capitolo.

Sebbene l'accesso non visuale ai documenti � stato importante nello sviluppo dei CSS, la maggior parte della gente – se pu� scegliere – preferisce le presentazioni visuali del testo a quelle non-visuali. Senza un potente modello di formattazione visuale i CSS non avrebbero avuto successo.

Nel processo di sviluppo che port� al VFM dei CSS c'erano diversi requisiti. Sebbene non fossero stati specificati prima che iniziasse il lavoro sul VFM, essi sono stati formulati retrospettivamente.

• Il VFM deve offrire agli autori una ricchezza visuale che vada oltre quella raggiunta usando il solo HTML.
• Per convincere i produttori di browser ad implementare i CSS, il VFM deve essere abbastanza semplice da poter essere implementato entro tempi di scadenza ben definiti.
• Il VFM deve supportare la resa progressiva.
• Il VFM deve essere implementabile su un'ampia gamma di dispositivi visuali.
• Il VFM deve supportare dispositivi di output dinamici ( come schermi di computer e proiettori) cos� come dispositivi di output statici (come le stampanti).
• Il VFM dovrebbe essere in grado di replicare comuni effetti tipografici. Idealmente, si dovrebbe essere in grado di prendere qualsiasi libro o rivista e scrivere un CSS per ottenere lo stesso layout.
• I requisiti di conformit� del VFM devono essere abbastanza specifici da produrre risultati consistenti in differenti browser.
• I requisiti di conformit� del VFM devono essere abbastanza elastici da consentire le implementazioni su dispositivi visuali meno ricchi. Per esempio, i dispositivi tty [teletypewriter, N.d.T.] dovrebbero essere in grado di supportare i margini.

In un certo senso questi requisiti sono in conflitto. Ci sono tre assi principali: semplicit� contro ricchezza, pixel-perfection contro estensione del dispositivo, e obiettivi a breve termine contro obiettivi a lungo termine. Come nella maggior parte dei design, il VFM CSS � un compromesso tra obiettivi in conflitto.

Creare box dagli elementi

Il modello di elaborazione CSS [CSS2 1998] descrive come i documenti vengono elaborati da quando sono scaricati in un browser fino a quando sono presentati in un dispositivo di output. Il processo riguarda cinque fasi distinte:

1. analizzare il documento, creare un albero del documento
2. identificare il tipo di media
3. reperire i fogli di stile
4. annotare ogni elemento
5. generare la struttura di formattazione

In pratica, le implementazioni possono ottimizzare l'elaborazione eseguendo diverse fasi in parallelo.

I vari box [riquadri, N.d.T.] che formano la presentazione del documento sono creati nella fase 5 del processo. L'insieme di box viene definito struttura presentazionale. Spesso la struttura presentazionale assomiglier� all'albero del documento creato nella fase 1. Per i documenti semplici pu� anche esserci una correlazione uno-a-uno tra elementi e box, ma la correlazione � di solito pi� complessa per diversi motivi:

• un elemento in riga che si estende oltre la fine della riga deve essere diviso in diversi box;
• similmente, gli elementi di blocco sono spesso divisi in due box nelle interruzioni di pagina;
• gli elementi possono essere dichiarati come non visualizzabili (ossia, mentre esistono nella struttura logica, essi non esistono nella struttura presentazionale);
• I fogli di stile CSS2 possono specificare contenuto generato in aggiunta al contenuto dell'albero del documento. Per esempio, il foglio di stile pu� specificare che la stringa Capitolo: sia aggiunta davanti a tutti gli elementi H1. Il contenuto generato generer� i propri box.

Supportando il contenuto soppresso e quello generato, i CSS sono in grado di supportare processi simili a quelli trasformazionali. Tuttavia, essendo basati sul flusso, i CSS non sono in grado di riordinare gli elementi. Come discusso nel Capitolo 2, altri linguaggi di stile hanno intrapreso una strada diversa, basando la formattazione su un linguaggio trasformazionale completo.

Il box model

Un modello di box rettangolari annidati forma la base del VFM. Nella sua forma pi� semplice, ogni elemento nel documento sorgente viene trasformato in un box di blocco o in riga nel dispositivo di output. Il contenuto del box � sia testuale che grafico, e attorno al contenuto vi sono tre fasce: padding, bordo e margine. Si veda la Figura 4.

Aggiungendo padding o margine intorno ad un elemento, lo si separer� dal contenuto visuale e sar� cos� enfatizzato. Similmente, aggiungendo un bordo si far� risaltare l'elemento. La larghezza di ciascuna delle tre fasce pu� essere regolata su una base per-lato. In questo modo 12 propriet� individuali e 6 propriet� abbreviate possono essere impostate su ogni elemento. In pratica sono relativamente pochi gli elementi che usano le caratteristiche fornite, e perci� pu� sembrare eccessivo supportare 18 propriet� su tutti gli elementi.

Vi sono diversi design alternativi che avrebbero potuto mantenere il box model CSS pi� semplice:

• Supportando solo una fascia per elemento, il numero delle propriet� si sarebbe potuto ridurre con un fattore di 3. Lo svantaggio di questo approccio � che i design con diverse fasce avrebbero richiesto elementi annidati nel documento sorgente. Questo era l'approccio preso nelle prime bozze CSS nel luglio 1995 [CSS draft1 1995] [CSS draft2 1995].
• Il supporto a tre fasce si sarebbe potuto limitare agli elementi a livello di blocco. Gli elementi in riga si sarebbero potuti semplificare supportando solo una fascia. Questo approccio fu seguito nelle prime bozze CCC dall'agosto al novembre 1995 [CSS draft3 1995] [CSS draft4 1995] [CSS draft5 1995] [CSS draft6 1995].
• Le fasce si sarebbero potute trattare come contenuto generato. Ossia gli elementi non avrebbero di norma avuto fasce attorno ad essi, ma una o pi� fasce si sarebbero potute generare su richiesta. I CSS1 non supportano il contenuto generato, e quindi questo approccio non venne seguito.

Nei CSS1, tuttavia, le tre fasce possono essere impostate su tutti gli elementi. Ai designer viene dato perci� un potente meccanismo per definire gli elementi. Poich� sono relativamente pochi gli elementi che usano padding, bordi e margini diversi da zero, i browser possono ottimizzare il modo con cui queste propriet� vengono rappresentate internamente.

Box di base: a blocco e in riga

Due dei fondamentali elementi costitutivi di un documento sono box in riga e a blocco. I box in riga non generano interruzioni di riga, mentre i box a livello di blocco si. Per esempio, i box a livello di blocco sono usati per generare paragrafi ed intestazioni, mentre i box in riga vengono adoperati per il testo enfatizzato e gli ipercollegamenti. Entrambi i tipi di box usano il medesimo box model a tre livelli descritto in precedenza, ma alcune regole per rappresentare i box sono differenti.

Per gli elementi di blocco, il limite esterno dell'area di margine definisce la dimensione dell'elemento a scopo di layout. Ossia, gli elementi di blocco adiacenti saranno spostati di lato per fare spazio ad un elemento in base al limite del suo margine. Come regola speciale, le aree di margine possono collassare (ossia sovrapporsi) verticalmente per non creare una distanza verticale eccessiva tra i box. In questo modo l'ampiezza del margine rappresenta lo spazio verticale minimo tra elementi adiacenti.

I valori dei margini possono anche essere negativi, avendo come risultato la sovrapposizione degli elementi. Questa caratteristica pu� essere usata per creare speciali effetti, ad esempio negli annunci pubblicitari. A causa delle variazioni nella disponibilit� e nella metrica dei font, � difficile prevedere il risultato visuale della sovrapposizione degli elementi testuali, e perci� questa caratteristica non ha molto uso. Inoltre gli elementi posizionati (si veda di seguito) forniscono un altro modo di far sovrapporre gli elementi tra loro.

I box in riga sono rappresentati in modo differente. Per preservare una spaziatura dell'interlinea uniforme, impostare padding/bordo/margine non influenzer� il layout verticale dei box in riga. Ossia, il padding e il bordo saranno visibili, ma essi non sposteranno di lato altro contenuto. Il margine �, per definizione, trasparente e perci� non avr� nessun effetto in verticale. In orizzontale, di contro, le tre aree occuperanno spazio.

Formattazione outside-in contro formattazione inside-out

Un'altra differenza tra box di blocco e in riga sta nel modo con cui viene calcolata la loro larghezza ed altezza. Se non specificata esplicitamente, la larghezza di un box di blocco si estender� fino a coprire tutto lo spazio orizzontale. Verticalmente l'altezza � determinata dal suo contenuto. Ossia, i box di blocco usano un calcolo della larghezza outside-in e un calcolo dell'altezza inside-out. L'elemento radice � limitato orizzontalmente dal blocco contenitore iniziale (ICB) [Initial Containing Block, N.d.T] che di solito corrisponde alla larghezza della finestra o della superficie di stampa.

La larghezza di un box in riga �, invece, definita dal suo contenuto. Ossia, il box sar� largo per far spazio al contenuto, ma non pi� largo del necessario. Se c'� bisogno di ulteriore spazio, si possono usare padding/bordi/margini per creare pi� spazio, ma la larghezza del box non pu� essere cambiata. I calcoli dell'altezza degli elementi in riga si basano spesso sul contenuto del box ma, di solito, i box in riga sono leggermente pi� alti del testo al loro interno. Una lettura confortevole richiede pi� spazio verticale tra le righe di quello che i font stessi contengono. Perci�, i CSS hanno introdotto una propriet� separata (detta line-height) per impostare l'altezza dei box in riga. Solitamente il valore di line-height � un fattore che, se moltiplicato con la dimensione del font, produce l'altezza del box in riga. Quandi sia la larghezza che l'altezza sono calcolati in modo inside-out, la larghezza sempre, l'altezza di solito.

Oltre il box model di base

Oltre ai box di base di blocco e in riga discussi in precedenza, i CSS hanno diversi tipi di box che estendono il modello di formattazione visuale:

• Box flottanti: si pu� far flottare un elemento sul limite destro o sinistro del suo blocco contenitore. La caratteristica pi� interessante di un box flottante � che il resto del contenuto fluisce lungo il suo lato.
• Box marcatori: I marcatori di lista sono posizionati all'interno dei box marcatori. Nei CSS1, i box marcatori sono generati automaticamente e non possono essere posizionati o dimensionati.
• Box run-in: Questi box furono introdotti nei CSS2 per supportare le intestazioni run-in, ossia elementi di blocco dove l'intestazione � integrata nel primo paragrafo. Le intestazioni run-in possono essere espresse anche nei CSS1, ma qui � richiesto un elemento contenitore extra intorno all'intestazione e al primo paragrafo. Avendo definito run-in come un box speciale, non si deve cambiare la marcatura pre ottenere l'effetto tipografico.
• Box compatti: Furono introdotti nei CSS2 soprattutto affinch� l'attributo compact degli elementi UL, OL e DL potesse essere deprecato in HTML4 [HTML4 1997]. L'effetto tipografico di un elemento compatto � che il box corrispondente � posizionato nel margine del successivo elemento di blocco, se possibile. Questo tipo di formattazione � spesso usato nei dizionari per preservare lo spazio verticale. A differenza dei box run-in, non c'� un modo di ottenere l'effetto tipografico dei box compatti con altri mezzi.
• Box posizionati in modo assoluto: Questi box vengono estratti dal flusso normale e posizionati in relazione al loro blocco contenitore. La loro posizione e dimensione � determinata dalle seguenti propriet�: top, right, bottom, left, width, height. Se le dimensioni di un box posizionato in modo assoluto sono sotto-specificate, i principi della formattazione inside-out verranno usati per determinare le sue dimensioni.
• Box posizionati in modo fisso: Questi box sono come i box posizionati in modo assoluto, con la differenza che essi usano l'area di visualizzazione come riferimento per il posizionamento (invece del blocco contenitore). In questo modo, alcuni elementi possono rimanere sullo schermo mentre il resto del documento scrolla.
• Box posizionati in modo relativo: Una volta che un box viene rappresentato secondo il normale flusso, esso pu� venire spostato in relazione alla sua posizione con le propriet� top/right/ bottom/left.
• Box di pagina: Per migliorare la stampa delle pagine web, il VFM ha aggiunto il concetto di box di pagina per consentire di specificare margini di pagina, intestazioni correnti e pi� di pagina.
• Tabelle: Le tabelle sono estesamente usate a scopo di layout sul Web. La maggior parte delle pagine che usano le tabelle potrebbero essere migliorate usando il float e gli elementi posizionati in luogo delle tabelle, ma le tabelle hanno anche un uso legittimo nei documenti. I CSS2 hanno introdotto il supporto alle tabelle prendendo in prestito il modello di tabella HTML e aggiungendo ulteriori caratteristiche presentazionali.

Ispirazione da altri modelli di formattazione

Nelle prime fasi di design del VFM CSS, furono spesso consultati altri modelli di formattazione come ispirazione. In particolare, TeX [Knuth 1984] venne spesso portato nelle discussioni.

Tra i suoi fondamenti, TeX ha un box model ben definito dove tutti gli oggetti, inclusi i glifi individuali, sono contenuti in box. Lo spazio tra i box pu� essere controllato con comandi TeX. Oltre alla spaziatura ottimale tra i box, TeX pemette anche di esprimere la spaziatura minima e massima. Questo viene definito colla (sebbene Knuth suggerisce che salti sia un termine migliore [Knuth&Plass 1981]).

Il VFM nei CSS si basa su un box model, e tutti gli elementi, di blocco e in riga, vengono trasformati in box. I CSS vanno cos� oltre gli altri linguaggi di stile nella creazione di box. Per esempio, DSSSL e P94 non usano i box per gli elementi in riga. Tuttavia, i CSS non adottarono la colla di TeX. Sebbene il problema fosse stato discusso, si decise in modo contrario per mantenere semplice il VFM. La colla � molto utile quando si segmentano i paragrafi in righe, ma i CSS lasciano questo problema alle implementazioni. I CSS consentono, ma non richiedono, le ottimizzazioni delle interruzioni di riga tra paragrafi. Ogni box CSS, tuttavia, � potenzialmente pi� ricco dei box di TeX, poich� pu� contenere fasce di padding, bordo e margine. I CSS prendono in prestito anche altre caratteristiche da TeX, tra cui le unit� em ed ex.

FrameMaker [FrameMaker], un'applicazione per la pubblicazione desktop in seguito acquistata da Adobe, venne inoltre consultato nello sviluppo dei CSS. L'autore della tesi cominci� ad usare FrameMaker nel 1987 e tra le caratteristiche prese in prestito vi � il concetto dei margini verticali collassati.

Meccanismo di collegamento

Quando i CSS1 divennero una Raccomandazione W3C nel 1996, le specifiche HTML di allora [HTML2 1995] non specificavano come collegare i documenti HTML ai fogli di stile. Formalmente era oltre l'�mbito delle specifiche CSS definire il meccanismo di collegamento, ma i CSS1 mostravano un semplice esempio di come potesse essere fatto:

<LINK REL=STYLESHEET TYPE="text/css" 
   HREF="http://style.com/cool" TITLE="Cool">
<STYLE TYPE="text/css">
   @import url(http://style.com/basic);
   H1 { color: blue }
</STYLE>

Gli elementi LINK e STYLE furono in seguito aggiunti ad HTML4 [HTML4 1997] insieme con l'attributo STYLE:

<H1 STYLE="color: blue; background: red">

Oltre a descrivere come collegare i fogli di stile ai documenti HTML, i CSS2 descrivono anche come collegare documenti XML e fogli di stile:

<?XML stylesheet type="text/css" href="bach.css"?>

Ancora: � fuori dall'�mbito dei CSS definire formalmente il collegamento ed una Raccomandazione W3C [XML-stylesheet 1999] fu in seguito pubblicata per questo scopo.

Contenuto generato

Il contenuto generato fu introdotto nei CSS2. Il contenuto pu� essere aggiunto prima e dopo gli elementi nel documento. Ci� viene fatto impostando la propriet� content per gli pseudo-elementi :before e :after. Ecco un semplice esempio che aggiunge la stringa Chapter: prima di ogni elemento H1:

H1:before { 
  content: "Chapter: ";
  font-style: italic;
}

Nell'esempio il contenuto generato ha anche uno stile diverso da quello dell'elemento cui � legato. Per impostazione predefinita, il contenuto generato erediter� lo stitle dell'elemento che lo ospita.

La propriet� content accetta i seguenti tipi di valori:

• stringhe: Come mostrato nel precedente esempio;
• URL: Questo valore punta ad una risora esterna da cui prendere il contenuto generato;
• virgolette: Quattro diverse parole chiave (open-quote, close-quote, no-open-quote e no-close-quote) forniscono uno speciale supporto alle virgolette (queste parole chiave puntano ad una tabella tenuta dalla propriet� quotes per supportare le virgolette annidate);
• contatori: Si veda di seguito.

Contatori

I contatori nei CSS sono inizializzati dalla propriet� counter-reset e incrementati (o, possibilmente, decrementati) dalla propriet� counter-increment. Ecco un semplice esempio che numera gli elementi H1 e H2:

H1:before {
    content: "Chapter " counter(chapter) ". ";
    counter-increment: chapter;
    counter-reset: section;
}
H2:before {
    content: counter(chapter) "." counter(section) " ";
    counter-increment: section;
}

Nell'esempio, la funzione counter() restituisce il valore dei contatori chapter e section.

Per supportare i contatori annidati, ogni contatore nominato pu� avere uno stack di contatori aperti. Questo � importante per gli elementi che possono essere annidati dentro se stessi ad una profondit� arbitraria. La Figura 6 mostra come una coppia di liste annidate (la marcatura � mostrata sulla sinistra) sia numerata in modo differente. I due fogli di stile per la numerazione della tabella sono mostrati nella parte superiore.

<OL> 
  <LI></LI> 
  <LI> 
    <OL> 
      <LI></LI>     
      <LI></LI> 
      <LI></LI> 
  </LI> 
  <LI></LI> 
</OL> 

  OL { counter-reset: item }
  LI:before { 
    content: counter(item);
    counter-increment: item;
  }

  OL { counter-reset: item }
  LI:before { 
    content: counters(item, ".");
    counter-increment: item;
  }

 1
 2
   1
   2
   3
 3

 1
 2
   2.1
   2.2
   2.3
 3

Altri contesti di formattazione

Uno dei benefici principali dei fogli di stile � che il contenuto pu� essere riproposto pi� facilmente per vari tipi di media. La maggior parte degli utenti oggi usa dei dispositivi visuali per la presentazione dei contenuti web (per esempio uno schermo di computer o una pagina stampata), mentre gli utenti con disabilit� visive usano dispositivi acustici, come per esempio un dispositivo braille tattile. La gamma di dispositivi usati per rappresentare i contenuti web � probabile che aumenti nel futuro, e, di conseguenza, aumenter� anche la richiesta di formati di documento e di sistemi di formattazione.

I CSS si sforzano di supportare contesti di formattazione multipli, e i CSS2 hanno introdotto due caratteristiche fondamentali per supportare l'accesso multimodale ai contenuti web:

1. I CSS acustici consentono ai fogli di stile di definire come i documenti debbano essere resi su un dispositivo acustico. I CSS sono l'unico linguaggio di stile esaminato in questa tesi ad avere propriet� acustiche. Per una descrizione delle propriet� acustiche CSS, a cui si fa riferimento come ad ACSS [Aural Cascading Style Sheets, N.d.T.], si vedano la Raccomandazione CSS2 [CSS2 1998] e la descrizione di T.V. Raman [Raman 1996].
2. I tipi di media consentono ai fogli di stile di definire a quale tipo di dispositivo debba applicarsi una particolare regola di stile.

Tipi di media

I tipi di media per il Web furono proposti per la prima volta da Dave Raggett in un messaggio a www-talk nel 1993 [Raggett 1993g]. Dave rispose alla proposta di fogli di stile di Pei Wei:

Ho letto la tua proposta con grande interesse, e aggiunger� "style" alla definizione di attributo del tag LINK nella DTD.

Hai considerato di permettere a fogli di stile multipli di avere usi diversi? Ci� significherebbe poter specificare uno stile per la stampa e uno per l'uso online. Puoi andare anche oltre e distinguere tra X window, PC e palmari.

Il mio suggerimento � che l'elemento LINK assuma un altro attributo che specifichi il media stabilito, per esempio:

<LINK style="http://ora.com/styles/paper_a4" media="paper/A4">
<LINK style="http://ora.com/styles/paper_B5" media="paper/B5">
<LINK style="http://ora.com/styles/xwindows" media="xwindows">      

L'attributo media divenne parte di HTML4 [HTML4 1997]. HTML4 definisce nove differenti descrittori di media: screen, tty, tv, projection, handheld, print, braille, aural, all. I CSS2, divenuti Racccomandazione W3C nel maggio 1998, erano quasi del tutto in linea con HTML4 su questo argomento: le sole differenze sono che i CSS2 usano il termine "tipi di media" e aggiungono il tipo di media embossed.

Di principio sarebbe stao sufficiente usare solo l'attributo media (definito anche per i documenti XML [XML-stylesheet 1999], ma avere una nozione dei tipi di media all'interno dei fogli di stile CSS consente ad un solo foglio di stile di descrivere la resa su diversi tipi di media differenti:

@media tv {
  BODY { font-size: 14px }
}
@media handheld {
  BODY { font-size: 10px }
}
@media print {
  BODY { font-size: 12pt }
}
@media projection {
  BODY { font-size: 20px }
}

I browser che supportano i CSS2 interpreteranno il precedente esempio in modo che le regole nelle parentesi graffe siano applicate solo ai rispettivi tipi di media. I browser che comprendono solo i fogli di stile CSS1 salteranno tutte le regole all'interno delle parentesi graffe grazie al parsing compatibile nel futuro.

La scelta dei nomi per i tipi di media � stata alquanto controversa. I nomi attuali sono descrittivi del loro uso, ma non definiscono chiaramente la gamma di dispositivi a cui si applicano. Il bisogno di linguaggio di query pi� specifico fu previsto in HTML 4.0 e nei CSS2, ed entrambe le specifiche hanno lasciato spazio ad estensioni future.

I CSS nel contesto

Quando il lavoro sui CSS inizi� nel 1994, esso affront� diverse sfide. Da allora il Web si � affermato come un mezzo adatto per la pubblicazione elettronica e si sono stabilite delle convenzioni di authoring. I fogli di stile non facevano parte di queste convenzioni e molti dubitavano del fatto che essi sarebbero mai divenuti parte della pubblicazione web. Un commentatore scrisse [Suck 1996]:

Le tabelle in HTML potrebbero avere meno a che fare con il design della pagina e pi� con righe e colonne di numeri, se non fosse per lo spettacolare fallimento dei fogli di stile. L'effetto a cascata dei "Fogli di stile a cascata, livello 1" del W3C - inaugurati da oltre un anno lo scorso inverno in quella citt� di sogno (Parigi, Francia) - non si sarebbe potuto progettare meglio. Da allora, i layout di pagina con le tabelle e i Netscapismi come FONT SIZE si sono rafforzati, rendendo i fogli di stile un eccellente prodotto da comitato per gli standard - non solo nella loro semplice eleganza, ma anche nella loro inutilit� e ridondanza.

Affinch� i fogli di stile CSS avessero successo a dispetto dei rafforzati Netscapismi, era necessario che venissero accettati da:

• produttori di browser: I CSS dovevano essere semplici da implementare, e offrire caratteristiche convinceti che avrebbero reso le succesive release dei loro browser altrettanto convincenti per il pubblico;
• autori: I CSS dovevano essere facili da imparare come l'HTML, e fornire al contempo caratteristiche di stile non ottenibili altrimenti;
• utenti: Tra questi tre gruppi gli utenti sono quelli con l'influenza minore, ma la disapprovazione da parte degli utenti pu� essere problematica per le nuove tecnologie web. Per esempio, l'uso dei frame [HTML4 1997] � stato ostacolato dalla resistenza degli utenti [Nielsen 1996].

Oltre alla popolarit� a breve termine necessaria per essere accettati, i CSS avevano anche l'ambizione a lungo termine di salvare l'HTML dalla sua trasformazione in un linguaggio di marcatura visuale. Questo aspetto dei CSS non � sottolineato nelle specifiche stesse, ma � citato nella Appendice E: L'applicabilit� ed estensibilit� dei CSS1 delle specifiche CSS1 [CSS1 1996]:

• sostituzione della marcatura visuale: le estensioni HTML, come "CENTER", "FONT" e "SPACER", sono facilmente sostituire dai fogli di stile CSS1.
• marcatura pi� bella: invece di usare gli elementi "FONT" per ottenere il popolare stile maiuscoletto, � sufficiente una sola dichiarazione nel foglio di stile.

Per far vincere ai CSS le loro sfide e soddisfare le loro ambizioni, furono prese delle decisioni fondamentali in sede di design:

• Creare un nuovo linguaggio. Nel periodo in cui i CSS furono proposti per la prima volta alla comunit� del Web, ISO stava gi� lavorando a DSSSL da quasi dieci anni. Come abbiamo avuto modo di vedere nel Capitolo 4, diverse persone proposero l'uso di un linguaggio ridotto come DSSSL-lite da applicare ai documenti HTML. I CSS presero alcune idee da DSSSL (come la nomenclatura delle propriet�), ma si decise di sviluppare un nuovo linguaggio piuttosto che costruirlo su DSSSL. Vi sono diversi motivi per questa scelta. Primo: DSSSL era un lavoro in svolgimento e le bozze non erano generalmente disponibili. Secondo: DSSSL non era stato sviluppato tenendo presente il Web e non aveva un modo di combinare i fogli di stile degli autori e degli utenti. Terzo: la sintassi basata su Scheme fu giudicata non adatta ai non-programmatori.
• Creare un linguaggio dichiarativo non-Turing-complete. Un altra scelta di design, a quel tempo controversa, era sviluppare un linguaggio dichiarativo che esprimesse restrizioni, piuttosto che un linguagggio di programmazione Turing-complete. Un linguaggio di programmazione sarebbe stata una soluzione pi� potente, ma con un costo da pagare: i programmi sono difficili da leggere e costosi da mantenere. Inoltre la sicurezza, – che � sempre una preoccupazione sul Web – ne risente.
• Supportare la resa progressiva. Per far visualizzare il contenuto all'utente il pi� velocemente possibile, i browser supportano la resa progressiva dei documenti. Anche se un documento non � stato completamente scaricato, la prima parte pu� essere visualizzata. La resa progressiva era considerata una caratterstica importante che i CSS non dovevano infrangere. I CSS non hanno perci� un modo di dare uno stile ad un elemento in base ai suoi figli o fratelli pi� giovani. Inoltre gli elementi non possono essere riordinati, e questo rende impossibile, ad esempio, creare una tabella dei contenuti. XSL [XSL 2001] ha assunto un approccio differente essendo un linguaggio trasformazionale.
• Far funzionare i CSS con i documenti strutturati. I CSS richiedono che le implementazioni siano consapevoli della struttura del documento. Pi� specificamente, i selettori contestuali possono selezionare un elemento in base al suo antenato e le implementazioni, perci�, devono mantenere uno stack di elementi aperti. Nel 1995 i browser pi� diffusi non mantenevano uno stack degli elementi aperti e perci� i CSS1 imponevano un cambiamento significativo alla loro architettura. Retrospettivamente, pu� essere stato un errore inserire i selettori contestuali nelle specifiche CSS1. Le implementazioni non supportarono questa caratteristica in modo interoperabile se non diversi anni dopo, il che rallent� lo sviluppo dei CSS1.
• Far funzionare i CSS con qualsiasi linguaggio di marcatura strutturato. Sebbene HTML comparisse nel titolo della proposta iniziale, i CSS furono presto generalizzati per funzionare con qualsiasi linguaggio di marcatura strutturato, in cui i linguaggi basati su SGML formavano un sottoinsieme particolarmente interessante. Il costo della generalizzazione fu ridotto, e la decisione in seguito si rivel� importante quando cominciarono a comparire linguaggi scritti in XML. Questo ha funzionato in entrambi i sensi: la gente � pi� disposta a usare XML dato che gli si pu� attribuire uno stile con i CSS.

Un test importante sulla correttezza o meno di tali scelte � determinare come i CSS si comportino rispetto ai requisiti del Web precedentemente stabiliti, proprio come gli altri linguaggi di stili valutati nel precedente capitolo. La Tabella 21 continua dal punto in cui la Tabella 16 si interrompe:

I CSS soddisfano tutti i requisiti del Web per un linguaggio di stile.

Sommario e conclusioni

I CSS sono un linguaggio di stile concepito per l'uso sul Web. Si � sviluppato principalmente a partire da due proposte di fogli di stile per il Web, ossia CHSS e SSP. Alcune caratteristiche di queste proposte furono eliminate nel corso dello sviluppo dei CSS dalla fase di proposta a quella di Raccomandazione W3C.

Paragonati con altri linguaggi di stile maturi, i CSS hanno delle caratteristiche distintive ed innovative:

• La cascata permette a diversi fogli di stile di influenzare la presentazione di un documento.
• Le pseudo-classi e gli pseudo-elementi permettono alle informazioni esterne alla struttura logica di influenzare la presentazione.
• Le regole di parsing compatibile nel futuro permettono al linguaggio di essere esteso con eleganza.
• I tipi di media permettono ai fogli di stile di essere indirizzati a determinati dispositivi di output.
• I CSS danno maggiore risalto ai selettori rispetto agli altri linguaggi; piuttosto che avere espressioni nei linguaggi di stile, le espressioni sono inserite nei selettori.

Questo capitolo ha descritto il design dei CSS. Il prossimo capitolo affronta i problemi sperimentati nei CSS.

Problemi nei CSS

In questo capitolo sono discussi i problemi nei, e correlati ai, fogli di stile a cascata. Questi problemi vanno dai semplici errori di compitazione nelle specifiche, fino a questioni pi� complesse come quelle sul soddisfacimento da parte dei CSS del loro ruolo specifico. Il capitolo � organizzato liberamente lungo un asse di complessit�: la prima parte descrive come siano stati gestiti semplici errori, e il resto discute invece dei problemi reali e manifesti dei CSS.

Il meccanismo a cascata gioca un importante – e complesso – ruolo nei CSS e una sezione di questo capitolo � dedicata ai problemi nel meccanismo a cascata. Da ultimo viene illustrata la storia dell'implementazione CSS nei browser.

Errori nelle specifiche

Come in ogni altra specifica, esistono errori anche nelle specifiche CSS. Come parte del processo di mantenimento delle specifiche, i curatori raccolgono gli errori e li pubblicano nei successivi documenti di errata corrige. Man mano che l'elenco degli errori cresce, diventa difficile leggere le specifiche originali e al contempo l'elenco degli errori. Unire i due documenti crea un nuovo documento che � pi� facile da leggere.

Le specifiche CSS1, pubblicate per la prima volta come Racccomandazione W3C nel dicembre 1996, furono ripubblicate con tutti gli errori conosciuti corretti nel gennaio 1999. Nel nuovo documento, un appendice elenca i cambiamenti e li ordina in tre categorie:

• Errori tipografici e di compitazione (12 errori elencati). Per esempio furono aggiunte una parentesi destra ed una virgola mancante.
• Errori (28 errori elencati). Per esempio fu usata in un esempio una dichiarazione non valida (font-style: small-caps), e si fece riferimento ad una sezione "4.4", mentre quella corretta � "4.7".
• Struttura e organizzazione (6 errori elencati). Per esempio l'edizione riveduta usa un nuovo foglio di stile, ed � stata aggiunta l'appendice che descrive i cambiamenti.

Un simile sforzo � stato programmato anche per i CSS2, ma poich� esso comprender� anche cambiamenti semantici (oltre agli errori), � pi� probabile che venga rilasciata una nuova versione.

Problemi con le specifiche

Risolvere gli errori nelle specifiche, come descritto nella precedente sezione, non � molto controverso. Identificare e correggere i problemi reali e manifesti � invece molto pi� problematico. Vi sono spesso interessi in conflitto tra designers ed implementatori: una soluzione di un designer pu� facilmente divenire un problema per un implementatore. Un resoconto personale dei problemi nelle specifiche CSS viene dato in questa sezione.

Mancanza di funzionalit�

Fare l'authoring di una specifica tecnica vuol dire spesso trovare un equilibrio tra funzionalit� da un lato ed implementabilit� dall'altro. La funzionalit� deve essere abbastanza ricca per affrontare i bisogni degli utenti, e abbastanza semplice per essere implementata in modo interoperabile.

Tradizionalmente i CSS hanno rivalutato la semplicit� rispetto alla funzionalit�. Per esempio, il sommario dei CSS1 afferma che i CSS sono un semplice meccanismo di fogli di stile. L'autore crede che questa sia stata una scelta corretta, ma vi sono tuttavia delle aree in cui i CSS avrebbero dovuto offrire una funzionalit� pi� ricca:

• contrasto di colore: Non � possibile assicurare un determinato contrasto tra il colore del testo e lo sfondo.
• dimensioni dei font: Non � possibile specificare la dimensione del font in funzione della larghezza dell'elemento. La mancanza di questa funzionalit� rende difficile, ad esempio, creare delle presentazioni slide che scalino da una dimensione di schermo all'altra.
• interlinea: Non � possibile impostare l'interlinea in funzione della grandezza dell'elemento. Per aumentare la leggibilit�, l'interlinea dovrebbe aumentare in altezza se l'elemento aumenta di dimensione.
• centratura: Non � possibile centrare un elemento verticalmente in relazione allo schermo.

Oltre all'elenco specifico di cui sopra, vi sono altre aree generali dove sarebbe stato importante uno sforzo maggiore:

• interfaccia utente: I CSS furono concepiti soprattutto per presentare documenti, e non l'interfaccia utente. Tuttavia, molti dei componenti richiesti per descrivere l'interfaccia utente sono presenti, ed alcune funzionalit� aggiuntive avrebbero potuto rendere possibile la descrizione dell'interfaccia utente. Soprattutto, sarebbe stato necessario poter descrivere la presentazione delle liste di navigazione.
• layout multi-colonna: Non � possibile descrivere un layout multi-colonna ove il contenuto fluisce automaticamente da una colonna all'altra.
• intestazioni/pi� di pagina: Non � possibile descrivere intestazioni e pi� di pagina sulle pagine.

Alcune di queste caratteristiche saranno probabilmente aggiunte nelle future versioni dei CSS, proprio come i CSS2 aggiunsero alcune caratteristiche richieste di frequente:

• roll-over: Nei CSS1, non era possibile descrivere la presentazione quando il colore/sfondo di un elemento cambiava se il puntatore passava sopra o copriva un elemento. Gli autori usavano invece Javascript per ottenere questo effetto. Questa funzionalit� fu aggiunta con successo nei CSS2 tramite lo pseudo-selettore :hover.
• posizionamento: Nei CSS1 non era possibile estrarre gli elementi dal flusso e posizionarli sopra altro contenuto. I CSS2 aggiunsero il posizionamento degli elementi. La proposta fu esaminata dalle rappresentative di Microsoft e Netscape e pubblicata come bozza di lavoro W3C [WD-positioning 1997] prima di essere integrata nei CSS.
• interruzioni di pagina: I CSS1 non si occupavano dei media impaginati, e le interruzioni di pagina furono tra le caratteristiche aggiunte nei CSS2.

Queste aggiunte sono un esempio dei cambiamenti nei CSS creati dal feedback tra autori e produttori.

Eccessiva funzionalit�

Come la mancanza di funzionalit�, l'eccessiva funzionalit� pu� essere pericolosa per una specifica. Gli implementatori possono giudicare la specifica troppo complessa e scegliere quindi di implementare solo alcune parti o ignorarle in toto. Il risultato � un'interoperabilit� povera o mancante.

Le caratteristiche elencate di seguito sono descritte nelle specifiche CSS ma, si pu� dire, potrebbero essere tralasciate senza una perdita significativa. Tali caratteristiche sono relativamente complesse da implementare, e ci � voluto un lungo periodo per raggiungere l'interoperabilit�.

• first-line e first-letter: Gli pseudo-elementi first-line e first-letter rendono possibile assegnare uno stile al contenuto basandosi sul layout della pagina piuttosto che sulla struttura del documento. Ci si riferisce a questo tipo di caratteristiche dicendo che sono azionate dal layout. I CSS1 includevano questi pseudo-elementi per essere in grado di offrire agli autori delle caratteristiche non ottenibili altrimenti. Tuttavia, il costo della loro implementazione andava oltre i vantaggi degli effetti visivi che essi fornivano.
• box model: Il box model CSS comprende aree di padding, bordo e margine intorno a tutti gli elementi. Per gli elementi a livello di blocco questo ha un senso. Per gli elementi in riga, tuttavia, avere tre aree � eccessivo: avere un'area di padding sarebbe sufficiente.
• selettori contestuali: Un selettore contestuale permette di selezionare gli elementi in base alla loro posizione nella struttura ad albero del documento. Supportare i selettori contestuali rende possibile, ad esempio, rimuovere i bordi dalle immagini che fungono da collegamenti ipertestuali. Lo si reput� un requisito adatto in luogo delle estensioni di Netscape. Tuttavia, supportare i selettori contestuali � complesso, a meno che le implementazioni non fossero gi� state in grado di mantenere uno stack degli elementi aperti. In genere ci� non accadde, e i selettori contestuali non furono supportati in modo interoperabile se non diversi anni dopo la pubblicazione dei CSS1. In questo modo i selettori contestuali ritardarono lo sviluppo dei CSS1. D'altro canto, avendo i selettori contestuali, i CSS contribuirono alla comprensione dell'HTML come di un linguaggio di marcatura strutturato.

Si pu� anche dire che altre parti dei CSS2 siano eccessive, dal momento che non sono state ampiamente implementate. Queste parti comprendono:

• text-shadow: Questa propriet� fu aggiunta nei CSS2 per generare effetti d'ombra sul testo e per scoraggiare gli autori dall'usare immagini al posto del testo. La propriet� � complessa da implementare e pu� sostituire solo un limitato insieme di effetti visuali che i designer vogliono applicare al testo.
• marks: Nella stampa ad alta qualit�, i segni a croce sono spesso stampati sui margini della pagina per allineare i fogli, e i segni di taglio indicano dove i fogli devono essere tagliati. La propriet� marks fu aggiunta ai CSS2 per togliere ed inserire tali segni. Questa operazione, tuttavia, pu� anche essere svolta dall'utente nella casella di dialogo per la stampa dell'applicazione.
• markers: I marcatori sono di solito usati con le voci di lista per marcare l'inizio di una nuova voce. I CSS1 consentivano la descrizione del tipo di marcatore (per esempio se una voce di lista debba essere marcata con un cerchio o un numero). I CSS2 offrono un modo pi� ricco e complesso di descrivere i marcatori tramite pseudo-elementi.
• font scaricabili: I font sono una risorsa essenziale nella presentazione dei documenti. Un tipico computer desktop ha circa 20 famiglie di font disponibili e i dispositivi palmari meno. Essere in grado di scaricare i font dal Web ha la potenzialit� di aumentare la ricchezza della presentazione. I CSS2 offrono un meccanismo per descrivere e selezionare i font dal Web. Tuttavia, la caratteristica non � molto usata. Vi sono due motivi principali per questo: in primis, non vi � un formato di font universale supportato da tutti i produttori; in secundis, i designer di font vogliono essere ricompensati per il loro lavoro, e non vi � un meccanismo adatto per il pagamento.
• font-size-adjust: Questa propriet� affronta un problema che ricorre quando una famiglia di font viene sostituita da un'altra. La leggibilit� dei due font pu� variare considerevolmente e il valore di x-height � spesso pi� importante della dimensione del font. Lo scopo della propriet� font-size-adjust � quello di indicare, per i designer, che la x-height del font deve essere preservata, piuttosto che la dimensione del font.

Sebbene nessuna delle caratteristiche elencate sia stata ampiamente implementata, l'autore ritiene che esse descrivano delle funzionalit� utili, e che tali funzionalit� verrebbero usate qualora fossero implementate.

Design povero

La mancanza di funzionalit� pu� essere aggiunta, e l'eccessiva funzionalit� pu� essere rimossa. Il design povero, tuttavia, � spesso pi� difficile da risolvere in una fase successiva. Di seguito vengono considerati tre problemi di design per cui i CSS sono stati criticati.

Propriet� sovrasfruttate

I CSS1 cercarono di essere un linguaggio compatto per rendere possibili le implementazioni su piccoli dispositivi. In alcune aree, tuttavia, troppe funzionalit� furono compresse in una singola propriet� al fine di preservare lo spazio. Questo � il caso della propriet� white-space che descrive sia il collassamento dei caratteri, sia il rispetto delle interruzioni di riga. Questi sono due problemi separati, e la propriet� dovrebbe, perci�, essere divisa in due propriet�. Similmente, la propriet� text-decoration codifica diversi valori non correlati tra loro. Per esempio, essa descrive se un elemento deve essere sottolineato o se deve essere lampeggiante. Come risultato, non � possibile interrompere il lampeggiare degli elementi senza influenzarne anche la sottolineatura.

Posizionamento

Nel gennaio 1997, due mesi dopo che i CSS1 divennero una raccomandazione W3C, fu pubblicata dal W3C la prima Bozza di Lavoro di un documento chiamato Posizionare gli elementi HTML con i fogli di stile a cascata. Avendo come autori gli sviluppatori di Netscape e di Microsoft, il documento � un raro esempio di collaborazione tecnica tra le due societ� rivali. La proposta introduceva nuove propriet� CSS per consentire agli autori di avere grande accuratezza nella descrizione della pagina e nel layout. È significativo il fatto che la descrizione faccia riferimento solo agli autori – non agli utenti – e perci� trascuri la cascata. Difatti, le propriet� di posizionamento non si adattano bene alla cascata (si veda il problema del posizionamento di seguito).

Un altro problema con l'iniziale bozza sul posizionamento � la mancanza di propriet� corrispettive alle propriet� proposte top e left. Questo indica una certa preferenza verso i sistemi di scrittura occidentali, che sono di solito scritti da sinistra a destra e dall'alto in basso. Quando il posizionamento fu integrato nei CSS2, le propriet� right e bottom furono in seguito aggiunte per assicurare che il posizionamento potesse essere usato anche con altri sistemi di scrittura.

Sintassi XML

Una critica comune ai CSS riguarda il loro uso di una sintassi propria piuttosto che l'essere scritti in XML. Usando la sintassi XML, si afferma, sarebbe pi� facile far analizzare i CSS da un parser e i fogli di stile potrebbero essere letti e scritti da strumenti XML standard. Infatti, la scelta della sintassi � importante e se gli argomenti a favore dell'uso di una sintassi XML, come visto sopra, sono veri, allora i CSS avrebbero potuto trarre un beneficio dall'usare la sintassi XML. Vi sono, tuttavia, diversi motivi per cui i CSS non sono scritti in XML.

In primis, quando i CSS vennero sbiluppati, XML non era disponibile. XML divenne una Raccomandazione W3C nel febbraio 1998 [XML 1998], e cambiare la sintassi a quel punto avrebbe richiesto un costo considerevole. SGML, tuttavia, era disponibile, e alcune persone sostennero che si doveva usare una sintassi basata su SGML [Gramlich 1996]:

Non sappiamo cosa pensano gli altri produttori, ma ci stiamo stancando di dover implementare un nuovo parser ogni volta che qualcosa di nuovo nasce dal W3C (PICS, PEP, CSS, HTTP-NG, ecc.) È chiaro che i CSS hanno attirato molta attenzione per il fatto di avere un modo testualmente compatto di rappresentare i fogli di stile. Sfortunatamente, non crediamo che tutti i produttori implementeranno correttamente il parser CSS e questo porter� a gravi problemi di interoperabilit� nei fogli di stile (se non siete d'accordo, pensate solo a quanto tempo ci � voluto affinch� la maggior parte dei client web interpretasse correttamente il sottoinsieme di SGML, ossia l'HTML). Inoltre siamo preccoupati dal fatto di dover gravare sui fornitori di contenuto con l'onere aggiuntivo di una sintassi per esprimere i fogli di stile; SGML ha una sintassi orribile, ma i fornitori di contenuto possiedono gi� la capacit� di generarla.

Alla fine, si prefer� la leggibilit� e la facilit� di scrittura umane rispetto al riutilizzo dei parser. La sintassi CSS � ottimizzata per scrivere fogli di stile, e non sappiamo se vi sia un sistema di codifica XML che sia pi� adatto agli umani. Inoltre scrivere un parser CSS � relativamente semplice.

Il beneficio maggiore dello scrivere i CSS in XML sarebbe probabilmente stato una maggiore accettazione da parte della comunit� XML.

Problemi della cascata

Nel capitolo precedente, il meccanismo a cascata nei CSS � stato descritto in dettaglio ad un livello tecnico. Il meccanismo a cascata soddisfa due importanti requisiti per i CSS. In primis, consente sia agli autori che agli utenti di influenzare la presentazione dei documenti. In secundis, fornisce valori di ripiego quando vengono forniti solo fogli di stile parziali, o quando tali fogli di stile mancano. Tuttavia, il meccanismo a cascata ha molti problemi ad esso correlati. Essi vengono discussi in questa sezione. Verso la fine, vengono proposte delle soluzioni.

Problemi autoinflitti

I problemi elencati di seguito sono dovuti al peculiare design dei CSS.

• Il problema di stile: Combinare differenti stili spesso porta a scarsi risultati estetici. Un esempio preso dall'architettura: erigere un edificio con uno stile diverso da quelli circostanti raramente aggiunger� un contrasto creativo, e pi� spesso sembrer� fuori posto. Intuitivamente, combinare differenti fogli di stile ha alcuni degli stessi problemi ad esso associati.
• Il problema dell'abbondanza di selettori: Il numero e il tipo di selettori disponibili sono di vitale importanza nei fogli di stile, poich� forniscono gli agganci per collegare le regole di stile. Per creare presentazioni ricche, un potente insieme di selettori � sicuramente benefico. Per esempio, se solo i selettori di tipo sono disponibili, tutti gli elementi P avranno lo stesso stile. I selettori pi� avanzati rendono possibile dare uno stile diffrente agli elementi P a seconda della loro collocazione nella struttura del documento. I CSS2 forniscono un ricco insieme di selettori per questo scopo, ma vi � un conflitto intrinseco tra ricchezza dei selettori e cascata. Per impostare lo stile su tutti gli elementi P, la parte in gara avr� bisogno di scrivere un vasto insieme di selettori, oppure di aumentare consistentemente il peso delle sue regole di stile.
• Il problema dell'abbondanza di propriet�: Proprio come la ricchezza di selettori si risolve in un problema per la cascata, anche le propriet� hanno il problema dell'abbondanza. In particolare, la distanza visuale tra gli elementi pu� essere impostata tramite diversi tipi di propriet�: padding, bordi e margini. Inoltre la distanza pu� essere influenzata dalle propriet� display, float e position. Per assicurare una certa distanza, si deve perci� impostare un insieme di propriet�. Si consideri questo esempio:

  P {
    display: block;
    float: none;
    position: static;
    margin: 1em;
    border: 0;
    padding: 0;
  }
  

  Il precedente esempio imposta la distanza verticale tra gli elementi P ad un em. La sintassi abbreviata usata per impostare il margine, il bordo e il padding, allevia in una certa misura il problema.

• Il problema del raggruppamento: Una richiesta comune da parte degli autori che cominciano ad usare i CSS � un modo di raggruppare le regole in modo tale che se una regola fallisce, le altre non vengono applicate. Per esempio, un foglio di stile pu� impostare il colore di primo piano sul bianco e il colore di sfondo sul nero. Se una di queste regole viene sovrascritta da una regola introdotta dalla cascata, l'autore vorrebbe specificare che anche l'altra regola debba fallire. I CSS non offrono un tale meccanismo; ogni regola nei CSS � impostata indipendentemente dalle altre.
• Il problema dell'isola a sè: Il meccanismo a cascata � in grado di combinare diversi fogli di stile, ma non vi � un meccanismo generale che consente alle regole di un foglio di stile di basarsi sulle regole contenute in altri fogli di stile. Per esempio, non � possibile scrivere un foglio di stile che aumenti il contrasto tra colori di sfondo e di primo piano mentre si usano ancora i valori definiti in un altro foglio di stile. Se si usano unit� di misura relative, le regole di stile in un foglio di stile possono essere relative alle regole di stile contenute in altri fogli di stile. Per esempio, la dimensione dei font pu� essere impostata in un foglio di stile e la larghezza di un elemento pu� essere impostata a 10em in un altro foglio di stile.
• Il problema della positivit�: Le regole CSS possono esprimere solo asserzioni positive. Per esempio, una regola pu� affermare che un elemento deve essere rosso, ma non che un elemento non deve essere blu. In alcune situazioni sarebbe positivo descrivere che valori particolari, o combinazioni di valori, non sono accettabili. Per esempio, il testo verde su sfondo rosso � difficile da leggere per le persone affette da cecit� ai colori. In alcune situazioni, i CSS forniscono un elenco di valori alternativi. L'elenco di famiglie di font separate da virgola ne � un esempio.

  Il problema della possibilit� non sarebbe stato tale se fosse possibile selezionare gli elementi in base ai loro valori di stile. Si consideri questo esempio immaginario, dove tutti gli elementi con testo verde su sfondo rosso vengono selezionati:

  *[color=green][background=red] {
    background: white
  }
  

  Per quanto questo esempio possa sembrare semplice, esso comporta un numero non indifferente di gravi problemi. Per esempio, qual'� la definizione di rosso?

• Il problema del posizionamento: Alcune propriet� non si combinano bene nella cascata. Le propriet� introdotte per supportare il posizionamento degli elementi (position, left, right, top, bottom, z-index) sono di solito impostate su singoli elementi piuttosto che su gruppi di elementi. Questo rende complicato per gli utenti scrivere fogli di stile che si combinino elegantemente con i fogli di stile dell'autore.

Problemi risultanti dalla marcatura

• Il problema della marcatura generica: Le specifiche HTML definiscono un insieme di elementi consentiti nei documenti HTML. I documenti HTML possono essere visualizzati nei browser poich� i produttori di browser hanno tutti implementato le specifiche HTML (con vario successo). L'insieme di tag comune � anche la base della cascata, poich� il vocabolario di elementi � noto. Un designer pu� scrivere un foglio di stile alternativo usando gli elementi e gli attributi dell'HTML nei selettori CSS.

  Di contro, gli elementi e gli attributi di un documento che usa marcatura generica sono, per definizione, sconosciuti a chiunque fuorch� all'autore del documento. Sebbene la marcatura possa ancora avere un ruolo utile per l'autore, � impossibile per gli altri scrivere fogli di stile per visualizzare il documento. Solo il selettore universale (che seleziona tutti gli elementi) e gli pseudo-selettori (per esempio :first-line e :visited) hanno senso per l'uso con un insieme di tag sconosciuto, e ci� non � abbastanza per scrivere un foglio di stile intelligente.

• Il problema delle classi: L'attributo class in HTML rende possibile scrivere fogli di stile con i quali non si pu� mai ottenere la cascata. Le specifiche CSS1 contengono un avvertimento sull'uso degli attributi di classe:

  I CSS danno cos� tanto potere all'attributo CLASS, che in molti casi non importa neppure a quale elemento HTML sia associata la classe – ossia si pu� far si che ogni elemento emuli l'altro. Basarsi su questo potere non � raccomandato, poich� esso rimuove il livello strutturale che ha significato universale (gli elementi HTML). Una struttura basata su CLASS � utile solo all'interno di un dominio ristretto, laddove il significato di una classe � mutualmente concordato.

  Il problema delle classi � un caso specifico del problema della marcatura generica descritto in precedenza.

• Il problema della marcatura presentazionale: Molte pagine web usano le tabelle a scopo di layout. Posizionando il contenuto nelle celle di tabella, gli autori rappresentano il loro contenuto in una griglia bidimensionale. In un certo senso, le tabelle sono scalabili orizzontalmente e verticalmente (per esempio la larghezza e l'altezza delle colonne e delle righe si espandono e si contraggono in base al contenuto della tabella), ma il layout bidimensionale � rigido. È possibile per i CSS appiattire le tabelle in elementi di blocco e in riga, ma si perde la semantica originale della relazione spaziale, e le tabelle reali (opposte alle tabelle usate a scopo di layout) sono anch'esse appiattite nel processo.

Problemi dell'interfaccia utente

• Il problema dell'interfaccia utente: Storicamente i browser hanno dato agli utenti ben pochi mezzi per impostare le preferenze presentazionali. Scelte tipiche comprendono la sottolineatura e la colorazione dei collegamenti. Nel periodo in cui gran parte della presentazione era inserita nel codice del browser, questa scelta limitata poteva essere spiegata. Con l'arrivo dei CSS, tuttavia, molti aspetti della presentazione sono configurabili. Tuttavia, l'interfaccia utente dei browser pi� diffusi non � cambiata molto e nessun browser fornisce una GUI per descrivere nulla di simile a quello che i CSS possono esprimere. Inoltre, Microsoft Internet Explorer per Windows (altrimenti noto come WinIE, usato dalla maggior parte degli utenti) non fornisce un modo di applicare fogli di stile alternativi. Molti browser, tuttavia, forniscono un modo per puntare ad un file contenente l'interfaccia utente.
• Il problema della GUI: Un problema tipico dell'interfaccia utente � quello per cui pu� non essere intuitivamente chiaro come editare un foglio di stile CSS tramite una GUI. Di solito le GUI danno all'utente il controllo di tutti i valori configurabili. Nel contesto della cascata, tuttavia, � interesse prioritario dell'utente non impostare tutti i valori, lasciando invece all'eredit� o ad altri fogli di stile di determinare il valore. È possibile rappresentare questi valori con impostazioni come auto o defer, ma non � qualcosa che le GUI hanno fatto in passato.

Problemi di complessit�

• il problema dell'abbondanza di siti: Il Web collega migliaia di server e milioni di pagine. È impossibile scrivere un foglio di stile utente che si accordi con tutti i fogli di stile degli autori sul Web. Questo problema si sarebbe potuto affrontare se i browser avessero consentito l'uso di fogli di stile utenti per siti specifici, ma questo non � ancora il caso.
• il problema del debugger del documento: I programmatori usano i debugger per stabilire perch� un determinato valore viene impostato in un determinato punto del programma. Similmente, un debugger del documento � necessario per stabilire perch� una determinata combinazione elemento/propriet� abbia un determinato stile. Ci� deve essere noto per scrivere una regola per modificare il valore. Sono stati scritti debugger del documento, ma non ancora offerti dai principali browser.

Problemi nelle implementazioni

Questa tesi si concentra sullo sviluppo dei CSS e di altri linguaggi di stile, ed � oltre il suo �mbito specifico l'analisi del livello di supporto CSS nei vari browser. Tuttavia, deve essere citato il fatto che, dal punto di vista degli autori, il problema pi� pressante nei primi anni dei CSS era la qualit� del supporto CSS nei browser. Jeffrey Zeldman descrive la situazione nel 1998 [Zeldman 2003]:

Se Netscape 4 ignora le regole CSS applicate all'elemento <body> e aggiunge dello spazio bianco casuale su ogni elemento strutturale delle vostre pagine, e IE4 riconosce <body> ma pasticcia col padding, quale tipo di CSS si potrebbe mai scrivere? Alcuni sviluppatori scelgono di non scrivere affatto i CSS. Altri scrivono un foglio di stile per compensare le falle di IE4 e un altro per compensare gli errori madornali di Netscape 4.

La citazione descrive efficacemente la difficile situazione nella quale si venivano a trovare gli autori: solo un piccolo sottoinsieme di propriet� CSS era implementato interoperabilmente tra Netscape4 e WinIE [Wilson 2003a]. La situazione gradatamente cambi� quando diminu� l'uso di Netscape4 e miglior� il supporto CSS in Internet Explorer [WASP 2004]:

Il W3C ha inventato i fogli di stile a cascata (CSS) nel 1996, per aumentare il grado di complessit� presentazionale e l'accessibilit� dei siti web, e per eliminare la marcatura proprietaria che minacciava di frammentare il Web emergente. Nel 1997, alcuni browser cominciarono a supportare parte dei CSS-1, ma lo standard non divenne realmente usabile fino al 2001.

Come suggerito nella precedente citazione, il 2001 fu un anno di svolta per i CSS. In quell'anno Microsoft rilasci� Internet Explorer 6.0 che, per quanto ancora incompleto e non esente da bug [Wilson 2003b], ha un supporto usabile ai CSS. Da quell'anno sono stati rilasciati altri browser con un supporto eccellente dei CSS, tra cui Opera, Mozilla, e Internet Explorer for MacOS [Wilson 2003a].

Un motivo per l'aumento di qualit� nell'implementazione CSS � probabilmente la CSS1 Test Suite del W3C. La suite di test fu pubblicata per la prima volta nel 1998, 18 mesi dopo che i CSS1 divennero una Raccomandazione W3C [W3C 2004]. Se la suite di test fosse stata disponibile in una fase precedente, la svolta per i CSS sarebbe potuta avvenire prima.

Nessuno dei browser � stato in grado di competere con WinIE in termini di numero di utenti, e WinIE, perci�, ha in effetti definito un sottoinsieme di propriet� CSS che gli autori possono usare. Il supporto limitato ai CSS di WinIE, combinato con un monopolio de facto sui browser web, � attualmente il pi� grande problema per lo sviluppo dei CSS sul Web.

Sommario e conclusioni

I CSS hanno visto molti problemi dalla pubblicazione dei CSS1 nel 1996 come Raccomandazione W3C. I problemi si possono dividere in tre gruppi: problemi nelle specifiche, nel meccanismo a cascata e nell'implementazione.

Le specifiche CSS hanno tre tipi di problemi: errori, mancanza di funzionalit� ed eccessiva funzionalit�. Gli errori sono stati corretti dai curatori che hanno pubblicato gli elenchi di errata corrige e rivisto le specifiche. Inoltre sono state rese disponibili le suite di test per gli implementatori. Le opinioni su quali funzionalit� siano mancanti o eccessive sono soggettive, e sono state descritte tali opinioni dell'autore.

La cascata � un meccanismo ambizioso che ha fallito nel fornire agli utenti eguali diritti per influenzare la presentazione dei documenti, mentre ha avuto successo nel permettere di combinare fogli di stile parziali. Credo che non vi siano problemi di base nei CSS che avrebbero reso pi� semplice l'introduzione dei fogli di stile sul Web.

Le prime implementazioni CSS nei browser erano incomplete e inclini agli errori. Questo ha portato ad una situazione in cui molte parti dei CSS non potevano essere usate finch� particolari browser venivano usati in numero significativo. Ad oggi i CSS sono un riconosciuto linguaggio di stile con diverse eccellenti implementazioni. Tuttavia, non � ancora possibile sfruttare appieno i CSS a causa del relativamente scarso supporto in Microsoft Internet Explorer.

I due capitoli precedenti hanno descritto e valutato lo sviluppo dei CSS. I successivi due capitoli guardano al futuro. Prima viene descritto un uso nuovo e non-stilistico dei CSS. Quindi viene delineata la possibile ricerca futura.

CSS per piccoli schermi

La maggior parte delle pagine web sono scritte e testate esclusivamente per computer desktop con grandi monitor a colori. I dispositivi mobili wireless di solito hanno schermi molto pi� piccoli, e presentare le pagine web su queste unit� � una sfida. Questo capitolo descrive come i CSS possono essere usati per vincere la sfida. La soluzione si basa sulla cascata: usando un foglio di stile concepito per un particolare browser su tutti i documenti, la resa di questi ultimi viene aggiustata a seconda delle restrizioni del dispositivo dell'utente.

Daniel Glazman ha sviluppato il feel-like-a-cellphone stylesheet [lett. "sentiti come un cellulare", N.d.T.] (chiamato FLACS in questa tesi) che, se installato come il foglio di stile predefinito del browser, limiter� la larghezza dei documenti cosicch� gli utenti dovranno scrollarli verticalmente per vederli nella loro interezza [Glazman 2002]. Lo sviluppo di questo foglio di stile fu ispirato dall'annuncio di Opera Software del Small-Screen Rendering [Resa per Piccoli Schermi, N.d.T.] (SSR). In passato SSR � stato parzialmente basato sui fogli di stile, ma ha anche componenti che non possono essere descritti dai CSS. FLACS, essendo una soluzione basata unicamente sui CSS, � perci� pi� adatta all'analisi svolta in questo capitolo.

FLACS � un foglio di stile relativamente semplice. Contiene solo 22 dichiarazioni ed imposta i valori su 16 propriet�. In questo modo � in grado di riferomattare molti documenti per adattarli alla presentazione su un piccolo schermo. I frammenti di stile in questo capitolo sono copiati da FLACS, ma alcuni di essi sono stati leggermente semplificati e sono stati rimossi i commenti nel foglio di stile.

Il problema

L'HTML � un semplice linguaggio di marcatura dove i tag descrivono i ruoli logici del contenuto (per esempio paragrafi e intestazioni) piuttosto che la presentazione del contenuto (per esempio font, colori). Quando le tabelle furono introdotte nell'HTML 3.2 furono destinate a rappresentare semplici righe e colonne di numeri e testo all'interno dei documenti – proprio come le tabelle venivano usate nei documenti tradizionali. Tuttavia gli autori scoprirono presto che le tabelle potevano essere usate a scopo di layout. Invece di mettere le tabelle nel documento, l'intero documento fu messo in una tabella. Per esempio, la pagina poteva consistere di un menu sul lato sinistro, di un banner sulla parte superiore, di una barra laterale a destra, e ciascun componente era una cella di tabella.

Le pagine che usano le tabelle a scopo di layout hanno spesso una larghezza fissa, di solito intorno ai 600 pixel. Questa larghezza va bene su un computer desktop, ma non su dispositivi web pi� piccoli. Ci sono diversi modi per adattare il contenuto ai piccoli schermi.

In primis, alcuni browser possono zoomare le pagine avanti e indietro. Lo zoom � un sistema potente per avere una visione complessiva di pagine web complesse, essendo al contempo in grado di ingrandire alcune parti della pagina. Viene spesso usato da persone con menomazioni visive per ottenere una dimensione dei font leggibile. Lo zoom all'indietro consente alle pagine web scritte per i computer desktop di essere mostrate sui piccoli schemri, ma in questo modo il contenuto leggibile della pagina � esiguo. L'uso dello zoom di solito richiede che l'utente scrolli la pagina sia in orizzontale che in verticale.

In secundis, si pu� riformattare il contenuto per meglio adattarlo sui piccoli dispositivi. La riformattazione richiede un elaborazione maggiore rispetto allo zoom; lo zoom cambia solo la dimensione degli elementi sullo schermo, ma preserva le relazioni spaziali tra di essi, mentre la riformattazione implica che la pagina venga presentata in modo da cambiare le relazioni spaziali tra gli elementi. La riformattazione soddisfa un requisito che di solito troviamo nei cellulari: non ci dovrebbe essere lo scrolling orizzontale.

Questo capitolo descrive una strategia per riformattare il contenuto sulla base di quattro componenti principali:

• cascata: Il browser applica un foglio di stile del browser al documento;
• linearizzazione: Il browser linearizza la presentazione del documento trasformando le celle di tabella e gli elementi posizionati in normali elementi di blocco;
• rimozione di elementi: Il browser rimuove gli elementi non adatti alla visualizzazione su piccoli schermi;
• ridimensionamento di elementi: A tutti gli elementi viene data una larghezza massima uguale alla dimensione dello schermo, e tali elementi vengono ridotti se necessario.

Il resto di questo capitolo descrive il processo di riformattazione in dettaglio. Un browser che riformatta i documenti secondo questo processo si dice in modalit� small-screen [piccolo schermo, N.d.T.].

Cascata

Come discusso nel Capitolo 6, i fogli di stile possono avere tre diverse origini: autore, utente e browser. Di solito il ruolo del foglio di stile predefinito del browser � solo quello di fornire valori di ripiego. In modalit� small-screen, tuttavia, il foglio di stile del browser gioca un ruolo pi� attivo. Si consideri questo frammento di FLACS:

body {
  width: 176px ! important;
  padding: 3px ! important;
  margin: auto ! important;
  border: thick black solid ! important;
}

La prima dichiarazione imposta l'elemento BODY su una larghezza fissa (176px � una larghezza di schermo comune sui cellulari). La dichiarazione � marcata come important per rafforzarla, anche nel caso in cui il foglio di stile dell'autore o dell'utente ha impostato un'altra larghezza. Allo stesso modo vengono rafforzate le dichiarazioni di padding, bordo e margine sull'elemento BODY.

FLACS, tuttavia, non descrive completamente la presentazione del documento. Per esempio, i colori e i font non vengono impostati in FLACS (con l'eccezione della dimensione dei font) e perci� vengono parzialmente rispettati i fogli di stile dell'autore. FLACS fa perci� un uso attivo della cascata.

Linearizzazione

Le tabelle HTML sono costituite da celle allineate orizzontalmente in colonne all'atto della presentazione. Pi� spesso, l'organizzazione del contenuto in tabella è un effetto puramente visivo usato per ottenere un tipo di layout a griglia. Su un piccolo dispositivo non vi è abbastanza spazio per un layout a griglia, e la tabella pu� essere riorganizzata in elementi di blocco. In modalit� small-screen, tutte le celle di una riga si combinano per formare un elemento di blocco, ossia ogni riga viene trasformata in un elemento di blocco, e tutti gli elementi di blocco creati a partire da una tabella sono presentati uno sopra l'altro. Ci� viene espresso facilmente nei CSS:

table, tr, td, th {
  display: block ! important;
}

Una tecnica simile viene usata per gli elementi posizionati in modo assoluto. Gli elementi posizionati sono di norma estratti dal flusso normale di testo e posizionati su un punto dello schermo. Sui piccoli schermi ci� risulta problematico, in quanto molti elementi posizionati verranno posti fuori dalla limitata area di visualizzazione. Dunque il posizionamento viene annullato:

* { 
  position: static ! important;
}

Infine, il floating degli elementi viene a sua volta annullato, poich� lo schermo non � abbastanza ampio per mostrare gli elementi uno affianco all'altro:

* {
  float: none ! important;
}

Rimozione di elementi

Alcuni elementi non sono adatti alla visualizzazione su piccoli schermi. Vi sono tre tipi principali di elementi rimossi da FLACS: piccole immagini, annunci pubblicitari ed elementi che usano determinati plug-in.

Le piccole immagini usate solo a scopo ornamentale possono essere selezionate in base alla loro dimensione:

img[width="1"], img[height="1"] {
  display: none ! important;
}

Il precedente esempio rimuove le immagini con un'altezza o larghezza pari ad un pixel. Le immagini che non hanno una dimensione dichiarata attraverso gli attributi non saranno selezionate.

Gli annunci pubblicitari sono problematici sui piccoli schermi, poich� occupano un notevole spazio sullo schermo e consumano banda. Perci�, FLACS cerca di rimuovere tali annunci dalla presentazione del documento. Non c'� un modo per sapere quali elementi contengono annunci in HTML. Tuttavia, si sono stabilite delle convenzioni per tali annunci, e queste convenzioni possono essere usate per selezionarli e rimuoverli. Per esempio, una dimensione tipica per gli annunci � 468 per 600 pixel. FLACS rimuove le immagini di questa dimensione con una semplice regola:

img[width="468"], img[height="600"] {
  display: none ! important;
}

Anche l'elemento iframe � spesso usato per gli annunci pubblicitari e pu� perci� essere rimosso:

iframe {
  display : none ! important;
}

Infine FLACS rimuove gli elementi embed che puntano ad un determinato tipo di contenuto:

embed[type*="shockwave"] {
  display : none ! important;
}

Il selettore usato nell'esempio � proposto nei CSS3 [WD-CSS3-selectors].

Ridimensionamento di elementi

Per evitare lo scrolling orizzontale, gli elementi pi� grandi della dimensione dello schermo devono essere scalati. I CSS2 hanno una propriet� per descrivere la larghezza massima degli elementi:

* {
  max-width: 176px ! important;
}

La precedente asserzione imposta la larghezza massima di tutti gli elementi su 176 pixel. Le immagini pi� grandi di 176 pixel verranno ridotte a 176 pixel, mentre le altre non saranno modificate.

Sommario e conclusioni

La strategia per la riformattazione del contenuto su piccoli schermi descritta in questo capitolo usa due aspetti dei CSS. In primis, la cascata viene usata per rafforzare il foglio di stile del browser sui fogli di stile dell'autore e dell'utente. In secundis, propriet� CSS come display, position, float e max-width vengono usate per descrivere la resa in modalit� small-screen. Il risultato � un browser che pu� visualizzare la maggior parte delle pagine web su un piccolo schermo.

Collegamenti a cascata

Il precedente capitolo ha descritto un modo di usare i CSS per descrivere una presentazione visuale specifica dei documenti. Questo capitolo descriver� un uso non-stilistico dei CSS.

Lo scopo dei fogli di stile � quello di descrivere la presentazione dei documenti. I linguaggi di stile assolvono questo compito associando delle propriet� e dei valori di stile agli elementi nel documento. Tuttavia, non vi � nulla di specificamente stilistico nella sintassi, e i meccanismi di trasmissione di valore dei linguaggi e dei fogli di stile possono essere allo stesso modo usati per associare altri tipi di propriet� e valori agli elementi. Come tali, i linguaggi di stile possono essere considerati come un meccanismo generico per associare coppie di propriet�/valore agli elementi. I collegamenti a cascata, o CLINK, usano i CSS come meccanismo per descrivere i collegamenti nei documenti.

Background del problema

Un tipo di informazione cruciale sul Web sono i collegamenti. In HTML, i collegamenti si trovano in determinati attributi (per esempio l'attributo href dell'elemento a) che il browser deve conoscere. L'XML generico non ha tali attributi, e sorge dunque il problema di dove collocare e trovare i collegamenti ipertestuali. XLink [XLink 2001] fu sviluppato per risolvere questo problema. XLink definisce un insieme di nuovi attributi che rappresentano collegamenti di diverso genere. Ecco un semplice esempio XLink:

<my:crossReference xlink:href="students.xml">
Current List of Students
</my:crossReference>

Nel precedente esempio, xlink:href trasforma l'elemento in un collegamento ipertestuale. XLink definisce un insieme di attributi che deve essere usato per stabilire i collegamenti.

Il Gruppo di Lavoro sull'HTML del W3C oppose resistenza al passaggio ad XLink. Il principale argomento contro l'uso di XLink era che tutti i documenti dovevano essere cambiati. Invece, si sostenne, una soluzione che descrive i collegamenti piuttosto che essere essa stessa un collegamento sarebbe stata benefica [Pemberton 2000]:

Un altro aspetto semantico importante di una pagina web, forse il pi� importante dopo la presentazione, sono i collegamenti. C'� bisogno di una sorta di 'Fogli di collegamento per il Web': un modo per dire ad una generica applicazione XML quali attributi rappresentano un collegamento, e come interpretarli.

HLink [WD-hlink] fu in seguito sviluppato per affrontare i bisogni di XHTML.

Due delle proposte discusse nel Capitolo 4 mostrano come descrivere i collegamenti nei fogli di stile. SSFP propone la propriet� click per indicare dove trovare gli URL nel documento. Vengono suggeriti due modi per descrivere il comportamento dell'attributo HTML href nell'elemento A:

(style a (click (follow (attval 'href))))
(style a (click 'follow-URL 'HREF))

SSP propone un modo per identificare le ancore e le destinazioni nel documento:

*A.anchor: !HREF
*A.target: !NAME

CLink segue lo stesso pattern di SSFP e SSP; fornisce un modo ai fogli di stile di descrivere i collegamenti nel documento.

La proposta CLink

CLink fu proposto per la prima volta nel maggio 2000 [CLink 2000a], con un aggiornamento nel novembre dello stesso anno [CLink 2000b]. La proposta non venne annunciata pubblicamente in quel periodo, ma discussa nei forum del W3C. Opera Software [Opera] ha aggiunto un supporto sperimentale a CLink, e gli esempi di questo capitolo usano la sintassi supportata da Opera.

CLink ha due funzioni di base. La prima � che un elemento pu� essere marcato come ancora sorgente, in modo che il browser pu� renderlo come un collegamento ipertestuale cliccabile. La seconda � che gli elementi possono essere marcati come rimpiazzati in modo che il contenuto dell'elemento venga rimpiazzato ad esempio da un'immagine quando il documento viene presentato all'utente.

Creare ipercollegamenti

CLink usa due propriet� per marcare un ipercollegamento [anche "collegamento ipertestuale", N.d.T.] La propriet� -o-link-source identifica l'URL dell'ancora, mentre la propriet� -o-link trasforma l'elemento in un'ancora sorgente. (Il prefisso -o delle propriet� CLink identificano le propriet� come sperimentali.) Di solito entrambe le propriet� sono usate sugli stessi elementi:

A {
  -o-link-source: attr(HREF);
  -o-link: current;
}

Nell'esempio precedente, la prima dichiarazione afferma che l'attributo HREF dell'elemento A contiene l'URL dell'ancora. L'effetto di tale dichiarazione � che ogni volta che si incontra un elemento A, l'URL viene copiato in una variabile speciale tenuta dal browser. La seconda dichiarazione afferma che l'elemento A � divenuto un'ancora sorgente e che il valore current della variabile speciale sar� l'URL dell'ancora.

L'approccio a due fasi usato per definire gli ipercollegamenti pu� sembrare complicato. Nel caso dell'elemento HTML A (descritto nell'esempio precedente), un approccio ad una sola fase avrebbe raggiunto l'obiettivo. Tuttavia, in alcuni linguaggi l'URL dell'ancora non � definito sullo stesso elemento dell'ancora sorgente, cos� la soluzione pi� semplice non sempre funzioner�. Si consideri questo esempio in WML [WML]:

<anchor>follow me
  <go href="destination"/>
</anchor>

La precedente marcatura dovrebbe avere lo stesso effetto di questa marcatura HTML:

<a href="destination">follow me</a>

L'elemento anchor WML impone una sfida, poich� l'URL dell'ancora non si trova in un attributo dell'elemento stesso, ma piuttosto in un attributo di un elemento figlio (ossia go). Clink pu� descrivere questo comportamento con:

go { -o-link-source: attr(href) }
anchor { -o-link: next }

La prima regola afferma che l'attributo href dell'elemento go contiene l'URL dell'ancora. La seconda regola trasforma l'elemento anchor in un'ancora sorgente, e afferma anche che l'URL dell'ancora si trover� nella successiva [next, N.d.T.] assegnazione della variabile di collegamento (next e current sono solo i valori della propriet� -o-link).

Elementi rimpiazzati

In HTML, le immagini e il restante contenuto non-testuale sono conservati al di fuori del documento. Per esempio, l'elemento IMG � parte della struttura del documento, ma l'elemento contiene solo un collegamento ai dati dell'immagine. Quando il documento � presentato all'utente, i dati dell'immagine vengono presi automaticamente e l'elemento IMG � sostituito dall'immagine decodificata. Come tale, l'elemento IMG � un esempio di elemento rimpiazzato. Per avere la stessa funzionalit� nei documenti scritti in XML arbitrario, ci deve essere un modo per dichiarare gli elementi rimpiazzati. In CLink, la propriet� -o-replace soddisfa questo ruolo. Si consideri il seguente esempio:

picture {
  -o-replace: attr(source)
}

Nell'esempio precedente, l'elemento fittizio picture viene rimpiazzato e il contenuto rimpiazzato verr� preso da un URL specificato nell'attributo source.

Sommario e conclusioni

CLink � un esempio di uso non stilistico dei CSS. Invece di propriet� di stile, CLink distribuisce propriet� che descrivono l'informazione di collegamento per gli elementi. In questo modo, CLink evidenzia il fatto che al di l� dei sei componenti richiesti per un linguaggio di stile (sintassi, selettori, propriet�. valori e unit�, meccanismo di trasmissione di valore e modello di formattazione), solo uno (il modello di formattazione) non ha necessariamente nulla a che fare con lo stile.

Si pu� immaginare una vasta gamma di ulteriori usi non-stilistici dei fogli di stile, e solo pochi di questi sono stati esplorati.

Ricerca futura

I fogli di stile costituiscono un'interessante area di ricerca. Oltre alle sfide intellettuali, offerte dalla maggior parte degli �mbiti di ricerca, l'autore ritiene che vi siano due motivi per cui lo studio dei fogli di stile � interessante. In primis, come scrivono Marden e Munson, i fogli di stile sono stati terribilmente poco studiati nel passato [Marden&Munson 1999]. Questo rende possibile ai giovani ricercatori di dare il loro contributo senza spendere anni a studiare quello che gli altri hanno fatto. In secundis, il Web contiene una quantit� sempre crescente di informazioni. Per rendere tali informazioni leggibili dagli esseri umani, i fogli di stile sono necessari. Perci�, in un possibile futuro, � probabile che i fogli di stile influenzino la presentazione di una significativa parte delle informazioni umane.

Questa sezione elenca delle domande a cui, si spera, la ricerca futura dar� una risposta. Ad alcune domande si pu� rispondere pi� facilmente che ad altre. Per evitare di esaminare la ricerca futura, non vi � un'ulteriore classificazione delle domande.

• Vi � un livello di astrazione ideale per i linguaggi di marcatura? Gli utenti vogliono belle presentazioni, ma anche documenti da cercare. Alcuni utenti hanno esigenze peculiari e dipendono da linguaggi di marcatura indipendenti dal dispositivo per accedere alle informazioni. Gli autori sembrano avere un limitato desiderio di accrescere la semantica dei loro documenti, ma sicuramente gradirebbero vedere il loro contenuto presentato su una vasta gamma di dispositivi. Restrizioni conflittuali come queste indicano che non vi � un unico livello ideale di astrazione, ma che i formati di documento per il Web hanno bisogno di coprire una vasta numero di gradini sulla scala di astrazione. Come influenzer� tutto questo lo sviluppo dei futuri linguaggi di marcatura?
• I fogli di stile sono in grado di descrivere la presentazione in un contesto diverso da quello dei documenti elettronici? Proprio come i linguaggi di marcatura si possono usare per altri scopi (XML ne � un tipico esempio), i linguaggi di stile possono essere usati per qualcosa di pi� rispetto alla presentazione dei documenti. Per esempio, i fogli di stile possono descrivere l'architettura? Ecco un semplicistico esempio:

  Norway Oslo Drammensvn 97 b { 
    floors: 3;
    color: #FCA;
    roof: mansard;
  }
  

• Quali altri usi non-stilistici esistono per i fogli di stile? Come la sintassi CSS e il meccanismo di trasmissione di valore sono stati usati per distribuire propriet� e valori non stilistici agli elementi (Capitolo 9), anche Daniel Glazman ha sviluppato un linguaggio trasformazionale usando una sintassi basata sui CSS [Glazman 1997]. Probabilmente vi sono molti altri usi interessanti delgi stessi meccanismi. Per esempio, si pu� facilmente pensare di usare i CSS per descrivere informationi a schema sugli elementi:

  p {
    nestable: no;
    end-tag: optional;
    legal-inside: body, div;
    attributes: href, style, class;
  }
  

• Come vengono usati i fogli di stile sul Web oggi? L'uso dei fogli di stile nelle applicazioni di word processing � stato studiato [S�rgaard 1996], ma il loro uso sul Web non � stato studiato a fondo. Quali caratteristiche dei CSS vengono usate? I fogli di stile sono usati solo per codificare quello che l'elemento FONT dell'HTML gi� rappresenta in un documento, o i siti usano i CSS per descrivere in toto il loro design?
• Pu� la cascata essere usata per risolvere altri conflitti tra utenti, programmi e autori? Per esempio, pu� la cascata essere usata per determinare le impostazioni della GUI di un'applicazione? In molti modi vi � somiglianza con la presentazione dei documenti: l'autore (il programmatore) potrebbe suggerire le impostazioni predefinite, ma all'utente dovrebbe essere data l'ultima parola. I CSS potrebbero essere usati per esprimere le preferenze dell'utente per le applicazioni?
• Le forme dei glifi possono essere prese in considerazione dai linguaggi di stile? La tipografia pubblicitaria e artistica spesso allinea i glifi in base alle loro forme. Nessun linguaggio di stile conosciuto ha cercato di descrivere la tipografia a questo livello di dettagli. Come si dovrebbe fare?
• Possono l'HTML e i CSS essere usati come formato di archiviazione per i documenti di ufficio? Le applicazioni della suite Office di Microsoft sono di solito usate per creare documenti (lettere, contratti, manoscritti), fogli di calcolo, e presentazioni proiettate. HTML e CSS possono probabilmente esprimere la maggior parte dei documenti. Inoltre, usando la caratteristica projection dei CSS2, si possono descrivere molte presentazioni proiettate. Le tabelle in HTML possono essere usate per esprimere fogli di calcolo, ma non sono in grado di codificare le relazioni tra le celle. Pu� questa funzionalit� mancante essere aggiunta in modo che, ad esempio, OpenOffice [OpenOffice] possa usare HTML e CSS come formato di archiviazione nativo?
• In che misura i produttori di browser hanno usato i fogli di stile nelle loro campagne di marketing? Che rapporto c'� tra gli sforzi nel marketing e l'effettivo livello di supporto?
• Si possono risolvere i problemi descritti nel Capitolo 7?
• XSL non � stato analizzato estesamente in questa tesi. Come si pone XSL rispetto ai linguaggi e alle proposte discussi in questa tesi?
• I futuri linguaggi di marcatura dovrebbero essere sviluppati intorno ai CSS? Nel passato, i linguaggi di stile hanno seguito i linguaggi di marcatura, e i primi, per questo motivo, dovevano essere sviluppati per funzionare con i linguaggi di marcatura. In futuro la situazione potr� cambiare: i linguaggi di marcatura potranno essere sviluppati in modo che il loro contenuto possa essere facilmente presentato con i linguaggi di stile. Per esempio, Chavchanidze [Chavchanidze 2004] ha svolto un lavoro interessante sulla rappresentazione della notazione matematica in un linguaggio basato su XML e compatibile con i CSS.
• Nel 1993 si sostenne che l'HTML sarebbe dovuto essere congelato e che si sarebbe dovuto sviluppare un nuovo linguaggio di marcatura per il Web [Dougherty 1993]. Cosa ha guadagnato (o perso) il Web facendo evolvere un HTML compatibile a ritroso piuttosto che congelarlo?

  I linguaggi di stile e le proposte discusse in queste tesi seguono tutti uno schema simile: i fogli di stile esprimono regole che associano propriet� e valori di stile agli elementi strutturali in un documento. Questa � proprio la definizione di foglio di stile proposta nella pubblicazione elettronica. Vi sono altri modelli che raggiungerebbero meglio gli obiettivi del riutilizzo del contenuto e dell'indipendenza dal dispositivo? Per esempio, un approccio basato su modelli in cui il contenuto testuale � importato in tabelle sarebbe flessibile? Le tabelle e la marcatura associata sarebbero presentazionali, ma le risorse importate potrebbero essere riutilizzate in altri contesti.

• È possibile usare i meccanismi di estensione offerti dai browser per migliorare il loro supporto ai linguaggi di stile? In particolare, � possibile estendere Microsoft Internet Explorer in modo che renda i CSS correttamente?
• Due dei linguaggi esaminati (P94, PSL96) sono basati esplicitamente su restrizioni. Ha un senso introdurre tali restrizioni ai CSS? Questo approccio fu proposto da [Badros et al. 1999]. Si pu� dire, in un certo senso, che i CSS sono gi� costruiti su restrizioni, ma pu� il linguaggio essere sviluppato ulteriormente rendendo le restrizioni pi� visibili per i designer?
• È possibile usare le restrizioni per verificare matematicamente i modelli di formattazione? Questo approccio fu proposto da [Michalowski 1998]. Per esempio, si pu� descrivere il modello di formattazione visuale dei CSS come un sistema basato su restrizioni per scoprire inconsistenze ed altri errori nello sviluppo?
• Avendo chiare le nostre conoscenze di oggi, come dovrebbe apparire il linguaggio di stile ideale?

Sommario e conclusioni

I fogli di stile, un'interessante area di studio, hanno lasciato molto spazio alla ricerca futura. Questo capitolo ha posto delle domande che possono interessare i ricercatori in futuro.

Conclusioni

Questo capitolo descrive, in forma sintetica, quello che credo si possa imparare da questa tesi.

L'ipotesi che sottintende la tesi � che il Web richiede linguaggi di stile diversi da quelli della tradizionale pubblicazione elettronica. Credo che si sia dimostrato che tale ipotesi � vera. L'introduzione ha delineato le caratteristiche uniche del Web come ambiente di pubblicazione, e queste caratteristiche sono state formulate come requisiti per un linguaggio di stile per il Web nel Capitolo 5 (Requisiti del Web). Nessuno dei linguaggi di stile sviluppati prima del Web soddisfa – o si avvicina a soddisfare – i requisiti del Web e, perci�, sembra ragionevole concludere che l'ipotesi � corretta.

Si potrebbe affermare che, anche se veniva richiesto un linguaggio diverso, non era necessario sviluppare un nuovo linguaggio. Una versione modificata di un linguaggio esistente sarebbe stata sufficiente. Questo approccio fu adottato da DSSSL Lite, come discusso nel Capitolo 4. Retrospettivamente, ritengo che una versione modificata di FOSI sarebbe potuta essere adattata con successo all'uso sul Web, ma che non avrebbe avuto dei vantaggi significativi sui CSS. Al contrario i CSS, – essendo sviluppati specificamente per il Web, accettando al contempo la lezione di linguaggi di stile come DSSSL – sono in grado di soddisfare i requisiti del Web.

Inoltre, la tesi descrive cinque importanti contributi a questo campo di studi: la divisione dei linguaggi di stile in sei componenti richiesti; la descrizione dei requisiti del Web per i linguaggi di stile; l'analisi comparata dei differenti linguaggi di stile e delle differenti proposte; la scala di astrazione e i CSS stessi.

• Per comparare differenti linguaggi di stile, � necessario stabilire criteri comuni con cui giudicare tali linguaggi. Il Capitolo 3 descrive un insieme di criteri per i linguaggi di stile con sei componenti richiesti: sintassi, selettori, propriet�, valori e unit�, un meccanismo di trasmissione di valore, e un modello di formattazione.
• Questa tesi fornisce la prima analisi comparativa estesa dei linguaggi di stile. I linguaggi sviluppati prima del Web, e le proposte sviluppate per il Web, sono stati valutati in base ai sei componenti richiesti di un linguaggio di stile. Inoltre tutti i linguaggi e le proposte sono stati valutati rispetto ad un insieme di requisiti del Web.
• Il Web aggiunge nuovi requisiti per i linguaggi di stile. Tra i requisiti descritti in questa tesi vi sono il bisogno di essere basati sul flusso, e di supportare il design incentrato sullo schermo.
• La scala di astrazione viene proposta come metodo di valutazione dei formati di documento elettronico. L'altezza di un determinato formato di documento sulla scala determiner� la complessit� nel formattare il documento per la presentazione. Poich� la formattazione di un documento � specificata da un foglio di stile, il livello di astrazione dei documenti di destinazione � cruciale per il successo di un linguaggio di stile. Inoltre la scala di astrazione � utile quando si valuta l'accessibilit� dei vari formati di documento.

  Quando si sviluppano nuovi formati di documento, perci�, si dovrebbe sempre tener presente come verranno presentati i documenti scritti nel nuovo formato. Definire la sintassi per un formato di documento � abbastanza semplice se paragonato al compito di sviluppare un meccanismo di presentazione per tale formato.

• I CSS hanno alcune caratteristiche uniche ed innovative, tra cui la cascata, gli pseudo-elementi e le pseudo-classi, il parsing compatibile nel futuro, e i tipi di media. Fino ad oggi, i CSS si sono affermati come una delle specifiche fondamentali sul Web e molti siti li usano. Come tali, gli sforzi per creare un linguaggio di stile per il Web hanno avuto successo. Inoltre i CSS hanno parzialmente soddisfatto la loro ambizione di mantenere l'HTML un linguaggio di marcatura strutturato e di assicurare che gli utenti possano dare uno stile ai documenti. Ma, a causa del limitato supporto ai CSS da parte del browser predominante sul Web, i CSS non possono essere sfruttati appieno.

Oltri ai contributi principali elencati poc'anzi, l'autore � giunto a ritenere – durante il corso del lavoro – che quanto segue sia vero:

• Nel passato i documenti strutturati hanno sofferto di una carenza di linguaggi di stile. Mentre chi proponeva i documenti strutturati, in particolare SGML, sosteneva la propria tesi e in seguito sviluppava modi per creare documenti strutturati, ben poca attenzione fu prestata alla presentazione dei documenti.
• L'HTML ha il giusto livello di astrazione per un linguaggio di marcatura con scopo generico: � abbastanza alto sulla scala di astrazione per supportare la presentazione su un'ampia gamma di dispositivi, e abbastanza basso per far comprendere facilmente alla gente il significato degli elementi.

  Scribe, pi� che SGML, sarebbe stato probabilmente un punto di partenza migliore per lo sviluppo dell'HTML. Scribe offre il meglio dell'HTML (c'� un insieme predefinito di tag e convenzioni su come presentarli), dei CSS (c'� un insieme predefinito di convenzioni presentazionali che possono essere modificate), e di XML (si possono creare nuovi elementi). Inoltre Scribe � molto pi� semplice di SGML. D'altro canto ci sarebbero potuti essere problemi legali con l'uso di Scribe, e il sistema di presentazione di Scribe non si sarebbe potuto evolvere in un linguaggio di stile che soddisfi i requisiti del Web.

• Gran parte dei linguaggi di stile proposti per il Web contenevano alcune caratteristiche innovative. Alcune di queste caratteristiche furono in seguito introdotte nei CSS, ma la maggior parte no. Ci sono validi motivi per non includere tutte le caratteristiche suggerite, poich� le specifiche risultanti diverrebbero troppo complesse e potrebbero avere funzionalit� in conflitto. Tuttavia, alcune delle idee proposte avrebbero migliorato i fogli di stile per il Web e ritengo sia stato infelice il fatto che i CSS non li abbiano inclusi. In particolare, le unit� di lunghezza relative al display (pcd, nlh, p) proposte da JEP sarebbero state un utile aggiunta.
• I linguaggi di stile trasformazionali possono essere adatti in ambienti di pubblicazione tradizionali, ma non sono adatti al Web. Questo � dovuto soprattutto al fatto di non essere in grado di supportare la resa progressiva.
• Le specifiche possono fallire per vari motivi. Una delle specifiche citate in questa tesi, ODA, ha tre significativi fattori contrari: la complessit�, l'uso di un sistema di codifica binario, e il fatto di non essere liberamente disponibile. Invece le specifiche dovrebbero essere semplici, il linguaggio descritto dovrebbe essere facile da leggere e da scrivere, e le specifiche dovrebbero essere liberamente disponibili.
• Avere una mailing list aperta al pubblico � molto importante per lo sviluppo di nuove specifiche. Tale mailing list attrarr� persone di talento con idee nuove, e consentir� agli autori e ai curatori delle specifiche di esprimere il loro pensiero. Nel caso dei CSS, si � formata una comunit� intorno alla mailing list www-style. Per un'analisi retrospettiva, come questa tesi, gli archivi di una mailing list forniscono considerevoli informazioni.
• L'interoperabilit� � uno dei traguardi primari per le specifiche web. Accanto alle specifiche stesse, una completa suite di test � lo strumento pi� importante per assicurare l'interoperabilit�. Retrospettivamente, l'introduzione dei CSS sul Web sarebbe stata pi� facile e veloce se una suite di test fosse stata sviluppata contemporaneamente alle specifiche.