Fogli di stile a cascata

Håkon Wium Lie

Traduzione di Gabriele Romanato

Originale: http://people.opera.com/howcome/2006/phd/

Nota del traduttore

Tesi presentata per il titolo di laurea di Doctor Philosophiae
Facoltà di Matematica e Scienze Naturali
Università di Oslo
Norvegia
2005

© Håkon Wium Lie, 1994-2005

Quest'opera è distribuita sotto la Creative Commons Attribution-NonCommercial 2.5 License.

Presentata il 29 marzo 2005, come parziale conseguimento del titolo di
Doctor Philosophiae
Presso la Facoltà di Mathematica e Scienze Naturali
Università di Oslo
Norvegia

Serie di dissertazioni presentate alla Facoltà di Matematica e Scienze Naturali, Università di Oslo.
No. 498

ISSN 1501-7710

Sommario

L'argomento di questa tesi sono i linguaggi dei fogli di stile per i documenti strutturati sul Web. A causa delle caratteristiche del Web – fra cui un modello di pubblicazione schermo-centrico, una moltitudine di dispositivi di output, incerta distribuzione, forti preferenze dell'utente, e la possibilità di un successivo legame fra contenuto e stile – l'ipotesi è che il Web richiede differenti linguaggi di stile rispetto alla tradizionale pubblicazione elettronica.

I linguaggi dei fogli di stile sviluppati e usati prima del Web sono analizzati e comparati con le proposte di fogli di stile per il Web nel periodo che va dal 1993 al 1996. La dissertazione descrive la concezione e lo sviluppo di un linguaggio di stile web-centrico conosciuto come Fogli di Stile a Cascata (CSS). I CSS hanno diverse caratteristiche importanti, fra cui: cascata, pseudo-classi e pseudo-elementi, regole di parsing compatibili nel futuro, supporto per diversi tipi di media, e una forte enfasi sui selettori. Vengono analizzati i problemi nei CSS, e viene descritta la futura ricerca che si raccomanda.

Ispirazione

I fogli di stile costituiscono il foro di un tarlo su indicibili universi. –James D Mason, 1994
I linguaggi di stile sono terribilmente poco studiati. –Philip M Marden, Ethan V Munson, 1999
In quale forma hai pensato di pubblicare la prima edizione del Parsifal? Anche se mi piacciono i caratteri latini, temo che siano impopolari (sopratutto fra gli editori). Così, se i caratteri saranno tedeschi, ti prego di farli grandi e di buona qualità. La leggibilità di un testo è molto importante per me. –Richard Wagner, in una lettera al suo editore Ludwig Strecker

Tavola dei contenuti

Elenco delle immagini

  1. La scala di astrazione.
  2. Eredità e grafico di flusso di default in FOSI.
  3. Il documento d'esempio PWP reso in Viola.
  4. Il box model CSS.
  5. Due differenti stili di contatori.

Elenco delle tabelle

  1. Confronto di formati di documento sulla scala di astrazione.
  2. Le ambizioni e i risultati di sei diversi sistemi strutturati di  documento .
  3. Ambienti comuni offerti in Scribe.
  4. Le categorie di FOSI.
  5. Oggetti di flusso di DSSSL e proprietà associate.
  6. Proprietà di P94.
  7. Categorie e proprietà di RRP.
  8. Confronto delle categorie in FOSI e RRP.
  9. Confronto della categoria dei font in RRP e FOSI.
  10. Proprietà di JEP.
  11. Categorie in JEP.
  12. Proprietà di SSFP con gli equivalenti CSS.
  13. Le proprietà di DSSSL Lite.
  14. Il numero delle classi e delle proprietà degli oggetti di flusso in DSSSL Lite, DSSSL-O e DSSSL.
  15. Proprietà proposte da SSP.
  16. Valutazione di come i diversi linguaggi di stile e le proposte si comportano rispetto ai requisiti del Web.
  17. Selettori nei CSS1.
  18. Selettori aggiunti nei CSS2.
  19. Proprietà nei CSS1.
  20. Proprietà introdotte nei CSS2.
  21. I CSS valutati rispetto ai requisiti del Web.

Riconoscimenti

Dopo aver sfogliato rapidamente un bel numero di dissertazioni di dottorato, credo che i riconoscimenti siano una delle sezioni più lette. È dove l'autore, per un breve istante, può distogliere la mente dall'aridità del documento accademico per esprimere anni di frustrazione e gratitudine accumulate. Avendo lavorato ai fogli di stile a cascata (CSS) per dieci anni, ho avuto la mia parte di frustrazione e gratitudine. Cercherò di esprimere quest'ultima a parole, mentre la frustrazione sarà lasciata nell'interlinea. I termini in grassetto sono spiegati nel Glossario.

La mia gratitudine va innanzitutto ai miei genitori, Sissel e Alfred Lie. Mio padre è un bell'esempio accademico, avendo conseguito il suo PhD all'età di 50 anni ed il fatto che io lo stia battendo di dieci anni o giù di li è un complemento per lui piuttosto che per me. L'amore di mia madre per le pubblicazioni e il suo sistema estensivo di raccolta delle informazioni a schede hanno contribuito alla mia necessità di tenere i miei appunti in ordine. Con il presente documento lascio la sfida di battere il loro padre in un PhD ai miei figli. O, almeno, a tenere in ordine i loro appunti.

Due persone davvero speciali meritano in particolare di essere citate e ringraziate; senza di loro, questa tesi non esisterebbe. Bert Bos si unì a me quando i furono abbozzati, ma erano ancora un insieme di idee immature piuttosto che delle specifiche coerenti. Durante alcune settimane attorno ad una lavagna nell'estate del 1995, i CSS furono elaborati. Ricorderò sempre quel periodo a Sofia-Antipoli come alcuni dei migliori giorni della mia vita. Karen Mosman è il mio editore, musa e partner. La sua durevole lealtà verso i miei scritti e la mia persona ha portato a dei cambiamenti in meglio per entrambi. I miei scritti e la mia persona, questo è; Karen stessa è praticamente perfetta.

Il World Wide Web Consortium (W3C) è stata un ottima casa per i CSS. Ringrazio Tim Berners-Lee e Jean-Francois Abramatic per aver creato le strutture organizzative per far si che accadesse. Tim merita anche un ringraziamento speciale per aver inventato il Web senza brevettarlo, e per aver lasciato un divario stilistico da colmare. Fra i miei colleghi del W3C che sono stati fondamentali per supportare l'opera nei primi tempi ci sono Dave Raggett e Dan Connolly. Il browser di Dave, chiamato in seguito Arena, ha fornito la base perfetta per i test sui CSS. Dan – dopo una iniziale, salutare resistenza – mi ha supportato presentando i CSS alla W3C HTML Editorial Review Board (ERB) che co-dirigeva con Dave.

Un piccolo aneddoto dal meeting dell'ERB nell'aprile 1996 merita di essere citato. Poichè io ero lì soprattutto per presentare i CSS piuttosto che per prendere parte alle discussioni sull'HTML, mi fu dato l'incarico di stendere le note della riunione. Accadde così che il nome della successiva versione dell'HTML fu deciso in quel meeting. Spero che mi si perdonerà se pubblico un estratto (anonimo) dalle note:

Il problema principale venne sollevato, e il meeting passò
al brainstorming. Le proposte si divisero in tre gruppi:
 - numeri di versione: 3.1, 3.2, 3.5, 4.0
 - nomi in codice: Wilbur, Classic HTML, Unified HTML, 
   Common HTML, W3C HTML
 - composti: HTML96, W3C HTML4
Alla fine si preferirono i numeri di versione. NN 
sosteneva che Wilbur fosse un cambiamento maggiore che meritava un nuovo numero 
maggiore: 4.0. Agli altri non piaceva lo zero nel nome. 
"HTML 3.2" fu scelto dopo discussioni e votazioni.

Così, casualmente, fui la prima persona a digitare l'ormai celebre stringa HTML 3.2 su un computer. Poche battiture di tasti per un uomo, un passo da gigante per il Web.

Nel W3C, il CSS Working Group è stato il custode della fiamma. Alcune persone altamente intelligenti e motivate si sono unite al gruppo negli anni. Vorrei ringraziare specialmente Ian Hickson, David Baron, Tantek Çelik, Daniel Glazman e Eric Meyer. Inoltre, Steven Pemberton presiedette il primo W3C Workshop sui fogli di stile, Chris Lilley lo guidò per molti anni, e Ian Jacobs contribui ai suoi editoriali. Sono grato a tutti voi.

Nel 1999, quando erano stati scritti i CSS1 e CSS2, mi unii ad Opera Software per assicurare che le specifiche fossero implementate correttamente da almeno un browser. Ringraziamenti vanno a Jon von Tetzchner e Geir Ivarsøy per aver fondato una società per cui è cosa meritevole lavorare. Geir, insieme con Karl Anders Øygard, è anche la mente dietro al motore di Opera che fa splendere i CSS sugli schermi di ogni dimensione. Ringraziamenti vanno anche a Snorre Grimsby, Rijk van Geijtenbeek, Brian Wilson e Sue Sims per aver supportato i CSS internamente ed esternamente.

Molte persone sono state d'aiuto nella stesura della tesi. Sono in debito con Paul Grosso, Vincent Quint, Pamela Gennusa, Ethan Munson, Joe English, Harvey Bingham, Paul Prescod, Jany Quintard, Yann Dirson, Dave Pawson, Ian Castle, Didier P. H. Martin, Geir Ove Grønmo e Bette Harvey per aver risposto alle mie molte domande sul passato. Sono grato a Joe English, Wayne Gramlich, James Mason, Jeff Moore e Dan Connolly per avermi concesso di fare citazioni dai loro scritti inediti. Gunilla Petersén dell' Opera Reale di Svezia mi ha guidato alla citazione ispiratrice da Wagner.

Questa tesi tratta delle proposte di fogli di stile per il Web. Sono grato agli autori delle proposte per aver contribuito ad un argomento molto interessante della ricerca. Avendo analizzato le loro proposte senza aver accesso alle loro menti, posso aver frainteso o mal interpretato il loro lavoro. Se è così, vi prego di contattarmi. Ringraziamenti vanno anche ai partecipanti delle mailing list www-talk, www-html e www-style. Senza le comunità formatesi sulle mailing list, il Web non sarebbe come lo conosciamo oggi.

I CSS hanno preso in prestito molte idee dal MIT Media Lab dove ho trascorso due anni di formazione. Grazie a Walter Bender e Andy Lippman per avermi illustrato queste idee. All'università di Oslo, Ole Hanseth e Gisle Hannemyr mi hanno incoraggiato a mettere i miei appunti in forma di tesi, e consigliato su come ciò andava fatto. Senza di loro i miei appunti sarebbero ancora sparsi.

Sono grato ad Anthea Vaughan per aver pazientemente copiato e corretto le mie bozze.

Vorrei ringraziare le persone che hanno creato FrameMaker, GNU-emacs, e il formattatore Prince. FrameMaker mi ha insegnato la tipografia, GNU-emacs ha accettato con eleganza tutti i miei tag stesi a mano, e Prince ha messo questa tesi sulla carta.

Oslo, marzo 2005
Håkon Wium Lie

Sguardo d'insieme e sommario della tesi

L'argomento della tesi sono i linguaggi di stile per documenti strutturati sul Web. L'ipotesi è che il Web richiede linguaggi di stile differenti da quelli della tradizionale pubblicazione elettronica. Inoltre viene descritto lo sviluppo di un linguaggio di stile che soddisfi i requisiti specifici del Web, ossia i fogli di stile a cascata. La tesi può essere divisa in una parte sul perchè (capitoli 1-5), in una sul come (capitoli 6-9), e i futuri sviluppi (capitolo 10).

Capitolo 1: Introduzione

Il primo capitolo è un'introduzione all'argomento della tesi e agli argomenti correlati. Viene descritto il contesto storico in cui furono sviluppati i CSS, incluso lo sviluppo dell'HTML, dalle sue radici nei documenti strutturati fino ai tag presentazionali introdotti dai vari browser. Vengono introdotti concetti chiave come i documenti strutturati, i fogli di stile e la cascata.

Capitolo 2: documenti strutturati

I linguaggi di stile e i documenti strutturati sono reciprocamente dipendenti. 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. Il capitolo 2 inizia introducendo la scala di astrazione proposta come strumento di misurazione per i formati dei documenti strutturati. Vengono descritti questi formati sviluppati prima del Web (Scribe, LaTeX, ODA, SGML) e per il Web (HTML, XML). Infine viene discusso il ruolo dei linguaggi trasformazionali contro i linguaggi di stile.

Capitolo 3: fogli di stile prima del Web

Il capitolo 3 è il primo capitolo in cui i fogli di stile vengono discussi con qualche dettaglio. La prima parte del capitolo definisce un insieme di criteri per i linguaggi di stile; per qualificare un linguaggio di stile devono essere presentati sei componenti: sintassi, selettori, proprietà, valori e unità, trasmissione di valore e un modello di formattazione. Vengono presentati tre linguaggi di stile sviluppati prima del Web (FOSI, DSSSL e P94). Il quadro storico di ciascuno è seguito da una spiegazione tecnica.

Capitolo 4: proposte di fogli di stile per il Web

Questo capitolo è una summa dei linguaggi di stile proposti per il Web nel periodo 1993-1996. Vengono esaminate nove diverse proposte secondo i criteri stabiliti nel precedente capitolo.

Capitolo 5: requisiti del Web

Publicare sul Web è diverso da altri tipi di pubblicazione elettronica. Nel capitolo 5 vengono discussi sei requisiti specifici per il Web. Nessuno dei linguaggi di stile precedenti al Web nè le successive proposte di linguaggi di stile soddisfano tutti i requisiti per la pubblicazione sul Web.

Capitolo 6: fogli di stile a cascata

Questo capitolo apre la sezione come della tesi. In questo capitolo i fogli di stile a cascata (CSS) sono discussi in dettaglio, e il linguaggio è valutato secondo i criteri stabiliti nel capitolo 3. I CSS sono anche valutati rispetto ai requisiti del Web discussi nel capitolo 5.

Capitolo 7: problemi nei CSS

Questo capitolo descrive i problemi interni e quelli correlati alle specifiche CSS. Il capitolo spazia dai semplici errori di sintassi fino a questioni più complesse, come ad esempio se una funzionalità soddisfa il ruolo per cui è stata concepita. Il capitolo è organizzato liberamente lungo un asse di complessità; la prima parte descrive la gestione degli errori semplici. Quindi vengono discussi problemi reali e manifesti nelle specifiche. L'ultima sezione è dedicata ai problemi nel meccanismo della cascata.

Capitolo 8: CSS per piccoli schermi

Questo capitolo descrive il modo in cui la cascata può essere usata per rendere pagine web su piccoli schermi. Dando un foglio di stile per il browser sviluppato con cura, le pagine web vengono riformattate in strette colonne per evitare lo scrolling orizzontale

Capitolo 9: collegamenti a cascata

Viene discusso in questo capitolo un nuovo utilizzo dei CSS per rappresentare informazioni ipertestuali piuttosto che informazioni di stile. I collegamenti a cascata rendono possibile lo sviluppo di nuovi linguaggi di marcatura con collegamenti ipertestuali senza che i programmi utente conoscano la codifica di queste informazioni di collegamento.

Capitolo 10: ricerca futura

Questo capitolo illustra quelle aree della ricerca e dello sviluppo futuro che con ogni probabilità daranno positivi risultati.

Capitolo 11: conclusioni

Le conclusioni sostengono l'argomento della tesi: per le sue caratteristiche, il Web necessita di linguaggi di stile diversi da quelli della tradizionale pubblicazione elettronica. Sono elencati i contributi principali della tesi: la scala di astrazione, i componenti di un linguaggio di stile, i requisiti del Web per i linguaggi di stile e i CSS.

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.

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.

La scala di astrazione.

La scala di astrazione. Illustrazione ripresa da Hayakawa [Hayakawa 1940].

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:

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:

Comparazione di formati di documento sulla scala di astrazione.

GIF, PNG vocabolario XML
privato
PDF XSL-FO HTML MathML
semantica per una-
specifica applicazione?
no no no no no si
indipendente dal dispositivo? no no no no si si
regole conosciute? no no no no si si
testo in ordine logico? sconosciuto sconosciuto no si si si
riflusso possibile? no sconosciuto no si si si
scalabile? no sconosciuto si si si si
testo leggibile dalla macchina? no si si si si si
testo leggibile dall'uomo? si si si si si si

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

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.

Le ambizioni e i traguardi dei sei diversi sistemi di documento strutturato.

È principalmente un sistema per definire nuovi linguaggi? Ha il concetto di semantica del documento? Ha il concetto di presentazione del documento? Codi-
fica
Riferimento Livello di complessità Traguardo principale
Scribe no si si testo implementazione moderato ha ispirato LaTeX
LaTex no si si testo implementazione moderato de facto il formato delle pubblicazioni scientifiche
ODA no si si binaria specifiche alto è diventato uno standard ISO
SGML si no no testo specifiche alto è diventato uno standard ISO, ha ispirato HTML e XML
HTML no si qualche testo specifiche & implementazione moderato formato ipertestuale universalmente compreso
XML si no no testo specifiche moderato base sintattica per i formati emergenti

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:

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.

Ambienti comuni offerti in Scribe.

Ambiente Elemento HTML corrispondente Funzionalità CSS corrispondente Commento
B B font-style: bold
C font-style: small-caps
Center CENTER text-align: center
Description DL questo ambiente sembra fornire una formattazione simile all'elemento DL dell'HTML
Display questo ambiente rispetta le interruzioni di riga e aggiunge un margine sinistro extra
Enumerate UL
Example PRE aggiunge margini extra
FileExample PRE
FlushLeft text-align: left
FlushRight text-align: right
Format usato per la formattazione tabulare
G usa un font greco
Group page-break: avoid
Heading H2
I I
Itemize UL
MajorHeading H1
Multiple DIV si veda l'esempio sotto.
O text-decoration: overline
P BI font-weight: bold; font-style: italic
ProgramExample per esempi di programmi di computer con uso corrispondente dei font
Quotation BLOCKQUOTE margin: 1em aggiunge margini su tutti i lati
R font-family: serif tipo di font romano ordinario
Subheading H3
T tt font-family: monospace
Text L'ambiente predefinito
U U text-decoration: underline sottolinea tutti i caratteri non vuoti
UN sottolinea solo lettere e cifre
UX sottolinea tutti i caratteri, spazi compresi
Verbatim usato per formattazione tabulare con font monospaziati
Verse concepito per la poesia e per il testo dove lo spazio bianco dovrebbe essere rispettato
W white-space: nowrap tratta il testo come un'unica parola, ossia una sequenza non interrotta di caratteri

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:

Ci sono anche notevoli differenze tra i due sistemi:

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.

Open Document Architecture (ODA)

Open Document Architecture è un insieme di standard ISO che descrivono formati per la rappresentazione e lo scambio di documenti strutturati. Iniziò sotto il nome di Office Document Architecture negli anni '80, e il nome cambiò in Open Document Architecture negli anni '90 quando i risultati furono pubblicati come standard ISO [ODA][Appelt 1991][Rosenberg et al. 1991].

Come il modello OSI di ISO [OSI], ODA ha avuto grande influenza senza essere esso stesso molto usato. ODA, insieme con gli altri sistemi descritti in questo capitolo, sostenne l'idea della separarazione della rappresentazione logica del contenuto dalla sua presentazione fisica. Tuttavia, ODA fece diversi passi i avanti rispetto agli altri sistemi. Diversamente da SGML e XML, ODA descrive anche la presentazione dei documenti. Paragonato a LaTex, Scribe e HTML, ODA si distingue, per esempio, per la standardizzazione dei formati delle immagini.

ODA fu sviluppato da un consorzio societario dove, tra gli altri, erano membri IBM, DEC, Unisys, Bull e Unisys. Ancora: molti ricercatori accademici presero parte allo sviluppo di ODA. Nel 1991 la comunità era molto ottimists sul futuro di ODA [Sherman 1991]:

ODA è uno degli standard a livello applicativo nel modello OSI che inizia a crescere e a svilupparsi. ODA sarà adottato in una varietà di altri standard per venire incontro ad un crescente insieme di bisogni.

Tuttavia, ODA non ebbe mai il successo che i suoi sostenitori speravano, e non fu mai usato al di là di progetti pilota. Ci sono diverse ragioni per questo. In primis, ODA è un insieme complesso di specifiche. Risulta difficile comprendere le specifiche ed è difficile scrivere sotware per supportarle. In secundis, ODA e SGML venivano sentiti in competizione tra di loro e la comunità dei documenti strutturati non appoggiò mai completamente ODA. La differenza negli scopi tra ODA e SGML è significativa: ODA è un formato di documento che descrive la sintassi, la struttura e la presentazione dei documenti, mentre SGML è un sistema per definire la sintassi per i linguaggi di marcatura. Essi vengono ancora sentiti in conflitto tra di loro [Watson&Davis 1991]. Di seguito è riportata una considerazione retrospettiva fatta dal presidente della commissione (ISO JTC1 SC) che definì lo standard SGML [Mason 2001]:

I conflitti tra SGML e ODA occupavano troppo del nostro tempo e produssero un'atmosfera di paranoia tra le parti di diversi nostri membri. A lungo andare, ODA morì e SGML vinse, ma da allora le forze che condussero all'XML stavano già spingendo le persone fuori dal SC34. L'effetto tecnico su SGML fu misto: portò sia a CONCUR che ad Architectural Forms. L'effetto umano fu molto più pericoloso.

Il fatto che ODA non sia mai stato usato lo rende difficile da esaminare. Pochi documenti ODA sono stati creati per il fatto che il software non fu mai scritto. A differenza degli altri sistemi descritti in questo capitolo, ODA usa una codifica binaria e gli esempi sono perciò difficili da inserire nelle descrizioni testuali degli standard. Ancora: è difficile esaminare ODA poichè le specifiche non sono liberamente disponibili.

Invece di cercare di fare una rivisitazione accademica di ODA, evidenzio il suo ruolo nella storia e lascio ai ricercatori dopo di me di fare quella rivisitazione che credo ODA meriti.

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:

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:

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:

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:

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:

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:

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:

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:

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è:

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:

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

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.

Categorie di FOSI.

Categoria Proprietà Funzionalità CSS corrispondente
font style, famname, size, posture, weight, width, smallcap, offset Corrisponde all'incirca alle proprietà font- nei CSS.
interlinea lead, force Corrisponde all'incirca a line-height nei CSS.
trattino (divisione) lang, hyph, zone I CSS2 non hanno funzionalità per la divisione. L'attributo lang di HTML e XML può esprimere la lingua.
wordsp (word spacing) e lettersp (letter spacing) minimum, nominal, maximum Corrisponde a word-spacing e letter-spacing nei CSS, ma i CSS possono esprimere solo valori nominali.
sentxsp (sentence spacing) minimum, nominal, maximum Nessuna funzionalità simile nei CSS, poichè è molto difficile determinare programmaticamente cosa è una frase.
lettersp (letter spacing) minimum, nominal, maximum, kerntype, kernpair Alcuni effetti possono essere raggiunti con la proprietà letter-spacing nei CSS.
indentazione leftind, rightind, firstln Effetti simili possono essere raggiunti con margin e text-indent nei CSS (ma si veda il "modello di pagina" più avanti per una discussione delle differenze).
quadding quad, lastquad Simile a text-align nei CSS.
highlt (highlight) reverse, scoring, scorewt, scoreoff, scorechron, scorechr, bckclr (background color), fontclr (font color), bckpct, forpct, allcap, scorespc Effetti simili possono essere raggiunti con color, background, e text-decoration nei CSS.
chgmark (change marks) literal, barthick, baroffset, join, type, cmclass Non c'è nessuna funzionalità simile nei CSS.
prespace/postspace minimum, nominal, maximum, condit, priority Gli stessi effetti possono essere raggiunti con margin, padding, page-break-before, e page-break-after nei CSS
keeps keep, scope, widowct, orphanct, next, prev, floatsout Corrisponde a page-break-inside, widow, e orphan nei CSS.
vjinfo (vertical justification) presppr, postsppr, keepspr Corrisponde alla proprietà vertical-align nei CSS.
textbrk (textbreak) startcol, startpg, resumepg, pageid, newpgmdl, startln, endln Corrisponde a page-break-before, page-break-after nei CSS.
span span La proprietà span descrive come gli elementi si estendono su diverse colonne.
bordo bordname La proprietà bordname punta ad un definizione di bordo per livello di pagina.
float flidref (un riferimento a una posizione di float), width, widowht, orphanht, scope, pagetype (same, facing ecc.), inline, multirefname Queste proprietà descrivono come il contenuto possa flottare verso altre parti del documento. Per esempio, gli elementi possono flottare sulla parte superiore delle pagine anteriori. Non c'è una funzionalità simile nei CSS.
algroup (alignment group) refpoint (top, first, middle, last, bottom), postspace Queste proprietà sono usate per allineare gli elementi uno accanto all'altro, simili alla proprietà float nei CSS.
suppress sup La proprietà sup ha un valore intero da 0 a 5 che indica un livello di soppressione del contenuto. Nei CSS, il valore none della proprietà display può essere usato per indicare la soppressione del contenuto.
boxing toffset, boffset, loffset, roffset, trel, brel, siderel, leftgap, rightgap, thick, ttype, btype, ltype, rtype, inclr, inpct, outclr, outpct Queste proprietà descrivono il boxing del contenuto. Questa funzionalità è descritta nelle proprietà background, padding, e border.
link sysid, targdocent, targid, endtargid, linktype, uselink, usetargid, useendtargid Queste proprietà descrivono vari aspetti dei link. Non c'è una funzionalità simile nei CSS.
linkproc loprocess, exloproc, loconrule, liprocess, exliproc, liconrule Queste proprietà descrivono vari aspetti dei link. Non c'è una funzionalità simile nei CSS.
reset resetlist Simile alla proprietà counter-reset nei CSS
enumerat (enumeration) increm, enumid, setvalue Simile alla proprietà counter-increment nei CSS
ruling thick, lentype, speclen, rellen, voffset, placemnt, ruleclr, rulepct, type Queste regole descrivono l'aspetto e il posizionamento delle regole orizzontali. I CSS possono solo descrivere se una regola orizzontale dovrebbe essere presente o no.
puttext literal, placemnt Queste funzionalità è simile al testo (contenuto) generato nei CSS2.
putgraph graphname, width, depth, placemnt, scalefit, hscale, vscale, hoffset, voffset, rotation I CSS si affidano alla marcatura per aggiungere grafica esterna.
savetext textid, conrule, placemnt, append Descrive il contenuto testuale da salvare per uso in altro luogo. I CSS non hanno una simile funzionalità.
usetext source, placemnt, userule, userparam Descrive cosa fare col testo salvato da una parte del documento. Non c'è una simile funzionalità nei CSS.

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.

Complesso diagramma che mostra il flusso di eredità e di defaulting in FOSI

Diagramma del flusso di eredità e di defaulting in FOSI.

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:

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:

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:

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.

Oggetti di flusso DSSSL e proprietà associate.

Oggetto di flusso Proprietà
Sequence nessuna, questo è un contenitore per altri oggetti di flusso
Display-group coalesce-id, position-preference, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?
Simple-page-sequence page-width, page-height, left-margin, right-margin, top-margin, bottom-margin, header-margin, footer-margin, left-header, center-header, right-header, left-footer, center-footer, right-footer, writing-mode
Page-sequence initial-page-models, repeat-page-models, force-last-page, force-first-page, blank-back-page-model, blank-front-page-model, justify-spread?, page-category, binding-edge
Column-set-sequence column-set-model-map, column-set-model, position-preference, span, span-weak?, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?
Paragraph lines, asis-truncate-char, asis-wrap-char, asis-wrap-indent, first-line-align, alignment-point-offset, ignore-record-end?, expand-tabs?, line-spacing, line-spacing-priority, min-pre-line-spacing, min-post-line-spacing, min-leading, first-line-start-indent, last-line-end-indent, hyphenation-char, hyphenation-ladder-count, hyphenation-remain-char-count, hyphenation-push-char-count, hyphenation-keep, hyphenation-exceptions, line-breaking-method, line-composition-method, implicit-bidi-method, glyph-alignment-mode, font-family-name, font-weight, font-posture, font-structure, font-proportionate-width, font-name, font-size, numbered-lines?, line-number, line-number-side, line-number-sep, quadding, last-line-quadding, last-line-justify-limit, justify-glyph-space-max-add, justify-glyph-space-max-remove, hanging-punct?, widow-count, orphan-count, language, country, position-preference, writing-mode, start-indent, end-indent, span, span-weak?, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?
Paragraph-break La caratteristica "first-line-start-indent" si applica alla riga che segue un oggetto di flusso paragraph-break, e la caratteristica "last-line-end-indent" si applica alla riga che precede un oggetto di flusso paragraph-break.
Line-field field-width, field-align, writing-mode, inhibit-line-breaks?, break-before-priority, break-after-priority
Sideline sideline-side, sideline-sep, color, layer, line-cap, line-dash, line-thickness, line-repeat, line-sep
Anchor anchor-keep-with-previous?, display?, span, span-weak?, inhibit-line-breaks?, break-before-priority, break-after-priority
Character char, char-map, glyph-id, glyph-subst-table, glyph-subst-method, glyph-reorder-method, writing-mode, font-family-name, font-weight, font-posture, math-font-posture, font-structure, font-proportionate-width, font-name, font-size, stretch-factor, hyphenate?, hyphenation-method, kern?, kern-mode, ligature?, allowed-ligatures, space?, inline-space-space, escapement-space-before, escapement-space-after, record-end?, input-tab?, input-whitespace-treatment, input-whitespace?, punct?, break-before-priority
Leader length, truncate-leader?, align-leader?, min-leader-repeat, inhibit-line-breaks?, break-before-priority, break-after-priority
Embedded-text direction, language, country, inhibit-line-breaks?
Rule orientation, length, color, layer, line-cap, line-dash, line-thickness, line-repeat, line-sep, position-point-shift, inhibit-line-breaks?, break-before-priority, break-after-priority, display-alignment, start-indent, end-indent, writing-mode, span, span-weak?, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?
External-graphic display?, scale, max-width, max-height, entity-system-id, notation-system-id, color, layer, position-preference, display-alignment, start-indent, end-indent, writing-mode, span, span-weak?, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?, position-point-x, position-point-y, escapement-direction, inhibit-line-breaks?, break-before-priority, break-after-priority
Included-container-area display?, filling-direction, width, height, contents-alignment, overflow-action, contents-rotation, scale, position-preference, display-alignment, end-indent, writing-mode, span-weak?, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?, position-point-x, position-point-y, escapement-direction, inhibit-line-breaks?, break-before-priority, break-after-priority
Score type, score-spaces?, color, layer, line-cap, line-dash, line-thickness, line-repeat, line-sep, inhibit-line-breaks?, font-family-name, font-weight, font-posture, font-structure, font-proportionate-width, font-name, font-size
Box display?, box-type, box-open-end?, background-color, background-layer, box-corner-rounded, box-corner-radius, box-border-alignment, box-size-before, box-size-after, color, layer, line-cap, line-dash, line-thickness, line-repeat, line-sep, line-miter-limit, line-join, writing-mode, position-preference, inhibit-line-breaks?, break-before-priority, break-after-priority, start-indent, end-indent, span, span-weak?, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?
Side-by-side side-by-side-overlap-control, position-preference, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?
Side-by-side-item start-indent, end-indent, side-by-side-pre-align, follows, side-by-side-post-align
Glyph-annotation annotation-glyph-placement, annotation-glyph-style, inhibit-line-breaks?, break-before-priority, break-after-priority
Alignment-point nessuna
Aligned-column display-alignment, start-indent, end-indent
Multi-line-inline-note open, close, inline-note-line-count, inline-note-style, inhibit-line-breaks?, break-before-priority, break-after-priority
Emphasizing-Mark mark, mark-distribution, mark-style, inhibit-line-breaks?, break-before-priority, break-after-priority
Oggetto di flusso Proprietà
Table table-width, table-auto-width-method, table-border, before-row-border, before-column-border, after-column-border, table-corner-rounded, table-corner-radius, position-preference, display-alignment, end-indent, writing-mode, span, span-weak?, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?
Table-part table-part-omit-middle-header?, table-part-omit-middle-footer?, space-before, space-after, keep-with-previous?, keep-with-next?, break-before, break-after, keep, may-violate-keep-before?, may-violate-keep-after?
Table-column column-number, n-columns-spanned, width, display-alignment, start-indent, end-indent
Table-row (nessuna, questo è un contenitore per altri oggetti di flusso)
Table-cell column-number, n-columns-spanned, n-rows-spanned, cell-before-row-margin, cell-after-row-margin, cell-before-column-margin, cell-after-column-margin, cell-row-alignment, cell-background?, background-color, background-layer, cell-before-row-border, cell-after-row-border, cell-before-column-border, cell-after-column-border, starts-row?, ends-row?, line-cap, line-dash, line-thickness, line-repeat, line-sep, float-out-sidelines?, float-out-marginalia?, float-out-line-numbers?
Table-border border-priority, border-alignment, border-omit-at-break?, color, layer, line-cap, line-dash, line-thickness, line-repeat, line-sep, line-miter-limit, line-join
Oggetto di flusso Proprietà
Scroll filling-direction, writing-mode, background-color, background-layer, background-tile, start-margin, end-margin
Multi-mode multi-modes, principal-mode-simultaneous?
Flow destination
Marginalia marginalia-sep, marginalia-side, marginalia-keep-with-previous?

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:

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.

Proprietà di P94.

Proprietà P94 Funzionalità CSS corrispondente Commento
LineSpacing line-height
Indent text-indent
Adjust text-align La proprietà Adjust accetta anche un valore "LeftWithDots" per generare i puntini di guida.
Justify text-align Proprietà booleana
Break white-space: nowrap La proprietà Break è booleana e stabilisce se l'elemento può essere spezzato su diverse righe/pagine.
NoBreak1 widows La proprietà NoBreak1 accetta anche una lunghezza come valore (in aggiunta a un intero).
NoBreak2 orphans La proprietà NoBreak2 accetta anche una lunghezza come valore (in aggiunta a un intero).
Gather - La proprietà Gather fu introdotta per gestire grandi documenti. Thot formatta solo una parte del documento, all'incirca la parte visualizzata sullo schermo. Quando l'utente si sposta nel documento, viene formattata una nuova parte e vengono rilasciate le risorse usate dalla parte non più visualizzata. Il problema è decidere cosa debba essere formattato quando qualcosa di nuovo deve essere visualizzato. Per esempio, associando la proprietà Gather con un'equazione, si può dire al formattatore quando inizi a formattare un'equazione, formattala tutta o non formattarla affatto, ma non fermarti a metà. Questa funzionalità non si trova in nessun altro linguaggio di stile discusso in questa tesi.
Visibility visibility I livelli di visibilità possono essere aggiunti agli elementi per nascondere selettivamente quegli elementi al di sotto di una determinata soglia.
Size font-size I valori validi per la proprietà Size sono discussi più avanti nella sezione "Unità di lunghezza".
Font font-family Solo tre valori sono accettati: Times, Helvetica, e Courier.
Style font-style/font-weight Style accetta le seguenti parole chiave: Roman, Bold, Italics, BoldItalics, Oblique, BoldOblique.
Underline text-decoration
Thickness - Descrive lo spessore della sottolineatura e può essere thick o thin.
Depth z-index
Content content
VertRef - Posiziona verticalmente l' "asse di riferimento", che è usato per posizionare i riquadri.
HorizRef - Posiziona orizzontalmente l' "asse di riferimento", che è usato per posizionare i riquadri.
VertPos margin/padding
HorizPos margin/padding
Height height
Width width

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:

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.

Categorie e proprietà di RRP.

Categoria Proprietà
font (fo) family (fa), spacing (sp), size (si), weight (we), slant (sl), foreground (fo), background (ba), line (li), number (nu), longname (lo)
justify (ju) style (st), hyphen (hy), kern (ke)
column (co) num (nu), width (wi)
break (br) style (st), object (ob)
mark (ma) object (ob), preceed (pr), before (be), replace (re), succeed (su), after (af)
vert (ve) before (be), after (af), spacing (le), offset (of)
indent (in) left (le), right (ri), first (fi)
link (li) location (lo), mark (ma), line (li), number (nu), before (be), after (af), hide (hi)

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.

Comparazione delle categorie in FOSI e RRP.

Categoria RRP Categoria FOSI
font font
justify quadding
column column
break textbrk
mark nessuna categoria simile
vert vjinfo
indent indent
link nessuna categoria simile

Comparazione della categoria font in RRP e FOSI.

Nome della proprietà RRP Valori RRP Nome della proprietà FOSI Valori FOSI
family (fa) times (ti), helvetica (he), system (sy), typewriter (ty) style (nella categoria font) serif, sanserif, monoser, monosans
spacing (sp) monospace (mo), proportional (pr) nessuna proprietà equivalente
size (si) integer size (nella categoria font) valore di lunghezza che usa una di queste unità: pi, pt, in, mm, cm, em
weight (we) ultralight (ul), light (li), medium (me), demibold (de), bold (bo) weight (nella categoria font) ultlight, exlight, light, semlight, medium, sembold, bold, exbold, ultbold
slant (sl) roman (ro), italic (it), oblique(ob) posture (nella categoria font) upright, oblique, bsobl (back-slanted oblique), italic, bsital (back-slanted italic)
foreground (fo) I colori sono specificati con nomi testuali (per esempio black, white, magenta), o come valori RGB in notazione esadecimale (per esempio 0x000000, 0xffffff, 0xff00ff) foreground (nella categoria highlight) black, white, red, orange, yellow, green, blue, violet, brown, gray
background (ba) I colori sono specificati con nomi testuali (per esempio black, white, magenta), o come valori RGB in notazione esadecimale (per esempio 0x000000, 0xffffff, 0xff00ff) background (nella categoria highlight) bblack, bwhite, bred, borange, byellow, bgreen, bblue, bviolet, bbrown, bgray
line (li) none (no), under (un), through (th), over (ov) impostato con la proprietà scoring offset nella categoria highlight un valore positivo posizionerà la linea sotto la riga di base, e un valore negativo la posizionerà sopra la riga di base
number (no) un valore numerico che indica il numero di righe scoring (nella categoria highlight) un valore numerico che indica il numero di righe
longname (lo) stringa che descrive il nome di un font per una specifica piattaforma famname (nella categoria font) stringa che descrive il nome di un font per una specifica piattaforma

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:

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 (marca@ncsa.uiuc.edu)
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.

Screenshot di Viola

Il documento d'esempio PWP reso in Viola.

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>wei@ora.com
<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:

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:

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.

Proprietà JEP.

Proprietà Valori Funzionalità CSS corrispondente Commenti
fontfam normal, heading, fixed, alternate font-family I nomi di font generici possono essere correlati con un font effettivo tramite l'elemento fontdesc element (si veda avanti).
fontsize tiny, small, normalsize, large, big, huge, 0, 1, 2, 3, 4, 5, 6, 7 font-size Le parole chiave sono prese da LaTex, i numeri da Netscape.
fontshape plain, bf, it, bi, sc, tt font-style, font-weight, font-variant I valori a due lettere sono: bold, italic, bold italic, small-caps, teletype (ossia monospaziato).
lmargin length value margin-left
rmargin length value margin-right
preskip length value margin-top
postskip length value margin-bottom
parskip length value - (Questa proprietà è lasciata nella DTD per errore [English 2002])
parindent length value text-indent Indentazione della prima riga.
presep reference to "separator" padding/border/margin
postsep reference to "separator" padding/border/margin
align left, center right text-align and/or margin-left, margin-right
xleading length value line-height Indica un'interlinea extra.
obeylines obeylines, wraplines white-space Indica se le interruzioni di linea debbano essere rispettate.
obeyspaces obeyspaces, squeezespaces white-space Indica se i caratteri di spazio debbano essere rispettati.
box box, nobox border-style
boxcolor color border-color
bgcolor color background
fgcolor color color
line noline, underline, overline, strikethrough text-decoration
linecolor color nessuna, viene usato il colore dell'elemento
foldcase nofoldcase, toupper, tolower text-transform
headfmt display, runin, margin display/float
icon riferimento indiretto ad un URL di un'immagine list-style-image Si applica all'intestazione.
numfmt arabic, lcroman, ucroman, lcalpha, ucalpha list-style-type
width length value width Descrive la larghezza dei separatori.
thick length value border-width Descrive lo spessore dei separatori.
align left, center right margin-left/margin-right Descrive l'allineamento dei separatori.

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:

Le unità relative al display sono:

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:

Categorie in JEP.

Categoria Elementi HTML
frasi b cite code em i kbd samp strong tt var
blocchi address blockquote
paragrafi dd li p
elenchi dir dl menu ol ul
visualizzazione in riga img input
visualizzazione a blocco option pre textarea
intestazioni dt h1 h2 h3 h4 h5 h6
metainfo base isindex link meta nextid title
divisioni body form head html select
elementi flottanti -

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.

Proprietà SSFP con equivalenti CSS.

Proprietà Valori Funzionalità CSS corrispondente
block true/false display
flow true/false white-space
vspace two length values margin-top, margin-bottom
margins two length values margin-left, margin-right
shape normal-para, centered, flush-left, block-para, netnews-quote, indent-left, indent-twice-left -
display-level intero, dove '0' indica nascosto e gli interi positivi indicano la visualizzazione -
font-family elenco di nomi di font font-family
font-size intero (rappresenta la dimensione in punti) o parola chiave: normal, lg, vlg, sm, vsm, huge font-size
font-style roman, ital, bold font-style, font-weight
treatment normal, underlined, relined text-decoration, color
color nome di colore (l'elenco dei nomi non è definito) color
content concatenazione di uno o più tra: content(), attval(NAME), stringa letterale content
click si veda di seguito -

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

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:

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

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:

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:

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:

Per gestire i contatori sono definite queste funzioni di query:

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:

Le proprietà di DSSSL Lite.

Nome della proprietà Proprietà CSS con funzionalità simile Commento
break-before display
first-line-start-indent text-indent
break-after display
space-before margin-top Queste proprietà si applicano a oggetti di flusso a livello di blocco
space-after margin-bottom
escapement-space-before margin-left Queste proprietà si applicano a oggetti di flusso di livello carattere
escapement-space-after margin-right
label list-style-type Non presente in DSSSL.
font-family-name font-family
font-weight font-weight
font-posture font-style
font-proportionate-width font-width
font-size font-size
score text-decoration? Non spiegata, DSSSL ha diverse proprietà che descrivono la sottolineatura.
placement-offset - Detta alignment-point-offset in DSSSL.
color color
start-indent margin-left
first-line-start-indent text-indent
end-indent - Detta last-line-end-indent in DSSSL.
quadding text-align
display-alignment text-align, margin-left, margin-right
verbatim? ? Non spiegata, non presente in DSSSL.
pre-line-spacing line-height Detta min-pre-line-spacing in DSSSL.
post-line-spacing line-height Detta min-post-line-spacing in DSSSL.
background-color background Si applica solo all'elemento radice.
keep-with-previous page-break-before
keep-with-next page-break-after

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:

I principali limiti di DSSSL Lite rispetto a DSSSL sono:

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.

Il numero delle classi di oggetti di flusso e le proprietà in DSSSL Lite, DSSSL-O e DSSSL.

DSSSL Lite DSSSL-O DSSSL
classi di oggetti di flusso 14 25 35
(non si contano gli oggetti di flusso matematici)
proprietà 27 157
(non si contano le proprietà per le quali tutti i valori possono essere ignorati)
213
(non si contano le proprietà usate solo negli oggetti di flusso matematici)

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.

Properties proposed by SSP.

Proprietà Valore Funzionalità CSS corrispondente Commento
Proprietà dei font e del testo
size intero, facoltativamente con un prefisso '+' o '-' font-size Il valore è un indice in una tabella di dimensioni di font. Se è presente un prefisso +/-, il valore è relativo al valore dell'elemento genitore, altrimenti il valore è l'indice stesso.
family una di quattro famiglie di font generiche: normal, alt, tt, sym font-family
familyname famiglia di font specifica, per esempio "Univers" font-family Questa proprietà ha la precedenza su family, ma solo se il browser è in grado di fornire il font.
emphasis un numero che seleziona il livello di enfasi - Si veda la discussione successiva.
slant true/false font-style
bold true/false font-weight
underscore il numero di righe sotto il testo text-decoration
strikeout true/false text-decoration
textcolor nome di colore X11 color
textbackground nome di colore X11, o 'transparent' background
leading numero line-height Il numero indica lo spazio verticale extra tra le righe relativo all'interlinea predefinita. Così, 1.0 indica righe a doppia spaziatura.
obeyspaces true/false white-space
nowrap true/false white-space
justify left, right, full, center text-align
hyphenate true/false -
Proprietà del bordo
rulebefore numero padding-top, border-top Questa proprietà inserisce una regola orizzontale sopra l'elemento, seguita dalla quantità data di spazio bianco.
ruleafter numero padding-below, border-below Questa proprietà inserisce una regola orizzontale sotto l'elemento, seguita dalla quantità data di spazio bianco.
rulethickness numero - Questa proprietà descrive lo spessore delle regole generate dalle proprietà "rulebefore" e "ruleafter".
frame ogni sequenza di zero o più parole da `left', `right', `top', `bottom', `border'. `border' è equivalente a `left right top bottom' proprietà del bordo
Proprietà dello spazio bianco
prebreak numero margin-top Si veda la discussione successiva
postbreak numero margin-bottom Si veda la discussione successiva
vmargin numero padding-top, padding-bottom Spazio extra da aggiungere sopra e sotto un oggetto in riga.
hmargin numero padding-left, padding-right Spazio extra da aggiungere a destra e sinistra di un oggetto in riga.
leftindent numero margin-left
rightindent numero margin-right
parindent numero text-indent
noindent true/false - Si veda la discussione successiva.
Proprietà dell'allineamento verticale
valign top, bottom, middle vertical-align Allineamento verticale di un oggetto in riga.
depth intero vertical-align Profondità sotto la riga di base di un oggetto in riga, in pixel. Questa proprietà sovrascrive valign.
raise intero vertical-align Valori positivi alzano il testo, valori negativi lo abbassano. Le esatte posizioni in pixel sono una proprietà del font.
Proprietà delle dimensioni del box
textwidth numero width
width intero width Larghezza in pixel di un oggetto in riga.
height intero height Altezza in pixel di un oggetto in riga.
Proprietà per il testo generato
insertbefore stringa pseudo-elemento :before
insertafter stringa pseudo-elemento :after
Proprietà per il fluttuamento
track left, right, normal float Si veda la discussione nella sezione "Modello di formattazione visuale".
flush left, right, full clear
Proprietà di tabella
table true/false display: table
tablerow true/false display: table-row
tablecell true/false display: table-cell
rowspan intero -
colspan intero -
caption top, bottom, left, right caption-side
Proprietà di classificazione
empty booleano - Si veda la discussione di seguito.
title true/false - Si veda la discussione di seguito.
ismap true/false - Indica se un elemento è un "ismap" o no.
stylesheet merge, replace, override - Si veda la discussione di seguito.
language Codice ISO per una lingua Selettore :lang Si veda la discussione di seguito.
Proprietà per il comportamento dei collegamenti
inline URL di qualcosa da visualizzare in riga all'inizio dell'elemento -
id ID di elemento - Questo valore sarà quasi sempre un riferimento ad attributo, come !ID. Si veda la discussione di seguito.
target ID di elemento - Si veda la discussione di seguito.
anchor URL - Si veda la discussione di seguito.
anchorshape - Si veda la discussione di seguito.
anchorcoords - Si veda la discussione di seguito.
Other properties
label A, a, 1, I, i, bullet, square, -, *, nomi di simboli (rispettivamente lettere maiuscole autonumerate, lettere minuscole, numeri arabi, numerali romani, numerali romani minuscoli, puntini, quadrati, trattini, asterischi, icone-WWW). list-style-type
hide true/false visibility
minimized true/false - Si veda la discussione di seguito.

Alcune delle proprietà sopra elencate meritano un ulteriore discussione:

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 tracceleft, 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:

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:

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.

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.

Valutazione di come i differenti linguaggi di stile e proposte di linguaggi di stile si comportino rispetto ai requisiti del Web. Le valutazioni positive sono marcate da uno sfondo grigio.

Basato sul flusso Proprietà, valori, unità basate su schermo Negoziazione tra preferenze di stile in conflitto Fogli di stile per media specifici Stile per i collegamenti Robustezza
FOSI In un certo senso, FOSI si può considerare basato sul flusso. Un foglio di stile FOSI accurato che eviti alcune caratteristiche avanzate (tra cui cross-reference, float, e testo generato) e alcuni selettori (per esempio i valori middle e last per l'attributo occur) può essere reso in modo progressivo. No. Per esempio, non c'è un unità pixel. No. I fogli di stile FOSI sono di solito applicati dagli autori/editori, e gli utenti vedono solo l'output stampato. Non c'è un meccanismo per combinare diversi fogli di stile. No, FOSI è inteso soprattutto per stampare documenti e non ha il concetto di fogli di stile per specifici media. No, lo stile per i collegamenti non è supportato. No, non c'è un meccanismo per aumentare la robustezza.
DSSSL No, DSSSL è un linguaggio trasformazionale e richiede un documento completo per iniziare l'elaborazione. No. Per esempio, non c'è un unità pixel. No, non c'è supporto per fogli di stile multipli. No, DSSSL è concepito per stampare documenti e non ha un concetto di fogli di stile per media specifici. No, DSSSL non ha il concetto di collegamenti No, non c'è un meccanismo per aumentare la robustezza
P94 Si, P94 è un linguaggio per descrivere le presentazioni e lascia il compito di trasformare il documento al linguaggio 'T' No. Per esempio, non c'è un unità pixel. No. Fogli di stile multipli sono supportati con le vedute, ma i vari fogli di stile non possono essere combinati. Si, un foglio di stile P94 può definire diverse vedute, per esempio una per la stampa e una per lo schermo. No, P94 non ha il concetto di collegamenti. No, non c'è un meccanismo per aumentare la robustezza
RRP Si, RRP supporta la resa progressiva Si, la proposta è scritta tenendo a mente gli schermi dei computer. Per esempio, viene suggerito come i valori di colore possano essere visualizzati su terminali che non supportano il colore. Non c'è un unità pixel in se, ma alcuni valori numerici possono essere interpretati come pixel. I fogli di stile multipli sono supportati, ma solo come modo per gli autori di sostituire uno stile con un altro all'interno del documento. No, non vengono discussi fogli di stile per media specifici Si. RRP ha un ricco supporto per lo stile dei collegamenti, inclusi i marcatori da inserire prima e dopo il collegamento. Tuttavia, non c'è un modo per dare uno stile differente ai collegamenti visitati e non visitati. La proposta evidenzia il fatto che un foglio di stile è un elenco di consigli e suggerimenti. Ciò implica che vi sarà un altro meccanismo sottinteso per assicurare che i documenti vengano resi quando non è disponibile un foglio di stile.
PWP Si, PWP supporta la resa progressiva No. PWP ha un insieme di proprietà per controllare il lampeggiamento del testo, ma altre caratteristiche di base (per esempio l'unità pixel) mancano. I fogli di stile multipli sono discussi nella proposta, e implementati da Viola. Tuttavia, come in RRP, solo gli autori possono specificare i fogli di stile. No, i fogli di stile per media specifici non sono discussi. No, lo stile per i collegamenti non è discusso. Come RRP, PWP non descrive esplicitamente un meccanismo per aumentare la robustezza, ma l'implementazione di Viola era in grado di rendere i documenti senza fogli di stile.
SHP Si. SHP supporta la resa progressiva, poichè quelle caratteristiche di FOSI, che avrebbero impedito tale resa, non fanno parte del sottoinsieme. No, SHP manca di proprietà, valori e unità basati su schermo. No. A differenza di PWP, SHP non discute i fogli di stile multipli. No, i fogli di stile per media specifici non sono discussi. No, lo stile per i collegamenti non è discusso. Come RRP e PWP, SHP non tratta esplicitamente la robustezza, ma sembra probabile che i documenti fossero pensati per essere resi anche se un foglio di stile non fosse stato collegato al documento.
CHSS Si, CHSS è basato sul flusso. Si, CHSS supporta la resa basata su schermo. L'unità pixel è una fra le diverse unità di misura, e la dimensione dello schermo può essere considerata quando si seleziona un foglio di stile. Si, CHSS introduce il concetto di cascata, che combina diversi fogli di stile in una sola presentazione. Si, i fogli di stile per media specifici sono parte della proposta. No, lo stile per i collegamenti non è discusso. Si, il foglio di stile predefinito del browser permette ai documenti di essere resi anche se i fogli di stile autore/utente mancano.
JEP Si, la resa progressiva è possibile. Si, il design basato su schermo è supportato. Manca l'unità pixel, ma altre caratteristiche, tra cui l'unità "pcd" (percent of display) sono supportate. Sebbene JEP non supporti un meccanismo generico per combinare i fogli di stile, esso suggerisce due schemi per dare influenza agli utenti: correlazione di font e peso delle regole. JEP discute come scrivere fogli di stile per media diversi, ma non propone una sintassi in tal senso. La proposta discute la possibilità di specificare gli stili per le ancore, ma non propone una sintassi. Si, la proposta descrive un modello in cui i browser hanno la capacità di rendere i documenti HTML e possono scegliere di rispettare le regole in modo selettivo. Per esempio, la proposta dice un browser che evidenzia le ancore ipertestuali sottolineandole è incoraggiato a ignorare ogni specifica di sottolineatura nel foglio di stile.
SSFP Si, la resa progressiva è possibile. No. Per esempio non c'è un'unità pixel. No, i fogli di stile multipli non sono discussi. No, i fogli di stile per media specifici non sono discussi. No, lo stile per i collegamenti non è supportato. (I comportamenti dei collegamenti sono tuttavia descritti.) No. La proposta menziona la specifica di un elaborazione di ripiego come un problema non ancora considerato.
DSSSL Lite No. DSSSL-Lite è, come lo stesso DSSSL, un linguaggio trasformazionale. La proposta ha una caratteristica, l'oggetto di flusso iconify, che è l'unico implementabile su un display dinamico. La proposta non elenca valori e unità. No, i fogli di stile multipli non sono discussi. No, i fogli di stile per media specifici non sono discussi. La proposta afferma che oggetti/caratteristiche per il collegamento sono necessari, ma essi non sono descritti. Non discussa.
SSP Si. La proposta ha basato sul flusso nel nome per sottolineare l'importanza di questa caratteristica. Si. Alcune proprietà interpretano i valori numerici come pixel, ed è possibile impostare lo sfondo degli elementi. Alcune proprietà (come isman e minimized) hanno senso solo in un ambiente basato su schermo. No, i fogli di stile multipli non sono supportati. Si, SSP abbozza e discute il supporto per fogli di stile per media specifici. Un esempio è poter impostare differenti valori di colore a seconda del tipo di display in uso. No, non c'è supporto allo stile per i collegamenti. (I comportamenti dei collegamenti sono tuttavia descritti.) Non discussa.
PSL96 PSL96 è un interessante punto d'incontro tra linguaggi trasformazionali e basati sul flusso. PSL96 consente la presentazione out-of-order, e la resa progressiva può perciò essere impossibile. PSL96 è stato implementato in un browser basato su schermo [Marden&Munson 1997] [Marden&Munson 1998], ma non supporta proprietà, unità o valori orientati allo schermo. Per esempio, l'unità pixel non è supportata. No. Lo stile multiplo è supportato con le vedute, ma i vari fogli di stile non possono essere combinati. Si, i fogli di stile PSL96 possono definire diverse vedute, per esempio una per la stampa e una per lo schermo. Una delle possibili vedute in PSL96 è la veduta collegamenti che, per esempio, può elencare tutti i collegamenti con i loro URL di destinazione. Tuttavia, non è possibile dare uno stile ai collegamenti basandosi su un'informazione esterna, per esempio se un collegamento è stato visitato o no. La proposta non descrive un meccanismo per aumentare la robustezza della resa, ma il browser Mosaic, modificato dagli autori, è in grado di presentare i documenti HTML senza fogli di stile allegati.

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:

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 CSS1.

Pattern Significato
E Seleziona ogni elemento E (ossia un elemento di tipo E).
E F Questo selettore contestuale seleziona ogni elemento F che sia discendente di un elemento E.
E:link
E:visited
Seleziona l'elemento E se E è l'ancora di un ipercollegamento il cui target non è stato ancora visitato (:link) o è stato già visitato (:visited).
E:active
E:hover
E:focus
Seleziona E durante determinate azioni da parte dell'utente.
DIV.warning Lo stesso che DIV[class~="warning"] nei CSS2.
E#myid Seleziona ogni elemento E con ID uguale a "myid".

Selettori nei CSS2

In aggiunta ai selettori dei CSS1, I CSS2 hanno aggiunto diversi tipi di selettori. Si veda la Tabella 18.

Selettori aggiunti nei CSS2.

Pattern Significato
* Il selettore universale che seleziona ogni elemento.
E > F Seleziona ogni elemento F figlio di un elemento E.
E:first-child Seleziona l'elemento E quando E è il primo figlio del suo genitore.
E:lang(c) Seleziona l'elemento di tipo E se esso è in una lingua (umana) c (il linguaggio del documento specifica come viene determinata la lingua).
E + F Seleziona ogni elemento F immediatamente preceduto da un elemento E.
E[foo] Seleziona ogni elemento E che abbia l'attributo foo impostato (qualunque sia il valore).
E[foo="warning"] Seleziona ogni elemento E il cui valore dell'attributo foo è esattamente uguale a warning.
E[foo~="warning"] Seleziona ogni elemento E il cui valore dell'attributo foo è un elenco di valori separati da uno spazio, uno dei quali è esattamente uguale a warning.
E[lang|="en"] Seleziona ogni elemento E il cui attributo lang ha un elenco di valori separati da trattino che cominciano (da sinistra) con en.

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.

Proprietà nei CSS1.

Proprietà Valori
Proprietà dei font (6)
font-family [[<family-name> | <generic-family>],]* [<family-name> | <generic-family>]
font-style normal | italic | oblique
font-variant normal | small-caps
font-weight normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900
font-size <absolute-size> | <relative-size> | <length> | <percentage>
font [ <font-style> || <font-variant> || <font-weight> ]? <font-size> [ / <line-height> ]? <font-family>
Proprietà del colore e dello sfondo (7)
color <color>
background-color <color> | transparent
background-image <url> | none
background-repeat repeat | repeat-x | repeat-y | no-repeat
background-attachment scroll | fixed
background-position [<percentage> | <length>]{1,2} | [top | center | bottom] || [left | center | right]
background <background-color> || <background-image> || <background-repeat> || <background-attachment> || <background-position>
Proprietà del testo (8)
word-spacing normal | <length>
letter-spacing normal | <length>
text-decoration none | [ underline || overline || line-through || blink ]
vertical-align baseline | sub | super | top | text-top | middle | bottom | text-bottom | <percentage>
text-transform capitalize | uppercase | lowercase | none
text-align left | right | center | justify
text-indent <length> | <percentage>
line-height normal | <number> | <length> | <percentage> <percentage>
Proprietà del box (26)
margin-top <length> | <percentage> | auto
margin-right <length> | <percentage> | auto
margin-bottom <length> | <percentage> | auto
margin-left <length> | <percentage> | auto
margin [ <length> | <percentage> | auto ]{1,4}
padding-top <length> | <percentage>
padding-right <length> | <percentage>
padding-bottom <length> | <percentage>
padding-left <length> | <percentage>
padding [ <length> | <percentage> ]{1,4}
border-top-width thin | medium | thick | <length>
border-right-width thin | medium | thick | <length>
border-bottom-width thin | medium | thick | <length>
border-left-width thin | medium | thick | <length>
border-width [thin | medium | thick | <length>]{1,4}
border-color <color>{1,4}
border-style none | dotted | dashed | solid | double | groove | ridge | inset | outset
border-top <border-top-width> || <border-style> || <color>
border-right <border-right-width> || <border-style> || n<color>
border-bottom <border-bottom-width> || <border-style> || <color>
border-left <border-left-width> || <border-style> || <color>
border <border-width> || <border-style> || <color>
width <length> | <percentage> | auto
height <length> | auto
float left | right | none
clear none | left | right | both
Proprietà di classificazione (6)
display block | inline | list-item | none
white-space normal | pre | nowrap
list-style-type disc | circle | square | decimal | lower-roman | upper-roman | lower-alpha | upper-alpha | none
list-style-image <url> | none
list-style-position inside | outside
list-style [disc | circle | square | decimal | lower-roman | upper-roman | lower-alpha | upper-alpha | none] || [inside | outside] || [<url> | none]

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.

Proprietà introdotte nei CSS2.

Proprietà Valori
border-collapse collapse | separate | inherit
border-spacing <length> <length>? | inherit
caption-side top | bottom | left | right | inherit
clip <shape> | auto | inherit
content [ <string> | <uri> | <counter> | attr(X) | open-quote | close-quote | no-open-quote | no-close-quote ]+ | inherit
counter-increment [ <identifier> <integer>? ]+ | none | inherit
counter-reset [ <identifier> <integer>? ]+ | none | inherit
cursor [ [<uri> ,]* [ auto | crosshair | default | pointer | move | e-resize | ne-resize | nw-resize | n-resize | se-resize | sw-resize | s-resize | w-resize| text | wait | help ] ] | inherit
direction ltr | rtl | inherit
display inline | block | list-item | run-in | compact | marker | table | inline-table | table-row-group | table-header-group | table-footer-group | table-row | table-column-group | table-column | table-cell | table-caption | none | inherit
empty-cells show | hide | inherit
font-size-adjust <number> | none | inherit
font-stretch normal | wider | narrower | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | inherit
left <length> | <percentage> | auto | inherit
list-style-type disc | circle | square | decimal | decimal-leading-zero | lower-roman | upper-roman | lower-greek | lower-alpha | lower-latin | upper-alpha | upper-latin | hebrew | armenian | georgian | cjk-ideographic | hiragana | katakana | hiragana-iroha | katakana-iroha | none | inherit
marker-offset <length> | auto | inherit
marks [ crop || cross ] | none | inherit
max-height <length> | <percentage> | none | inherit
max-width <length> | <percentage> | none | inherit
min-height <length> | <percentage> | inherit
min-width <length> | <percentage> | inherit
orphans <integer> | inherit
outline [ 'outline-color' || 'outline-style' || 'outline-width' ] | inherit
outline-color <color> | invert | inherit
outline-style <border-style> | inherit
outline-width <border-width> | inherit
overflow visible | hidden | scroll | auto | inherit
page <identifier> | auto
page-break-after auto | always | avoid | left | right | inherit
page-break-before auto | always | avoid | left | right | inherit
page-break-inside avoid | auto | inherit
position static | relative | absolute | fixed | inherit
quotes [<string> <string>]+ | none | inherit
right <length> | <percentage> | auto | inherit
size <length>{1,2} | auto | portrait | landscape | inherit
speak-header once | always | inherit
table-layout auto | fixed | inherit
text-shadow none | [<color> || <length> <length> <length>? ,]* [<color> || <length> <length> <length>?] | inherit
top <length> | <percentage> | auto | inherit
unicode-bidi normal | embed | bidi-override | inherit
visibility visible | hidden | collapse | inherit
widows <integer> | inherit
z-index auto | <integer> | inherit

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:

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:

Le unità relative sono:

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:

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.

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:

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.

margine
bordo
padding
contenuto
 
 
 

Il box model CSS.

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:

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:

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:

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.

Codice HTML
<OL> 
  <LI></LI> 
  <LI> 
    <OL> 
      <LI></LI>     
      <LI></LI> 
      <LI></LI> 
  </LI> 
  <LI></LI> 
</OL> 
Codice CSS
  OL { counter-reset: item }
  LI:before { 
    content: counter(item);
    counter-increment: item;
  }
  OL { counter-reset: item }
  LI:before { 
    content: counters(item, ".");
    counter-increment: item;
  }
Risultato formattato
 1
 2
   1
   2
   3
 3
 1
 2
   2.1
   2.2
   2.3
 3

Due differenti stili di contatori.

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:

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:

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 valutati rispetto ai requisiti del Web.

Basato sul flusso Proprietà, valori e unità basati sul flusso Negoziazione tra preferenze di stile in conflitto Fogli di stile per media specifici Stile per i collegamenti Robustezza
CSS1 Si, i CSS1 sono basati sul flusso Si, i CSS hanno un numero di caratteristiche per il supporto del design basato su schermo, tra cui l'unità pixel ed il testo lampeggiante. Si, i CSS possono combinare fogli di stile presi da differenti fonti. Si, i CSS2 supportano i fogli di stile per media specifici. Si, i CSS supportano lo stile per i collegamenti. Si, i CSS sono robusti nel senso che i documenti con fogli di stile parziali o senza fogli di stile possono essere ancora presentati. In particolare, questo è il caso dei documenti HTML sul Web.

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:

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:

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:

Oltre all'elenco specifico di cui sopra, vi sono altre aree generali dove sarebbe stato importante uno sforzo maggiore:

Alcune di queste caratteristiche saranno probabilmente aggiunte nelle future versioni dei CSS, proprio come i CSS2 aggiunsero alcune caratteristiche richieste di frequente:

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à.

Si può anche dire che altre parti dei CSS2 siano eccessive, dal momento che non sono state ampiamente implementate. Queste parti comprendono:

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.

Problemi risultanti dalla marcatura

Problemi dell'interfaccia utente

Problemi di complessità

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:

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.

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.

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.

Oltri ai contributi principali elencati poc'anzi, l'autore è giunto a ritenere – durante il corso del lavoro – che quanto segue sia vero:

Glossario

actual value [valore effettivo]
Il valore di proprietà effettivamente usato nella presentazione del documento. Il valore effettivo può essere diverso dal valore specificato a causa delle limitazioni nel dispositivo di output (per esempio la mancanza di alcune dimensioni dei font).
anchor [ancora]
Il punto terminale di un collegamento. Ci sono due tipi di ancore: ancore sorgenti e ancore di destinazione.
application [applicazione]
Un (in qualche modo complesso) programma per computer con un'interfaccia utente.
area
Un'area è per un modello a sequenza quello che un box è in un box model. Ossia, un'area è un contenitore rettangolare che racchiude il contenuto e che viene rappresentata nell'area di layout. Ci sono due tipi di aree: aree di visualizzazione e aree in riga.
attribute [attributo]
Un nome o una coppia nome/valore scritto all'interno di un tag iniziale.
author [autore]
Una persona che scrive i documenti e vi associa i fogli di stile.
author style sheet [foglio di stile dell'autore]
Un foglio di stile inserito o collegato ad un documento.
band [fascia]
Un box nel box model CSS ha tre fasce: padding, bordo e margine. Le fasce sono superfici che circondano i box. Le fasce di margine possono essere negative, mentre quelle di padding e di bordo devono essere uguali a zero o positive.
binding [legame]
Il processo di combinare un documento strutturato con un foglio di stile al fine di formattare il documento in una presentazione di forma finale.
block-level element [elemento a livello di blocco]
Un elemento che genera uno o più box di blocco.
block box [box di blocco]
Un box generato da un elemento a livello di blocco, che ha un'interruzione di riga prima e dopo di se.
box [riquadro]
Un contenitore rettangolare che racchiude il contenuto ed altri box, ed è rappresentato nell'area di layout. Vi sono due tipi di box: box di blocco e box in riga.
box model
Un modello di formattazione visuale dove il contenuto è rappresentato in box rettangolari annidati che formano una struttura ad albero.
browser
Vedi browser web.
browser style sheet [foglio di stile del browser]
Un foglio di stile che descrive la presentazione predefinita dei documenti.
cascading [cascata]
Il processo di combinare diversi fogli di stile e di risolvere i conflitti tra di essi.
character [carattere]
Una voce nel Unicode Character Database [Unicode].
client
Un applicazione che comunica con un server su una rete.
constraint [restrizione]
Un'espressione di una relazione geometrica restrittiva tra elementi.
content [contenuto]
Le parti di un documento sorgente che non sono marcatura. Inoltre il termine si riferisce a risorse esterne collegate, per esempio immagini e grafici.
content model [modello di contenuto]
Il modello di contenuto descrive quali costrutti ( per esempio elementi e attributi) sono consentiti in una determinata parte del documento.
contextual selector [selettore contestuale]
Un selettore che ricerca un pattern sulla base di elementi multipli, piuttosto che di un singolo elemento.
continuous media type [tipo di media continuo]
Una classe di dispositivi di output che ha una superficie di presentazione continua, diversamente da un media impaginato.
containing block [blocco contenitore]
Un box rettangolare generato da un elemento antenato di blocco a cui un box discendente si relaziona in modo geometrico.
declaration [dichiarazione]
Una coppia di proprietà e valore.
declarative language [linguaggio dichiarativo]
Un linguaggio dichiarativo è un termine generale che descrive quei linguaggi che esprimono relazioni tra variabili, opposti ai linguaggi imperativi che esprimono sequenze esplicite di passi da seguire per produrre un risultato. Spesso i linguaggi dichiarativi non sono Turing-complete, mentre i linguaggi imperativi lo sono. Tutti i linguaggi di stile descritti in questa tesi sono dichiarativi.
default style sheet [foglio di stile predefinito]
Un foglio di stile che descrive la presentazione predefinita di un linguaggio di documento (per esempio HTML) e che è inserito in un browser.
designer
Una persona che scrive fogli di stile style.
digital document [documento digitale]
Un documento rappresentato da cifre su un media, leggibile dal computer (per esempio un hard disk o un CD-ROM) ma non dagli esseri umani.
display area [area di visualizzazione]
Un'area rettangolare generata da un elemento a livello di blocco in un modello a sequenza.
document [documento]
Un insieme di contenuti, di solito testo, immagini e grafici. Di solito i documenti raggiungono il pubblico sulla carta stampata, ma la pubblicazione elettronica è sempre più popolare.
document format [formato di documento]
Un linguaggio per archiviare e scambiare documenti digitali, per esempio l'HTML.
document language [linguaggio del documento]
Il formato di documento del documento sorgente, per esempio l'HTML.
draft [bozza]
Una proposta.
editor
Un'applicazione che permette agli utenti di comporre ed editare documenti.
electronic publishing [pubblicazione elettronica]
Una forma di pubblicazione in cui i documenti sono trasmessi in forma digitale dall'autore al lettore. Il Web è un esempio di pubblicazione elettronica.
element [elemento]
Il costrutto sintattico primario di un documento strutturato.
element type [tipo di elemento]
Il nome di un elemento (per esempio H1 e BLOCKQUTE in HTML). Il tipo di elemento si dice the Identificatore Generico [Generic Identifier o GI, N.d.T.] in SGML.
embedded style sheets [fogli di stile incorporati]
Fogli di stile posti all'interno del documento, invece che collegati ad esso. In HTML, i fogli di stile possono essere incorporati nell'elemento STYLE e nell'attributo STYLE attribute.
environment variable [variabile di ambiente]
Un parametro dell'ambiente dell'utente, per esempio la larghezza del display o la data del giorno.
fallback value [valore di ripiego]
Un valore usato se il valore preposto non è disponibile, per esempio mentre il foglio di stile viene scaricato.
final form [forma finale]
Si dice che un documento è nella sua forma finale quando non può più essere editato, ed è pronto per la presentazione all'utente. Un documento in forma finale può essere sia in formato digitale (per esempio PDF) o stampato su carta.
flow object [oggetto di flusso]
Un termine DSSSL per oggetto di formattazione.
font
Un tipo di carattere che può essere classificato secondo diverse caratteristiche, tra cui la famiglia, la dimensione, il peso e l'inclinazione.
formatter [formattatore]
Un programma di computer che formatta un documento.
formatting [formattazione]
Il processo che converte un documento strutturato combinato ad un foglio di stile in una presentazione di forma finale.
formatting model [modello di formattazione]
Una presentazione schematica di tutte le caratteristiche orientate alla presentazione che un linguaggio di stile è in grado di esprimere.
formatting object [oggetto di formattazione]
Un oggetto che reca in sè un determinato contenuto, insieme con le informazioni su come presentare il contenuto. Un oggetto che descrive come deve essere presentato un determinato elemento. L'oggetto di formattazione non ha informazioni sul ruolo logico dell'elemento, ma solo sulla sua presentazione. L'oggetto di formattazione può essere espresso in marcatura esplicita (XSL-FO) o esistere solo all'interno di un formattatore (CSS). Se espresso in marcatura esplicita, un oggetto di formattazione è simile ad un elemento presentazionale.
forward-compatible parsing [parsing compatibile nel futuro]
Una grammatica valida per tuttele versioni di un linguaggio, passate, presenti e future. Lo scopo di tale grammatica nei CSS è di consentire alle future versioni di includere nuove funzionalità assicurando al contempo che le vecchie versioni possano analizzare [parse, N.d.T.] i nuovi fogli di stile.
generated content [contenuto generato]
Contenuto specificato nel foglio di stile invece che nel documento sorgente. Esempi di contenuto generato comprendono semplici stringhe, virgolette, contatori, cross-reference, intestazioni/piè di pagina, regole orizzontali, e tavole dei contenuti.
generated text [testo generato]
Contenuto testuale specificato nel foglio di stile invece che nel documento sorgente. Il testo generato è una forma di contenuto generato.
generic markup [marcatura generica]
Marcatura in cui il vocabolario di tag e altri simboli sono sconosciuti al ricevente. Ossia la marcatura può essere elaborata solo a livello sintattico e non su più alti livelli di astrazione.
glyph [glifo]
Una forma del font usata per rappresentare uno o più caratteri nell'area di layout.
GUI
Interfaccia Grafica Utente [Graphical User Interface, N.d.T.].
individual property [proprietà individuale]
Una proprietà che non è una proprietà abbreviata. Ossia, impostare un valore su una proprietà individuale non assegna valori a proprietà diverse da quella individuale.
inheritance [eredità]
Un meccanismo di trasmissione di valore che trasferisce i valori di proprietà dall'elemento genitore ai suoi figli. Il suo principale beneficio sono fogli di stile meno prolissi.
initial containing block [blocco contenitore iniziale]
Un box rettangolare, stabilito dal formattatore, che serve da contenitore per la presentazione del documento.
inline area [area in riga]
Un'area rettangolare generata da un elemento in riga in un modello a sequenza.
inline box [box in riga]
Un box generato da un elemento in riga che, in generale, non ha un'interruzione di riga prima e dopo di se.
inline element [elemento in riga]
Un elemento che genera uno o più box in riga.
initial value [valore iniziale]
Il valore dato ad una combinazione elemento/proprietà se nessun altro valore è impostato o ereditato. Spesso detto valore "predefinito".
inside-out formatting [formattazione inside-out]
Formattazione in cui la dimensione del box (o dell'area) è determinata dal suo contenuto.
instant binding [legame istantaneo]
Il concetto di combinare i documenti strutturati con i fogli di stile in tempo reale durante il processo di authoring.
ladder of abstraction [scala di astrazione]
Uno strumento di misurazione per i documenti digitali. I documenti in alto sulla scala sono semanticamente più ricchi di quelli in basso. Inoltre i documenti in alto sulla scala richiedono più elaborazione prima di raggiungere la loro forma finale.
late binding
Il concetto di combinare i documenti con i fogli di stile dopo che l'authoring è stato completato. In questo modo gli autori non devono preoccuparsi della presentazione del documento durante l'authoring.
later binding
Il concetto di combinare i documenti strutturati con i fogli di stile dal lato utente piuttosto che dal lato autore, prendendo quindi in considerazione le preferenze dell'utente.
layout area [area di layout]
Una superficie bidimensionale su cui vengono resi i documenti, per esempio carta stampata e schermi di computer.
leading [interlinea]
I tipografi la usavano per aggiungere spazio tra le righe. Il termine interlinea descrive lo spazio tra le righe. Nei CSS, il termine si riferisce alla differenza tra i valori di font-size e line-height.
link [collegamento]
Una connessione tra una risorsa web ed un'altra. Un collegamento ha due estremità, dette ancore, e una direzione.
list-item element [elemento a voce di lista/elenco]
Un elemento a livello di blocco che genera marcatore di voce di lista oltre a uno o più box di blocco.
list-item marker [marcatore di voce di lista/elenco]
Un simbolo o un'immagine che marca una voce di lista, per esempio un punto o un cerchio.
logical element [elemento logico]
Un elemento il cui ruolo, opposto alla presentazione, è conosciuto. Per esempio, l'elemento H1 in HTML specifica che il suo contenuto è un'intestazione di livello 1, ma non dice nulla sulla presentazione del contenuto. Un elemento logico è più alto sulla scala di astrazione di un elemento presentazionale.
logical markup [marcatura logica]
La marcatura consiste soprattutto di elementi logici, piuttosto che di elementi presentazionali.
logical structure [struttura logica]
La rappresentazione di un documento che consiste soprattutto di elementi logici, piuttosto che di oggetti di formattazione.
markup [marcatura]
Tag e altri simboli che, se inseriti nel contenuto, formano un documento sorgente.
markup language [linguaggio di marcatura]
Un vocabolario di tag e altri simboli che, se inseriti nel contenuto. aumenta il livello di astrazione e abilita l'elaborazione del contenuto.
media type [tipo di media]
Una classe di dispositivi di output. I CSS2 denominano nove tipi di media (aural, braille, embossed, handheld, print, projection, screen, tty, tv) cosicchè i fogli di stile possono essere indirizzati a particolari dispositivi di output.
origin [origine]
L'origine di un foglio di stile è l'autore, l'utente, o il browser.
out-of-order rendering [resa out-of-order]
Presentare il contenuto in un ordine diverso da quello specificato nel documento sorgente.
output device [dispositivo di output]
Un unità fisica in grado di rendere i documenti visivamente o acusticamente.
outside-in formatting [formattazione outside-in]
La dimensione del box (o dell'area) è determinato dal suo blocco contenitore.
paged media [media impaginati]
Una classe di dispositivi di output che divide l'area di layout in pagine discrete invece di essere continuo.
point [punto]
Un'unità di lunghezza pari ad 1/72 di pollice.
pixel [pixel]
Un pixel è l'unità più piccola su display bitmap di computer e su stampanti. Le lunghezze e le dimensioni dei font sono spesso misurate in pixel, e i linguaggi di stile spesso offrono i pixel come unità di misura. Poichè la densità dei pixel varia molto da un dispositivo di output all'altro, i CSS definiscono l'unità pixel in relazione ad un pixel di riferimento.
plug-in
Un programma che estende la funzionalità di un browser.
presentational element [elemento presentazionale]
Un elemento la cui presentazione, diversamente dal suo ruolo, è conosciuta. Per esempio, l'elemento B in HTML specifica che il suo contenuto deve essere presentato in grassetto, ma non dice nulla sul ruolo del contenuto. Un elemento presentazionale è più in basso sulla scala di astrazione di un elemento logico. Un elemento presentazionale è sullo stesso livello di astrazione di un oggetto di formattazione.
presentational structure [struttura presentazionale]
La rappresentazione di un documento basata su oggetti di formattazione piuttosto che su elementi logici.
procedural markup [marcatura procedurale]
Marcatura che usa istruzioni imperative da dare al formattatore (per esempio l'istruzione di iniziare una nuova pagina).
processing instruction [istruzione di elaborazione]
Un costrutto sintattico di SGML e XML.
progressive rendering [resa progressiva]
I browser che supportano la resa progressiva sono in grado di visualizzare i documenti in modo incrementale man mano che vengono scaricati dal Web.
proposal [proposta]
Una prima, immatura versione di una specifica.
pseudo-class [pseudo-classe]
Una classificazione di elementi simile all'attributo class in HTML, tranne per il fatto che la classificazione avviene automaticamente senza alcun attributo presente nella marcatura.
property [proprietà]
La caratteristica di un elemento che, se legata ad un particolare elemento e con un valore assegnato, può influenzare la resa dell'elemento.
pseudo-element [pseudo-elemento]
Gli pseudo-elementi marcano sezioni del documento al di là di quelle specificate nel documento stesso. I CSS hanno quattro pseudo-elementi: due determinati dalla formattazione (first-letter e first-line) e due che supportano il contenuto generato (before e after).
reader [lettore]
Vedi utente.
reference pixel [pixel di riferimento]
Affinchè l'unità pixel sia usabile su una vasta gamma di dispositivi di output, i CSS descrivono come i valori pixel devono essere scalati se la densità di pixel è molto diversa da quella di un tipico display di computer. Si raccomanda che il pixel di riferimento sia l'angolo visuale di un pixel su un dispositivo di output con una densità di pixel di 90dpi e una distanza dal lettore della lunghezza di un braccio. Per la lunghezza nominale di un braccio pari a 28 pollici, l'angolo visuale è perciò di 0.0227 gradi.
replaced element [elemento rimpiazzato]
Un elemento automaticamente rimpiazzato da un contenuto diverso dal proprio (per esempio un'immagine) quando l'elemento è presentato all'utente.
root element [elemento radice]
In un documento con struttura ad albero, l'elemento radice è l'antenato più remoto di tutti gli altri elementi ed è l'unico elemento a non avere genitore.
rule [regola]
Un'asserzione costituita da un selettore e da una dichiarazione.
selector [selettore]
Un pattern di ricerca che stablisce a quali elementi si applica la corrispondente dichiarazione.
semantic markup [marcatura semantica]
Vedi marcatura logica.
sequence model [modello a sequenza]
Un modello di formattazione visuale in cui il contenuto è rappresentato in una sequenza di aree all'interno di un'area di layout (contrapposto a box model).
shorthand property [proprietà abbreviata]
Le proprietà abbreviate offrono un modo di impostare il valore di diverse proprietà individuali correlate in una sola semplice dichiarazione. Per esempio, nei CSS, la proprietà font è una proprietà abbreviata che imposta tutte le proprietà correlate ai font (e line-height) in una sola volta.
small-screen mode [modalità small-screen]
Un browser che riformatta i documenti per un piccolo schermo si dice in modalità small-screen.
source anchor [ancora sorgente]
Il punto di partenza di un collegamento.
source document [documento sorgente]
Un documento strutturato che, se combinato con uno o più fogli di stile in un formattatore, produce una presentazione di forma finale.
specification [specifica]
Un documento tecnico che descrive un aspetto della comunicazione tra computer, per esempio un formato di documento, un linguaggio di stile, o un protocollo di trasferimento. Prima che le specifiche raggiungano un certo livello di maturità, si chiamano "proposte" o "bozze". Le Raccomandazioni W3C, gli Standard ISO e i RFC IETF sono esempi di specifiche.
specificity [specificità]
La misurazione di quanto sia esplicito un selettore.
specified value [valore specificato]
Il valore della proprietà specificato nel foglio di stile (contrapposto al valore effettivo).
stream-based [basato sul flusso]
Un linguaggio di stile che supporta la resa progressiva dei documenti.
structured document [documento strutturato]
Un documento digitale costituito da una gerarchia di elementi contenenti testo o altro contenuto. Gli elementi rappresentano soprattutto le regole logiche del contenuto piuttosto che la sua presentazione.
structured document system [sistema di documento strutturato]
Un sistema per la pubblicazione elettronica che riconosce la differenza tra struttura logica e struttura presentazionale di un documento. Gli autori di solito sono incoraggiati ad editare la struttura logica, in seguito trasformata in struttura presentazionale. Un sistema di documento strutturato è costituito da un formato di documento e da implementazioni facoltative. Esempi di tali sistemi sono LaTex, ODA, SGML, e HTML.
style sheet [foglio di stile]
Nel contesto della pubblicazione elettronica, ed anche in questa tesi, vengono date le seguenti definizioni di foglio di stile:
Un insieme di regole che associano proprietà e valori di stile agli elementi strutturali di un documento, esprimendo perciò come presentare il documento. I fogli di stile di solito non contengono contenuti, sono collegabili ai documenti e riutilizzabili.

Essendo i fogli di stile l'argomento della tesi, vengono date altre definizioni. In ordine cronologico esse sono:

  • Una definizione dell'uso del termine nella pubblicazione cartacea si trovain [Brüggemann-Klein 1992]:
    Un insieme corrente di regole sull'uso del lessico e del linguaggio adottato per un particolare manoscritto.
  • Da [English 1994a]:
    Un foglio di stile è una collezione di specifiche di stile preparata dall'autore del documento.
  • I CSS1 [CSS1 1996] definiscono così il termine:
    una collezione di regole

    ove il termine regola è definito come:

    una dichiarazione (es: 'font-family: helvetica') e il suo selettore (es: 'H1')

    Un'altra definizione si trova in [Prescod 1997a]:

    ... una serie di asserzioni che correlano elementi strutturali (del documento sorgente) e oggetti di formattazione.
  • I CSS2 [CSS2 1998] contenevano un'altra definizione del termine:
    Un insieme di asserzioni che specifica la presentazione di un documento.
  • Da [Munson 1999]:
    Un foglio di stile è una specifica di come i documenti dovrebbero apparire.
style sheet language [linguaggio di stile]
Un linguaggio che ha sintassi, selettori, proprietà, valori e unità, trasmissione di valore, e modello di formattazione. I linguaggi di stile sono usati per esprimere i fogli di stile.
surf [navigare]
Esplorare i documenti web.
tag
Un costrutto sintattico che marca l'inizio e la fine degli elementi in HTML e altri linguaggi di marcatura.
target anchor [ancora di destinazione]
La destinazione di un collegamento.
transformation-based style sheet language [linguaggio di stile basato sulla trasformazione]
Un linguaggio di stile che è anche un linguaggio trasformazionale.
transformation language [linguaggio trasformazionale]
Un linguaggio che esprime un modo per convertie un documento da una forma all'altra. Alcuni linguaggi di stile considerano al formattazione come una trasformazione.
tree structure [struttura ad albero]
Gli elementi in una struttura ad albero hanno sempre un solo elemento genitore (tranne l'elemento radice, che non ne ha), ma possono avere zero o più elementi figli.
Turing-complete
Um sistema Turing-complete ha un potere computazionale equivalente ad una macchina universale di Turing. Il termine Turing-complete è spesso usato per i linguaggi di programmazione che possono implementare ogni algoritmo ben definito, in opposizione a quei linguaggi che non sono così potenti. La maggior parte dei linguaggi di stile non sono Turing-complete, ma alcuni – come DSSSL e XSL – lo sono.
unit [unità]
Una quantità specificamente precisata in termini di valori asseriti. Esempi di unità nei fogli di stile sono i punti e i pixel.
URL
Un indirizzo web.
URI
Vedi URL.
user [utente]
Un essere umano che usa un browser web.
user agent [programma utente]
Un browser web.
user style sheet [foglio di stile utente]
Un foglio di stile fornito dall'utente. Tale foglio di stile codifica le preferenze dell'utente.
value [valore]
Ogni combinazione valida elemento/proprietà ha un valore. Un valore può essere una stringa, una parola chiave, un numero, o un numero con un identificatore di unità. Inoltre i valori possono essere elenchi o espressioni che coinvolgono i determinanti sopracitati.
value propagation [trasmissione di valore]
Assegnazione automatica di valori non descritti nel foglio di stile. Esempi in tal senso sono l'eredità, i valori iniziali e la and cascata.
viewport [area di visualizzazione]
Una finestra, o un'altra area visiva sullo schermo, che mostra parte dell'area di layout.
Web
Vedi World Wide Web.
web browser [browser web]
Un programma che reperisce risorse (es: testo, immagini e fogli di stile) dal Web, le decodifica e le assembla, e presenta il risultante contenuto ad un utente umano.
web device [dispositivo web]
Un dispositivo elettronico che ha un browser web e accesso di rete al Web.
web page [pagina web]
Un documento disponibile sul Web.
winning declaration [dichiarazione vincente]
Se vi sono diverse dichiarazioni in conflitto che si applicano ad una data combinazione di elemento/proprietà, il processo di cascata stabilirà una sola dichiarazione vincente tra le varie dichiarazioni. Per esempio, una dichiarazione in un foglio di stile dell'autore vincerà di solito su una dichiarazione del foglio di stile del browser.
word processor
Un programma usato per l'authoring e l'editazione dei documenti.
World Wide Web
Un sistema di server interconnessi che usano il protocollo HTTP per trasferire documenti e altre informazioni su richiesta dei browser. I documenti sono di solito scritti in HTML e contengono collegamenti ad altri documenti.

Riferimenti

[Adie 1993]
Adie, C.; Networking Multimedia Applications; Messaggio postato su www-talk giovedì, 3 giugno 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0433.html; Accesso: 25 ottobre 2004 ( copia locale).
[Adler 2002]
Adler, S.; Re: xsl-fo first anniversary; Messaggio postato su www-xsl-fo@w3.org 21 ottobre 2002; Disponibile su http://lists.w3.org/​Archives/​Public/​www-xsl-fo/​2002Oct/0076.html; Accesso: 25 ottobre 2004 (copia locale).
[Adobe 1993]
Portable Document Format; Reference Manual, Adobe Systems, Addison-Wesley, 1993
[Adobe 2001]
PDF Reference, Third Edition, Version 1.4, Addison-Wesley, 2001
[Amaya]
Welcome to Amaya; Pagina web W3C, 2004; Disponibile su http://www.w3.org/Amaya/; Accesso: 25 ottobre 2004 (copia locale).
[André, et al. 1989]
André, J., Furuta, R., and Quint, V. (curatori); Structured Documents; The Cambridge series on electronic publishing, Cambridge University Press, 1989
[Andreessen 1993a]
Andreessen, M.; NCSA Mosaic for X 0.10 available; Messaggio postato su comp.infosystems.gopher, comp.infosystems.wais, comp.infosystems, alt.hypertext e comp.windows.x 15 marzo 1993; Disponibile su http://groups.google.com/​groups?selm=​MARCA.93Mar14225600%40​wintermute.ncsa.uiuc.edu&​output=gplain; Accesso: 25 ottobre 2004 (copia locale).
[Andreessen 1993b]
Andreessen, M.; Stylesheet Language; Messaggio postato su www-talk 22 ottobre 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q4/0266.html; Accesso: 25 ottobre 2004 (copia locale).
[Andreessen 1994a]
Andreessen, M.; Indented <MENU>s; Messaggio postato su www-talk 17 febbraio 1994; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1994q1/0648.html; Accesso: 25 ottobre 2004 (copia locale).
[Andreessen 1994b]
Andreessen, M.; Mosaic Netscape is out the door...; Messaggio postato su www-talk 13 ottobre 1994; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1994q4/0187.html; Accesso: 25 ottobre 2004 (copia locale).
[Appelt 1991]
Appelt, W.; Document architecture in open systems: The ODA standard; Springer-Verlag, 1991
[Badros et al. 1999]
Badros, G. J., Borning, A., Marriott, K. and Stuckey, P.; Constraint Cascading Style Sheets for the Web; Technical Report UW CSE 99-05-01; Reprinted in Proceedings of the 12th annual ACM symposium on User interface software and technology, p.73-82, November 1999, Asheville, North Carolina, United States
[Behlendorf 1994]
Behlendorf, B.; Re: Cascading HTML style sheets – a proposal; Messaggio postato su www-talk 13 ottobre 1994; Disponibile su http://www.w3.org/​Style/​History/​www.eit.com/​www.lists/​www-talk.1994q4/0186.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1991a]
Berners-Lee, T.; HTML Tags; Disponibile su http://www.w3.org/​History/​19921103-hypertext/​hypertext/​WWW/​MarkUp/Tags.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1991b]
Berners-Lee, T.; Re: status. Re: X11 BROWSER for WWW; Messaggio postato su www-talk 29 ottobre 1991; Disponibile su http://lists.w3.org/​Archives/​Public/​www-talk/​1991SepOct/0003.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1992a]
Berners-Lee, T.; MIME, SGML, UDIs, HTML and W3; Messaggio postato su www-talk 11 giugno 1992; Disponibile su http://lists.w3.org/​Archives/​Public/​www-talk/​1992MayJun/0038.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1992b]
Berners-Lee, T.; Re: HTML DTD; Messaggio postato su www-talk 26 giugno 1992; Disponibile su http://lists.w3.org/​Archives/​Public/​www-talk/​1992MayJun/0063.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1992c]
Berners-Lee, T.; Re: HTML DTD and related problems (rather long); Messaggio postato su www-talk 15 luglio 1992; Disponibile su http://lists.w3.org/​Archives/​Public/​www-talk/​1992JulAug/0017.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1992d]
Berners-Lee, T.; Design Constraints; Ultima modifica 13 novembre 1992; Disponibile su http://www.w3.org/​History/​19921103-hypertext/​hypertext/​WWW/​MarkUp/HTMLConstraints.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1993a]
Berners-Lee, T.; HTML, HMML, and HyperTeX; Messaggio postato su www-talk 21 aprile 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0129.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1993b]
Berners-Lee, T.; Re: RE dtd2.html; Messaggio postato su www-talk 27 maggio 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0396.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1993c]
Berners-Lee, T.; Re: browsing vs validation, or, why not to make software robust; Messaggio postato su www-talk 20 agosto 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q3/0745.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1994]
Berners-Lee, T.; HTML *** Important ** LIST CHANGE; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1994q2/0581.html; Accesso: 25 ottobre 2004 (copia locale).
[Berners-Lee 1996]
The Web Maestro: An Interview with Tim Berners-Lee; intervista realizzata da Brody, H.; pubblicata in Technology Review 99, n. 5: 32-40, luglio 1996
[Berners-Lee 1999]
Berners-Lee, T.; Weaving the Web; Harper, San Francisco, 1999
[Bingham 2000]
Bingham, H.; CALS Table Model History; Versione pubblica originale 1.3 2000-06-30; Disponibile su http://users.rcn.com/​hwbingham/​tables/calstbhs.htm; Accesso: 25 ottobre 2004 (copia locale).
[Borenstein 1994]
Borenstein, N.; The text/enriched MIME Content-type; RFC1563, gennaio 1994
[Bos 1994]
Bos, B.; Re: Cascading HTML style sheets – a proposal; Messaggio postato su www-talk 11 ottobre 1994; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1994q4/0158.html; Accesso: 25 ottobre 2004 (copia locale).
[Bos 1995]
Bos, B.; Stream-based Style sheet Proposal; Ultimo aggiornamento 31 marzo 1995; Disponibile su http://odur.let.rug.nl/​~bert/stylesheets.html Accesso: 25 ottobre 2004 (copia locale).
[Bos 1998]
Bos, B.; OPINIONS WANTED: regexps in CSS? (Re: Suggestion for Attribute Selectors); Messaggio postatto su www-style 10 marzo 1998; Disponibile su http://lists.w3.org/​Archives/​Public/​www-style/​1998Mar/0051.html; Accesso: 25 ottobre 2004 (copia locale).
[Bosak 1995]
Bosak, J.; Toward a specification of DSSSL Core; Messaggio postato il 9 ottobre 1995 su dsssl-lite; Disponibile su http://xml.coverpages.org/​dssslCore1.txt; Accesso: 25 ottobre 2004 (copia locale).
[Bosak 1996a]
Bosak, J.; SGML: DSSSL style sheet for HTML 3.2 print output; Messaggio postato il 21 luglio 1996; Disponibile su http://xml.coverpages.org/​dsssl-o-html32.html; Accessso: 25 ottobre 2004 (copia locale).
[Bosak 1996b]
Bosak, J.; Greetings from the chair; Messaggio postato su w3c-sgml-wg@w3.org 28 agosto 1996; Disponibile su http://lists.w3.org/​Archives/​Public/​w3c-sgml-wg/msg00004.html; Accesso: 25 ottobre 2004 (copia locale).
[Bosak 1997]
Bosak, J.; RE: Positioning HTML Elements with Cascading Style Sheets; Messaggio postato su www-style@w3.org 3 febbraio 1997; Disponibile su http://lists.w3.org/​Archives/​Public/​www-style/​1997Feb/0033.html; Accesso: 25 ottobre 2004 (copia locale).
[Brüggemann-Klein&Wood 1992]
Brüggemann-Klein, A., Wood, D.; Electronic Style Sheets; Interner Bericht 45, Institut für Informatik, Universitat Freiburg, 1992
[Bray 2002]
Bray, T.; XML-SW, a thought experiment; Messaggio postato su www-tag@w3.org 6 febbraio 2002; Disponibile su http://lists.w3.org/​Archives/​Public/​www-tag/​2002Feb/0031.html; Accesso: 25 ottobre 2004 (copia locale).
[Burnard 1993]
Burnard, L.; FOSI/sgml stylesheets; Messaggio postato su www-talk 27 ottobre 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q4/0301.html; Accesso: 25 ottobre 2004 (copia locale).
[Cailliau 1997]
Cailliau, R.; Foreword of Cascading Style Sheets by Lie, H. W., and Bos, B.; Addison-Wesley, 1997,
[Chicago 1993]
The Chicago Manual of Style; The University of Chicago Press, Fourteenth Edition, 1993
[Chavchanidze 2004]
Chavchanidze, G.; Formatting Mathematical Articles with Cascading Style Sheets; Edizione rivista pubblicata il 10 ottobre 2004; Disponibile su http://geocities.com/​csssite/math.xml; Accesso: 25 ottobre 2004 (copia locale).
[Clark 1994]
Clark, J.; DSSSL Lite; Bozza di specifica datata 24 novembre 1994; In origine disponibile su http://www.falch.no/​~pepper/DSSSL-Lite/ (copia locale scannerizzata (PDF))
[Clark 1998]
Clark, J.; Jade - James' DSSSL Engine; Ultima modifica 13 ottobre 1998; Disponibile su http://www.jclark.com/jade/; Accesso: 25 ottobre 2004 (copia locale).
[CLink 2000a]
Lie, H. W.; CLink; Disponibile su http://people.opera.com/​howcome/​2000/​clink/2000-05-05.html; Accesso: 25 ottobre 2004 (copia locale).
[CLink 2000b]
Lie, H. W.; CLink; Disponibile su http://people.opera.com/​howcome/​2000/​css3/clink-nov-6.html; Accesso: 25 ottobre 2004 (copia locale).
[Connolly 1992]
Dan Connolly; MIME as a hypertext architecture; Messaggio postato su www-talk 6 Jun 92; Disponibile su: http://lists.w3.org/​Archives/​Public/​www-talk/​1992MayJun/0020.html; Accesso: 25 ottobre 2004 (copia locale).
[Connolly 1994a]
Connolly, D.; Some Background on SGML for the World-Wide Web; Saggio disponibile su http://www.w3.org/​MarkUp/​html-spec/html-essay.html; Accesso: 25 ottobre 2004 (copia locale).
[Connolly 1994b]
Connolly, D.; Toward Closure on HTML; Messaggio postato su www-talk 4 aprile 1994; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1994q2/0020.html; Accesso: 25 ottobre 2004 (copia locale).
[Connolly 1996]
Connolly, D.; Generic SGML Activity Launched; W3C Newsletter, Volume 2, N. 7, 5 giugno 1996
[Connolly 1997]
Connolly, D.; XML Enables Custom Markup Schemes; W3C Newsletter, Volume 3, N. 6, 21 marzo 1997
[Connolly 2000]
Connolly, D.; Re: XHTML Invalidity / WML2 / New XHTML 1.1 Attribute; Messaggio postato su www-html@w3.org 12 agosto 2000; Disponibile su http://lists.w3.org/​Archives/​Public/​www-html/2000Aug/0052.html Accesso: 25 ottobre 2004 (copia locale).
[CSS draft1 1995]
Cascading Style Sheets: a draft specification; Bozza di specifica pubblicata il 31 maggio 1995; Disponibile su http://www.w3.org/​Style/​CSS/draft1.html; Accesso: 25 ottobre 2004 (copia locale).
[CSS draft2 1995]
Cascading Style Sheets: a draft specification; Bozza di specifica pubblicata il 3 luglio 1995; Disponibile su http://www.w3.org/​Style/​CSS/draft2.html; Accesso: 25 ottobre 2004 (copia locale).
[CSS draft3 1995]
Cascading Style Sheets: a draft specification; Bozza di specifica pubblicata il 10 agosto 1995; Disponibile su http://www.w3.org/​Style/​CSS/draft3.html; Accesso: 25 ottobre 2004 (copia locale).
[CSS draft4 1995]
Cascading Style Sheets: a draft specification; Bozza di specifica pubblicata il 6 ottobre 1995; Disponibile su http://www.w3.org/​Style/​CSS/draft4.html; Accesso: 25 ottobre 2004 (copia locale).
[CSS draft5 1995]
Cascading Style Sheets: fifth draft specification; Bozza di specifica pubblicata il 1 novembre 1995; Disponibile su http://www.w3.org/​Style/​CSS/draft5.html; Accesso: 25 ottobre 2004 (copia locale).
[CSS draft6 1995]
Cascading Style Sheets, level 1; Bozza di Lavoro W3C pubblicata il 17 novembre 1995; Disponibile su http://www.w3.org/​Style/​CSS/draft6.html Accesso: 25 ottobre 2004 (copia locale).
[CSS1 1996]
Cascading Style Sheets, level 1; Lie, H. W. and Bos, B.; Raccomandazione W3C del 17 dicembre 1996; Disponibile su http://www.w3.org/​TR/​REC-CSS1-961217
[CSS2 1998]
Cascading Style Sheets, level 2; Bos, B., Lie, H. W., Lilley, C. and Jacobs, I. (curatori); Raccomandazione W3C del 12 maggio 1998; Disponibile su http://www.w3.org/​TR/​1998/REC-CSS2-19980512
[Davis 1994]
Jim Davis; Re: Toward Closure on HTML; Messaggio postato su www-talk 5 aprile 1994; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1994q2/0050.html; Accesso: 25 ottobre 2004 (copia locale).
[DOM1 1998]
Document Object Model (DOM) Level 1 Specification; Apparao, V., Byrne, S., Champion, M., Isaacs, S., Jacobs, I., Le Hors, A., Nicol, G., Robie, J., Sutor, R., Wilson, C. and Wood, L.; Raccomandazione W3C del 1 ottobre 1998; Disponibile su http://www.w3.org/​TR/REC-DOM-Level-1/
[Dougherty 1993]
Re: Re HMML?; Dougherty, D.; Messaggio postato su www-talk 25 maggio 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0388.html; Accesso: 25 ottobre 2004 (copia locale).
[DSSSL 1996]
Document Style Semantics and Specification Language (DSSSL); ISO/IEC 10179:1996; La specifica DSSSL è disponibile in formato compresso su http://metalab.unc.edu/​pub/​sun-info/​standards/​dsssl/draft/, e in HTML su http://www.cs.berkeley.edu/​~wilensky/​CS294/dsssl/html/
[dssslist]
La mailing list dssslist fu inaugurata nel marzo 1997 come un forum per gli utenti DSSSL. I suoi archivi sono disponibili su http://lists.mulberrytech.com/​dssslist/archives/; Accesso: 25 ottobre 2004.
[DuCharme 2001]
DuCharme, B.; Getting Loopy; xml.com, 1 agosto 2001; Disponibile su http://www.xml.com/pub/​a/​2001/​08/01/gettingloopy.html?page=2; Accesso: 25 ottobre 2004 (copia locale).
[EBT 1997]
EBT ANNOUNCES PLANS TO SUPPORT IMPORTANT NEW PUBLISHING STANDARD: DSSSL; Comunicato stampa di Electronic Book Technologies Inc, Providence, RI, USA; Disponibile su http://xml.coverpages.org/​ebtDSSSL.html; Accesso: 25 ottobre 2004 (copia locale).
[Electronic Publishing]
Electronic Publishing—Origination, Dissemination and Design; John Wiley & Sons, ISSN 0894-3982; Una pagina riassuntiva dei contenuti è disponibile su http://cajun.cs.nott.ac.uk/​compsci/​epo/​papers/epoddtoc.html; Accesso: 25 ottobre 2004
[English 1994a]
English, J.; Style Sheets for HTML; 18 novembre 1994; Versione elettronica disponibile su http://www.w3.org/​Style/​History/jenglish.ps; Accesso: 25 ottobre 2004 (copia locale, copia locale in formato PDF).
[English 1994b]
English, J.; Style Sheets; Messaggio postato su www-html 18 novembre 1994; Disponibile su http://lists.w3.org/​Archives/​Public/​www-html/​1994Nov/0064.html; Accesso: 25 ottobre 2004 (copia locale).
[English 2002]
Corrispondenza personale via email con Joe English, 2002
[FOSI 1997]
MARKUP REQUIREMENTS AND GENERIC STYLE SPECIFICATION FOR EXCHANGE OF TEXT AND ITS PRESENTATION; MIL-PRF-28001C, 2 maggio 1997; Disponibile su http://www.dt.navy.mil/​tot-shi-sys/​tec-inf-sys/​cal-std/​doc/28001C.pdf; Accesso: 25 ottobre 2004 (copia locale).
[FrameMaker]
Una breve storia dell'applicazione per il desktop publishing FrameMaker è disponibile su http://en.wikipedia.org/​wiki/FrameMaker/; Accesso: 25 ottobre 2004 (copia locale).
[Furuta, et al. 1982]
Furuta, R., Scofield, J. and Shaw, A; Document Formatting Systems: Survey, Concepts, and Issues; Computing Surveys, 14, 3, 417­472. (Settembre 1982) ISSN:0360-0300
[Furuta 1992]
Furuta, R; Important papers in the history of document preparation systems: basic sources; Electronic Publishing—Origination, Dissemination, and Design; 5 (1), 19-44, 1992; Disponibile su http://cajun.cs.nott.ac.uk/​compsci/​epo/​papers/​volume5/​issue1/ep057rf.pdf; Accesso: 25 ottobre 2004 (copia locale).
[Germán 1997]
Germán, D. M.; An Introduction to DSSSL; 1997; Disponibile su http://csgrs6k1.uwaterloo.ca/​~dmg/​dsssl/​tutorial/tutorial.html; Accesso: 25 ottobre 2004 (copia locale).
[GIF 1990]
GRAPHICS INTERCHANGE FORMAT(sm); Version 89a, CompuServe Incorporated, Columbus, Ohio, 1990; Disponibile su http://www.w3.org/​Graphics/​GIF/spec-gif89a.txt; Accesso: 25 ottobre 2004 (copia locale).
[Glazman 1997]
Glazman, D.; Simple Tree Transformation Sheets 2; Nota W3C 17 ottobre 1997; Disponibile su http://www.w3.org/​TR/​NOTE-stts2-971017; Accesso: 25 ottobre 2004 (copia locale).
[Glazman 2002]
Glazman, D.; Small Screen Rendering; Post su blog 21 ottobre 2002; Disponibile su http://webperso.easyconnect.fr/​danielglazman/​weblog/​newarchive/​2002_10_20_glazblogarc.html#s83291371; Accesso: 25 ottobre 2004 (copia locale).
[Goldfarb 1991]
Goldfarb, C. F.; The SGML Handbook; Oxford University Press, 1991
[Goldfarb et al.1997]
Goldfarb, C. F., Pepper, S. and Ensign, C.; SGML Buyer's Guide; Prentice Hall, 1997
[Graham, et al. 1992]
Graham, S. L., Harrison, M. A. and Munson, E. V.; The Proteus Presentation System; University of California, Berkeley, California; Il documento apparve nei Proceedings of the Fifth ACM SIGSOFT Symposium on Software Development Environments, Tyson's Corner, VA, 9-11 dicembre 1992;
[Gramlich 1996]
Email di Wayne Gramlich ad HTML ERB, 12 aprile 1996
[Grif 1993]
Grif Languages; Grif S.A., St Quentin en Yvelines, France, 1993
[Grosso 1993]
Corrispondenza personale via email con Paul Grosso, 1993
[Harvey 2000]
Betty Harvey; Re: AW: ebXML - core components glossary of terms and acronyms; Messaggio postato su ebxml-core, 23 giugno 2000; Disponibile su http://lists.ebxml.org/archives/​ebxml-core/​200006/msg00038.html; Accesso: 25 ottobre 2004 (copia locale).
[Harvey 2002]
What SGML Can Teach Us About XML & the Web; Betty Harvey intervistato da Tony Byrne, CMSWatch, 15 gennaio 2002; Disponibile su http://www.cmswatch.com/
Features/PeopleWatch/FeaturedPeople/?feature_id=58
; Accesso: 25 ottobre 2004 (copia locale).
[Hayakawa 1940]
Hayakawa, S. I.; Language in Action; Harcourt, Brace and Company; 1940; Edizioni successive sono intitolate Language in thought and action.
[Heaney 1993]
Heaney, S.; Re: Stylesheet Language; Messaggio postato su www-talk 26 ottobre 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q4/0295.html; Accesso: 25 ottobre 2004 (copia locale).
[HTML+ 1993]
Raggett, D.; HTML+ (Hypertext markup format); 8 novembre 1993; Disponibile su http://www.w3.org/​MarkUp/​HTMLPlus/htmlplus_1.html; Accesso: 25 ottobre 2004 (copia locale).
[HTML 3.2 1997]
Raggett, D.; HTML 3.2 Reference Specification; Raccomandazione W3C 14 gennaio 1997; Disponibile http://www.w3.org/TR/REC-html32.html
[HTML2 1995]
Berners-Lee, T. and Connolly, D.; HTML 2.0; RFC1866, November 1995
[HTML4 1997]
HTML 4.0 Specification; Raggett, D., Le Hors, A. and Jacobs, I.; Racccomandazione W3C 18 dicembre 1997; Disponibile su http://www.w3.org/​TR/REC-html40-971218/
[HTTP 1999]
Hypertext Transfer Protocol – HTTP/1.1; Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and Berners-Lee, T.; RFC2616, giugno 1999
[Hutton 2002]
Hutton, G. (curatore); Frequently Asked Questions for comp.lang.functional; Versione del novembre 2002; Disponibile su http://www.cs.nott.ac.uk/​~gmh/faq.html; Accesso: 25 ottobre 2004 (copia locale).
[Interleaf]
Una breve storia dell'applicazione per il desktop publishing Interleaf è disponibile su http://en.wikipedia.org/​wiki/Interleaf/; Accesso: 25 ottobre 2004 (copia locale).
[Kennedy 1997]
Kennedy, D.; DSSSL; An Introduction; (Una versione dell'articolo fu pubblicata in <TAG>, febbraio 1997.) Disponibile su http://xml.coverpages.org/​kennDSSSLInt.html. Accesso: 26 ottobre 2004 (copia locale).
[Kidwell&Richman 1997]
Kidwell, R. S. and Richman, J. G.; Final DSSSL Survey and Assessment Report for the DOD CALS IDE PROJECT; ManTech Advanced Technology Systems, marzo 1997; Disponibile su http://www.dcnicn.com/​lamp/​cals_ide/​task03/​html/​dssslsar/cals_a009/recon02.htm; Accesso: 25 ottobre 2004 (copia locale).
[Lamport 1986]
Lamport, L.; LaTeX: A document preparation system; Addison-Wesley, Reading, Mass, 1986
[Lamport 2003]
Corrispondenza personale via email con Leslie Lamport, 2003
[Kernighan&Richie 1978]
Kernighan, B. W., Ritchie, D. M.; The C Programming Language; Prentice-Hall, Englewood Cliffs, NJ, 1978
[Khare&Rifkin 1998]
Khare, R., Rifkin, A.; The origin of (document) species; Proceedings of the seventh international conference on World Wide Web, Brisbane, Australia, 1998
[Knuth&Plass 1981]
Knuth, D. E., Plass, M. F.; Breaking Paragraphs into Lines; Software Practice and Experience, 11:1119–1184, 1981
[Knuth 1984]
Knuth, D. E.; The TeXbook; Addison-Wesley, 1984
[Lie 1994]
Lie, H. W.; Cascading HTML Style Sheets; Proposta pubblicata il 10 ottobre 1994; Disponibile su http://www.w3.org/​People/​howcome/​p/cascade.html; Accesso: 25 ottobre 2004 (copia locale).
[Lie 1996]
Lie, H. W.; CSS1 status; Messaggio postato su www-style@w3.org 25 gennaio 1996; Disponibile su http://lists.w3.org/​Archives/​Public/​www-style/1996Jan/0039.html; Accesso: 25 ottobre 2004 (copia locale).
[Lie&Saarela 1999]
Lie, H. W. and Saarela, J.; Multipurpose Web Publishing using HTML, XML and CSS; Comunicazioni dell'ACM, ottobre 1999
[Lorimer 1996]
Lorimer, P.; A critical evaluation of the historical development of the tactile modes of reading and an analysis and evaluation of researches carried out in endeavours to make the braille code easier to read and to write; Tesi Ph.D., University of Birmingham, December 1996
[Magliery 1994]
Magliery, T.; DSSSL-Lite Announcement; Messaggio postato su www-talk 1 dicembre 1994, e su comp.text.sgml, comp.infosystems.www.users, comp.infosystems.www.misc, comp.infosystems.www.providers 2 Dec 1994; Disponibile su http://xml.coverpages.org/​dsssl-lite-ann.html; Accesso: 25 ottobre 2004 (copia locale).
[Marden&Munson 1997]
Marden, P. M. and Munson, E. V.; Multiple presentations of WWW documents using style sheets; Proceedings of the 1997 workshop on New paradigms in information visualization and manipulation, Las Vegas, Nevada, United States, pp. 75-78, 1997
[Marden&Munson 1998]
Marden, P. M. and Munson, E. V.; PSL: An alternate approach to style sheet languages for the world wide web; Journal of Universal Computer Science, 4(10), 1998
[Marden&Munson 1999]
Marden, P. M. and Munson, E. V.; Today's Style Sheet Standards: The Great Vision Blinded; Computer, November 1999
[Mason 2001]
Mason, J. D.; History (was: Re: Montreal meeting recommendations); Messaggio inviato a sc34wg3@isotopicmaps.org 18 settembre 2001; Disponibile su http://www.isotopicmaps.org/​pipermail/​sc34wg3/​2001-September/000047.html; Accesso: 26 ottobre 2004 (copia locale).
[MathML 1998]
Mathematical Markup Language (MathML) 1.0 Specification; Ion, P., Miner, R. (curatori); Raccomandazione W3C 7 aprile 1998; Disponibile su http://www.w3.org/​TR/​1998/REC-MathML-19980407/
[Michalowski 1999]
Michalowski, B.; A Constraint-Based Specification for Box Layout in CSS2; UW Tech Report UW-CSE-98-06-03, Department of Computer Science and Engineering, University of Washington, Seattle, June 1998
[Milowski 1997]
Alexander Milowski; Re: Heresy? Re: DSSSL WWW Enhancements; Messaggio postato su dssslist 18 maggio 1997; Disponibile su http://www.biglist.com/​lists/​dssslist/​archives/​199705/msg00038.html; Accesso: 25 ottobre 2004 (copia locale).
[Mosaic]
Una breve storia del browser Mosaic è disponibile su http://en.wikipedia.org/​wiki/​Mosaic_web_browser; Accesso: 25 ottobre 2004 (copia locale).
[MS-Word]
Una breve storia di Microsoft Word è disponibile su http://en.wikipedia.org/​wiki/Microsoft_Word; Accesso: 25 ottobre 2004 (copia locale).
[Munson 1994]
Munson, E. V.; Proteus: An Adaptable Presentation System for a Software Development and Multimedia Document Environment; Dissertazione PhD, University of California, Berkeley, December 1994
[Munson 1996]
Munson, E. V.; A new presentation language for structured documents; Electronic Publishing, Vol. 8 (2&3), pp. 125­138 (Giugno & Settembre 1995), Documento ricevuto il 16 aprile 1996, rivisto il 28 giugno 1996
[Munson&Pfeiffer 1999]
Munson, E. V., Pfeiffer, M.; A Representation of Media for Multimedia Authoring and Browsing Systems; Proceedings of the AAAI 98 Workshop on Representations for Multi-Modal Human-Computer Interaction, Madison, WI, USA, luglio 1998
[Munson 2003]
Corrispondenza personale via email con Ethan Munson, 2003
[Naggum 1994]
Naggum, E; Erik Naggum's review of DSSSL (DIS); Messaggio postato su comp.text.sgml 5 dicembre 1994 col titolo DSSSL; Disponibile su http://xml.coverpages.org/​dsssl-note-erik.html; Accesso: 25 ottobre 2004 (copia locale).
[Nicol 1995]
Gavin Nicol; Re: A New Era of Afforable Tools; Messaggio postato su comp.text.sgml 10 giugno 1995; Disponibile su http://groups.google.com/​groups?​selm=GTN.95Jun10022744%40ebt-inc&output=gplain; Accesso: 25 ottobre 2004 (copia locale).
[Nielsen&Lie 1994]
Nielsen, H. F. and Lie, H. W.; Towards a Uniform Library of Common Code; Proceedings of Second International WWW Conference '94, Chicago, 1994;
[Nielsen 1996]
Jakob Nielsen; Why Frames Suck (Most of the Time); dicembre 1996; Disponibile su http://www.useit.com/​alertbox/9612.html; Accesso: 25 ottobre 2004
[NOTE-XSL 1997]
A Proposal for XSL; Adler, S., Berglund, A., Clark, J., Cseri, I., Grosso, P., Marsh, J., Nicol, G., Paoli, J., Schach, D., Thompson, H. S. and Wilson, C.; Disponibile su http://www.w3.org/​TR/NOTE-XSL-970910; Accesso: 26 ottobre 2004 (copia locale).
[ODA]
Office Document Architecture (ODA) and Interchange Format; Famiglia di specifiche pubblicate come bozze nel 1988, e divenute ISO/IEC standard nel 1994-1998.
[Opera]
Una breve descrizione del browser Opera è disponibile su http://en.wikipedia.org/​wiki/Opera_browser; Accesso: 25 ottobre 2004 (copia locale).
[OpenOffice]
Una breve descrizione della suite OpenOffice è disponibile su http://en.wikipedia.org/​wiki/Openoffice; Accesso: 25 ottobre 2004 (copia locale).
[OSI]
Una breve descrizione del Open Systems Interconnection Reference Model (OSI Model o OSI Reference Model) si trova su http://en.wikipedia.org/​wiki/OSI_model; Accesso: 25 ottobre 2004 (copia locale).
[Pemberton 2000]
HTML WG Last Call Comments, part 1 of 2; Messaggio postato su www-xml-linking-comments 13 marzo 2000; Disponibile su http://lists.w3.org/​Archives/​Public/​www-xml-linking-comments/​2000JanMar/0073.html; Accesso: 25 ottobre 2004 (copia locale).
[PNG 1996]
PNG (Portable Network Graphics) Specification Version 1.0; Raccomandazione W3C 1 ottobre 1996; Disponibile su http://www.w3.org/TR/REC-png
[Prescod 1997a]
Prescod, P.; Introduction to DSSSL; luglio 1997; Disponibile su http://www.prescod.net/dsssl/; Accesso: 25 ottobre 2004 (copia locale).
[Prescod 1997b]
Prescod, P.; Heresy? Re: DSSSL WWW Enhancements; Messaggio postato su dssslist 18 maggio 1997; Disponibile su http://www.biglist.com/​lists/​dssslist/​archives/​199705/msg00035.html; Accesso: 25 ottobre 2004 (copia locale).
[Quint 1994]
Quint, V.; The Languages of Grif; Tradotto da Ethan Munson, GIPSI S.A., GRIF S.A., Versione del 18 aprile 1994
[Radestock 2004]
Radestock, M.; Scheme Frequently Asked Questions; Versione 1.8, 17 ottobre 2004; Disponibile su http://www.schemers.org/​Documents/FAQ/#N40081C; Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1993a]
Raggett, D.; Standardizing new HTML features; Messaggio postato su www-talk 27 aprile 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0166.html; Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1993b]
Raggett, D.; Re: Standardizing new HTML features; Messaggio postato su www-talk 28 aprile 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0186.html; Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1993c]
Raggett, D.; Re: Mail addresses as URLs; Messaggio postato su www-talk 13 maggio 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0313.html; Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1993d]
Raggett, D.; Re: HTML+ and printed books; Messaggio postato su www-talk 19 maggio 1993; Disponibile su http://www.webhistory.org/www.lists/​www-talk.1993q2/0349.html; Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1993e]
Raggett, D.; Re HMML?; Messaggio postato su www-talk 25 maggio 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0385.html; Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1993f]
Raggett, D.; Re: RE dtd2.html; Messaggio postato su www-talk 27 maggio 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0393.html; Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1993g]
Raggett, D.; Re: Style sheets for HTML; Messaggio postato su www-talk 11 giugno 1993; Disponibile su http://www.webhistory.org/www.lists/​www-talk.1993q2/0448.html; Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1995a]
Raggett, D.; A Review of the HTML+ Document Format; Ultima modifica 1 febbraio 1995; Disponibile su http://www.w3.org/MarkUp/HTMLPlus/​htmlplus_paper/htmlplus.html; Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1995b]
Raggett, D.; Document Type Definition for the HyperText Markup Language (HTML DTD); Pubblicato il 24 marzo 1995; Disponibile su http://www.w3.org/​MarkUp/​html3/html3.dtd Accesso: 25 ottobre 2004 (copia locale).
[Raggett 1995c]
Raggett, D.; HTML Tables; Bozza Internet, 7 luglio 1995; Disponibile su http://www.w3.org/​MarkUp/​html3-tables/tables.txt; Accesso: 25 ottobre 2004 (copia locale).
[Raisch 1993a]
Raisch, R.; Request for Comments: STYLESHEETS; Messaggio postato su www-talk 10 giugno 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q2/0445.html; Accesso: 25 ottobre 2004 (copia locale).
[Raisch 1993b]
Raisch, R.; Re: Stylesheet Language; Messaggio postato su www-talk 23 ottobre 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q4/0269.html; Accesso: 25 ottobre 2004 (copia locale).
[Raman 1996]
Raman, T. V.; Style Sheets For Producing Spoken Renderings; Disponibile su http://www.w3.org/​Style/​CSS/​Speech/speech.html; Accesso: 25 ottobre 2004 (copia locale).
[Reid&Walker 1979]
Reid, B. K. and Walker, J. H.; Scribe Introductory User's Manual; Seconda Edizione, terza ristampa, UniLogic Ltd, Pittsburgh, PA, luglio 1979;
[Reid 1980]
Reid, B. K.; Scribe: A Document Specification Language and its Compiler; dissertazione Phd, Department of Computer Science, Carnegie-Mellon University, Pittsburgh, PA, ottobre 1980
[Reid 1989]
Reid, B. K.; Electronic Mail of Structured Documents; in André, J., Furuta, R., Quint, V. (curatori) Structured Documents, Cambridge University Press, 1989
[Rosenberg et al. 1991]
Rosenberg, J., Sherman, M., Marks, A. e Akkerjuis, J.; Multi-Media Document Translation: Oda and the Express Project Springer-Verlag, 1991
[Sandahl 1999]
Sandahl, T. I.; From Paper to Digital Documents: Challenging and Improving the SGML Approach; Tesi Dr. Scient, Università di Oslo, gennaio 1999
[SGML 1986]
Standard Generalized Markup Language (SGML); ISO 8879:1986
[SGMLUG 1990]
A Brief History of the Development of SGML; SGML Users' Group, 11 giugno 1990; Disponibile su http://www.sgmlsource.com/​history/sgmlhist.htm; Accesso: 25 ottobre 2004 (copia locale).
[Sherman 1991]
Guest Editorial; Sherman, M.; ComputerNetworks and ISDN Systems; 21 (1991) pp. 145-147, North Holland Disponibile su http://reports-archive.adm.cs.cmu.edu/​anon/​itc/CMU-ITC-102.pdf; Accessed 25 Oct 2004 (local copy).
[Sørgaard 1996]
Sørgaard, P. e Sandahl, T. I.; Problems with Styles in Word Processing: A Weak Foundation for Electronic Publishing with SGML; Published in the Proceedings of the 30th HICSS, Wailea, Hawaii, January 7-10, 1997
[Sperberg-McQueen 1994a]
Sperberg-McQueen, C.M.; Sketch of Simple Formatting Primitives; Versione originale pubblicata il 13 settembre 1994, aggiornata il 4 luglio 1995; Disponibile su http://tigger.cc.uic.edu/​~cmsmcq/style-primitives.html; Accesso: 25 ottobre 2004 (copia locale).
[Sperberg-McQueen 1994b]
Re: HTML style sheets; Sperberg-McQueen, C.M.; Messaggio postato su www-html 4 novembre 94; Disponibile su http://lists.w3.org/​Archives/​Public/​www-html/​1994Nov/0023.html; Accesso: 25 ottobre 2004 (copia locale).
[Suck 1996]
Xanadu Redux, Part I: The World Wide Web Consortium could learn a few things from Xanadu; Disponibile su http://www.suck.com/​daily/​96/02/16/daily.html; Accesso: 25 ottobre 2004 (copia locale).
[Thot 2001]
About Thot; Ultima modifica 16 dicembre 2001; Disponibile su http://www.inrialpes.fr/​opera/​Thot/AboutThot.html; Accesso: 25 ottobre 2004 (copia locale).
[USPS 1994]
U.S. Postal Service Purchasing Protest Decision P.S. Protest No. 94-15, Interleaf Inc.; Scritto da William J. Jones, Senior Counsel, Contract Protests and Policies; 4 agosto 1994; Disponibile su http://www.usps.com/​lawdept/​protestdecisions/1994/9415.htm; Accesso: 25 ottobre 2004 (copia locale).
[WASP 2004]
The Web Standards Project; Cascading Style Sheets; Disponibile su http://www.webstandards.org/​learn/​resources/css/; Accesso: 26 ottobre 2004 (copia locale).
[Watson&Davis 1991]
Watson, B. C. e Davis, R.; ODA and SGML: An Assessment of Co-Existence Possibilities; Computer Standards & Interfaces 11 (1990/91) 169-176, Elsevier Science Publishers, 1991
[WD-CSS3-selectors 2001]
Glazman, D., Çelik, T. e Hickson, I.; Selectors; Raccomandazione Candidata W3C, 13 novembre 2001; Disponibile su http://www.w3.org/​TR/​2001/CR-css3-selectors-20011113; Accesso: 25 ottobre 2004.
[WD-hlink]
Pemberton, S. e Ishikawa, M.; HLink – Link recognition for the XHTML Family; Bozza di lavoro W3C, 13 settembre 2002; Disponibile su http://www.w3.org/​TR/​2002/WD-hlink-20020913/
[WD-positioning 1997]
Stevahn, R. (curatore); Positioning HTML Elements with Cascading Style Sheets; Bozza di lavoro W3C, 31 gennaio 1997; Disponibile su http://www.w3.org/​TR/​WD-positioning-970131; Accesso: 25 ottobre 2004 (copia locale).
[WD-style 1997]
Raggett, D., Bos, B. e Lie H. W.; HTML and Style Sheets; Bozza di lavoro W3C, 24 marzo 1997; Disponibile su http://www.w3.org/​TR/​WD-style-970324; Accesso: 25 ottobre 2004 (copia locale).
[WD-XML 1996]
Bray, T. e Sperberg-McQueen, C. M.; Extensible Markup Language (XML); Bozza di lavoro W3C, 14 novembre 1996; Disponibile su http://www.w3.org/​pub/​WWW/​TR/WD-xml-961114.html; Accesso: 25 ottobre 2004 (copia locale).
[Wei 1992]
Il browser Viola è documentato nel Viola Browser Archive; Disponibile su http://www.viola.org; Accesso: 25 ottobre 2004 (copia locale).
[Wei 1993a]
Wei, P. Y.; Stylesheet Language; Messaggio postato su www-talk 22 ottobre 1993; Disponibile, in due parti, su http://www.webhistory.org/​www.lists/​www-talk.1993q4/0264.html e http://www.webhistory.org/​www.lists/​www-talk.1993q4/0265.html; Accesso: 25 ottobre 2004 (copia locale) (copia locale).
[Wei 1993b]
Wei, P. Y.; Re: Stylesheet Language; Messaggio postato su www-talk 23 ottobre 1993; Disponibile su http://www.webhistory.org/​www.lists/​www-talk.1993q4/0276.html; Accesso: 25 ottobre 2004 (copia locale).
[Wei 1993c]
Wei, P. Y.; FOSI; Messaggio postato su www-talk 26 ottobre 1993; Disponibile su http://www.webhistory.org/www.lists/​www-talk.1993q4/0297.html; Accesso: 25 ottobre 2004 (copia locale).
[Wei 1993d]
Wei, P. Y.; Stylesheet; Disponibile su http://www.xcf.berkeley.edu/​~wei/​viola/​book/chp14.html; Accesso: 26 ottobre 2004 (copia locale).
[Wei 1994]
Wei, P. Y.; Re: Cascading HTML style sheets – a proposal; Messaggio postato su www-talk 24 ottobre 1994; Disponibile su http://www.w3.org/​Style/​History/​www.eit.com/​www.lists/​www-talk.1994q4/​0387.html; Accesso: 25 ottobre 2004 (copia locale).
[Weitzman&Wittenberg 1994]
Weitzman, L. e Wittenberg, K.; Automatic presentation of multimedia documents using relational grammars; Proceedings of ACM Multimedia '94, pp. 443-451, ACM Press, ottobre 1994
[Wilson 2003a]
Wilson, B.; Browser Timelines; Disponibile su http://www.blooberry.com/​indexdot/​history/browsers.htm; Accesso: 26 ottobre 2004 (copia locale).
[Wilson 2003b]
Wilson, B.; CSS Support History; Disponibile su http://www.blooberry.com/​indexdot/​css/​supportkey/syntax.htm; Accesso: 26 ottobre 2004 (copia locale).
[WML]
Wireless Markup Language Specification; Versione 1.2, Wireless Application Protocol Forum, 4 novembre 1999
[www-talk]
La mailing list www-talk fu inaugurata nell'ottobre 1991 e ospitò gran parte delle discussioni sullo sviluppo tecnico del Web. La mailing list è archiviata dal W3C ( http://lists.w3.org/​Archives/​Public/www-talk/), e dal World Wide Web History Project (http://www.webhistory.org).
[W3C 2003]
Some early ideas for HTML; Disponibile su http://www.w3.org/​MarkUp/historical. Ultima modifica: 9 gennaio 2003. Accesso: 13 marzo 2005 (copia locale).
[W3C 2004]
W3C CSS1 Test Suite – Version History; Disponibile su http://www.w3.org/​Style/​CSS/​Test/​CSS1/​current/vhistory. Ultima modifica: 25 ottobre 2004. Accesso: 13 marzo 2005 (copia locale).
[Xerox Star]
Una breve descrizione della workstation Xerox Star si trova su http://en.wikipedia.org/​wiki/Xerox_Star/. Accesso: 25 ottobre 2004 (copia locale).
[XLink 2001]
DeRose, S., Maler, E. e Orchard, D.; XML Linking Language (XLink) Version 1.0; Raccomandazione W3C 27 giugno 2001; Disponibile su http://www.w3.org/​TR/​2001/​REC-xlink-20010627/
[XML 1998]
Bray, T., Paoli, J., Sperberg-McQueen, C. M.; Extensible Markup Language (XML) 1.0; Disponibile su http://www.w3.org/​TR/​1998/REC-xml-19980210
[XML-names 1999]
Bray, T., Hollander, D. e Layman, A.; Namespaces in XML; Raccomandazione W3C 14 gennaio 1999; Disponibile su http://www.w3.org/​TR/​1999/REC-xml-names-19990114
[XML-stylesheet 1999]
Clark, J. (curatore); Associating Style Sheets with XML documents, Version 1.0; Raccomandazione W3C 29 giugno 1999; Disponibile su http://www.w3.org/​1999/​06/REC-xml-stylesheet-19990629/
[XSL 2001]
Adler, S., Berglund, A., Caruso, J., Deach, S., Graham, T., Grosso, P., Gutentag, E., Milowski, A., Parnell, S., Richman, J. e Zilles, S.; Extensible Stylesheet Language (XSL) Version 1.0; Raccomandazione W3C 15 ottobre 2001; Disponibile su http://www.w3.org/​TR/​2001/REC-xsl-20011015/
[X11]
X11 (noto anche come X Window System o X) è un sistema a finestre per display bitmap. Una breve descrizione di X11 si trova su http://en.wikipedia.org/wiki/X11; Accesso: 25 ottobre 2004 (copia locale).
[Zeldman 2003]
Zeldman, J.; Designing with Web Standards; New Riders, maggio 2003

Colophon

Scrivere una tesi sui fogli di stile stabilisce determinate aspettative; il documento risultante dovrebbe usare una marcatura propria e fare uso attivo dei fogli di stile. E dovrebbe essere presentabile. Questa sezione descrive in breve come si sono raggiunti questi obiettivi per questa tesi.

Quasi tutti i documenti da me redatti negli ultimi dieci anni (tranne le email) sono stati scritti in HyperText Markup Language (HTML) e presentati con i CSS. Una tesi, tuttavia, è di certo più complessa di una lettera o di una home page. Per prima cosa, una tesi è di norma più lunga della maggior parte degli altri documenti. Poi una tesi, idealmente, dovrebbe avere più semantica degli altri documenti. Da ultimo, la presentazione di una tesi – soprattutto su carta – è una sfida per i CSS.

La lunghezza di una tesi è un grande problema nel processo di authoring. Fondamentalmente, vi sono due modi di gestire questo problema: il documento è diviso in varie parti gestibili (per esempio capitoli), o l'intero documento è tenuto in un file. La scelta giusta dipenderà dalla capacità dell'editor, dalle sue capacità di ricerca e di vista d'insieme e dalle preferenze personali dell'autore. GNU-Emacs, l'editor da me scelto, può editare grandi file ed ha una buona capacità di ricerca all'interno di un file. Ho scelto, perciò, di editare questa tesi come un unico file HTML.

L'HTML fu sviluppato in ambiente scientifico e, in summis, si adatta bene a mantenere la semantica di una tesi. Per esempio, i riferimenti interni ed esterni possono essere marcati come collegamenti, e gli esempi di codice possono essere marcati con l'elemento CODE. Ho scelto di usare l'elemento CODE per marcare il codice HTML in riga. Questo, tuttavia, non è in grado di discernere tra diversi tipi di codice HTML. Non può distinguere, per esempio, tra elementi e attributi HTML. Per mantenere questa distinzione, ho introdotto diversi nomi di classe dati come valori dell'attributo CLASS. Per esempio, la marcatura della frase precedente è:

Per mantenere questa distinzione, ho introdotto diversi nomi di classe
dati come valore dell'attributo <code class="attribute">CLASS</code> .

Similmente, altri elementi sono stati sottoclassificati.

Sembra inutile aggiungere che la presentazione della tesi deve essere specificata coi CSS. Ogni altra soluzione avrebbe, presumo, automaticamente privato la dissertazione di un'ulteriore analisi. Per fortuna i CSS sono in uno stadio di sviluppo in cui specificare la presentazione di una tesi è possibile. Il foglio di stile associato descrive la presentazione su cinque diversi tipi di media: schermo, proiezione, stampa, acustico e palmare. Si può dire che poche persone leggeranno il documento su un dispositivo palmare o acustico, ma il lavoro extra per specificare la presentazione per tali dispositivi di output è minimo.

Il tipo di media che richiede più lavoro è la stampa. L'università di Oslo, come molte altre istituzioni, richiede che le dissertazioni siano presentate su carta stampata. Il requisito non usa la parola carta, ma prescrive che la tesi debba essere presentata rilegata o fissata in cinque copie. Il modo più semplice per soddisfare questo requisito è stampare il documento HTML da un browser. Purtroppo i browser – inclusi quelli di cui ho parziale responsabilità – sono raramente in grado si stampare i documenti web in modo conforme ad una lettura confortevole. Per generare un documento stampato con eleganza, è necessario usare un formattatore dedicato. Ho scelto di usare il formattatore Prince, che supporta le caratteristiche per la stampa dei CSS2 e alcune caratteristiche proposte per i CSS3. Intestazioni e piè di pagina, nota in calce e numeri di pagina nella tavola dei contenuti sono stati specificati nel CSS.

La versione PDF di questo documento e scritta in Bergamo 10pt/15pt. Gli esempi di codice sono scritti in Bitstream Vera Sans Mono 9pt/13pt .

Il risultato è un documento che sono orgoglioso di presentare.