You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
10841 lines
696 KiB
10841 lines
696 KiB
8 months ago
|
<!DOCTYPE html><html lang="en"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||
|
|
<head>
|
||
|
|
|
||
|
|
<link rel="stylesheet" title="full view" href="thesis.css" media="screen" type="text/css" />
|
||
|
|
<link rel="stylesheet" media="print" href="errata.css" type="text/css" />
|
||
|
|
<link rel="alternate stylesheet" title="outline view" href="outline.css" type="text/css" />
|
||
|
|
|
||
|
|
<!--[if lt IE 7]>
|
||
|
|
<style type="text/css" media="screen">
|
||
|
|
/* courtesy of Gabriele Romanato */
|
||
|
|
html, body { height: 100%; overflow-y: hidden }
|
||
|
|
#scroll { height: 100%; width: 100%; overflow: auto; overflow-x: hidden; font-size: 100% }
|
||
|
|
</style>
|
||
|
|
<![endif]-->
|
||
|
|
|
||
|
|
|
||
|
|
<title>PhD Thesis: Cascading Style Sheets</title>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<div class="menu" id="menu">
|
||
|
|
|
||
|
|
<p><em><a href="http://gabrieleromanato.altervista.org/css/lie/tesi/">Italian translation</a></em></p>
|
||
|
|
<p><em><a href="defense.html">Lecture transcriptions</a></em></p>
|
||
|
|
<p><em><a href="css.pdf">PDF version</a></em></p>
|
||
|
|
|
||
|
|
<p><em>Thesis contents:</em></p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><a href="#title">Title</a></li>
|
||
|
|
|
||
|
|
<li><a href="#abstract">Abstract</a></li>
|
||
|
|
|
||
|
|
<li><a href="#inspiration">Inspiration</a></li>
|
||
|
|
|
||
|
|
<li><a href="#toc">Table of contents</a></li>
|
||
|
|
|
||
|
|
<li><a href="#lof">List of figures</a></li>
|
||
|
|
|
||
|
|
<li><a href="#lot">List of tables</a></li>
|
||
|
|
|
||
|
|
<li><a href="#acknowledgements">Acknowledgements</a></li>
|
||
|
|
|
||
|
|
<li><a href="#overview">Overview and summary</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-introduction">Introduction</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-structure">Structured documents</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-preweb">Style sheets prior to the web</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-postweb">Style sheet proposals for the web</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-webreq">Web requirements</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-css">Cascading Style Sheets</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-problems">Problems in CSS</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-ssr">CSS for small screens</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-clink">Cascading links</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-future">Future research</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-conclusion">Conclusions</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-terminology">Glossary</a></li>
|
||
|
|
|
||
|
|
<li><a href="#ch-references">References</a></li>
|
||
|
|
|
||
|
|
<li><a href="#colophon">Colophon</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div id="scroll"> <!-- errata: added element -->
|
||
|
|
<div class="titlepage" id="title"> <!-- errata: added id attribute -->
|
||
|
|
|
||
|
|
<h1 class="title">Cascading Style Sheets</h1>
|
||
|
|
|
||
|
|
<h2>Håkon Wium Lie</h2>
|
||
|
|
|
||
|
|
|
||
|
|
<img alt="Universtity of Oslo's logo" id="logo" src="i/uio-logo-l.png" />
|
||
|
|
|
||
|
|
<div class="bottom"><p>Thesis submitted for the degree of Doctor Philosophiœ<!--Doctor Philosophiae--><br/>Faculty of Mathematics and Natural Sciences<br/>University of Oslo<br/>Norway<br/>2005</p>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="imprint">
|
||
|
|
|
||
|
|
<p>© Håkon Wium Lie, 1994-2005</p>
|
||
|
|
|
||
|
|
<p>This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc/2.5/">Creative Commons Attribution-NonCommercial 2.5 License</a>.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Submitted 29th of March, 2005, as partial fulfillment of the degree<br />
|
||
|
|
Doctor Philosophiœ<!--Doctor Philosophiae--><br />
|
||
|
|
At the Faculty of Mathematics and Natural Sciences<br />
|
||
|
|
University of Oslo<br />
|
||
|
|
Norway</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Series of dissertations submitted to the Faculty of Mathematics and Natural Sciences, University of Oslo.<br/>
|
||
|
|
No. 498</p>
|
||
|
|
|
||
|
|
<p>ISSN 1501-7710</p>
|
||
|
|
|
||
|
|
<div class="bottom print-only">
|
||
|
|
<p>Cover: Inger Sandved Anfinsen.<br/>
|
||
|
|
Printed in Norway: AiT e-dit AS, Oslo, 2006.</p>
|
||
|
|
|
||
|
|
<p>Produced in co-operation with Unipub AS.
|
||
|
|
The thesis is produced by Unipub AS merely in connection with the
|
||
|
|
thesis defence. Kindly direct all inquiries regarding the thesis to the copyright holder or the unit which grants the doctorate.</p>
|
||
|
|
|
||
|
|
<p>Unipub AS is owned by The University Foundation for Student Life (SiO)</p>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="abstract" id="abstract">
|
||
|
|
<h1 class="uchapter" id="h-4">Abstract</h1>
|
||
|
|
|
||
|
|
<p>The topic of this thesis is style sheet languages for structured documents on the web. Due to characteristics of the web – including a screen-centric publishing model, a multitude of output devices, uncertain delivery, strong user preferences, and the possibility for later binding between content and style – the hypothesis is that the web calls for different style sheet languages than does traditional electronic publishing.</p>
|
||
|
|
|
||
|
|
<p>Style sheet languages that were developed and used prior to the web are analyzed and compared with style sheet proposals for the web between 1993-1996. The dissertation describes the design of a web-centric style sheet language known as Cascading Style Sheets (CSS). CSS has several notable features including: cascading, pseudo-classes and pseudo-elements, forward-compatible parsing rules, support for different media types, and a strong emphasis on selectors. Problems in CSS are analyzed, and recommended future research is described.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="dedication" id="inspiration">
|
||
|
|
<h1 class="uchapter" id="h-5">Inspiration</h1>
|
||
|
|
|
||
|
|
<blockquote>Style sheets constitute a wormhole into unspeakable universes.
|
||
|
|
<cite class="author">–James D Mason, 1994</cite></blockquote>
|
||
|
|
|
||
|
|
<blockquote>Style sheet languages are terribly underresearched.
|
||
|
|
<cite class="author">–Philip M Marden, Ethan V Munson, 1999</cite></blockquote>
|
||
|
|
|
||
|
|
<blockquote>In which form are you planning to publish the first edition of the Parsifal poem? Even if I like Latin letters, I'm afraid they are unpopular (especially among publishers). So, if the letters will be German, please make the type large and of good quality. The legibility of a text is very important to me.
|
||
|
|
<cite class="author">–Richard Wagner, in a letter to his publisher Ludwig Strecker</cite></blockquote>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="toc" id="toc">
|
||
|
|
<h1 class="uchapter" id="h-7">Table of contents</h1>
|
||
|
|
|
||
|
|
<ul class="toc">
|
||
|
|
<li class="rchapter"><a href="#h-4">Abstract</a></li>
|
||
|
|
|
||
|
|
<li class="rchapter"><a href="#h-5">Inspiration</a></li>
|
||
|
|
|
||
|
|
<li class="rchapter"><a href="#h-7">Table of contents</a></li>
|
||
|
|
|
||
|
|
<li class="rchapter"><a href="#h-8">List of figures</a></li>
|
||
|
|
|
||
|
|
<li class="rchapter"><a href="#h-9">List of tables</a></li>
|
||
|
|
|
||
|
|
<li class="rchapter"><a href="#h-6">Acknowledgements</a></li>
|
||
|
|
|
||
|
|
<li class="rchapter"><a href="#h-10">Overview and summary of the thesis</a></li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-24">Introduction</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-25">Structure versus presentation</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-26">Abstraction levels</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-27">Presentational HTML</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-28">Style sheets</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-29">WYSIWYG – a competing model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-30">Web characteristics</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-32">Style sheet mechanisms for the web</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-33">CSS</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-34">The CSS development</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-35">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-36">Structured documents</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-37">Abstraction levels</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-38">Structured document systems</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-39">Scribe</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-40">A simple document</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-41">Document types</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-42">Scribe commands</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-43">Formatting environments</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-44">Changing and adding environments</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-45">Scribe in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-46">LaTeX</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-47">Open Document Architecture (ODA)</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-48">Standard Generalized Markup Language (SGML)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-49">Document Type Definition (DTD)</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-50">Processing Instructions</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-51">LINK</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-52">SGML in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-53">HyperText Markup Language (HTML)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-54">HTML's original design</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-55">Structure versus style</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-56">HTML and SGML</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-57">HTML+ and HTML3</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-58">HTML 3.2</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-59">HTML 4</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-60">HTML in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-61">XML</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-62">The SGML Working Group charter</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-63">The XML specification</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-64">XML and style sheets</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-65">XML in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-66">The role of transformation languages</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-67">Adorning the tree</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-69">Transforming the tree</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-70">Formatting objects</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-71">Retaining both semantics and presentation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-72">Style versus transformation</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-73">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-74">Style sheets prior to the web</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-75">Components of a style sheet language</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-76">Formatting Output Specification Instance (FOSI)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-77">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-78">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-79">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-81">Values and units</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-82">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-83">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-84">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-85">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-86">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-87">FOSI in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-88">DSSSL</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-89">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-90">Selectors</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-91">Element construction rule</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-92">Root construction rule</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-93">Default construction rule</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-94">Query construction rule</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-95">ID construction rule</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-96">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-97">Values and units</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-98">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-99">Visual formatting model</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-100">Flow objects</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-101">Areas</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-103">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-104">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-105">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-106">DSSSL in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-107">P94</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-108">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-109">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-111">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-112">Values and units</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-113">Length units</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-116">Constraints</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-118">Elastic values</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-119">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-120">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-121">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-122">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-124">Other formatting contexts</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-125">Views</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-127">P94 in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-128">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-130">Style sheet proposals for the web</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-131">Robert Raisch's proposal (RRP)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-132">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-133">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-134">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-135">Values and units</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-136">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-137">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-138">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-139">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-140">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-141">RRP in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-142">Pei Wei's proposal (PWP)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-143">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-144">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-145">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-146">Values and units</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-147">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-148">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-149">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-150">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-151">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-152">PWP in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-153">Steve Heaney's proposal (SHP)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-154">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-155">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-156">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-157">Values and units</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-158">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-159">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-160">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-161">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-162">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-163">SHP in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-164">Cascading HTML Style Sheets (CHSS)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-165">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-168">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-170">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-171">Values and units</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-172">Expressions</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-174">Blending values</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-176">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-177">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-178">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-179">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-180">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-181">CHSS in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-182">Joe English's proposal (JEP)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-183">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-184">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-185">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-186">Values and units</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-187">Length values</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-188">Color values</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-189">Images</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-190">Keyword values</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-191">Value propagation</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-192">Inheritance</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-193">Cascading</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-194">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-195">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-196">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-197">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-198">JEP in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-199">Sketch of Simple Formatting Primitives (SSFP)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-200">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-201">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-202">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-203">Values and units</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-204">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-205">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-206">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-207">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-208">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-209">SSFP in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-210">DSSSL Lite</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-211">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-212">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-213">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-214">Values and units</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-215">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-216">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-217">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-217b">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-218">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-219">DSSSL Lite in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-231">Stream-based style sheet proposal (SSP)</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-232">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-233">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-234">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-235">Values and units</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-236">Attribute references</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-237">Property references</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-238">Built-in functions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-239">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-240">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-241">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-242">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-243">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-244">SSP in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-245">PSL96</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-246">Syntax</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-248">Selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-249">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-250">Values and units</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-252">Expressions</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-253">Specified versus actual values</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-254">Value propagation</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-255">Visual formatting model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-256">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-257">Generated content</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-258">Other formatting contexts</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-259">PSL96 in context</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-260">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-272">Web requirements</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-272b">Web characteristics formulated as requirements</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-273">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-274">Cascading Style Sheets</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-275">Syntax</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-278">Forward-compatible parsing</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-279">At-keywords</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-280">Selectors</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-281">Simple and contextual selectors</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-282">Pseudo-elements and pseudo-classes</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-283">Selectors in CSS1</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-284">Selectors in CSS2</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-285">Properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-286">Values and units</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-287">Length units</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-288">Value propagation</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-289">Cascading</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-290">The basic cascading mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-295">Multiple sources: User versus author style sheets</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-297">Combining partial style sheets with the browser's default style sheet</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-299">Inheritance</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-300">Initial value</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-301">Visual formatting model</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-302">Creating boxes from elements</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-303">The box model</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-305">Basic boxes: block and inline</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-306">Outside-in versus inside-out formatting</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-308">Beyond the basic box model</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-309">Inspiration from other formatting models</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-314">Linking mechanism</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-315">Generated content</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-317">Counters</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-319">Other formatting contexts</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-320">Media types</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-321">CSS in context</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-322">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-323">Problems in CSS</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-324">Errors in the specifications</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-325">Problems with the specifications</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-326">Missing functionality</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-327">Excessive functionality</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-328">Poor design</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-329">Overloaded properties</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-330">Positioning</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-331">XML syntax</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-334">Cascading problems</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-335">Self-inflicted problems</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-336">Problems resulting from markup</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-337">User interface problems</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-338">Complexity problems</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-339">Problems in implementations</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-340">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-342">CSS for small screens</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-343">The problem</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-344">Cascading</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-345">Linearization</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-346">Element removal</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-347">Element resizing</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><a href="#h-348">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-349">Cascading links</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-349b">Background</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-349c">Background</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-350">Making hyperlinks</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-351">Replaced elements</a></li>
|
||
|
|
|
||
|
|
<li><a href="#h-353">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="chapter"><a href="#h-354">Future research</a>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#h-355">Summary and conclusions</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li class="uchapter"><a href="#h-356">Conclusions</a></li>
|
||
|
|
|
||
|
|
<li class="uchapter"><a href="#h-357">Glossary</a></li>
|
||
|
|
|
||
|
|
<li class="uchapter"><a href="#h-358">References</a></li>
|
||
|
|
|
||
|
|
<li class="uchapter"><a href="#h-359">Colophon</a></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="lot" id="lof">
|
||
|
|
<h1 class="uchapter" id="h-8">List of figures</h1>
|
||
|
|
|
||
|
|
<ol>
|
||
|
|
<li><a href="#f-1">The abstraction ladder.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#f-2">Inheritance and defaulting flow chart in FOSI.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#f-3">The PWP sample document rendered in Viola.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#f-4">The CSS box model.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#f-5">Two different counter styles.</a></li>
|
||
|
|
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="lot" id="lot">
|
||
|
|
<h1 class="uchapter" id="h-9">List of tables</h1>
|
||
|
|
|
||
|
|
<ol>
|
||
|
|
<li><a href="#t-1">A comparison of document formats on the ladder of abstraction.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-2">The ambitions and achievements of the six different structured document systems.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-3">Common environments offered in Scribe.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-4">FOSI's categories.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-5">DSSSL's flow objects and associated properties.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-6">Properties of P94.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-7">RRP's catetories and properties.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-8">A comparison of categories in FOSI and RRP.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-9">A comparison of the font category in RRP and FOSI.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-10">JEP's properties.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-11">Categories in JEP.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-12">SSFP's properties along with CSS equivalents.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-13">The properties of DSSSL Lite.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-14">The number of flow object classes and properties in DSSSL Lite, DSSSL-O and DSSSL.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-15">Properties proposed by SSP.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-16">An evaluation of how different style sheet languages and proposals perform with respect to web requirements.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-17">Selectors in CSS1.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-18">Selectors added in CSS2.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-19">Properties in CSS1.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-20">Properties introduced in CSS2.</a></li>
|
||
|
|
|
||
|
|
<li><a href="#t-21">CSS evaluated with respect to the web requirements.</a></li>
|
||
|
|
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="foreword" id="acknowledgements">
|
||
|
|
<h1 class="uchapter" id="h-6">Acknowledgements</h1>
|
||
|
|
|
||
|
|
<p>Having glanced through a fair number of doctoral dissertations myself, I believe the acknowledgements to be one of the most widely read sections. It is where the author, for a brief moment, can stray from the dryness of academic writing to express years of accumulated frustration and gratitude. Having worked on Cascading Style Sheets (CSS) for a decade, I have had my fair share of both frustration and gratitude. I'll try to express the latter in words while the frustration will be left to the <a href="#leading" class="term">leading</a>.<span class="fn">Terms in bold are explained in the <a href="#ch-terminology" class="addpage">Glossary</a>.</span></p>
|
||
|
|
|
||
|
|
<p>My gratitude goes first and foremost to my parents, Sissel and Alfred Lie. My father set a fine academic example by getting his PhD at the age of 50 and the fact that I'm beating him by a decade or so is a complement to him rather than to me. My mother's love of publications and her extensive information filing system have also contributed to my own urge to get my notes into order. I hereby pass the challenge of beating their father to a PhD onto my own children. Or, at least, to get their notes in order.</p>
|
||
|
|
|
||
|
|
<p>Two very special people deserve particular mention and thanks; without them, this thesis would not exist. Bert Bos joined me at a point when CSS had been named and waved, but was still a set of immature ideas rather than a coherent specification. During some short weeks around a white-board in the summer of 1995, CSS was hammered out. I will remember that time in Sophia-Antipolis as some of best days and nights of my life. Karen Mosman is my publisher, muse and partner. Her enduring loyalty to my writing and to my person has changed both for the better. My writing and my person, that is; Karen herself is practically perfect.</p>
|
||
|
|
|
||
|
|
<p>The World Wide Web Consortium (W3C) has been a good home for CSS. I thank Tim Berners-Lee and Jean-Francois Abramatic for setting up the organizational structures necessary to make it happen. Tim also gets very special thanks for inventing the web, not patenting it, and leaving a stylistic gap to filled. Among my W3C colleagues who were instrumental in supporting the work in the early days are Dave Raggett and Dan Connolly. Dave's browser, later named Arena, provided the perfect testing ground for CSS. Dan – after some healthy initial resistance – supported me when presenting CSS to the W3C HTML Editorial Review Board (ERB) which he co-chaired with Dave.</p>
|
||
|
|
|
||
|
|
<p>One small anecdote from the ERB meeting in April 1996 is worth recounting. Since I was there primarily to present CSS rather than take part in HTML discussions, I was given the task of taking minutes. It so happened that the name of the next HTML version was decided in this meeting. I hope I will be forgiven for disclosing an (anonymized) excerpt from the minutes:</p>
|
||
|
|
|
||
|
|
<blockquote>
|
||
|
|
<pre>The naming issue was raised, and the meeting switched
|
||
|
|
into brainstorm mode. Suggestions fell into three groups:
|
||
|
|
- version numbers: 3.1, 3.2, 3.5, 4.0
|
||
|
|
- code names: Wilbur, Classic HTML, Unified HTML,
|
||
|
|
Common HTML, W3C HTML
|
||
|
|
- compounds: HTML96, W3C HTML4
|
||
|
|
In the end, people preferred version numbers. <em>NN</em>
|
||
|
|
argued that Wilbur was a major change that deserved a new
|
||
|
|
major number: 4.0. Other people didn't like the zero in
|
||
|
|
that name. "HTML 3.2" was selected after discussions and
|
||
|
|
votes.
|
||
|
|
</pre>
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<p>So, somewhat by accident, I was the first person to type the now ubiquitous string <q>HTML 3.2</q> into a computer. A few small key strokes for a man, a giant leap for the web.</p>
|
||
|
|
|
||
|
|
<p>Inside W3C, the CSS Working Group has been the keeper of the flame. Some highly intelligent and dedicated people joined the group over the years. I would especially like to thank Ian Hickson, David Baron, Tantek Çelik, Daniel Glazman and Eric Meyer. Additionally, Steven Pemberton chaired the first W3C Workshop on Style Sheets, Chris Lilley served as chair for many years, and Ian Jacobs contributed his editorial skills. I am grateful to all of you.</p>
|
||
|
|
|
||
|
|
<p>In 1999, when CSS1 and CSS2 had been written, I joined Opera Software to ensure that the specifications were implemented correctly by at least one browser. Thanks go to Jon von Tetzchner and Geir Ivarsøy for founding a company worth working for. Geir, along with Karl Anders Øygard, is also the mastermind behind Opera's display engine that makes CSS shine on screens of all sizes. Thanks also go to Snorre Grimsby, Rijk van Geijtenbeek, Brian Wilson and Sue Sims for supporting CSS internally and externally.</p>
|
||
|
|
|
||
|
|
<p>Many people have been helpful while writing this thesis. I am indebted to 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 and Bette Harvey for answering my many questions about the past. I am grateful to Joe English, Wayne Gramlich, James Mason, Jeff Moore and Dan Connolly for allowing me to quote from their unpublished writings. Gunilla Petersén of the Royal Swedish Opera directed me to the inspirational Wagner quote.</p>
|
||
|
|
|
||
|
|
<p>This thesis concerns style sheet proposals for the web. I am grateful to the authors of the proposals for contributing a very interesting topic of research. Having analyzed their proposals without having access to their minds, I may have misunderstood or misinterpreted their work. If so, please contact me. Thanks also go to the participants on the www-talk, www-html and www-style mailing lists. Without the communities that formed on the mailing lists, the web would not have existed as we know it today.</p>
|
||
|
|
|
||
|
|
<p>CSS has borrowed many ideas from the MIT Media Lab where I spent two forming years. Thanks to Walter Bender and Andy Lippman for exposing me to those ideas. At the University of Oslo, Ole Hanseth and Gisle Hannemyr have motivated me to write up my notes into a thesis, and advised me on how this should be done. Without them, my notes would still be scattered around.</p>
|
||
|
|
|
||
|
|
<p>I am grateful to Anthea Vaughan for patiently copy-editing my drafts.</p>
|
||
|
|
|
||
|
|
<p>I would like to thank the people who created <em class="product">FrameMaker</em>, <em class="product">GNU-emacs</em>, and the <em class="product">Prince</em> formatter. FrameMaker taught me typography, GNU-emacs gracefully accepted all my handcrafted tags, and Prince put this thesis onto paper.</p>
|
||
|
|
|
||
|
|
<p class="author">Oslo, March 2005<br />
|
||
|
|
Håkon Wium Lie</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="uchapter" id="overview">
|
||
|
|
|
||
|
|
<h1 class="uchapter" id="h-10">Overview and summary of the thesis</h1>
|
||
|
|
|
||
|
|
<p>The topic of this thesis is style sheet languages for structured documents on the web. The hypothesis is that the web calls for different style sheet languages than does traditional electronic publishing. Further, the design of a style sheet language that fulfills the specific requirements of the web, namely Cascading Style Sheets, is described. The thesis can be divided into a <em>why</em> part (Chapter 1-5), a <em>how</em> part (Chapter 6-9), and where to go from here (Chapter 10).</p>
|
||
|
|
|
||
|
|
<h3 id="h-11"><a href="#ch-introduction">Chapter 1: Introduction</a></h3>
|
||
|
|
|
||
|
|
<p>The first chapter is an introduction to the the topic of the thesis and related subjects. The historical context in which CSS was developed is described, including the development of HTML from its roots in structured documents to the presentational <a href="#tag" class="term">tags</a> introduced by various <a href="#browser" class="term">browsers</a>. Key concepts such as <a href="#structured_document" class="term">structured documents</a>, <a href="#style_sheet" class="term">style sheets</a> and <a href="#cascading" class="term">cascading</a> are introduced.</p>
|
||
|
|
|
||
|
|
<h3 id="h-12"><a href="#ch-structure">Chapter 2: Structured documents</a></h3>
|
||
|
|
|
||
|
|
<p>Style sheet languages and structured documents are mutually dependent. Without style sheets, structured documents cannot be presented, and without structured documents there is nothing for style sheets to present. Chapter 2 starts by introducing the <a href="#ladder_of_abstraction" class="term">ladder of abstraction</a> which is proposed as a measuring tool for structured document formats. Such formats developed prior to the web (Scribe, LaTeX, ODA, SGML) and for the web (HTML, XML) are described. Finally, the role of <a class="term" href="#transformation_language">transformation languages</a> vs. style sheet languages is discussed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-13"><a href="#ch-preweb">Chapter 3: Style sheets prior to the web</a></h3>
|
||
|
|
|
||
|
|
<p>Chapter 3 is the first chapter in which style sheets are discussed in some detail. The first part of the chapter establishes a set of criteria for style sheet languages; in order to qualify as a style sheet language six components must be present: syntax, <a href="#selector" class="term">selectors</a>, <a href="#property" class="term">properties</a>, <a href="#values" class="term">values</a> and <a href="#unit" class="term">units</a>, <a class="term" href="#value_propagation">value propagation</a> and a <a href="#formatting_model">formatting model</a>. Three style sheet languages developed before the Web (FOSI, DSSSL and P94) are described. The historical background of each is followed by a technical review.</p>
|
||
|
|
|
||
|
|
<h3 id="h-14"><a href="#ch-postweb">Chapter 4: Style sheet proposals for the web</a></h3>
|
||
|
|
|
||
|
|
<p>This chapter is a survey of the style sheet languages that were proposed for the web in the period 1993-1996. Nine different <a class="term" href="#proposal">proposals</a> are reviewed according to the criteria established in the previous chapter.</p>
|
||
|
|
|
||
|
|
<h3 id="h-15"><a href="#ch-webreq">Chapter 5: Web requirements</a></h3>
|
||
|
|
|
||
|
|
<p>Publishing on the web is different from other types of electronic publishing. Six web-specific requirements are discussed in Chapter 5. None of the pre-web style sheet languages nor subsequent style sheet language proposals fulfill all requirements for publishing on the web.</p>
|
||
|
|
|
||
|
|
<h3 id="h-16"><a href="#ch-css">Chapter 6: Cascading Style Sheets</a></h3>
|
||
|
|
|
||
|
|
<p>This chapter marks the start of the <q>how</q> section of the thesis. In this chapter Cascading Style Sheets (CSS) is described in some detail, and the language is evaluated according to the criteria that were established in <a href="#ch-preweb">Chapter 3</a>. CSS is also evaluated against the web requirements discussed in Chapter 5.</p>
|
||
|
|
|
||
|
|
<h3 id="h-19"><a href="#ch-problems">Chapter 7: Problems in CSS</a></h3>
|
||
|
|
|
||
|
|
<p>This chapter discusses problems in, and related to, the CSS specifications. These range from simple spelling errors to more complex questions such as whether or not some functionality fulfills its intended role. The chapter is loosely organized along an axis of complexity; the first part describes how simple errors have been handled. Thereafter, real and perceived problems in the specifications are discussed. The last section is dedicated to problems in the cascading mechanism.</p>
|
||
|
|
|
||
|
|
<h3 id="h-17"><a href="#ch-ssr">Chapter 8: CSS for small screens</a></h3>
|
||
|
|
|
||
|
|
<p>This chapter describes how cascading can be used to render <a class="term" href="#web_page">web pages</a> on small screens. By enforcing a carefully crafted <a class="term" href="#browser_style_sheet">browser style sheet</a>, web pages are reformatted into narrow columns to avoid horizontal scrolling.</p>
|
||
|
|
|
||
|
|
<h3 id="h-18"><a href="#ch-clink">Chapter 9: Cascading links</a></h3>
|
||
|
|
|
||
|
|
<p>A novel use of CSS to represent hyperlink information rather than stylistic information is discussed in this chapter. Cascading links make it possible to deploy new <a href="#markup_language" class="term">markup languages</a> with hyperlinks in them, without <a href="#user_agent" class="term">user agents</a> knowing how linking information is coded.</p>
|
||
|
|
|
||
|
|
<h3 id="h-20"><a href="#ch-future">Chapter 10: Future research</a></h3>
|
||
|
|
|
||
|
|
<p>This chapter points to areas of future research and development that are likely to yield beneficial results.</p>
|
||
|
|
|
||
|
|
<h3 id="h-21"><a href="#ch-conclusion">Chapter 11: Conclusions</a></h3>
|
||
|
|
|
||
|
|
<p>The conclusions support the argument of the thesis: due to its characteristics, the web calls for style sheet languages different from those for traditional electronic publishing. The main contributions of the thesis are listed: the ladder of abstraction, the components of a style sheet language, the web requirements on style sheet languages, and CSS.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-introduction" title="Introduction">
|
||
|
|
<h1 class="chapter" id="h-24">Introduction</h1>
|
||
|
|
|
||
|
|
<p>Around 1990, Tim Berners-Lee developed three specifications that formed the basis of the <a href="#world_wide_web">World Wide Web</a> project: the HyperText Markup Language (HTML) was developed as a <a class="term" href="#document_format">document format</a> for the web; Universal Resource Locators (URL) were added to represent <a class="term" href="#link">links</a> between the documents; and the HyperText Transfer Protocol (HTTP) was developed to transfer <a class="term" href="#document">documents</a> between machines on the internet <a href="#Berners-Lee_1999">[Berners-Lee 1999]</a>. Both specifications and implementations were made freely available by CERN.</p>
|
||
|
|
|
||
|
|
<p>The web quickly gained momentum. With the launch of the National Center for Supercomputing Applications (NCSA) Mosaic browser in 1993 <a href="#Andreessen_1993a">[Andreessen 1993a]</a>, <a class="term" href="#user">users</a> suddenly had an attractive browser to <a class="term" href="surf">surf</a> a steadily increasing set of interlinked documents. With an rising number of users, more authors were attracted to the web, and content proliferated.</p>
|
||
|
|
|
||
|
|
<p>In the beginning, HTML, was a simple <a href="#structured_document" class="term">structured document</a> format with <a href="#markup" class="term">markup</a> tags added between text strings to indicate the role of the text. For example, a string of text could be marked as a paragraph, while another string could be marked as a clickable link. The elements in early HTML were <a class="term" href="#logical_element">logical</a> rather than <a class="term" href="#presentational_element">presentational</a>. For example, HTML would mark some text as a heading but would not describe how the heading was to be presented. The presentation of text – including what <a href="#font" class="term">font</a>, color and size to use – was primarily determined by the browser.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-25">Structure versus presentation</h2>
|
||
|
|
|
||
|
|
<p>Scientific environments such as CERN value logic, structure and content more highly than aesthetics, imagery and style. This sense of structure is reflected in HTML. Each paragraph is marked as such and headings are given a numbered level to indicate their place in the document structure.</p>
|
||
|
|
|
||
|
|
<p>As the web attracted attention outside of scientific environments, authors started complaining that they did not have enough influence over the appearance of their pages. One of the most frequent questions asked by authors new to the web was how to change fonts and colors of elements. This excerpt from a message sent to the www-talk <a href="#www-talk">[www-talk]</a> mailing list early in 1994 <a href="#Andreessen_1994a">[Andreessen 1994a]</a>, gives a sense of the tension between authors and browser implementors<span class="fn">I have quoted from a message sent to a mailing list for the developer community in this chapter, and will do so many times in chapters to come. Mailing lists were crucial for bringing together the web community in the early years, and hypertext archives of mailing lists quickly sprang up in the early 1990s. Today, a decade later, these archives provide valuable insights to the web's design and development. </span>:</p>
|
||
|
|
|
||
|
|
<blockquote>In fact, it has been a constant source of delight for me over the past year to get to continually tell hordes (literally) of people who want to – strap yourselves in, here it comes – control what their documents look like in ways that would be trivial in TeX, Microsoft Word, and every other common text processing environment: 'Sorry, you're screwed.'</blockquote>
|
||
|
|
|
||
|
|
<p>The author of the message was Marc Andreessen, one of the programmers behind the popular NCSA Mosaic browser. He later became a co-founder of Netscape which fullfilled authors' requests by introducing presentational tags in HTML. On October 13, 1994, Netscape announced <a href="#Andreessen_1994b">[Andreessen 1994b]</a> the first beta release of their browser. The Netscape browser supported a set of new presentational HTML tags (e.g. <code class="element">CENTER</code> to center text) and more were to follow shortly.</p>
|
||
|
|
|
||
|
|
<h3 id="h-26">Abstraction levels</h3>
|
||
|
|
|
||
|
|
<p>By adding presentational tags to HTML, the language evolved from being an abstract, structured, markup language where authors marked the different logical roles of the text (paragraphs, headlines, lists and so forth) towards a concrete presentation language where emphasis is on the <a href="#final_form" class="term">final form</a> presentation of documents (fonts, colors and layout).</p>
|
||
|
|
|
||
|
|
<p>In traditional paper-based publishing, the <a href="#reader" class="term">reader</a> receives a final form product. Each letter on a printed page has a fixed position, shape, size and color that cannot be changed by the reader. Electronic documents, however, are unfinished products that must be assembled before they can be presented to the human reader. In the assembly process – better known as <a href="#formatting" class="term">formatting</a> – many choices of how to present the document are made. For example, the browser must pick the fonts and colors to use when presenting the document on a color screen. The level of processing that an electronic document needs will vary considerably depending on what document format is used. As such, electronic documents are similar to furniture: some furniture comes pre-assembled while other items are bought in flat packages and the owner must do the final assembly. If a document format requires much processing, it is said to have a high level of abstraction. If the document format needs little processing, it is said to have a low level of abstraction.</p>
|
||
|
|
|
||
|
|
<p>Determining the right abstraction level is an important part of designing a document format. If the abstraction level is high, both the authoring process and the task of formatting the document become more complex. The author must relate to non-visible abstract concepts. On the receiving end, the browser must transform elements from abstract to concrete objects and this task is more complex if the elements are highly abstract. The benefit of a high abstraction level is that the content can be reused in many contexts. For example, a headline can be presented in large letters on printed sheets, and with a louder voice in a text-to-speech system.</p>
|
||
|
|
|
||
|
|
<p>Conversely, a low level of abstraction will make the authoring and formatting process easier (up to a point). Authors can use visually oriented WYSIWYG (What You See Is What You Get) tools, and the browser does not have to perform extensive transformations before presenting the document. The drawback of using presentation-oriented document formats is that the content is not easily reusable in other contexts. For example, it can be difficult to make presentation-oriented documents available on a device with a different screen size, or to a visually impaired person.</p>
|
||
|
|
|
||
|
|
<p>When transforming documents from one format to another, the chances are that the two formats are at different abstraction levels. In general, it is possible to transform documents from a higher to a lower abstraction level, but not the other way around. The ladder of abstraction is introduced in this thesis as a way of measuring the level of abstraction.</p>
|
||
|
|
|
||
|
|
<h3 id="h-27">Presentational HTML</h3>
|
||
|
|
|
||
|
|
|
||
|
|
<p>The introduction of presentational tags in HTML was a downwards move on the ladder of abstraction. Several of the new elements (e.g., <code class="element">BLINK</code>) were meaningful only for particular output devices (how is blinking text displayed in a text-to-speech system?). The creators of HTML intended it to be usable in many settings but presentational tags threatened device independence, accessibility and content reuse.</p>
|
||
|
|
|
||
|
|
<p>The development of HTML into a presentation-oriented language also changed the power balance between authors and users. Structured documents must be formatted by the browser before presentation, and – to some extent – the formatting process can be influenced by the user. However, when the browser receives a document in its final form, the formatting process is complete and can no longer be influenced by the user.</p>
|
||
|
|
|
||
|
|
<p>Web authors had asked for more influence over the document presentation and welcomed this development, but there was also resistance in the web community. Many felt that the web had the potential of realizing personalized publishing where the reader – rather than the publisher – was in control. Content should be selectable based on reader preferences, and the medium and form of presentation should also be the choice of the reader. By turning HTML into a presentation language there was a risk of losing the degrees of freedom necessary to realize a user-centric publishing model.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-28">Style sheets</h2>
|
||
|
|
|
||
|
|
<p>Style sheets were proposed as an alternative to the evolution of HTML from a structural language to a presentational language. The term <a href="#style_sheet" class="term">style sheet</a> is used in traditional publishing as a way to <q>ensure consistency</q> <a href="#Chicago_1993">[Chicago 1993]</a> in documents. In the traditional publishing process, a manuscript is accompanied by a style sheet which serves as a <q>running account of rules about diction and language usage adopted for a particular manuscript</q> <a href="#Bruggemann-Klein_1992">[Brüggemann-Klein&Wood 1992]</a>.</p>
|
||
|
|
|
||
|
|
<p>In the 1980's, publishing changed dramatically with the introduction of personal computers for use in the preparation of manuscripts. <a href="#electronic_publishing" class="term">Electronic publishing</a> offered tools to ease all stages of publishing from authoring, through editing, to printing. In electronic publishing, the term <a href="#style_sheet" class="term">style sheets</a> came to mean a set of rules regarding how to <em>present</em> content, rather than rules for how to <em>author</em> content. Style sheets would be specified by the <a class="term" href="#designer">designer</a> and sent to the typesetter before printing. Typically, they would describe the visual layout of a text-centric document, including fonts, colors and white space.</p>
|
||
|
|
|
||
|
|
<p>In this thesis, the term <a class="term" href="#style_sheet">style sheet</a> refers to a set of rules that associate stylistic properties and values with structural elements in a document, thereby expressing how to present the document. Style sheets generally do not contain content, are linkable from documents, and they are reusable. This definition allows the term to be used in the context of electronic publishing both off and on the web.</p>
|
||
|
|
|
||
|
|
<p>Style sheets were available in electronic publishing systems from around 1980 (see Chapter 2 and 3). Combined with structured documents, style sheets offered <a href="#late_binding" class="term">late binding</a> <a href="#Reid_1989">[Reid 1989]</a> of content and presentation where the content and the presentation are combined after the authoring is complete. This idea was attractive to publishers for two reasons. First, a consistent style could be achieved across a range of publications. Second, the author did not have to worry about the presentation of the publication but could concentrate on the content.</p>
|
||
|
|
|
||
|
|
<p>Indeed, some authors found it liberating not having to worry about presentational details in the authoring process <a href="#Cailliau_1997">[Cailliau 1997]</a>. However, most authors ended up using authoring systems which emphasizes the presentation rather than the structure <a href="#Sorgaard_1996">[Sørgaard 1996]</a>.</p>
|
||
|
|
|
||
|
|
<h3 id="h-29">WYSIWYG – a competing model</h3>
|
||
|
|
|
||
|
|
<p>WYSIWYG – What You See Is What You Get – is a competing model for authoring documents. WYSIWYG <a class="term" href="#application">applications</a> constantly update a <a class="term" href="#final_form">final form</a> presentation. As the author types, the screen is updated to reflect the page layout that would result should the document be printed at that point.</p>
|
||
|
|
|
||
|
|
<p>Instead of the <a href="#late_binding" class="term">late binding</a> between presentation and content, employed by structured documents and style sheets, WYSIWYG offers <a class="term" href="#instant_binding">instant binding</a>; all editing operations result in instant visual changes to the final presentation. This approach often results in documents whose authors emphasize the final presentation – which is typically a printed document – rather than the <a href="#logical_markup" class="term">logical markup</a>.</p>
|
||
|
|
|
||
|
|
<p>Several applications try to combine the concept of structured documents with WYSIWYG editing, including Adobe's FrameMaker <a href="#FrameMaker">[FrameMaker]</a>, Microsoft's Word <a href="#MS-Word">[MS-Word]</a> and W3C's Amaya <a href="#Amaya">[Amaya]</a>. Typically, these applications offer the author several views of the document one of which is WYSIWYG and others that are more structural. This makes it possible to author structured documents with a WYSIWYG tool. There is a risk associated with using WYSIWIG tools, however: they also allow authors to make purely presentational modifications which may not be consistent with the document structure.</p>
|
||
|
|
|
||
|
|
<h3 id="h-30">Web characteristics</h3>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Research has shown that when documents are authored with the printed copy as the final target, it is difficult to motivate authors to work on a logical level rather than a visual level <a href="#Sandahl_1999">[Sandahl 1999]</a>. With the emergence of the web, however, the possibilities for reuse of content increases. Instead of printing and distributing documents on paper, web documents are transferred electronically to the user's computer. The shift towards electronic distribution of documents has several key characteristics that influence both the authoring process and style sheet languages.</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Late binding becomes later binding: On the web, documents are transmitted in electronic form to the user's computer. The <a href="#late_binding" class="term">late binding</a> between content and presentation of electronic publishing becomes even <a href="#later_binding" class="term">later binding</a> on the web. The binding no longer takes place in the publishing house but, rather, in the user's computer. This increases the freedom of the presentation but also poses a new performance challenge since the binding takes place while the user is waiting. Also, the author is not present to make sure that the presentation is correct.</li>
|
||
|
|
|
||
|
|
<li>Paper-centric publishing becomes screen-centric: Before the advent of the web, most electronic documents ended up as printed documents. They were edited and processed on computer screens but, most often, the final media type was print. On the web, most users view documents on a screen.</li>
|
||
|
|
|
||
|
|
<li>Single output becomes multiple outputs: Although screens are the primary media type on the web, many other types exist. Authors do not know what kind of output device will be employed by a user. There is no longer one final form presentation, there are many. Therefore, it is important that style sheets can describe presentations for multiple output devices.</li>
|
||
|
|
|
||
|
|
<li>Author control becomes shared author/user influence: Since the binding between content and presentation takes place in the user's computer, influences from several sources may be combined to form a presentation. Given this freedom, it seems reasonable that the user – as well as the author – should be able to influence the presentation. Personalized presentations based on the needs and preferences of the user become possible. This is different from other publishing environments where authors and publishers have full control of the presentation.</li>
|
||
|
|
|
||
|
|
<li>Stand-alone documents become hyperlinked: The web is a large collection of hyperlinked documents and information that was previously expressed as textual references can now be active hyperlinks.</li>
|
||
|
|
|
||
|
|
<li>Dependable delivery becomes uncertain: Web resources are distributed across many connected computers and the chance of a resource not being available is significant. Another change is that the web is more likely to fail than are in-house publishing systems. It is natural to make the style sheet available on the web, but the resource may not always be available at the user's end.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Thus, with the introduction of the web the focus of style sheets is shifted from being an author's tool in the authoring process to being a tool for content reuse after the content has been generated. Style sheets on the web are potentially more important than are style sheets for paper-centric publishing because the possibility of content reuse is greater. Just as the nature of style sheets changed from paper-based publishing to electronic publishing, so has the nature of style sheets changed again for web publishing.</p>
|
||
|
|
|
||
|
|
<h3 id="h-32">Style sheet mechanisms for the web</h3>
|
||
|
|
|
||
|
|
<p>A crude form of style sheets was hard-coded into the first WWW <a class="term" href="#client">client</a> implemented on the NeXT machine at CERN. However, no specification for style sheets was written and no syntax for a style sheet language was proposed; it was considered a matter for each browser to decide how to best display pages to its users.</p>
|
||
|
|
|
||
|
|
<p>The potential benefits of using style sheets on the web are significant. A well-developed style sheet mechanism would give authors a richer stylistic vocabulary than they could hope for in an evolving HTML. Also, HTML would remain a structured markup language that worked on a wide range of devices.</p>
|
||
|
|
|
||
|
|
<p>For these reasons, many people on the www-talk mailing list <a href="#www-talk">[www-talk]</a>, which was the electronic meeting place for the early web community, agreed that the web could benefit from style sheets. However, there was disagreement as to whether or not the web would require a new style sheet language or if one of the existing languages, designed primarily for paper-based publishing, would be suitable.</p>
|
||
|
|
|
||
|
|
<p>Several style sheet languages for the web were proposed in 1993 (see <a href="#ch-postweb">Chapter 4: Style sheet proposals for the web</a>) but none of them gained momentum. This was mostly due to lack of support in browsers; as long as Mosaic – by far the most popular browser of its day – did not support style sheets there was little motivation for authors to write them. Also, none of the proposals were developed to a stable state. A successful style sheet language for the web had to be compelling enough both for browser developers to implement, and for authors to use.</p>
|
||
|
|
|
||
|
|
<h2 id="h-33">CSS</h2>
|
||
|
|
|
||
|
|
<p>Three days before Netscape announced their new browser, this author published the first CSS proposal (named <em class="title">Cascading HTML style sheets – a proposal</em>) <a href="#Lie_1994">[Lie 1994]</a> on the web. In addition to describing fonts, colors and layout of documents – which several proposals had done previously – CSS introduced new functionality to account for the differences in publishing imposed by the web. The concept of <a href="#cascading" class="term">cascading</a> allowed both authors and users to influence the presentation of a document:</p>
|
||
|
|
|
||
|
|
<blockquote>The proposed scheme supplies the brower with an ordered list (cascade) of style sheets. The user supplies the initial sheet which may request total control of the presentation, but – more likely – hands most of the influence over to the style sheets referenced in the incoming document.</blockquote>
|
||
|
|
|
||
|
|
<p>Negotiating between the needs and wishes of readers and authors was one of the main ambitions of CSS. If successful, authors would get their fair share of influence over the presentation and would not feel compelled to use presentational HTML and other tricks. Readers, on the other hand, would be served documents in a form in which they could choose between accepting the author's suggested presentation or specify their own.</p>
|
||
|
|
|
||
|
|
<p>In many cases there would be no conflict between the author and the reader. Neither would want to specify the presentation of the document. In such cases, it is important for the browser to have a <a href="#default_style_sheet" class="term">default style sheet</a> that describes a default presentation of HTML documents. CSS, therefore, defines three possible sources for style sheets: authors, readers, and browsers. CSS is able to combine style sheets from these sources to form the presentation of a document. The process of combining several style sheets – and resolving conflicts if they occur – is known as cascading.</p>
|
||
|
|
|
||
|
|
<h3 id="h-34">The CSS development</h3>
|
||
|
|
|
||
|
|
<p>The first CSS proposal was put forward in the spirit of open exchange of ideas on how the web should develop, and discussions took place on public mailing lists. A number of people responded to the proposal <a href="#Bos_1994">[Bos 1994]</a><a href="#Behlendorf_1994">[Behlendorf 1994]</a><a href="#Wei_1994">[Wei 1994]</a> and the <a class="term" href="#draft">draft</a> was developed further. During the course of 1995, approximately eight revisions were published. The last of these, published in December 1995, was declared to be stable and browser vendors were <q>encouraged to use it as a base for implementations</q> <a href="#Lie_1996">[Lie 1996]</a>.</p>
|
||
|
|
|
||
|
|
<p>With a few minor exceptions, the syntax from the draft of December 1995 has remained stable and the first section of the specification can still serve as an introduction to CSS:</p>
|
||
|
|
|
||
|
|
<blockquote>Designing simple style sheets is easy. One only needs to know a little HTML and some basic desktop publishing terminology. E.g., to set the text color of 'H1' elements to blue, one can say:
|
||
|
|
|
||
|
|
<pre> H1 { color: blue }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
The example consists of two main parts: selector ('H1') and declaration ('color: blue'). The declaration has two parts, property ('color') and value ('blue').</blockquote>
|
||
|
|
|
||
|
|
<p>The CSS1 specification became a W3C Recommendation <a href="#CSS1_1996">[CSS1 1996]</a> in December 1996. In May 1998 CSS2 became a W3C Recommendation <a href="#CSS2_1998">[CSS2 1998]</a>. <a href="#ch-css">Chapter 6 (Cascading Style Sheets)</a> describes the development of the Recommendations in more detail.</p>
|
||
|
|
|
||
|
|
<p>A decade after the first CSS proposal was published, all major web browsers support CSS and a majority of web pages use CSS. It may still be too early to fully evaluate CSS and its impact on the web, but it possible to study the design of CSS and compare it with other style sheet languages and style sheet language proposals.</p>
|
||
|
|
|
||
|
|
<h2 id="h-35">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>This chapter introduces some of the key concepts of this thesis. HTML was developed as a simple structured document format for the web. As web authors requested more presentational influence over their documents, HTML started developing into a presentational rather than a structural language. To stop this downwards slide on the ladder of abstraction, CSS was developed as a style sheet language for the web. Style sheets have been part of electronic publishing systems since around 1980. On the web, the focus of style sheets is shifted from being a tool in the authoring process to being a tool for content reuse after the content has been generated.</p>
|
||
|
|
|
||
|
|
<p>The thesis explores in more detail <em>why</em> the web requires style sheet languages different from those in other kinds of publishing, and <em>how</em> such a language can be designed. Before doing so, however, it is necessary to discuss two other topics. First, structured documents must be understood since style sheets are applied to structured documents. Second, style sheet languages developed before the advent of the web must be researched to determine if any of these languages are suitable for use on the web. This is done in Chapter 2 and Chapter 3, respectively.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-structure" title="Structured documents">
|
||
|
|
<h1 class="chapter" id="h-36">Structured documents</h1>
|
||
|
|
|
||
|
|
<p>Style sheet languages and structured document formats are mutually dependent on each other. Without style sheets, structured documents cannot be presented, and without structured documents there is nothing for style sheets to present. Due to the strong relationship between the two, it is important to understand structured documents when studying style sheet languages. Some <a class="term" href="#structured_document_system">structured document systems</a> that have been most influential on style sheet languages are discussed in this chapter.</p>
|
||
|
|
|
||
|
|
<p>In a seminal work titled <em class="title">Structured Documents</em> <a href="#Andre_1989">[André, et al. 1989]</a>, the topic is defined as:</p>
|
||
|
|
|
||
|
|
<blockquote>A document may be described as a collection of objects with higher-level objects formed from more primitive objects. The object relationships represent the logical relationships between components of the document. For example, the present document is described as a book at the highest level. The book is subdivided into chapters, each chapter into sections, subsections, paragraphs, and so forth. Such a document organization has come to be known as the <em>structured document</em> representation.</blockquote>
|
||
|
|
|
||
|
|
<p>One important feature of the structured document representation is that it has a certain level of abstraction. The level of abstraction is especially important when the structured document is combined with a style sheet to form a presentation. Therefore, the first part of this chapter discusses abstraction levels in structured documents and proposes a <a href="#ladder_of_abstraction" class="term">ladder of abstraction</a> to measure the level of abstraction in web document formats.</p>
|
||
|
|
|
||
|
|
<p>The second part of the chapter describes seminal structured document systems, namely Scribe; LaTex; Open Document Architecture (ODA); Standard Generalized Markup Language (SGML); HyperText Markup Language (HTML); and Extensible Markup Language (XML). Each of the systems is briefly described historically and technically with special emphasis on their relationships with style sheet languages.</p>
|
||
|
|
|
||
|
|
<p>A third part discusses the relationship between transformation languages and style sheet languages on the web.</p>
|
||
|
|
|
||
|
|
<h2 id="h-37">Abstraction levels</h2>
|
||
|
|
|
||
|
|
<p>In his book, <em class="title">Language in Action</em>, Hayakawa <a href="#Hayakawa_1940">[Hayakawa 1940]</a> introduces the notion of a linguistic ladder of abstraction. At the bottom of the abstraction ladder is an object. As an example, Hayakawa uses a cow named <em>Bessie</em>. The cow is composed of muscle, bones, skin and other biological parts. As the first step up the ladder, we disregard the biology inside the cow but retain its physical properties – for example its color, size and shape – and we call it Bessie. Bessie is just one of many objects that can be classified as <em>cows</em>. On the farm where Bessie lives, there are many other kinds of animals that can all be referred to as <em>livestock</em>. The climb up the ladder of abstraction can continue to <em>farm assets</em> and <em>wealth</em>. This concept is illustrated in Figure 1.</p>
|
||
|
|
|
||
|
|
<div id="f-1" class="figure">
|
||
|
|
<!--<p><img class="figure" src="i/abstraction-ladder.jpg" alt="The ladder of abstraction." /></p>-->
|
||
|
|
<p><img class="figure" src="i/ladder-600dpi.png" alt="The ladder of abstraction." /></p>
|
||
|
|
|
||
|
|
<p class="caption">The ladder of abstraction. Illustration reprinted from Hayakawa <a href="#Hayakawa_1940">[Hayakawa 1940]</a>.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<p>A similar example of abstraction levels can be found in the field of computer networking. In 1983, the International Standards Organization (ISO) developed a network model called Open Systems Interconnection (OSI) Reference Model which defined a framework of computer communications. The ISO/OSI Reference Model has seven layers, each of which has a different level of abstraction. The seven layers are: physical, data link, network, transport, session, presentation and application.</p>
|
||
|
|
|
||
|
|
<p>I believe the notion of an abstraction ladder is useful when evaluating document formats. How high a certain document format is on the ladder will determine the complexity of formatting the document into a presentation. Since the formatting of a document is specified by a style sheet, the abstraction level is a crucial feature for the success of style sheets.</p>
|
||
|
|
|
||
|
|
<p>The vertical nature of a ladder corresponds to how one describes abstraction levels as <em>high</em> or <em>low</em>. Typical characteristics of document formats that are high on the ladder of abstraction are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The information needs processing in order to be presented. For example, in order to render an HTML document visually, the words must be broken into lines, fonts must be selected, and the <a class="term" href="#character">characters</a> must be turned into rasterized <a class="term" href="#glyph">glyphs</a>.</li>
|
||
|
|
|
||
|
|
<li>The information can be processed and presented in many different ways. Presenting a document visually is only one of several possibilities; others include aural renderings and braille embedding.</li>
|
||
|
|
|
||
|
|
<li>The information is represented in a compact manner. Representing a character with an eight-bit code is more compact than representing an image of the same character.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Conversely, documents written in formats that are low on the ladder of abstraction need less processing in order to be presented, they have less flexibility of presentation, and they are less compact.</p>
|
||
|
|
|
||
|
|
<p>Another important observation is that it is generally possible to transform documents downwards on the ladder but much more difficult to move the other way <a href="#Lie_1999">[Lie&Saarela 1999]</a>. For example, graphical web browsers – in collaboration with the windowing system – rasterize HTML documents into pixels and thereby move information downwards on the ladder of abstraction. Optical Character Recognition (OCR) software attempts to climb the ladder by turning images into text, but OCR systems only work under certain conditions and are prone to errors. Similarly, it is impossible to devise an algorithm that converts documents written in a Turing-complete language due to the halting problem <a href="#Connolly_1994a">[Connolly 1994a]</a>.</p>
|
||
|
|
|
||
|
|
<p>In the context of web document formats, I believe the following criteria can be used to establish the steps in the ladder of abstraction:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Is the text human-readable? That is, if the document is presented to a human reader, will he/she be able to read the document?</li>
|
||
|
|
|
||
|
|
<li>Is the text machine-readable? That is, does the format have a notion of numbered characters, or does it represent text as images – in which case the text is not available.</li>
|
||
|
|
|
||
|
|
<li>Is the logical order of text preserved? That is, do documents written in the format have a notion of the logical reading order of the content?</li>
|
||
|
|
|
||
|
|
|
||
|
|
<li>Is the document scalable? That is, can the document be zoomed in without introducing visible artefacts?</li>
|
||
|
|
|
||
|
|
<li>Is reflow possible? That is, can text be reflowed into lines, columns and pages of different dimensions?</li>
|
||
|
|
|
||
|
|
<li>Can the roles of the various text elements be represented? For example, can the author mark part of the text as a headline, a paragraph, or perhaps as the name of a variable in a computer program? Being able to distinguish between these roles is important. When making documents available in braille, for example, some text should be contracted (e.g. headlines), while other text should not (e.g. variable names) <a href="#Lorimer_1996">[Lorimer 1996]</a>.</li>
|
||
|
|
|
||
|
|
<li>Is the format device-independent? That is, can documents written in the format be rendered into many different devices (e.g. printers, screens, braille printers, and text synthesizers) or are documents intended for a single type of device?</li>
|
||
|
|
|
||
|
|
<li>Does the format contain application-specific semantics? HTML is a general document format that does not attempt to describe semantics from more specialized fields, e.g. mathematics and chemistry, and therefore does not contain application-specific semantics. Formats that contain application-specific semantics tend to be higher on the ladder of abstraction.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="table" id="t-1">
|
||
|
|
<p class="caption">A comparison of document formats on the ladder of abstraction.</p>
|
||
|
|
|
||
|
|
<table summary="" class="page">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th></th>
|
||
|
|
<th>GIF, PNG</th>
|
||
|
|
<th>private XML<br />
|
||
|
|
vocabulary</th>
|
||
|
|
<th>PDF</th>
|
||
|
|
<th>XSL-FO</th>
|
||
|
|
<th>HTML</th>
|
||
|
|
<th>MathML</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>application-<br />
|
||
|
|
specific semantics?</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>device-independent?</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>roles known?</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>text in logical order?</td>
|
||
|
|
<td class="no">unknown</td>
|
||
|
|
<td class="no">unknown</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>reflow possible?</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">unknown</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>scalable?</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">unknown</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>text machine-readable?</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>text human-readable?</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>Table 1 shows the relative positions of various document formats on the ladder of abstraction. Some notes to the table:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>GIF <a href="#GIF_1990">[GIF 1990]</a> and PNG <a href="#PNG_1996">[PNG 1996]</a> are bitmap image formats rather than document formats, but images are often used to represent documents. Fax transmission is a common example outside the web.</li>
|
||
|
|
|
||
|
|
<li>PDF <a href="#Adobe_1993">[Adobe 1993]</a> is a document format developed by Adobe Systems. PDF is a presentation-oriented format and has no concept of, for example, paragraphs and headings. Many users have discovered this when trying to copy content from PDF documents laid out in several columns. When selecting text, the selection will span across multiple columns and thereby mix text from several parts of the document into the same selection. Recent versions of PDF have introduced functionality to retain a document's logical structure in PDF <a href="#Adobe_2001">[Adobe 2001]</a>.</li>
|
||
|
|
|
||
|
|
<li>XSL-FO refers to a document consisting of formatting objects as defined in the XSL Recommendation <a href="#XSL_2001">[XSL 2001]</a>. XSL-FO is discussed later in this chapter.</li>
|
||
|
|
|
||
|
|
<li>XML <a href="#XML_1998">[XML 1998]</a>, in which several of the emerging formats are written, is also included in the table and refers to documents published using private XML vocabularies where the semantics are not universally known.</li>
|
||
|
|
|
||
|
|
<li>The rating of HTML is based on a best-case scenario where the author makes use of semantic elements and does not alter the reading order of elements by using features such as positioning or tables. It may be argued that most HTML documents do not follow these conventions.</li>
|
||
|
|
|
||
|
|
<li>MathML is a W3C Recommendation for mathematical notation <a href="#MathML_1998">[MathML 1998]</a>.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Having established the ladder of abstraction as a measuring tool for structured document formats, the next section discusses structured document systems in more detail.</p>
|
||
|
|
|
||
|
|
<h2 id="h-38">Structured document systems</h2>
|
||
|
|
|
||
|
|
<p>Beginning around 1980, there was an active research community in the field of electronic publishing and structured documents. The community published their results in the proceedings of the <em class="title">Electronic Publishing</em> conferences, in the journal <em class="title">Electronic Publishing – Origination, Dissemination and Design</em> <a href="#EP">[Electronic Publishing]</a>, and Cambridge University Press published a series of books on the topic. Richard Furuta lists many of the important works in <em class="title">Important papers in the history of document preparation systems: basic sources</em> <a href="#Furuta_1992">[Furuta 1992]</a>.</p>
|
||
|
|
|
||
|
|
<p>The researchers generally agreed on the benefits of vendor-neutral document formats to facilitate document exchange. The benefits of structured documents were also well understood. There were, however, several approaches to structured documents, and competing formats were developed. This section describes and discusses four of them.</p>
|
||
|
|
|
||
|
|
<p>One line of development started in the late 1970's when Brian Reid developed <em>Scribe</em> <a href="#Reid_1980">[Reid 1980]</a>. Scribe pioneered the notion of structured documents and enforced a distinction between <a href="#logical_markup" class="term">logical markup</a> and presentational templates in the authoring process. The Scribe philosophy was continued in Leslie Lamport's <em>LaTeX</em> which was first released in 1985 <a href="#Lamport_1986">[Lamport 1986]</a>. LaTeX is a macro package on top of Donald Knuth's <em>TeX</em> program which serves as the low-level formatter <a href="#Knuth_1984">[Knuth 1984]</a>.</p>
|
||
|
|
|
||
|
|
<p>Open Document Architecture (ODA) is a set of ISO standards to facilitate the electronic exchange of documents <a href="#ODA_1989">[ODA]</a>. ODA documents can represent both the logical and the presentational representation of a document.</p>
|
||
|
|
|
||
|
|
<p>Standard Generalized Markup Language (SGML) <a href="#SGML_1986">[SGML 1986]</a> and its predecessor GML were developed by Charles Goldfarb and colleagues during the 1970s and 1980s <a href="#Furuta_1982">[Furuta, et al. 1982]</a>. SGML became an ISO standard in 1986.</p>
|
||
|
|
|
||
|
|
<p>These six systems (Scribe, LaTeX, ODA, SGML, HTML and XML) are described in this section. Before discussing each one, it may be helpful to informally list the perceived ambitions and achievements of the six systems. see Table 2.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-2">
|
||
|
|
<p class="caption">The ambitions and achievements of the six different structured document systems.</p>
|
||
|
|
|
||
|
|
<table summary="" class="page">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th></th>
|
||
|
|
<th>Is primarily a system to define new languages?</th>
|
||
|
|
<th>Has notion of document semantics?</th>
|
||
|
|
<th>Has notion of document presentation?</th>
|
||
|
|
<th>Enco-<br />
|
||
|
|
ding</th>
|
||
|
|
<th>Reference</th>
|
||
|
|
<th>Level of comp­lexity</th>
|
||
|
|
<th>Main achieve­ment</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>Scribe</th>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td>text</td>
|
||
|
|
<td>implementation</td>
|
||
|
|
<td>moderate</td>
|
||
|
|
<td>inspired LaTeX</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>LaTex</th>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td>text</td>
|
||
|
|
<td>implementation</td>
|
||
|
|
<td>moderate</td>
|
||
|
|
<td>de facto format in scientific publishing</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>ODA</th>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td>binary</td>
|
||
|
|
<td>specification</td>
|
||
|
|
<td>high</td>
|
||
|
|
<td>became ISO standard</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>SGML</th>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td>text</td>
|
||
|
|
<td>specification</td>
|
||
|
|
<td>high</td>
|
||
|
|
<td style="white-space: nobreak">became ISO standard, inspired HTML and XML</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>HTML</th>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="yes">some</td>
|
||
|
|
<td>text</td>
|
||
|
|
<td>specification & implementation</td>
|
||
|
|
<td>moderate</td>
|
||
|
|
<td>universally understood hypertext format</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>XML</th>
|
||
|
|
<td class="yes">yes</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td class="no">no</td>
|
||
|
|
<td>text</td>
|
||
|
|
<td>specification</td>
|
||
|
|
<td>moderate</td>
|
||
|
|
<td>syntactic basis for emerging formats</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>For a more formal taxonomy of document formats, see <em>The Origin of (Document) Species</em> <a href="Khare_1998">[Khare&Rifkin 1998]</a>.</p>
|
||
|
|
|
||
|
|
<p>In addition to the achievements listed in Table 2, all systems should be credited for having inspired authors and programmers to see the benefits of structured documents.</p>
|
||
|
|
|
||
|
|
<p>The discussions of the various structured document systems below do not follow a strict pattern. The systems vary widely in how well they are understood, how much use they have seen, and how much information is currently available about each system. The primary goal of the descriptions is not to perform a comparative analysis, but rather to discuss aspects of these languages which this author finds interesting in the context of style sheets.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-39">Scribe</h3>
|
||
|
|
|
||
|
|
<p>The Scribe system was developed in the late 1970s by Brian Reid at Carnegie-Mellon University <a href="#Reid_1980">[Reid 1980]</a>. Scribe is noteworthy for pioneering the structured approach to authoring. It encourages authors to work with predefined logical objects, and authors typically produce documents in their <a href="#final_form" class="term">final form</a> without having to specify any of the formatting.</p>
|
||
|
|
|
||
|
|
<p>The Scribe system changed somewhat over the years. The discussion in this chapter is based on Scribe as described in <em class="title">Scribe Introductory User's Manual</em> from 1980 <a href="#Reid_1979">[Reid&Walker 1979]</a>. The description attempts to give a general overview of Scribe, and not all features are discussed.</p>
|
||
|
|
|
||
|
|
<h4 id="h-40">A simple document</h4>
|
||
|
|
|
||
|
|
<p>A Scribe document can be remarkably simple:</p>
|
||
|
|
|
||
|
|
<pre>@Make(Text)
|
||
|
|
@Device(Diablo)
|
||
|
|
@Heading(Comrades and Strangers)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above uses three key concepts of Scribe: <em>document types</em>, <em>commands</em>, and <em>formatting environments</em>. The first line chooses a particular document type (<code>Text</code>) from a set of different document types. The second line is a command which specifies that the document should be printed on a specific device. The third line specifies that a certain string (<q>Comrades and Strangers</q>) is the heading of the document.</p>
|
||
|
|
|
||
|
|
<h4 id="h-41">Document types</h4>
|
||
|
|
|
||
|
|
<p>An installation of Scribe comes with a <em>database</em> of document types. The Scribe documentation lists 11 different document types: <code>Text</code> (which is default), <code>Article</code>, <code>Report</code>, <code>Manual</code>, <code>Thesis</code>, <code>Brochure</code>, <code>Guide</code>, <code>Letter</code>, <code>Letterhead</code>, <code>ReferenceCard</code>, and <code>Slides</code>. A Scribe document typically starts by selecting which document type to use:</p>
|
||
|
|
|
||
|
|
<pre>@Make(Thesis)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The system administrator of the Scribe installation is expected to change the database to fit local needs. For example, the formatting requirements of a dissertation vary from one university to another, and the differences can be accounted for in the <code>Thesis</code> document type. In theory, authors can write their dissertations without thinking about the formatting requirements and can concentrate rather on the content.</p>
|
||
|
|
|
||
|
|
<p>Document types influence both the <a href="#content_model" class="term">content model</a> and the presentation of a document. For example, the <code>Thesis</code> document type allows and expects the <code>TitlePage</code> and various other environments to be used:</p>
|
||
|
|
|
||
|
|
<pre>@Make(Thesis)
|
||
|
|
@Device(Diablo)
|
||
|
|
@Begin(TitlePage)
|
||
|
|
@TitleBox(Comrades and Strangers)
|
||
|
|
@CopyrightNotice(Michael Harrold)
|
||
|
|
@End(TitlePage)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>It is possible for authors to change both the content model and the presentation of their own documents, but doing so is cumbersome. Scribe encourages a mode where a local administrator maintains control over – and responsibility for – the various document types that are used in the organization.
|
||
|
|
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-42">Scribe commands</h4>
|
||
|
|
|
||
|
|
<p>In addition to the content itself, a Scribe source file contains <em class="title">Scribe commands</em>. These correspond to what is known as <a href="#markup" class="term">markup</a> in SGML/HTML/XML terminology. There are approximately 35 commands. They can be divided into five main groups:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Classification commands: <code>@Begin</code> and <code>@End</code> are used to mark the start and end of environments, and <code>@Make</code> is used to declare a document type.</li>
|
||
|
|
|
||
|
|
<li>Variable commands: To handle counters (<code>@Set</code>, <code>@Tag</code>), cross-references (<code>@Ref</code>), and string variables (<code>@String</code>, <code>@Value</code>) that are expanded into, for example, date and username.</li>
|
||
|
|
|
||
|
|
<li>Visual commands: To mark page breaks (<code>@NewPage</code>), add vertical spacing (<code>@BlankSpace</code>), handle tab stops (<code>@Tabset</code>, <code>@TabDivide</code>, <code>@TabClear</code>) or change style (<code>@Style</code>) or font (<code>@SpecialFont</code>).</li>
|
||
|
|
|
||
|
|
<li>Out-of-flow content commands: To label certain out-of-flow content, for example footnotes (<code>@Foot</code>), running headers (<code>@PageHeading</code>) and footers (<code>@PageFooting</code>).</li>
|
||
|
|
|
||
|
|
<li>System commands: To import other files (<code>@Import</code>), specify the output device (<code>@Device</code>), and output a message on the console (<code>@Message</code>).</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The classification of commands into groups is done by this author.</p>
|
||
|
|
|
||
|
|
<p>The Scribe documentation describes commands as <em class="excerpt">non-procedural</em>. However, some of the commands are arguably procedural, most notably <code>@BlankSpace</code> and <code>@NewPage</code>. In a structured approach, page breaks are attached to structured elements (e.g. a heading) rather than using a separate command.<span class="fn">Scribe also supports the structured approach through the <code>Pagebreak</code> environment Attribute.</span></p>
|
||
|
|
|
||
|
|
<p>Likewise, the <code>@Style</code> and <code>@SpecialFont</code> commands, which are used to set stylistic and font preferences, can be questioned since they are not attached to structured elements.</p>
|
||
|
|
|
||
|
|
<p>Another command that is easily challenged is <code>@Device</code>, which is used to specify the <q>printing device for the output</q>. Web authors will not know what printing device (if any) the user has. Scribe, however, was used mostly with paper as the final form, and including commands like <code>@Device</code> is a pragmatic choice.</p>
|
||
|
|
|
||
|
|
<h4 id="h-43">Formatting environments</h4>
|
||
|
|
|
||
|
|
<p>The most frequently used commands in Scribe are <code>@Begin</code> and <code>@End</code> which, respectively, mark the beginning and end of formatting environments. A <em>formatting environment</em> corresponds roughly to an <a href="#element" class="term">element</a> in SGML/HTML/XML terminology, and the <code>@Begin</code> and <code>@End</code> commands correspond to tags. Formatting environments are also referred to as <em>named formatting environments</em> or just <em>environments</em>. Here is a simple fragment from the Scribe documentation<span class="fn">The quote is from Oscar Wilde: <em class="title">The Soul of man under Socialism</em>, 1895</span>:
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<pre>@Begin(Quotation)
|
||
|
|
On mechanical slavery, on the slavery of the machine,
|
||
|
|
the future of the world depends.
|
||
|
|
@End(Quotation)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Text inside the <code>Quotation</code> environment is given extra space on all sides. Text can also be placed in environments through a shorthand syntax:</p>
|
||
|
|
|
||
|
|
<pre>@Quotation(On mechanical slavery, on the slavery of the machine,
|
||
|
|
the future of the world depends.)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Environments can be nested inside each other:</p>
|
||
|
|
|
||
|
|
<pre>@Quotation(On mechanical slavery, on the slavery of the @i[machine],
|
||
|
|
the future of the world depends.)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above also shows how different pairs of characters can be used in delimiters. The outer delimiters use <code>()</code> characters, while the inner delimiters use <code>[]</code>.</p>
|
||
|
|
|
||
|
|
<p>All Scribe systems offer a common set of environments for authors to use. See Table 3.</p>
|
||
|
|
|
||
|
|
<!--xxx-->
|
||
|
|
|
||
|
|
<p>Keeping in mind how important Scribe has been in the promotion of logical markup, it is noteworthy that around half of the environments have presentational rather than logical roles.</p>
|
||
|
|
|
||
|
|
<p>Not all structure in a Scribe document must be marked up explicitly. Scribe is able to identify paragraphs from the white space in the source document. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>@begin(enumerate)
|
||
|
|
The first item of three.
|
||
|
|
|
||
|
|
The second item.
|
||
|
|
|
||
|
|
The last item.
|
||
|
|
@end(enumerate)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The resulting enumerated list consists of three items. The <code>Multiple</code> environment can be used to override the automatic structure detection:</p>
|
||
|
|
|
||
|
|
<pre>@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)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>One benefit of automatic structure detection is that markup in source documents can be minimized.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-3">
|
||
|
|
<p class="caption">Common environments offered in Scribe.</p>
|
||
|
|
|
||
|
|
<table summary="" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Environment</th>
|
||
|
|
<th>Corresponding HTML element</th>
|
||
|
|
<th>Corresponding CSS functionality</th>
|
||
|
|
<th>Comment</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>B</td>
|
||
|
|
<td><code class="element">B</code></td>
|
||
|
|
<td>font-style: bold</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>C</td>
|
||
|
|
<td></td>
|
||
|
|
<td>font-style: small-caps</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Center</td>
|
||
|
|
<td><code class="element">CENTER</code></td>
|
||
|
|
<td>text-align: center</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Description</td>
|
||
|
|
<td><code class="element">DL</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td>this environment seems to provide formatting similar to HTML's <code class="element">DL</code> element</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Display</td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
<td>this environment honors line breaks and adds extra left margin</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Enumerate</td>
|
||
|
|
<td><code class="element">UL</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Example</td>
|
||
|
|
<td><code class="element">PRE</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td>adds extra margins</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>FileExample</td>
|
||
|
|
<td><code class="element">PRE</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>FlushLeft</td>
|
||
|
|
<td></td>
|
||
|
|
<td>text-align: left</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>FlushRight</td>
|
||
|
|
<td></td>
|
||
|
|
<td>text-align: right</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Format</td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
<td>use for tabular formatting</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>G</td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
<td>uses a Greek font</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Group</td>
|
||
|
|
<td></td>
|
||
|
|
<td>page-break: avoid</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Heading</td>
|
||
|
|
<td><code class="element">H2</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>I</td>
|
||
|
|
<td><code class="element">I</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Itemize</td>
|
||
|
|
<td><code class="element">UL</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>MajorHeading</td>
|
||
|
|
<td><code class="element">H1</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Multiple</td>
|
||
|
|
<td><code class="element">DIV</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td>see example below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>O</td>
|
||
|
|
<td></td>
|
||
|
|
<td>text-decoration: overline</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>P</td>
|
||
|
|
<td><code class="element">B</code><code class="element">I</code></td>
|
||
|
|
<td>font-weight: bold; font-style: italic</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>ProgramExample</td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
<td>for examples of computer programs and uses fonts accordingly</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Quotation</td>
|
||
|
|
<td><code class="element">BLOCKQUOTE</code></td>
|
||
|
|
<td>margin: 1em</td>
|
||
|
|
<td>adds margins on all sides</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>R</td>
|
||
|
|
<td></td>
|
||
|
|
<td>font-family: serif</td>
|
||
|
|
<td>ordinary roman typeface</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Subheading</td>
|
||
|
|
<td><code class="element">H3</code></td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>T</td>
|
||
|
|
<td><code class="element">tt</code></td>
|
||
|
|
<td>font-family: monospace</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Text</td>
|
||
|
|
<td></td>
|
||
|
|
<td>The default environment</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>U</td>
|
||
|
|
<td><code class="element">U</code></td>
|
||
|
|
<td>text-decoration: underline</td>
|
||
|
|
<td>underlines all nonblank characters</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>UN</td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
<td>underline letters and digits only</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>UX</td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
<td>underline all characters, including spaces</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Verbatim</td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
<td>used for tabular formatting with monospace fonts</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Verse</td>
|
||
|
|
<td></td>
|
||
|
|
<td></td>
|
||
|
|
<td>intended for poetry and other text where white space should be honored</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>W</td>
|
||
|
|
<td></td>
|
||
|
|
<td>white-space: nowrap</td>
|
||
|
|
<td>treats text as one word, i.e., an unbreakable sequence of characters</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h4 id="h-44">Changing and adding environments</h4>
|
||
|
|
|
||
|
|
<p>As mentioned above, the Scribe database of document types and formatting environments is maintained by a system administrator. However, an author can also change or add environments to fit his needs. Here is a simple example:</p>
|
||
|
|
|
||
|
|
<pre>@Modify(Description, Leftmargin 0.5in, Indent -0.5in)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, the left margin and indentation of the <code>Description</code> environment are changed. The <code>@Modify</code> command must appear in the beginning of the document. New environments can also be defined:</p>
|
||
|
|
|
||
|
|
<pre>@Define(InsetHead=Subheading, Leftmargin 0.5in)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, the <code>InsetHead</code> environment is created. It copies all properties from <code>Subheading</code> except for the left margin. Environments can also be created from scratch. The documentation discourages this but specifies the general form:</p>
|
||
|
|
|
||
|
|
<pre>@Define(Newname, <list of attribute-value paris>)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Also, the documentation lists the set of around 40 properties that define the presentation of environments.</p>
|
||
|
|
|
||
|
|
<p>In effect, the definition of environments in Scribe encompasses both style sheets and SGML's Document Type Definition (DTD) in one.</p>
|
||
|
|
|
||
|
|
<h4 id="h-45">Scribe in context</h4>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>Scribe pioneered the distinction between structure and style and allowed authors to write documents without thinking about the formatting of the documents. The database of document types and formatting environments is maintained by a system administrator, but authors who want to modify environments or add their own are free to do so. As such, Scribe offers the best of HTML (there is a default set of tags and conventions on how to present them), CSS (there is a default set of presentational conventions that can be modified), and XML (new elements can be created). As such, Scribe may have been a better inspiration for HTML than SGML. It is also noteworthy that Scribe provided this functionality more than 15 years before it became available to authors on the web.</p>
|
||
|
|
|
||
|
|
<p>Scribe is no longer available for authors to use, but the historical impact of Scribe on the development of structured documents is significant. There are no references to Scribe in W3C's overview of historical systems influencing the the development of HTML <a href="#W3C_2003">[W3C 2003]</a>, but the developers of SGML do reference Scribe <a href="#Goldfarb_1991">[Goldfarb 1991]</a> which makes it an indirect influence. Scribe's greatest achievement may have been its influence on LaTeX. Leslie Lamport, who created LaTeX, mentions Scribe in the first edition <span class="fn">Lamport removed the reference to Scribe in the second edition of his book for legal reasons. He writes <q>I removed all mention of Scribe in the 2nd edition of the LaTeX book because I was informed that the person who bought Scribe from Brian Reid would have loved to find someone he could sue for infringing Scribe's patents or copyright or whatever. I disliked not crediting Brian, but I didn't want to tempt the legal fates.</q> <a href="#Lamport_1986">[Lamport 1986]</a>.</span> of his book <a href="#Lamport_2003">[Lamport 2003]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Fundamental to LaTeX is the idea of a document style that determines how the document is to be formatted – an idea stolen from Brian Reid's Scribe text formatting system.</blockquote>
|
||
|
|
|
||
|
|
<p style="page-break-before: avoid">LaTeX is discussed in the next section.</p>
|
||
|
|
|
||
|
|
<h3 id="h-46">LaTeX</h3>
|
||
|
|
|
||
|
|
<p>The TeX typesetting system was developed by Donald Knuth <q>for the creation of beautiful books</q> <a href="#Knuth_1984">[Knuth 1984]</a>. The work was started in the late 1970s and TeX became the preferred format for scientific publishing in the 1980s. Designed by a mathematician, TeX has special features for formatting mathematics but its formatting model is suitable for many types of documents. TeX has been used primarily in environments where paper is the final target. Commands in TeX typically describe spatial relationships between elements and thus are presentational. Here is a simple TeX fragment:</p>
|
||
|
|
|
||
|
|
<pre>{\narrower\smallskip\noindent
|
||
|
|
This paragraph will have narrower lines than surrounding paragraphs.
|
||
|
|
\smallskip}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Many of the commands in TeX are macros that are expanded into basic commands by the TeX interpreter. TeX allows users to create their own macros, and several macro packages for TeX have been published. LaTeX is one such macro package which enables authors to create structured document formats.</p>
|
||
|
|
|
||
|
|
<p>LaTeX's author, Leslie Lamport, was a Scribe user who wanted to <q>make LaTeX a sort for Scribe on top of TeX</q> [Lamport 2003]. Many of features in LaTeX were copied from Scribe but, as LaTeX developed, some Scribe features were dropped and some new functionality was added. Here is a simple LaTeX fragment:</p>
|
||
|
|
|
||
|
|
<pre>\documentclass{book}
|
||
|
|
\title{Comrades and Strangers}
|
||
|
|
\author{Michael Harrold}
|
||
|
|
\begin{document}
|
||
|
|
\maketitle
|
||
|
|
\chapter{Red Carpet in Paradise}
|
||
|
|
\end{document}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first line in the above example declares that the document will eventually become a book. Other document classes include: report, letter, article and slides. The choice of document class will influence the final presentation of the document, as well as the type of elements (or <em class="excerpt">environments</em> as LaTeX and Scribe calls them) that are available. For example, the <code>chapter</code> element, used further down, is available in a book but not in an article. The next two lines declare the title and author of the publication. The first part of the code – until the document itself starts – is called the <em>preamble</em> and is similar to the <code class="element">HEAD</code> element in HTML.</p>
|
||
|
|
|
||
|
|
<p>The document body is contained in the <code class="element">document</code> environment. The <code>\maketitle</code> command is a common way to start documents; depending on the class of document and the meta-information declared in the preamble, a proper title will be generated. The last element in the above example is a chapter heading.</p>
|
||
|
|
|
||
|
|
<p>There are many similarities between Scribe and Latex:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Like Scribe, LaTeX's functionality can be grouped into three: <em>document classes</em> (called <em>document types</em> in Scribe), <em>commands</em> and <em>environments</em> (also called <em>formatting environments</em> in Scribe).</li>
|
||
|
|
|
||
|
|
<li>Many of the environment names are the same, for example: <code>enumerate</code>, <code>itemize</code>, <code>quotation</code>, <code>description</code>, <code>verbatim</code>, <code>center</code>, <code>flushleft</code> and <code>flushright</code>.</li>
|
||
|
|
|
||
|
|
<li>Both languages are tied to a specific formatter and have not been proposed as candidates for standardization.</li>
|
||
|
|
|
||
|
|
<li>Both Scribe and LaTeX provide a base set of document classes and environments that can be extended by local system administrators or authors.</li>
|
||
|
|
|
||
|
|
<li>The ambitions of the two systems are roughly the same: It should be possible to author structured documents without having to describe the presentation of documents, while still having the documents printed neatly onto paper in the end.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>There are also notable differences between the two systems:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The syntax is different; LaTeX uses different delimiters than does Scribe.</li>
|
||
|
|
|
||
|
|
<li>LaTex offers access to TeX commands. This makes it possible to control the formatting of document at a very low level, but it also makes it difficult – if not impossible – to convert LaTex documents into other formats.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>LaTeX has been a highly successful authoring system that has seen much use, primarily in academic environments. Due to its success, LaTeX has probably done more for structured documents than any other language, bar HTML.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<div>
|
||
|
|
<h3 id="h-47">Open Document Architecture (ODA)</h3>
|
||
|
|
|
||
|
|
<p>Open Document Architecture is a set of ISO standards that describe formats for representing and exchanging structured documents. The efforts started out under the name <q>Office Document Architecture</q> in the 1980s, and the name changed to <q>Open Document Architecture</q> in the 1990s when results of the efforts were published as ISO standards <a href="#ODA">[ODA]</a><a href="#Appelt_1991">[Appelt 1991]</a><a href="#Rosenberg_1991">[Rosenberg et al. 1991]</a>.</p>
|
||
|
|
|
||
|
|
<p>Like ISO's OSI <a href="#OSI">[OSI]</a> model, ODA has been highly influential without having seen much use itself. ODA, along with the other systems described in this chapter, championed the idea of separating the logical representation of content from its physical presentation. However, ODA went several steps further than the other systems. Unlike SGML and XML, ODA also describes the presentation of documents. Compared with LaTex, Scribe and HTML, ODA goes further by, for example, also standardizing image formats.</p>
|
||
|
|
|
||
|
|
<p>ODA was developed by an industrial consortium where, among others, IBM, DEC, Unisys, Bull and Unisys were members. Also, many researchers in academic institutions took part in the development of ODA. Around 1991 the community was highly optimistic about the future of ODA <a href="#Sherman_1991">[Sherman 1991]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>ODA is one of the application-layer standards in the OSI model that is starting to grow and flourish. ODA is being adopted in a variety of other standards to meet an enlarging set of needs.</blockquote>
|
||
|
|
|
||
|
|
<p>However, ODA never became the success that its proponents hoped for, and was never used beyond pilot projects. There are several reasons for this. First, ODA is a complex set of specifications. It is difficult to understand the specifications and it is difficult to write software to support them. Second, ODA and SGML were perceived to be in competition with each other and the structured documents community never fully backed ODA. The difference in scope between ODA and SGML is significant: ODA is a document format that describes the syntax, structure and presentation of documents, while SGML is a system for defining the syntax of markup languages. Still the two were perceived to be in conflict with each other <a href="Watson_1991">[Watson&Davis 1991]</a>. Below is a retrospective remark made by the chair of the committee (ISO JTC1 SC) which defined the SGML standard <a href="#Mason_2001">[Mason 2001]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>The SGML/ODA Wars occupied entirely too much of our time and promoted an atmosphere of paranoia on the parts of several of our members. In the long run, ODA died and SGML won, but by then the forces that led to XML were already pushing people out of SC34. The technical effect on SGML was mixed: it brought us both CONCUR and Architectural Forms. The human effect was much more harmful.</blockquote>
|
||
|
|
|
||
|
|
<p>The fact that ODA has never been used makes it difficult to review. Few ODA documents have been created because the software to do so was never written. Unlike the other systems described in this chapter, ODA uses a binary encoding and examples are therefore hard include in textual descriptions of the standards. Also, ODA is hard to review since the specifications are not freely available.</p>
|
||
|
|
|
||
|
|
<p>Instead of attempting a scholarly review of ODA, I note its role in history and challenge researchers after me to do the review I believe ODA deserves.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-48">Standard Generalized Markup Language (SGML)</h3>
|
||
|
|
|
||
|
|
|
||
|
|
<p>As mentioned in the previous section, the <em class="title">Standard Generalized Markup Language</em> (SGML) is not a document format. Instead, SGML is a system which is used to create new document formats. In other words, SGML is not – despite its name – a markup language in itself, but is used to define other markup languages.</p>
|
||
|
|
|
||
|
|
<p>The first working draft of SGML was published in 1980 <a href="#SGMLUG_1990">[SGMLUG 1990]</a> and SGML became an ISO standard in 1986 <a href="#SGML_1986">[SGML 1986]</a>.</p>
|
||
|
|
|
||
|
|
<p>SGML is based on GML (Generalized Markup Language) which was developed at IBM over a period of years in the early to mid 1970s <a href="#Furuta_1982">[Furuta, et al. 1982]</a>. In <a href="#SGMLUG_1990">[SGMLUG 1990]</a> the people and motivation behind GML is described:</p>
|
||
|
|
|
||
|
|
<blockquote>Together with Edward Mosher and Raymond Lorie [Charles Goldfarb] invented the Generalized Markup Language (GML) as a means of allowing the text editing, formatting, and information retrieval systems to share documents</blockquote>
|
||
|
|
|
||
|
|
<p>GML became available for general use in 1978 <a href="#Furuta_1982">[Furuta, et al. 1982]</a>. A GML document looks quite different from an SGML document due to the former not using the now familiar angle brackets to denote tags. Here is a simple fragment from <a href="#Furuta_1982">[Furuta, et al. 1982]</a>:</p>
|
||
|
|
|
||
|
|
<pre>:body.
|
||
|
|
:h2.The Formatting Problem
|
||
|
|
:p.In order to discuss formatters and their functions...
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>One of the GML creators, Charles Goldfarb, continued the work towards SGML <a href="#SGMLUG_1990">[SGMLUG 1990]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>After the completion of GML, Goldfarb continued his research on document structures, creating additional concepts, such as short references, link processes, and concurrent document types, that were not part of GML but were later to be developed as part of SGML.</blockquote>
|
||
|
|
|
||
|
|
<p>It is noteworthy that none of the SGML features mentioned in the above quote has seen much use. One of them, the <em>LINK</em> feature (described below), was motivated by the need to compete with ODA by offering a way to attach presentational information to documents.</p>
|
||
|
|
|
||
|
|
<p>SGML is a complex standard and it is beyond the scope of this thesis to give an overview of all features. Below is a description of three features that are interesting in the context of style sheets; all three features can potentially carry stylistic information.
|
||
|
|
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-49">Document Type Definition (DTD)</h4>
|
||
|
|
|
||
|
|
<p>A Document Type Definition (DTD) is a set of rules defining the syntax of a markup language. DTDs are central to SGML and all SGML-based markup languages have a DTD which describes elements, attributes, and entities – and the relationship between them. Here is a simple fragment from the HTML4 DTD:</p>
|
||
|
|
|
||
|
|
<pre><!ELEMENT UL - - (LI)+>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, the <code class="element">UL</code> element is declared to require start and end tag (the two dashes, respectively), and the content model is set to <code>(LI)+</code>. The content model describes what kind of content is allowed within the declared element. In the above example, the plus sign indicates that <code class="element">UL</code> elements can contain one or more <code class="element">LI</code> elements. The fragment below adds more information about the <code class="element">LI</code> element:</p>
|
||
|
|
|
||
|
|
<pre><!ENTITY % inline "A | #PCDATA">
|
||
|
|
<!ELEMENT LI - O (%inline)*>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first line of the above example declares an <em>entity</em> referred to in the second line: the <code class="element">LI</code> element must have a start tag, but the end tag is optional. The <code class="element">LI</code> element contains inline content, which – according to the first line – is <code class="element">A</code> elements or <code>#PCDATA</code>. <code>#PCDATA</code> means textual content.<span class="fn">In HTML4, the content model for the <code class="element">LI</code> is slightly more complex.</span></p>
|
||
|
|
|
||
|
|
<p>The DTD is also used to declare attributes on elements.</p>
|
||
|
|
|
||
|
|
<p>The HTML4 DTD uses entity names like <code>heading</code>, <code>inline</code> and <code>block</code> to group various elements. These names, however, do not signify any meaning; from SGML's perspective they are random strings. In the minds of the DTD creators, however, the names have a meaning that conveys logical roles as well as presentational information.</p>
|
||
|
|
|
||
|
|
<p>Although DTDs, by design, only convey information at a syntactical level, one could easily envision adding presentational information there. For example, this extended syntax would describe the content model, along with information about preferred fonts:</p>
|
||
|
|
|
||
|
|
<pre><!ELEMENT UL - - (LI)+ 11pt sans-serif>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The Scribe system, as discussed above, takes this approach when defining new environments. Also, the <a href="#ssp">SSP</a> style sheet proposal, discussed in Chapter 4, combines presentational and syntactical information in one.</p>
|
||
|
|
|
||
|
|
<h4 id="h-50">Processing Instructions</h4>
|
||
|
|
|
||
|
|
<p>A <a class="term" href="#processing_instruction">Processing Instruction</a> (PI) is a syntactic construct in SGML that can be used to hold information about how the document should be processed, including how it should be formatted. In a message to www-talk <a href="#Connolly_1994b">[Connolly 1994b]</a>, Dan Connolly proposed to use PIs to describe the formatting of HTML documents:</p>
|
||
|
|
|
||
|
|
<blockquote>I suggest we introduce a whole set of processing instructions so that folks can mark up the formatting of their document without affecting the structure. For example, rather than the <BR> element, I'd suggest a <? linebreak> processing instruction, and a &br; entity as a shorthand form.</blockquote>
|
||
|
|
|
||
|
|
<p>SGML puts few restrictions on the content of processing instructions, and a wide range of processing instructions are possible:</p>
|
||
|
|
|
||
|
|
<pre><? the next element should be green >
|
||
|
|
<? background=white >
|
||
|
|
<? p { color: black } >
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>A W3C Recommendation describes how PIs can be used to link to style sheets from XML documents. See the section on XML below.</p>
|
||
|
|
|
||
|
|
<h4 id="h-51">LINK</h4>
|
||
|
|
|
||
|
|
<p>The SGML specification defines two types of LINK features: implicit LINKs and explicit LINKs. The latter are poorly understood and the discussion in this section pertains only to implicit LINKs.</p>
|
||
|
|
|
||
|
|
<p>Like <em>processing instructions</em>, the LINK feature was added to aid the processing of SGML documents. Like PIs too, one of the uses for the LINK feature is to add formatting information to SGML documents. There are, however, several differences between PIs and LINKs:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>LINKs are placed in separate external <em>link declarations</em>, rather than being embedded into the document.</li>
|
||
|
|
|
||
|
|
<li>LINKs define the processing of a certain element, rather than just being a placeholder for any processing information.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The main purpose of the LINK mechanism is to attach attributes to elements. Here is a simple excerpt from a link declaration:</p>
|
||
|
|
|
||
|
|
<pre><!LINK #INITIAL table [ ALIGN="right" ]>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The link declaration above would add the <code class="attribute">ALIGN="right"</code> attribute to all <code class="element">table</code> elements.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>A slightly more advanced example shows how LINKs can be used to add attributes in a contextual manner:</p>
|
||
|
|
|
||
|
|
<pre><!LINK #INITIAL ul #USELINK uldef
|
||
|
|
ol #USELINK oldef>
|
||
|
|
<!LINK uldef li [ mark="bullet" ]>
|
||
|
|
<!LINK oldef li [ mark="digit" ]>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Consider this simple document:</p>
|
||
|
|
|
||
|
|
<pre><UL>
|
||
|
|
<LI>number unknown
|
||
|
|
<OL>
|
||
|
|
<LI>number one
|
||
|
|
<LI>number two
|
||
|
|
</OL>
|
||
|
|
</UL>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>When the link declaration above is applied to the above document, it produces the following document:</p>
|
||
|
|
|
||
|
|
<pre><UL>
|
||
|
|
<LI mark="bullet">number unknown
|
||
|
|
<OL>
|
||
|
|
<LI mark="digit">number one
|
||
|
|
<LI mark="digit">number two
|
||
|
|
</OL>
|
||
|
|
</UL>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>As can be seen from the example above, the LINK feature has some of the properties of a style sheet language (namely syntax and selectors, as described in Chapter 3). Also, the LINK feature is a generic mechanism that can be used to distribute any kind of information as long as the information can be represented in attributes. However, the LINK feature lacks a notion of formatting. For example, no properties, values or formatting model are proposed. Therefore, the LINK feature cannot be considered a style sheet language.</p>
|
||
|
|
|
||
|
|
<h4 id="h-52">SGML in context</h4>
|
||
|
|
|
||
|
|
<p>SGML is one of the standards that has most influenced the web, and both XML and HTML owe much of their design to SGML. SGML successfully brought important issues regarding document authoring, storage and exchange formats to the attention of the information technology communities. Especially, SGML emphasized:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><a href="#logical_markup" class="term">logical markup</a>, rather than <a href="#procedural_markup" class="term">procedural markup</a>; and</li>
|
||
|
|
|
||
|
|
<li>that information storage and exchange formats must be separated from software and hardware to ensure that data will survive computer systems.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Outside of a limited community, however, SGML never became the success that its proponents hoped for. This author believes there are several reasons for this:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The SGML standard became too complex. The <em class="title">SGML handbook</em>, which is an annotated version of the SGML standard, has 664 numbered pages <a href="#Goldfarb_1990">[Goldfarb 1991]</a>. Though this includes tutorials and other non-essential texts, it is yet an indication of how the complexity of SGML. Only a handful of experts are able to read and understand the full SGML specification. In addition to not being understood, many of the advanced features were not supported by implementations.</li>
|
||
|
|
|
||
|
|
<li>SGML only partially solved the problems for which its users needed solutions. It can successfully define markup languages, but few people actually do this. Rather, authors need a vocabulary of elements and ways to including graphics. SGML did not attempt to solve these problems.</li>
|
||
|
|
|
||
|
|
<li>Lack of style sheet language. When SGML became an ISO standard in 1986, no standardized style sheet language was available to format SGML documents. The <em class="title">Formatting Output Specification Instance</em> (FOSI; see the next chapter) soon became available but was considered a temporary solution while waiting for <em class="title">Document Style Semantics and Specification Language</em> (DSSSL). It took approximately 10 years before DSSSL was finalized in 1996. A simple solution based on an expanded DTD or PI syntax, as discussed above, may also have made SGML documents more presentation-friendly.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>It may be too early to pass judgement on SGML, but this author believes SGML's main achievement will be that it inspired HTML and XML.</p>
|
||
|
|
|
||
|
|
<h3 id="h-53">HyperText Markup Language (HTML)</h3>
|
||
|
|
|
||
|
|
|
||
|
|
<p>The HTML specification is, along with HTTP and <a href="#URL">URL</a> specifications, one of the basic building blocks of the web. HTML has had a far-reaching impact on how electronic content is authored, stored, transmitted and processed. The design of HTML is probably one of the main reasons for the success of the web.</p>
|
||
|
|
|
||
|
|
<p>This section discusses HTML's design and development with regard to style sheets.</p>
|
||
|
|
|
||
|
|
<h4 id="h-54">HTML's original design</h4>
|
||
|
|
|
||
|
|
<p>The origin of HTML is described in W3C's document <em class="title">Some early ideas for HTML</em> <a href="#W3C_2003">[W3C 2003]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>[In 1989] many people were using TeX and PostScript for their documents. A few were using SGML. Tim realized that something simpler was needed that would cope with dumb terminals through high end graphical X Window workstations. HTML was conceived as a very simple solution, and matched with a very simple network protocol HTTP.</blockquote>
|
||
|
|
|
||
|
|
<p>Indeed, the original design of HTML was simple. The first publically available description of HTML was a document called <em class="title">HTML Tags</em> <a href="#Berners-Lee_1991a">[Berners-Lee 1991a]</a>, which was announced and annotated in one of the first messages <a href="#Berners-Lee_1991b">[Berners-Lee 1991b]</a> on the www-talk mailing lists in October 1991. I refer to this document as <q>HTML-0</q>. It describes 22 elements that make up the initial design of HTML. In order of appearance the elements are: <code class="element">TITLE</code>, <code class="element">NEXTID</code>, <code class="element">A</code>, <code class="element">ISINDEX</code>, <code class="element">PLAINTEXT</code>, <code class="element">XMP</code> (described indirectly), <code class="element">LISTING</code>, <code class="element">P</code>, <code class="element">H1</code>, <code class="element">H2</code>, <code class="element">H3</code>, <code class="element">H4</code>, <code class="element">H5</code>, <code class="element">H6</code>, <code class="element">ADDRESS</code>, <code class="element">HP1</code>, <code class="element">HP2</code>, <code class="element">DL</code>, <code class="element">DT</code>, <code class="element">UL</code>, <code class="element">MENU</code> and <code class="element">DIR</code>. Thirteen of these elements still exist in HTML4 <a href="#HTML4_1997">[HTML4 1997]</a>, three elements have been deprecated (<code class="element">ISINDEX</code>, <code class="element">MENU</code>, <code class="element">DIR</code>), and six elements have been removed (<code class="element">NEXTID</code>, <code class="element">PLAINTEXT</code>, <code class="element">XMP</code>, <code class="element">LISTING</code>, <code class="element">HP1</code>, <code class="element">HP2</code>).
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>It is noteworthy that HTML-0 did not include any <a href="#presentational_element" class="term">presentational elements</a>. That is, HTML-0 consisted only of <a href="#logical_element" class="term">logical elements</a>. This crucial design decision is confirmed in a comparison of MIME's rich text feature <a href="#Borenstein_1994">[Borenstein 1994]</a> and HTML <a href="#Berners-Lee_1992a">[Berners-Lee 1992a]</a>:
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<blockquote>Comparing MIME's rich text and HTML, I see that we lack the characetr formatting attributes BOLD and ITALIC but on the other hand I feel that our treatment of logical heading levels and other structures is much more powerful and has turned out to provide more flexible formatting on different platforms than explicit semi-references to font sizes. This is born out by all the systems which use named styles in preference to explicit formatting, LaTeX or other macros instead of TeX, etc etc.</blockquote>
|
||
|
|
|
||
|
|
<p>Style sheets are mentioned once in HTML-0 in the description of the <code class="element">P</code> element:</p>
|
||
|
|
|
||
|
|
<blockquote>This tag indicates a new paragraph. The exact representation of this (indentation, leading, etc) is not defined here, and may be a function of other tags, style sheets etc.</blockquote>
|
||
|
|
|
||
|
|
<p>Thus, the concept of style sheets was known to the designer of HTML. The program library <em>libwww</em> <a href="#Nielsen_1994">[Nielsen&Lie 1994]</a> which was CERN's freely available implementation of HTTP and HTML, supported client-side style sheets. That is, style sheets were hard-coded in the client to support the presentation of HTML documents and were not considered to be resources to be put on the web. As such, style sheets played a minor role in the initial design of the web.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>This view is supported by the fact that there was no discussion on style sheets on the www-talk mailing list from its inception in October 1991 until Robert Raisch put forward <a href="#rrp">his proposal</a> (RRP, which is discussed in the next chapter) in June 1993 <a href="#Raisch_1993a">[Raisch 1993a]</a>.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-55">Structure versus style</h4>
|
||
|
|
|
||
|
|
<p>Although style sheets per se were not discussed on www-talk, the term <em>styles</em> was used a few times in the context of HTML design. In an early message to www-talk, Berners-Lee argued that a nested structure would have been preferable to the relatively shallow structure that HTML-0 offered <a href="#Berners-Lee_1991b">[Berners-Lee 1991b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>In writing a new generic parser, I wondered whether your text object will store the nested structure of a document. At the moment, the document is a linear sequence of styles: you can't have lists within lists, etc. Ideally, it would be able to handle this - although its more difficult for a human writer to handle when formatting the document. I would in fact prefer, instead of <H1>, <H2> etc for headings [those come from the AAP DTD] to have a nestable <SECTION>..</SECTION> element, and a generic <H>..</H> which at any level within the sections would produce the required level of heading.</blockquote>
|
||
|
|
|
||
|
|
<p>This issue is reiterated in another message eight months later <a href="#Berners-Lee_1992b">[Berners-Lee 1992b]</a>:
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<blockquote>So if we went for a nestable HTML which would be cleaner for those who apreciate recursion, we would have to have a hypertext editor which made the structure visible. I don't have experience enough to know whether real information providers (group secretaries, for example) would be into generating nested elements – maybe the styles are useful to keep as the current `user interface metaphor' of word processors.</blockquote>
|
||
|
|
|
||
|
|
<p>The statements above argue that elements in HTML should not generally be nestable, even if nestable structures are <q>cleaner</q>. One of the arguments against nestable elements is that they do not combine with <q>a linear sequence of styles</q>. Berners-Lee is making these statements after having implemented an HTML parser and formatter of the <em>libwww</em> <a href="#Nielsen_1994">[Nielsen&Lie 1994]</a> library. The percieved conflict between nestable elements and styles is probably due to limitations in the implementation. CSS later addressed this issue by introducing <a href="#contextual_selector" class="term">contextual selectors</a>.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-56">HTML and SGML</h4>
|
||
|
|
|
||
|
|
<p>Like style sheets, SGML was known to the designer of HTML but played a minor role in the sense that HTML-0 was not formally specified in terms of SGML. To some extent, HTML-0 was incompatible with SGML <a href="#Berners-Lee_1991b">[Berners-Lee 1991b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote><PLAINTEXT> is used to indicate that the rest of the file is in fact just ASCII. It turns off SGML parsing completely. It's a fudge for the moment, until we have the document format negociation.</blockquote>
|
||
|
|
|
||
|
|
<p>Berners-Lee also discouraged browser implementors from using strict formal methods when processing HTML documents <a href="#Berners-Lee_1993c">[Berners-Lee 1993c]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>I support Marc completely in his decision to make Mosaic work as best it can when it is given invalid HTML. The maxim is that one should be<br />
|
||
|
|
- conservative in what one does<br />
|
||
|
|
- liberal in what one expects.</blockquote>
|
||
|
|
|
||
|
|
<p>This author believes the above message was unfortunate. If Mosaic had been stricter in its parsing of incoming HTML, the markup on the web may have been much cleaner than it is today.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>The philosophy of SGML was, however, a source of inspiration. In a document describing the design of HTML-0 titled <em class="title">Design Constraints</em>, Berners-Lee writes <a href="#Berners-Lee_1992d">[Berners-Lee 1992d]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.</blockquote>
|
||
|
|
|
||
|
|
<p>Unlike style sheets, SGML quickly became a topic of discussion on www-talk. Of 31 messages posted to the list in 1991 (the list was started in October of that year) eight mentioned SGML. In 1992, 466 messages were posted to the mailing list, of which 138 mentioned SGML.</p>
|
||
|
|
|
||
|
|
<p>Dan Connolly initiated many of the discussions by arguing that HTML should be defined in terms of SGML. In June 1992 he published a DTD for HTML <a href="#Connolly_1992">[Connolly 1992]</a>. In the accompanying message he argued why this was necessary:</p>
|
||
|
|
|
||
|
|
<blockquote>We need an SGML DTD so that we can parse HTML using something besides the public implementation of WWW, and so that we can verify documents converted from other authoring systems such as GNU info, Andew's EZ, or FrameMaker.</blockquote>
|
||
|
|
|
||
|
|
<p>Almost two years later, Connolly reached the same conclusion in a message titled <em>Toward Closure on HTML</em> <a href="#Connolly_1994b">[Connolly 1994b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>The costs and benefits of basing using <em class="ed">[sic]</em> SGML to define HTML have been discussed at great length. Simplifications have been suggested <em class="ed">[...]</em> but at this point, it appears that there is a clear requirement that an HTML document shall be a conforming SGML document.</blockquote>
|
||
|
|
|
||
|
|
<p>Connolly's message generated heated discussions on www-talk and many resisted the idea of making SGML an integral part of the web. The resistance to SGML was based on two main arguments. First, SGML was perceived to be overly complex <a href="#Raggett_1993b">[Raggett 1993b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>I have a feeling that most people find the SGML DTD rather hard to follow in detail. Goldfarb's account of SGML almost seems to go out of its way to make life difficult for the newcomer.</blockquote>
|
||
|
|
|
||
|
|
<p>Second, it was argued that introducing SGML at this stage was unrealistic as it did not reflect the state of the web at the time <a href="#Davis_1994">[Davis 1994]</a> :</p>
|
||
|
|
|
||
|
|
<blockquote>Dan, I don't intend this as a flame, but you need to face reality, by which I mean you need to look at what people ACTUALLY do, not what you WISH they did. As you observe, people don't use an SGML parser to validate their documents. There is no reason to think then that they will ever start. That's reality.</blockquote>
|
||
|
|
|
||
|
|
<p>Despite the controversy, HTML2 was formally defined in terms of SGML and was published as RFC 1866 in November 1995 <a href="#HTML2_1995">[HTML2 1995]</a>.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-57">HMML, HTML+ and HTML3</h4>
|
||
|
|
|
||
|
|
<p>While HTML2 slowly moved towards becoming standardized, the www-talk community busily proposed new features for HTML. Among the most popular features was support for images and multimedia <a href="#Berners-Lee_1993a">[Berners-Lee 1993a]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>HMML is in fact already an extension of HTML for multimedia from O'Reilly. There are similar extenstions from NCSA. We just have to standardize on them for the next DTD which we define. HTML was checkpointed so as not to make a moving target. NCSA's (released) Mosaic for X handles embedded images in the hypertext, as does O'Reilly's (unreleased) Viola.</blockquote>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>The above quote raises several important questions about the development of markup languages for the web: who should be in charge of development, what features should be supported, and what should the language be called? The <em>HMML</em> acronym stands for <em>HyperMedia Markup Language</em> <a href="#Adie_1993">[Adie 1993]</a> and mentioning this indicates a preference for a new language with better support for multimedia.</p>
|
||
|
|
|
||
|
|
<p>A few days later, Dave Raggett announced that he was editing the next version of HTML <a href="#Raggett_1993a">[Raggett 1993a]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>In a recent phone conversation, Tim Berners-Lee suggested I take over editing a new DTD for extensions to the current HTML spec. Don't get worried - the existing HTML tags will continue unchanged.</blockquote>
|
||
|
|
|
||
|
|
<p>Raggett expresses a preference for continuing to use the <q>HTML</q> name as well as the existing HTML elements. A month later he explains the name issue this way <a href="#Raggett_1993f">[Raggett 1993f]</a>:
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<blockquote>HMML is the name of an internal and experimental DTD developed by Pei Wei. However, things became confused when Tim Berners Lee started using "HMML" for the proposed replacement for the original HTML DTD. To avoid confusion I am calling the new DTD "HTML+" which also emphasises that it is a superset of the current format.</blockquote>
|
||
|
|
|
||
|
|
<p>Further, he emphasizes the need for backwards compatibilty with HTML in the sense that existing HTML elements would <q>continue unchanged</q> <a href="#Raggett_1993e">[Raggett 1993e]</a>:
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<blockquote>My main objective is backwards compatibility with existing HTML.</blockquote>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Dale Dougherty of O'Reilly wanted to create a new acronym and a new language <a href="#Dougherty_1993">[Dougherty 1993]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>I'd like to see some discussion about HMML being backwards compatible with HTML. I think it's a mistake to set that up as a design objective. It also raises questions about how WWW parsers are going to work in the future. I would prefer to see HTML as a frozen thing; and HMML as the next generation.</blockquote>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>However, the discussion Dougherty had hoped for did not happen and Raggett published a backwards compatible specification in May 1993. The specification was referred to as <em>HTML+</em> <a href="#Raggett_1993d">[Raggett 1993d]</a> and this name was used until mid-1994 when the proposal was renamed <em>HTML 3.0</em>.</p>
|
||
|
|
|
||
|
|
<p>HTML+ introduced several new concepts which later became part of HTML; the most important of which are tables and forms <a href="#HTMLplus_1993">[HTML+ 1993]</a>. Among the features that HTML+ proposed but which have not become part of HTML are mathematical formulae.</p>
|
||
|
|
|
||
|
|
<p>HTML+ added several features to improve the presentation of documents. Here are some examples:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The proposed <code class="element">FIG</code> element accepted the <code class="attribute">align</code> attribute which allowed text to flow next to the figure.</li>
|
||
|
|
|
||
|
|
<li>The <code class="element">FOOTNOTE</code> element allowed footnotes to be marked up.</li>
|
||
|
|
|
||
|
|
<li>The <code class="element">MARGIN</code> element indicated side notes.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Most of the additional markup that HTML+ offered was logical in nature but came with a suggested presentation that had the potential to enrich the presentation of HTML documents.</p>
|
||
|
|
|
||
|
|
<p>HTML+ did not support style sheets. However, in a <em class="title">A Review of the HTML+ Document Format</em> <a href="#Raggett_1995a">[Raggett 1995a]</a>, Dave Raggett foresees that style sheets will be part of HTML+ in the future:</p>
|
||
|
|
|
||
|
|
<blockquote>Information providers are interested in making their documents appear in a particular style which differentiates them from other information providers. Work is under way to see how HTML+ could support style information without limiting platform independence. Style hints could be expressed as part of the document head and cover aspects such as font families, text color and size, and the use of whitespace around elements. The use of images, and the opportunity to set the color and texture of the background offer further ways of creating a unique style.</blockquote>
|
||
|
|
|
||
|
|
<p>As HTML+ progressed, it was renamed HTML 3.0. At this point, the work on style sheets for the web had progressed and HTML 3.0 introduced functionality for associating documents with style sheets <a href="#Raggett_1995">[Raggett 1995b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>HTML 3.0 relies on linked style info to give authors control over the appearence of documents. Such info is placed in a linked style sheet, or as overrides in the HTML document head, using the STYLE element. The generic CLASS attribute can be used to subclass elements when you want to use a different style from normal, e.g. you might use <h2 class=bigcaps> for headers with enlarged capital letters.</blockquote>
|
||
|
|
|
||
|
|
<p>HTML+ and HTML 3.0 never became officially sanctioned versions of HTML, but the specifications pioneered functionality that, subsequently, has seen extensive use on the web.</p>
|
||
|
|
|
||
|
|
<h4 id="h-58">HTML 3.2</h4>
|
||
|
|
|
||
|
|
<p>Several implementors considered HTML 3.0 to be too far removed from their own implementations and wanted the next HTML specification to codify current behavior rather than engineering new solutions. This conflict was well-known from the development of HTML 2.0. The specification itself describes the development:</p>
|
||
|
|
|
||
|
|
<blockquote>HTML 3.2 aims to capture recommended practice as of early '96 and as such to be used as a replacement for HTML 2.0 (RFC 1866). Widely deployed rendering attributes are included where they have been shown to be interoperable.</blockquote>
|
||
|
|
|
||
|
|
|
||
|
|
<p>HTML 3.2 also makes two references to the non-official HTML 3.0, but most of the novel features from HTML 3.0 were not included. The naming of the specification, therefore, became an issue: giving the specification a name in the 2.x series would probably have been technically more correct, but marketing a lower number would have been difficult. On the other hand, giving the specification a new major number (e.g. 4.0) would promise more than the specification could deliver. Therefore, a compromise solution was reached at <q>3.2</q>.<span class="fn">An excerpt from the minutes of the discussions in W3C's <em>Editorial Review Board</em> is included in the <a href="#acknowledgements">Acknowledgementes</a> of this thesis.</span></p>
|
||
|
|
|
||
|
|
<p>HTML 3.2 became a W3C Recommendation in January 1997, barely a month after CSS1 achieved the same status. The time gap was not long enough for HTML 3.2 to fully describe the impact of style sheets, but the DTD included a <code class="element">STYLE</code> element that made it possible to validate documents that had style sheets in them <a href="#HTML_3.2_1997">[HTML 3.2 1997]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>SCRIPT and STYLE are included to smooth the introduction of client-side scripts and style sheets. Browsers must avoid showing the contents of these element Otherwise <em class="ed">[sic]</em> support for them is not required.</blockquote>
|
||
|
|
|
||
|
|
<p>HTML 3.2 was the first HTML specification to be published as a W3C Recommendation. As such, it was an important test to see how well different W3C member organizations, including Netscape and Microsoft, could work together to achieve consensus on a technical specification.</p>
|
||
|
|
|
||
|
|
<h4 id="h-59">HTML 4</h4>
|
||
|
|
|
||
|
|
<p>HTML4 became a W3C Recommendation in December 1997 <a href="#HTML4_1997">[HTML4 1997]</a>, less than a year after HTML 3.2 had achieved the same status. HTML4 added important functionality, especially in the area of internationalization.</p>
|
||
|
|
|
||
|
|
<p>HTML4 is the first standardized version of the HTML language which describes how style sheets and HTML documents are combined. Three mechanisms are described:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>the <code class="element">STYLE</code> element</li>
|
||
|
|
|
||
|
|
<li>the <code class="attribute">STYLE</code> attribute</li>
|
||
|
|
|
||
|
|
<li>the <code class="element">LINK</code> element
|
||
|
|
</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>These mechanisms had previously been described in a separate W3C Working Draft <a href="#WD-style_1997">[WD-style 1997]</a> and to some extent in the CSS1 specification but, without an official recognition in HTML it was impossible for authors to use web style sheets while adhering to W3C Recommendations.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-60">HTML in context</h4>
|
||
|
|
|
||
|
|
<p>HTML has developed significantly from the first version made available in 1991. Along the way, much functionality has been added while ensuring backwards compatibility. The principle of encouraging logical, rather than presentational markup has remained despite resistance from implementors and authors. As a consequence, style sheets became necessary and later found their place on the web.</p>
|
||
|
|
|
||
|
|
<p>Also, HTML has resisted the temptation of climbing too high on the ladder of abstraction. Tim Berners-Lee describes the difficult balancing act in a message to www-talk <a href="#Berners-Lee_1993b">[Berners-Lee 1993b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>HTML and HTML <em class="ed">[sic]</em> have a status in between a formatting language and a spacific application. As a delivery language for very wide use, the tags must be generic thimselves. STRONG emphasis or EMphasis is not a formatting instruction, it is semantic. But it is not as semantic as PROHIBITION or LOCSHELFNUMBER or MICASHEETTHICKNESS.<br />
|
||
|
|
HTML+ must like HTML refrain from falling into eiter trap, of being too related to markup, or of being too related to a specific application.<br />
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<p>(I believe he meant to write <q>HTML and HTML+</q> in the first sentence.)</p>
|
||
|
|
|
||
|
|
<p>This author believes that HTML has the right level of abstraction: high enough to support presentation on a wide range of devices, and low enough for people to grasp easily the meaning of elements. Unfortunately, however, HTML is often authored at a too low level of abstraction.</p>
|
||
|
|
|
||
|
|
<p>HTML has had a profound impact on how electronic information is authored, stored, transmitted and processed. If HTML had not been successful, we might still have been living in the <q>bad old days</q> <a href="#Berners-Lee_1996">[Berners-Lee 1996]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network.</blockquote>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-61">XML</h3>
|
||
|
|
|
||
|
|
<p>The use of HTML and the web grew rapidly around 1995. Many proponents of SGML argued that HTML was a temporary solution and that the future of web publishing was SGML. This excerpt from a message posted on the comp.text.sgml newsgroup is representative of this view <a href="#Nicol_1995">[Nicol 1995]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>... eventually, HTML will be used primarily for publishing home pages and whatnot, and (SGML|RTF|PDF|whatever) will be used for everything else. Large documents with long lifespans will almost certainly be in SGML (or something similar)</blockquote>
|
||
|
|
|
||
|
|
|
||
|
|
<p>However, many in the SGML community also realized that SGML, as described in <a href="#SGML_1986">[SGML 1986]</a>, was not suitable for use on the web. In June, 1996, W3C announced to its members the formation of a <q>Web-SGML activity</q> <a href="#Connolly_1996">[Connolly 1996]</a>. From the announcement:</p>
|
||
|
|
|
||
|
|
<blockquote>The overall goal of the activity is to work in collaboration with ongoing efforts in ISO/IEC JTC1, SGML Open, and the IETF to provide the pieces needed to complete the array of specifications that will enable Web publishing using generic SGML.</blockquote>
|
||
|
|
|
||
|
|
<p>The term <q>generic SGML</q> refers to <a class="term" href="#generic_markup">generic markup</a> that uses tags unknown to the recipient.</p>
|
||
|
|
|
||
|
|
<h4 id="h-62">The SGML Working Group charter</h4>
|
||
|
|
|
||
|
|
<p>In his first message to the SGML Working Group, the chair Jon Bosak listed three expected deliverables from the group <a href="#Bosak_1996b">[Bosak 1996b]</a>. First, the group wanted to produce a form of SGML designed for Internet transmission:</p>
|
||
|
|
|
||
|
|
<blockquote>The specification of an application profile defining a form of SGML designed for Internet transmission and processing by user agents. For purposes of discussion, the format thus defined has been given the temporary working name of Extensible Markup Language (XML).</blockquote>
|
||
|
|
|
||
|
|
<p>Second, the group was to work on a specification of <q>basic hypertext link types for XML</q> <a href="#Bosak_1996b">[Bosak 1996b]</a>. This work later turned into XLink <a href="#XLink_2001">[XLink 2001]</a> and is not discussed further in this thesis.</p>
|
||
|
|
|
||
|
|
<p>Third, the goal was to make DSSSL work in an Internet context <a href="#Bosak_1996b">[Bosak 1996b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>The specification of extensions and public text needed to make DSSSL work in an Internet context. For example, a mechanism needs to be added to DSSSL to enable text to flow around objects.</blockquote>
|
||
|
|
|
||
|
|
<p>It is noteworthy that the group was chartered to address all three areas. Previously, the SGML community had organized for work on each of these three areas to be done by different groups which had led to specifications not being synchronized. By assigning one working group to perform the work in all three areas, one coherent set of specifications could be produced in the same time frame.</p>
|
||
|
|
|
||
|
|
<p>In the end, however, the work on linking and style sheets ended up in separate working groups and their respective specifications were finalized more than three years after XML became a W3C Recommendation <a href="#XSL_2001">[XSL 2001]</a><a href="#XLink_2001">[XLink 2001]</a>.</p>
|
||
|
|
|
||
|
|
<h4 id="h-63">The XML specification</h4>
|
||
|
|
|
||
|
|
<p>The first public XML working draft was published in November 1996 <a href="#WD-XML_1996">[WD-XML 1996]</a>. Line one of the abstract reads:</p>
|
||
|
|
|
||
|
|
<blockquote>Extensible Markup Language (XML) is an extremely simple dialect of SGML which is completely described in this document.</blockquote>
|
||
|
|
|
||
|
|
<p>Both parts of the sentence above are significant. The first part claims that XML is <q>extremely simple</q>. Compared with the SGML standard the first draft XML was relatively simple, but calling it <q>extremely simple</q> is misleading and this wording was changed in the final W3C Recommendation <a href="#XML_1998">[XML 1998]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document.</blockquote>
|
||
|
|
|
||
|
|
<p>The second part of the sentence, which remained unchanged between the first draft and the Recommendation, claims that <q>XML is completely described in this document</q>. It was important for XML to set itself apart from SGML in the sense that knowing SGML was not a requirement for using XML. SGML is referenced in the XML Recommendation, but is not among the normative references.<span class="fn">Since XML has six normative references it can be argued that XML is not <q>completely described in this document</q> as the Recommendation claims.</span></p>
|
||
|
|
|
||
|
|
<p>The introductory sentence of the XML Recommendation also states the two main tasks of the XML Working Group; the group had to select which of SGML's features XML should support, and then describe the feature set in a readable manner. The first task was influenced by the needs of SGML users. Dan Connolly grouped the features into two: those that are architecturally solid, and those that are there for transition purposes <a href="#Connolly_2000">[Connolly 2000]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>My experience leads me to believe that parts of XML are solid architectural inrfastructure <em class="ed">[sic]</em> for the long term: tags and attributes, and namespaces. But other parts of it are there to manage the transition from the existing software base: DTDs, entities, processing instructions, and I don't recommend investing them unless you are constrained by existing software somehow.</blockquote>
|
||
|
|
|
||
|
|
<p>Namespaces, which Connolly included in the group of architecturally solid features, were not part of the XML Recommendation, but are described in a separate W3C Recommendation which trailed the XML Recommendation by a year <a href="#XML-names_1999">[XML-names 1999]</a>.</p>
|
||
|
|
|
||
|
|
<p>Tim Bray, one of the editors of the XML specifications, later proposed to use a similar grouping of XML features and to remove DTDs and entities from future versions of XML <a href="#Bray_2002">[Bray 2002]</a>. One reason for keeping processing instructions (which Bray proposes) is that they are used to point to style sheets.</p>
|
||
|
|
|
||
|
|
<h4 id="h-64">XML and style sheets</h4>
|
||
|
|
|
||
|
|
<p>The XML Recommendation does not refer to style sheets in any way. In order to use style sheets with XML documents there needs to be a way of linking a document to a style sheet. In June 1999, W3C published a Recommendation called <em class="title">Associating Style Sheets with XML Documents</em> <a href="#XML-stylesheet_1999">[XML-stylesheet 1999]</a> which describes how to achieve this using XML processing instructions. For example, to link to a CSS style sheet from an XML document, the following line can be placed in the document:</p>
|
||
|
|
|
||
|
|
<pre><?xml-stylesheet href="mystyle.css" type="text/css"?>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The use of processing instructions for this purpose was somewhat controversial and the Recommendation included text to warn about the future of processing instructions:</p>
|
||
|
|
|
||
|
|
<blockquote>The use of XML processing instructions in this specification should not be taken as a precedent. The W3C does not anticipate recommending the use of processing instructions in any future specification.</blockquote>
|
||
|
|
|
||
|
|
<p>However, the Recommendation <a href="#XML-stylesheet_1999">[XML-stylesheet 1999]</a> is widely implemented and processing instructions are, therefore, likely to be part of any future version of XML.</p>
|
||
|
|
|
||
|
|
<h4 id="h-65">XML in context</h4>
|
||
|
|
|
||
|
|
<p>The stated goal of the XML Recommendation was to <q>enable generic SGML to be served, received, and processed on the web in the way that is now possible with HTML</q> <a href="#XML_1998">[XML 1998]</a>. Measured strictly by this goal, XML has not been a success; the use of generic SGML/XML on the web today is limited. Also, most documents on the web are exchanged in HTML and not in XML. That is, XHTML – which is HTML written according to the rules of XML – has not replaced traditional HTML.</p>
|
||
|
|
|
||
|
|
<p>XML has been a success, however, but perhaps in an area that the creators did not expect. While the XML Recommendation describes <em>XML documents</em>, Dan Connolly noted at an early stage that XML could be used also for <em>data exchange</em>. When describing XML in W3C's newsletter in March 1997, XML was introduced as <q>a markup language for structured document interchange</q>, but he also noted <a href="#Connolly_1997">[Connolly 1997]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Database interchange and structured data exchange between software components and agents are expected to be popular uses.<br />
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<p>Indeed, the impact of XML on data exchange has been more significant than its impact on document exchange.</p>
|
||
|
|
|
||
|
|
<h2 id="h-66">The role of transformation languages</h2>
|
||
|
|
|
||
|
|
<p>A transformation language is a language that expresses transformations from one structure into another. In the context of structured documents, the structures are typically <a class="term" href="#tree_structure">tree structures</a> containing textual content. For example, a transformation language can transform a document written in a private XML vocabulary into an XHTML document.</p>
|
||
|
|
|
||
|
|
<p>In this thesis, transformation languages are interesting for two reasons:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Transformation languages are used on the server side to convert content into content for the web. Typically, a transformation will only move content downwards on the ladder of abstraction; to move content upwards, information external to the document is necessary. It is important that flexible, powerful and efficient transformation languages exist so that content can be generated at the right level of abstraction.</li>
|
||
|
|
|
||
|
|
<li>One school of thought in style sheet languages argues that the document formatting process can and should be expressed as a transformation. Style sheet languages in this tradition are transformation languages as well as being style sheet languages. In this thesis, they are referred to as <a href="#tbssl">transformation-based style sheet languages (TBSSL)</a>.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The latter point is the topic of this section. I argue that while treating formatting as a transformation has certain advantages, there are significant reasons for not adopting this approach on the web.</p>
|
||
|
|
|
||
|
|
<h3 id="h-67">Adorning the tree</h3>
|
||
|
|
|
||
|
|
<p>Most style sheet languages are not transformation languages. Instead of transforming the document structure into a presentation structure, these style sheet languages adorn the document structure with presentational information. For example, consider the following style sheet:</p>
|
||
|
|
|
||
|
|
<pre>H1 { color: red }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>It expresses that all <code class="element">H1</code> elements should be red. The information about color (and other presentational properties) is attached to the <code class="element">H1</code> element. By way of various value propagation mechanisms, all elements in the document have values for all presentational properties. Examples of style sheet languages that use this approach are CSS, P94 and FOSI.</p>
|
||
|
|
|
||
|
|
<p>Implementations of these style sheet languages may optimize memory structures so that not all values are stored on each element but, in principle, the knowledge of the value of each element/property combination should be known. Also, some implementations may choose to use two different tree structures internally, one for the logical structure and another for the presentational structure. Conceptually, though, this behavior is not necessary.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-69">Transforming the tree</h3>
|
||
|
|
|
||
|
|
<p>Transformation-based style sheet languages do not adorn a tree, instead they transform the logical structure into a presentational structure. DSSSL and XSL are style sheet languages that fall into this category.</p>
|
||
|
|
|
||
|
|
<p>Often, these languages are referred to as transformation languages rather than style sheet languages. In the case of XSL, the transformation language has been given its own name, XSLT (where <q>T</q> stands for transformation). Below is an example of how XSLT can be used to convert a XML element into an HTML element. Consider a XML element written in a private vocabulary:</p>
|
||
|
|
|
||
|
|
<pre><ChapterHeading>The headline</ChapterHeading>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>To transform the <code class="element">ChapterHeading</code> element into an <code class="element">H1</code> element, this XSLT fragment can be used:</p>
|
||
|
|
|
||
|
|
<pre><xsl:template match="ChapterHeading">
|
||
|
|
<H1>
|
||
|
|
<xsl:apply-templates/>
|
||
|
|
</H1>
|
||
|
|
</xsl:template>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The output of the transformation is:</p>
|
||
|
|
|
||
|
|
<pre><H1>The headline</H1>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Note that the resulting HTML is at a high enough level of abstraction that device-independence and accessibility are preserved. What is lacking is information about how to present it. XSL addresses this with formatting objects.</p>
|
||
|
|
|
||
|
|
<h3 id="h-70">Formatting objects</h3>
|
||
|
|
|
||
|
|
<p>In order for transformation-based languages also to be style sheet languages, a set of presentational elements is typically defined. The presentational elements serve as building blocks for presentational structure. In DSSSL, the presentational elements are called <em>flow objects</em> and in XSL they are called <a href="#formatting_object" class="term">formatting objects</a>. The DSSSL flow objects are discussed in more detail in the next chapter and the rest of this section focuses on XSL formatting objects (XSL-FO) <a href="#XSL_2001">[XSL 2001]</a>.</p>
|
||
|
|
|
||
|
|
<p>XSL-FO is an XML vocabulary for describing the presentation of documents. A simple XSL style sheet which transforms the <code class="element">ChapterHeading</code> element into a formatting object follows:</p>
|
||
|
|
|
||
|
|
<pre><xsl:template match="ChapterHeading">
|
||
|
|
<fo:block font-size="1.3em" margin-top="1.5em">
|
||
|
|
<xsl:apply-templates/>
|
||
|
|
</fo:block>
|
||
|
|
</xsl:template>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The output of the transformation is XSL-FO:</p>
|
||
|
|
|
||
|
|
<pre><fo:block font-size="1.3em" margin-top="1.5em">
|
||
|
|
The headline
|
||
|
|
</fo:block>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The resulting flow object is at a lower level of abstraction than the HTML element that was the output in the previous example. When transformed into HTML, the semantics of the XML element (<code class="element">ChapterHeading</code>) is preserved since the <code class="element">H1</code> element is globally recognized as being a headline of level 1. When transformed into XSL-FO, the semantics is lost and replaced by presentational properties (<code class="property">font-size</code>, <code class="property">margin-top</code>, and <code class="property">margin-bottom</code> which are borrowed from CSS) that are low on the ladder of abstraction.</p>
|
||
|
|
|
||
|
|
<p>Extensive use of XSL-FO on the web would be a threat to accessibility. Consider one example from braille renderings. Since braille characters use much space, words are often contracted to fit more text on one page. However, some words – for example program variables – should not be contracted. HTML offers the ability to express this (using the <code class="element">VAR</code> element) and this is crucial to improve braille renderings. XSL-FO, on the other hand, gives access to the text but without the information that can be used to decide if a word can be contracted or not.</p>
|
||
|
|
|
||
|
|
<h3 id="h-71">Retaining both semantics and presentation</h3>
|
||
|
|
|
||
|
|
<p>Transformation languages such as XSLT can be used also to generate output that retains the abstraction level while also containing presentational information. Below is an example wherein XML is transformed into an HTML element with associated CSS stylistic properties:</p>
|
||
|
|
|
||
|
|
<pre><xsl:template match="ChapterHeading">
|
||
|
|
<H1 STYLE="font-size: 1.3em; margin-top: 1.5em">
|
||
|
|
<xsl:apply-templates/>
|
||
|
|
</H1>
|
||
|
|
</xsl:template>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The output of the transformation is:</p>
|
||
|
|
|
||
|
|
<pre><H1 STYLE="font-size: 1.3em; margin-top: 1.5em">
|
||
|
|
The headline
|
||
|
|
</H1>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The result preserves both the semantics (in the form of HTML elements) and presentational information (as values on the <code class="attribute">STYLE</code> attribute).<span class="fn">When authoring with CSS, the stylistic rules would normally appear in a separate style sheet and not in a <code class="attribute">STYLE</code> attribute as in the above example. Having separate style sheets eases web-site maintenance and makes documents smaller. However, both forms are valid and one can automatically convert between the two.</span>
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>Yet even more semantics can be preserved by using the <code class="attribute">CLASS</code> attribute of HTML. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre><xsl:template match="ChapterHeading">
|
||
|
|
<H1 CLASS="ChapterHeading"
|
||
|
|
STYLE="font-size: 1.3em; margin-top: 1.5em">
|
||
|
|
<xsl:apply-templates/>
|
||
|
|
</H1>
|
||
|
|
</xsl:template>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The output of the transformation is:</p>
|
||
|
|
|
||
|
|
<pre><H1 CLASS="ChapterHeading"
|
||
|
|
STYLE="font-size: 1.3em; margin-top: 1.5em">
|
||
|
|
The headline
|
||
|
|
</H1>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the <code class="attribute">CLASS</code> attribute is used to store the semantics of the private XML vocabulary. Since this XML vocabulary is not universally understood, the addition of the <code class="attribute">CLASS</code> attribute does not raise the document's abstraction level on the web. However, the <code class="attribute">CLASS</code> attribute makes it possible for the author to transform the HTML document back to the original document.</p>
|
||
|
|
|
||
|
|
<h3 id="h-72">Style versus transformation</h3>
|
||
|
|
|
||
|
|
<p>As discussed above, transformation-based style sheet languages take a different approach to the formatting process than do other style sheet languages. Instead of adorning a logical document structure, these languages transform documents downward on the ladder of abstraction into a presentational structure of formatting objects. In the context of the web, the transformation can take place either on the server side or on the client side. Each option has a significant drawback:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>If the transformation takes place on the server side and formatting objects (for example XSL-FO) are transmitted over the web, there will be a loss of semantics since the transmitted content is at a lower level of abstraction than if the content had been transmitted in HTML.</li>
|
||
|
|
|
||
|
|
<li>If the transformation takes place on the client side, the browser will not be able to support <a href="#progressive_rendering" class="term">progressive rendering</a> of content where content is displayed in small chunks as the document is downloaded. Since the transformation may specify that the last element in the logical structure should come first in the presentational structure, the whole document must be downloaded before the transformation can take place.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>In a traditional publishing environment where printed material is the output, however, the above features are not necessarily drawbacks and the transformation-based approach can make sense. There are three reasons for this:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Authors will often submit material in different formats that need some form of transformation before formatting.</li>
|
||
|
|
|
||
|
|
<li>Since the final result is on paper, the loss of machine-readable semantics is inherent in the medium.</li>
|
||
|
|
|
||
|
|
<li>Progressive rendering is not an issue when paper is the final result.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Hence, transformation-based style sheet languages may be suitable in traditional publishing environments, but not on the web. It should be emphasized that the discussion in this section pertains to transformation-based style sheet languages, not to transformation languages in general.</p>
|
||
|
|
|
||
|
|
<h2 id="h-73">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>Structured document systems have been an area of research and development since around 1980. The concept of separating structure from presentation is now firmly established. Style sheet languages are a requirement for the presentation of structured documents but several of the structured document formats were developed without an accompanying style sheet language. As a result, the benefits of structured document formats have been limited.</p>
|
||
|
|
|
||
|
|
<p>The ladder of abstraction is proposed as a way of measuring abstraction levels of structured document formats. A document format's level of abstraction is an important factor when determining the format's suitability for use on the web: formats that are high on the ladder typically require more processing – including transformations and styling – before presentation. Document formats that are low on the ladder of abstraction require little processing, and may be unsuitable for use on the web for accessibility reasons. Since the style sheet language is an important part of the processing of documents before presentation, the level of abstraction is very relevant in determining the suitability of a particular style sheet language/document format combination.</p>
|
||
|
|
|
||
|
|
<p>Several structured document systems were developed in the 1980s and 1990s. Scribe, LaTex, ODA, and SGML were developed prior to the web and none of them have seen much use on the web. HTML and XML were developed for the web and are still seeing active development. HTML is the most popular structured markup language for the web, and – when used correctly – is a media-independent document format that is recognized by all web browsers. As such, HTML has established a layer of universal semantics for web documents. One important feature of HTML is that it does not need extensive client-side transformations before presentation. Browsers, therefore, can support progressive rendering of documents.</p>
|
||
|
|
|
||
|
|
<p>An alternative to HTML is to use generic XML, i.e. a private XML vocabulary. Depending on the format, the document may require extensive transformation on the client side. This makes the presentation more flexible (e.g., elements can be reordered) but progressive rendering becomes impossible. Also, the document is no longer universally understood. Transformation-based style sheet languages are therefore not suitable on the web.</p>
|
||
|
|
|
||
|
|
<p>Different document formats serve different purposes and different audiences. There is no document format or level of abstraction that will be ideal for all purposes and the web must be hospitable to a range of formats. The challenge is to find a format that is high enough on the ladder to be useful in many contexts while not requiring too much effort by the author, nor too much transformation in the user agent. HTML, when used correctly, comes close to being an ideal format for a wide range of documents.</p>
|
||
|
|
|
||
|
|
<p>Having established the need for style sheet languages in order to present documents, style sheets are the topic of the next two chapters.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-preweb" title="Style sheets prior to the web">
|
||
|
|
<h1 class="chapter" id="h-74">Style sheets prior to the web</h1>
|
||
|
|
|
||
|
|
<p>One of the most attractive features of structured documents is that the content can be used in many contexts and presented in various ways. A variety of different style sheets can be attached to the logical structure to serve different needs. However, the flexibility that structured documents offer comes at a price since some kind of style sheet mechanism is needed to make the content available for users.</p>
|
||
|
|
|
||
|
|
<p>In order for content in structured documents to be presented, a set of stylistic rules – describing for example, colors, fonts and layout – must be applied. A collection of stylistic rules is called a <a href="#style_sheet" class="term">style sheet</a>. Style sheets in the form of written documents have a long history of use by editors and typographers to ensure consistency of presentation, spelling and punctuation. In electronic publishing, the term style sheet is mostly used in the context of visual presentation rather than spelling and punctuation. In this thesis, style sheet is defined as <em>a set of rules that associate stylistic properties and values with structural elements in a document, thereby expressing how to present the document.</em></p>
|
||
|
|
|
||
|
|
<p>Style sheets have been referred to by other names in the past. P94 calls them <em>presentation schemas</em>. <em class="program">Interleaf</em> and <em class="program">Xerox Star</em> refer to them as <em>property sheets</em>. <em class="program">Microsoft Word</em> refers to them as <em>styles</em>. FOSI and DSSSL use the term <em>characteristic</em> to mean what CSS calls <a href="#property" class="term">property</a>, while P94 sometimes calls it a <em>parameter</em>. Because various proposals use different terms to mean the same thing and, in order to facilitate a comparison, this thesis uses CSS terms in the discussions.</p>
|
||
|
|
|
||
|
|
<p>In this chapter are discussed three seminal style sheet languages that were developed before the web. Two of them (FOSI and DSSSL) were developed by standards committees for use with SGML. The third (P94) was developed by a research project for experimental purposes. The three systems were chosen since they:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>contribute novel features to the concept of style sheets;</li>
|
||
|
|
|
||
|
|
<li>separate style sheets from the document;</li>
|
||
|
|
|
||
|
|
<li>can, in principle, be used with different types of structured document systems;</li>
|
||
|
|
|
||
|
|
<li>are not tied to any particular application or formatter;</li>
|
||
|
|
|
||
|
|
<li>were developed before the web. Although the development of DSSSL and P94 in part took place after the web was launched, the style sheet languages do not exhibit any influence from the web.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>This chapter does not cover proprietary style sheet systems (such as Microsoft Word, FrameMaker, Interleaf, Panorama, Lector, ViewPort and ReportLab's RML2PDF), nor does it discuss systems that have been been described in articles but not used in practice (such as <a href="#Bruggemann-Klein_1992">[Brüggemann-Klein&Wood 1992]</a> and <a href="#Weitzman_1994">[Weitzman&Wittenberg 1994]</a>). Also, two authoring systems (Scribe, LaTex) that also have style sheet languages associated with them are discussed in the previous chapter instead of here.</p>
|
||
|
|
|
||
|
|
<p>Each review starts with a short description of the historical context of the language, followed by a technical review. The reviews are not exhaustive but give a general overview of each language and discuss points of interest along the way. Document and style sheet fragments are used extensively in the discussions since I believe style sheet languages are best understood by looking at examples.</p>
|
||
|
|
|
||
|
|
<h2 id="h-75"><a id="what" name="what">Components of a style sheet language</a></h2>
|
||
|
|
|
||
|
|
<p>Before evaluating the style sheet languages themselves, it is necessary to establish common criteria by which the languages will be judged. I suggest that a style sheet language has six required components:
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Syntax: a style sheet language needs a syntax in order to be expressed in a machine-readable manner. All languages reviewed in this dissertation have a text-based syntax to make them easier for humans to read and write. Furthermore, the syntax of the style sheet language can be specified in a standardized syntax (FOSI is written in SGML), borrowed from other languages (DSSSL is based on the Scheme programming language), or inspired by other syntaxes (SSP, which is discussed in the next chapter, is inspired by X11 resources [X11]).</li>
|
||
|
|
|
||
|
|
<li>Selectors: selectors specify which elements are to be influenced by the style rule. As such, selectors are the glue between the structure of the document and the stylistic rules in the style sheets. Some languages express selection only through selectors (CSS, SSP), while other languages also perform selection in declarations associated with potential elements (DSSSL, FOSI, P94). In the latter case, a simple selector language based on <a href="#element_type" class="term">element types</a> is typically combined with an expression language.</li>
|
||
|
|
|
||
|
|
<li>Properties: all style sheet languages have some concept of properties that can be given values to change one aspect of rendering an element. The <em>font size</em> and <em>font weight</em> are typical examples of properties. Some languages group properties (e.g. all font-related properties) into categories (FOSI) or allow several properties to be set in some shorthand syntax (CSS). Properties to set white space and borders can be relative to the writing direction (before/after/start/end), or absolute (top/bottom/left/right and inside/outside). Most style sheet languages have properties of both types (paragraph indentation is always relative, and page margins are typically absolute) but tend to favor one kind of property.</li>
|
||
|
|
|
||
|
|
<li>Values and units: properties change the rendering of an element by being assigned a certain value. The value can be a string, a keyword, a number, or a number with a unit identifier. Also, values can be lists or expressions involving several of the aforementioned values. A typical value in a visual style sheet is a length; for example, <code class="value">3.1cm</code> which consists of a number (<code>3.1</code>) and a unit (<code class="unit">cm</code>). Units can be absolute (e.g. <code class="unit">cm</code>) or relative to some other measurement (e.g. <code class="unit">em</code>, which is relative to the font size). Some languages also allow expressions as values.</li>
|
||
|
|
|
||
|
|
<li>Value propagation mechanism: to avoid having to specify explicitly all values for all properties on all elements, style sheet languages have mechanisms to propagate values automatically. The main benefit of value propagation is less-verbose style sheets. <a href="#inheritance" class="term">Inheritance</a>, <a href="#initial_value" class="term">initial values</a> and <a href="#cascading" class="term">cascading</a> are examples of value propagation mechanisms.</li>
|
||
|
|
|
||
|
|
<li>Formatting model: all style sheet languages support some kind of formatting model. All style sheet languages discussed in this thesis has a <em>visual</em> formatting model and some also support an <em>aural</em> formatting model for accessibility reasons.
|
||
|
|
|
||
|
|
<p>In a visual formatting model <a href="#logical_element" class="term">logical elements</a> are turned into <a href="#formatting_object" class="term">formatting objects</a> in the <a href="#formatting" class="term">formatting</a> process. Most often, the formatting objects are rectangular boxes that are laid out one after the other or nested inside each other. Different visual formatting models have different kinds of formatting objects; for example, generated by <a href="#block-level_element" class="term">block-level</a>, <a href="#inline_element" class="term">inline</a>, floating and various table elements. Visual formatting models can be classified as <a href="#box_model" class="term">box models</a> (where hierarchies of <a href="#box" class="term">boxes</a> fit inside each other) or as <a href="#sequence_model" class="term">sequence models</a> (where <a href="#area" class="term">areas</a> are placed in sequence in the <a href="#layout_area" class="term">layout area</a>). Further, formatting can be <a href="#outside-in_formatting" class="term">outside-in</a> (where parent elements set the size of their children) or <a href="#inside-out_formatting" class="term">inside-out</a> (where child elements determine the size of their parent).</p>
|
||
|
|
|
||
|
|
<p>Formatting to an aural device is very different from visual formatting, but the concepts of style sheets, properties, values and units are still applicable.</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The above components are present in all style sheet languages. Many style sheet languages also contain functionality in these optionaly components:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Generated content: more-advanced style sheet languages have ways of adding text and other content to the document presentation. Style sheets do not contain substantial content and generated content is limited to short passages including: simple strings, quote marks, counters, cross-references, headers/footers, horizontal rules and table of contents.</li>
|
||
|
|
|
||
|
|
<li>Linking mechanism: in order to take effect, a style sheet must be linked to a document. The linking can be specified in the document, in the style sheet, or by the human user. The linking mechanism is often not part of the style sheet language itself but is still described in style sheet language proposals. Some style sheet languages have ways to import one style sheet into another.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h2 id="h-76"><a id="fosi" name="fosi">Formatting Output Specification Instance (FOSI)</a></h2>
|
||
|
|
|
||
|
|
<p>SGML (as discussed in <a href="#ch-structure">Chapter 2, Structured documents</a>) defines the syntax for specifying the structure and content of a document. However, SGML does not describe the presentation of documents. Around 1986, when SGML became an ISO standard, users typically relied on proprietary systems to produce human presentations of SGML documents.</p>
|
||
|
|
|
||
|
|
<p>In 1987, the US Department of Defense (DoD) organized a committee to study how SGML could address the need for document interchange. A year later DoD adopted SGML as the documentation component of the CALS (Continuous Acquisition and Life-cycle Support) initiative.<span class="fn">The acronym CALS originally stood for <em>Computer-Aided Logistics Support</em>, then for <em>Computer-aided Acquisition and Logistics Aupport</em> until it was changed to the current <em>Continuous Acquisition and Life-cycle Support</em></span> For the next decade, CALS was an active proponent of SGML-based technologies <a href="#SGMLUG_1990">[SGMLUG 1990]</a> <a href="#Goldfarb_1997">[Goldfarb et al.1997]</a>.</p>
|
||
|
|
|
||
|
|
<p>In addition to representing structure and content – which SGML addressed – CALS also needed a vendor-neutral way of presenting SGML documents. Where the standards did not exist, CALS created its own.<span class="fn">One of them, the CALS Table model, was influential for the HTML table model <a href="#Bingham_2000">[Bingham 2000]</a><a href="#Raggett_1995c">[Raggett 1995c]</a>.</span> In <a href="#Kidwell_1997">[Kidwell&Richman 1997]</a>, the history is told in this way:</p>
|
||
|
|
|
||
|
|
<blockquote>Because SGML is independent from presentation, some means of describing presentation to a document composition system was needed. Unfortunately, the language that the international standards community was developing to satisfy this requirement, called the Document Style Semantics and Specification Language (DSSSL), was first published in draft form in late 1994, and was published as an official ISO standard in late 1995 - eight years after the CALS requirement was identified. During that time, the DoD elected to establish an interim capability for CALS, based upon SGML, that addressed composition.</blockquote>
|
||
|
|
|
||
|
|
<p>The <q>interim capability</q> is the <em>Output Specification</em> described in <a href="#FOSI_1997">[FOSI 1997]</a>. A style sheet written according to the <em>Output Specification</em> is called a <em>Formatting Output Specification Instance</em>, FOSI for short. The specification is also commonly referred to as <em>FOSI</em> and this term is used in this thesis although the specification refers to itself as <em>OS</em>.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>For almost 10 years, FOSI was the only vendor-neutral method of specifying the presentation of SGML documents. The FOSI specification went through three major revisions during that period and matured along the way. As with all specifications in this area, FOSI contained ambiguities that led to non-interoperable implementations <a href="#Harvey_1997">[Harvey 2000]</a><a href="#ManTech_1997">[ManTech 1997]</a>, and some of the advanced features were not widely supported. By the time the specification matured, still well before DSSSL became a standard, there were only two implementors left: Arbortext and Datalogics <a href="#Harvey_2002">[Harvey 2002]</a>.</p>
|
||
|
|
|
||
|
|
<p>For these reasons, FOSI was controversial. In 1994, the United States Postal Service issued a solicitation for a system to <q>edit technical manuals, and to print hard copies of manuals in various sizes and formats or to generate electronic media copies through the use of an electronic handbook feature</q> <a href="#USPS_1994">[USPS 1994]</a>. The solicitation specified that SGML was to be used for content and FOSI style sheets were to be used to render the content. Expressing a strong belief in a future DSSSL, the solicitation stated that FOSI <q>defines the appearance of an SGML document by determining the format of each tag described in a DTD. FOSI is ... the recognized government standard for format until [Document Style Semantics and Specification Language (DSSSL)] is approved as the superseding international standard</q>. Interleaf, an SGML software company, protested against several aspects of the solicitation, including the requirement for a solution to support FOSI. Interleaf claimed that <q>FOSI is not a standard; interpretation is system-dependent and is effectively proprietary</q>. Also, Interleaf claimed that the USPS would require <q>highly trained and technical personnel to construct FOSIs</q> because the <q>process is detailed, and non-intuitive</q>. The USPS defended the use of FOSI and the protest was rejected <a href="#USPS_1994">[USPS 1994]</a>.</p>
|
||
|
|
|
||
|
|
<p>FOSI is still (as of 2004) in use and supported by commercial implementations. I have not had access to a FOSI implementation when performing this review but have had helpful discussions with Paul Grosso and Pamela Gennusa who have been central in the development of FOSI. The initial FOSI specification, called MIL-M-28001, was originally issued in February, 1988; versions MIL-M-28001A and MIL-M-28001B were issued in July, 1990 and June, 1993, respectively. The technical review below is based on the latest version of the FOSI specification, MIL-PRF-28001C, published in 1997 <a href="#FOSI_1997">[FOSI 1997]</a>.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-77">Syntax</h3>
|
||
|
|
|
||
|
|
<p>A FOSI style sheet describes the presentation of an SGML document. It is also written in SGML. FOSI is, therefore, an early example of using a markup language to store data (i.e., stylistic rules) rather than documents. Here is a sample FOSI fragment:</p>
|
||
|
|
|
||
|
|
<pre><e-i-c gi="h1">
|
||
|
|
<charlist inherit="1">
|
||
|
|
<font size="14pt" weight="bold">
|
||
|
|
</charlist>
|
||
|
|
</e-i-c>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="element">e-i-c</code> element (which stands for <em>element in context</em>) is FOSI's selector mechanism. In the example above all <code class="element">H1</code> elements are selected (<code class="attribute">gi</code> is short for <em>generic identifier</em> which is SGML's term for element names).</p>
|
||
|
|
|
||
|
|
<p>The next element is <code class="element">charlist</code> which contains a list of stylistic properties and values for the <code class="element">h1</code> elements. The <code class="attribute">inherit</code> attribute on <code class="element">charlist</code> indicates whether or not property values should be inherited from the parent element. Boolean values are represented as <code class="value">1</code> and <code class="value">0</code> in FOSI. By default, inheritance is turned off. FOSI has an elaborate mechanism for <q>inheritance and defaulting</q> (described below), but in the simple example above all inheritable properties take their values from the the parent element with the exception of font size and font weight.</p>
|
||
|
|
|
||
|
|
<h3 id="h-78">Selectors</h3>
|
||
|
|
|
||
|
|
<p>Selectors in FOSI are expressed as attributes to the <code class="element">e-i-c</code> element. In the simple example in the previous section, all elements of a certain type (<code class="element">h1</code>) were selected independently of their context. Here is a more advanced example which selects elements in context (and thereby does justice to the <em>e-i-c</em> name):</p>
|
||
|
|
|
||
|
|
<pre><e-i-c gi="li" context="ol">
|
||
|
|
<charlist>
|
||
|
|
<font posture="italic">
|
||
|
|
</charlist>
|
||
|
|
</e-i-c>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The selector above expresses two requirements; for elements to match they must be of type <code class="element">li</code> and have an <code class="element">ol</code> element as parent. The <code class="attribute">context</code> attribute expresses parental relationships, and can – by adding the asterisk character in the UNIX wildcard tradition – also express ancestor relationships.</p>
|
||
|
|
|
||
|
|
<pre><e-i-c gi="li" context="* ol">
|
||
|
|
<charlist>
|
||
|
|
<font posture="italic">
|
||
|
|
</charlist>
|
||
|
|
</e-i-c>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above the <code class="element">li</code> element must have an ancestor of type <code class="element">ol</code>, but <code class="element">ol</code> does not have to be the parent.</p>
|
||
|
|
|
||
|
|
<p>The FOSI specification describes in detail how the <a href="#specificity" class="term">specificity</a> of a contextual selector is determined (<q>determine which context path most specifically matches the current path</q> in FOSI terminology). The strategy for determining specifictiy is similar to the one defined in CSS.</p>
|
||
|
|
|
||
|
|
<p>The <code class="attribute">occur</code> attribute adds more constraints to selectors by specifying that the element should be the <code class="value">only</code>, <code class="value">first</code>, <code class="value">last</code>, <code class="value">middle</code> (all elements but first and last), <code class="value">notlast</code>, or <code class="value">notfirst</code> sibling. Also, <code class="value">all</code> (which is the default value) is allowed. Here is a simple example:</p>
|
||
|
|
|
||
|
|
<pre><e-i-c gi="P" occur="first">
|
||
|
|
<charlist>
|
||
|
|
...
|
||
|
|
</charlist>
|
||
|
|
</e-i-c>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Elements can also be selected based on the existence, or value, of an attribute. FOSI does this in two stages: first the element is selected based on its name, thereafter the attributes are matched. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre><e-i-c gi="NOTE">
|
||
|
|
<att>
|
||
|
|
<specval attname="WARNING" attval="#ANY">
|
||
|
|
<charsubset>
|
||
|
|
...
|
||
|
|
</charsubset>
|
||
|
|
</att>
|
||
|
|
</e-i-c>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the <code class="element">att</code> and <code class="value">specval</code> elements indicate that only <code class="element">NOTE</code> elements with a <code class="attribute">WARNING</code> attribute should be selected.</p>
|
||
|
|
|
||
|
|
<h3 id="h-79">Properties</h3>
|
||
|
|
|
||
|
|
<p>FOSI has a rich set of properties that are grouped into <em>categories</em>. Each category is represented by an element, and each property is an attribute. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The categories in the example above are <code class="element">font</code>, <code class="element">textbrk</code>, <code class="element">presp</code> and <code class="element">postsp</code>. Categories are always children of <code class="element">charlist</code>. Besides being a container for the categories, the <code class="element">charlist</code> element also determines if inheritance should be turned on for its children. FOSI's concept of inheritance is discussed in more detail below.</p>
|
||
|
|
|
||
|
|
<p>FOSI has some properties that are relative to the writing direction, and some that are absolute. The properties to set vertical margins on elements (called <code class="property">presp</code> and <code class="property">postsp</code>, short for <em>prespace</em> and <em>postspace</em>, respectively) are relative, while the properties to set horizontal margins are absolute (<code class="property">leftind</code>, <code class="property">rightind</code>).</p>
|
||
|
|
|
||
|
|
<p>Some properties are interdependent. In the above example <code class="property">presp</code> and <code class="property">postsp</code> will only take effect when <code class="attribute">startln</code> and <code class="attribute">endln</code> are set on the <code class="element">textbrk</code> element.</p>
|
||
|
|
|
||
|
|
<p>Table 4 gives an overview of all FOSI categories.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-4">
|
||
|
|
<p class="caption">FOSI's categories.</p>
|
||
|
|
|
||
|
|
<table summary="" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Category</th>
|
||
|
|
<th>Properties</th>
|
||
|
|
<th>Corresponding CSS functionality</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tbody>
|
||
|
|
<tr>
|
||
|
|
<td>font</td>
|
||
|
|
<td>style, famname, size, posture, weight, width, smallcap, offset</td>
|
||
|
|
<td>Corresponds roughly to the <code class="property">font-</code> properties in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>leading</td>
|
||
|
|
<td>lead, force</td>
|
||
|
|
<td>Corresponds roughly to <code class="property">line-height</code> in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>hyphen (hyphenation)</td>
|
||
|
|
<td>lang, hyph, zone</td>
|
||
|
|
<td>CSS2 has no functionality for hyphenation. The <code class="attribute">lang</code> attribute of HTML and XML can express language.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>wordsp (word spacing) and lettersp (letter spacing)</td>
|
||
|
|
<td>minimum, nominal, maximum</td>
|
||
|
|
<td>Corresponds to <code class="property">word-spacing</code> and <code class="property">letter-spacing</code> in CSS, but CSS can only express nominal values.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>sentxsp (sentence spacing)</td>
|
||
|
|
<td>minimum, nominal, maximum</td>
|
||
|
|
<td>No similar functionality in CSS since it is very hard to programmatically determine what a sentence is.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>lettersp (letter spacing)</td>
|
||
|
|
<td>minimum, nominal, maximum, kerntype, kernpair</td>
|
||
|
|
<td>Some effects can be achieved with the <code class="property">letter-spacing</code> property in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>indent</td>
|
||
|
|
<td>leftind, rightind, firstln</td>
|
||
|
|
<td>Similar effects can be achieved with <code class="property">margin</code> and <code class="property">text-indent</code> in CSS (but see <q>page model</q> below for a discussion of differences).</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>quadding</td>
|
||
|
|
<td>quad, lastquad</td>
|
||
|
|
<td>Roughly similar to <code class="property">text-align</code> in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>highlt (highlight)</td>
|
||
|
|
<td>reverse, scoring, scorewt, scoreoff, scorechron, scorechr, bckclr (background color), fontclr (font color), bckpct, forpct, allcap, scorespc</td>
|
||
|
|
<td>Similar effects can be achieved with <code class="property">color</code>, <code class="property">background</code>, and <code class="property">text-decoration</code> in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>chgmark (change marks)</td>
|
||
|
|
<td>literal, barthick, baroffset, join, type, cmclass</td>
|
||
|
|
<td>There is no similar functionality in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>prespace/postspace</td>
|
||
|
|
<td>minimum, nominal, maximum, condit, priority</td>
|
||
|
|
<td>The same effects can be achieved with <code class="property">margin</code>, <code class="property">padding</code>, <code class="property">page-break-before</code>, and <code class="property">page-break-after</code> in CSS</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>keeps</td>
|
||
|
|
<td>keep, scope, widowct, orphanct, next, prev, floatsout</td>
|
||
|
|
<td>Corresponds to <code class="property">page-break-inside</code>, <code class="property">widow</code>, and <code class="property">orphan</code> in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>vjinfo (vertical justification)</td>
|
||
|
|
<td>presppr, postsppr, keepspr</td>
|
||
|
|
<td>Corresponds to the <code class="property">vertical-align</code> property in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>textbrk (textbreak)</td>
|
||
|
|
<td>startcol, startpg, resumepg, pageid, newpgmdl, startln, endln</td>
|
||
|
|
<td>Corresponds to the <code class="property">page-break-before</code>, <code class="property">page-break-after</code> in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>span</td>
|
||
|
|
<td>span</td>
|
||
|
|
<td>The <code class="property">span</code> property describes how elements span several columns.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>border</td>
|
||
|
|
<td>bordname</td>
|
||
|
|
<td>The <code class="property">bordname</code> property points to the a border definition on a per page level.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>float</td>
|
||
|
|
<td>flidref (a reference to a float location), width, widowht, orphanht, scope, pagetype (same, facing etc.), inline, multirefname</td>
|
||
|
|
<td>These properties describe how content can float to other parts of the document. For example, elements can float to the top of recto pages. There is no similar functionality in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>algroup (alignment group)</td>
|
||
|
|
<td>refpoint (top, first, middle, last, bottom), postspace</td>
|
||
|
|
<td>These properties are used to align elements next to each other, similar to the <code class="property">float</code> property in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>suppress</td>
|
||
|
|
<td>sup</td>
|
||
|
|
<td>The <code class="property">sup</code> property has an integer value from 0-5 indicating a level of content suppression. In CSS, the <code class="value">none</code> value on the <code class="property">display</code> property can be used to indicate content suppression.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>boxing</td>
|
||
|
|
<td>toffset, boffset, loffset, roffset, trel, brel, siderel, leftgap, rightgap, thick, ttype, btype, ltype, rtype, inclr, inpct, outclr, outpct</td>
|
||
|
|
<td>These properties describe the <code class="property">boxing</code> of content. This functionality is described in <code class="property">background</code>, <code class="property">padding</code>, and <code class="property">border</code> properties.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>link</td>
|
||
|
|
<td>sysid, targdocent, targid, endtargid, linktype, uselink, usetargid, useendtargid</td>
|
||
|
|
<td>These properties describe various aspects of links. There is no similar functionality in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>linkproc</td>
|
||
|
|
<td>loprocess, exloproc, loconrule, liprocess, exliproc, liconrule</td>
|
||
|
|
<td>These properties describe various aspects of links. There is no similar functionality in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>reset</td>
|
||
|
|
<td>resetlist</td>
|
||
|
|
<td>Similar to the <code class="property">counter-reset</code> property in CSS</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>enumerat (enumeration)</td>
|
||
|
|
<td>increm, enumid, setvalue</td>
|
||
|
|
<td>Similar to the <code class="property">counter-increment</code> property in CSS</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>ruling</td>
|
||
|
|
<td>thick, lentype, speclen, rellen, voffset, placemnt, ruleclr, rulepct, type</td>
|
||
|
|
<td>These properties describe the look and placement of horizontal rules. CSS can only describe whether a horizontal rule should be present or not.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>puttext</td>
|
||
|
|
<td>literal, placemnt</td>
|
||
|
|
<td>This functionality is similar to generated text in CSS2.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>putgraph</td>
|
||
|
|
<td>graphname, width, depth, placemnt, scalefit, hscale, vscale, hoffset, voffset, rotation</td>
|
||
|
|
<td>CSS relies on markup to add external graphics.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>savetext</td>
|
||
|
|
<td>textid, conrule, placemnt, append</td>
|
||
|
|
<td>Describes text content to be saved for use elsewhere. CSS does not have similar functionality.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>usetext</td>
|
||
|
|
<td>source, placemnt, userule, userparam</td>
|
||
|
|
<td>Describes what to do with text saved from some part of the document. There is no similar functionality in CSS.</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>In addition to the categories listed above, FOSI has several categories for table formatting.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-81">Values and units</h3>
|
||
|
|
|
||
|
|
<p>Values in FOSI can be keywords, integers and lengths.</p>
|
||
|
|
|
||
|
|
<p>The length units in FOSI are: <code class="unit">pi</code> (picas), <code class="unit">pt</code> (points), <code class="unit">in</code> (inches), <code class="unit">mm</code> (millimeters), <code class="unit">cm</code> (centimeters), <code class="unit">em</code> (em space). Notably missing is a pixel unit, and this indicates that FOSI is mostly targeted for printed output. The only relative unit is the <code class="unit">em</code> unit which CSS later adopted. The pica unit is called <code class="unit">pi</code>, not <code class="unit">pc</code> as in CSS.</p>
|
||
|
|
|
||
|
|
<p>Values can contain simple expressions but relative and absolute units cannot be combined. Combinations of units are allowed. For example, to specify 5 picas plus 3 points one could write:</p>
|
||
|
|
|
||
|
|
<pre>5pi 3pt
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The space separating the two values is optional. Subtraction can be achieved by adding a negative value:</p>
|
||
|
|
|
||
|
|
<pre>5pi -3pt
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Integer values are used to represent boolean values <a href="#FOSI_1997">[FOSI 1997]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Zero is defined as 0, false, no, and off. Non-zero is defined as 1, true, yes, and on.</blockquote>
|
||
|
|
|
||
|
|
<p>Some categories have properties to declare minimum, nominal and maximum values:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<h3 id="h-82">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>FOSI has an elaborate model for <q>inheritance and defaulting</q>. Some properties in FOSI are inheritable, but even inheritable properties are not inherited unless inheritance is specifically enabled. Inheritance can be enabled on a per-category basis and inheritance is enabled by the <code class="attribute">inherit</code> attribute:</p>
|
||
|
|
|
||
|
|
<pre><e-i-c gi="TITLE">
|
||
|
|
<charlist>
|
||
|
|
<font inherit="1" size="20pt">
|
||
|
|
</charlist>
|
||
|
|
</e-i-c>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, all properties in the <code>font</code> category use the inherited value except <code>size</code> which sets the value explicitly. By setting the <code class="attribute">inherit</code> attribute on the <code class="element">charlist</code> element, inheritance will be enabled for all inheritable properties:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="attribute">inherit</code> attribute on the <code class="element">charlist</code> element effectively gives the default value for all inheritable categories therein, and then the individual inherit attribute on each inheritable category may override it.</p>
|
||
|
|
|
||
|
|
<p>The specification also describes an <code class="attribute">envname</code> attribute on the <code class="element">charlist</code> element <a href="#FOSI_1997">[FOSI 1997]</a>.</p>
|
||
|
|
|
||
|
|
<blockquote>If inheritance is not enabled for this category, the characteristics in this category that are not explicitly assigned values obtain their respective values from the environment indicated by the environment name (envname) attribute of the charlist.</blockquote>
|
||
|
|
|
||
|
|
<p>In practice, however, <code class="attribute">envname</code> is never used in FOSI style sheets <a href="#Grosso_1993">[Grosso 1993]</a>.</p>
|
||
|
|
|
||
|
|
<p>Figure 2 is one of the few figures in the FOSI specification. It describes the information flow in the inheritance and defaulting mechanism.</p>
|
||
|
|
|
||
|
|
<div id="f-2" class="figure">
|
||
|
|
<p><img style="width: 90%" alt="Complex diagram showing inheritance and defaulting flow chart in FOSI" class="page" src="i/fosi.png" /></p>
|
||
|
|
|
||
|
|
<p class="caption">Inheritance and defaulting flow chart in FOSI.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-83">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>FOSI supports a rich formatting model, including tables, multi-column layout, headers and footers areas, and footnotes. Here is a simple example on how to set page margins.</p>
|
||
|
|
|
||
|
|
<pre><pagedesc>
|
||
|
|
<pagespec>
|
||
|
|
<topmarg nomdepth="1.5in">
|
||
|
|
<botmarg nomdepth="1.4in">
|
||
|
|
<leftmarg width="1.5in">
|
||
|
|
<rightmarg width="1.5in">
|
||
|
|
</pagespec>
|
||
|
|
</pagedesc>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>FOSI's formatting model is based on a sequence of <a href="#area" class="term">areas</a> being poured into the <a href="#layout_area" class="term">layout area</a>. Normally, block-level elements are positioned relative to the layout area. However, FOSI also provides a way of referencing the position of the parent element to create the appearance of a box model <a href="#FOSI_1997">[FOSI 1997]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote><!--errata: space removed after "T"-->The syntax for indents allows for specification <em class="ed">[..]</em> with respect to the text margin determined by the parent element's indent, for example, "@+2pi" or "@2pi". The delimiter "@" can be used to specify that the indent is relative to the text margin established by the element's parent, including any indenting that may have been applied.</blockquote>
|
||
|
|
|
||
|
|
<p>Here is an example of using this feature:</p>
|
||
|
|
|
||
|
|
<pre><e-i-c gi="BLOCKQUOTE">
|
||
|
|
<charlist>
|
||
|
|
<indent firstln="*" leftind="@+1em" rightind="@+1em">
|
||
|
|
</charlist>
|
||
|
|
</e-i-c>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>(In FOSI the indentation of the first line must be set explicitly to the special value <q><code class="value">*</code></q> to give it the same indentation as the rest of the paragraph.)</p>
|
||
|
|
|
||
|
|
<p>Elements are set to be block-level or inline with the <code>textbrk</code> category:</p>
|
||
|
|
|
||
|
|
<pre><e-i-c gi="BLOCKQUOTE">
|
||
|
|
<charlist>
|
||
|
|
<textbrk startln="1" endln="1">
|
||
|
|
</charlist>
|
||
|
|
</e-i-c>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="property">startln</code> and <code class="property">endln</code> properties indicate that there should be a line break before and after the element, respectively.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-84">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>Most commonly, FOSI style sheets are not directly associated with documents. Instead, the style sheet is associated with a DTD and documents refer to the DTD via the SGML doctype declaration. How the association between the DTD and the style sheet is established is implementation-dependent.</p>
|
||
|
|
|
||
|
|
<h3 id="h-85">Generated content</h3>
|
||
|
|
|
||
|
|
<p>FOSI has a developed system for generated content. Here is a simple example to add a string and a counter before an element:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The generated content is specified on the <code class="attribute">source</code> attribute of the <code class="property">usetext</code> element. The <q>\</q> characters are effectively quotes to delimit literal strings. The <code>chaptercounter</code> string is the name of a counter that is declared somewhere else.</p>
|
||
|
|
|
||
|
|
<p>To give the generated text a distinct style, the <code class="element">subchars</code> element can be used:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<h3 id="h-86">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>Not proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-87">FOSI in context</h3>
|
||
|
|
|
||
|
|
<p>FOSI was the first style sheet language to be standardized and has, as such, been a pioneer in the area of style sheet languages. The FOSI specification is lengthy and difficult to read (for example, it lacks a table of contents), but FOSI style sheets can be remarkably intuitive, concise and powerful.</p>
|
||
|
|
|
||
|
|
<p>Being a pioneer, FOSI shows innovation in many areas. Among the innovative features are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The use of SGML as a syntactic foundation. It may be argued that SGML was meant to create markup languages and not style sheet languages, but the FOSI syntax is still friendly both to authors and readers.</li>
|
||
|
|
|
||
|
|
<li>The inheritance/default mechanism. Though it is too complicated to be used in full, it is an early attempt to address the issue of multiple sources for stylistic information. As such it can be compared with cascading in CSS.</li>
|
||
|
|
|
||
|
|
<li>The simple, yet powerful selector mechanism. (The syntax, however, is only readable to the initiated.)</li>
|
||
|
|
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>In addition to being innovative, the specification has a reasonably restricted scope. The properties have been carefully selected to produce common typographic effects without being excessive.</p>
|
||
|
|
|
||
|
|
<p>On the negative side, some features described in the specification remained unimplemented and unused. Also, the number of implementations is limited and they support different subsets of the specification. For this reason, FOSI style sheets have a reputation for being non-interoperable <a href="#Harvey_2002">[Harvey 2002]</a>.</p>
|
||
|
|
|
||
|
|
<p>While the SGML community was waiting for DSSSL, FOSI actually did a decent job of printing SGML documents. If more efforts had gone into producing a more mature specification, trimming unused features, and addressing the issues of importance to the SGML community (e.g., multi-directional text) I believe FOSI would have prevailed.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-88"><a id="dsssl" name="dsssl">DSSSL</a></h2>
|
||
|
|
|
||
|
|
|
||
|
|
<p>When FOSI was adopted by CALS around 1989 it was perceived of as an interim solution <a href="#Kennedy_1997">[Kennedy 1997]</a>. The SGML community expected DSSSL <a href="#DSSSL_1996">[DSSSL 1996]</a> to be a permanent solution. For a permanent solution to be acceptable to the SGML community it would need to:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>be approved by ISO, the same organization that published the SGML standard; and</li>
|
||
|
|
|
||
|
|
<li>support multi-directional typography. For the CALS project this aspect of a style sheet language had not been important since all their documents were written in English.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The work on DSSSL started in 1986-87 overlapping with the final <q>tweaking</q> of SGML <a href="#Adler_2002">[Adler 2002]</a>. DSSSL became an ISO standard a decade later in 1996 <a href="#DSSSL_1996">[DSSSL 1996]</a>. Expectations were high when DSSSL was released. From <a href="#ManTech_1997">[ManTech 1997]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>It is our belief that the tremendous interest and anticipation for DSSSL in the SGML arena is not without reason, and we expect DSSSL to be the undisputed (likely and logical) specification of choice in SGML publishing for either paper or electronic delivery.</blockquote>
|
||
|
|
|
||
|
|
<p>DSSSL is the most complex specification reviewed in this thesis. The specification is difficult to read and has few examples. The DSSSL community, however, has produced a body of documentation on DSSSL and Paul Prescod's tutorial <a href="#Prescod_1997a">[Prescod 1997a]</a> has been especially helpful when reviewing DSSSL.</p>
|
||
|
|
|
||
|
|
<p>The DSSSL specification has two main parts: the style language and the transformation language. Only the style language is of concern in this dissertation, and the transformation language is not discussed.<span class="fn">The style language in DSSSL can also be used as a transformation language with an extension that Jade <a href="#Clark_1998">[Clark 1998]</a>, a DSSSL implementation, supports.</span>
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-89">Syntax</h3>
|
||
|
|
|
||
|
|
<p>DSSSL is based on the Scheme programming language and this is reflected in the syntax as well as functionality. Scheme is an example of a functional programming language that emphasizes the evaluation of expressions, rather than the execution of commands <a href="#Hutton_2002">[Hutton 2002]</a>. While most other style sheet languages are not Turing-complete DSSSL is a Turing-complete programming language. The DSSSL specification itself <a href="#DSSSL_1996">[DSSSL 1996]</a> downplays this:</p>
|
||
|
|
|
||
|
|
<blockquote>The DSSSL specification languages are declarative. They are not intended to be complete programming languages, although they contain constructs normally associated with such languages.</blockquote>
|
||
|
|
|
||
|
|
<p>(The term <q>DSSSL specification languages</q> refers to the <em>DSSSL style language</em> and the <em>DSSSL transformation language</em>.)</p>
|
||
|
|
|
||
|
|
<p>Jon Bosak explains how DSSSL is different from other programming languages <a href="#Bosak_1997">[Bosak 1997]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>It's a mistake to put DSSSL into the same bag as scripting languages. Yes, DSSSL is turing-complete; yes, it's a programming language. But a script language (at least the way I use the term) is procedural; DSSSL very definitely is not. DSSSL is entirely functional and entirely side-effect-free. Nothing ever happens in a DSSSL stylesheet. The stylesheet is one giant function whose value is an abstract, device-independent, nonprocedural description of the formatted document that gets fed as a specification (a declaration, if you will) of display areas to downstream rendering processes.</blockquote>
|
||
|
|
|
||
|
|
<p>Paul Prescod <a href="#Prescod_1997a">[Prescod 1997a]</a> expands on the implications of being <q>side-effect-free</q>:</p>
|
||
|
|
|
||
|
|
<blockquote>DSSSL's "expression language" is a full featured programming language that can do most of the things other programming languages can do. It is, however, a side-effect free language. That means that you cannot read or write files, open or close windows, assign to variables or do anything other than transform or format an SGML document.</blockquote>
|
||
|
|
|
||
|
|
<p>The choice of Scheme as the basis for DSSSL was lauded by Erik Naggum <a href="#Naggum_1994">[Naggum 1994]</a>:<span class="fn">The lack of normal capitalization in this quotation is the choice of the original author.</span></p>
|
||
|
|
|
||
|
|
<blockquote>the most obvious advantage of using Scheme is that the DSSSL team built on the decades of experience that went into Scheme, not having to invent their own language. the second most obvious advantage of using Scheme is that several of the large SGML vendors are already using languages from the LISP family in their products, if not Scheme itself, and it has an inordinately simple syntax that you learn in half an hour.</blockquote>
|
||
|
|
|
||
|
|
<p>There were few dissenters to the choice basing DSSSL on Scheme. Paul Prescod presented <q>a couple of heretic ideas</q> in a message posted to the DSSSL mailing list <a href="#dssslist">[dssslist]</a> in May 1997. One of the issues was the syntax <a href="#Prescod_1997a">[Prescod 1997a]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Syntax less like Lisp? Maybe a CSS-like syntax? I'm strongly supportive of the existing DSSSL syntax for the full DSSSL constituency, but I don't want to turn off Dirty Perl Hackers.</blockquote>
|
||
|
|
|
||
|
|
|
||
|
|
<p>At this point, however, DSSSL had already become an ISO standard and was not about to change.</p>
|
||
|
|
|
||
|
|
<p>Here is a simple DSSSL fragment:</p>
|
||
|
|
|
||
|
|
<pre>(element H1
|
||
|
|
(make paragraph
|
||
|
|
font-size: 14pt
|
||
|
|
font-weight: 'bold))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The above example declares that elements of type <code class="element">H1</code> are block-level with <code>14pt</code> bold text. In DSSSL terminology, a <q>Specification of a Sequence of Flow Objects</q> (a.k.a. <em>sosofo</em>) is returned by the <q>element construction rule</q> whenever an H1 element is encountered in the source document. The sequence specified in the above rule only contains one flow object, namely the <code>paragraph</code> flow object.</p>
|
||
|
|
|
||
|
|
<p>The rule above is composed of two parts:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>the <em>selector</em> part (described in the <q>Selectors</q> section below);</li>
|
||
|
|
|
||
|
|
<li>the <em>construct expression</em>, i.e. the <code>make</code> function which creates the flow object (described in the <q>Properties</q> section below).</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Two properties are set in the above construct expression: font-size and font-weight. The first property takes a length value (<code class="value">14pt</code>) and the second a keyword value (<code class="value">'bold</code>) Keyword values in DSSSL are preceded by <code>'</code> to indicate that they should not be evaluated further.</p>
|
||
|
|
|
||
|
|
<p>Since DSSSL is a programming language, common operations can be abstracted into a separate function. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>(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))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, the <code>create-heading</code> function is defined. It takes one argument, namely the size of the heading. By calling the function with different arguments, <code class="element">h1</code> and <code class="element">h2</code> elements will have different font sizes, but both will be bold-faced.</p>
|
||
|
|
|
||
|
|
<p>Although DSSSL's syntax is based on Scheme, DSSSL style sheets are technically SGML documents and need SGML's DOCTYPE to be recognized as such.</p>
|
||
|
|
|
||
|
|
<pre><!DOCTYPE style-sheet system "style-sheet.dtd" >
|
||
|
|
|
||
|
|
(element P
|
||
|
|
(make paragraph
|
||
|
|
first-line-start-indent: (* 2 (actual-font-size))))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<h3 id="h-90">Selectors</h3>
|
||
|
|
|
||
|
|
<p>Selectors in DSSSL are simple. Unlike CSS, much of DSSSL's logic for setting property values on a specific element is found in the declarations rather than in the selectors. Selectors form the first part of construction rules. There are five types of construction rules and each one is described below.</p>
|
||
|
|
|
||
|
|
<p>For a given element in a document, only one construction rule can <em>fire</em>. This is different from CSS where several selectors can match one element. Like CSS selectors, DSSSL construction rules have a <a href="#specificity" class="term">specificity</a> to determine which construction should be used.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h4 id="h-91">Element construction rule</h4>
|
||
|
|
|
||
|
|
<p>Element construction rules are the most common type of construction rules. Elements are selected based on their type:</p>
|
||
|
|
|
||
|
|
<pre>(element h1 (make paragraph ...))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Also, contextual selectors can be written as element construction rules:</p>
|
||
|
|
|
||
|
|
<pre>(element (ol li) (make paragraph ...))
|
||
|
|
(element (html body div h1) (make paragraph ...))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first selector in the above example selects <code class="element">li</code> elements that are children of <code class="element">ol</code> elements. The second selector lists three elements that must be immediate ancestors of the <code class="element">h1</code> element in order to match.</p>
|
||
|
|
|
||
|
|
<p>To write more complex queries DSSSL's <em>Standard Document Query Language</em> can be used along with conditional expressions. Here is an example that selects elements based on the existence of an attribute:</p>
|
||
|
|
|
||
|
|
<pre>(element NOTE
|
||
|
|
(if (not (node-list-empty? (attribute "WARNING")))
|
||
|
|
...
|
||
|
|
...))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, <code class="element">NOTE</code> elements with a <code class="attribute">WARNING</code> attribute are selected. Here is another example which selects all <code class="element">P</code> elements that are first children:</p>
|
||
|
|
|
||
|
|
<pre>(element P
|
||
|
|
(if (absolute-first-sibling? (current-node))
|
||
|
|
...
|
||
|
|
...))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>By combining the query language with the mathematical expressions offered by DSSSL, some interesting selectors can be constructed:</p>
|
||
|
|
|
||
|
|
<pre>(element TR
|
||
|
|
(if (= (modulo (child-number) 2)
|
||
|
|
0)
|
||
|
|
... ;even-row
|
||
|
|
...)) ;odd-row
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above will allow style sheets to set values on every other row in an HTML table.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h4 id="h-92">Root construction rule</h4>
|
||
|
|
|
||
|
|
<p>The root construction rule selects the root element, independent of its name. Here is an example:</p>
|
||
|
|
|
||
|
|
<pre>(root (sequence
|
||
|
|
font-family-name: serif-font-family))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
|
||
|
|
<h4 id="h-93">Default construction rule</h4>
|
||
|
|
|
||
|
|
<p>The default construction rule is used to set rules for all properties. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>(default (sequence
|
||
|
|
font-family-name: serif-font-family))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
|
||
|
|
<h4 id="h-94">Query construction rule</h4>
|
||
|
|
|
||
|
|
<p>The query construction rule is not supported by the leading DSSSL implementation (Jade <a href="#Clark_1998">[Clark 1998]</a>) and therefore is not widely used.<span class="fn">The <em>query construction rule</em> should not be confused with the <em>core query language</em> which has been implemented and is in use.</span> I have found only one code example (from [Martin 1999]) that uses query construction rules:</p>
|
||
|
|
|
||
|
|
<pre>(query q-class 'pi )
|
||
|
|
(make paragraph
|
||
|
|
literal "Processing instruction: "
|
||
|
|
(node-property 'system-data
|
||
|
|
(current-node))
|
||
|
|
)
|
||
|
|
)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The above code would select all processing instructions (<code>pi</code>) in a document and print their names preceded by the string <q>Processing instruction</q>. Prescod states that <q>... you can use conditional expressions to do basically the same things with more work</q> [Prescod 1997a]. See <em>Element construction rule</em> above for some examples.</p>
|
||
|
|
|
||
|
|
<h4 id="h-95">ID construction rule</h4>
|
||
|
|
|
||
|
|
<p>The ID construction rule is used to select elements based on their ID. Consider this HTML example:</p>
|
||
|
|
|
||
|
|
<pre><P ID="x678y">An S-expression is a list
|
||
|
|
of function calls and their arguments.</P>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="element">P</code> element in the example above can be selected with this ID construction rule:</p>
|
||
|
|
|
||
|
|
<pre>(id ("x678y")
|
||
|
|
(make paragraph))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<h3 id="h-96">Properties</h3>
|
||
|
|
|
||
|
|
|
||
|
|
<p>DSSSL provides a comprehensive set of more than 200 properties (called <em>characteristics</em> in DSSSL terminology) to describe the rendering of content.<span class="fn">This author has counted 213 properties altogether, excluding properties only used on the math flow objects.</span></p>
|
||
|
|
|
||
|
|
<p>As in other style sheet languages, not all properties apply to all elements. In DSSSL, each type of <em>flow object</em> accepts a subset of the properties. For example, the <code class="fo">paragraph</code> flow object accepts all font-related properties (amongst others) while the <code class="fo">simple-page-sequence</code> flow object accepts properties to set page margins. Conceptually, DSSSL flow objects are similar to XSL formatting objects discussed in the previous chapter, but there is no XML syntax for DSSSL flow objects.</p>
|
||
|
|
|
||
|
|
<p>In Table 5, the DSSSL flow objects are listed along with the properties they accept. It is beyond the scope of this thesis to describe the flow objects and associated properties in more detail, but the table will give an indication of the complexity of DSSSL. A question mark after a property name indicates that the property only accepts a true/false value.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-5">
|
||
|
|
<p class="caption">DSSSL's flow objects and associated properties.</p>
|
||
|
|
|
||
|
|
<table summary="" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Flow object</th>
|
||
|
|
<th>Properties</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-86.htm">Sequence</a></td>
|
||
|
|
<td><em>none, this is a container for other flow objects</em></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-87.htm">Display-group</a></td>
|
||
|
|
<td>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?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-88.htm">Simple-page-sequence</a></td>
|
||
|
|
<td>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</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-89.htm">Page-sequence</a></td>
|
||
|
|
<td>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</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-90.htm">Column-set-sequence</a></td>
|
||
|
|
<td>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?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-91.htm">Paragraph</a></td>
|
||
|
|
<td>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?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-92.htm">Paragraph-break</a></td>
|
||
|
|
<td><em>The first-line-start-indent characteristic is applicable to the line following a paragraph-break flow object, and the last-line-end-indent characteristic is applicable to the line preceding a paragraph-break flow object.</em></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-93.htm">Line-field</a></td>
|
||
|
|
<td>field-width, field-align, writing-mode, inhibit-line-breaks?, break-before-priority, break-after-priority</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-94.htm">Sideline</a></td>
|
||
|
|
<td>sideline-side, sideline-sep, color, layer, line-cap, line-dash, line-thickness, line-repeat, line-sep</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-95.htm">Anchor</a></td>
|
||
|
|
<td>anchor-keep-with-previous?, display?, span, span-weak?, inhibit-line-breaks?, break-before-priority, break-after-priority</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-96.htm">Character</a></td>
|
||
|
|
<td>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</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-97.htm">Leader</a></td>
|
||
|
|
<td>length, truncate-leader?, align-leader?, min-leader-repeat, inhibit-line-breaks?, break-before-priority, break-after-priority</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-98.htm">Embedded-text</a></td>
|
||
|
|
<td>direction, language, country, inhibit-line-breaks?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-99.htm">Rule</a></td>
|
||
|
|
<td>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?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-100.htm">External-graphic</a></td>
|
||
|
|
<td>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</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-101.htm">Included-container-area</a></td>
|
||
|
|
<td>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</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-102.htm">Score</a></td>
|
||
|
|
<td>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</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-103.htm">Box</a></td>
|
||
|
|
<td>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?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-104.htm">Side-by-side</a></td>
|
||
|
|
<td>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?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-105.htm">Side-by-side-item</a></td>
|
||
|
|
<td>start-indent, end-indent, side-by-side-pre-align, follows, side-by-side-post-align</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-106.htm">Glyph-annotation</a></td>
|
||
|
|
<td>annotation-glyph-placement, annotation-glyph-style, inhibit-line-breaks?, break-before-priority, break-after-priority</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-107.htm">Alignment-point</a></td>
|
||
|
|
<td><em>none</em></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-108.htm">Aligned-column</a></td>
|
||
|
|
<td>display-alignment, start-indent, end-indent</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-109.htm">Multi-line-inline-note</a></td>
|
||
|
|
<td>open, close, inline-note-line-count, inline-note-style, inhibit-line-breaks?, break-before-priority, break-after-priority</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-110.htm">Emphasizing-Mark</a></td>
|
||
|
|
<td>mark, mark-distribution, mark-style, inhibit-line-breaks?, break-before-priority, break-after-priority</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>Flow object</th>
|
||
|
|
<th>Properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-112.htm#AEN11597">Table</a></td>
|
||
|
|
<td>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?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-112.htm#AEN11772">Table-part</a></td>
|
||
|
|
<td>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?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-112.htm#AEN11848">Table-column</a></td>
|
||
|
|
<td>column-number, n-columns-spanned, width, display-alignment, start-indent, end-indent</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-112.htm#AEN11926">Table-row</a></td>
|
||
|
|
<td><em>(none, this is a container for other flow objects)</em></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-112.htm#AEN11934">Table-cell</a></td>
|
||
|
|
<td>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?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-112.htm#AEN12060">Table-border</a></td>
|
||
|
|
<td>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</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>Flow object</th>
|
||
|
|
<th>Properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-113.htm#AEN12138">Scroll</a></td>
|
||
|
|
<td>filling-direction, writing-mode, background-color, background-layer, background-tile, start-margin, end-margin</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-113.htm#AEN12176">Multi-mode</a></td>
|
||
|
|
<td>multi-modes, principal-mode-simultaneous?</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-113.htm#AEN12198">Flow</a></td>
|
||
|
|
<td>destination</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><a href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/h3-113.htm#AEN12206">Marginalia</a></td>
|
||
|
|
<td>marginalia-sep, marginalia-side, marginalia-keep-with-previous?</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>Most properties in DSSSL are relative to writing direction, rather than being absolute. For example, the DSSSL margin properties on the <code>paragraph</code> flow object are called <code class="property">start-margin</code> and <code class="property">end-margin</code> rather than the <code class="property">margin-left</code> and <code class="property">margin-right</code> that CSS uses. However, page margins are set with absolute properties, including <code class="property">left-margin</code> and <code class="property">right-margin</code>.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-97">Values and units</h3>
|
||
|
|
|
||
|
|
<p>DSSSL offers a simple set of of values and units also found in other style sheet languages, as well as the ability to let values be lists and advanced expressions.</p>
|
||
|
|
|
||
|
|
<p>The most frequently used DSSSL values are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>keywords (e.g. <code class="value">'bold</code>): keywords start with an apostrophe (') to indicate that no further processing should be performed;</li>
|
||
|
|
|
||
|
|
<li>boolean values: true/false are represented by <code class="value">#t</code> and <code class="value">#f</code>, respectively; and</li>
|
||
|
|
|
||
|
|
<li>length values: the base length unit for DSSSL is the meter, <code class="unit">m</code>. Pre-defined derived units are: <code class="unit">cm</code>, <code class="unit">mm</code>, <code class="unit">in</code>, <code class="unit">pt</code>, <code class="unit">pica</code>.
|
||
|
|
</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Here is a simple example of a value and unit in DSSSL:</p>
|
||
|
|
|
||
|
|
<pre>(element H1
|
||
|
|
(make paragraph
|
||
|
|
font-size: 20pt))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, the font size of <code class="element">H1</code> elements is set to a fixed size.</p>
|
||
|
|
|
||
|
|
<p>Notably missing from the list of units are relative units, e.g. the <code class="unit">em</code> unit used in FOSI (and later in CSS). Jon Bosak presents one way of supporting the <code class="unit">em</code> unit in DSSSL <a href="#Bosak_1996a">[Bosak 1996a]</a>:</p>
|
||
|
|
|
||
|
|
<pre>(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%)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, one <code class="unit">em</code> is set to be an absolute measurement equal to the height of a <em>base font</em>. The size of the base font depends on the <code>visual-acuity</code> variable. This definition of <code class="unit">em</code> makes it an absolute unit.</p>
|
||
|
|
|
||
|
|
<p>Typically, however, the <code class="unit">em</code> unit is relative to the font size of the element itself or the font size of the parent element. This can also be expressed in DSSSL. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>(element H1
|
||
|
|
(make paragraph
|
||
|
|
font-size: (* 2 (inherited-font-size))))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The expression <code class="expression">(* 2 (inherited-font-size))</code> refers to the font size inherited from the parent element and multiplies it by two before assigning it to the <code class="element">H1</code> element. This example shows that DSSSL turns to expressions for quite simple operations and that expressions can be very powerful. Expressions in DSSSL extend well beyond even the most advanced units. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>(element H1
|
||
|
|
(make paragraph
|
||
|
|
font-size: (+ 4pt (inherited-font-size))))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above sets the element's font size to be <code>4pt</code> larger than the parent element's font size. These kinds of values are not possible without expressions.</p>
|
||
|
|
|
||
|
|
<h3 id="h-98">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>DSSSL has a simple model for value propagation. Properties are classified as inherited or non-inherited. All inherited properties have an <code class="value">initial</code> value, and all non-inherited properties have a <code class="value">default</code> value which serves the same purpose. In general, DSSSL and CSS agree on on which properties are inherited.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-99">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>DSSSL has a rich formatting model with emphasis on producing printed output. A DSSSL style sheet can specify multi-column layout, footnotes, sidenotes, tables and other advanced constructs. Central to the DSSSL formatting model is the notion of <a href="#flow_object" class="term">flow objects</a> and <a href="#area" class="term">areas</a>.</p>
|
||
|
|
|
||
|
|
<h4 id="h-100">Flow objects</h4>
|
||
|
|
|
||
|
|
<p>DSSSL defines the visual appearance of a formatted document in terms of property values attached to a tree of <a href="#formatting_object" class="term">formatting objects</a>, called <em>flow objects</em> in DSSSL. The first step in the DSSSL formatting process is to construct the flow object tree from the source document. This process is a tree transformation process, and it is no coincidence that DSSSL is also a tree transformation language.</p>
|
||
|
|
|
||
|
|
<p>DSSSL defines around 35 types of flow objects (including flow objects for tables and online display, excluding mathematics). DSSSL's flow objects and their associated properties are listed in the <q>Properties</q> section above. Two commonly used flow objects are <code class="fo">paragraph</code> (seen in previous examples) and <code class="fo">simple-page-sequence</code>. Below is a simple example of using <code class="fo">simple-page-sequence</code> to set margins on pages:</p>
|
||
|
|
|
||
|
|
<pre>(root
|
||
|
|
(make simple-page-sequence
|
||
|
|
left-margin: 1in
|
||
|
|
right-margin: 1in
|
||
|
|
top-margin: 1in
|
||
|
|
bottom-margin: 1in
|
||
|
|
(process-children)))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example is from [Germán 1997]. More advanced flow objects allow content, for example, to be presented in a multi-column layout, to appear in side notes and to generate footnotes. One missing feature is that of floating images with surrounding text.</p>
|
||
|
|
|
||
|
|
<p>A significant amount of work has gone into DSSSL to make sure the flow objects can support multi-directional text.</p>
|
||
|
|
|
||
|
|
<h4 id="h-101">Areas</h4>
|
||
|
|
|
||
|
|
<p>The second part of the DSSSL formatting process is to produce a sequence of rectangular <a href="#area" class="term">areas</a> from the tree of flow objects. The DSSSL specification claims to not fully describe areas (<q>The nature of these areas is not fully specified by this International Standard</q> [DSSSL 1996]), but they seem to be described at the level of detail comparable with other style sheet languages.</p>
|
||
|
|
|
||
|
|
<p>Areas have a fixed width and height. There are two types of areas: <a href="#inline_area" class="term">inline areas</a> that are part of lines, and <a href="#display_area" class="term">display areas</a> that are not part of lines. Typically, display areas are block-level containers for other content.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-103">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>Neither SGML nor the DSSSL specification describe how to link style sheets to source documents. Typically, DSSSL implementations look for SGML processing instructions in the source document. For example, Jade <a href="#Clark_1998">[Clark 1998]</a> recognizes two types of processing instructions:</p>
|
||
|
|
|
||
|
|
<pre> <?stylesheet href="<i>sysid</i>" type="text/dsssl">
|
||
|
|
<?dsssl <i>sysid</i>>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, <code>sysid</code> is a <em>system identifier</em> which typically is a file name.</p>
|
||
|
|
|
||
|
|
<h3 id="h-104">Generated content</h3>
|
||
|
|
|
||
|
|
<p>DSSSL has strong functionality for generated content. Through expressions, several chunks of different styles can be associated with any element. Here is a simple example from [Prescod 1997a]:</p>
|
||
|
|
|
||
|
|
|
||
|
|
<pre>(element note (make paragraph font-size: 12pt
|
||
|
|
(make sequence
|
||
|
|
font-weight: 'bold
|
||
|
|
(literal "Warning:"))
|
||
|
|
(process-children)))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The above example adds the string <q><span style="font-style: normal; font-weight: bold">Warning</span></q> before the content of the <code>note</code> element.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-105">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>Not proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-106">DSSSL in context</h3>
|
||
|
|
|
||
|
|
<p>DSSSL was received enthusiastically by SGML experts when released in 1996. Erik Naggum wrote <a href="#Naggum_1994">[Naggum 1994]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>this is the best thing that happened to the world of SGML since SGML itself, maybe more than that <em class="ed">[...]</em> this is good stuff. this deserves to become an International Standard <em class="ed">[...]</em> DSSSL is a solid piece of work.</blockquote>
|
||
|
|
|
||
|
|
<p>However, the implementation experience and actual use of DSSSL has been limited <a href="#DuCharme_2001">[DuCharme 2001]</a>. There are, I believe, two major reasons for this: the specification itself and the outside world.</p>
|
||
|
|
|
||
|
|
<p>First, the specification itself is difficult to read unless you are an SGML expert. The terminology used in the specification is precise, but terse. One example of DSSSL terminology is the acronym <em>sosofo</em>, which expands to <em>specification of sequence of flow objects</em>.</p>
|
||
|
|
|
||
|
|
<p>Also, the Scheme-based language used to express style sheets is unfriendly to non-programmers. The language uses nested parentheses extensively and in order to learn Scheme you need to <q>get over your fear of parentheses</q> <a href="#Radestock_2004">[Radestock 2004]</a>. Some SGML experts did not consider the syntax to be a problem <a href="#Milowski_1997">[Milowski 1997]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>The fact that perl succeed with a rather cryptic language syntax suggests that it is not the syntax but what the language can do that makes something succeed. If I can transform my documents with a few lines of DSSSL code with parenthesis galour, I win over some other language in which it takes me many more! (not intended to rhyme) This should be our goal for extending DSSSL–simple clear descriptions of what should be done–not a change of syntax.</blockquote>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>Second, when DSSSL emerged in 1996 after ten years in development the outside world had changed. Printing SGML documents was no longer the main challenge for structured documents. Instead, HTML and the web had arrived but DSSSL was not targeted for the web. It could not could not express common HTML presentations (e.g. the styling of visited and active links). A DSSSL profile targeted for the web was developed (called <q>DSSSL Lite</q>, which is discussed in the next chapter) but did not gain much momentum.</p>
|
||
|
|
|
||
|
|
<p>Measured by usage, DSSSL did not succeed as a style sheet language. However, the DSSSL specification has been influential for other style sheet languages, especially in the area of multi-directional layout. The DSSSL community has since developed XSL <a href="#XSL_2001">[XSL 2001]</a> inside W3C.</p>
|
||
|
|
|
||
|
|
<h2 id="h-107"><a id="p93" name="p93">P94</a></h2>
|
||
|
|
|
||
|
|
|
||
|
|
<p>The P language was developed by Vincent Quint and Irène Vatton as part of their long-standing research on structured documents at INRIA in Grenoble <a href="#Thot_2001">[Thot 2001]</a>. Together, the <q>T</q> language (for Transformation), the <q>S</q> (for Structure) and <q>P</q> (for Presentation) form the <em>Thot languages</em>. These are supported by a software library known as the <em>Thot library</em>. The purpose of the Thot library is to facilitate the creation of <q>document centered applications based on the concept of structured active documents</q>.</p>
|
||
|
|
|
||
|
|
<p>The work on Thot started in 1983 and initial results were first published in 1986. Several industry collaborations followed and Thot formed the core of several commercial products, including Grif and Symposia. In 1995, INRIA became the European host of the World Wide Web Consortium, and Vincent Quint and Irène Vatton joined as W3C staff in 1996. The work on Thot continued in W3C's Amaya Web editor which uses the Thot library. Amaya is a test-bed application for W3C specifications, and CSS, XHTML, SVG, MathML and XML are experimentally supported by Amaya. Typically, Amaya adds support for a new specification by translating the external language into one of the internal languages (P, S or T). Amaya's formatter is built around the P language and the default formatting of the markup languages supported by Amaya is described in P. Also, Amaya supports CSS by generating P rules that are subsequently interpreted by the formatter.</p>
|
||
|
|
|
||
|
|
<p>In order to support CSS in Amaya it was necessary to extend the P language in some areas. For example, all CSS length units are now supported in P and a set of properties have been added to support padding, borders and margins around elements. For research purposes, it is interesting to study the P language before the influx of CSS and the web. The discussion below is therefore based on the P language as it existed in 1994 and is referred to as <em>P94</em> <a href="#Quint_1994">[Quint 1994]</a>.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-108">Syntax</h3>
|
||
|
|
|
||
|
|
<p>Style sheets in P94 are called <em>presentation schema</em>. They have two main parts: <a href="#declaration" class="term">declarations</a> and <a href="#rule" class="term">rules</a>. Here is a small, but quite advanced, style sheet in P94:</p>
|
||
|
|
|
||
|
|
<pre>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
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first line declares what kind of documents the style sheet applies to. The style sheet above applies to <code>HTML</code> documents. The <q>HTML</q> string is arbitrary; it is the job of the Thot system to associate the style sheet with the document.</p>
|
||
|
|
|
||
|
|
<p>The above example only has one <a href="#declaration" class="term">declaration</a>; the <code>COUNTERS</code> section specifies that the counter called <code>H2Counter</code> is set to zero when an <code class="element">H1</code> element is found, and is incremented by one when an <code class="element">H2</code> element is found in a pre-order traversal of the document tree. (The counter is only declared in the above style sheet, and not actually used.)</p>
|
||
|
|
|
||
|
|
<p>In the above example, there are two sections containing <a href="#rule" class="term">rules</a>: <code>DEFAULT</code> and <code>RULES</code>. A block of rules starts with the word <code>BEGIN</code> and ends with <code>END;</code>. The first block contains two rules. One specifies that font size should be inherited from the parent element, and the second rule specifies that the font weight should be inherited from the parent element. Rules in the <code>DEFAULT</code> section apply to all elements unless overridden by other rules in the <code>RULES</code> section. In the example above, the <code>RULES</code> section contains rules that only apply to <code class="element">H2</code> elements. The first specifies that the font size should be <code>4pt</code> larger than the parent element's font size, and the second sets the font weight to bold.</p>
|
||
|
|
|
||
|
|
<p>P94 is a case-insensitive language. By convention, properties and values are written in initial-cap, while other parts of the language are written in uppercase.</p>
|
||
|
|
|
||
|
|
<p>In several ways, the syntax of P94 is similar to the Pascal programming language <a href="#Munson_1996">[Munson 1996]</a>. Emphasis is put on declaring values before using them (e.g. counters), and on enforcing a block structure (the Pascal keywords <code>BEGIN</code> and <code>END</code> are used).</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-109">Selectors</h3>
|
||
|
|
|
||
|
|
<p>As in DSSSL, selectors in P94 are simple. Only element names and attribute names/values can be used as selectors. Here is a simple example:</p>
|
||
|
|
|
||
|
|
<pre>H1: Size: 20 pt;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The selector in the above example is <code class="selector">H1</code> which selects all <code class="element">H1</code> elements in the document and sets the font size to 20 points. (The <code>BEGIN</code> and <code>END</code> keywords used in the previous examples can be omitted since there is only one declaration associated with the <code class="selector">H1</code> selector.)</p>
|
||
|
|
|
||
|
|
<p>Selectors based on attribute names/values are written in the ATTRIBUTES section of the style sheet. For example, to set the font size of all elements with a <code class="attribute">warning</code> attribute one could write:</p>
|
||
|
|
|
||
|
|
<pre>ATTRIBUTES
|
||
|
|
warning:
|
||
|
|
Size: 25 pt;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>More complex queries can also be written in P94 but the logic is placed in declarations rather than in the selector. For example, to set values on all <code class="element">LI</code> elements within an OL element, one could write:</p>
|
||
|
|
|
||
|
|
<pre>LI: BEGIN
|
||
|
|
if within OL Size: 10 pt;
|
||
|
|
END;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-111">Properties</h3>
|
||
|
|
|
||
|
|
<p>P94 has two types of rules, those containing a <em>presentation parameter</em> and those containing a <em>presentation function</em>. Presentation parameters are similar to properties in CSS and are discussed in this section. Presentation functions are used to create <em>presentation boxes</em> and are discussed in the section on <q>Generated content</q> below.</p>
|
||
|
|
|
||
|
|
<p>Table 6 gives an overview of the properties in P94.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-6">
|
||
|
|
<p class="caption">Properties of P94.</p>
|
||
|
|
|
||
|
|
<table summary="" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>P94 property</th>
|
||
|
|
<th>Corresponding CSS functionality</th>
|
||
|
|
<th>Comment</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>LineSpacing</td>
|
||
|
|
<td>line-height</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Indent</td>
|
||
|
|
<td>text-indent</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Adjust</td>
|
||
|
|
<td>text-align</td>
|
||
|
|
<td>The Adjust property also accepts a <code>LeftWithDots</code> value to generate leaders.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Justify</td>
|
||
|
|
<td>text-align</td>
|
||
|
|
<td>Boolean property</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Break</td>
|
||
|
|
<td>white-space: nowrap</td>
|
||
|
|
<td>The Break property is boolean and tells whether the element can be broken across several lines/pages.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>NoBreak1</td>
|
||
|
|
<td>widows</td>
|
||
|
|
<td>The NoBreak1 property also accepts a length as a value (in addition to an integer).</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>NoBreak2</td>
|
||
|
|
<td>orphans</td>
|
||
|
|
<td>The NoBreak2 property also accepts a length as a value (in addition to an integer).</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Gather</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>The <code class="property">Gather</code> property was introduced to handle large documents. Thot formats only a part of the document, roughly the part that is displayed on the screen. When the user moves around in the document, a new part is formatted and the resources used by the part that is no longer displayed are released. The issue is to decide how much has to be formatted when something new has to be displayed. For example, by associating the <code class="property">Gather</code> property with an equation, one can tell the formatter <q>when you start formatting an equation, format it all or don't format it at all, but do not stop in the middle</q>. This functionality is not found in any other style sheet language discussed in this thesis.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Visibility</td>
|
||
|
|
<td>visibility</td>
|
||
|
|
<td>Levels of visibility can be attached to elements to selectively hide elements below a certain threshold.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Size</td>
|
||
|
|
<td>font-size</td>
|
||
|
|
<td>The legal values for the <code class="property">Size</code> property are discussed in the <q>Length units</q> section below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Font</td>
|
||
|
|
<td>font-family</td>
|
||
|
|
<td>Only three values are accepted: <code class="value">Times</code>, <code class="value">Helvetica</code>, and <code class="value">Courier</code>.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Style</td>
|
||
|
|
<td>font-style/font-weight</td>
|
||
|
|
<td>Style accepts the following keywords: <code class="value">Roman</code>, <code class="value">Bold</code>, <code class="value">Italics</code>, <code class="value">BoldItalics</code>, <code class="value">Oblique</code>, <code class="value">BoldOblique</code>.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Underline</td>
|
||
|
|
<td>text-decoration</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Thickness</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>Describes the thickness of the underlining and can either be <code class="value">thick</code> or <code class="value">thin</code>.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Depth</td>
|
||
|
|
<td>z-index</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Content</td>
|
||
|
|
<td>content</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>VertRef</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>Positions the <q>reference axis</q>, which is used for positioning boxes, vertically.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>HorizRef</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>Positions the <q>reference axis</q>, which is used for positioning boxes, horizontally.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>VertPos</td>
|
||
|
|
<td>margin/padding</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>HorizPos</td>
|
||
|
|
<td>margin/padding</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Height</td>
|
||
|
|
<td>height</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>Width</td>
|
||
|
|
<td>width</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>With just over 20 properties, P94's property set is much smaller than those of FOSI or DSSSL. Still, P94 is a highly functional style sheet language which, in several respects, offers more functionality than the other languages. There are several explanations for this seeming discrepancy. First, P94 often combines into one property functionality that others split into several properties. For example, the <code class="property">Style</code> property in P94 describes both font weight and font posture. Second, P94's constraint-based box model is able to reduce the number of properties by expressing quite complex geometrical relationships as values. Third, some property-intensive functionality offered by other languages is not available in P94. Examples include element borders (beyond simple horizontal and vertical rules), foreground and background colors, word- and letter-spacing.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-112">Values and units</h3>
|
||
|
|
|
||
|
|
<p>Values and units in P94 can be divided into a traditional part and a novel part. The traditional part comprises the keywords and length units that are similar to those used in other style sheet languages. The novel part is made up of the values that are able to express <a href="#constraint" class="term">constraints</a> between elements and the <em>elastic values</em>.</p>
|
||
|
|
|
||
|
|
<h4 id="h-113">Length units</h4>
|
||
|
|
|
||
|
|
<p>Length units (called <em>distance units</em> in P94) can be absolute or relative. The absolute length units are: centimeters (<code class="unit">cm</code>), inches (<code class="unit">in</code>) and typographic points (<code class="unit">pt</code>, 1/72 inch).</p>
|
||
|
|
|
||
|
|
<p>P94 also has a relative length unit similar to the <code class="unit">em</code> unit in FOSI and CSS. This is expressed with a number without a unit identifier:</p>
|
||
|
|
|
||
|
|
<pre>H2: Width: 20;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above sets the width of <code class="element">H2</code> elements to be 20 times the height of the current font.</p>
|
||
|
|
|
||
|
|
<p>On the <code class="property">Size</code> property, which describes the font size of the element, a unit-less number has another meaning. <code class="property">Size</code> accepts an integer value between 1-6 (inclusive) which points into a table of font sizes kept by the application.</p>
|
||
|
|
|
||
|
|
<pre>H2: Size: 3;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
|
||
|
|
<p>P94 has no concept of initial values. The application is responsible for setting an initial value if no default value exists.</p>
|
||
|
|
|
||
|
|
<h4 id="h-116">Constraints</h4>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Constraints form an important part of values in P94. Most style sheet languages are able to express some form of constraints. For example, one simple constraint can set the font size of an element to be 50% larger than the parent element.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Another kind of constraint supported by P94 concerns the maximum and minimum values which is accepted on the <code class="property">Size</code> property. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>LI:
|
||
|
|
Size : Enclosing - 2pt Min 7;
|
||
|
|
H1:
|
||
|
|
Size : Enclosing + 2 Max 5;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first rule in the example above states that the font size of <code class="property">LI</code> elements is 2 points less than that of the parent element, but that it may not be less than 7 points. The second rule states that the font size of H1 elements should be two sizes larger than the surrounding text, but not larger than 5. In both examples, the values that come after <code class="value">Min</code>/<code class="value">Max</code> takes the same unit as the value before <code class="value">Min</code>/<code class="value">Max</code>.</p>
|
||
|
|
|
||
|
|
<h4 id="h-118">Elastic values</h4>
|
||
|
|
|
||
|
|
<p>P94 has a notion of <q>authorizing the user to choose dimensions</q> for certain elements. Length values can be influenced by the users and are called <em>elastic values</em>. The <code class="property">Width</code> and <code class="property">Height</code> properties accept the <code class="value">Userspecified</code> keyword in addition to a length value.</p>
|
||
|
|
|
||
|
|
<pre>GraphElem: BEGIN
|
||
|
|
Width: 2 cm Userspecified;
|
||
|
|
END
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example expresses that <code class="element">GraphElem</code> elements have a 2cm width by default, but users may change the width.</p>
|
||
|
|
|
||
|
|
<p>Elastic values can be considered a form of cascading; one style sheet explicitly hands over control of some aspect of document formatting to the user. However, elastic values are only used in a limited manner in P94. The control that the style sheet defers to the user is meant to be filled in by user interaction rather than a separate user style sheet.</p>
|
||
|
|
|
||
|
|
<h3 id="h-119">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>P94 offers three mechanisms to avoid setting all values for all properties for all elements. First, the <code>DEFAULT</code> section of the style sheet contains declarations used by default. Second, inheritance can transfer values for textual properties from nearby elements. Third, geometrical constraints can be established between boxes and thereby transfer values from one box to another.</p>
|
||
|
|
|
||
|
|
<p>Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>DEFAULT
|
||
|
|
Depth: 0;
|
||
|
|
Size: Enclosing =;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code>DEFAULT</code> section in the example above contains two rules. The first rule sets the default value of <code class="property">Depth</code> to be zero. The second rule sets the default size of all elements to be equal to the size of the parent (<code class="value">Enclosing</code> in P94 terminology) element. That is, the rule declares that the <code class="property">Size</code> property is inherited.</p>
|
||
|
|
|
||
|
|
<p>P94 relies less on inheritance of property values than most other style sheet languages. No values are inherited automatically and inheritance can only be specified for certain properties (<code class="property">Justificy</code>, <code class="property">LineSpacing</code>, <code class="property">Font</code>, <code class="property">Style</code>, <code class="property">Size</code>, <code class="property">Visibility</code>, and <code class="property">Indent</code>). Values can be inherited from the parent element (<code class="value">Enclosing</code>) as well as the child element (<code class="value">Enclosed</code>) and the older sibling (<code class="value">Previous</code>).</p>
|
||
|
|
|
||
|
|
<p>Inheritance in P94 follows the logical structure of elements, therefore, generated content cannot transmit any values by inheritance.</p>
|
||
|
|
|
||
|
|
<p>Here is an example of inheriting a value from a child element:</p>
|
||
|
|
|
||
|
|
<pre>RULES
|
||
|
|
PRE: Width: Enclosed . Width;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the width of <code class="element">PRE</code> elements is set be the width of its enclosed box. That is, the width of the <code class="element">PRE</code> element will be determined by its content, so-called <a href="#inside-out_formatting" class="term">inside-out formatting</a>. While the <code class="element">PRE</code> element doesn't have any child elements in the logical structure of elements, the contents of the <code class="element">PRE</code> element form a box which can be referred to.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Geometrical constraints between boxes is the third type of value propagation mechanism in P94. This mechanism uses some of the same keywords (<code class="value">Enclosing</code>, <code class="value">Enclosed</code>, <code class="value">Previous</code>) as the inheritance mechanism and, therefore, can be confusing. While inheritance only works for textual properties, geometrical constraints are used to position boxes. Also, geometrical constraints can refer to <code class="value">Next</code> and <code class="value">Referred</code> elements.<span class="fn">In a description of the P language from 1993 <a href="#Grif_1993">[Grif 1993]</a>, the value is spelt <code class="value">Refered</code>. This spelling mistake is remarkably similar to the spelling of <code>Referer</code> in HTTP, with the exception that the mistake remains in HTTP to this day <a href="#HTTP_1999">[HTTP 1999]</a>.</span>
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>For an example of a geometrical constraint, see the <em>Visual formatting model</em> below.</p>
|
||
|
|
|
||
|
|
<h3 id="h-120">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>The P94 formatting model is based on a hierarchy of rectangular boxes. There are three types of boxes:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>boxes corresponding to elements in the document structure;</li>
|
||
|
|
|
||
|
|
<li>presentation boxes that are generated; and</li>
|
||
|
|
|
||
|
|
<li>page layout boxes.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Boxes corresponding to elements in the document structure form a tree structure identical to the structure of the document. This tree expresses the inclusion relationships between the boxes: a box includes all the boxes of its subtree.</p>
|
||
|
|
|
||
|
|
<p>Presentation boxes represent elements which are not found in the logical structure of the document but which are added based on the existence of logical elements. This corresponds roughly to the pseudo-elements in CSS. For example, a presentation box can be used to add <q>Chapter</q> before each <code class="element">H1</code> element. See the section on Generated Content.</p>
|
||
|
|
|
||
|
|
<p>Page layout boxes are boxes created implicitly by the page layout rules. These rules indicate how the contents of a structured element must be broken into lines and pages. In contrast to presentation boxes, these line and page boxes do not depend on the logical structure of the document but, rather, on the physical constraints of the output devices: character size, height and width of the window on the screen or of the sheet of paper.</p>
|
||
|
|
|
||
|
|
<p>The formatting model P94 supports advanced formatting features such as footnotes, change marks, tables, and mathematics. One missing feature is that of floating images with text around them.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-121">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>In the S language, a default style sheet can be specified for each type of document. When the user creates a new document of that type, the editor uses the default style sheet. The user can specify another style sheet, and the editor will reformat the document accordingly. When the user saves the document, the current style sheets are recorded in the document itself.</p>
|
||
|
|
|
||
|
|
<h3 id="h-122">Generated content</h3>
|
||
|
|
|
||
|
|
<p>P94 has rich functionality to generate content in addition to the content in the document. For example, here is the code to add the text <q>Chapter x:</q> before all <code class="element">H1</code> elements (where <q>x</q> is replaced by an incrementing chapter number):</p>
|
||
|
|
|
||
|
|
<pre>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;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The box to be generated before each H1 element is described in the <code>BOXES</code> section in the above example. The creation of the box is initiated by the presentation function <code class="function">CreateBefore</code>.</p>
|
||
|
|
|
||
|
|
<p>In the example above, the chapter number is added before every <code class="element">H1</code> element. P94 offers a set of logical expressions to indicate that the presentation function should only be called in certain conditions. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>Column:
|
||
|
|
BEGIN
|
||
|
|
CreateBefore (VertRule);
|
||
|
|
IF LAST CreateAfter(VertRule)
|
||
|
|
Width: 2.8cm;
|
||
|
|
Height: Enclosed.Height;
|
||
|
|
VertPos: Top = Enclosing.Top;
|
||
|
|
HorizPos: Left = Previous.Rightl
|
||
|
|
END;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the <code class="function">CreateBefore</code> presentation function is called for every <code>Column</code> element, but the <code>CreateAfter</code> function is only called if the <code>Column</code> element is the last in a set of siblings. P94 offers around 30 other conditions which can be tested before calling a presentation function.</p>
|
||
|
|
|
||
|
|
<h3 id="h-124">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<h4 id="h-125">Views</h4>
|
||
|
|
|
||
|
|
<p>Central to P94 is the notion of <em>views</em>. Views can be thought of as several style sheets in one, and one P94 style sheet can describe several views. Examples of commonly used views are formatted view, source code view and table of contents. For example, Amaya can show different views at the same time (e.g., the formatted document can be shown in one window, and the table of contents in another window), and the user can edit in all views.</p>
|
||
|
|
|
||
|
|
<pre>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
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above adds a second view. In addition to <code>Formatted_view</code> (which is the default since it comes first), a view called <code>Table_of_contents</code> has been added. In this view, the font size of <code class="element">H1</code> elements is <code class="value">2pt</code> bigger than the parent (as opposed to <code class="value">6pt</code> bigger than the parent in the normal view), and <code class="element">H2</code> elements are not visible. In Thot, views within a presentation schema are synchronized in semi-realtime: when you select an element in one view, the other views are scrolled automatically to show the same element.</p>
|
||
|
|
|
||
|
|
<p>Also, it is possible to write many different presentation schemas for the same document <a href="#Quint_1994">[Quint 1994]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Recall that it is possible to write many different presentation schemas for the same class of documents or objects. This allows users to choose for a document the graphical appearance which best suits their type of work or their personal taste.</blockquote>
|
||
|
|
|
||
|
|
<p>Typically, a schema defines a consistent set of views that may be useful for performing a particular type of task. For performing different types of tasks (drafting an outline, writing, fine tuning presentation, reviewing, etc.) one would write different sets of views, hence different schemas.</p>
|
||
|
|
|
||
|
|
<h3 id="h-127">P94 in context</h3>
|
||
|
|
|
||
|
|
<p>P94 was a powerful style sheet language in 1994. Combined with the <q>S</q> and <q>T</q> languages, it formed a powerful package for processing structured documents. The P language offers a rich set of stylistic functionality based on simple relationships between elements. Among the style sheet languages described in this chapter, it comes closest to expressing layout in terms of constraints between elements.</p>
|
||
|
|
|
||
|
|
<p>P94 was developed for one application (Thot) and was never standardized as a style sheet language for use by other applications. I believe P94 would have been a good style sheet language for SGML around 1990 and one that could have developed into a suitable style sheet language for the web. The language is simple enough to be understood by authors, yet powerful enough to express advanced typography. The syntax, which may not be intuitive, may have been an argument against the use of P94. However, the main reason why P94 never entered into the competition was that the creators of P94 never proposed the use of P94 outside of Thot.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>The P language has evolved from where it was in 1994. P now has properties to describe borders around elements, foreground and background colors, bi-directionality, hyphenation and more. These properties have been added in order to support W3C specifications such as CSS and SVG. P continues to serve a useful purpose as part of a test-bed application for new specifications.</p>
|
||
|
|
|
||
|
|
<h2 id="h-128">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>All style sheet languages share a set of common components. I propose the following six components to be required in a style sheet language: syntax, selectors, properties, values and units, value propagation mechanism, and formatting model. Most formatting models are visual, but aural and tactile formatting models are also possible. Also, many style sheet languages support generated content and a linking mechanism.</p>
|
||
|
|
|
||
|
|
<p>Style sheets existed before the web and this chapter has reviewed three seminal systems: FOSI, DSSSL and P94. The main purpose of these style sheet languages was for printing structured documents. All three systems fulfill the style sheet language criteria that were established at the beginning of this chapter.</p>
|
||
|
|
|
||
|
|
<p>The next chapter discusses style sheet languages for the web and evaluate nine different proposals by the same criteria used in this chapter.
|
||
|
|
|
||
|
|
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-postweb" title="Style sheet proposals for the web">
|
||
|
|
<h1 class="chapter" id="h-130">Style sheet proposals for the web</h1>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>The previous chapter described style sheet languages developed and used before the web. This chapter will look at style sheet languages that were proposed specifically for the web. Each proposal will be evaluated according to criteria established in the previous chapter.
|
||
|
|
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>The web was launched without a style sheet language in place. CERN's <em class="title">libwww</em> library <a href="#Nielsen_1994">[Nielsen&Lie 1994]</a>, which formed the basis for many of the early web browsers, had a notion of style sheets but these were hardcoded into the application and could not be changed by authors or users. In order to allow authors and users to influence the presentation of documents, a style sheet language is necessary. However, around 1993 there was no obvious candidate for a web style sheet language. As discussed in the previous chapter, DSSSL was still being developed, FOSI was only in limited use, and P94 was not actively proposed for use on the web. Unlike structured documents, where SGML had been the natural basis for the development of HTML a few years earlier, no style sheet language had achieved a similar status.</p>
|
||
|
|
|
||
|
|
<p>The first proposal for a style sheet language for the web appeared in 1993 and since then the subject of style sheets was a recurring topic discussed on the www-talk mailing list. In the period 1993-1995, eight different style sheet languages were proposed in web forums, mainly on the www-talk <a href="#www-talk">[www-talk]</a> mailing list. In 1996 one language was proposed in an academic paper <a href="#Munson_1996">[Munson 1996]</a>. All nine proposals are reviewed in chronological order in this chapter. The reviews are based on the proposals themselves, discussions on www-talk and other mailing lists, and personal communication with the authors. Some of the proposals have been implemented, but I have not had implementations available when doing the reviews.</p>
|
||
|
|
|
||
|
|
<p>In August 1997, W3C received a <q>A Proposal for XSL</q> from several of its members <a href="#NOTE-XSL_1997">[NOTE-XSL 1997]</a>. As a result of the submission, a working group on XSL was formed and XSL became a W3C Recommendation in 2001 <a href="#XSL_2001">[XSL 2001]</a>. In <a href="#ch-structure">Chapter 2</a>, XSL was discussed briefly in the context of style versus transformation. However, XSL will not be analyzed further in this chapter because it falls outside the time frame of the other proposals.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h2 id="h-131"><a id="rrp" name="rrp">Robert Raisch's proposal (RRP)</a></h2>
|
||
|
|
|
||
|
|
<p>This style sheet proposal <a href="#Raisch_1993a">[Raisch 1993a]</a> was published in June 1993 by Robert Raisch of O'Reilly & Associates Inc. It was the first style sheet proposal that was specifically designed for the web. Part of the introduction was used to argue why the web needed a style sheet language:</p>
|
||
|
|
|
||
|
|
<blockquote>There is a need within the WWW to be able to specify rendering specific information along with the content tagging in a WWW document. It is not appropriate to use HTML for this purpose, since one of the first principles of HTML is to encode objects within a document, not how they might be rendered in a particular environment.</blockquote>
|
||
|
|
|
||
|
|
<p>RRP was included in full in the message sent to www-style. The text message is around 700 lines and includes – in addition to the description of properties and values – a sample style sheet for HTML and pseudo-code for an implementation of RRP.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-132">Syntax</h3>
|
||
|
|
|
||
|
|
<p>The syntax of RRP is designed specifically for the proposal. It is compact (in order to <q>minimize the time required to retrieve and interpret</q> style sheets), but not easy to read for humans at first sight. Here is a fragment from the <em>Example stylesheet</em> which is provided in an appendix of RRP:</p>
|
||
|
|
|
||
|
|
<pre>@BODY fo(fa=he,si=18)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, two properties in the font (<code class="property">fo</code>) category are set on the <code class="element">BODY</code> element. The font family (<code class="property">fa</code>) is set to <code class="value">helvetica</code> (<code class="value">he</code>) and the font size (<code class="property">si</code>) is set to 18 points.</p>
|
||
|
|
|
||
|
|
<p>The example above is typical for RRP and all statements follow the same pattern: a selector is followed by one or more property/value pairs. All categories, properties and keyword values are represented by two-letter codes.</p>
|
||
|
|
|
||
|
|
<h3 id="h-133">Selectors</h3>
|
||
|
|
|
||
|
|
<p>RRP has a simple selector mechanism which selects elements based on their name. Elements cannot be selected based on other criteria such as their context or attributes. Selectors take the form:</p>
|
||
|
|
|
||
|
|
<pre>@<element-name>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In addition to element names, there is one selector which sets default values:</p>
|
||
|
|
|
||
|
|
<pre>@DEFAULT fo(fa=ti,sp=pr,si=14,we=me,sl=ro,fo=in,bo=in,li=no,nu=1,fn='')
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The possible namespace conflict between <code>DEFAULT</code> and a future HTML element with that name is not addressed. All selectors are written in uppercase in the examples given in RRP, but the case-sensitiveness of RRP is not defined. As such, RRP is immature but not more so than the first version of other style sheet proposals.</p>
|
||
|
|
|
||
|
|
<h3 id="h-134">Properties</h3>
|
||
|
|
|
||
|
|
<p>RRP defines 35 properties that are grouped into eight property categories. The properties span a wide range in functionality; they describe both basic formatting primitives (such as the font and colors of an element) and also support some advanced features. Table 7 shows the categories, their associated properties and RRP's descriptive title of the categories.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-7">
|
||
|
|
<p class="caption">RRP's catetories and properties.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Category</th>
|
||
|
|
<th>Properties</th>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font (fo)</td>
|
||
|
|
<td>family (fa), spacing (sp), size (si), weight (we), slant (sl), foreground (fo), background (ba), line (li), number (nu), longname (lo)</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>justify (ju)</td>
|
||
|
|
<td>style (st), hyphen (hy), kern (ke)</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>column (co)</td>
|
||
|
|
<td>num (nu), width (wi)</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>break (br)</td>
|
||
|
|
<td>style (st), object (ob)</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>mark (ma)</td>
|
||
|
|
<td>object (ob), preceed (pr), before (be), replace (re), succeed (su), after (af)</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>vert (ve)</td>
|
||
|
|
<td>before (be), after (af), spacing (le), offset (of)</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>indent (in)</td>
|
||
|
|
<td>left (le), right (ri), first (fi)</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>link (li)</td>
|
||
|
|
<td>location (lo), mark (ma), line (li), number (nu), before (be), after (af), hide (hi)</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>Several property names (e.g., <code class="property">before</code>, <code class="property">after</code>) are used in different categories (e.g., <code>vert</code>, <code>link</code>, <code>mark</code>) and mean something different in each category. The grouping of properties is therefore necessary to disambiguate properties. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>@LI ve(af=10) ma(af=5) li(af=st)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Three properties, all named <code class="property">after</code> are set in the above example. The first rule sets the vertical space after an <code class="element">LI</code> element to 10 units (see below for a discussion on units). The second rule sets the distance between a mark (i.e., the list-item marker) and the text of the element. The third rule describes links appearing inside <code class="element">LI</code> elements; the rule declares that links should have a <em>star</em> (*) after them.<span class="fn">RRP lists many possible marks (among them the <em>star</em>). However, the proposal does not specify the two-letter keyword to refer to marks, and the <code>st</code> value in the example is, therefore, a guess.</span>
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>The concept of grouping properties into categories in RRP is similar to the grouping found in FOSI. Table 8 lists all RRP categories along with similar FOSI categories, and Table 9 compares the font category in RRP and FOSI.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-8">
|
||
|
|
<p class="caption">A comparison of categories in FOSI and RRP.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>RRP category</th>
|
||
|
|
<th>FOSI category</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font</td>
|
||
|
|
<td>font</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>justify</td>
|
||
|
|
<td>quadding</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>column</td>
|
||
|
|
<td>column </td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>break</td>
|
||
|
|
<td>textbrk</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>mark</td>
|
||
|
|
<td><em>no similar category</em></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>vert</td>
|
||
|
|
<td>vjinfo</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>indent</td>
|
||
|
|
<td>indent</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>link</td>
|
||
|
|
<td><em>no similar category</em></td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="table" id="t-9">
|
||
|
|
<p class="caption">A comparison of the font category in RRP and FOSI.</p>
|
||
|
|
|
||
|
|
<table summary="" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>RRP property name</th>
|
||
|
|
<th>RRP values</th>
|
||
|
|
<th>FOSI property name</th>
|
||
|
|
<th>FOSI values</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>family (fa)</td>
|
||
|
|
<td>times (ti), helvetica (he), system (sy), typewriter (ty)</td>
|
||
|
|
<td>style (in <code class="element">font</code> category)</td>
|
||
|
|
<td>serif, sanserif, monoser, monosans</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>spacing (sp)</td>
|
||
|
|
<td>monospace (mo), proportional (pr)</td>
|
||
|
|
<td><em>no equivalent property</em></td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>size (si)</td>
|
||
|
|
<td><em>integer</em></td>
|
||
|
|
<td>size (in <code class="element">font</code> category)</td>
|
||
|
|
<td>length value using one of these units: pi, pt, in, mm, cm, em</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>weight (we)</td>
|
||
|
|
<td>ultralight (ul), light (li), medium (me), demibold (de), bold (bo)</td>
|
||
|
|
<td>weight (in <code class="element">font</code> category)</td>
|
||
|
|
<td>ultlight, exlight, light, semlight, medium, sembold, bold, exbold, ultbold</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>slant (sl)</td>
|
||
|
|
<td>roman (ro), italic (it), oblique(ob)</td>
|
||
|
|
<td>posture (in <code class="element">font</code> category)</td>
|
||
|
|
<td>upright, oblique, bsobl (back-slanted oblique), italic, bsital (back-slanted italic)</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>foreground (fo)</td>
|
||
|
|
<td>Colors are specified as text names, (eg. black, white, magenta), or as RGB color values in hexadecimal (e.g. 0x000000, 0xffffff, 0xff00ff)</td>
|
||
|
|
<td>foreground (in <code class="element">highlight</code> category)</td>
|
||
|
|
<td>black, white, red, orange, yellow, green, blue, violet, brown, gray</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>background (ba)</td>
|
||
|
|
<td>Colors are specified as text names, (eg. black, white, magenta), or as RGB color values in hexadecimal (e.g. 0x000000, 0xffffff, 0xff00ff)</td>
|
||
|
|
<td>background (in <code class="element">highlight</code> category)</td>
|
||
|
|
<td>bblack, bwhite, bred, borange, byellow, bgreen, bblue, bviolet, bbrown, bgray</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>line (li)</td>
|
||
|
|
<td>none (no), under (un), through (th), over (ov)</td>
|
||
|
|
<td>set with <code class="element">scoring offset</code> property in <code class="element">highlight</code> category</td>
|
||
|
|
<td>a positive value will place the score below the baseline, and a negative value will place the score above the baseline</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>number (no)</td>
|
||
|
|
<td>a numeric value indicating the number of lines</td>
|
||
|
|
<td>scoring (in <code class="element">highlight</code> category)</td>
|
||
|
|
<td>a numeric value indicating the number of lines</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>longname (lo)</td>
|
||
|
|
<td>string describing a platform-specific font name</td>
|
||
|
|
<td>famname (in <code class="element">font</code> category)</td>
|
||
|
|
<td>string describing platform-specific font name</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<p>There are several indications that RRP is influenced by FOSI. The grouping of properties into categories are similar and use some of the same names. Also, many of the names used for for properties and values often are identical.</p>
|
||
|
|
|
||
|
|
<h3 id="h-135">Values and units</h3>
|
||
|
|
|
||
|
|
<p>RRP has four different kinds of values:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>two-letter keywords</li>
|
||
|
|
|
||
|
|
<li>strings</li>
|
||
|
|
|
||
|
|
<li>colors expressed as hexadecimal digits</li>
|
||
|
|
|
||
|
|
<li>integers (called <em>UNITS</em>)</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Here is an example which uses all four kinds of values:</p>
|
||
|
|
|
||
|
|
<pre>@P fo(fa=ti fo='black' ba=0xffffff) co(nu=2,wi=10)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>First, three values are set in the <code>font</code> category. The font family is set to <code class="value">times</code> (which is one of four different font family values), the foreground color is set to <code class="value">black</code> (which is one of several color names mentioned in the proposal), and the background color to white (expressed in hexadecimal numbers). Thereafter, the number of columns is set to <code class="value">2</code>, and the column width is set to <code class="value">10</code>.</p>
|
||
|
|
|
||
|
|
<p>The interpretation of the integer value depends on the property in question, as well as the kind of object that the value is describing. For example, in the description of the column width property, the proposal states:</p>
|
||
|
|
|
||
|
|
<blockquote>In the case of a text object, UNITS might represent characters, while in the context of a graphical object, UNITS could represent picture elements (pixels.)</blockquote>
|
||
|
|
|
||
|
|
<p>The motivation for using one integer value and automatically switching between different ways of interpreting the value is to simplify the syntax. For some properties this may be an acceptable solution, but for other properties where the number of different units (as per CSS terminology) is high, the solution is insufficient. For example, in RRP, font sizes can only be expressed in <q>typographic points</q>, while other languages offer a number of different units.</p>
|
||
|
|
|
||
|
|
<h3 id="h-136">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>RRP provides three mechanisms for value propagation. First, style sheets can specify default rules for element/property combinations that are not specified explicitly. The sample style sheet contains this fragment to set default values:</p>
|
||
|
|
|
||
|
|
<pre>@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)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Second, each property has an initial value defined in the specification. Most values set in the above example are redundant since the values are set to their initial values.</p>
|
||
|
|
|
||
|
|
<p>Third, inheritance can be specified on two properties: <code class="property">foreground</code> and <code class="property">background</code>. Consider this excerpt from the above example (with one minor spelling correction: <code>bo</code> has been changed to <code>ba</code>):</p>
|
||
|
|
|
||
|
|
<pre>@DEFAULT fo(fo=in,ba=in)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, the foreground and background colors are set to inherit. In effect, this turns the <code class="property">foreground</code> and <code class="property">background</code> properties into inherited properties. Surprisingly, the inherit value (<code class="value">in</code>) is not allowed on properties other than <code class="property">foreground</code> and <code class="property">background</code>.</p>
|
||
|
|
|
||
|
|
<p>RRP's concept of inheritance (non-inherited properties, with an explicit <code class="value">inherit</code> value) is similar to FOSI's inheritance model.</p>
|
||
|
|
|
||
|
|
<h3 id="h-137">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>RRP sketches a simple visual formatting model. The proposal is not complete enough to get a full understanding of how it works and there is not enough information to classify RRP into a either a <a href="#box_model" class="term">box model</a> or a <a href="#sequence_model" class="term">sequence model</a>.</p>
|
||
|
|
|
||
|
|
<p>Various break-related properties can be set to describe where line breaks occur. This way, elements will appear as block-level or inline and the amount of space before and after the element can be set.</p>
|
||
|
|
|
||
|
|
<p>One advanced feature offered by RRP is multi-column layouts. The <code class="property">column number</code> and <code class="property">column width</code> properties can, for example, be used to describe a two-column page:</p>
|
||
|
|
|
||
|
|
<pre>@BODY co(nu=2,wi=40)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>There is, however, no way to set the space between columns. The proposal, therefore, is not able to describe common cases of multi-column layouts.</p>
|
||
|
|
|
||
|
|
<h3 id="h-138">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>RRP suggests using the LINK element to point to external style sheets, thus offering authors the possibility to link their documents to style sheets of their own liking. Here is the proposed syntax:</p>
|
||
|
|
|
||
|
|
<pre><LINK STYLE={URL}>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>User style sheets were not part of the proposal and there is no discussion in the proposal about authors versus reader preferences. However, the proposal limits the role of style sheets to be <q>hints</q> or <q>suggestions</q> that <q>might</q> be used <a href="#Raisch_1993a">[Raisch 1993a]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Rather, this is really a set of HINTS or SUGGESTIONS to the renderer which might be used to display particular HTML objects in the fashion the author of a document originally intended.</blockquote>
|
||
|
|
|
||
|
|
<p>This policy leaves room for honoring user preferences in combination with author style sheets.</p>
|
||
|
|
|
||
|
|
<h3 id="h-139">Generated content</h3>
|
||
|
|
|
||
|
|
<p>Not proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-140">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>Not proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-141">RRP in context</h3>
|
||
|
|
|
||
|
|
<p>RRP was the first proposal for a style sheet language specifically for the web. As such, the proposal is groundbreaking and deserves credit for its early date of publication. After the proposal was published in June 1993 it was briefly discussed on the www-talk mailing list. However, the proposal was not developed further and the author's own implementation was never published.</p>
|
||
|
|
|
||
|
|
<p>RRP is ambitious in several areas. Advanced topics such as counters and multi-column layouts are described. However, the descriptions of these topics are not detailed enough to produce consistent implementations. Also, RRP is simplistic in its approach to styling web documents. The most serious problem is probably the lack of units on numerical values. As a first draft, however, the proposal is well worth considering.</p>
|
||
|
|
|
||
|
|
<p>It seems clear that RRP was inspired by FOSI. The grouping of properties, the property names, and the similar concept of inheritance indicate that the author knew FOSI. FOSI is not referenced in the proposal, however.</p>
|
||
|
|
|
||
|
|
<p>RRP appeared at a time when the Mosaic browser development team was very active. If it had been taken up by Mosaic at an early stage, it is likely that HTML's presentation-oriented elements (e.g. <code class="property">FONT</code> and <code class="property">CENTER</code> elements) would not have appeared. Instead, more properties and values would have been added to RRP's style sheet language. As such, it is unfortunate that RRP was not implemented by web browsers of the time.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-142"><a id="pwp" name="pwp">Pei Wei's proposal (PWP)</a></h2>
|
||
|
|
|
||
|
|
<p>In October 1993, four months after Robert Raisch's proposal was published, Pei Wei published a brief proposal for a style sheet language on www-talk <a href="#Wei_1993a">[Wei 1993a]</a>. As the architect and programmer behind the ViolaWWW browser Pei Wei was in a good position to implement a style sheet language. The ViolaWWW browser was launched in 1992 <a href="#Wei_1992">[Wei 1992]</a> and was among the first graphical web browsers.</p>
|
||
|
|
|
||
|
|
<p>Like Robert Raisch, Pei Wei was employed by O'Reilly and it was natural for the community on www-talk to ask about the relationship between the two proposals <a href="#Andreessen_1993b">[Andreessen 1993b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>
|
||
|
|
<pre>From: Marc Andreessen (marca@ncsa.uiuc.edu)
|
||
|
|
Date: Fri, 22 Oct 93 23:48:42 -0700
|
||
|
|
|
||
|
|
What's the relationship between this and Rob Raisch's stylesheet
|
||
|
|
proposal from this summer? (Rob, are you out there? :-)
|
||
|
|
|
||
|
|
Cheers,
|
||
|
|
Marc
|
||
|
|
</pre>
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<p>The above message shows that the Mosaic developers indeed were following the development of style sheets. Robert Raisch's reply <a href="#Raisch_1993b">[Raisch 1993b]</a> to Marc Andreessen was that he had left O'Reilly and that further questions should be directed to them. Pei Wei sent this reply <a href="#Wei_1993b">[Wei 1993b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>
|
||
|
|
<pre>
|
||
|
|
Well, after Rob left ORA I've basically inherited the stylesheet
|
||
|
|
problem– finish the design, prototype, and final implementation.
|
||
|
|
As Rob has done the good work of writing the initial proposal,
|
||
|
|
I will try to reuse as much of the collected material as possible.
|
||
|
|
But there were and will be changes since Rob presented the proposal
|
||
|
|
this past summer.
|
||
|
|
|
||
|
|
</pre>
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<p>Indeed, as the screenshot in Figure 3 testifies, style sheets were implemented in ViolaWWW.</p>
|
||
|
|
|
||
|
|
<div id="f-3" class="figure">
|
||
|
|
<p><img style="width: 90%" alt="Viola screenshot" src="i/viola.png" /></p>
|
||
|
|
|
||
|
|
<p class="caption">The PWP sample document rendered in Viola.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>The document <a href="#Wei_1993d">[Wei 1993d]</a> shown in Figure 3 illustrates how PWP is supposed to work. Along with the style sheets that describe its presentation, it is considered to be part of the PWP proposal in order to make the proposal more complete. It is referred to as <em>the sample document</em>.
|
||
|
|
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-143">Syntax</h3>
|
||
|
|
|
||
|
|
<p>PWP includes a sample style sheet which is short enough to reprint in full:</p>
|
||
|
|
|
||
|
|
<pre>(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)
|
||
|
|
)
|
||
|
|
)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The most striking feature of the syntax is the use of parentheses. The syntax of PWP is, like DSSSL, based on Lisp with its multi-level parentheses. Unlike DSSSL, however, the multi-level parentheses in PWP do not express functions. Rather, they express contextual selectors in the document structure. While having contextual selectors is a powerful feature, human readability of style sheets arguably suffers when multi-level parentheses are introduced in the syntax. Also, writability suffers since the parentheses need to be balanced in order to write valid style sheets.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Pei Wei probably expected resistance to the proposed syntax and when asking for feedback the syntax was explicitly mentioned:</p>
|
||
|
|
|
||
|
|
<blockquote>Particularly, any problem with the the syntax of the style description language?</blockquote>
|
||
|
|
|
||
|
|
<p>The syntax issue was one reason why Steve Heaney wrote an alternative proposal (which is discussed next), but there were no other comments about the syntax on www-talk.</p>
|
||
|
|
|
||
|
|
<p>Since a PWP style sheet outlines the structure of the document, it can perceivably also be used to prescribe the structure. For example, in addition to describing the styling of <code class="element">H1</code> elements inside <code class="element">BODY</code> elements, the style sheet fragment above can express that <code class="element">H1</code> elements must only appear inside <code class="element">BODY</code> elements. In SGML, DTDs are used to express structural constraints, but PWP comes close to being able to replace DTDs. This may be what the author refers to in the statement: <q>The lone "(P)"s are there to engage the respective <P> tags to be in those particular contexts.</q> <a href="#Wei_1993a">[Wei 1993a]</a></p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-144">Selectors</h3>
|
||
|
|
|
||
|
|
<p>As discussed above, selectors are intrinsically built into the PWP syntax. By using multi-level parentheses, contextual selectors can easily be expressed. In the sample style sheet above, list items are given numbering styles depending on their level in the structure: the first level is numbered in the <code class="value">roman</code> style, the second in the <code class="value">number</code> style, and the third in the <code class="value">alpha</code> style.</p>
|
||
|
|
|
||
|
|
<p>Although not explicitly described in PWP, it is clear that contextual selectors express ancestor relationships, not parent-child relationships. Consider this fragment:</p>
|
||
|
|
|
||
|
|
<pre>(BODY
|
||
|
|
(BOLD,EMPH,STRONG fontWeight=bold))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Given the structure of HTML, it is clear that <code class="element">BODY</code> is an ancestor of <code class="element">BOLD</code>, <code class="element">EMPH</code>, and <code class="element">STRONG</code> rather than a parent (even if <code class="element">BOLD</code> and <code class="element">EMPH</code> are not HTML elements).</p>
|
||
|
|
|
||
|
|
<p>As seen above, selectors can be comma-separated lists of element names. There are no provisions for selecting elements based on criteria other than name and context.</p>
|
||
|
|
|
||
|
|
<h3 id="h-145">Properties</h3>
|
||
|
|
|
||
|
|
<p>One significant difference between RRP and PWP is the naming and grouping of properties. PWP uses longer, more readable property names, and properties are not grouped. This makes style sheets in PWP more readable.</p>
|
||
|
|
|
||
|
|
<p>The initial proposal does not contain a list of properties but the following properties are used in the sample style sheet: <code class="property">fontSize</code>, <code class="property">fontWeight</code>, <code class="property">fontSlant</code>, <code class="property">fontFamily</code>, <code class="property">numStyle</code>, <code class="property">BGColor</code>, <code class="property">FGColor</code>.</p>
|
||
|
|
|
||
|
|
<p>The number of properties supported by Viola seems to have increased over time. In the style sheets describing the sample document (Figure 3), these additional properties are used: <code class="property">fontSpacing</code>, <code class="property">align</code>, <code class="property">border</code>, <code class="property">BDColor</code>, <code class="property">blink</code>, <code class="property">blinkColorOn</code>, <code class="property">blinkColorOff</code>.</p>
|
||
|
|
|
||
|
|
<p>The set of properties listed above are sufficient for a proof-of-concept implementation like ViolaWWW, but are not well-suited for a widely deployed style sheet language for the web. For example, there are no properties to describe margins and indentation, but blinking behavior is described (perhaps tounge-in-cheek) in three properties.</p>
|
||
|
|
|
||
|
|
<h3 id="h-146">Values and units</h3>
|
||
|
|
|
||
|
|
<p>PWP style sheets use only two types of values: keywords and integers.</p>
|
||
|
|
|
||
|
|
<p>Keywords are by far the most common and the sample style sheet <a href="#Wei_1993a">[Wei 1993a]</a> uses only keyword values. For example, the keyword values represent font sizes (<code class="value">small</code>, <code class="value">normal</code>, <code class="value">large</code>, <code class="value">largest</code>), color names (<code class="value">red</code>, <code class="value">maroon</code>, <code class="value">grey70</code>), and list number types (<code class="value">roman</code>, <code class="value">number</code>, <code class="value">alpha</code>). In general, the keyword values are intuitively understandable. The list of color names is taken from X11 <a href="#X11">[X11]</a>.</p>
|
||
|
|
|
||
|
|
<p>Integer values are used on two properties: <code class="property">border</code> and <code class="property">blink</code>. Consider this excerpt from <a href="#Wei_1993d">[Wei 1993d]</a>:</p>
|
||
|
|
|
||
|
|
<pre>(BODY,HPANE,INPUT,P
|
||
|
|
(SECTION border=1)
|
||
|
|
(P blink=1000))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The proposal does not fully describe how to interpret these values. The value of <code class="property">border</code> may represent the border width in pixels, while the value of <code class="property">blink</code> may represent the blinking interval in milliseconds.</p>
|
||
|
|
|
||
|
|
<p>As for properties, the set of available values would need further development.</p>
|
||
|
|
|
||
|
|
<h3 id="h-147">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>PWP uses inheritance to propagate values from parent to child elements. From <a href="#Wei_1993a">[Wei 1993a]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Note that properties are inherited down the tree, unless overridden. [..] Having this inheritance behaviour also helps to keep the description short, as lots of information can be derived by the context in the tree structure.</blockquote>
|
||
|
|
|
||
|
|
<p>In addition, each property probably has an initial value in the ViolaWWW implementation, but this is not described in the proposal.</p>
|
||
|
|
|
||
|
|
<h3 id="h-148">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>The description of the visual formatting model in PWP is not sufficiently complete to review fully. However, some information can be gained by analyzing the rendering of the sample document in Figure 3. ViolaWWW uses a box-based model (the <code class="element">P</code> elements inside the <code class="element">SECTION</code> element are enclosed by the border attached to the <code class="element">SECTION</code> element). Also, PWP is able to align text within block-level elements to the left or right side. It is unclear what makes block-level elements be narrower than their containing block (e.g., the blue box with the <code class="element">ADDRESS</code> element in it). PWP does not describe how to classify elements as inline or block-level.</p>
|
||
|
|
|
||
|
|
<h3 id="h-149">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>PWP uses HTML's <code class="element">LINK</code> element to point to external style sheets. The proposal is undecided about where <code class="element">LINK</code> elements should be allowed:</p>
|
||
|
|
|
||
|
|
<blockquote>A document uses a <LINK REL="STYLE" HREF="URL_to_a_stylesheet"> to associate to a stylesheet. It's an open question as to whether we should allow multiple stylesheets in a document, and where this link can be specified (once only, in the <HEAD>?).</blockquote>
|
||
|
|
|
||
|
|
<p>ViolaWWW allowed <code class="element">LINK</code> elements to appear within the body of the document. Here is a (somewhat shortened) fragment from the sample document:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The purpose of having <code class="element">LINK</code> elements interspersed in the content is to apply specific style sheets to particular parts of the document. The same results can be achieved in a cleaner but perhaps less convenient way by restructuring the document (e.g., by using <code class="element">DIV</code> elements) and applying the style sheets to the resulting elements.</p>
|
||
|
|
|
||
|
|
<p>When links to style sheets were added later to HTML, they were restricted to <code class="element">HEAD</code> elements.</p>
|
||
|
|
|
||
|
|
<h3 id="h-150">Generated content</h3>
|
||
|
|
|
||
|
|
<p>Not proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-151">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>Not proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-152">PWP in context</h3>
|
||
|
|
|
||
|
|
<p>ViolaWWW was the first web browser that supported style sheets linked from documents. This was quite an achievement, especially when considering that a single person did the design and programming. Subsequent style sheet languages used concepts pioneered by PWP, including the use of the <code class="element">LINK</code> element to point to style sheets on the web. As is expected from an experimental application, not all aspects of PWP style sheets were successful and the proposal was quite immature when published in 1993.</p>
|
||
|
|
|
||
|
|
<p>Based on the communication between Pei Wei and Marc Andreessen quoted earlier, one could conclude that PWP evolved from RRP. However, this does not seem to be the case. The proposals differ greatly. In particular, the syntax, the selector mechanism, value propagation, and then names of properties/values of each are fundamentally different.</p>
|
||
|
|
|
||
|
|
<p>ViolaWWW never gained the widespread use achieved by Mosaic, but it was an influential application that inspired other developers. If style sheets had been supported by ViolaWWW when the browser was first released in 1992, Mosaic and other emerging browsers might have accepted the concept of style sheets at an earlier stage.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-153"><a id="shp" name="shp">Steve Heaney's proposal (SHP)</a></h2>
|
||
|
|
|
||
|
|
<p>Four days after Pei Wei published PWP, Steve Heaney posted a message to www-talk <a href="#Heaney_1993">[Heaney 1993]</a> where he argued for reusing FOSI rather than <q>re-inventing the wheel</q>. Steve Heaney's proposal (SHP) consists of a style sheet that expresses approximately the same stylistic rules as the sample style sheet in PWP, but expressed in FOSI. Further, SHP discusses the benefits and downsides of using a subset of FOSI. It is a sketch rather than a full proposal, and the evaluation below is correspondingly limited, therefore.</p>
|
||
|
|
|
||
|
|
<h3 id="h-154">Syntax</h3>
|
||
|
|
|
||
|
|
<p>The sample style sheet in SHP is short enough to reprint in full:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The proposal included only a brief explanation of the syntax:</p>
|
||
|
|
|
||
|
|
<blockquote>(The e-i-c tag is element in context - I hope the rest are reasonably self evident).</blockquote>
|
||
|
|
|
||
|
|
<p>Most participants in the www-talk mailing list, however, were not familiar with FOSI, so the rest of the style sheet was not self-evident. For example, it is not intuitively clear what the role of the <code class="element">docdesc</code> and <code class="element">charlist</code> elements are. SHP mentions <q>FOSI</q> twice, but FOSI is not explained and there are no bibliographic references to the FOSI specification.</p>
|
||
|
|
|
||
|
|
<p>SHP also lists the advantages and disadvantages of using a standardized SGML-based syntax. According to SHP, the advantages include validation, the use of existing tools, and expandability into full FOSI functionality. The main disadvantages are that it was <q>less easy to read</q> and <q>less easy to write without assistance</q>.</p>
|
||
|
|
|
||
|
|
<h3 id="h-155">Selectors</h3>
|
||
|
|
|
||
|
|
<p>Selectors in SHP are based on the name and the context of elements. In FOSI this is expressed in the <code class="attribute">gi</code> attribute and the <code class="attribute">context</code> attribute, respectively. FOSI can also express more advanced selectors (e.g., based on attributes), but these are not included in SHP.</p>
|
||
|
|
|
||
|
|
<h3 id="h-156">Properties</h3>
|
||
|
|
|
||
|
|
<p>SHP is a direct response to PWP. The former's sample style sheet uses only properties that are similar to those in PWP. Also, SHP lists <q>some of the other formatting attributes that the FOSI DTD includes</q>: <code class="element">presp</code>, <code class="element">postsp</code>, <code class="element">indent</code>, <code class="element">boxing</code>, <code class="element">textbrk</code>, <code class="element">quadding</code>. As such, SHP is primarily an argument for reusing a subset of FOSI rather than a proposal for functionality needed by the web.</p>
|
||
|
|
|
||
|
|
<h3 id="h-157">Values and units</h3>
|
||
|
|
|
||
|
|
<p>SHP's sample style sheet uses a subset of the values defined in FOSI. Most of the values used in PWP's sample style sheets are keywords for which equivalents exist in FOSI. For example, <code class="value">roman</code> in PWP becomes <code class="value">romanlc</code> in SHP. Some of the keywords cannot be translated; PWP's keyword values for font sizes (<code>small</code>, <code>normal</code>, <code>large</code>, <code>largest</code>) have been translated into length values (<code>10pt</code>, <code>12pt</code>, <code>20pt</code>, <code>24pt</code>) in SHP.</p>
|
||
|
|
|
||
|
|
<p>Adding keywords to represent font sizes in SHP would be simple, but SWP would no longer be a subset of FOSI.</p>
|
||
|
|
|
||
|
|
<h3 id="h-158">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>Not discussed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-159">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>Not discussed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-160">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>Not discussed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-161">Generated content</h3>
|
||
|
|
|
||
|
|
<p>Not discussed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-162">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>Not discussed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-163">SHP in context</h3>
|
||
|
|
|
||
|
|
<p>The response to SHP was mixed. One participant strongly endorsed the use of SGML as syntactic basis <a href="#Burnard_1993">[Burnard 1993]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>I'd like to endorse very strongly indeed the notion of using SGML as a notation for whatever style-sheet mechanism you eventually decide on. I don't particularly mind whether it's a FOSI-subset, or a DSSSL look-alike or a home-brewed dtd, but at least if it uses the SGML formalism ...</blockquote>
|
||
|
|
|
||
|
|
<p>Pei Wei's response <a href="#Wei_1993c">[Wei 1993c]</a> was more reserved:</p>
|
||
|
|
|
||
|
|
<blockquote>The idea was to do a quick style-hints sort of thing ASAP, rather than something as comprehensive as FOSI. But I suppose a very subset of FOSI can be that. Personally I still much prefer the simple semi LISP'ish syntax. But I see your points. ... If we go with FOSI now, someone should edit down the FOSI DTD. As is its got too much we can't use now.</blockquote>
|
||
|
|
|
||
|
|
<p>If someone had taken on the challenge to define a subset of FOSI and write a readable specification, FOSI might have been the basis for a style sheet language for the web. Unfortunately, no one did this.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-164"><a id="chss" name="chss">Cascading HTML Style Sheets (CHSS)</a></h2>
|
||
|
|
|
||
|
|
|
||
|
|
<p>In October 1994, I published a proposal for <em class="title"><a href="http://www.w3.org/People/howcome/p/cascade.html">Cascading HTML Style Sheets</a></em> <a href="#Lie_1994">[Lie 1994]</a>. Over the course of several years CHSS developed into CSS, but the initial proposal (referred to as <em>CHSS</em>) is of historic interest and is discussed in this section. CHSS is not a complete proposal on its own. Rather, it referred to other proposals for a description of properties and values (e.g., it referenced RRP) and focused on describing novel features thought necessary in a style sheet language for the web. Among these are shared author/user influence, support for visual as well as non-visual media types, and <a href="#environment_variable" class="term">environment variables</a>.</p>
|
||
|
|
|
||
|
|
<h3 id="h-165">Syntax</h3>
|
||
|
|
|
||
|
|
<p>In its simplest form, the syntax of CHSS is a variation of X11 Resources <a href="#X11">[X11]</a>. Here is a simple example:</p>
|
||
|
|
|
||
|
|
<pre>font.family = times
|
||
|
|
h1.font.family = helvetica
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first line in the example above sets the font family of all elements to <code class="value">times</code>. The second line is a more specific statement that only applies to <code class="element">H1</code> elements; <code class="element">H1</code> elements should use the <code class="value">helvetica</code> font family instead. Because the second statement is more specific than the first, it will override the setting for all <code class="element">H1</code> elements.</p>
|
||
|
|
|
||
|
|
<p>The CHSS syntax does not distinguish between properties and elements; without knowing about properties and elements in advance, a parser will not be able to distinguish between them. The parser's job is further complicated when optional media types are added to the syntax:</p>
|
||
|
|
|
||
|
|
<pre>speech.em.weight = 40db
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, <code>speech</code> is the media type, <code class="element">em</code> is the element, and <code class="property">weight</code> is the property.</p>
|
||
|
|
|
||
|
|
<p>CHSS supports shared influence between authors and users. Each party can indicate a requested influence as a percentage of the total influence. Here is an example:</p>
|
||
|
|
|
||
|
|
<pre>h2.font.size = 20pt 40%
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The rule in the above example asks for 40% of the influence over <code class="element">H2</code> elements' font size. User style sheets are given priority when influence is assigned, and author style sheets come second. The proposal foresees that <q>the user [..] may request total control of the presentation, but – more likely – hands most of the influence over to the [author]</q>.</p>
|
||
|
|
|
||
|
|
<p>The syntax of CHSS also includes logical expressions involving <a href="#environment_variable" class="term">environment variables</a> to determine when/if a rule should be applied. Environment variables are <q>parameters from the user's environment</q>, i.e., not from the document itself. The syntax for these expressions borrows from the C programming language <a href="#Kernighan_1978">[Kernighan&Richie 1978]</a>. Here is an example:</p>
|
||
|
|
|
||
|
|
<pre>AGE > 3d ? background.color = pale_yellow : background.color = white
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In English, the expression above can be written: if the document is older than three days, the background color should be pale yellow, otherwise the background color should be white.</p>
|
||
|
|
|
||
|
|
<p>Thus, the simple syntax borrowed from X11 Resources has been extended in several ways to accommodate the CHSS concept of shared influence, media types, and expressions.</p>
|
||
|
|
|
||
|
|
<h3 id="h-168">Selectors</h3>
|
||
|
|
|
||
|
|
<p>CHSS offers a simple set of traditional selectors as well as more experimental selectors. Traditional selectors, which combine stylistic declarations with structural elements in the document, are based on element names:</p>
|
||
|
|
|
||
|
|
<pre>h1.font.size = 12pt
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>By omitting the element name, all elements are selected:</p>
|
||
|
|
|
||
|
|
<pre>font.size = 12pt
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>CHSS also offers two aliases to more easily select groups of elements:</p>
|
||
|
|
|
||
|
|
<pre>head.space.above = 15pt
|
||
|
|
list.space.first = 1cm
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, <code>head</code> selects all headline elements (<code class="element">H1-H6</code> in HTML), and <code>list</code> selects all lists (<code class="element">UL</code>, <code class="element">OL</code>, and <code class="element">DL</code> in HTML). The name space conflict between the <q>head</q> alias and the <code class="element">HEAD</code> element is not discussed in the proposal.</p>
|
||
|
|
|
||
|
|
<p>Experimental selectors offered by CHSS fall into two categories. First, the <code class="selector">window</code> selector attaches declarations to an element (i.e., the browser window) which is not part of the document:</p>
|
||
|
|
|
||
|
|
<pre>window.margin.left = 2cm
|
||
|
|
window.margin.right = 2cm
|
||
|
|
window.margin.above = 2cm
|
||
|
|
window.margin.below = 2cm
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Second, the media types and expressions act as selectors by putting additional constraints on when a rule should be used. These kind of selectors are <em>meta-selectors</em> in the sense that they work in conjunction with the traditional selectors, but at a higher level. Media types are discussed in more detail in the <em>Other formatting contexts</em> section below. Here are some examples of expressions:</p>
|
||
|
|
|
||
|
|
<pre>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
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above is taken from the CHSS proposal and shows that expressions can be diverse. <code class="selector">AGE</code> represents the time since the content was written and is used to give older content a pale yellow background. <code class="selector">DISPLAY_HEIGHT</code> is a feature of the output device, which the author has no way of knowing in advance. <code class="selector">RELEVANCE</code> is a number that represents how relevant a document is compared with the user's personal profile.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-170">Properties</h3>
|
||
|
|
|
||
|
|
<p>The CHSS proposal states specifically that it is not a <q>formal definition of the style sheet language</q> and that <q>the specific list of style values</q> is less interesting than other topics. RRP is pointed to as a reasonable list of properties.</p>
|
||
|
|
|
||
|
|
<p>The examples in CHSS use property names with dots in them. This naming scheme indicates a grouping of properties where, for example, <code>font</code> is the property group name and <code class="property">family</code> and <code class="property">size</code> are individual properties. This organization is similar to the grouping of properties in FOSI and RRP.</p>
|
||
|
|
|
||
|
|
<p>Most property names describing space around elements are absolute rather than relative to the writing direction. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>space.left = 0pt
|
||
|
|
space.right = 0pt
|
||
|
|
space.above = 4pt
|
||
|
|
space.below = 4pt
|
||
|
|
space.first = space.left + 0.5cm
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the first four properties use absolute names (<code>left</code>, <code>right</code>, <code>above</code> and <code>below</code>), while the last property (<code>first</code>) is relative to the writing direction.</p>
|
||
|
|
|
||
|
|
<h3 id="h-171">Values and units</h3>
|
||
|
|
|
||
|
|
<p>As noted in the previous section, CHSS does not contain a <q>list of style values</q> that can be compared with other proposals. Still, the examples and the prose describe several types of values:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>numeric length values with unit identifiers (these units are suggested: <code class="unit">pt</code>, <code class="unit">px</code>, <code class="unit">mm</code>, <code class="unit">cm</code>)</li>
|
||
|
|
|
||
|
|
<li>a numeric loudness value (discussed under <q>Other formatting contexts</q> below)</li>
|
||
|
|
|
||
|
|
<li>keywords (e.g. <code class="value">bold</code>, <code class="value">italics</code>, and <code class="value">proportional</code>)</li>
|
||
|
|
|
||
|
|
<li>simple expressions</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h4 id="h-172">Expressions</h4>
|
||
|
|
|
||
|
|
<p>The expressions deserve some discussion. First, expressions can involve environment variables:</p>
|
||
|
|
|
||
|
|
<pre>window.height = REAL_HEIGHT - 50px
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, <code class="value">REAL_HEIGHT</code> probably refers to the height of the output device and the statement sets the window size to be 50 pixels less.</p>
|
||
|
|
|
||
|
|
<p>Another type of expression involves the <em>previous value</em> of the same element/property combination:</p>
|
||
|
|
|
||
|
|
<pre>h1.font.size *= 1.5
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>To compute the font size of <code class="element">H1</code> elements, a user agent would first have to compute the font size as if the rule above did not exist and, subsequently, multiply the old value by 1.5 in order to find the new value. Also, the end result must be scaled according to the assigned influence of the rule. The benefit of this approach is that a rule can express a constraint relative to another, possibly unknown, rule. However, the algorithm for finding the actual value is complex.</p>
|
||
|
|
|
||
|
|
<p>A third kind of expression involves references to other properties. Here is a simple example:</p>
|
||
|
|
|
||
|
|
<pre>space.first = space.left + 0.5cm
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the indentation of the first line is set to be the same as the element's space on the left side plus 0.5cm. This is another example of describing a constraint which will be resolved in the future rather than setting a value directly. The constraint in the above example relies on <code class="value">space.left</code> being computed before <code class="value">space.first</code> to avoid circular constraints.<span class="fn">The <code class="unit">em</code> unit in CSS offers a similar feature and restriction: <code class="unit">em</code> units are relative to a value determined in the future, and the <code class="property">font-size</code> must be computed before other length units.</span></p>
|
||
|
|
|
||
|
|
<h4 id="h-174">Blending values</h4>
|
||
|
|
|
||
|
|
<p>The concept of shared influence over style is a fundamental feature of CHSS. In principle, any number of style sheets can demand, and be assigned, influence over any element/property combination. If more than one rule tries to influence a value, CHSS will calculate a median value based on a <q>weighted average</q>. The proposal describes some of the issues involved when blending values:</p>
|
||
|
|
|
||
|
|
<blockquote>For continuous values, e.g. the font size, mixing influences is not problematic – one simply calculates the weighted average if they differ. For discrete values, e.g. the font family, it may not be obvious how to mix 40% helvetica and 60% times. Some will argue that font families certainly can be parameterized and mixed, others that one should select the request with the highest influence. The issue deserves more research for which this proposal leaves room.</blockquote>
|
||
|
|
|
||
|
|
<p>The research mentioned in the last sentence has not yet materialized. For properties that accept numerical values, e.g. <code class="property">font-size</code>, calculating weighted average values is easy. Even if the value is specified in relative terms (<q>bigger than surrounding text</q>) or as a keyword (<code class="value">huge</code>), a numerical value fit for computations can be found. However, other properties accept other types of values which are more difficult to compute:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>boolean values</li>
|
||
|
|
|
||
|
|
<li>one-dimensional keyword values</li>
|
||
|
|
|
||
|
|
<li>multi-dimensional keyword values</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The above listed value types would have been more difficult to compute and even if algorithms for finding the computed value could have been devised, the results may have been neither beautiful nor intuitive. The proposal of blending style sheets at the property level was dropped, therefore, at an early stage in the development of CSS, while the concept of combining style sheets was kept.</p>
|
||
|
|
|
||
|
|
<p>The difference between CHSS, CSS and other proposals on this issue can be described along a one-dimensional axis of granularity. CHSS is the most fine-grained proposal, allowing preferences to be computed on a sub-property basis (i.e., several sources may influence the computation of a single element/property combination). CSS is not as fine-grained and only allows shared influence on a per-property basis. Most other proposals are even more monolithic, allowing shared influence on a per style sheet basis (i.e., one among several style sheets is selected to describe the presentation of a document).</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-176">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>CHSS offers two mechanisms for value propagation. First, rules can set default values on properties. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>font.weight = normal
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>By omitting the selector from the rule in the example above, the font weight is set to <code class="value">normal</code> for all media/elements/property combinations.</p>
|
||
|
|
|
||
|
|
<p>Second, CHSS introduces the notion of <a href="#cascading" class="term">cascading</a> which can be considered a value propagation mechanism. This is how cascading is described:</p>
|
||
|
|
|
||
|
|
<blockquote>The proposed scheme supplies the browser with an ordered list (cascade) of style sheets. The user supplies the initial sheet which may request total control of the presentation, but – more likely – hands most of the influence over to the style sheets referenced in the incoming document.</blockquote>
|
||
|
|
|
||
|
|
<p>In addition to style sheets from users and authors, the browser may also supply a style sheet. Typically, the browser will supply a base style sheet which includes conventional descriptions of HTML presentations. One such convention is that <code class="element">H1</code> elements are shown in larger fonts than text inside <code class="element">P</code> elements.</p>
|
||
|
|
|
||
|
|
<p>By relying on the browser having a base style sheet available, users and authors do not need to repeat all desired stylistic rules. Instead they can just describe the differences between the accepted conventions and the desired presentation. Thus, cascading reduces the length of style sheets since accepted conventions do not have to be repeated.</p>
|
||
|
|
|
||
|
|
<h3 id="h-177">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>CHSS does not describe a complete visual formatting model. The sample code indicates that the white space around elements can be described in properties. However, there is no discussion of what kind of formatting objects the style sheet language supports nor how elements are classified into different formatting objects.</p>
|
||
|
|
|
||
|
|
<h3 id="h-178">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>CHSS proposes to use HTML's <code class="element">LINK</code> element to point to external style sheets:</p>
|
||
|
|
|
||
|
|
<pre><LINK REL="style" HREF="http://NYT.com/style">
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="element">LINK</code> element is used to indicate the URL of the style sheet. Multiple style sheets can be referenced from the same document and will be appended to the cascade and merged as they are encountered.</p>
|
||
|
|
|
||
|
|
<p>In the list of unresolved issues, it is noted that only allowing <code class="element">LINK</code> elements in the <code class="element">HEAD</code> of the document is a limitation. By having a way of <q>adding and subtracting style sheets from within the document</q>, different parts of the document could be styled differently. This idea is similar to the functionality found in PWP.</p>
|
||
|
|
|
||
|
|
<h3 id="h-179">Generated content</h3>
|
||
|
|
|
||
|
|
<p>Not proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-180">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>CHSS emphasizes that the proposal can be used with both visual and non-visual media types. An example in the proposal sets property values for speech media:</p>
|
||
|
|
|
||
|
|
<pre>speech.*.weight = 35db
|
||
|
|
speech.em.weight = 40db
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Likewise, the proposal contains examples with special rules for print media, for example:</p>
|
||
|
|
|
||
|
|
<pre>print.head.align.style = right
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Just like <code>head</code> is an alias for the <code class="element">H1-H6</code> elements in CHSS, the <code class="media">print</code> keyword is also an alias for two more specific media types: <code class="media">print_mono</code> and <code class="media">print_color</code>. By using the more specific media types directly, a style sheet can describe presentations of monochrome and color printers.</p>
|
||
|
|
|
||
|
|
<h3 id="h-181">CHSS in context</h3>
|
||
|
|
|
||
|
|
<p>The development of CSS was started on the basis of the CHSS proposal. Many of the ideas put forward by CHSS have not survived in CSS, for example, environment variables, selector aliases, and the blending of values. Also, the CSS syntax is quite different from that proposed in CHSS.</p>
|
||
|
|
|
||
|
|
<p>However, three important aspects of CHSS are used in CSS. First, the <q>C</q> in CSS stands for <a href="#cascading" class="term">cascading</a> which was first described in CHSS. Although the cascading mechanism in CHSS is different from the one in CSS, the concept of shared influence is the same. Second, the ability to use information outside the document itself in the presentation of the document was introduced in CHSS. CSS does not have environmental variables, but the pseudo-classes are based on the same concept. Third, the notion of media types which is found in CSS2 was first proposed in CHSS.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h2 id="h-182"><a id="jep" name="jep">Joe English's proposal (JEP)</a></h2>
|
||
|
|
|
||
|
|
<p>Joe English' proposal for <em class="title">Style Sheets for HTML</em> <a href="#English_1994a">[English 1994a]</a> was announced to the www-html mailing list <a href="#English_1994b">[English 1994b]</a> in November 1994.<span class="fn">The www-html mailing list had been created <a href="#Berners-Lee_1994">[Berners-Lee 1994]</a> in May 1994 to host discussions on HTML-related matters. Style sheets were among the topics on the new list.</span></p>
|
||
|
|
|
||
|
|
<p>The proposal is more extensive than any of the other web style sheet proposals, and it contains rich discussions on difficult topics. This indicates that the author had worked on the proposal for some time. However, when the draft was published the author also announced that it would be abandoned in favor of DSSSL Lite (which is discussed below) and, therefore, the proposal did not receive much discussion on www-talk.</p>
|
||
|
|
|
||
|
|
<h3 id="h-183">Syntax</h3>
|
||
|
|
|
||
|
|
<p>Here is a simple JEP style sheet:</p>
|
||
|
|
|
||
|
|
<pre><stylesheet>
|
||
|
|
<style gis = "body"
|
||
|
|
fontfam = normal
|
||
|
|
fontsize = normalsize>
|
||
|
|
</style>
|
||
|
|
<style gis = "h1"
|
||
|
|
fontfam = heading
|
||
|
|
fontsize = large>
|
||
|
|
</style>
|
||
|
|
</stylesheet>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Like FOSI and SHP, JEP is written in SGML. Simple selectors are specified as values to the <code class="attribute">gis</code> attribute, and each property is an attribute of its own. In the example above, the <code class="property">fontfam</code> and <code class="property">fontsize</code> properties are set on the <code class="element">BODY</code> and <code class="element">H1</code> elements.</p>
|
||
|
|
|
||
|
|
<p>The JEP properties and their values are quite readable in this syntax, but the selector attribute is not intuitive unless one is familiar with SGML terminology. Element names in SMGL are called <em>Generic Identifiers</em> (GI). Several GIs become <code class="attribute">gis</code>. FOSI uses the <code class="attribute">gi</code> attribute for the same purpose.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-184">Selectors</h3>
|
||
|
|
|
||
|
|
<p>The <code class="attribute">gi</code> attribute in the example above is a simple way of selecting elements based on their names. It accepts a space-separated list of element names as value:</p>
|
||
|
|
|
||
|
|
<pre><style gis = "h1 h2 h3"
|
||
|
|
fontfam = heading>
|
||
|
|
</style>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the <code class="property">fontfam</code> property is set on all <code class="element">H1</code>, <code class="element">H2</code>, and <code class="element">H3</code> elements.</p>
|
||
|
|
|
||
|
|
<p>JEP also describes two mechanisms for selecting elements contextually, i.e., based on their position in the document structure. The first is to have <em>style sets</em> be applied by the <code class="property">useset</code> property. Style sets can be thought of as style sheets of their own. Consider this example:</p>
|
||
|
|
|
||
|
|
|
||
|
|
<pre><styleset id=inheading>
|
||
|
|
<style gis="em" fgcolor=red></style>
|
||
|
|
</styleset>
|
||
|
|
<style gis="h1" useset = inheading></style>
|
||
|
|
<style gis="em" fgcolor=blue></style>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, <code class="element">EM</code> elements are red when inside an <code class="element">H1</code> element, and blue otherwise. This is due to an indirection: the <code class="property">useset</code> property on the <code class="element">H1</code> element declares that the <code>inheading</code> style set is to be used within the <code class="element">H1</code> element.</p>
|
||
|
|
|
||
|
|
<p>The second, and more conventional, mechanism for contextual selectors is to use a pattern-matching syntax similar to the one in X11 <a href="#X11">[X11]</a>:</p>
|
||
|
|
|
||
|
|
<pre> <style context = "h1 * em" fgcolor=red></style>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The syntax of this second method is similar to the approach taken by CHSS and SSP.</p>
|
||
|
|
|
||
|
|
<h3 id="h-185">Properties</h3>
|
||
|
|
|
||
|
|
<p>JEP includes a set of 28 properties. Combined, the properties are able to describe most of HTML 3.2's rendering conventions with the exception of tables and counters. Table 10 lists the JEP properties.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-10">
|
||
|
|
<p class="caption">JEP's properties.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Property </th>
|
||
|
|
<th>Values</th>
|
||
|
|
<th>Corresponding CSS functionality</th>
|
||
|
|
<th>Comments</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">fontfam</td>
|
||
|
|
<td class="value">normal, heading, fixed, alternate</td>
|
||
|
|
<td class="property">font-family</td>
|
||
|
|
<td>The generic font names can be mapped to an actual font through the <code class="element">fontdesc</code> element (see below).</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">fontsize</td>
|
||
|
|
<td class="value">tiny, small, normalsize, large, big, huge, 0, 1, 2, 3, 4, 5, 6, 7</td>
|
||
|
|
<td class="property">font-size</td>
|
||
|
|
<td>The keywords are taken from LaTex, the numbers are taken from Netscape.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">fontshape</td>
|
||
|
|
<td class="value">plain, bf, it, bi, sc, tt</td>
|
||
|
|
<td class="property">font-style, font-weight, font-variant</td>
|
||
|
|
<td>The two-letter values mean bold, italic, bold italic, small-caps, teletype (i.e., monospace).</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">lmargin</td>
|
||
|
|
<td class="value">length value</td>
|
||
|
|
<td class="property">margin-left</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">rmargin</td>
|
||
|
|
<td class="value">length value</td>
|
||
|
|
<td class="property">margin-right</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">preskip</td>
|
||
|
|
<td class="value">length value</td>
|
||
|
|
<td class="property">margin-top</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">postskip</td>
|
||
|
|
<td class="value">length value</td>
|
||
|
|
<td class="property">margin-bottom</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">parskip</td>
|
||
|
|
<td class="value">length value</td>
|
||
|
|
<td class="property">-</td>
|
||
|
|
<td>(This property is left in the DTD by mistake [English 2002])</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">parindent</td>
|
||
|
|
<td class="value">length value</td>
|
||
|
|
<td class="property">text-indent</td>
|
||
|
|
<td>Indentation of first line.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">presep</td>
|
||
|
|
<td class="value">reference to <q>separator</q></td>
|
||
|
|
<td class="property">padding/border/margin</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">postsep</td>
|
||
|
|
<td class="value">reference to <q>separator</q></td>
|
||
|
|
<td class="property">padding/border/margin</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">align</td>
|
||
|
|
<td class="value">left, center right</td>
|
||
|
|
<td class="property">text-align and/or margin-left, margin-right</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">xleading</td>
|
||
|
|
<td class="value">length value</td>
|
||
|
|
<td class="property">line-height</td>
|
||
|
|
<td>Indicates <em>extra</em> leading.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">obeylines</td>
|
||
|
|
<td class="value">obeylines, wraplines</td>
|
||
|
|
<td class="property">white-space</td>
|
||
|
|
<td>Indicates if line breaks should be obeyed.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">obeyspaces</td>
|
||
|
|
<td class="value">obeyspaces, squeezespaces</td>
|
||
|
|
<td class="property">white-space</td>
|
||
|
|
<td>Indicates if space characters should be obeyed.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">box</td>
|
||
|
|
<td class="value">box, nobox</td>
|
||
|
|
<td class="property">border-style</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">boxcolor</td>
|
||
|
|
<td class="value">color</td>
|
||
|
|
<td class="property">border-color</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">bgcolor</td>
|
||
|
|
<td class="value">color</td>
|
||
|
|
<td class="property">background</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">fgcolor</td>
|
||
|
|
<td class="value">color</td>
|
||
|
|
<td class="property">color</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">line</td>
|
||
|
|
<td class="value">noline, underline, overline, strikethrough</td>
|
||
|
|
<td class="property">text-decoration</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">linecolor</td>
|
||
|
|
<td class="value">color</td>
|
||
|
|
<td>none, the element's color is used</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">foldcase</td>
|
||
|
|
<td class="value">nofoldcase, toupper, tolower</td>
|
||
|
|
<td class="property">text-transform</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">headfmt</td>
|
||
|
|
<td class="value">display, runin, margin</td>
|
||
|
|
<td class="property">display/float</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">icon</td>
|
||
|
|
<td>an indirect reference to an image URL</td>
|
||
|
|
<td class="property">list-style-image</td>
|
||
|
|
<td>Applies to heading.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">numfmt</td>
|
||
|
|
<td class="value">arabic, lcroman, ucroman, lcalpha, ucalpha</td>
|
||
|
|
<td class="property">list-style-type</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">width</td>
|
||
|
|
<td class="value">length value</td>
|
||
|
|
<td class="property">width</td>
|
||
|
|
<td>Describes the width of separators.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">thick</td>
|
||
|
|
<td class="value">length value</td>
|
||
|
|
<td class="property">border-width</td>
|
||
|
|
<td>Describes the thickness of separators.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">align</td>
|
||
|
|
<td class="value">left, center right</td>
|
||
|
|
<td class="property">margin-left/margin-right</td>
|
||
|
|
<td>Describes the alingnment of separators.</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<p>JEP's properties correspond roughly to those found in CSS1 <a href="#CSS1_1996">[CSS1 1996]</a>. Both CSS1 and JEP are able to describe basic styling with fonts, colors and spacing. Also, they can both draw boxes around elements and perform case transformations. None of them describes tables, counters, generated text or hyphenation. JEP's naming of properties and values is similar to FOSI (both use pre/right/post/left to describe what CSS calls top/right/bottom/left) and FOSI is referred to in notes (but not in the list of references).</p>
|
||
|
|
|
||
|
|
<p>For some of the properties, the proposal describes the initial value. Also, JEP distinguishes between inheritable and non-inheritable properties.</p>
|
||
|
|
|
||
|
|
<p>JEP has fewer and simpler font-related properties than most other proposals. The three font properties are <code class="property">fontfam</code>, <code class="property">fontsize</code>, and <code class="property">fontshape</code>. The <code class="property">fontfam</code> property only accepts one of four different keywords (<code class="value">normal</code>, <code class="value">heading</code>, <code class="value">fixed</code>, <code class="value">alternate</code>) which each express a <q>logical</q> font family. Similarly, the <code class="property">fontsize</code> property (through keywords or, alternatively, integers from 0 to 7) expresses a <q>logical size</q>. Finally, the <code class="property">fontshape</code> property accepts one of six keywords that describe the weight (normal or bold, slant (normal or slanted), variant (normal or small-caps), and glyph widths (proportional or monospace). The six keywords are <code class="value">plain</code>, <code class="value">bf</code> (bold), <code class="value">it</code> (italic), <code class="value">bi</code> (bold italic), <code class="value">sc</code> (small caps) and <code class="value">tt</code> (monospace). By only having six keywords there are many combinations that cannot be expressed. For example, it is impossible to select a bold monospace font, or an italic small-caps. The font strategy is described in the proposal:</p>
|
||
|
|
|
||
|
|
<blockquote>This scheme provides a limited logical palette of fonts for designers to choose from, and readers are able to select the actual typefaces and sizes to which the logical fonts map.</blockquote>
|
||
|
|
|
||
|
|
<p>Thus, the proposal envisions that the reader is given the final choice of font to be used by providing a mapping from the logical font to the actual font. The proposal also suggests a way of describing this mapping:</p>
|
||
|
|
|
||
|
|
<pre><fontdesc fontfam=normal fontsize=normal fontshape=it>
|
||
|
|
<fontspec notation=XLFD>
|
||
|
|
-adobe-times-medium-r-normal–*-120-*-*-*-*-iso8859-1
|
||
|
|
</fontspec>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>By combining style sheets from the author side with <code class="element">FONTDESC</code> elements from the reader, a simple form of cascading could be achieved. However, the proposal specifically notes that only one style sheet is allowed and that the <code class="element">FONTDESC</code> element is meant for authors.</p>
|
||
|
|
|
||
|
|
<p>Another reason for simplifying the font specification into three properties is that the proposal does not support <q>cumulative</q> font styles <a href="#English_1994a">[English 1994a]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Some authors may expect bold and italic specifications to have a cumulative effect, i.e., that an italic phrase inside bold text should be rendered in bold italic. [[The utility of this has always puzzled me, but every Mac program, desktop publishing application, and even LaTeX2e seem to think that font selection should work like that. I think the notion that you can do arithmetic with fonts that way is misleading: Times Bold Italic is not just Times Roman plus bold plus italic.]]</blockquote>
|
||
|
|
|
||
|
|
<p>(The original author uses double square brackets to mark comments in the proposal.)</p>
|
||
|
|
|
||
|
|
<p>JEP is, as it notes, quite alone in not supporting cumulative font styles. Most other style sheet languages support cumulative font styles by having independent, inheritable font properties.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-186">Values and units</h3>
|
||
|
|
|
||
|
|
<p>Perhaps the most innovative parts of JEP is the lists of values and units. JEP supports three main kinds of values: length, color and keyword. Of these, the length values are especially interesting.</p>
|
||
|
|
|
||
|
|
<h4 id="h-187">Length values</h4>
|
||
|
|
|
||
|
|
<p>Unlike most other proposals, JEP barely mentions the possibility of absolute length values (<code class="unit">pt</code>, <code class="unit">mm</code>, <code class="unit">cm</code> etc.) but it describes a number of interesting relative length units. The relative length units fall into two categories: font-relative units and display-relative units.</p>
|
||
|
|
|
||
|
|
<p>The font-relative units are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><code class="unit">em</code>, <code class="unit">en</code>, <code class="unit">ex</code>. JEP defines <code class="unit">em</code> as the width of a capital letter <q>M</q> in the current font (while most other systems define it as the height of the current font). One interesting restriction on the <code class="unit">em</code> unit is that it <q>may only be used in horizontal contexts</q>.</li>
|
||
|
|
|
||
|
|
<li><code class="unit">lh</code> (line height): the unit is defined as the normal distance from baseline to baseline (including leading) of the current font.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The display-relative units are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><code class="unit">pcd</code> (per cent of display): the unit is relative to the display size. The valid range is between 0 and 100 inclusive.</li>
|
||
|
|
|
||
|
|
<li><code class="unit">nlh</code> (normal line height): the unit is defined as the normal distance from baseline to baseline of the normal body font at the normal size. While <code class="value">1lh</code> may mean different things at different points in a document, <code class="value">1nlh</code> always refers to the same height regardless of the current font.</li>
|
||
|
|
|
||
|
|
<li><code class="unit">p</code>: A value of <code class="value">1p</code> (one <code class="unit">p</code>) represents the thickness of a <em>hairline</em>, i.e., the smallest amount of space easily visible to the eye.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>With the exception of the commonly used <code class="unit">em</code>, <code class="unit">en</code>, and <code class="unit">ex</code> units, the relative length units described in JEP have not been taken up by any of the subsequent style sheet proposals. I believe this is unfortunate.</p>
|
||
|
|
|
||
|
|
<p>As in FOSI, length values can refer to the margins of the containing block. This way, values can express more constraints. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre><style id=s1 lmargin="+3em" >
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>By prefixing the value with a '+' or '-' sign, the value is relative to the containing block rather than absolute (presumably w.r.t. the display area). To indicate a negative absolute value, JEP suggests using '='.</p>
|
||
|
|
|
||
|
|
<h4 id="h-188">Color values</h4>
|
||
|
|
|
||
|
|
<p>JEP requires style sheets to define any color names that are used. Here is a sample color definition and usage:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Thus, the color names serve as indirections to make style sheets more readable. Unlike most other style sheet languages, JEP has no predefined colors.</p>
|
||
|
|
|
||
|
|
<h4 id="h-189">Images</h4>
|
||
|
|
|
||
|
|
<p>Images representing list item markers are handled similarly to color names. Here is a simple excerpt from the proposal:</p>
|
||
|
|
|
||
|
|
<pre><image id = kilroy
|
||
|
|
url = "http://www.art.com/bitmaps/stupid-kilroy-gif.gif">
|
||
|
|
|
||
|
|
<style gis="hr" icon=kilroy preskip=2p postskip=2p>
|
||
|
|
</style>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>By defining an image name with the <code class="element">image</code> element, a user-friendly name can be used instead of a URL.</p>
|
||
|
|
|
||
|
|
<h4 id="h-190">Keyword values</h4>
|
||
|
|
|
||
|
|
<p>Keyword values in JEP are fairly traditional. Here is an example:</p>
|
||
|
|
|
||
|
|
<pre><style gis = "h1"
|
||
|
|
fontfam = heading
|
||
|
|
fontshape = bf
|
||
|
|
></style>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first keyword used, <code class="value">heading</code>, refers to a logical font defined somewhere else (several options are discussed in the proposal). By not allowing references to real font names as values, JEP does not need to make a distinction between string and keyword values, and this simplifies the syntax.</p>
|
||
|
|
|
||
|
|
<p>The second keyword, <code class="value">bf</code>, is shorthand for <em class="value">boldface</em>. Many of the keyword values in JEP consists of two letters.</p>
|
||
|
|
|
||
|
|
<h3 id="h-191">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>JEP has two main mechanisms for value propagation: inheritance and cascading. Both of them are different from inheritance and cascading in CSS; inheritance in JEP is more complex than in CSS, while cascading (JEP does not use this term) is simpler.</p>
|
||
|
|
|
||
|
|
<h4 id="h-192">Inheritance</h4>
|
||
|
|
|
||
|
|
<p>Inheritance is used to transfer values down from parent to child elements in the tree of elements. For some properties, JEP describes initial values (called <code class="value">default</code> in JEP), but the proposal seems to expect that most initial values are set on the root element (or an element close to the root) and use inheritance to propagate the value:</p>
|
||
|
|
|
||
|
|
<blockquote>To specify initial or global style properties, designers may use a <code class="element">STYLE</code> element applicable to the <code class="element">HTML</code> or <code class="element">BODY</code> element. Properties specified there will be inherited by all other document elements.</blockquote>
|
||
|
|
|
||
|
|
<p>In addition to inheriting property values from parent to child, <code class="element">STYLE</code> elements can inherit values from each other to avoid duplicate declarations. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="attribute">inherit</code> attributes on the last two <code class="element">STYLE</code> elements declare that the declarations in the first STYLE element also should apply to <code class="element">H1</code> and <code class="element">H2</code> elements.</p>
|
||
|
|
|
||
|
|
<p>The <code class="attribute">useset</code> attribute described in the section on <q>Selectors</q> above is similar to the <code class="attribute">inherit</code> attribute, and can be considered another value propagation mechanism.</p>
|
||
|
|
|
||
|
|
<h4 id="h-193">Cascading</h4>
|
||
|
|
|
||
|
|
<p>In addition to CHSS, JEP is the only proposal that proposes a mechanism to negotiate between author and reader preferences. JEP does not use the term <a href="#cascading" class="term">cascading</a> but the proposed mechanism is similar:</p>
|
||
|
|
|
||
|
|
<blockquote>Browsers are encouraged to provide users with the ability to configure the default style sheet. It is also desirable if users may selectively override parts of an external stylesheet without discarding the entire specification. To accomplish this, style sheets may specify a weight for each attribute. The weight is an integer from 1 to 3 for external stylesheets, and from 0 to 4 for user's configurations. A different weight may be specified for each style attribute.</blockquote>
|
||
|
|
|
||
|
|
<p>By allowing the user a wider range of weights, the user has the final word. This is a simple solution to a much-debated issue. The proposal does not, however, suggest any syntax for expressing weights.</p>
|
||
|
|
|
||
|
|
<h3 id="h-194">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>JEP describes a moderately complex formatting model with emphasis on screen-based presentations. Several advanced topics (e.g., multi-column layout and table layout) are also discussed without proposing a solution. Table 11 shows how JEP sorts HTML elements into categories:</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-11">
|
||
|
|
<p class="caption">Categories in JEP.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Category</th>
|
||
|
|
<th>HTML elements</th>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>phrases</td>
|
||
|
|
<td>b cite code em i kbd samp strong tt var</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>blocks</td>
|
||
|
|
<td>address blockquote</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>paragraphs</td>
|
||
|
|
<td>dd li p</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>lists</td>
|
||
|
|
<td>dir dl menu ol ul</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>inline display</td>
|
||
|
|
<td>img input</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>block display</td>
|
||
|
|
<td>option pre textarea</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>headings</td>
|
||
|
|
<td>dt h1 h2 h3 h4 h5 h6</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>metainfo</td>
|
||
|
|
<td>base isindex link meta nextid title</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>divisions</td>
|
||
|
|
<td>body form head html select</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>floating elements</td>
|
||
|
|
<td>-</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>Compared with CSS, JEP has more types of block-level elements: CSS1 distinguishes between <a href="#block-level_element" class="term">block-level</a> and <a href="#list-item_element" class="term">list-item</a> elements while JEP has blocks, paragraphs, lists, block display, headings and divisions. The names of the categories indicate that the motivation for sorting elements into the various categories is semantics. For example, knowing whether an element is a heading or not has semantic value, but should not – I believe – limit the presentation of the element. JEP, however, attaches different presentational capabilities to the different categories. For example, only heading elements can be shown <a href="#run-in" class="term">run-in</a>. This is similar to how different properties apply to different flow object classes in DSSSL.</p>
|
||
|
|
|
||
|
|
<p>JEP describes a sequence model for elements rather than a box model. Margin values can refer to the edge of areas as well as the edge of the containing block. This is similar to the FOSI formatting model.</p>
|
||
|
|
|
||
|
|
<p>JEP can describe advanced separators between elements, including bars and spacing. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="element">SEPSPEC</code> element in the example above describes a separator which includes two horizontal rules (<code class="element">HRULE</code>) with vertical space (<code class="element">VSPACE</code>) between and underneath them. The separator is referred to in the <span class="property">presep</span> property of the <code class="element">STYLE</code> element so that all <code class="element">H1</code> elements will have a separator before them.</p>
|
||
|
|
|
||
|
|
<h3 id="h-195">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>JEP proposes to link to external style sheets with the <code class="element">LINK</code> element in the head of the document, or in an HTTP header found when retrieving the document. HTML and CSS later used the same approach when linking to style sheets.</p>
|
||
|
|
|
||
|
|
<p>JEP also supports a way of directly referring to <code class="element">STYLE</code> elements though the <code class="attribute">style</code> attribute in the document. Here is a simple example</p>
|
||
|
|
|
||
|
|
<pre>In HTML, they are all marked up as <code
|
||
|
|
style=html-elem>CODE</code> elements, but
|
||
|
|
it would be useful...
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In order for the <code class="attribute">style</code> attribute to have an effect, the external style sheet would need to have a <code class="element">STYLE</code> element with a corresponding <code class="attribute">ID</code> attribute:</p>
|
||
|
|
|
||
|
|
<pre><style id=html-elem
|
||
|
|
fontshape=tt
|
||
|
|
fgcolor=red>
|
||
|
|
</style>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<h3 id="h-196">Generated content</h3>
|
||
|
|
|
||
|
|
<p>JEP discusses requirements for generated text, but does not contain a concrete proposal.</p>
|
||
|
|
|
||
|
|
<h3 id="h-197">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>The proposal only describes a visual formatting context, but specifically requests feedback on how to support non-visual presentations.</p>
|
||
|
|
|
||
|
|
<h3 id="h-198">JEP in context</h3>
|
||
|
|
|
||
|
|
<p>JEP is both a traditional and innovative proposal for a web style sheet language. JEP is traditional in the sense that it uses an SGML-based syntax similar to FOSI. Also, the author references and borrow features from several existing languages, including DSSSL and LaTeX. JEP is also innovative. In particular, the length units relative to the display (<code>pcd</code>, <code>nlh</code>, <code>p</code>) is a valuable contribution.</p>
|
||
|
|
|
||
|
|
<p>When JEP was published, the author wrote:</p>
|
||
|
|
|
||
|
|
<blockquote>I've been working on a stylesheet proposal on and off for several months now, and it's finally at the point where it's ready to publish. However, I'm probably going to abandon it now. There are other works in progress – particularly the DSSSL Lite proposal – which look much better.</blockquote>
|
||
|
|
|
||
|
|
<p>I must disagree with the author about the quality of his work: I personally find that JEP is a more suitable proposal than DSSSL Lite.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-199"><a id="ssfp" name="ssfp">Sketch of Simple Formatting Primitives (SSFP)</a></h2>
|
||
|
|
|
||
|
|
<p>The title of this proposal suggests it is merely an outline of simple stylistic properties. Indeed, the proposal sketches, rather than fully defines, a simple set of formatting primitives, but it is not limited to <em>primitives</em> (which is SSFP's term for <a href="#property" class="term">properties</a>). SSFP outlines a complete style sheets language including syntax, selectors, properties, values and units. The author also has strong opinions on how style sheets should be linked to documents, and goes beyond most other style sheet proposals by describing link behavior. Therefore, despite the unassuming title, the proposal qualifies for discussion in this chapter.</p>
|
||
|
|
|
||
|
|
<p>SSFP is dated September 1994 and was first published to the www-talk mailing list in November 1994 <a href="#Sperberg-McQueen_1994a">[Sperberg-McQueen 1994a]</a>. The message that announced the proposal [Sperberg-McQueen_1994b] contains additional information that is relevant to the interpretation of the proposal. For the purpose of evaluating SSFP, the announcement message is considered, therefore, to be part of the proposal.</p>
|
||
|
|
|
||
|
|
<h3 id="h-200">Syntax</h3>
|
||
|
|
|
||
|
|
<p>SSFP states that <q>notation is not specified here, but various options are obviously suitable</q>. The proposal uses a LISP-inspired syntax in all examples. Here is a simple excerpt:</p>
|
||
|
|
|
||
|
|
<pre>(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
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first line selects <code class="element">A</code> elements, while the rest of the style sheet assigns values to properties. The selected elements are set to be inline, and are given a blue color. The last line describes hypertext behavior: if the element is clicked, the value of the <code class="attribute">href</code> attribute should be followed. By describing hypertext behavior, SSFP – along with SSP – goes beyond the normal scope of style sheet languages.</p>
|
||
|
|
|
||
|
|
<h3 id="h-201">Selectors</h3>
|
||
|
|
|
||
|
|
<p>SSFP only supports one simple type of selector. The examples in the proposal select elements based on their name only. Here is an example:</p>
|
||
|
|
|
||
|
|
<pre>(style h1
|
||
|
|
(block #t)
|
||
|
|
(vspace '24pt '8pt)
|
||
|
|
(shape 'centered)
|
||
|
|
(font-size 'vlg)
|
||
|
|
(font-style 'bold)
|
||
|
|
(flow #f))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The author of the proposal is well aware of the need for more advanced selectors and the issue is discussed in the announcement message <a href="#Sperberg-McQueen_1994b">[Sperberg-McQueen 1994b]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Critical to making the logic useful is a reasonable set of primitive functions for querying one's location in the SGML document.</blockquote>
|
||
|
|
|
||
|
|
<p>The reason why more advanced selectors are not included may be that the proposal was specifically targeted for the relatively simple HTML language. This is supported in the accompanying message which states that the proposal only describes <q>the behavior of HTML browsers as described in the HTML specification</q>.</p>
|
||
|
|
|
||
|
|
<h3 id="h-202">Properties</h3>
|
||
|
|
|
||
|
|
<p>SSFP describes 13 properties and this is the simplest set of properties among the proposals discussed in this chapter. Table 12 lists the properties along with CSS equivalents.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-12">
|
||
|
|
<p class="caption">SSFP's properties along with CSS equivalents.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1" class="properties">
|
||
|
|
<tr>
|
||
|
|
<th>Property</th>
|
||
|
|
<th>Values</th>
|
||
|
|
<th>Corresponding CSS functionality</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>block</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>display</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>flow</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>white-space</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>vspace</td>
|
||
|
|
<td>two length values</td>
|
||
|
|
<td>margin-top, margin-bottom</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>margins</td>
|
||
|
|
<td>two length values</td>
|
||
|
|
<td>margin-left, margin-right</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>shape</td>
|
||
|
|
<td>normal-para, centered, flush-left, block-para, netnews-quote, indent-left, indent-twice-left</td>
|
||
|
|
<td>-</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>display-level</td>
|
||
|
|
<td>integer where '0' means hide and positive integers mean display</td>
|
||
|
|
<td>-</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font-family</td>
|
||
|
|
<td>list of font names</td>
|
||
|
|
<td>font-family</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font-size</td>
|
||
|
|
<td>integer (representing the point size) or a keyword: normal, lg, vlg, sm, vsm, huge</td>
|
||
|
|
<td>font-size</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font-style</td>
|
||
|
|
<td>roman, ital, bold</td>
|
||
|
|
<td>font-style, font-weight</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>treatment</td>
|
||
|
|
<td>normal, underlined, relined</td>
|
||
|
|
<td>text-decoration, color</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>color</td>
|
||
|
|
<td>color name (the list of names is not defined)</td>
|
||
|
|
<td>color</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>content</td>
|
||
|
|
<td>concatenation of one or more of: content(), attval(NAME), string literal</td>
|
||
|
|
<td>content</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>click</td>
|
||
|
|
<td>see below</td>
|
||
|
|
<td>-</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>Three of the properties in the table above offer functionality not found in any of the other proposals discussed in this chapter and deserve special mention:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The <code class="property">shape</code> property is listed but not described in the specification. Judging from the list of keyword values, this property determines the horizontal margins of the elements, the text alignment within the element, and even quote marks in the element's margin.</li>
|
||
|
|
|
||
|
|
<li>The <code class="property">display-level</code> property is not described in detail in the proposal but, judging from the name, it seems similar to the <code class="property">Visibility</code> property of P94 <a href="#Quint_1994">[Quint 1994]</a>. Thus, it is a way of creating outline views of the document by, for example, giving headings higher values than paragraphs. By raising/lowering the display threshold, elements become invisible/visible.</li>
|
||
|
|
|
||
|
|
<li>The <code class="property">click</code> property describes link behavior. The proposal lists two ways of describing HTML's linking behavior for the <code class="element">A</code> element:
|
||
|
|
|
||
|
|
<pre>(style a (click (follow (attval 'href))))
|
||
|
|
(style a (click 'follow-URL 'HREF))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="property">click</code> property is described in a section called <em>Actions</em> which also mentions the possibility of having a <code class="property">double-click</code> property.</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The names of SSFP's properties do not disclose whether they are relative to the writing direction or not. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>(style address
|
||
|
|
(margins '+10pica '0))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="property">margins</code> property takes two values but it is unclear if the values are absolute (left/right) or relative to the writing direction. The values of the <code class="property">shape</code> property use absolute names (e.g., <code class="value">indent-left</code>, <code class="value">indent-twice-left</code>), while the two values of the <code class="property">vspace</code> property is described as <q>vertical space before and after element</q>. SSFP therefore seems to use a mixed model with no clear preference for either absolute or relative names.</p>
|
||
|
|
|
||
|
|
<h3 id="h-203">Values and units</h3>
|
||
|
|
|
||
|
|
<p>The values and units in SSFP are similar to those used in DSSSL:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>keywords are prefixed by an apostrophe</li>
|
||
|
|
|
||
|
|
<li>true/false values are represented by <code>#t</code> and <code>#f</code>, respectively</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>There are, however, some differences in values between DSSSL and SSFP:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>SSFP length values are prefixed by an apostrophe; in DSSSL they are not</li>
|
||
|
|
|
||
|
|
<li>SSFP color names are not pre-fixed by an apostrophe, in DSSSL they are</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The list of length units is not defined anywhere in the specification but examples use the following units: <code class="unit">pt</code>, <code class="unit">pica</code>, and <code class="unit">l</code>. The last unit may refer to the line height but this is not described in the proposal.</p>
|
||
|
|
|
||
|
|
<h3 id="h-204">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>SSFP has two mechanisms for value propagation: initial values (called <em>default</em> values), and inheritance.</p>
|
||
|
|
|
||
|
|
<p>Although the specification only lists the initial value for four of the properties, it is reasonable to assume that a more developed proposal would list initial values for all properties.</p>
|
||
|
|
|
||
|
|
<p>Inheritance does not happen automatically in SSFP. However, all properties accept the <code class="value">CURRENT</code> value which specifies that the property should be inherited. <code class="attribute">INHERIT</code> is offered as a synonym for <code class="attribute">CURRENT</code>.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-205">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>Given that the proposal only describes 13 properties, the visual formatting model of SSFP is quite simple. Formatting objects are either block-level or inline. Block-level objects have:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>a <em>shape</em>, as described in the section on <em>Properties</em></li>
|
||
|
|
|
||
|
|
<li>vertical space before and after the element</li>
|
||
|
|
|
||
|
|
<li>margins on the each side of the element</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Like FOSI and JEP, length values in SSFP can be prefixed by '+' or '-' signs. This indicates that SSFP supports a FOSI-like area model where prefixed values refer to the edges of the containing block and other values refer to the edges of the area. The text, however, does not discuss this matter.</p>
|
||
|
|
|
||
|
|
<h3 id="h-206">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>The proposal argues strongly that style sheets should not be referenced from the document itself, but rather by using an HTTP header:</p>
|
||
|
|
|
||
|
|
<blockquote>I'd put the final point even more strongly: they should not be referenced from the HTML *document* at all; the link should be external to the document, established in the HTTP header, not within the HTML document.</blockquote>
|
||
|
|
|
||
|
|
<h3 id="h-207">Generated content</h3>
|
||
|
|
|
||
|
|
<p>Despite its simplicity, SSFP supports generated content through the <code class="property">content</code> property. The <code class="property">content</code> property can take one of three values. The <code class="value">content()</code> value refers to the content of the element itself and is the initial value. The <code class="value">attval(NAME)</code> value names an attribute whose value will be used instead of the element's content. The <code class="value">string literal</code> value allows the style sheet to set the content of the element. CSS2 has a property with the same name and similar values.</p>
|
||
|
|
|
||
|
|
<p>SSFP also includes a discussion on how counters could be supported.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-208">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>Not proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-209">SSFP in context</h3>
|
||
|
|
|
||
|
|
<p>SSFP is a simple proposal which borrows both from FOSI and DSSSL. The proposal shows concern for <q>low-level</q> web browsers and <q>higher level</q> implementations, presumably SGML-based products. It can be seen as an attempt to build a bridge between the web and SGML.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>The main shortcoming of the proposal is that it is immature and incomplete.</p>
|
||
|
|
|
||
|
|
<p>The main strength of the proposal is that it describes advanced functionality – notably counters, link behavior and generated text – in a simple proposal.</p>
|
||
|
|
|
||
|
|
<p>Another noteworthy achievement of SSFP is that the proposal is still available from the URL that was published in 1994 (<a href="http://tigger.cc.uic.edu/~cmsmcq/style-primitives.html">http://tigger.cc.uic.edu/~cmsmcq/style-primitives.html</a>).</p>
|
||
|
|
|
||
|
|
<h2 id="h-210"><a id="dsssl-lite" name="dsssl-lite">DSSSL Lite</a></h2>
|
||
|
|
|
||
|
|
<p>In November 1994 the SGML '94 conference was held in Tysons Corner, Virginia, USA. At the conference, a group of people met to discuss the <q>the feasibility of defining a subset of the Document Style Semantics and Specification Language (DSSSL)</q>. As discussed in the previous chapter, DSSSL is a complex specification and there was little hope of having web browsers support all of DSSSL. By defining a subset, dubbed <em class="title">DSSSL Lite</em>, the goal was to create a style sheet language that would be <q>simple yet powerful enough to provide a basis for style sheet interchange on the Web</q> <a href="#Magliery_1994">[Magliery 1994]</a>.</p>
|
||
|
|
|
||
|
|
<p>In December 1994 the <em class="title">DSSSL Lite Announcement</em> was sent to various web mailing lists and newsgroups <a href="#Magliery_1994">[Magliery 1994]</a>. It encouraged people to join efforts to create a subset of the DSSSL specification targeted for use on the web, and was sent out by Tom Magliery who was a programmer in NCSA's Mosaic team.</p>
|
||
|
|
|
||
|
|
<p>James Clark wrote the first draft. The version reviewed in this chapter is dated November 24, 1994 <a href="#Clark_1994">[Clark 1994]</a>. It is written for readers familiar with DSSSL and does not attempt to promote or teach DSSSL Lite to a wider audience.</p>
|
||
|
|
|
||
|
|
<p>The stated intention of the work was for DSSSL Lite to be a subset of DSSSL <a href="#Magliery_1994">[Magliery 1994]</a>. However, there are several discrepancies between DSSSL Lite and the DSSSL standard. For example, several of the properties listed in the DSSSL Lite proposal do not exist in DSSSL. This is probably because the DSSSL standard was not yet finalized in 1994.</p>
|
||
|
|
|
||
|
|
<p>The DSSSL Lite proposal does not contain any extended examples of how to use the language. Only small code fragments are shown, and this makes it difficult to review the proposal. I have tried to write the examples below according to the proposal.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-211">Syntax</h3>
|
||
|
|
|
||
|
|
<p>DSSSL Lite is based on DSSSL and uses the DSSSL syntax. Here is a simple example:</p>
|
||
|
|
|
||
|
|
<pre>(element H1
|
||
|
|
(paragraph font-size: 20pt))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, <code class="element">H1</code> elements are selected and turned into paragraphs with font size <code class="value">20pt</code>. A paragraph is one of 14 different flow objects in DSSSL Lite. Unlike DSSSL, DSSSL Lite does not require the <code>make</code> keyword before the name of a flow object.
|
||
|
|
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-212">Selectors</h3>
|
||
|
|
|
||
|
|
|
||
|
|
<p>DSSSL Lite offers four kinds of selectors:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><strong>type selectors</strong> select elements based on their type. The example in the previous section uses a type selector.</li>
|
||
|
|
|
||
|
|
<li><strong>contextual selectors</strong> select elements based on their type and ancestors. Here is an example which selects <code class="element">LI</code> elements which are children of <code class="element">UL</code>:
|
||
|
|
|
||
|
|
<pre>(element (UL LI)
|
||
|
|
(labeled-item)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Contextual selectors in DSSSL Lite are similar to those in CSS.</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><strong>id selectors</strong> select elements based on their unique identifier (in HTML, this is the value of the <code class="attribute">ID</code> attribute).</li>
|
||
|
|
|
||
|
|
<li>the <strong>root selector</strong> selects the root element.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>It is not possible to select elements based on their attributes. However, elements can be treated differently based on their attributes or ancestry by using the expression and query language:
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<pre>(element NOTE
|
||
|
|
(if (attribute "WARNING")
|
||
|
|
font-weight: 'bold))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
|
||
|
|
<p>The <code class="expression">if</code> statement is one of the expressions supported by DSSSL Lite. Other logical expressions, like <code class="expression">and</code> and <code class="expression">or</code> are also supported.</p>
|
||
|
|
|
||
|
|
<p>The <code class="function">attribute</code> function queries the attributes of the element. DSSSL Lite describes three functions for querying attributes:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><code class="function">attribute</code>: returns an attribute of the current element, or <code>false</code> if the current element has no such attribute;</li>
|
||
|
|
|
||
|
|
<li><code class="function">inherited-attribute</code>: returns an attribute of the current element or of the nearest ancestor for which the attribute is present; and</li>
|
||
|
|
|
||
|
|
<li><code class="function">ancestor-attribute</code>: returns the attribute of nearest ancestor of a given type.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>To handle counters, these query functions are defined:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><code class="function">child-number</code>: returns the child number of the current element, that is, the number of preceding siblings of the same type returns the child number of nearest ancestor of a given type.</li>
|
||
|
|
|
||
|
|
<li><code class="function">ancestor-child-number</code>: returns the child number of nearest ancestor.</li>
|
||
|
|
|
||
|
|
<li><code class="function">hierarchical-number</code>: returns a list of child numbers for a given list of element types. For each element type, the returned list describes the youngest ancestor of the current element.</li>
|
||
|
|
|
||
|
|
<li><code class="function">hierarchical-number-recursive</code>: returns a list of child numbers for a given element type. The length of the returned list reflects the number of elements of that type among the ancestors.</li>
|
||
|
|
|
||
|
|
<li><code class="function">element-number</code>: returns the number of elements with the same type as the current element appearing before the current element.</li>
|
||
|
|
|
||
|
|
<li><code class="function">element-number-list</code>: returns the element number for a given list of element types.</li>
|
||
|
|
|
||
|
|
<li><code class="function">first</code>: returns <code>true</code> if if the current element has no preceding sibling of the same type.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-213">Properties</h3>
|
||
|
|
|
||
|
|
<p>The DSSSL Lite proposal lists 27 properties (called <em>characteristics</em> in DSSSL). Table 13 lists the properties in the order they appear in the proposal:</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-13">
|
||
|
|
<p class="caption">The properties of DSSSL Lite.</p>
|
||
|
|
|
||
|
|
<table summary="" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Property name</th>
|
||
|
|
<th>CSS properties with similar functionality</th>
|
||
|
|
<th>Comment</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>break-before</td>
|
||
|
|
<td>display</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>first-line-start-indent</td>
|
||
|
|
<td>text-indent</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>break-after</td>
|
||
|
|
<td>display</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>space-before</td>
|
||
|
|
<td>margin-top</td>
|
||
|
|
<td rowspan="2">These properties apply to block-level flow objects</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>space-after</td>
|
||
|
|
<td>margin-bottom</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>escapement-space-before</td>
|
||
|
|
<td>margin-left</td>
|
||
|
|
<td rowspan="2">These properties apply to character-level flow objects</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>escapement-space-after</td>
|
||
|
|
<td>margin-right</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>label</td>
|
||
|
|
<td>list-style-type</td>
|
||
|
|
<td>Not present in DSSSL.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font-family-name</td>
|
||
|
|
<td>font-family</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font-weight</td>
|
||
|
|
<td>font-weight</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font-posture</td>
|
||
|
|
<td>font-style</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font-proportionate-width</td>
|
||
|
|
<td>font-width</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>font-size</td>
|
||
|
|
<td>font-size</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>score</td>
|
||
|
|
<td>text-decoration?</td>
|
||
|
|
<td>Not explained, DSSSL has several properties that describe scoring.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>placement-offset</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>Called <q>alignment-point-offset</q> in DSSSL.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>color</td>
|
||
|
|
<td>color</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>start-indent</td>
|
||
|
|
<td>margin-left</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>first-line-start-indent</td>
|
||
|
|
<td>text-indent</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>end-indent</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>Called <q>last-line-end-indent</q> in DSSSL.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>quadding</td>
|
||
|
|
<td>text-align</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>display-alignment</td>
|
||
|
|
<td>text-align, margin-left, margin-right</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>verbatim?</td>
|
||
|
|
<td>?</td>
|
||
|
|
<td>Not explained, not present in DSSSL.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>pre-line-spacing</td>
|
||
|
|
<td>line-height</td>
|
||
|
|
<td>Called <q>min-pre-line-spacing</q> in DSSSL.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>post-line-spacing</td>
|
||
|
|
<td>line-height</td>
|
||
|
|
<td>Called <q>min-post-line-spacing</q> in DSSSL.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>background-color</td>
|
||
|
|
<td>background</td>
|
||
|
|
<td>Applies only to root element.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>keep-with-previous</td>
|
||
|
|
<td>page-break-before</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>keep-with-next</td>
|
||
|
|
<td>page-break-after</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<h3 id="h-214">Values and units</h3>
|
||
|
|
|
||
|
|
<p>The proposal does not list values and units.</p>
|
||
|
|
|
||
|
|
<h3 id="h-215">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>The proposal labels properties as inherited or not. The initial values of properties are not discussed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-216">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>DSSSL Lite describes a simple visual formatting model suitable for printed and screen presentations. The model is much simpler than DSSSL:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>DSSSL Lite lists 14 flow objects compared with 35 in DSSSL (excluding DSSSL's flow objects for mathematical formulae); and</li>
|
||
|
|
|
||
|
|
<li>DSSSL Lite list 27 properties compared with more than 200 in DSSSL (excluding DSSSL's flow objects for mathematical formulae).</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The main limitations of DSSSL Lite compared with DSSSL are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>single column only;</li>
|
||
|
|
|
||
|
|
<li>no footnotes; and</li>
|
||
|
|
|
||
|
|
<li>headers and footers can only have one line.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The proposed flow objects for DSSSL Lite, in order of appearance, are: <code>root</code>, <code>paragraph</code>, <code>labeled-item</code>, <code>character</code>, <code>rule</code>, <code>leader</code>, <code>external graphic</code>, <code>table</code>, <code>table-part</code>, <code>table-row</code>, <code>inline-table-cell</code>, <code>display-table-cell</code> and <code>iconify</code>.</p>
|
||
|
|
|
||
|
|
<p>In addition, a simple variant of the <code class="fo">page-sequence</code> flow object is discussed, but not named. Most likely, the work on DSSSL Lite resulted in the <code class="fo">simple-page-sequence</code> being added to DSSSL.</p>
|
||
|
|
|
||
|
|
<h3 id="h-217">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>Like DSSSL itself, DSSSL Lite does not specify how style sheets are linked to documents.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-217b">Generated content</h3>
|
||
|
|
|
||
|
|
<h3 id="h-218">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>Not proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-219">DSSSL Lite in context</h3>
|
||
|
|
|
||
|
|
<p>The work on DSSSL Lite gained considerable support from key people in the web community. In January 1995, Dave Raggett added the <code class="element">STYLES</code> element, the <code class="element">STYLE</code> element, and the <code class="attribute">CLASS</code> attribute to the HTML 3.0 draft being developed at the time. In the draft he wrote:</p>
|
||
|
|
|
||
|
|
<blockquote>A style sheet can be associated with the document using the LINK element, e.g. <LINK rel=stylesheet href="housestyle.dsssl">. Style overrides can be placed in the document head using the STYLES element, e.g.
|
||
|
|
|
||
|
|
<pre><styles notation=dsssl-lite>
|
||
|
|
<style class=bigcaps>(dsssl-lite-stuff)
|
||
|
|
<style class=para17>(more dsssl-lite-stuff)
|
||
|
|
</styles>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<p>In May 1995, Dan Connolly of W3C wrote a personal email to Tim Berners-Lee, David Raggett, and myself:</p>
|
||
|
|
|
||
|
|
<blockquote>DSSSL-Lite, from my research, appears to be exactly "as simple as possible, and no simpler." It is not at all clear what the advantage of the other proposals is.</blockquote>
|
||
|
|
|
||
|
|
<p>The <q>other proposals</q> are further described:</p>
|
||
|
|
|
||
|
|
<blockquote>From what I've seen of Bert Bos and Hakon Lie's proposals, they're re-inventing DSSSL using X resource syntax rather than lisp s-expressions.</blockquote>
|
||
|
|
|
||
|
|
<p>His conclusion is:</p>
|
||
|
|
|
||
|
|
<blockquote>So I suggest that further development on stylesheets be based on DSSSL-Lite. Spending resources for a mechanism that isn't compatible isn't justified.</blockquote>
|
||
|
|
|
||
|
|
<p>DSSSL Lite also had strong support in the SGML community. Joe English, the person behind the JEP proposal, which he dropped in favor of DSSSL-Lite, writes in a retrospective personal email <a href="#English_2002">[English 2002]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>As to why I thought DSSSL-Lite would be the "winner" – the SGML community had been eagerly anticipating the DSSSL spec for years (literally!) with high expectations. As it turned out, DSSSL didn't take the world by storm, but at the time we all thought it would...</blockquote>
|
||
|
|
|
||
|
|
<p>Commercial vendors were also involved in the development of DSSSL Lite. At least one company announced plans to support it <a href="#EBT_1997">[EBT 1997]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>GMUNDEN, AUSTRIA (SGML EUROPE '95) May 16, 1995 – In yet another example of its standards-based philosophy, Electronic Book Technologies, Inc. (EBT, Booth # 25) today announced plans to incorporate support for the Document Style Semantics and Specification Language (DSSSL) in the next major release of DynaText(tm), EBT's industry leading standards-based online publishing system. EBT also plans to support "DSSSL Lite," currently being proposed as the stylesheet language for the World-Wide Web (Web) ...</blockquote>
|
||
|
|
|
||
|
|
<p>In October 1995, the name of the effort to create a subset of DSSSL was changed from <em class="title">DSSSL Lite</em> to <em class="title">DSSSL Online Application Profile</em>, informally referred to as <em>DSSSL-O</em>. One of the reasons for dropping the <em class="title">DSSSL Lite</em> name was that <q>'Lite' is the well-known name of a particularly insipid brand of beer</q> <a href="#Bosak_1995">[Bosak 1995]</a>. </p>
|
||
|
|
|
||
|
|
<p>DSSSL-O was completed in 1996 around the same time that DSSSL became an ISO standard. James Clark was an architect and editor of both specifications and it seems clear that the work on DSSSL Lite and DSSSL-O influenced the final design of DSSSL.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>DSSSL-O ended up being much more complex than the DSSSL Lite proposal reviewed in this chapter. Table 14 compares the number of flow object classes and properties in the three DSSSL specifications.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-14">
|
||
|
|
<p class="caption">The number of flow object classes and properties in DSSSL Lite, DSSSL-O and DSSSL.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th></th>
|
||
|
|
<th>DSSSL Lite</th>
|
||
|
|
<th>DSSSL-O</th>
|
||
|
|
<th>DSSSL</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>flow object classes</td>
|
||
|
|
<td>14</td>
|
||
|
|
<td>25</td>
|
||
|
|
<td>35<br />
|
||
|
|
(not counting math flow objects)</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>properties</td>
|
||
|
|
<td>27</td>
|
||
|
|
<td>157<br />
|
||
|
|
(not counting properties for which all values can be ignored)</td>
|
||
|
|
<td>213<br />
|
||
|
|
(not counting properties only used in math flow objects)</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>The complexity of DSSSL-O may have been a reason why it was never implemented in any browser and has never seen any real use on the web. The DSSSL community has since developed XSL <a href="#XSL_2001">[XSL 2001]</a>.
|
||
|
|
|
||
|
|
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h2 id="h-231"><a id="ssp" name="ssp">Stream-based style sheet proposal (SSP)</a></h2>
|
||
|
|
|
||
|
|
<p>In March 1995, Bert Bos published a proposal called <em class="title">Stream-based Style sheet Proposal</em> (SSP) <a href="#Bos_1995">[Bos 1995]</a>. The author emphasizes the need for a style sheet language that can present documents progressively as they are downloaded from the web into the browser, thus the name <em>stream-based</em>. The proposal starts by discussing how previous proposals perform against this requirement. Several of them, including RRP, PWP and CHSS, are able to render progressively. The only proposals dismissed for not being stream-based are DSSSL and DSSSL Lite.</p>
|
||
|
|
|
||
|
|
<p>Another feature emphasized in SSP is the ability to apply style sheets to SGML documents in addition to HTML documents.</p>
|
||
|
|
|
||
|
|
<h3 id="h-232">Syntax</h3>
|
||
|
|
|
||
|
|
<p>Here is a sample SSP style sheet fragment:</p>
|
||
|
|
|
||
|
|
<pre>HTML.justify: full
|
||
|
|
*H1.justify: center
|
||
|
|
*OL.LI.label: A
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Each line in the example above is a stylistic rule with a selector, property and value. The syntax is borrowed from X11 resource files <a href="#X11">[X11]</a>. SSP argues that the X11 resource file syntax is straightforward, human read- and writable, and supports the addressing of tree-based structures. Also, software for parsing the syntax is already available.</p>
|
||
|
|
|
||
|
|
<p>SSP distinguishes between element names and properties by case: element names are written in uppercase and properties (and media types) are written in lowercase.</p>
|
||
|
|
|
||
|
|
<h3 id="h-233">Selectors</h3>
|
||
|
|
|
||
|
|
<p>In the example above, the name of the element (e.g. <code class="element">H1</code>) is preceded by an asterisk character (*) to match all elements in the tree. Without the asterisk, only the root element (<code class="element">HTML</code> in the example above) is matched. This syntax emphasizes the structured nature of the target content and reminds authors that style sheets apply to structured documents. The approach is similar to the one taken by Pei Wei, arguably with a more readable syntax.</p>
|
||
|
|
|
||
|
|
<p>Selectors can also express parental and ancestral relationships:</p>
|
||
|
|
|
||
|
|
<pre>*OL*OL.LI.label: A
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, <code class="element">LI</code> elements with an <code class="element">OL</code> parent and another <code class="element">OL</code> as ancestor are selected.</p>
|
||
|
|
|
||
|
|
<p>SSP also proposes to extend selectors to express media types:</p>
|
||
|
|
|
||
|
|
<pre>b&w*A.textcolor: white
|
||
|
|
b&w*A.textbackground: black
|
||
|
|
monochrome*A.textcolor: black
|
||
|
|
monochrome*A.textbackground: gray80
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the first two rules apply to black-and-white devices, while the last two rules apply to monochrome devices. This method for supporting different media types is similar to CHSS.</p>
|
||
|
|
|
||
|
|
<p>Selectors in SSP can also involve the value of <code class="attribute">ID</code> attributes:</p>
|
||
|
|
|
||
|
|
<pre>*id: !ID
|
||
|
|
@p101.size: 1
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the first line establishes that for all elements, the <code class="property">id</code> property finds its value from the ID attribute (the exclamation mark denotes an attribute reference). When it has been established that the <code class="attribute">ID</code> attribute contains the value of the <code class="property">id</code> property, selectors matching ID values can written with a preceding '@' character. The second line of the example above matches any element with this attribute: <code class="attribute">ID="p101"</code></p>
|
||
|
|
|
||
|
|
<p>Thus, the simple X11 resource file syntax has been extended to express <code class="selector">ID</code> selectors. By introducing yet more symbols, the selector syntax could have been extended even further. SSP, however, chooses to add logical expressions in the declarations rather than in selectors. See the section on <em>Values</em> below. This approach is similar to P94 and DSSSL.</p>
|
||
|
|
|
||
|
|
<h3 id="h-234">Properties</h3>
|
||
|
|
|
||
|
|
<p>The properties proposed by SSP are listed in Table 15. The grouping of properties is done by this author.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-15">
|
||
|
|
<p class="caption">Properties proposed by SSP.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Property</th>
|
||
|
|
<th>Value</th>
|
||
|
|
<th>Corresponding CSS functionality</th>
|
||
|
|
<th>Comment</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Font and text properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>size</td>
|
||
|
|
<td>integer, optionally with '+' or '-' prefix</td>
|
||
|
|
<td>font-size</td>
|
||
|
|
<td>The value is an index into a table of font sizes. If a +/- prefix is present, the value is relative to the parent element's value, otherwise the value is the index itself.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>family</td>
|
||
|
|
<td>one of four generic font families: normal, alt, tt, sym</td>
|
||
|
|
<td>font-family</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>familyname</td>
|
||
|
|
<td>specific font family, e.g. <q>Univers</q></td>
|
||
|
|
<td>font-family</td>
|
||
|
|
<td>This propoerty takes precedence over <code class="property">family</code>, but only if the browser is able to provide the font.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>emphasis</td>
|
||
|
|
<td>a number selecting the level of emphasis</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>slant</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>font-style</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>bold</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>font-weight</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>underscore</td>
|
||
|
|
<td>the number of lines under the text</td>
|
||
|
|
<td>text-decoration</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>strikeout</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>text-decoration</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>textcolor</td>
|
||
|
|
<td>X11 color name</td>
|
||
|
|
<td>color</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>textbackground</td>
|
||
|
|
<td>X11 color name, or 'transparent'</td>
|
||
|
|
<td>background</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>leading</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>line-height</td>
|
||
|
|
<td>The number indicates <em>extra</em> vertical space between lines relative to the default line height. Thus, 1.0 means double-spaced lines.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>obeyspaces</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>white-space</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>nowrap</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>white-space</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>justify</td>
|
||
|
|
<td>left, right, full, center</td>
|
||
|
|
<td>text-align</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>hyphenate</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Border properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>rulebefore</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>padding-top, border-top</td>
|
||
|
|
<td>This property causes a horizontal rule to be inserted above the element, followed by the given amount of whitespace.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>ruleafter</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>padding-below, border-below</td>
|
||
|
|
<td>This property causes a horizontal rule to be inserted below the element, followed by the given amount of whitespace.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>rulethickness</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>This property describes the thickness of rules generated <!--errata: "generate" fixe to "generated"--> by <code>rulebefore</code> and <code>ruleafter</code> properties.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>frame</td>
|
||
|
|
<td>any sequence of zero or more words from `left', `right', `top', `bottom', `border'. `border' is equivalent to `left right top bottom'</td>
|
||
|
|
<td>border properties</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">White space properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>prebreak</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>margin-top</td>
|
||
|
|
<td>See discussion below</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>postbreak</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>margin-bottom</td>
|
||
|
|
<td>See discussion below</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>vmargin</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>padding-top, padding-bottom</td>
|
||
|
|
<td>Extra space to add above and below an inline object.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>hmargin</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>padding-left, padding-right</td>
|
||
|
|
<td>Extra space to add left and right of an inline object.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>leftindent</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>margin-left</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>rightindent</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>margin-right</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>parindent</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>text-indent</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>noindent</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Vertical alignment properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>valign</td>
|
||
|
|
<td>top, bottom, middle</td>
|
||
|
|
<td>vertical-align</td>
|
||
|
|
<td>Vertical alignment of an inline object.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>depth</td>
|
||
|
|
<td>integer</td>
|
||
|
|
<td>vertical-align</td>
|
||
|
|
<td>Depth below the baseline of an inline object, in pixels. This property overrides <code>valign</code>.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>raise</td>
|
||
|
|
<td>integer</td>
|
||
|
|
<td>vertical-align</td>
|
||
|
|
<td>Positive values raise the text, negative values lower it. <q>The exact positions in pixels are a property of the font.</q></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Box size properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>textwidth</td>
|
||
|
|
<td>number</td>
|
||
|
|
<td>width</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>width</td>
|
||
|
|
<td>integer</td>
|
||
|
|
<td>width</td>
|
||
|
|
<td>Width of an inline object in pixels.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>height</td>
|
||
|
|
<td>integer</td>
|
||
|
|
<td>height</td>
|
||
|
|
<td>Height of an inline object in pixels.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Properties for generated text</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>insertbefore</td>
|
||
|
|
<td>string</td>
|
||
|
|
<td>:before pseudo-element</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>insertafter</td>
|
||
|
|
<td>string</td>
|
||
|
|
<td>:after pseudo-element</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Properties for floating</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>track</td>
|
||
|
|
<td>left, right, normal</td>
|
||
|
|
<td>float</td>
|
||
|
|
<td>See discussion in the <q>Visual formatting model</q> section.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>flush</td>
|
||
|
|
<td>left, right, full</td>
|
||
|
|
<td>clear</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Table properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>table</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>display: table</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>tablerow</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>display: table-row</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>tablecell</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>display: table-cell</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>rowspan</td>
|
||
|
|
<td>integer</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>colspan</td>
|
||
|
|
<td>integer</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>caption</td>
|
||
|
|
<td>top, bottom, left, right</td>
|
||
|
|
<td>caption-side</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Classification properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>empty</td>
|
||
|
|
<td>boolean</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>title</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>ismap</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>Indicates whether an element is an <code>ismap</code> or not.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>stylesheet</td>
|
||
|
|
<td>merge, replace, override</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>language</td>
|
||
|
|
<td>ISO code for a language</td>
|
||
|
|
<td>:lang selector</td>
|
||
|
|
<td>See discussion below</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Link behavior properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>inline</td>
|
||
|
|
<td>URL of something to display in-line at the start of the element</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>id</td>
|
||
|
|
<td>an element ID</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>This value will nearly always be an attribute reference, such as <code>!ID</code>. See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>target</td>
|
||
|
|
<td>element ID</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>anchor</td>
|
||
|
|
<td>URL</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>anchorshape</td>
|
||
|
|
<td></td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>anchorcoords</td>
|
||
|
|
<td></td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="4">Other properties</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>label</td>
|
||
|
|
<td>A, a, 1, I, i, bullet, square, -, *, names of symbols (resp. auto-numbering uppercase letters, lowercase letters, Arabic numbers, Roman numerals, lowercase Roman numerals, bullets, squares, dashes, asterisks, WWW-icons).</td>
|
||
|
|
<td>list-style-type</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>hide</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>visibility</td>
|
||
|
|
<td></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>minimized</td>
|
||
|
|
<td>true/false</td>
|
||
|
|
<td>-</td>
|
||
|
|
<td>See discussion below.</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>Some of the properties listed above deserve farther discussion:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><code class="property">emphasis</code>: this property takes an integer value from zero and upwards to express levels of emphasis. The property does not say anything about how the level of emphasis is to be formatted, leaving this issue to the browser. Thus, this property says more about semantics than presentation. This is unusual in a style sheet language. When in conflict with other, more presentation-oriented properties, this property will be overridden.</li>
|
||
|
|
|
||
|
|
<li><code class="property">prebreak</code>/<code class="property">postbreak</code>: these properties indicate the minimum amount of white space above/below the element. The concept of minimum space (rather than exact space) is also used in CSS.</li>
|
||
|
|
|
||
|
|
|
||
|
|
<li><code class="property">minimized</code>: if true, this property indicates that the element is replaced by a marker. When clicked, the marker will show the content of the element. This feature is an example of interactive behavior which has not been taken up by other style sheet languages.</li>
|
||
|
|
|
||
|
|
<li><code class="property">noindent</code>: This property suppresses first-line text indentation on the <em>next</em> paragraph. Typically, first-line text indentation is suppressed on paragraphs <em>following</em> a headline and, since it is easier to select headline elements than to select elements following a headline, this property simplifies the style specification.</li>
|
||
|
|
|
||
|
|
<li><code class="property">empty</code>/<code class="property">id</code>: the <code class="property">empty</code> property indicates whether an element is empty or not, and the <code class="property">id</code> property names the attribute that contains the ID of elements. In SGML, this information is stored in the DTD. SGML browsers have few other reasons for consulting the DTD than to find what elements are empty and what attribute is the ID attribute. By storing this information in a style sheet, SSP challenges the need for DTDs.</li>
|
||
|
|
|
||
|
|
<li><code class="property">title</code>/<code class="property">stylesheet</code>: these properties identify which elements contain titles and style sheets, respectively. By using these properties it is possible to turn any SGML element into HTML's <code class="element">TITLE</code> or <code class="element">STYLE</code> element. The values of the <code class="property">stylesheet</code> property allow style sheets to be merged in various ways. This feature is further described in the <em>Value propagation</em> section below.</li>
|
||
|
|
|
||
|
|
<li><code class="property">target</code>/<code class="property">anchor</code>/<code class="property">anchorshape</code>/<code class="property">anchorcoords</code>: these properties identify anchors and targets in the source documents, thereby making hyperlinking possible. They go beyond traditional style sheets by describing the behavior of documents in addition to the presentation thereof.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-235">Values and units</h3>
|
||
|
|
|
||
|
|
<p>SSP offers a range of values from the very simple to the complex. In practice – where practice is defined by the sample style sheets in the proposal – the simple values cover most needs, while the advanced values solve specific problems.</p>
|
||
|
|
|
||
|
|
<p>There are four different kinds of simple values (called <em>explicit values</em>) in SSP: integer, decimal number, keyword and string. Each property only accepts one kind of simple value. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>*H2.size: 1
|
||
|
|
*HR.rulethickness: 0.1
|
||
|
|
*H2.justify: left
|
||
|
|
*H2.familyname: Gill Sans
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first rule in the example above assigns an integer value to the <code class="property">size</code> property on <code class="element">H2</code> elements. The <code class="property">size</code> property only accepts integer values (which serve as indexes into a browser-defined table) and, therefore, there is no need for unit identifiers. The second rule assigns a real number (not an integer) to the <code class="property">rulethickness</code> property. The value is relative to the line height. In the third rule, the <code class="property">justify</code> property is assigned the value <code class="value">left</code>. The value in the fourth rule is the name of a font family and since the list of font names is open-ended, the value is a string rather than a keyword. However, since the property only accepts one simple kind of value, there is no need to differentiate strings from keywords syntactically.</p>
|
||
|
|
|
||
|
|
<p>In addition to the simple values, SSP has three advanced values: attribute references, property references, and the <code class="value">ifmatch</code> function.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h4 id="h-236">Attribute references</h4>
|
||
|
|
|
||
|
|
<p>Here is an example of how attribute references can be used:</p>
|
||
|
|
|
||
|
|
<pre>*IMG.width: !WIDTH
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In this example, the <code class="property">width</code> property is assigned the value of the <code class="attribute">WIDTH</code> attribute of the <code class="element">IMG</code> element. In HTML, the <code class="element">IMG</code> element has a <code class="attribute">WIDTH</code> attribute which takes an integer as a value. Since the <code class="property">width</code> property in SSP also accepts an integer value representing pixels, the simple rule transfers presentational information from the markup to the style sheet language. A similar rule can be written for the height.</p>
|
||
|
|
|
||
|
|
<p>The simplistic beauty of the above example, however, also imposes a serious restriction: only one type of value can be transferred (in this case pixels). The system is not able to handle percentage values which are also legal according to HTML.</p>
|
||
|
|
|
||
|
|
<h4 id="h-237">Property references</h4>
|
||
|
|
|
||
|
|
<p>Property references are described briefly in the proposal, but only an incomplete example is given. The following example is constructed by this author:</p>
|
||
|
|
|
||
|
|
<pre>PRE.width: $width
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The value in the example above is the name of a property (<code class="property">width</code>) preceded by a <code>$</code> sign, which indicates that the value should be fetched from the parent element. The effect in the example is to make the <code class="property">width</code> property inherit for <code class="element">PRE</code> elements.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-238">Built-in functions</h4>
|
||
|
|
|
||
|
|
<p>The most advanced value in SSP is the <code class="value">ifmatch</code> built-in function. Consider this example (which is the only example using <code class="value">ifmatch</code> in the proposal):</p>
|
||
|
|
|
||
|
|
<pre>*IMG.ismap: @ifmatch(!ISMAP, "ISMAP", true, false)
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>One purpose of the <code class="value">ifmatch</code> function is to address the limitation of attribute references described above. The attribute reference (<code>!ISMAP</code>) only returns the value of an attribute. If the attribute value does not match exactly the values accepted by an element, they can be transformed by the <code class="value">ifmatch</code> property. In the example above, the <code class="property">ismap</code> property accepts <code class="value">true</code> and <code class="value">false</code> and this is what the <code class="value">ifmatch</code> function returns. The function returns <code class="value">true</code> if the value of the <code class="attribute">ISMAP</code> attribute is equal to the regular expression given as the second argument to the function. Otherwise <code class="value">false</code> is returned.</p>
|
||
|
|
|
||
|
|
<p>The <code class="value">ifmatch</code> function is a complex value, both for authors and for implementations. No other style sheet language uses regular expressions as values, and SSP's author later changed his mind on this topic <a href="#Bos_1998">[Bos 1998]</a>.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-239">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>SSP relies on two familiar mechanisms for value propagation: inheritance and initial values. Also, there is a mechanism for combining several style sheets.</p>
|
||
|
|
|
||
|
|
<p>For each property, the proposal specifies whether or not it is inherited. Non-inherited properties can be made to inherit by using property references, as described above.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>SSP's <code class="property">stylesheet</code> property declares that the element contains a style sheet. The style sheet contained in the element can either merge with other style sheets, replace other style sheets, or override other style sheets. This mechanism has some resemblance with cascading in the sense that it is able to combine stylistic rules from several different style sheets. However, merging is defined to mean that the two style sheets are simply concatenated, giving the first style sheet priority in case of conflict. Also, the mechanism has no notion of the origin of the style sheet (user/author/browser).</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-240">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>Compared with the other proposals discussed in this chapter, SSP describes an advanced formatting model. In addition to basic inline and block-level elements, floating elements, tables and captions are discussed.</p>
|
||
|
|
|
||
|
|
<p>SSP employs a box model where child elements are inside their parent.</p>
|
||
|
|
|
||
|
|
<p>Surprisingly, there is no property that explicitly distinguishes between the two basic types of element: block-level and inline. Instead, some properties imply that an element is block-level. That is, if any of these properties (e.g., <code class="property">prebreak</code>, <code class="property">ruleafter</code>, <code class="property">leftindent</code>) has a non-default value the element becomes block-level, otherwise it is inline.</p>
|
||
|
|
|
||
|
|
<p>Floating elements are supported through the <code class="property">track</code> and <code class="property">flush</code> properties. SSP defines three <em>tracks</em> – <code class="value">left</code>, <code class="value">center</code> and <code class="value">right</code> – into which an element can be put. When elements are put in the left or right tracks, the elements in the center track will flow around them. The <code class="property">flush</code> property indicates whether an element can reside next to floated content or not. Here is an example of its use:</p>
|
||
|
|
|
||
|
|
<pre>*IMG.track: right
|
||
|
|
*H1.flush: full
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Here, <code class="element">IMG</code> elements are floated to the right while <code class="element">H1</code> elements will always be placed underneath a floating element. CSS has adopted the SSP model for floating elements, but uses different property names.</p>
|
||
|
|
|
||
|
|
<p>Tables are achieved in SSP by classifying elements into rows, cells and the main table container:</p>
|
||
|
|
|
||
|
|
<pre>*TR.tablerow: true
|
||
|
|
*TD.tablecell: true
|
||
|
|
*TABLE.table: true
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above maps HTML's table elements to SSP table formatting.</p>
|
||
|
|
|
||
|
|
<h3 id="h-241">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>SSP provides a way to embed style sheets into documents. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre><DOCUMENT>
|
||
|
|
<STYLE>
|
||
|
|
*STYLE.stylesheet: true
|
||
|
|
</STYLE>
|
||
|
|
</DOCUMENT>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Here, the rule inside the <code class="element">STYLE</code> element declares that the <code class="element">STYLE</code> element contains a style sheet. For the parser, however, the information in the <code class="property">stylesheet</code> property comes too late – in order to understand the style rule, the parser must know that the element contains a style sheet.</p>
|
||
|
|
|
||
|
|
<p>The proposal considers links to external style sheets to be outside its scope but, nonetheless, describes various ways of linking. The options discussed are:</p>
|
||
|
|
|
||
|
|
<blockquote>
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>In the LINK tag of HTML. This is unsatisfactory for several reasons: (1) it is too late, the document has already started before the link is found; (2) it doesn't work for non-HTML.</li>
|
||
|
|
|
||
|
|
<li>In a new header line of the HTTP protocol. This is better, but it relies on HTTP being used.</li>
|
||
|
|
|
||
|
|
<li>As part of a MIME/multipart document.</li>
|
||
|
|
|
||
|
|
<li>In the URL. A bad idea, not only because the style doesn't really `belong' to the document, but also because the URL would become too long.</li>
|
||
|
|
|
||
|
|
<li>The other way round: a hyperlink contains not the URL of the document, but of its style sheet, which in turn references the document (in a new `document' property).</li>
|
||
|
|
|
||
|
|
<li>As an attribute of A: <A HREF="doc.html" STYLE="doc.sty"></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<h3 id="h-242">Generated content</h3>
|
||
|
|
|
||
|
|
<p>SSP supports a simple way of adding text to the beginning and end of elements. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>*Q.insertbefore: `
|
||
|
|
*Q.insertafter: '
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Two properties, <code class="property">insertbefore</code> and <code class="property">insertafter</code>, contain the text that should be added. There is no way to style the generated text differently from the content of the element.</p>
|
||
|
|
|
||
|
|
<h3 id="h-243">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>The proposal briefly discusses the possibility of supporting other output devices, but no mechanism is proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-244">SSP in context</h3>
|
||
|
|
|
||
|
|
<p>Although SSP is a fairly short and simple proposal, it goes further than most other web style sheet proposals in two areas. First, it describes a relatively sophisticated formatting model including tables, floating elements and minimum (as opposed to exact) vertical margins.</p>
|
||
|
|
|
||
|
|
<p>Second, SSP style sheets contain more non-stylistic information than other languages. For example, information about the content language, link behavior, which attribute contains the ID value, and whether or not an element is empty can be represented. To some extent, SSP challenges SGML's DTD by providing an alternative – and much simpler – syntax for the same information.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>SSP is notably sparse in the number of units it suggests. Units are tied to properties and values, therefore, do not need unit identifiers. The length units are limited to ems, lines and pixels.</p>
|
||
|
|
|
||
|
|
<p>The author of SSP, Bert Bos, later joined W3C to work with this author on style sheets. Thus SSP had an strong influence on the development CSS.</p>
|
||
|
|
|
||
|
|
<p>Like SSFP, the SSP specification is still available from its original URL.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-245"><a id="psl" name="psl">PSL96</a></h2>
|
||
|
|
|
||
|
|
<p>PSL is a <em>presentation specification language</em> developed by Ethan Munson and his team at the University of Wisconsin-Milwaukee <a href="#Munson_1996">[Munson 1996]</a> <a href="#Marden_1998">[Marden&Munson 1998]</a>. The PSL language is inspired by – and builds upon – the P language discussed in the previous chapter. Unlike the other proposals described in this chapter, PSL was not put forward as a proposal to be discussed on the www-talk mailing lists. Instead PSL was, like P, described in research papers, and implementations were made available in the form of a source code library called <em>Proteus</em>.</p>
|
||
|
|
|
||
|
|
<p>The PSL language evolved over time. The initial description of Proteus in a paper from 1992 <a href="#Graham_1992">[Graham, et al. 1992]</a> described a <em>presentation schema language</em> but did not use the acronym PSL. The syntax of PSL in 1992 is very close to that of P, and the same syntax is used in Munson's PhD thesis of 1994 <a href="#Munson_1994">[Munson 1994]</a>. However, a paper of 1996 <a href="#Munson_1996">[Munson 1996]</a> describes an evolved syntax and PSL is proposed as a style sheet language for the web. To distinguish this language from earlier languages, the language reviewed will be referred to as <em>PSL96</em>. Another paper from 1998 <a href="#Marden_1998">[Marden&Munson 1998]</a> further describes PSL96 and gives code examples. Also, the title of the 1998 paper (<em>PSL: An Alternate Approach to Style Sheet Languages for the World Wide Web</em>) promotes PSL96 as a style sheet language for the web.</p>
|
||
|
|
|
||
|
|
<p>Both papers are written in a scientific style. This gives readers a quick grasp of the language but does not serve to make them complete proposals. For example, none of the papers gives a list of proposed properties.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-246">Syntax</h3>
|
||
|
|
|
||
|
|
<p>PSL96, in its simplest form, looks similar to CSS. Here is a simple fragment:</p>
|
||
|
|
|
||
|
|
<pre>H1 {
|
||
|
|
fontSize: 20;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>This would have been a valid CSS style sheet if the property was <code class="property">font-size</code>, and the value had a unit identifier (e.g. <code class="unit">px</code>).</p>
|
||
|
|
|
||
|
|
<p>PSL96 uses curly brackets to indicate blocks where P94 uses <code>begin</code> and <code>end</code> keywords. As such, PSL96 resembles the C programming language while P94 draws upon Pascal. The newer PSL96 syntax is arguably easier to read and is also similar to CSS.</p>
|
||
|
|
|
||
|
|
<p>The above example is not a complete style sheet on its own. A PSL96 style sheet consists of four sections: <code>HEADER</code>, <code>DEFAULT</code>, <code>ELABORATIONS</code>, and <code>RULES</code>. Here is a simple style sheet with a <code>DEFAULT</code> and <code>RULES</code> section:</p>
|
||
|
|
|
||
|
|
<pre>DEFAULT {
|
||
|
|
lineHeight = Self.fontSize * 1.5;
|
||
|
|
}
|
||
|
|
RULES {
|
||
|
|
P {
|
||
|
|
fontFamily = "times";
|
||
|
|
fontSize = 14;
|
||
|
|
}
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The rule in the <code>DEFAULT</code> section is applied to elements if no other rule sets the value for <code class="property">lineHeight</code>. The rule expresses that the line height is the font size of the element itself (<code class="value">Self</code>) multiplied with 1.5. This is an example of a constraint which expresses a relationship between two values on the same element. PSL96 can also express constraints between values on different elements, and geometrical constraints between the bounding boxes of different elements. Geometrical constraints have their own syntax:</p>
|
||
|
|
|
||
|
|
<pre>LI {
|
||
|
|
VertPos: Top = LeftSib . Actual Bottom;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above expresses that the vertical position (<code class="property">VertPos</code>) of an <code class="element">LI</code> element is described by a constraint: the top (<code class="property">Top</code>) of the element should be in the same place as the left sibling's (<code class="value">LeftSib</code>, i.e., older sibling) actual bottom (<code class="value">Actual bottom</code>) position. The distinction between actual and specified positions is one of the differences between P94 and PSL96.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-248">Selectors</h3>
|
||
|
|
|
||
|
|
<p>PSL96, like DSSSL and P93, use simple element name selectors. Here is a simple example to style an <code class="element">A</code> element like Mosaic <a href="#Mosaic">[Mosaic]</a> displays links:</p>
|
||
|
|
|
||
|
|
<pre>A {
|
||
|
|
fgColor = "blue";
|
||
|
|
underlineNumber = 1;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In HTML, only <code class="element">A</code> elements with <code class="attribute">HREF</code> attributes are links. This can be described in PSL96 by adding a logical expression within the block:</p>
|
||
|
|
|
||
|
|
<pre>A {
|
||
|
|
if (getAttribute(self, "href") != "") then
|
||
|
|
fgColor = "blue";
|
||
|
|
underlineNumber = 1;
|
||
|
|
endif
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>While curly brackets mark the outer block, the inner block is marked by keywords (<code>then</code>, <code>endif</code>).</p>
|
||
|
|
|
||
|
|
<h3 id="h-249">Properties</h3>
|
||
|
|
|
||
|
|
<p>PSL96 has a notion of <em>schemas</em> which may differ from one media to another <a href="#Munson_1996">[Munson 1996]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>The grammar for all PSL schemas is the same, but the details (primitive types, attributes, and dimensions) change between media.</blockquote>
|
||
|
|
|
||
|
|
<p>Thus, PSL96 does not define a set of properties (called <em>attributes</em> in the quote above) but delegates this to the schema associated with a media type [Munson 1996]:</p>
|
||
|
|
|
||
|
|
<blockquote>For instance, Ensemble's text medium currently has 15 attributes controlling font (FontFamily, Size, Bold, and Italic), hyphenation (Hyphenate, MinHyph, MinLeft, MinRight), justification, indentation, line-spacing, visibility, foreground color, and background color.</blockquote>
|
||
|
|
|
||
|
|
<p>The Ensemble system <a href="#Graham_1992">[Graham 1992]</a> also supports the <code>video</code> and <code>graphics</code> media, which have their own properties. For example, <code>graphics</code> has the <code class="property">StrokeWidth</code> and <code class="property">Rotation</code> properties <a href="#Munson_1996">[Munson 1996]</a>.</p>
|
||
|
|
|
||
|
|
<h3 id="h-250">Values and units</h3>
|
||
|
|
|
||
|
|
<p>As described above, PSL96 does not describe properties but leaves this to a presentation schema. For the purpose of this discussion, however, this author assumes that the text schema is part of the PSL96 language.</p>
|
||
|
|
|
||
|
|
<p>Each PSL96 property accepts one of these values: boolean, string, real, or <em>application-specific enumeration</em>. The value can either be explicit, or can be an expression that returns a value.</p>
|
||
|
|
|
||
|
|
<p>The explicit values in PSL96 are fairly generic. Here are some examples:</p>
|
||
|
|
|
||
|
|
<pre>HTML {
|
||
|
|
fontFamily = "times";
|
||
|
|
fontSize = 14;
|
||
|
|
fgColor = "black";
|
||
|
|
visible = No;
|
||
|
|
}
|
||
|
|
H1 {
|
||
|
|
fontFamily = "helvetica";
|
||
|
|
fontSize = 18;
|
||
|
|
visible = Yes;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>PSL96 does not support different length units. Only numbers are allowed as values and it is up to the application to interpret the value <a href="#Munson_2003">[Munson 2003]</a>.</p>
|
||
|
|
|
||
|
|
<h4 id="h-252">Expressions</h4>
|
||
|
|
|
||
|
|
<p>The expression language is what makes values in PSL96 interesting. Expressions in PSL96 are based on P94, but go further by allowing constraints between arbitrary elements to be described. The format of the expressions is:</p>
|
||
|
|
|
||
|
|
<pre> <property> = <node expression> . <property>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The purpose of the node expression is to identify an element from which a property value can be fetched. PSL96 provides a set of functions that can be combined to form a node expression: <code class="value">Parent</code>, <code class="value">LeftSib</code>, <code class="value">RightSib</code>, <code class="value">FirstChild</code>, <code class="value">LastChild</code>, <code class="value">NthChild</code>, <code class="value">Root</code>, <code class="value">AncestorOfType</code>, <code class="value">Creator</code>, and <code class="value">AllChildren</code>. Here are some examples:</p>
|
||
|
|
|
||
|
|
<pre>P { fontSize = Root . fontSize }
|
||
|
|
UL { Width = AllChildren . Width }
|
||
|
|
TD { HorizPos: Left = LeftSib . Right }
|
||
|
|
P { fontSize = FirstChild(LeftSib(Parent)) . fontSize }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first example sets the font size of <code class="element">P</code> elements to be equal to the root element's font size. The second example makes the width of the <code class="element">UL</code> element equal to the width of all its children. The third example makes the left edge of a <code class="element">TD</code> element equal to the right edge of its left sibling, thereby laying <code class="element">TD</code> elements out horizontally. The fourth example shows how node expressions can become complex; <code class="element">P</code> elements are set to use the same font size as their parent's left sibling's first child.</p>
|
||
|
|
|
||
|
|
<p>PSL96 expressions can also include mathematical operators common to general-purpose programming languages including arithmetic, comparison, and boolean operators. Also, common mathematical functions (such as <code class="function">min</code>, <code class="function">max</code>, and <code class="function">round</code>) and trigonometric functions are available. Here is an example which stacks <code class="element">LI</code> elements on top of each other, except for the middle element which starts another stack of elements to the right of the existing one:</p>
|
||
|
|
|
||
|
|
<pre>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
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<h4 id="h-253">Specified versus actual values</h4>
|
||
|
|
|
||
|
|
<p>PSL96 recognizes the difference between <a href="#specified_value" class="term">specified</a> and <a href="#actual_value" class="term">actual</a> values and allows geometrical constraints to refer to either. Consider these two rules:</p>
|
||
|
|
|
||
|
|
<pre> UL { Width = AllChildren . Width }
|
||
|
|
UL { Width = AllChildren . Actual Width }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the first rule, the width of the <code class="element">UL</code> element is set to the specified width of its children (i.e., not taking their content into account). The second rule refers to the actual width of its children, which may be smaller since the content of the child elements may not fill the entire specified width.<span class="fn">The above example also shows a difference between the formatting models of PS96 and CSS: block-level elements in CSS will, unless specified otherwise, fill the entire width of their parent element regardless of content. This does not seem to be the case in P94/PSL96.</span>
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-254">Value propagation</h3>
|
||
|
|
|
||
|
|
<p>PSL96 has four mechanisms for value propagation. In descending order of precedence, they are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>geometrical constraints: expressions can declare explicit geometrical constraints between boxes and, thereby, propagate values;</li>
|
||
|
|
|
||
|
|
<li>explicit default rules: these are the rules listed in the DEFAULT section of the style sheet; and</li>
|
||
|
|
|
||
|
|
<li>implicit default rules: in cases where the explicit default rule fails or does not exist, the implicit default rule will be used. For example, the implicit default rule can set properties to be inherited by using a rule of the form: <code>Property = Partent . Property</code>.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-255">Visual formatting model</h3>
|
||
|
|
|
||
|
|
<p>The visual formatting model of PSL96 is similar to P94. Both are based on a hierarchy of rectangular boxes some of which correspond to elements in the source document.</p>
|
||
|
|
|
||
|
|
<p>In addition to the capabilities of P94, PSL96 can do <a href="#out-of-order_rendering">out-of-order rendering</a>. It can be argued that out-of-order formatting is not a feature of the formatting model itself but, rather, the transformation between a logical structure and a presentation structure. However, in the case of PSL96, out-of-order formatting is so tightly integrated with the geometry of the visual formatting model that it deserves a discussion in this section.</p>
|
||
|
|
|
||
|
|
<p>The role of transformation languages in the context of style sheets was discussed in Chapter 2. Style sheet languages, generally, can be split into two groups: those that are transformation languages and those that are stream-based. The major benefit of being a transformation language is that content can be reordered: content does not have to be presented in the order it is received. The downside to transformations is that progressive rendering no longer can be supported.</p>
|
||
|
|
|
||
|
|
<p>PSL96 is an interesting midpoint between transformation languages and stream-based languages. PSL96 supports out-of-order presentation of content without becoming a fully fledged transformation language. This is achieved by placing geometrical constraints on elements. Consider the following:</p>
|
||
|
|
|
||
|
|
<pre><TABLE>
|
||
|
|
<CAPTION>The table's caption</CAPTION>
|
||
|
|
<TR><TD>1</TD><TD>2</TD></TR>
|
||
|
|
<TR><TD>3</TD><TD>4</TD></TR>
|
||
|
|
</TABLE>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="element">CAPTION</code> element is the first child of <code class="element">TABLE</code>. In some cases one may want the caption shown underneath the content of the table and this presentation can easily be achieved in PSL96:</p>
|
||
|
|
|
||
|
|
<pre>CAPTION { VertPos: Top = Parent . Bottom }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-256">Linking mechanism</h3>
|
||
|
|
|
||
|
|
<p>Each PSL96 style sheet has a <code>HEADER</code> section that declares the kind of medium described by the style sheet describes (examples include <code>Text</code> and <code>Mosaic</code>), the name of the view and the document language to which the style sheet applies. Here is a sample <code>HEADER</code> section:</p>
|
||
|
|
|
||
|
|
<pre>MEDIUM mosaic;
|
||
|
|
PRESENTATION links FOR html;
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the medium is <code>Mosaic</code> (which, at one point, was synonymous with the web). The name of the view is <code>links</code> and the style sheet can be applied to HTML documents.</p>
|
||
|
|
|
||
|
|
<h3 id="h-257">Generated content</h3>
|
||
|
|
|
||
|
|
<p>PSL96 has rich support for generated content. The underlying model is similar to P94, but PSL96 uses different names and offers slightly enriched functionality. Generated content is called <em>tree elaborations</em> by PSL96 and the generated content is described in a section of the style sheet called <code>ELABORATIONS</code>. Here is an example:</p>
|
||
|
|
|
||
|
|
<pre>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);
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The style sheet above describes a presentation of links where the content of the <code class="element">A</code> element is shown in blue, underlined text. The last rule of the style sheet creates a set of boxes to the right of the link text: first an arrow, then the URL and, finally, a line break. The arrow and the line break are described by inserting HTML markup into the presentational structure. The concept of <em>generated markup</em> rather than <a href="#generated_content" class="term">generated content</a> gives PSL96 functionality normally associated with transformation languages without becoming a transformation language of its own.</p>
|
||
|
|
|
||
|
|
<h3 id="h-258">Other formatting contexts</h3>
|
||
|
|
|
||
|
|
<p>One of the goals of the research behind PSL is to investigate how style sheets can be used to describe presentations of different <em>media</em>. (The concept is similar to <a href="#media_type" class="term">media types</a> in CSS.) Munson <a href="#Munson_1994">[Munson 1994]</a> describes how the Proteus system has been adapted to three different media types: text, two-dimensional graphics and digital video. In order to support a new media type, the <em>elements of a medium</em> must be known. According to <a href="#Munson_1994">[Munson 1994]</a>, the elements of a media type are: <q>the set of primitive object types, a set of dimensions in which objects are laid out, and a set of parameterized formatting operations</q>. This idea is further developed in <a href="#Munson_1999">[Munson&Pfeiffer 1999]</a>, which defines the MSPEC language for describing a media type.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-259">PSL96 in context</h3>
|
||
|
|
|
||
|
|
<p>The PSL96 language was developed in a research environment over a decade starting about 1990. The language is closely related to the P language (of which the 1994 version is described in the previous chapter). It reuses all major parts of P94.</p>
|
||
|
|
|
||
|
|
<p>PSL96 uses a more readable syntax than P94. Although not fully consistent, the use of curly brackets instead of keywords and the colon sign (which is overloaded in P94) makes PSL96 a more friendly language for humans. Also, PSL96 offers novel functionality compared with P94 and other style sheet languages:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>PSL96 offers a node expression language which is used to declare constraints between arbitrary elements. This allows PSL96 style sheets to present content out of order without requiring a transformation language. However, <a href="#out-of-order_rendering" class="term">out-of-order rendering</a> makes progressive rendering difficult, if not impossible.</li>
|
||
|
|
|
||
|
|
<li>Most style sheet languages support generated content, but PSL96 is the first to propose that the style sheet should be able to generate <em>markup</em>. This feature is another example of how PSL96 provides functionality normally associated with transformation languages, without actually being a transformation language.</li>
|
||
|
|
|
||
|
|
<li>PSL96 recognizes the difference between specified and actual values and allows geometrical constraints to refer to either.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>In several publications, PSL96 was proposed as a style sheet language for the web <a href="#Munson_1996">[Munson 1996]</a> <a href="#Marden_1998">[Marden&Munson 1998]</a> <a href="#Marden_1999">[Marden&Munson 1999]</a>. While PSL96 contains features that would be useful in a web context, the language has problems that would need to be resolved before it could be implemented interoperably on the web. The most serious problem is that PSL96 is more of a framework, for defining style sheet languages for different media, than a well-defined style sheet language for the web. PSL96 does not have a clearly defined list of properties and values from which implementors can start working. It leaves this to media-type schema. If the <code>text</code> schema is considered to be part of the PSL96 language (as the discussion above does), one is closer to having a complete proposal.</p>
|
||
|
|
|
||
|
|
<p>The problem of extensibility remains yet. One of the features of PSL96 is that it can be extended: client applications can offer access to functionality that otherwise is not part of the PSL96 language. Most often, however, extensibility conflicts with interoperability since an extensible language will result in many different profiles of use. A style sheet language, which is generally used to express non-vital presentations, is probably better suited for different profiles than most other languages. To this author, though, it still seems a better idea to define functionality in a specification rather than leaving it up to applications.</p>
|
||
|
|
|
||
|
|
<p>The PSL96 authors observe <a href="#Munson_1996">[Munson 1996]</a> that while there is a long history of research on structured document editors, relatively little research has been done on style sheet languages (or <em>presentation specification languages</em> as PSL96 calls them). In another article <a href="#Marden_1999">[Marden&Munson 1999]</a> this view is posed in stronger terms: <q>Style sheet languages are terribly underresearched</q>. While PSL96 has not seen much use outside the research communities, the research performed by – and provoked by – the PSL team has been a significant contribution to the understanding of style sheet languages.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-260">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>In the period 1993-1996 nine different style sheet languages were proposed for the web, and HTML is the primary document language for all proposals. With the exception of PSL96, all proposals were either quite simple from the outset, or simplified subsets of style sheet languages developed before the web. (PSL96 is an exception since it extends P94, rather than simplifying it.) None of the proposed style sheet languages saw any real use on the web, but two of them (CHSS and SSP) formed the basis for CSS.</p>
|
||
|
|
|
||
|
|
<p>This chapter has reviewed the proposals according to criteria established in the previous chapter. The next chapter illustrates how all style sheet languages reviewed so far, both those developed before and for the web, fulfill the requirements of the web.
|
||
|
|
|
||
|
|
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-webreq" title="Web requirements">
|
||
|
|
<h1 class="chapter" id="h-272">Web requirements</h1>
|
||
|
|
|
||
|
|
|
||
|
|
<p>In the previous two chapters, style sheet languages and proposals have been evaluated according to the criteria established in Chapter 3. These evaluations have established that the languages are, indeed, style sheet languages and that the proposals could be developed into style sheet languages. However, the suitability of these languages for the web has not been evaluated. Their evaluation is the topic of this chapter.</p>
|
||
|
|
|
||
|
|
<h2 id="h-272b">Web characteristics formulated as requirements</h2>
|
||
|
|
|
||
|
|
<p>In order to evaluate suitability for web use, a set of requirements must be established. Six key web characteristics that are likely to influence the design of style sheet languages for the web are listed in the <a href="#ch-introduction">Chapter 1</a>. These are revisited below and reformulated as requirements for web style sheet languages.</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Later binding requires <em>stream-based style sheets</em>: On the web, the content and the style sheet can be combined into a presentation at a very late stage: in the user's computer. Current web browsers use <a href="#progressive_rendering" class="term">progressive rendering</a> to display information as it is downloaded from the web and it is important that the introduction of a style sheet does not slow down the presentation. Therefore, it is requirement that style sheets can be applied to documents as they are downloaded. One of the reviewed style sheet proposals has lent its name (<em class="title">Stream-based Style sheet Proposal</em>) to this requirement.</li>
|
||
|
|
|
||
|
|
|
||
|
|
<li>Screen-centric publishing requires support for <em>screen-based properties, values and units</em>: Print and screen are both visual media types and they can reuse many of the same properties, values and units. However, in order to optimize presentations for computer screens, it is necessary to support some extra properties, values and units. For example, setting the background of a textual element is common in screen-based designs, and a pixel unit is required to ensure that (say) a border is exactly one pixel wide.
|
||
|
|
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>Shared author/user influence requires <em>negotiation between conflicting stylistic preferences</em>: The added flexibility of later binding makes it possible for both users and authors to influence the presentation and it seems reasonable to make this a requirement for style sheet languages on the web. One way of supporting presentational negotiation is to combine style sheets from several sources.</li>
|
||
|
|
|
||
|
|
|
||
|
|
<li>Multiple outputs require <em>media-specific style sheets</em>: Web content is displayed on many types of output devices and style sheets must be able to express presentations for a range of such. For example, are there properties for non-visual media? Are units suitable for different types of output devices? Finally, can the style sheet indicate that it should only be applied to certain media types?</li>
|
||
|
|
|
||
|
|
<li>Hyperlinked documents require <em>link styling</em>: Users have come to expect that browsers record those links they have visited in the past. One of the ways of differentiating between visited and unvisited hyperlinks is to style them differently. In order to present hyperlinks, the browser, therefore, must use information outside the documents and style sheets themselves.</li>
|
||
|
|
|
||
|
|
<li>Uncertain delivery requires <em>robustness</em>. The internet is a medium prone to failure and style sheet languages should, like other web mechanisms, be designed with this in mind. If a style sheet fails to appear, the content should still be presentable to the user. Robustness is therefore a requirement. One way to achieve robustness is to have redundant presentational <a href="#fallback_value" class="term">fallback values</a>. Fallback values must go beyond simply having default values for each property. For example, default values are not able to distinguish between inline and block-level elements.</li>
|
||
|
|
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>When discussions on web style sheet languages started, these requirements had not been formulated in writing, as is typical before new standardization efforts are started. Writing the requirements retrospectively allows more experience to be used in their formulation. Calling them requirements, however, may be too strong. Indeed, none of the requirements are absolute in the sense that a style sheet language would be deemed unusable if not all requirements were fulfilled.<span class="fn">For example, it is impossible to fulfill the last requirement for documents written in generic XML since the fallback mechanism typically is based on common knowledge which, by definition, does not exist for generic XML.</span></p>
|
||
|
|
|
||
|
|
<p>Also, it may be argued that it is unfair to evaluate style sheet languages according to requirements for which they were not designed. For example, style sheet languages developed before the web do not need a mechanism to increase the robustness since the formatting process simply will not start until both the document and the style sheet is available. Thererfore, it should be noted that a style sheet language may be perfectly suitable for use outside of the web even if the requirements discussed in this chapter are not met.</p>
|
||
|
|
|
||
|
|
<p>For the purpose of this thesis, however, it is necessary and important to evaluate the pre-web style sheet languages and the web style sheet language proposals according to the requirements of the web. This is done in Table 16.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-16">
|
||
|
|
<p class="caption">An evaluation of how different style sheet languages and proposals perform with respect to web requirements. Positive evaluations are marked by a shaded background.</p>
|
||
|
|
|
||
|
|
<table summary="" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th></th>
|
||
|
|
<th>Stream-based</th>
|
||
|
|
<th>Screen-based properties, values, units</th>
|
||
|
|
<th>Negotiation between conflicting stylistic preferences</th>
|
||
|
|
<th>Media-specific style sheets</th>
|
||
|
|
<th>Link styling</th>
|
||
|
|
<th>Robustness</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>FOSI</th><!--errata: replace td with th-->
|
||
|
|
<td class="maybe">To some extent, FOSI can be considered stream-based. A carefully written FOSI style sheet which avoids some advanced features (including cross-references, floating, and generated text) and certain selectors (e.g., the <code class="value">middle</code> and <code class="value">last</code> values on the <code class="attribute">occur</code> attribute) can be rendered progressively.</td>
|
||
|
|
<td>No. For example, there is no pixel unit.</td>
|
||
|
|
<td>No. FOSI style sheets are typically applied by authors/publishers, and users only see the printed output. There exists no mechanism for combining several style sheets.</td>
|
||
|
|
<td>No, FOSI is primarily intended for printing documents and has no concept of media-specific style sheets.</td>
|
||
|
|
<td>No, link styling is not supported.</td>
|
||
|
|
<td>No, there is no mechanism to increase robustness.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>DSSSL</th><!--errata: replaced td with th-->
|
||
|
|
<td>No, DSSSL is a transformation language at its core and requires a complete document in order to start processing.</td>
|
||
|
|
<td>No. For example, there is no pixel unit.</td>
|
||
|
|
<td>No, there is no support for multiple style sheets.</td>
|
||
|
|
<td>No, FOSI is primarily intended for printing documents and has no concept of media-specific style sheets.</td>
|
||
|
|
<td>No, DSSSL has no concept of links</td>
|
||
|
|
<td>No, there is no mechanism to increase robustness</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>P94</th><!--errata: replaced td with th-->
|
||
|
|
<td class="yes">Yes, P94 is a language for describing presentations and leaves the task of transforming the document to its sister language, <q>T</q></td>
|
||
|
|
<td class="no">No. For example, there is no pixel unit.</td>
|
||
|
|
<td class="no">No. Multiple style are supported by way of <em>views</em>, but the various style sheets cannot be combined.</td>
|
||
|
|
<td class="yes">Yes, a P94 style sheet can define several <em>views</em>, e.g., a print view and a screen view.</td>
|
||
|
|
<td class="no">No, P94 has no concept of links.</td>
|
||
|
|
<td class="no">No, there is no mechanism to increase robustness</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>RRP</th><!--errata: replaced td with th-->
|
||
|
|
<td class="yes">Yes, RRP supports progressive rendering</td>
|
||
|
|
<td class="yes">Yes, the proposal is written with computer screens in mind. For example, it suggests how color values can be visualized on <q>terminals which do not support color</q>. There is no pixel unit per se, but some numeric values are interpreted as pixels.</td>
|
||
|
|
<td class="no">Multiple style sheets are supported, but only as a way for authors to replace one style with another inside a document.</td>
|
||
|
|
<td class="no">No, media-specific style sheets are not discussed</td>
|
||
|
|
<td class="yes">Yes. RRP has rich support for link styling, including what marks to put before and after the link. However, there is no way to style visited and unvisited links differently.</td>
|
||
|
|
<td class="maybe">The proposal stresses that a style sheet is a list of hints or suggestions. This implies that there will be another underlying mechanism to ensure that documents can be rendered when a style sheet is not available.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>PWP</th><!--errata: replaced td with th-->
|
||
|
|
<td class="yes">Yes, PWP supports progressive rendering</td>
|
||
|
|
<td class="no">No. PWP includes a set of properties to control blinking of text, but more basic features (e.g., the pixel unit) are lacking.</td>
|
||
|
|
<td class="no">Multiple style sheets are discussed in the proposal, and implemented by Viola. Like RRP, however, only authors are allowed to specify style sheets.</td>
|
||
|
|
<td class="no">No, media-specific style sheets are not discussed.</td>
|
||
|
|
<td class="no">No, link styling is not discussed.</td>
|
||
|
|
<td class="maybe">Like RRP, PWP does not explicitly describe a mechanism for increasing robustness but the Viola implementation was able to render documents without style sheets.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>SHP</th><!--errata: replaced td with th-->
|
||
|
|
<td class="yes">Yes. SHP supports progressive rendering since those features in FOSI which would make progressive rendering impossible are not part of the subset.</td>
|
||
|
|
<td>No, SHP lacks screen-based properties, values and units.</td>
|
||
|
|
<td>No, unlike PWP, SHP does not discuss multiple style sheets.</td>
|
||
|
|
<td>No, media-specific style sheets are not discussed.</td>
|
||
|
|
<td>No, link styling is not discussed.</td>
|
||
|
|
<td class="maybe">Like RRP and PWP, SHP does not explicitly discuss robustness, but it seems likely that documents were meant to be rendered even if a style sheet was not linked from the document.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>CHSS</th><!--errata: replaced td with th-->
|
||
|
|
<td class="yes">Yes, CHSS is stream-based.</td>
|
||
|
|
<td class="yes">Yes, CHSS supports screen-based rendering. The pixel unit is one of several length units, and the size of the screen can be taken into account when selecting a style sheet.</td>
|
||
|
|
<td class="yes">Yes, CHSS introduces the concept of cascading which combines several style sheets into one presentation.</td>
|
||
|
|
<td class="yes">Yes, media-specific style sheets are part of the CHSS proposal.</td>
|
||
|
|
<td>No, link styling is not discussed.</td>
|
||
|
|
<td class="yes">Yes, the default style sheet in the browser allows documents to be rendered even if user/author style sheets are missing.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>JEP</th><!--errata: replaced td with th-->
|
||
|
|
<td class="yes">Yes, progressive rendering is possible.</td>
|
||
|
|
<td class="yes">Yes, screen-based design is supported. The pixel unit is lacking, but some novel features, including the <code>pcd</code> unit (percent of display) is supported.</td>
|
||
|
|
<td class="yes">Although JEP does not support a generic mechanism for combining style sheets, it suggests two schemes for giving users influence: font mapping and weighted rules.</td>
|
||
|
|
<td class="maybe">JEP discusses how to write style sheets for different output media, but does not propose a syntax for doing so.</td>
|
||
|
|
<td>The proposal discusses whether it should be possible to <q>specify styles for anchors</q>, but does not propose a syntax.</td>
|
||
|
|
<td class="yes">Yes, the proposal describes a model where browsers have the capability to render HTML documents and can selectively choose to honor rules in a style sheet. For example, the proposal says <q>a browser which highlights hypertext anchors by underlining them is encouraged to ignore any underline specifications in the stylesheet</q>.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>SSFP</th><!--errata: replaced td with th-->
|
||
|
|
<td class="yes">Yes, progressive rendering is possible.</td>
|
||
|
|
<td>No. For example, there is no pixel unit.</td>
|
||
|
|
<td>No, multiple style sheets are not discussed.</td>
|
||
|
|
<td>No, media-specific style sheets are not discussed.</td>
|
||
|
|
<td>No, link styling is not supported. (Link behaviors are described, however.)</td>
|
||
|
|
<td>No. The proposal mentions <q>specification of fallback processing</q> as an issue which is not yet considered.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>DSSSL Lite</th><!--errata: replaced td with th-->
|
||
|
|
<td>No. DSSSL-Lite is, like DSSSL itself, a transformation language.</td>
|
||
|
|
<td class="maybe">The proposal has one feature, the <code>iconify</code> flow object, which is only implementable on a dynamic display. The proposal does not list values and units.</td>
|
||
|
|
<td>No, multiple style sheets are not discussed.</td>
|
||
|
|
<td>No, media-specific style sheets are not discussed.</td>
|
||
|
|
<td class="maybe">The proposal mentions that <q>objects/characteristics for linking</q> are necessary, but they are not described.</td>
|
||
|
|
<td>Not discussed.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>SSP</th><!--errata: replaced td with th-->
|
||
|
|
<td class="yes">Yes. The proposal has <q>stream-based</q> in its name to emphasize the importance of this feature.</td>
|
||
|
|
<td class="yes">Yes. Some properties interpret numeric values as pixels, and it is possible to set the background of elements. Some properties (including <code class="property">isman</code> and <code class="property">minimized</code>) only make sense in a screen-based environment.</td>
|
||
|
|
<td>No, multiple style sheets is not supported.</td>
|
||
|
|
<td class="yes">Yes, SSP sketches and discusses support for media-specific style sheets. One example in the proposal is to set different color values based on the type of display in use.</td>
|
||
|
|
<td>No, there is no support for link styling. (Link behaviors are described, however.)</td>
|
||
|
|
<td>Not discussed.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>PSL96</th><!--errata: replaced td with th-->
|
||
|
|
<td class="maybe">PSL96 is an interesting midpoint between transformation languages and stream-based languages. PSL96 allows out-of-order presentation, and progressive rendering can therefore be impossible.</td>
|
||
|
|
<td>PSL96 has been implemented in a screen-based browser <a href="#Marden_1997">[Marden&Munson 1997]</a> <a href="#Marden_1998">[Marden&Munson 1998]</a>, but does not support screen-oriented properties, units or values. For example, the pixel unit is not supported.</td>
|
||
|
|
<td>No. Multiple style are supported by way of <em>views</em>, but the various style sheets cannot be combined.</td>
|
||
|
|
<td class="yes">Yes, PSL96 style sheets can define different <em>views</em>, e.g., a print view and a screen view.</td>
|
||
|
|
<td class="maybe">One of the possible views in PSL96 is the <em>links</em> view which, for example, can list all links along with their target URLs. However, it is not possible to style links based on external information, for example if a link has been visited or not.</td>
|
||
|
|
<td class="maybe">The proposal does not describe any mechanism to increase the robustness of renderings, but the authors' modified Mosaic browser is able to present HTML documents without attached style sheets.</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>As can be seen in Table 16, none of the style sheet languages evaluated so far addresses all web requirements. The one that comes closest is CHSS which only fails to address link styling. CHSS was subsequently developed into CSS and link styling was added in the process. CSS is the topic of the next chapter and an evaluation of CSS, similar to Table 16, can be found in Table 21.</p>
|
||
|
|
|
||
|
|
<h2 id="h-273">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>The web adds several new requirements for style sheet languages. In order for a style sheet language to succeed on the web it should:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>be stream-based, so that content can be presented progressively;</li>
|
||
|
|
|
||
|
|
<li>support screen-based properties, values and units;</li>
|
||
|
|
|
||
|
|
<li>be able to combine multiple style sheets;</li>
|
||
|
|
|
||
|
|
<li>support media-specific style sheets;</li>
|
||
|
|
|
||
|
|
<li>offer link styling to distinguish visited links from non-visited links; and</li>
|
||
|
|
|
||
|
|
<li>be robust, in case the linked style sheet does not appear.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>It may be argued that the additional requirements added by the web change the design of style sheet languages to the extent that the term <q>style sheets</q> is no longer appropriate. Finding a new name might also lessen tensions between communities developing languages designed for the web and languages designed prior to the web. By now, however, <q>style sheets</q> is firmly established.</p>
|
||
|
|
|
||
|
|
<p>None of the pre-web style sheet languages nor the style sheet language proposals fulfill every requirement described in this chapter. In order to fulfill these requirements, a new style sheet language had to be developed. The next chapter describes one such effort.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-css" title="Cascading Style Sheets">
|
||
|
|
<h1 class="chapter" id="h-274">Cascading Style Sheets</h1>
|
||
|
|
|
||
|
|
<p>In the previous chapters, style sheet languages before and for the web have been described. However, as the last chapter concluded, none of them comprehensively addressed the needs of the web. In this chapter <em class="title">Cascading Style Sheets</em> is presented and evaluated according to the same criteria used to evaluate the other languages and proposals.</p>
|
||
|
|
|
||
|
|
<p>CSS was developed in part by this author, along with Bert Bos, the W3C HTML and CSS Working Groups and the community at www-style. Two of the proposals discussed in Chapter 4, CHSS and SSP, formed the basis for CSS's development and many people contributed ideas along the way.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>CSS is defined in W3C Recommendations. W3C has issued two major CSS specifications: CSS1 was released in December 1996, and CSS2 was released in May 1998. Both levels are based on the same core syntax and CSS1 is (with some minor exceptions) a subset of CSS2. Unless otherwise noted, the discussion below refers to CSS2.</p>
|
||
|
|
|
||
|
|
<h2 id="h-275">Syntax</h2>
|
||
|
|
|
||
|
|
<p>CSS uses a simple syntax. Here is an example:</p>
|
||
|
|
|
||
|
|
<pre>H1 { font-size: 2em }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The rule in the example above consists of two main parts: <em>selector</em> (<code class="selector">H1</code>) and <em>declaration</em> (<code class="declaration">font-size: 2em</code>). The declaration has two parts: a property (<code class="property">font-size</code>) and a value (<code class="value">2em</code>). While the example above tries to influence only one of the properties needed for rendering a document, it qualifies as a style sheet on its own. Combined with other style sheets it will determine the final presentation of the document.</p>
|
||
|
|
|
||
|
|
<p>Several declarations can be grouped in a declaration block:</p>
|
||
|
|
|
||
|
|
<pre>BODY {
|
||
|
|
margin: 3em;
|
||
|
|
font-family: "Gill Sans", sans-serif;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Declarations inside the declaration block (enclosed by curly brackets) are separated by semicolons. The last declaration is optionally followed by a semicolon. The first declaration in the example above sets the margin around the <code class="element">BODY</code> elements to be <code class="value">3em</code>. The <code class="unit">em</code> unit refers to the font size of the element. In this case, the result is that the margins around the <code class="element">BODY</code> element are three times wider than the font size of the <code class="element">BODY</code> element. The <code class="property">margin</code> property is an example of a <a href="#shorthand_property" class="term">shorthand property</a> which sets values on several other <a href="#individual_property" class="term">individual properties</a> at the same time (in this case, the <code class="property">margin-top</code>, <code class="property">margin-right</code>, <code class="property">margin-bottom</code> and <code class="property">margin-left</code>).</p>
|
||
|
|
|
||
|
|
<p>The second declaration in the above example has a comma-separated list of font families as value. If the first value cannot be used (i.e., if the <code class="value">Gill Sans</code> font is not available), the next value will be tried, and so forth. Only some CSS properties accept lists as values.</p>
|
||
|
|
|
||
|
|
<p>Selectors can also be grouped in comma-separated lists:</p>
|
||
|
|
|
||
|
|
<pre>H1, H2 {
|
||
|
|
font-weight: bold;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the declaration block applies to both <code class="element">H1</code> and <code class="element">H2</code> elements.</p>
|
||
|
|
|
||
|
|
<p>Most of the logic in CSS is expressed in selectors. Here is a more ambitious example:</p>
|
||
|
|
|
||
|
|
<pre>DIV.ingress P:first-line {
|
||
|
|
text-transform: uppercase;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In plain text, the rule above reads: the first line of all <code class="element">P</code> elements inside <code class="element">DIV</code> elements of class <code>ingress</code> should be transformed to uppercase. Advanced selectors like this one are described in more detail below.</p>
|
||
|
|
|
||
|
|
<h3 id="h-278">Forward-compatible parsing</h3>
|
||
|
|
|
||
|
|
<p>The CSS specifications describe two kinds of grammars. First, they describe the parsing rules for the respective level of CSS (i.e., CSS1 and CSS2). Second, they describe a grammar that is valid for all levels of CSS: past, present and future. The purpose of the <a href="#forward-compatible_parsing" class="term">forward-compatible parsing</a> is to allow future levels of CSS to include new functionality while ensuring that older implementations can parse the new style sheets. The old implementation will not understand the new features but will know which parts of the style sheet it does not understand.</p>
|
||
|
|
|
||
|
|
<p>In return for backwards compatibility, future levels of CSS must follow certain rules when adding new functionality. New selectors, properties and values can easily be added since the forward-compatible parsing rules instruct parsers to ignore rules with unknown parts. Here is an example:</p>
|
||
|
|
|
||
|
|
<pre> :foo { color: red }
|
||
|
|
P { foo: red }
|
||
|
|
P { color: foo }
|
||
|
|
P { color: blue }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first three rules are invalid in CSS1 and CSS2 (due to the selector, property and value, respectively). Conforming CSS1/CSS2 implementations will, due to the forward-compatible parsing rules, ignore each of the invalid rules and resume normal parsing after the right curly bracket (}). The last rule is valid and will have the normal effect.</p>
|
||
|
|
|
||
|
|
<h3 id="h-279">At-keywords</h3>
|
||
|
|
|
||
|
|
<p>The forward-compatible parsing rules also allow more advanced constructs to be introduced through <em>at-keywords</em>. An at-keyword starts with an '@' sign, immediately followed by the name of the keyword. The forward-compatible parsing rules state that <q>an at-rule consists of everything up to and including the next semicolon (;) or the next block, whichever comes first</q> <a href="#CSS2_1998">[CSS2 1998]</a>. This rule allows new syntactic structures to be introduced into CSS.</p>
|
||
|
|
|
||
|
|
<p>CSS1 uses an at-keyword to import one style sheet into another:</p>
|
||
|
|
|
||
|
|
<pre>@import "mystyle.css";
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>CSS2 used the at-keyword extension mechanism and added four additional at-keywords:</p>
|
||
|
|
|
||
|
|
<pre>@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 }
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The four at-keywords respectively describe: the character set used in the CSS style sheet; downloadable font resources, paged media, and media-dependent style sheets.</p>
|
||
|
|
|
||
|
|
<p>The purpose of the forward-compatible parsing rules is to ensure that future levels of CSS can introduce new features without breaking older implementations.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-280">Selectors</h2>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>CSS has a rich set of selectors and most of the logic that can be expressed in CSS is written into selectors. Other languages, e.g. DSSSL, P94, and PSL96 have simple selector mechanisms, but more complex expressions.</p>
|
||
|
|
|
||
|
|
<p>For example, when selecting an element based on its type (<code class="element">NOTE</code> in the example below) and the existence of an attribute (<code class="attribute">WARNING</code>), CSS expresses this in a selector:</p>
|
||
|
|
|
||
|
|
<pre>NOTE[WARNING] { ... }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>DSSSL, on the other hand, will only put the element type in the selectors and express the attribute requirement inside an <code>if</code> statement.</p>
|
||
|
|
|
||
|
|
<pre>(element NOTE
|
||
|
|
(if (not (node-list-empty? (attribute "WARNING")))
|
||
|
|
...
|
||
|
|
))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Two aspects of CSS selectors deserve further discussions: the notion of simple vs. contextual selectors, and pseudo-selectors. They are each discussed below, followed by an overview of the selectors in CSS1 and CSS2.</p>
|
||
|
|
|
||
|
|
<h3 id="h-281">Simple and contextual selectors</h3>
|
||
|
|
|
||
|
|
<p>CSS1 distinguishes between simple and contextual selectors. A simple selector is a selector that matches an element based on its type and/or attributes, but not the element's position in the document structure.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>In contrast, a contextual selector is a selector that matches an element based on its position in the document structure. A contextual selector consists of several simple selectors.</p>
|
||
|
|
|
||
|
|
<p>In order to support contextual selectors, browsers must keep a stack of open elements so that all simple selectors of the contextual selector can be evaluated. This task is further complicated when an element is present according to the DTD but the corresponding tags do not appear in the document. For example, this is often the case with the <code class="element">BODY</code> element in HTML, and implementations must, therefore, have knowledge of the HTML DTD. Most early web browsers did not keep a stack of open elements and, therefore, could not support contextual selectors.</p>
|
||
|
|
|
||
|
|
<p>One reason why the relatively advanced contextual selectors were present in the relatively simple CSS1 specification was to set borders around clickable images. The Netscape browser supported this feature through proprietary extensions and it was deemed, therefore, to be a required feature in CSS1 as well. Here is a quote from Appendix A of the CSS1 Recommendation:</p>
|
||
|
|
|
||
|
|
<pre>/* 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 }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Another reason why CSS1 requires support for contextual selectors was to increase awareness among implementors that the tags in HTML represent document structure and not formatting instructions.</p>
|
||
|
|
|
||
|
|
<p>In retrospect, it may have been a mistake to make contextual selectors part of the CSS1 specification. Implementations did not support this feature in an interoperable manner until several years later and this delayed the deployment of CSS1. On the other hand, by having contextual selectors, CSS contributed to the understanding of HTML as a <em>structured</em> markup language.</p>
|
||
|
|
|
||
|
|
<p>CSS2 further extended the range of contextual selectors. See Tables 17 and 18.</p>
|
||
|
|
|
||
|
|
<h3 id="h-282">Pseudo-elements and pseudo-classes</h3>
|
||
|
|
|
||
|
|
<p>CSS1 introduces the concept of pseudo-elements and pseudo-classes which have their own selectors.</p>
|
||
|
|
|
||
|
|
<p>The general model of CSS is to attach style properties to elements found in the source document. A CSS style sheet adorns the source tree with stylistic settings. This allows WYSIWYG editing of the document: the structures seen on the screen correspond directly to elements in the source document.</p>
|
||
|
|
|
||
|
|
<p>This simple system of mapping source elements to display objects, however, excludes some common typographic effects as well as some dynamic effects that are useful in interactive documents. For example, there is no element that corresponds to the first line of text as formatted on the screen, and there is no attribute that describes if a link has been visited or not.</p>
|
||
|
|
|
||
|
|
<p>CSS has two extensions to address these problems: pseudo-elements and pseudo-classes. A <a href="#pseudo-element" class="term">pseudo-element</a> is a part of an element that does not correspond to a real element in the source document but corresponds to a display object. In CSS1 there are two pseudo-elements: the <code class="property">first-letter</code> of an element and the <code class="property">first-line</code> as it appears on the display.</p>
|
||
|
|
|
||
|
|
<p><a href="#pseudo-class" class="term">Pseudo-classes</a> reflect the fact that the same element must sometimes be given different styling, depending on external information not found in the document. For example, a hyperlink is usually displayed in a different style after the user has visited the target, even though nothing in the source document has changed. CSS1 has three such pseudo-classes: <code>link</code>, <code>visited</code> and <code>active</code>.</p>
|
||
|
|
|
||
|
|
<p>Pseudo-elements and pseudo-classes permit a designer to enrich the structure of a source document without having to use a full-blown transformation language. CSS2 has added both new pseudo-classes and new pseudo-elements.</p>
|
||
|
|
|
||
|
|
<h3 id="h-283">Selectors in CSS1</h3>
|
||
|
|
|
||
|
|
<p>Table 17 gives an overview of the selectors that are available in CSS1.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-17">
|
||
|
|
<p class="caption">Selectors in CSS1.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Pattern</th>
|
||
|
|
<th>Meaning</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E</code></td>
|
||
|
|
<td>Matches any <code class="element">E</code> element (i.e., an element of type <code class="element">E</code>).</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E F</code></td>
|
||
|
|
<td>This contextual selector matches any <code class="element">F</code> element that is a descendant of an <code class="element">E</code> element.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E:link</code><br />
|
||
|
|
<code class="selector">E:visited</code></td>
|
||
|
|
<td>Matches element <code class="element">E</code> if <code class="element">E</code> is the source anchor of a hyperlink of which the target is not yet visited (:link) or already visited (:visited).</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E:active</code><br />
|
||
|
|
<code class="selector">E:hover</code><br />
|
||
|
|
<code class="selector">E:focus</code></td>
|
||
|
|
<td>Matches <code class="element">E</code> during certain user actions.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">DIV.warning</code></td>
|
||
|
|
<td>The same as <code class="selector">DIV[class~="warning"]</code> in CSS2.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E#myid</code></td>
|
||
|
|
<td>Matches any <code class="element">E</code> element with <code>ID</code> equal to <code>myid</code>.</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<h3 id="h-284">Selectors in CSS2</h3>
|
||
|
|
|
||
|
|
<p>In addition to the selectors in CSS1, CSS2 added several selector types. See Table 18.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-18">
|
||
|
|
<p class="caption">Selectors added in CSS2.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Pattern</th>
|
||
|
|
<th>Meaning</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">*</code></td>
|
||
|
|
<td>The universal selector matches any element.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E > F</code></td>
|
||
|
|
<td>Matches any <code class="element">F</code> element that is a child of an element <code class="element">E</code>.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E:first-child</code></td>
|
||
|
|
<td>Matches element <code class="element">E</code> when <code class="element">E</code> is the first child of its parent.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E:lang(c)</code></td>
|
||
|
|
<td>Matches element of type <code class="element">E</code> if it is in (human) language c (the document language specifies how language is determined).</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E + F</code></td>
|
||
|
|
<td>Matches any <code class="element">F</code> element immediately preceded by an element <code class="element">E</code>.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E[foo]</code></td>
|
||
|
|
<td>Matches any <code class="selector">E</code> element with the <code class="attribute">foo</code> attribute set (whatever the value).</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E[foo="warning"]</code></td>
|
||
|
|
<td>Matches any <code class="element">E</code> element whose <code class="attribute">foo</code> attribute value is exactly equal to <code>warning</code>.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E[foo~="warning"]</code></td>
|
||
|
|
<td>Matches any <code class="element">E</code> element whose <code class="attribute">foo</code> attribute value is a list of space-separated values, one of which is exactly equal to <code>warning</code>.</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td><code class="selector">E[lang|="en"]</code></td>
|
||
|
|
<td>Matches any <code class="element">E</code> element whose <code class="attribute">lang</code> attribute has a hyphen-separated list of values beginning (from the left) with <code>en</code>.</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>The selectors that were added in CSS2 add expressiveness and make CSS applicable to languages other than HTML.</p>
|
||
|
|
|
||
|
|
<h2 id="h-285">Properties</h2>
|
||
|
|
|
||
|
|
<p>CSS1 describes a basic set of properties for visual formatting. CSS2 extends the set by adding properties, especially in the areas of printing and aural presentations.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>For some properties, CSS provides a shorthand syntax for setting several values in one declaration. Here is an example:</p>
|
||
|
|
|
||
|
|
<pre>P { font: 10px/12px sans-serif }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the value of six <a href="#individual_property" class="term">individual properties</a> (<code class="property">font-style</code>, <code class="property">font-weight</code>, <code class="property">font-variant</code>, <code class="property">font-size</code>, <code class="property">line-height</code>, and <code class="property">font-family</code>) are set through the use of one <a href="#shorthand_property" class="term">shorthand property</a> (font). The benefit of shorthand properties is that they reduce the length of style sheets making them more readable. Also, shorthand properties provide a grouping of properties (similar to FOSI) that encourages designers to group related values.</p>
|
||
|
|
|
||
|
|
<p>Shorthand properties are sometimes criticized for making it more difficult to write parsers. The '/' used in the example above is borrowed from traditional typography, but the character is not used in other properties. Therefore, CSS parsers must add a special code to handle the syntax of the shorthand properties. Also, with the introduction of DOM APIs <a href="#DOM1_1998">[DOM1 1998]</a> to read/write the value of CSS properties, the shorthand properties pose an additional problem.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>Table 19 lists all properties in CSS1. In the values column, a formal syntax is used to indicate the legal syntax of values: A bar (|) separates two or more alternatives, exactly one of them must occur; A double bar (||) separates two or more options; one or more of them must occur in any order.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-19">
|
||
|
|
<p class="caption">Properties in CSS1.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th>Property</th>
|
||
|
|
<th>Values</th>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="2">Font properties (6)</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">font-family</td>
|
||
|
|
<td class="value">[[<family-name> | <generic-family>],]* [<family-name> | <generic-family>]</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">font-style</td>
|
||
|
|
<td class="value">normal | italic | oblique</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">font-variant</td>
|
||
|
|
<td class="value">normal | small-caps</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">font-weight</td>
|
||
|
|
<td class="value">normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">font-size</td>
|
||
|
|
<td class="value"><absolute-size> | <relative-size> | <length> | <percentage></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">font</td>
|
||
|
|
<td class="value">[ <font-style> || <font-variant> || <font-weight> ]? <font-size> [ / <line-height> ]? <font-family></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="2">Color and background properties (7)</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">color</td>
|
||
|
|
<td class="value"><color></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">background-color</td>
|
||
|
|
<td class="value"><color> | transparent</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">background-image</td>
|
||
|
|
<td class="value"><url> | none</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">background-repeat</td>
|
||
|
|
<td class="value">repeat | repeat-x | repeat-y | no-repeat</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">background-attachment</td>
|
||
|
|
<td class="value">scroll | fixed</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">background-position</td>
|
||
|
|
<td class="value">[<percentage> | <length>]{1,2} | [top | center | bottom] || [left | center | right]</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">background</td>
|
||
|
|
<td class="value"><background-color> || <background-image> || <background-repeat> || <background-attachment> || <background-position></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="2">Text properties (8)</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">word-spacing</td>
|
||
|
|
<td class="value">normal | <length></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">letter-spacing</td>
|
||
|
|
<td class="value">normal | <length></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">text-decoration</td>
|
||
|
|
<td class="value">none | [ underline || overline || line-through || blink ]</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">vertical-align</td>
|
||
|
|
<td class="value">baseline | sub | super | top | text-top | middle | bottom | text-bottom | <percentage></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">text-transform</td>
|
||
|
|
<td class="value">capitalize | uppercase | lowercase | none</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">text-align</td>
|
||
|
|
<td class="value">left | right | center | justify</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">text-indent</td>
|
||
|
|
<td class="value"><length> | <percentage></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">line-height</td>
|
||
|
|
<td class="value">normal | <number> | <length> | <percentage> <percentage></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="2">Box properties (26)</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">margin-top</td>
|
||
|
|
<td class="value"><length> | <percentage> | auto</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">margin-right</td>
|
||
|
|
<td class="value"><length> | <percentage> | auto</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">margin-bottom</td>
|
||
|
|
<td class="value"><length> | <percentage> | auto</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">margin-left</td>
|
||
|
|
<td class="value"><length> | <percentage> | auto</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">margin</td>
|
||
|
|
<td class="value">[ <length> | <percentage> | auto ]{1,4}</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">padding-top</td>
|
||
|
|
<td class="value"><length> | <percentage></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">padding-right</td>
|
||
|
|
<td class="value"><length> | <percentage></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">padding-bottom</td>
|
||
|
|
<td class="value"><length> | <percentage></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">padding-left</td>
|
||
|
|
<td class="value"><length> | <percentage></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">padding</td>
|
||
|
|
<td class="value">[ <length> | <percentage> ]{1,4}</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-top-width</td>
|
||
|
|
<td class="value">thin | medium | thick | <length></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-right-width</td>
|
||
|
|
<td class="value">thin | medium | thick | <length></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-bottom-width</td>
|
||
|
|
<td class="value">thin | medium | thick | <length></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-left-width</td>
|
||
|
|
<td class="value">thin | medium | thick | <length></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-width</td>
|
||
|
|
<td class="value">[thin | medium | thick | <length>]{1,4}</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-color</td>
|
||
|
|
<td class="value"><color>{1,4}</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-style</td>
|
||
|
|
<td class="value">none | dotted | dashed | solid | double | groove | ridge | inset | outset</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-top</td>
|
||
|
|
<td class="value"><border-top-width> || <border-style> || <color></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-right</td>
|
||
|
|
<td class="value"><border-right-width> || <border-style> || n<color></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-bottom</td>
|
||
|
|
<td class="value"><border-bottom-width> || <border-style> || <color></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border-left</td>
|
||
|
|
<td class="value"><border-left-width> || <border-style> || <color></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">border</td>
|
||
|
|
<td class="value"><border-width> || <border-style> || <color></td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">width</td>
|
||
|
|
<td class="value"><length> | <percentage> | auto</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">height</td>
|
||
|
|
<td class="value"><length> | auto</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">float</td>
|
||
|
|
<td class="value">left | right | none</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">clear</td>
|
||
|
|
<td class="value">none | left | right | both</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th colspan="2">Classification properties (6)</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">display</td>
|
||
|
|
<td class="value">block | inline | list-item | none</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">white-space</td>
|
||
|
|
<td class="value">normal | pre | nowrap</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">list-style-type</td>
|
||
|
|
<td class="value">disc | circle | square | decimal | lower-roman | upper-roman | lower-alpha | upper-alpha | none</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">list-style-image</td>
|
||
|
|
<td class="value"><url> | none</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">list-style-position</td>
|
||
|
|
<td class="value">inside | outside</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property">list-style</td>
|
||
|
|
<td class="value">[disc | circle | square | decimal | lower-roman | upper-roman | lower-alpha | upper-alpha | none] || [inside | outside] || [<url> | none]</td>
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<p>It is noteworthy that a significant number of the properties (22 of 53) describe the boxes around elements (the margin/border/padding areas). The high number is a result of having separate properties for each area on each of the four sides of the box. Also, border styles and border colors can be described on each side and there are shorthand properties to set margins, borders and padding for all four sides at once.</p>
|
||
|
|
|
||
|
|
<p>In other areas the number of CSS1 properties is kept to a minimum. For example, the <code class="property">background-position</code> property, which describes a pair of coordinates, is a single property. An alternative solution where <code class="property">background-position</code> is a shorthand property for (say) <code class="property">background-position-x</code> and <code class="property">background-position-y</code>, the number of properties would increase, but the values on the individual properties would be simpler to parse. By dropping the shorthand property altogether, parsing CSS would become simpler but style sheets would become longer and arguably more difficult to write.</p>
|
||
|
|
|
||
|
|
<p>A number of properties were added in CSS2 and Table 20 lists all properties present in CSS2 that are not in CSS1. Also, the <code class="property">display</code> and <code class="property">list-style-type</code> properties are listed since their values were significantly extended in CSS2.</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-20">
|
||
|
|
<p class="caption">Properties introduced in CSS2.</p>
|
||
|
|
|
||
|
|
<table summary="" border="1" class="properties">
|
||
|
|
<tr>
|
||
|
|
<th>Property</th>
|
||
|
|
<th>Values</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/tables.html#propdef-border-collapse">border-collapse</a></td>
|
||
|
|
<td class="value">collapse | separate | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
|
||
|
|
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/tables.html#propdef-border-spacing">border-spacing</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a>? | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/tables.html#propdef-caption-side">caption-side</a></td>
|
||
|
|
<td class="value">top | bottom | left | right | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visufx.html#propdef-clip">clip</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/visufx.html#value-def-shape"><shape></a> | auto | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/generate.html#propdef-content">content</a></td>
|
||
|
|
<td class="value">[ <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-string"><string></a> | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-uri"><uri></a> | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-counter"><counter></a> | attr(X) | open-quote | close-quote | no-open-quote | no-close-quote ]+ | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/generate.html#propdef-counter-increment">counter-increment</a></td>
|
||
|
|
<td class="value">[ <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-identifier"><identifier></a> <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-integer"><integer></a>? ]+ | none | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/generate.html#propdef-counter-reset">counter-reset</a></td>
|
||
|
|
<td class="value">[ <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-identifier"><identifier></a> <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-integer"><integer></a>? ]+ | none | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/ui.html#propdef-cursor">cursor</a></td>
|
||
|
|
<td class="value">[ [<a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-uri"><uri></a> ,]* [ auto | crosshair | default | pointer | move | e-resize | ne-resize | nw-resize | n-resize | se-resize | sw-resize | s-resize | w-resize| text | wait | help ] ] | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-direction">direction</a></td>
|
||
|
|
<td class="value">ltr | rtl | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-display">display</a></td>
|
||
|
|
<td class="value">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 | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/tables.html#propdef-empty-cells">empty-cells</a></td>
|
||
|
|
<td class="value">show | hide | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-size-adjust">font-size-adjust</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-number"><number></a> | none | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-stretch">font-stretch</a></td>
|
||
|
|
<td class="value">normal | wider | narrower | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-left">left</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-percentage"><percentage></a> | auto | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/generate.html#propdef-list-style-type">list-style-type</a></td>
|
||
|
|
<td class="value">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 | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/generate.html#propdef-marker-offset">marker-offset</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> | auto | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/page.html#propdef-marks">marks</a></td>
|
||
|
|
<td class="value">[ crop || cross ] | none | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-max-height">max-height</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-percentage"><percentage></a> | none | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-max-width">max-width</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-percentage"><percentage></a> | none | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-min-height">min-height</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-percentage"><percentage></a> | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-min-width">min-width</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-percentage"><percentage></a> | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/page.html#propdef-orphans">orphans</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-integer"><integer></a> | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/ui.html#propdef-outline">outline</a></td>
|
||
|
|
<td class="value">[ <a href="http://www.w3.org/TR/REC-CSS2/ui.html#propdef-outline-color">'outline-color'</a> || <a href="http://www.w3.org/TR/REC-CSS2/ui.html#propdef-outline-style">'outline-style'</a> || <a href="http://www.w3.org/TR/REC-CSS2/ui.html#propdef-outline-width">'outline-width'</a> ] | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/ui.html#propdef-outline-color">outline-color</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-color"><color></a> | invert | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/ui.html#propdef-outline-style">outline-style</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/box.html#value-def-border-style"><border-style></a> | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/ui.html#propdef-outline-width">outline-width</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/box.html#value-def-border-width"><border-width></a> | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visufx.html#propdef-overflow">overflow</a></td>
|
||
|
|
<td class="value">visible | hidden | scroll | auto | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/page.html#propdef-page">page</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-identifier"><identifier></a> | auto</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/page.html#propdef-page-break-after">page-break-after</a></td>
|
||
|
|
<td class="value">auto | always | avoid | left | right | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/page.html#propdef-page-break-before">page-break-before</a></td>
|
||
|
|
<td class="value">auto | always | avoid | left | right | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/page.html#propdef-page-break-inside">page-break-inside</a></td>
|
||
|
|
<td class="value">avoid | auto | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-position">position</a></td>
|
||
|
|
<td class="value">static | relative | absolute | fixed | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/generate.html#propdef-quotes">quotes</a></td>
|
||
|
|
<td class="value">[<a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-string"><string></a> <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-string"><string></a>]+ | none | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-right">right</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-percentage"><percentage></a> | auto | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/page.html#propdef-size">size</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a>{1,2} | auto | portrait | landscape | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/tables.html#propdef-speak-header">speak-header</a></td>
|
||
|
|
<td class="value">once | always | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/tables.html#propdef-table-layout">table-layout</a></td>
|
||
|
|
<td class="value">auto | fixed | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-shadow">text-shadow</a></td>
|
||
|
|
<td class="value">none | [<a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-color"><color></a> || <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a>? ,]* [<a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-color"><color></a> || <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a>?] | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-top">top</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length"><length></a> | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-percentage"><percentage></a> | auto | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-unicode-bidi">unicode-bidi</a></td>
|
||
|
|
<td class="value">normal | embed | bidi-override | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visufx.html#propdef-visibility">visibility</a></td>
|
||
|
|
<td class="value">visible | hidden | collapse | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/page.html#propdef-widows">widows</a></td>
|
||
|
|
<td class="value"><a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-integer"><integer></a> | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td class="property"><a href="http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-z-index">z-index</a></td>
|
||
|
|
<td class="value">auto | <a href="http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-integer"><integer></a> | <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit">inherit</a></td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>Most of the properties added to CSS2 extend the visual formatting model. For example, the <code class="property">position</code> and <code class="property">z-index</code> properties added absolute and relative positioned elements. Also, some properties were added to better support certain media types, in particular printing and aural presentations.</p>
|
||
|
|
|
||
|
|
<h2 id="h-286">Values and units</h2>
|
||
|
|
|
||
|
|
<p>CSS offers a rich set of values and units. In particular, the relative length units are powerful. There are six basic types of values:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>keywords: All properties accept one or more keyword values. The keyword <code class="value">inherit</code> is accepted on all CSS2 properties and most properties also have other keywords among the accepted values. Among the commonly used keywords are <code class="value">normal</code>, <code class="value">none</code>, <code class="value">auto</code>, <code class="value">left</code>, and <code class="value">right</code>. CSS avoids binary keywords (like <em>yes</em>/<em>no</em> and <em>true</em>/<em>false</em>) to more easily have room for additional values in the future.</li>
|
||
|
|
|
||
|
|
<li>strings: Strings are enclosed in double quotes or single quotes. String values are used when the namespace is unlimited and keywords, therefore, are too limited. The difference between keywords and strings is blurred by the fact that the <code class="property">font-family</code> property accepts arbitrary font names without requiring quote marks around them.</li>
|
||
|
|
|
||
|
|
<li>numbers (e.g., <code class="value">3</code>): Numbers can be either integer or real numbers. Some properties accept only integer values (e.g., the <code class="property">orphan</code> property) while others accept both integer and real numbers (e.g., line-height).</li>
|
||
|
|
|
||
|
|
<li>numbers with units (e.g., <code class="value">3em</code>): Numbers with units are most often used to express lengths, but they also express angles (e.g., <code class="value">90deg</code>), times (e.g., <code class="value">10ms</code>), and frequencies (e.g., <code class="value">3kHz</code>) on the aural properties. Length units are further described below.</li>
|
||
|
|
|
||
|
|
<li>percentages (e.g., <code class="value">30%</code>): Percentage values are similar to relative length units in the sense that they are relative to another value. Each property that accepts a percentage value also defines to what other value the percentage is relative. Most percentage values refer to width of the closest block-level ancestor but some refer to other values, for example, the font size of the parent element. For this reason, percentage values have been criticized for being inconsistent and this is discussed further below.</li>
|
||
|
|
|
||
|
|
<li>functions (e.g., <code class="value">counter(chapter)</code>): Some advanced properties accept a functional notation for values. This is typically the case when the value refers to an arbitrary object and it is not possible or natural to use a string value. For example, the <code class="property">content</code> property in CSS2 uses a function to refer to the name of an attribute. The string value cannot be used for this since strings have another meaning on the property.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Some properties accept several values, either space-separated (in cases where values are complementary) or comma-separated (in cases where values are alternatives).</p>
|
||
|
|
|
||
|
|
<h3 id="h-287">Length units</h3>
|
||
|
|
|
||
|
|
<p>CSS length units can be classified into <em>absolute</em> and <em>relative</em> units.</p>
|
||
|
|
|
||
|
|
<p>The absolute units are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>in: inches</li>
|
||
|
|
|
||
|
|
<li>cm: centimeters</li>
|
||
|
|
|
||
|
|
<li>mm: millimeters</li>
|
||
|
|
|
||
|
|
<li>pt: points (in CSS one point is equal to 1/72nd of an inch)</li>
|
||
|
|
|
||
|
|
<li>pc: picas (1 pica is equal to 12 points)</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The relative units are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>em: the font size of the current element</li>
|
||
|
|
|
||
|
|
<li>ex: the x-height of the current element's font</li>
|
||
|
|
|
||
|
|
<li>px: refers to <a href="#pixel" class="term">pixels</a> (see discussion below)</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>None of the length units is unique to CSS. The definition of the <code class="unit">px</code> unit, however, is novel. Although <code class="unit">px</code> refers to the term <a href="#pixel" class="term">pixel</a>, the unit is formally defined as a certain viewing angle from the user's perspective rather than the width of a pixel. The reason for not using the most simple and obvious definition is that the width of a pixel will vary considerably from one device to another. Also, as the resolution of output devices increases over time, style sheets should ideally not have to change accordingly.</p>
|
||
|
|
|
||
|
|
<p>CSS, therefore, defines a <a href="#reference_pixel" class="term">reference pixel</a> and prescribes that output devices, where pixels sizes are <q>very different</q>, adjust the <code class="unit">px</code> unit accordingly. The suggested reference pixel is the visual angle of one pixel on a device with a pixel density of 90 dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is about 0.0227 degrees.</p>
|
||
|
|
|
||
|
|
<p>The CSS specification encourages the use of relative length units by stating that <q>absolute length units are only useful when the physical properties of the output medium are known</q>. By using relative length units, documents will scale better in different user environments.</p>
|
||
|
|
|
||
|
|
<p>To some extent, CSS's lack of logical expressions (e.g., compared with DSSSL and P94) and general constraints (compared to PSL96) is compensated for by the repertoire of relative length values. However, the relative values have also been criticized for being irregular. PSL96's authors <a href="#Marden_1998">[Marden&Munson 1998]</a> write:</p>
|
||
|
|
|
||
|
|
<blockquote>Nearly every CSS property has different rules for the values on its right-hand side and it is not much of an exaggeration to say that each property's right-hand side has its own specialized language. This point is illustrated by the line-height property. It does not accept the keywords that can be used with font-size and, in addition, percentages are interpreted relative to the font-size of the current element, rather than relative to the parent element's line-height. For example, this rule
|
||
|
|
|
||
|
|
<pre> EM { line-height: 200%; }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
specifies that the line height for elements <code class="element">EM</code> should be twice as large as its font size. This is a natural way to specify line height, but it is not consistent with the treatment of percentages in other parts of the language.</blockquote>
|
||
|
|
|
||
|
|
<p>It is correct that percentage values in CSS refer to different values. For example, percentages can refer to the font size of the parent element (e.g., <code class="property">font-size</code>), the font size of the current element (e.g., <code class="property">line-height</code>), and the width of the <a href="#containing_block">containing block</a> (e.g., <code class="property">margin-left</code>). However, this author will argue that, most often, the referred values is the right choice and that the described limitation not has hindered, but rather helped, authors by making style sheets easier to write.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h2 id="h-288">Value propagation</h2>
|
||
|
|
|
||
|
|
<p>CSS has three principal mechanisms for value propagation: cascading, inheritance and initial values. Together, the three mechanisms ensure that all element/property combination always have a value.</p>
|
||
|
|
|
||
|
|
<p>The relative strengths of the three mechanisms are different. Cascading is the strongest: if the cascading process yields a value, it will be used. If cascading does not yield a value (or yields the <code class="value">inherit</code> value) the parent element's value will be used. The initial value comes third and will only be used if neither of the other mechanisms yield a value (or if they yield the <code class="value">initial</code> value).</p>
|
||
|
|
|
||
|
|
<h3 id="h-289">Cascading</h3>
|
||
|
|
|
||
|
|
<p>The cascading mechanism in CSS is multi-faceted and serves several purposes. This section will start by describing how the most basic function works, i.e., how the cascading mechanism chooses between several conflicting declarations for a given element/property combination. Further, two different ways of using the basic cascading mechanism are discussed: how conflicts between authors and users are resolved; and how partial style sheets are combined with the browser's <a href="#default_style_sheet">default style sheet</a>.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-290">The basic cascading mechanism</h4>
|
||
|
|
|
||
|
|
<p>When more than one style sheet declarations are trying to set a particular property value on a specific element, the cascading mechanism will pick one <a href="#winning_declaration" class="term">winning declaration</a>. The winning declaration will be given full control of the value in question.<span class="footnote">The cascading mechanism in CHSS was different; it proposed to blend several values into one resulting value.</span></p>
|
||
|
|
|
||
|
|
<p>The challenge is to pick the right declaration. Whenever a conflict between declarations is detected, the winning declaration is found by comparing three factors: the <a href="#origin" class="term">origin</a>, <a href="#specificity" class="term">specificity</a>, and order of appearence in the style sheet. The three factors are ordered in the sense that the specificity is only relevant if the origin does not yield a winning declaration, and the order is only relevant if the specificity does not yield a winning declaration.</p>
|
||
|
|
|
||
|
|
<p>There are three possible <a href="#origin" class="term">origins</a> in CSS: author, user and browser. By default, author declarations win over user declarations, and user declarations win over browser declarations. However, declarations may also be marked as <code>!important</code> and thereby win over other declarations. In the (somewhat contrived) example below, the first declaration will win over the second one due to being marked as <code>!important</code>:</p>
|
||
|
|
|
||
|
|
<pre>H1 {
|
||
|
|
font-size: 3em !important;
|
||
|
|
font-size: 2em;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>When marked <code>!important</code>, user declarations win over author declarations and thereby give users the final say over the presentation of documents.</p>
|
||
|
|
|
||
|
|
<p>The seemingly simple technical solution described above has caused much stir in the history of CSS. While the initial CHSS draft described a model where users would <q>retain control</q>, early CSS drafts contained a <code>!legal</code> construct which gave authors the final say <a href="#CSS_draft1_1995">[CSS draft1 1995]</a>. The logic behind <code>!legal</code> was that there were situations where authors are legally obliged to present content in a certain way. Realizing that CSS never could make any guarantees about the final presentation of the content, the <code>!legal</code> construct was removed in CSS1. However, the author was still given the final say since author declarations marked <code>!important</code> win over user declarations marked <code>!important</code> in CSS1. After intense discussion inside the CSS Working Group, the order was changed in CSS2 so that users again have the final word. In practice, the change has had little effect on how documents are presented since the <code>!important</code> construct is not widely used, but giving users the final say was an important shift that emphasizes the difference between the web and traditional publishing environments.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>If the origin does not yield a winning declaration, the <a href="#specificity" class="term">specificity</a> of the selector associated with the declarations must be computed. Consider this example:</p>
|
||
|
|
|
||
|
|
<pre>* { color: silver }
|
||
|
|
LI { color: red }
|
||
|
|
UL LI { color: blue }
|
||
|
|
LI.warning { color: green }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The four declarations in the example above each have an associated selector. The first selector (<code class="selector">*</code>) is the most general: it selects all elements in the document and is called the <em>universal</em> selector. It is intuitively clear that the second selector is more specific than the first since it only selects <code class="element">LI</code> elements. The last two selectors each select a subset of <code class="element">LI</code> elements; one selects the <code class="element">LI</code> elements with a <code class="attribute">warning</code> attribute, and the other selects <code class="element">LI</code> elements with a <code class="selector">UL</code> ancestor. It is not intuitively clear which of these selectors has the highest specificity.</p>
|
||
|
|
|
||
|
|
<p>CSS describes a formula for calculating the specificity of selectors:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>count the number of ID attributes in the selector (= a)</li>
|
||
|
|
|
||
|
|
<li>count the number of other attributes and pseudo-classes in the selector (= b)</li>
|
||
|
|
|
||
|
|
<li>count the number of element names in the selector (= c)</li>
|
||
|
|
|
||
|
|
<li>ignore pseudo-elements.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity. For the <code class="selector">OL LI</code> selector, the values are: a=0, b=0, c=2, and the specificity is 2. For the <code class="selector">LI.warning</code> selector, the values are: a=0, b=1, c=1, and the specificity is therefore 11.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>If several conflicting declarations have the same specificity, the order that the declarations appear in the style sheets finally determines the outcome. Later declarations win over earlier ones.
|
||
|
|
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-295">Multiple sources: User versus author style sheets</h4>
|
||
|
|
|
||
|
|
<p>In its most controversial role, the cascading mechanism serves as negotiator between user and author. The role is controversial since the two groups are often perceived to have opposing interests; users would like to retain final control of the presentation, and so would authors (or their respective editors and publishing house). This is a simplified view for two reasons. First, most users are happy to accept the presentation suggested by the author. Often, the presentation is an important part of the reading experience offered by the publication and not merely a wrapper around the content. Second, on the web users and authors are not two distinct groups. The web has lowered the threshold for publishing content and many of the <a href="#user" class="term">users</a> are also <a href="#author" class="term">authors</a> and vice versa.</p>
|
||
|
|
|
||
|
|
<p>Still, there are situations when authors and users have different, opposing, interests. One example is the <em>small print</em> in contracts; the text has to be there for legal reasons, but the author does not necessarily want to bring it to the attention of the user. The user, on the other hand, may be particularly interested in reading what the author wants to hide.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Several browsers support user-defined style sheets and are able to combine them with author style sheets. However, few users write their own style sheets. There are probably several reasons for this: the mechanism has not been promoted; writing style sheets is challenging for most people; and it is almost impossible to write one user style sheet that cascades well with all author pages. The last problem can be addressed by allowing user style sheets on a per-site or per-page basis. The burden of writing style sheets for all possible sites and pages may be too big for a single user, but it may also be possible for users to share style sheets, for example on a peer-to-peer basis.</p>
|
||
|
|
|
||
|
|
<p>The cascading mechanism is not necessarily tied to CSS style sheets. That is, a browser may offer a way for a user to set a preference (say, the preferred font size) through a Graphical User Interface (GUI) syntax but still use the cascading mechanism to resolve conflicts between user settings and (say) incoming style sheets from the author. By giving user preferences a well-defined place in the cascade, browsers can offer a predictable resolution of conflicts.</p>
|
||
|
|
|
||
|
|
<p>Negotiating between users and authors may be the most well-known use of the cascading mechanism but it is used rarely compared with another negotiation role: combining style sheets from authors with the browser's <a href="#default_style_sheet" class="term">default style sheet</a>.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h4 id="h-297">Combining partial style sheets with the browser's default style sheet</h4>
|
||
|
|
|
||
|
|
<p>In addition to style sheets coming from authors and readers, CSS acknowledges a third source of stylistic information, namely the browser. A browser that supports CSS has a <a href="#default_style_sheet">default style sheet</a> which is combined with style sheets coming from the author and/or reader. Sample default style sheet are listed in the CSS specifications and – with some minor variations – implementations use the sample default style sheet. This way, style sheets from the authors/users do not have to be complete. They can be partial. Authors and users can focus on describing the differences between the conventional presentation (as described in the default style sheet) and the preferred presentation.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Combining style sheets from authors with the browser's default style sheet is a widely used feature of cascading. A significant percentage of documents on the web currently uses CSS, but few of the style sheets used are complete. Thus, they rely on the cascading mechanism to combine the author's partial style sheet with the browser's default style sheet into one complete presentation.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Browsers already did this, at a very simple level, before CSS was proposed in 1994. For example, users of XMosaic could modify the presentation of documents by setting X11 resources. Combined with a hardcoded HTML style sheet, they formed the presentation of documents.</p>
|
||
|
|
|
||
|
|
<p>It can be argued that all style sheet languages support the notion of partial style sheets since they all use initial values and inheritance. These two mechanisms make it possible to shorten style sheets and, thereby, make them partial. The cascading mechanism, however, is more powerful since values can be set on element types rather than on a per-property basis. This is an important increase in functionality on which web authors have come to rely. For example, the suggested default style sheet for HTML <a href="#CSS2_1998">[CSS2 1998]</a> includes a rule that renders <code class="element">STRONG</code> elements in bold fonts. Since the author's style sheet is combined with the browser's default style sheet, the author does not have to specify the rendering of <code class="element">STRONG</code> elements in all style sheets. Similarly, if the color of text is the only issue of importance for the author, being relieved of having to specify the value for the <code class="element">display</code> property of every element is beneficial.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-299">Inheritance</h3>
|
||
|
|
|
||
|
|
<p>Like DSSSL, CSS properties are either classified as inherited or not-inherited. DSSSL and CSS mostly agree on which properties are inherited. All CSS properties accept the <code class="value">inherit</code> keyword which explicitly specifies that the value should be fetched from the parent. If <code class="value">inherit</code> is specified on the root element, the initial value is used instead.</p>
|
||
|
|
|
||
|
|
<p>CSS distinguishes between specified, computed and actual values. Specified values are found in style sheets. Computed values are processed to the extent possible without laying out the document. Actual values are those actually used to render the document. As a general rule, it is the computed value of a property that is inherited. Properties may, however, specify that other sorts of values should be inherited instead. For example, the <code class="property">line-height</code> property inherits the specified value if it is a number.</p>
|
||
|
|
|
||
|
|
<h3 id="h-300">Initial value</h3>
|
||
|
|
|
||
|
|
<p>Each CSS property has an <a href="#initial_value" class="term">initial value</a> which becomes the resulting value when cascading and inheritance do not yield a value. Also, the initial value can be explicitly specified with the <code class="value">initial</code> keyword which all properties accept.</p>
|
||
|
|
|
||
|
|
<h2 id="h-301">Visual formatting model</h2>
|
||
|
|
|
||
|
|
<p>This section gives the overview of, and rationale behind, the CSS visual formatting model (VFM). For the sake of readability, two assumptions are made to simplify the description. First, it is assumed that the document language is written horizontally, either left-to-right (e.g., the Latin script) or right-to-left (e.g., Arabic and Hebrew). The second assumption is that the output device is <a href="#continous_media" class="term">continuous</a>, as opposed to <a href="#paged_media" class="term">paged media</a>. The page model in CSS is described in the section on <em>Other formatting contexts</em> in this chapter.</p>
|
||
|
|
|
||
|
|
<p>Although non-visual access to documents has been important in the development of CSS, it is still the case that most people – if they have a choice – prefer visual over non-visual presentations of text. Without a powerful visual formatting model CSS would not have succeeded.</p>
|
||
|
|
|
||
|
|
<p>In the design process the led to the CSS VFM there were several requirements. Though not formally specified before the work on the VFM started, they have been formulated retrospectively.</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The VFM has to offer authors visual richness beyond what could be achieved by using HTML alone.</li>
|
||
|
|
|
||
|
|
<li>In order to convince browser vendors to implement CSS, the VFM has to be simple enough to be implementable within tight shipping deadlines.</li>
|
||
|
|
|
||
|
|
<li>The VFM has to support <a href="#progressive_rendering">progressive rendering</a>.</li>
|
||
|
|
|
||
|
|
<li>The VFM has to be implementable on a wide range of visual devices.</li>
|
||
|
|
|
||
|
|
<li>The VFM has to support dynamic <a href="#output_device" class="term">output devices</a> (such as computer screens and projectors) as well as static output devices (such as printers).</li>
|
||
|
|
|
||
|
|
<li>The VFM should be able to replicate common typographical effects. Ideally, one should be able to take any book or magazine and design a CSS style sheet to achieve the same layout.</li>
|
||
|
|
|
||
|
|
<li>The VFM conformance requirements has to be specific enough to produce consistent results in different browsers.</li>
|
||
|
|
|
||
|
|
<li>The VFM conformance requirements has to be loose enough to allow implementations on less-rich visual devices. For example, tty devices should be able to support margins.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>To some extent, these requirements are conflicting. There are three main axes: simplicity vs. richness, pixel-perfection vs. device outreach, and short-term vs. long-term goals. As in most designs, the CSS VFM is a compromise between conflicting goals.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-302">Creating boxes from elements</h3>
|
||
|
|
|
||
|
|
<p>The CSS processing model <a href="#CSS2_1998">[CSS2 1998]</a> describes how documents are processed from when they are downloaded in a browser to when they are presented in an output device. The process involves five distinct steps:</p>
|
||
|
|
|
||
|
|
<ol>
|
||
|
|
<li>parse document, create document tree</li>
|
||
|
|
|
||
|
|
<li>identify media type</li>
|
||
|
|
|
||
|
|
<li>retrieve style sheets</li>
|
||
|
|
|
||
|
|
<li>annotate every element</li>
|
||
|
|
|
||
|
|
<li>generate the formatting structure</li>
|
||
|
|
</ol>
|
||
|
|
|
||
|
|
<p>In practice, implementations can optimize processing by doing several steps in parallel.</p>
|
||
|
|
|
||
|
|
<p>The various boxes that make up the document presentation are created in stage 5 of the process. The collection of boxes is referred to as the <a href="#presentational_structure" class="term">presentational structure</a>. Often, the presentational structure will resemble the document tree created in stage 1. For simple documents, there may even be a one-to-one mapping between elements and boxes, but the mapping is typically more complex for several reasons:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>an inline element that extends beyond the end of the line must be split into several boxes;</li>
|
||
|
|
|
||
|
|
<li>similarly, block elements are often split into two boxes at page breaks;</li>
|
||
|
|
|
||
|
|
<li>elements can be declared to be non-displayable (i.e., while they exist in the <a href="#logical_structure" class="term">logical structure</a>, they do not exist in the <a href="#presentational_structure" class="term">presentational structure</a>); and</li>
|
||
|
|
|
||
|
|
<li>CSS2 style sheets can specify <a href="#generated_content" class="term">generated content</a> in addition to the content from the document tree. For example, the style sheet may specify that the string <q>Chapter:</q> is to be added in front of all <code class="element">H1</code> elements. Generated content will generate boxes of their own.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>By supporting suppressed content and generated content, CSS is able to support transformation-like tasks. However, due to being stream-based, CSS is not able to reorder elements. As discussed in <a href="#ch-structure">Chapter 2</a>, other style sheet languages have taken a different route by basing formatting on a computationally complete transformation language.</p>
|
||
|
|
|
||
|
|
<h3 id="h-303">The box model</h3>
|
||
|
|
|
||
|
|
<p>A model of nested rectangular boxes forms the basis for VFM. In its simplest form, each element in the source document is turned into a block box or inline box in the output device. The content of the box is either text or graphics, and around the content there are three <a href="#area" class="term">bands</a>: padding, border and margin. See figure 4.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<div id="f-4" class="figure">
|
||
|
|
<div style="width: 20em; font-size: 20px; font-family: sans-serif; background: white; color: black; border: 1px solid black; padding: 5px 10px">margin
|
||
|
|
|
||
|
|
<div style="background: black; color: white; margin: 15px 30px; padding: 5px 10px">border
|
||
|
|
|
||
|
|
<div style="background: white; color: black; margin: 15px 30px; padding: 5px 10px">padding
|
||
|
|
|
||
|
|
<div style="border: 1px solid black; margin: 15px 30px; padding: 10px">content</div>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p class="caption">The CSS box model.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>By adding padding or margin around an element, it will be set apart from the visual context and thereby emphasized. Similarly, adding a border will make the element stand out. The width of each of the three bands can be adjusted on a per-side basis. Thus, 12 individual properties and six shorthand properties can be set on each element. In practice, relatively few elements use the provided features and, therefore, it may seem excessive to support 18 properties on all elements.</p>
|
||
|
|
|
||
|
|
<p>There are several alternate designs which could have kept the CSS box model simpler:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>By only supporting one band per element, the number of properties could have been reduced by a factor of 3. The downside to this approach is that designs with several bands would require nested elements in the source document. This was the approach taken in early CSS drafts around July 1995 <a href="#CSS_draft1_1995">[CSS draft1 1995]</a> <a href="#CSS_draft2_1995">[CSS draft2 1995]</a>.</li>
|
||
|
|
|
||
|
|
<li>Support for three bands could have been limited to <a href="#block_box" class="term">block-level elements</a>. <a href="#inline_element" class="term">Inline elements</a> could be simplified by (say) only supporting one band. This approach was taken in early CSS drafts from August-November 1995 <a href="#CSS_draft3_1995">[CSS draft3 1995]</a> <a href="#CSS_draft4_1995">[CSS draft4 1995]</a> <a href="#CSS_draft5_1995">[CSS draft5 1995]</a> <a href="#CSS_draft6_1995">[CSS draft6 1995]</a>.</li>
|
||
|
|
|
||
|
|
<li>Bands could be treated as generated content. That is, elements would not normally have bands around them, but one or more bands could be generated on demand. CSS1 does not support generated content and this approach was not pursued, therefore.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>In CSS1, however, all three bands can be set on all elements. Designers are thereby given a rich mechanism for framing elements. Since relatively few elements use the non-zero padding, borders and margins, browsers can optimize how these properties are represented internally.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h4 id="h-305">Basic boxes: block and inline</h4>
|
||
|
|
|
||
|
|
<p>Two of the basic building blocks of a document are <a href="#inline_box" class="term">inline</a> and <a href="#block_box" class="term">block</a> boxes. Inline boxes do not generate line breaks, while block-level boxes do. For example, block-level boxes are used to generate paragraphs and headlines, and inline boxes are used for emphasized text and hyperlinks. Both types of boxes use the same three-layered box model described above but some of the rules for laying out boxes differ.</p>
|
||
|
|
|
||
|
|
<p>For block elements, the outer edge of the margin area defines the size of the element for layout purposes. That is, adjacent block elements will be pushed aside to make room for an element based on its margin edge. As a special rule, margin areas are allowed to collapse (i.e., overlap) vertically to not create excessive vertical gaps between boxes. Thus, the margin width represents the minimum vertical space to adjacent elements.</p>
|
||
|
|
|
||
|
|
<p>Margin values can also be negative which results in boxes overlapping each other. This feature can be used to create special effects, for example, in advertising. Due to variations in font availability and font metrics, it is difficult to predict the visual result of overlapping text elements and the feature, therefore, is not much in use. Also, positioned elements (see below) provide another way to make elements overlap each other.</p>
|
||
|
|
|
||
|
|
<p>Inline boxes are laid out somewhat differently. In order to preserve a uniform interline spacing, setting padding/border/margin will not influence the vertical layout of inline boxes. That is, the padding and border will be visible, but they will not push aside other content. The margin is, by definition, transparent and therefore will not have any effect vertically. Horizontally, all three areas will take up space.</p>
|
||
|
|
|
||
|
|
<h4 id="h-306">Outside-in versus inside-out formatting</h4>
|
||
|
|
|
||
|
|
<p>Another difference between block and inline boxes is the way their widths and heights are computed. Unless explicitly specified, the width of a block box will grow to fill all available horizontal space. Vertically, the height is determined by its content. That is, block boxes use <a href="#outside-in_formatting" class="term">outside-in</a> width computation and <a href="#inside-out_formatting" class="term">inside-out</a> height computation. The root element is constrained horizontally by the <a href="#initial_containing_block" class="term">initial containing block</a> (ICB) which typically corresponds to the width of the window or printing surface.</p>
|
||
|
|
|
||
|
|
<p>The width of an inline box is, on the other hand, defined by its content. That is, the box will be as wide as necessary to have room for the content, but no wider. If further spacing is required, padding/border/margins can be used to make more room, but the width of the box cannot be changed. Height computations for inline elements are often based on the content of the box, but, typically, the inline boxes are a little taller than the text inside them. Comfortable reading demands more vertical space between lines than what the fonts themselves contain. Therefore, CSS has introduced a separate property (called <code class="property">line-height</code>) to set the height of inline boxes. Typically, the value of <code class="property">line-height</code> is a factor which, when multiplied with the font size, yields the height of the inline box. Thus, both the width and height are computed <a href="#inside-out_formatting" class="term">inside-out</a>, the width strictly so, the height typically so.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h3 id="h-308">Beyond the basic box model</h3>
|
||
|
|
|
||
|
|
<p>In addition to the basic block and inline boxes discussed above, CSS has several kinds of boxes that extend the visual formatting model:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Floating boxes: An element can be declared to be floating to the right or left edge of its <a href="#containing_block" class="term">containing block</a>. The most interesting feature of a floating box is that other content may flow along its side.</li>
|
||
|
|
|
||
|
|
<li>Marker boxes: List-item markers are placed inside marker boxes. In CSS1, marker boxes are automatically generated and cannot be positioned or sized.</li>
|
||
|
|
|
||
|
|
<li>Run-in boxes: These were introduced in CSS2 to support <em>run-in</em> headings, that is, block elements where the heading is integrated into the first paragraph. Run-in headings can also be expressed in CSS1, but then an extra container element is required around the heading and the first paragraph. By having the <a href="#run-in" class="term">run-in</a> defined as a special box, the markup doesn't have to be changed to achieve the typographical effect.</li>
|
||
|
|
|
||
|
|
<li>Compact boxes: These were introduced in CSS2 mainly so that the <code class="attribute">compact</code> attribute on the <code class="element">UL</code>, <code class="element">OL</code> and <code class="element">DL</code> elements could be deprecated in HTML4 <a href="#HTML4_1997">[HTML4 1997]</a>. The typographic effect of declaring an element to be <em>compact</em> is that the corresponding box is placed in the margin of the next block-level element, if possible. This kind of formatting is often used in dictionaries to save vertical space. Unlike <em>run-in</em> boxes, there is no way to achieve the typographical effect of compact boxes through other means.</li>
|
||
|
|
|
||
|
|
<li>Absolutely-positioned boxes: These boxes are taken out of the normal flow and absolutely positioned relative to their containing blocks. Their position and size are set by the following properties: <code class="property">top</code>, <code class="property">right</code>, <code class="property">bottom</code>, <code class="property">left</code>, <code class="property">width</code>, <code class="property">height</code>. If the dimensions of an absolutely-positioned box are under-specified, the principles of <a href="#inside-out_formatting" class="term">inside-out formatting</a> will be used to determine its size.</li>
|
||
|
|
|
||
|
|
<li>Fixed-positioned boxes: These boxes are like absolutely-positioned boxes with the exception that they use the viewport as the reference for positioning (instead of the containing block). This way, certain elements can remain on the screen while the rest of the document scrolls.</li>
|
||
|
|
|
||
|
|
<li>Relatively positioned boxes: Once a box has been laid out according to the normal flow, it may be shifted relative to this position through the <code class="property">top</code>/<code class="property">right</code>/<code class="property">bottom</code>/<code class="property">left</code> properties.</li>
|
||
|
|
|
||
|
|
<li>Page boxes: To improve printing of web pages, the VFM has added the concept of page boxes to allow page margins and running headers and footers to be specified.</li>
|
||
|
|
|
||
|
|
<li>Tables: Tables are used extensively for layout purposes on the web. Most pages using tables could be improved by using floating and positioned elements instead of tables, but tables also have legitimate use in documents. CSS2 introduced support for tables by borrowing the table model from HTML and adding more presentational features.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3 id="h-309">Inspiration from other formatting models</h3>
|
||
|
|
|
||
|
|
<p>In the early design phases of the CSS visual formatting model, other formatting models were frequently consulted for inspiration. In particular, TeX <a href="#Knuth_1984">[Knuth 1984]</a> was often brought up in white-board discussions.</p>
|
||
|
|
|
||
|
|
<p>As one of its foundations, TeX has a well-defined box model wherein all objects, including individual glyphs, are contained in boxes. The spacing between the boxes can be controlled through TeX commands. In addition to optimal spacing between boxes, TeX also allows maximum and minimum spacing to be expressed. This is referred to as <em>glue</em> (although Knuth suggests that <em>springs</em> is a better term <a href="#Knuth_1981">[Knuth&Plass 1981]</a>).</p>
|
||
|
|
|
||
|
|
<p>The visual formatting model in CSS is based on a box model, and all elements, both block-level and inline, are turned into boxes. Thus, CSS goes further than most other style sheet languages in creating boxes. For example, DSSSL and P94 do not use boxes for inline elements. However, CSS did not adopt TeX's <em>glue</em>. Although the issue was discussed, it was decided against in order to keep the VFM simple. Glue is very useful when breaking paragraphs into lines, but CSS leaves this problem to implementations. CSS allows, but does not demand, inter-paragraph line-breaking optimizations. Each box in CSS is, however, potentially richer than the boxes found in TeX since it can contain a padding, border and margin bands. CSS also borrows other features from TeX, including the <code class="unit">em</code> and <code class="unit">ex</code> units.</p>
|
||
|
|
|
||
|
|
<p>FrameMaker <a href="#FrameMaker">[FrameMaker]</a>, a desktop publishing application later acquired by Adobe, was also consulted in the development of CSS. This author started using FrameMaker in 1987 and among the features that were borrowed is the concept of collapsing vertical margins.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-314">Linking mechanism</h2>
|
||
|
|
|
||
|
|
<p>When CSS1 became a W3C Recommendation in 1996, the current HTML specification <a href="#HTML2_1995">[HTML2 1995]</a> did not specify how to link HTML documents to style sheets. Formally, it was outside the scope of the CSS specification to define the linking mechanism, but CSS1 showed a simple example of how it could be done:</p>
|
||
|
|
|
||
|
|
<pre><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>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The <code class="element">LINK</code> and <code class="element">STYLE</code> elements were later added to HTML4 <a href="#HTML4_1997">[HTML4 1997]</a> along with the <code class="attribute">STYLE</code> attribute:</p>
|
||
|
|
|
||
|
|
<pre><H1 STYLE="color: blue; background: red">
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In addition to describing how to link to style sheets from HTML documents, CSS2 also describes how XML documents and style sheets can be linked:</p>
|
||
|
|
|
||
|
|
<pre><?XML stylesheet type="text/css" href="bach.css"?>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Again, it is outside the scope of CSS to formally define the link and a W3C Recommendation <a href="#XML-stylesheet_1999">[XML-stylesheet 1999]</a> was later published for this purpose.</p>
|
||
|
|
|
||
|
|
<h2 id="h-315">Generated content</h2>
|
||
|
|
|
||
|
|
<p>Generated content was introduced in CSS2. Content can be added before and after elements in the document. This is done by setting the <code class="property">content</code> property on the <code class="pseudo-class">:before</code> and <code class="pseudo-class">:after</code> pseudo-elements. Here is a simple example adding the string <q>Chapter:</q> before every <code class="element">H1</code> element:</p>
|
||
|
|
|
||
|
|
<pre>H1:before {
|
||
|
|
content: "Chapter: ";
|
||
|
|
font-style: italic;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above the generated content is also styled differently from the element to which it is attached. By default, the generated content will inherit the style from its host element.</p>
|
||
|
|
|
||
|
|
<p>The <code class="property">content</code> property accepts the following type of values:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>strings: As shown in the above example</li>
|
||
|
|
|
||
|
|
<li>URL: This value points to an external resource from where the generated content can be found;</li>
|
||
|
|
|
||
|
|
<li>quotes: Four different keywords (<code class="value">open-quote</code>, <code class="value">close-quote</code>, <code class="value">no-open-quote</code> and <code class="value">no-close-quote</code>) provide special support for quote marks (these keywords point into a table kept by the <code class="property">quotes</code> property in order to support nested quotes);</li>
|
||
|
|
|
||
|
|
<li>counters: See below.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3 id="h-317">Counters</h3>
|
||
|
|
|
||
|
|
<p>Counters in CSS are initiated by the <code class="property">counter-reset</code> property and incremented (or, possibly, decremented) by the <code class="property">counter-increment</code> property. Here is a simple example which numbers the <code class="element">H1</code> and <code class="element">H2</code> elements:</p>
|
||
|
|
|
||
|
|
<pre>H1:before {
|
||
|
|
content: "Chapter " counter(chapter) ". ";
|
||
|
|
counter-increment: chapter;
|
||
|
|
counter-reset: section;
|
||
|
|
}
|
||
|
|
H2:before {
|
||
|
|
content: counter(chapter) "." counter(section) " ";
|
||
|
|
counter-increment: section;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the <code class="function">counter()</code> function returns the value of the <code>chapter</code> and <code>section</code> counters.</p>
|
||
|
|
|
||
|
|
<p>To support nested counters, each named counter can have a stack of open counters. This is important for elements that can be nested inside themselves to arbitrary depth. Figure 6 shows how a nested pair of lists (the markup is shown on the left side) is numbered differently. The two style sheets used for numbering the table are shown at the top.</p>
|
||
|
|
|
||
|
|
<div id="f-5" class="figure">
|
||
|
|
<table summary="" border="1">
|
||
|
|
<tr>
|
||
|
|
<th>HTML code</th><!-- errata: replaced td with th-->
|
||
|
|
<td colspan="2"><!-- errata: added colspan-->
|
||
|
|
<pre><OL>
|
||
|
|
<LI></LI>
|
||
|
|
<LI>
|
||
|
|
<OL>
|
||
|
|
<LI></LI>
|
||
|
|
<LI></LI>
|
||
|
|
<LI></LI>
|
||
|
|
</LI>
|
||
|
|
<LI></LI>
|
||
|
|
</OL>
|
||
|
|
</pre>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>CSS code</th>
|
||
|
|
<th>
|
||
|
|
<pre> OL { counter-reset: item }
|
||
|
|
LI:before {
|
||
|
|
content: counter(item);
|
||
|
|
counter-increment: item;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
</th>
|
||
|
|
<th>
|
||
|
|
<pre> OL { counter-reset: item }
|
||
|
|
LI:before {
|
||
|
|
content: counters(item, ".");
|
||
|
|
counter-increment: item;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<th>Formatted result</th><!-- errata: replaced td with th-->
|
||
|
|
<td>
|
||
|
|
<pre> 1
|
||
|
|
2
|
||
|
|
1
|
||
|
|
2
|
||
|
|
3
|
||
|
|
3</pre>
|
||
|
|
</td>
|
||
|
|
<td>
|
||
|
|
<pre> 1
|
||
|
|
2
|
||
|
|
2.1
|
||
|
|
2.2
|
||
|
|
2.3
|
||
|
|
3</pre>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
|
||
|
|
<p class="caption">Two different counter styles.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<h2 id="h-319">Other formatting contexts</h2>
|
||
|
|
|
||
|
|
<p>One main benefit of style sheets is that content can more easily be re-purposed for various media types. Most users on the web today use some kind of visual device for the presentations of web content (e.g., a computer screen or a printed page) while visually impaired users use aural devices, or perhaps a braille tactile feedback device. The range of devices used to display web content is expected to increase in the future and the demands on document formats and formatting systems, therefore, will increase.</p>
|
||
|
|
|
||
|
|
<p>CSS makes efforts to support multiple formatting contexts, and CSS2 introduced two key features to support multimodal access to web content:</p>
|
||
|
|
|
||
|
|
<ol>
|
||
|
|
<li><em>Aural CSS</em> allow style sheets to express how documents should be rendered on an aural device. CSS is the only style sheet language reviewed in this thesis that has aural properties. For a description of the aural CSS properties, referred to as ACSS, see the CSS2 Recommendation <a href="#CSS2_1998">[CSS2 1998]</a> and T.V. Raman's description <a href="#Raman_1996">[Raman 1996]</a>.</li>
|
||
|
|
|
||
|
|
<li><em>Media types</em> allow style sheets to express to what kind of device a particular stylistic rule should apply.</li>
|
||
|
|
</ol>
|
||
|
|
|
||
|
|
<h3 id="h-320">Media types</h3>
|
||
|
|
|
||
|
|
<p>Media types for the web were first proposed by Dave Raggett in a message to www-talk in 1993 <a href="#Raggett_1993g">[Raggett 1993g]</a>. Dave wrote in reply to Pei Wei's style sheet proposal:</p>
|
||
|
|
|
||
|
|
<blockquote>I read your style sheet proposal with great interest, and will add the "style" attribute to the LINK tag attribute definition in the DTD.
|
||
|
|
|
||
|
|
<p>Have you considered allowing multiple stylesheets to cover different uses? This would mean that you could specify one style for printing and another for online use. You might want to go further and distinguish between X windows, PC's and palmtops.</p>
|
||
|
|
|
||
|
|
<p>My suggestion is that the LINK element takes another attribute which specifies the intended media, e.g.</p>
|
||
|
|
|
||
|
|
<pre><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">
|
||
|
|
</pre>
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<p>The <code class="attribute">media</code> attribute became part of HTML4 <a href="#HTML4_1997">[HTML4 1997]</a>. HTML4 defines nine different <em>media descriptors</em>: <code class="media">screen</code>, <code class="media">tty</code>, <code class="media">tv</code>, <code class="media">projection</code>, <code class="media">handheld</code>, <code class="media">print</code>, <code class="media">braille</code>, <code class="media">aural</code>, <code class="media">all</code>. CSS2, which became a W3C Recommendation in May 1998, was almost aligned with HTML4 on this topic: the only differences are that CSS2 uses the term <q>media types</q> and adds the <code class="media">embossed</code> media type.</p>
|
||
|
|
|
||
|
|
<p>In principle, it would have been sufficient to only use the <code class="attribtue">media</code> attribute (which is also defined for XML documents <a href="#XML-stylesheet_1999">[XML-stylesheet 1999]</a> but having a notion of media types inside CSS style sheets allow one style sheet to describe the rendering on several different media types:</p>
|
||
|
|
|
||
|
|
<pre>@media tv {
|
||
|
|
BODY { font-size: 14px }
|
||
|
|
}
|
||
|
|
@media handheld {
|
||
|
|
BODY { font-size: 10px }
|
||
|
|
}
|
||
|
|
@media print {
|
||
|
|
BODY { font-size: 12pt }
|
||
|
|
}
|
||
|
|
@media projection {
|
||
|
|
BODY { font-size: 20px }
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Browsers that support CSS2 will interpret the above example so that the rules within the curly brackets are applied only to the respective media types. Browsers that only understand CSS1 style sheets will skip all rules within the curly brackets due to <a href="#forward-compatible_parsing" class="term">forward-compatible parsing</a>.</p>
|
||
|
|
|
||
|
|
<p>The choice of names for media types has been somewhat controversial. The current names are descriptive of their intended use but do not clearly define the range of devices to which they apply. The need for a more specific query language was foreseen in HTML 4.0 and CSS2 and both specifications left room for future extensions.</p>
|
||
|
|
|
||
|
|
<h2 id="h-321">CSS in context</h2>
|
||
|
|
|
||
|
|
<p>When the work on CSS was started in 1994 it faced many challenges. By then the web had established itself as a viable medium for electronic publishing and authoring conventions had been established. Style sheets were not part of those conventions and many doubted whether style sheets could become part of web publishing. One commenter wrote <a href="#Suck_1996">[Suck 1996]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Tables in HTML might have less to do with page design and more to do with rows and columns of numbers if it weren't for the spectacular failure of style sheets. The cascade effect of the W3C's "Cascading Style Sheets, level 1" - unveiled a year too late last winter in that city of dreams, Paris, France - couldn't have been better planned. By then, page layout via tables and Netscapisms like FONT SIZE had become entrenched, making style sheets an excellent standards-committee product - not only in its simple elegance, but also in its superfluousness and redundancy.</blockquote>
|
||
|
|
|
||
|
|
<p>In order for CSS to succeed in face of the <q>entrenched Netscapisms</q>, it needed to be accepted by:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>browser vendors: CSS had to be easy to implement, and offer compelling features that could make the next version of their browser compelling;</li>
|
||
|
|
|
||
|
|
<li>authors: CSS had to be easy to learn in the same way HTML had been easy to learn, and provide stylistic features that could otherwise not be achieved; and</li>
|
||
|
|
|
||
|
|
<li>users: Users have the least influence of these three groups, but disapproval from users can be problematic for new web technologies. For example, the use of <em>frames</em> <a href="#HTML4_1997">[HTML4 1997]</a> has been hindered by user resistance <a href="#Nielsen_1996">[Nielsen 1996]</a>.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Beyond short-term popularity needed to gain acceptance, CSS also had a longer-term ambition of rescuing HTML from turning into a visual markup language. This aspect of CSS is not emphasized in the specification itself, but is mentioned in <em class="title">Appendix E: The applicability and extensibility of CSS1</em> of the CSS1 specification <a href="#CSS1_1996">[CSS1 1996]</a>:
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<blockquote>
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>visual markup replacement: HTML extensions, e.g. "CENTER", "FONT" and "SPACER", are easily replaced with CSS1 style sheets.</li>
|
||
|
|
|
||
|
|
<li>nicer markup: instead of using "FONT" elements to achieve the popular small-caps style, one declaration in the style sheet is sufficient.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</blockquote>
|
||
|
|
|
||
|
|
<p>For CSS to overcome the challenges and fulfill the ambitions, some key design decisions were made:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Create a <em>new</em> language. At the time CSS was first proposed to the web community, ISO had been working on DSSSL for almost a decade. As discussed in <a href="#ch-postweb">Chapter 4</a>, several people argued for a scaled-down <em>DSSSL-lite</em> to be applied to HTML documents. CSS took up certain ideas from from DSSSL (e.g., the naming of properties), but it was decided to develop a new language rather than build on DSSSL. There are several reasons for this. First, the DSSSL was work in progress and drafts were not generally available. Second, DSSSL had not been developed with the web in mind and did not have a way of combining style sheets from authors and users. Third, the Scheme-based syntax was considered to be unsuitable for non-programmers.</li>
|
||
|
|
|
||
|
|
<li>Create a non-Turing-complete declarative language. Another design choice that was controversial at the time was to develop a <a href="#declarative" class="term">declarative</a> language expressing constraints, rather than a Turing-complete programming language. A programming language would have been a more powerful solution, but it comes at a cost; programs are difficult to read and expensive to maintain. Also, security – which is always a concern on the web – suffers.</li>
|
||
|
|
|
||
|
|
<li>Support progressive rendering. In order to display content to the user as quickly as possible, browsers support <a href="#progressive_rendering" class="term">progressive rendering</a> of documents. Even if a document has not been fully downloaded, the first part of it may be displayed. Progressive rendering was considered an important feature that CSS should not break. CSS therefore has no way of styling an element based on its children or younger siblings. Also, elements cannot be reordered by a CSS style sheet and this makes it impossible to, for example, create a table of contents. XSL <a href="#XSL_2001">[XSL 2001]</a> has taken a different approach by being a transformation language.</li>
|
||
|
|
|
||
|
|
<li>Make CSS work with <a href="#structured_document" class="term">structured documents</a>. CSS requires implementations to be aware of the structure in the document. More specifically, contextual selectors can match an element based on its ancestor and implementations, therefore, are required to keep a stack of open elements. Around 1995, most popular browsers did not keep a stack of open elements and CSS1 therefore imposed a major change to their architectures. In retrospect, it may have been a mistake to make contextual selectors part of the CSS1 specification. Implementations did not support this feature in an interoperable manner until several years later, which delayed the deployment of CSS1.</li>
|
||
|
|
|
||
|
|
<li>Make CSS work with <em>any</em> structured markup language. Although <q>HTML</q> appeared in the title of the initial proposal, CSS was soon generalized to work with any structured markup language, of which SGML-based languages formed a particularly interesting subset. The cost of making the generalization was small, and the decision later proved important when new languages written in XML started to appear. This has worked both ways: people are more open to use XML given that it can be styled with CSS.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>One important test of whether the above choices were correct or not is to determine how well CSS performs according to the previously established requirements of the web, just like other style sheet languages were evaluated in the previous chapter. Table 21 continues where table 16 left off:</p>
|
||
|
|
|
||
|
|
<div class="table" id="t-21">
|
||
|
|
<p class="caption">CSS evaluated with respect to the web requirements.</p>
|
||
|
|
|
||
|
|
<table summary="" class="properties">
|
||
|
|
<thead>
|
||
|
|
<tr>
|
||
|
|
<th></th>
|
||
|
|
<th>Stream-based</th>
|
||
|
|
<th>Screen-based properties, values, units</th>
|
||
|
|
<th>Negotiation between conflicting stylistic preferences</th>
|
||
|
|
<th>Media-specific style sheets</th>
|
||
|
|
<th>Link styling</th>
|
||
|
|
<th>Robustness</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>CSS1</td>
|
||
|
|
<td class="yes">Yes, CSS1 is stream-based</td>
|
||
|
|
<td class="yes">Yes, CSS has a number of features to support screen-based design, including the pixel unit and blinking text.</td>
|
||
|
|
<td class="yes">Yes, CSS can combine style sheets from different sources.</td>
|
||
|
|
<td class="yes">Yes, CSS2 supports media-specific style sheets.</td>
|
||
|
|
<td class="yes">Yes, CSS supports link styling.</td>
|
||
|
|
<td class="yes">Yes, CSS is robust in the sense that documents with partial or no style sheets still can be presented. In particular, this is the case for HTML documents on the web.</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<p>CSS fulfills all web requirements for a style sheet language.</p>
|
||
|
|
|
||
|
|
<h2 id="h-322">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>CSS is a style sheet language that has been designed for use on the web. It developed mainly from two of the early proposals for web style sheets, namely CHSS and SSP. Some features from these early proposals were dropped in the course of developing CSS from proposal stage to W3C Recommendation stage.</p>
|
||
|
|
|
||
|
|
<p>Compared with other mature style sheet languages, CSS has some distinct and innovative features:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Cascading allows several style sheets to influence the presentation of a document.</li>
|
||
|
|
|
||
|
|
<li>Pseudo-classes and pseudo-elements allow information from outside the logical structure to influence the presentation.</li>
|
||
|
|
|
||
|
|
<li>Forward-compatible parsing rules allow the language to be gracefully extended.</li>
|
||
|
|
|
||
|
|
<li>Media types allow style sheets to be targeted for certain output devices.</li>
|
||
|
|
|
||
|
|
<li>CSS puts more emphasis on selectors than do other languages; rather than having expressions in the style sheet languages, the expressions are built into selectors.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>This chapter has described the design of CSS. The next chapter deals with problems experienced by CSS.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-problems" title="Problems in CSS">
|
||
|
|
<h1 class="chapter" id="h-323">Problems in CSS</h1>
|
||
|
|
|
||
|
|
|
||
|
|
<p>Problems in, and related to, Cascading Style Sheets are discussed in this chapter. These problems range from simple spelling errors in the specifications, to more complex questions as to whether CSS fulfills its intended role. The chapter is loosely organized along an axis of complexity; the first part describes how simple <em>errors</em> have been handled, and the rest discusses real and perceived <em>problems</em> in CSS.</p>
|
||
|
|
|
||
|
|
<p>The cascading mechanism plays an important – and complex – role in CSS and one section of this chapter is dedicated to problems in the cascading mechanism. Finally, the history of CSS implementations in browsers is outlined.</p>
|
||
|
|
|
||
|
|
<h2 id="h-324">Errors in the specifications</h2>
|
||
|
|
|
||
|
|
<p>As with any other specification, errors exist in the CSS specifications. As part of the specification maintenance process, the editors collect errors and publish them in accompanying errata documents. As the list of errors grows, it becomes unwieldy to read the original specification while always having to check the list of errata. Collapsing the two produces a new document which is easier to read.</p>
|
||
|
|
|
||
|
|
<p>The CSS1 specification, which was first published as a W3C Recommendation in December 1996, was republished with all known errors corrected in January 1999. An appendix in the new document lists the changes and sorts them into three categories:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Spelling and typographic mistakes (12 listed). For example, a missing comma and right parenthesis were added.</li>
|
||
|
|
|
||
|
|
<li>Errors (28 listed). For example, an invalid declaration (<code class="declaration">font-style: small-caps</code>) was used in an example, and a section was referred to as <q>4.4</q> while <q>4.7</q> is correct.</li>
|
||
|
|
|
||
|
|
<li>Structure and organization (6 listed). For example, the revised edition uses a new style sheet, and the appendix describing changes has been added.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>A similar effort is planned for CSS2 but since it will also incorporate semantic changes (in addition to errors), it will most likely be given a new version number.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-325">Problems with the specifications</h2>
|
||
|
|
|
||
|
|
<p>Fixing specification <em>errors</em>, as described in the previous section, is not very controversial. Identifying and correcting real and perceived <em>problems</em> in specifications is much more problematic. There are often conflicting interests between designers and implementors: a designer's solution can easily become an implementor's problem. A personal account of the problems in the CSS specifications as perceived by this author is given in this section.</p>
|
||
|
|
|
||
|
|
<h3 id="h-326">Missing functionality</h3>
|
||
|
|
|
||
|
|
<p>Authoring a technical specification is often a balancing act between functionality on one side and implementability on the other. The functionality must be sufficiently rich to address the needs of its users, and simple enough to be implemented interoperably.</p>
|
||
|
|
|
||
|
|
<p>Traditionally, CSS has valued simplicity over functionality. For example, the abstract of CSS1 states that it is a <q>simple style sheet mechanism</q>. This author believes this has been a correct choice, but there are still some areas where CSS should have offered richer functionality:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>color contrast: It is not possible to ensure a certain contrast between the text color and the background.</li>
|
||
|
|
|
||
|
|
<li>font-size: It is not possible to specify the font size as a function of the element's width. The lack of this functionality makes it difficult to produce, for example, slide presentations that scale from one screen size to another.</li>
|
||
|
|
|
||
|
|
|
||
|
|
<li>line-height: It is not possible to set the line height to be a function of the element width. To increase legibility, line heights should become higher when elements grow wider.</li>
|
||
|
|
|
||
|
|
<li>centering: It is not possible to center an element vertically relative to the screen.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>In addition to the specific list above, there are some general areas where some extra effort would have been worthwhile:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>user interface: CSS was primarily designed to present documents, not user interfaces. However, many of the components needed to describe a user interface are present, and some additional functionality could have made it possible to also design user interfaces. Most notably, it should have been possible to describe the presentation of navigation lists.</li>
|
||
|
|
|
||
|
|
<li>multi-column: It is not possible to describe multi-column layout where content automatically flows from one column to another.</li>
|
||
|
|
|
||
|
|
<li>headers/footers: It is not possible to describe headers and footers on pages.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Some of the above features are likely to be added in future versions of CSS, just like CSS2 added some frequently requested features:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>roll-overs: In CSS1, it was not possible to describe presentation where color/background of an element changed as the pointer <em>rolled over</em> or <em>hovered</em> over an element. Instead, authors used JavaScript to achieve this effect. This functionality was successfully added in CSS2 through the <code class="selector">:hover</code> pseudo-selector.</li>
|
||
|
|
|
||
|
|
<li>positioning: In CSS1, it was not possible to take elements out of the flow and place them over other content. CSS2 added the <em>positioning</em> of elements. The proposal was worked out by representatives from Microsoft and Netscape and published as a W3C working draft <a href="#WD-positioning_1997">[WD-positioning 1997]</a> before being integrated into CSS.</li>
|
||
|
|
|
||
|
|
|
||
|
|
<li>page breaks: CSS1 did not address paged media, and page breaks were among the features added in CSS2.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>These additions are examples of changes in CSS due to feedback from authors and vendors.</p>
|
||
|
|
|
||
|
|
<h3 id="h-327">Excessive functionality</h3>
|
||
|
|
|
||
|
|
<p>Like missing functionality, excessive functionality can be harmful to a specification. Implementors can deem the specification to be too complex and may choose to implement only parts of the specification or ignore it altogether. The result is poor or missing interoperability.</p>
|
||
|
|
|
||
|
|
<p>The features listed below are described in the CSS specifications but, arguably, could have been left out without significant loss. The features are relatively complex to implement and it has taken a long time to achieve interoperability.</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>first-line and first-letter: The first-line and first-letter pseudo-elements make it possible to style content based on the layout of the page rather than the structure of the document. These kinds of features are often referred to as being <em>layout-driven</em>. CSS1 included these pseudo-elements to be able to offer authors some features they could otherwise not achieve. However, the cost of implementing these features far outweighted the benefits of the visual effects they provided.</li>
|
||
|
|
|
||
|
|
<li>box model: The box model of CSS includes padding, border and margin areas around all elements. For block-level elements, this makes sense. For inline elements, however, having three areas is excessive; having a padding area would be sufficient.</li>
|
||
|
|
|
||
|
|
<li>contextual selectors: Contextual selector allow elements to be selected based on their place in the document's tree structure. Supporting contextual selector made it possible to, e.g., remove borders from images that where hyperlinks. This was perceived to be a requirements as one of Netscape's extensions could express it. However, supporting contextual selectors is complex unless implementations already kept a stack of open elements. Typically, this was not the case and contextual selectors were not interoperably supported until several years after the publication of CSS1. As such, contextual selectors delayed the deployment of CSS1. On the other hand, by having contextual selectors, CSS contributed to the understanding of HTML as a <em>structured</em> markup language.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>It may also be argued that other parts of CSS2 are excessive since they have not been widely implemented. These parts include:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><code class="property">text-shadow</code>: This property was added in CSS2 to generate shadow effects on text to deter authors from using images instead of text. The property is complex to implement and can only replace a limited set of the visual effects designers want to apply to text.</li>
|
||
|
|
|
||
|
|
|
||
|
|
<li><code class="property">marks</code>: In high-quality printing, cross marks are often printed in the page margins to align sheets of paper, and cut marks indicate where sheets should be cut. The <code class="property">marks</code> property was added to CSS2 to toggle on and off the printing of marks. Turning these marks on and off may also be handled in the application's print dialog box.</li>
|
||
|
|
|
||
|
|
<li><code class="property">markers</code>: Markers are typically used with list-items to mark the beginning of a new item. CSS1 allowed the <em>type</em> of marker to be described (for example, whether the list-item should be marked with a circle or a number). CSS2 offers a richer, more complex way of describing markers through pseudo-elements.</li>
|
||
|
|
|
||
|
|
<li>downloadable fonts: Fonts are essential resources when presenting documents. Typical desktop computers have around 20 font families available and handheld devices have fewer. Being able to download fonts from the web has the potential of increasing the richness of presentations. CSS2 offers a mechanism for describing and selecting fonts from the web. However, the feature is not much used. Two major reasons for this might be: First, there is no universal font format which all vendors support; and second, font designer want to be compensated for their work and no suitable payment mechanism is available.</li>
|
||
|
|
|
||
|
|
<li>the <code class="property">font-size-adjust property</code>: This property addresses a problem which can occur when one font family is substituted for another. The legibility of the two fonts can vary considerably and the <code class="value">x-height</code> value is often more important than the font size. The purpose of the <code class="property">font-size-property</code> is for designers to indicate that the x-height of the font should be preserved rather than the font size.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Although none of the features listed above have been widely implemented, this author argues that all of them describe useful functionality in a sensible manner, and that the functionality will be used when/if implemented.</p>
|
||
|
|
|
||
|
|
<h3 id="h-328">Poor design</h3>
|
||
|
|
|
||
|
|
<p>Missing functionality can be added, and excessive functionality can be removed. Poor design, however, is often more difficult to fix at a later stage. Three design issues where CSS has been criticized for poor design are considered below.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h4 id="h-329">Overloaded properties</h4>
|
||
|
|
|
||
|
|
<p>CSS1 tried to be a compact language to enable implementations on small devices. In a few areas, however, too much functionality was compressed into a single property in order to save space. This is the case for the <code class="property">white-space</code> property which describes both whether space characters should be collapsed, and whether line breaks should be honored. These are two separate issues and the property should, therefore, have been split into two properties. Similarly, the <code class="property">text-decoration</code> property encodes several unrelated values. For example, it describes whether an element should be underlined and whether it should be blinking. As result, it is not possible to turn off blinking of elements without also affecting underlining.</p>
|
||
|
|
|
||
|
|
<h4 id="h-330">Positioning</h4>
|
||
|
|
|
||
|
|
<p>In January 1997, two months after CSS1 became a W3C Recommendation, the first Working Draft of a document called <em class="title">Positioning HTML Elements with Cascading Style Sheets</em> was published by W3C. Listing authors from both Netscape and Microsoft, the document is a rare example of technical collaboration between the two competing companies. The proposal introduced several new CSS properties to <q>allow authors to exercise greater accuracy in page description and layout</q>. It is noteworthy that the description only refers to authors – not users – and thereby disregards cascading. Indeed, the positioning properties are not well suited for cascading (see the <em>positioning problem</em> below).</p>
|
||
|
|
|
||
|
|
<p>Another problem with the initial positioning draft is the lack of counterpart properties to the proposed <code class="property">top</code> and <code class="property">left</code> properties. This indicates a certain slant towards western writing systems which typically are written from left to right and top to bottom. When positioning was integrated into CSS2, the <code class="property">right</code> and <code class="property">bottom</code> properties were later added to ensure that positioning can be used equally well with other writing systems.</p>
|
||
|
|
|
||
|
|
|
||
|
|
<h4 id="h-331">XML syntax</h4>
|
||
|
|
|
||
|
|
<p>One common criticism of CSS is that it uses its own syntax rather than being written in XML. By using the XML syntax, it is argued, it would be easier to parse CSS and style sheets could be read and written by standard XML tools. Indeed, the choice of syntax is an important one and if the arguments for using the XML syntax, as stated above, are true, CSS could have benefited from using XML. There are, however, several reasons why CSS is not written in XML.</p>
|
||
|
|
|
||
|
|
<p>First, when CSS was developed, XML was not available. XML became a W3C Recommendation in February 1998 <a href="#XML_1998">[XML 1998]</a>, and switching syntax at that point would have incurred a considerable cost. SGML, however, was available, and some people argued that a SGML-based syntax should be used <a href="#Gramlich_1996">[Gramlich 1996]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>We do not know how other vendors feel, but we are getting tired of having to implement a new parser every time something new comes out of W3C (PICS, PEP, CSS, HTTP-NG, etc.) It is clear that CSS has lavished a great deal of attention on coming up with an extremely textually compact way of representing style sheets. Unfortunately, we have little confidence that all vendors will properly implement the CSS parser and this will lead to serious style sheet interoperability problems. (If you do not agree, just think of how long it has taken to get most web clients to parse the HTML subset of SGML reasonably properly.) We have additional concerns about burdening the content providers, with yet another syntax in order to express style sheets in; SGML has a pretty awful syntax, but content providers have already mastered the ability to generate it.</blockquote>
|
||
|
|
|
||
|
|
<p>In the end, human read- and writability was valued higher than reusability of parsers. The CSS syntax is optimized for writing style sheets, and it is doubtful that there is an XML encoding system that is more friendly to humans. Also, writing a CSS parser is relatively simple.</p>
|
||
|
|
|
||
|
|
<p>The most important benefit from writing CSS in XML would probably have been an increased acceptance in the XML community.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<h2 id="h-334">Cascading problems</h2>
|
||
|
|
|
||
|
|
<p>In the previous chapter, the cascading mechanism in CSS was described in some detail at a technical level. The cascading mechanism fulfills two important requirements for CSS. First, it allows both authors and users to influence the presentation of documents. Second, it provides fallback values when only partial style sheets are supplied, or when style sheets are missing. Still, the cascading mechanism has many associated problems. They are discussed in this section. Towards the end, some solutions are proposed.</p>
|
||
|
|
|
||
|
|
<h3 id="h-335">Self-inflicted problems</h3>
|
||
|
|
|
||
|
|
<p>The problems listed below are due to CSS' own design.</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The <em>style</em> problem: Combining different styles often leads to poor aesthetic results. Examples from architecture abound: erecting a building in a different style than the surrounding neighborhood will rarely add <q>creative contrast</q>, and most often look out-of-place. Intuitively, combining different style sheets has some of the same problems associated with it.</li>
|
||
|
|
|
||
|
|
<li>The <em>selector abundance</em> problem: The number and type of selectors available are key style sheets since they provide the hooks onto which the style rules are attached. To create rich presentations, a powerful set of selectors is beneficial. For example, if only type selectors are available, all <code class="element">P</code> elements will have the same style. More advanced selectors make it possible to give different style to different <code class="element">P</code> elements depending on their place in the document structure. CSS2 provides a rich set of selectors for this purpose but there is an intrinsic conflict between richness of selectors and cascading. In order to set the style on all <code class="element">P</code> elements, the challenger will need either to write a large set of selectors or consistently increase the weight of its style rule.</li>
|
||
|
|
|
||
|
|
<li>The <em>property abundance</em> problem: Just like the richness of selectors results in a problem for cascading, properties also have an abundance problem. In particular, the visual distance between elements can be set through several different types of properties: padding, borders and margins. Also, the distance can be affected by the <code class="property">display</code>, <code class="property">float</code> and <code class="property">position</code> property. In order for the challenger to ensure a certain distance, a set of properties must, therefore, be set. Consider this example:
|
||
|
|
|
||
|
|
<pre>P {
|
||
|
|
display: block;
|
||
|
|
float: none;
|
||
|
|
position: static;
|
||
|
|
margin: 1em;
|
||
|
|
border: 0;
|
||
|
|
padding: 0;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The above example sets the vertical distance between <code class="element">P</code> elements to be one em. The shorthand syntax used to set margin, border and paddings alleviates the problem to some extent.</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>The <em>grouping</em> problem: A common request from web authors starting to use CSS is for a way of grouping rules together so that if one rule fails, the other rules are not applied. For example, a style sheet may set the foreground color white and the background color to black. If one of these rules is overridden by a rule introduced by cascading, the style sheet author would like to specify that the other rule should also fail. CSS offers no such mechanism; each rule in CSS is set independently from the other rules.</li>
|
||
|
|
|
||
|
|
<li>The <em>island</em> problem: The cascading mechanism is able to combine several style sheets, but there is no general mechanism for rules in one style sheet to be based on rules in other style sheets. For example, it is not possible to write a style sheet that increases the contrast between foreground and background colors while still using the hues defined in another style sheet. Using relative length units, style rules in one style sheet can be relative to style rules in other style sheets. For example, the font size can be set in one style sheet and the width of the element can be set to <code class="value">10em</code> in another style sheet.</li>
|
||
|
|
|
||
|
|
<li>The <em>positive</em> problem: Rules in CSS can only express positive statements. For example, a rule can say that an element should be red, but not that the element should not be blue. In certain situations it would be beneficial to describe that particular values, or combination of values are not acceptable. For example, green text on a red background is difficult to read for people who are color blind. In some situations, CSS provides a way to list alternate values. The comma-separated list of alternate font families in order of preference is an example.
|
||
|
|
|
||
|
|
<p>The positive problem would not have been a problem if it was possible to select elements based on their stylistic values. Consider this imaginary example where all elements with a green color and a red background are selected:</p>
|
||
|
|
|
||
|
|
<pre>*[color=green][background=red] {
|
||
|
|
background: white
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>While the above example may seem simple, it raises a number of difficult issues. For example, what is the definition of <q>red</q>?</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>The <em>positioning</em> problem: Some properties do not cascade well. The properties that were introduced to support the positioning of elements (position, left, right, top, bottom, z-index) are typically set on single elements rather than groups of elements. This makes it complicated for users to write style sheets that cascade gracefully with author style sheets.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3 id="h-336">Problems resulting from markup</h3>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The <em>generic markup</em> problem: The HTML specifications define a set of elements which are allowed in HTML documents. HTML documents can be displayed in browsers since the browser vendors all have implemented the HTML specifications (with varying success). The common tag set is also a foundation for cascading since the vocabulary of elements is known. A designer can write an alternate style sheet by using the elements and attributes of HTML in the selectors.
|
||
|
|
|
||
|
|
<p>In contrast, the elements and attributes of a document using <a href="#generic_markup" class="term">generic markup</a> are, by definition, not known by anyone but the author of the document. While the markup may still serve a useful role for the author, it is impossible for others to write style sheets to display the document. Only the universal selector (which selects all elements) and the pseudo-selectors (e.g. <code>:first-line</code> and <code>:visited</code>) make sense to use with an unknown tag set, and this is not enough to write a sensible style sheet.</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>The <em>class</em> problem: The <tt>class</tt> attribute in HTML makes it possible to write style sheets with which no one can ever cascade. The CSS1 specification contains a warning against the use of class attributes:
|
||
|
|
|
||
|
|
<blockquote>CSS gives so much power to the CLASS attribute, that in many cases it doesn't even matter what HTML element the class is set on – you can make any element emulate almost any other. Relying on this power is not recommended, since it removes the level of structure that has a universal meaning (HTML elements). A structure based on CLASS is only useful within a restricted domain, where the meaning of a class has been mutually agreed upon.</blockquote>
|
||
|
|
|
||
|
|
<p>The <em>class</em> problem is a specific case of the <a href="#generic_markup" class="term">generic markup</a> problem described above.</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>The <em>presentational markup</em> problem: Many web pages use tables for layout purposes. By placing content into table cells, authors lay out their content in a two-dimensional grid. To some extent, tables are scalable horizontally and vertically (e.g., the widths and height of columns and rows expand and contract based on the content in the table), but the two-dimensional layout is rigid. It is possible for CSS to flatten tables into block-level and inline elements, but the intended semantics of the spatial relationship is lost, and <em>real</em> tables (as opposed to tables for layout purposes) are also flattened in the process.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3 id="h-337">User interface problems</h3>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>The <em>user interface</em> problem: Historically, browsers have provided users with very limited means of setting presentational preferences. Typical choices include the underlining and coloring of links. At a time when most of the presentation was hardcoded into the browser, this limited choice could be explained. With the arrival of CSS, however, most aspects of the presentation are configurable. Still, the user interface of popular browsers has not changed much and no browser provides a user <a href="#gui">GUI</a> for describing anything similar to what CSS can express. Also, Microsoft's Internet Explorer for Windows (a.k.a. WinIE, which is used by most web users) does not provide a way of applying alternate style sheets. Most browsers do, however, provide a way to point to a file containing the user interface.</li>
|
||
|
|
|
||
|
|
<li>The <em>GUI</em> problem: One reason for the user interface problem may be the that it is not intuitively clear how to edit a CSS style sheet through a GUI. Typically, GUIs are used to empower the user with control of all configurable values. In a cascading context, however, it is in the best interest of the user not to set all values and instead leave it to inheritance or other style sheets to determine the value. It is possible to represent these kinds of values through settings such as <q>auto</q> or <q>defer</q>, but it is not something that GUIs have done in the past.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3 id="h-338">Complexity problems</h3>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>the <em>site abundance</em> problem: The web links thousands of servers and millions of pages. It is impossible to write one user style sheet that cascades well with all author style sheets on the web. This problem could have been addressed if browsers allowed site-specific user style sheets, but this has not been the case yet.</li>
|
||
|
|
|
||
|
|
<li>the <em>document debugger</em> problem: Programmers use debuggers to find why a certain value is set at a certain point in a program. Similarly, a <em>document debugger</em> is needed to find out why a certain element/property combination has a certain style. This must be known in order to write a challenger rule to change the value. Document debuggers have been written, but are not offered by mainstream browsers.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h2 id="h-339">Problems in implementations</h2>
|
||
|
|
|
||
|
|
<p>This thesis focuses on the design of CSS and other style sheet languages, and it is beyond its scope to analyze the level of CSS support in various browsers. Still, it must be mentioned that, from the point of view of web authors, the most pressing problem in the early years of CSS was the quality of CSS support in browsers. Jeffrey Zeldman describes the situation around 1998 <a href="#Zeldman_2003">[Zeldman 2003]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>If Netscape 4 ignored CSS rules applied to the <body> element and added random amounts of whitespace to every structural element on your page, and if IE4 got <body> right but bungled padding, what kind of CSS was safe to write? Some developers chose not to write CSS at all. Others wrote one style sheet to compensate for IE4's flaws and a different style sheet to compensate for the blunders of Netscape 4.</blockquote>
|
||
|
|
|
||
|
|
<p>The quote correctly describes the difficult situation in which web authors found themselves: only a small subset of CSS was interoperably implemented between Netscape4 and WinIE <a href="#Wilson_2003a">[Wilson 2003a]</a>. The situation gradually changed as the use of Netscape4 declined and the CSS support in Internet Explorer improved <a href="http://www.webstandards.org/learn/resources/css/">[WASP 2004]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>The W3C invented Cascading Style Sheets (CSS) in 1996 to increase the presentational sophistication and the accessibility of websites, and to eliminate the browser-specific markup that threatened to fragment the emerging web. In 1997, some browsers began to support parts of CSS-1, but the standard did not become truly usable until 2001.</blockquote>
|
||
|
|
|
||
|
|
<p>As suggested in the quote above, 2001 was a turning point for CSS. That year Microsoft released Internet Explorer 6.0 which, although still incomplete and buggy <a href="#Wilson_2003b">[Wilson 2003b]</a>, has usable support for CSS. By that time several other browsers with excellent support for CSS had been released, including Opera, Mozilla, and Internet Explorer for MacOS <a href="#Wilson_2003a">[Wilson 2003a]</a>.</p>
|
||
|
|
|
||
|
|
<p>One reason for the improvement in the quality of CSS implementation is probably the W3C CSS1 Test Suite. The test suite was first published in 1998, 18 months after CSS1 became a W3C Recommendation <a href="#W3C_2004">[W3C 2004]</a>. If the test suite had been available at an earlier stage, the turning point for CSS might have appeared earlier.</p>
|
||
|
|
|
||
|
|
<p>None of the a browsers have been able to compete with WinIE in terms of numbers of users, and WinIE has, therefore, in effect defined what subset of CSS authors can use. WinIE's limited support for CSS, combined with a de facto monopoly in web browsers, is currently the biggest problem for CSS deployment on the web.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h2 id="h-340">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>CSS has seen many problems since CSS1 was published as a W3C Recommendation in 1996. The problems can be divided into three groups: problems in the specifications, problems in the cascading mechanism, and problems in the implementation.</p>
|
||
|
|
|
||
|
|
<p>The CSS specification has three kinds of problems: errors, missing functionality and excessive functionality. The errors have been corrected by the editors who have published lists of errata and revised Recommendations. Also, test suites have been made available for implementors. The views concerning what is excessive and what functionality is missing are subjective, and this author's views have been described.</p>
|
||
|
|
|
||
|
|
<p>Cascading is an ambitious mechanism that has failed to provide users an equal right to influence document presentations, while succeeding in allowing partial style sheets to be combined. I believe there are no fundamental problems in CSS that would have made the introduction of style sheets on the web any easier.</p>
|
||
|
|
|
||
|
|
<p>The first CSS implementations in major browsers were incomplete and prone to errors. That led to a situation where large parts of CSS could not be used as long as particular browsers were used in significant numbers. By now, CSS is a well-understood style sheet language with several excellent implementations. It is still, however, not possible to fully exploit the CSS language due to the relatively poor CSS support in Microsoft's Internet Explorer.</p>
|
||
|
|
|
||
|
|
<p>The two previous chapters have described and evaluated the CSS design. The next two chapters look to the future. First a novel, non-stylistic use of CSS is described. Thereafter, possible future research is outlined.
|
||
|
|
|
||
|
|
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-ssr" title="CSS for small screens">
|
||
|
|
<h1 class="chapter" id="h-342">CSS for small screens</h1>
|
||
|
|
|
||
|
|
<p>Most web pages are written for, and tested exclusively on, desktop computers with large color monitors. Mobile wireless devices typically have much smaller screens and presenting typical web pages on these units is a challenge. This chapter describes how CSS can be used to overcome the challenge. The solution is based on cascading: by enforcing a specially designed browser style sheet on all documents, the rendering of incoming documents is adjusted based on the constraints of the user's device.</p>
|
||
|
|
|
||
|
|
<p>Daniel Glazman has developed a the <em>feel-like-a-cellphone stylesheet</em> (referred to as <em>FLACS</em> in this thesis) which, when installed as the browser's default style sheet, will limit the width of documents so that users only have to scroll vertically to see the whole documents <a href="#Glazman_2002">[Glazman 2002]</a>. The development of the style sheet was inspired by Opera Software's announcement of <em>Small-Screen Rendering</em> (SSR). SSR has been partially based on style sheets in the past, but also has components that cannot be described by CSS. FLACS, being a CSS-only solution, is therefore more suitable for review in this chapter.</p>
|
||
|
|
|
||
|
|
<p>FLACS is a relatively simple style sheet. It contains only 22 declarations and set values on 16 properties. Still, it is able to reformat many documents to be suitable for presentation on a small screen. The style sheet fragments in this chapter are copied from FLACS, but some of theme have been simplified slightly and comments in the style sheet have been removed.
|
||
|
|
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h2 id="h-343">The problem</h2>
|
||
|
|
|
||
|
|
<p>HTML is a simple markup language where the tags describe the logical roles of the content (e.g., paragraphs, headings) rather than how the content is presented (e.g., fonts, colors). When tables were introduced in HTML 3.2 they were meant to represent simple rows and columns of numbers and text within documents – just like tables have been used in traditional documents. However, authors soon discovered that tables could be used for layout purposes. Instead of putting tables inside a document, the whole document was put inside a table. For example, the page could consist of a menu on the left side, an ad banner on the top, and a side bar on the right, and each component would be a cell in the table.</p>
|
||
|
|
|
||
|
|
<p>Pages that use tables for layout purposes are often set to a fixed width, typically around 600 pixels. This width fits well on a desktop computer, but not on smaller web devices. There are several ways to make content fit on smaller screens.</p>
|
||
|
|
|
||
|
|
<p>First, some browsers can zoom pages in and out. Zooming is a powerful way of getting the overview of complex web pages while also being able to magnify certain parts of the page. It is often used by visually impaired users to reach legible font sizes. Zooming out allows web pages written for desktop computers to be shown on small screens, but little content is legible when the page is zoomed out. The use of zooming typically requires the user to scroll extensively both horizontally and vertically.</p>
|
||
|
|
|
||
|
|
<p>Second, one can reformat content to better fit on small devices. Reformatting requires more processing of the content than does zooming; where zooming only changes the size of the elements on the screen while preserving the spatial relationships between the elements, reformatting means that the page is laid out in a new way that changes the spatial relationships between elements. Reformatting can also satisfy a commonly encountered requirement on mobile phones: there should be no horizontal scrolling.</p>
|
||
|
|
|
||
|
|
<p>This chapter describes a strategy for reformatting content based on four main components:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>cascading: The browser applies a browser style sheet to the document;</li>
|
||
|
|
|
||
|
|
<li>linearization: The browser linearizes the document presentation by turning table cells and and positioned elements into normal block-level elements;</li>
|
||
|
|
|
||
|
|
<li>element removal: The browser removes certain elements unfit for display on small screens; and</li>
|
||
|
|
|
||
|
|
<li>element resizing: All elements are given a maximum width equal to the screen size, and are scaled down if necessary.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>The rest of this chapter describes the reformatting process in some detail. A browser that reformats documents according to this process is said to be in <em>small-screen</em> mode.</p>
|
||
|
|
|
||
|
|
<h3 id="h-344">Cascading</h3>
|
||
|
|
|
||
|
|
<p>As discussed in Chapter 6, CSS style sheets can have three different origins: author, user and browser. Normally, the role of the browser's default style is only to provide fallback values. In small-screen mode, however, the browser's style sheet plays a more active role. Consider this fragment from FLACS:</p>
|
||
|
|
|
||
|
|
<pre>body {
|
||
|
|
width: 176px ! important;
|
||
|
|
padding: 3px ! important;
|
||
|
|
margin: auto ! important;
|
||
|
|
border: thick black solid ! important;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first declaration sets the <code class="element">BODY</code> element to a fixed width (176px is a common screen width on mobile phones). The declaration is marked as <code>important</code> to enforce the width even if the author or user style sheet has set another width. Similarly, a certain padding, margin and border is enforced on the <code class="element">BODY</code> element.</p>
|
||
|
|
|
||
|
|
<p>FLACS, however, does not fully describe the presentation of the document. For example, colors and fonts are not set in FLACS (with the exception of font sizes) and author style sheets are therefore partially honored. FLACS thereby makes active use of cascading.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<h3 id="h-345">Linearization</h3>
|
||
|
|
|
||
|
|
<p>HTML tables consist of rows of cells that are aligned horizontally into columns when presented. Most often, the organization of the content into a table is purely a visual effect to achieve a grid type of layout. On a small device there is not enough room for a grid layout, and the table can be reorganized into block-level elements. In small-screen mode, all table cells in a row are combined to form a block-level element, that is, each row is turned into a block-level element, and all block-level elements created from a table are presented on top of each other. This is easily expressed in CSS:</p>
|
||
|
|
|
||
|
|
<pre>table, tr, td, th {
|
||
|
|
display: block ! important;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>A similar technique is used for absolutely-positioned elements. Positioned elements are normally taken out of the normal text flow and positioned somewhere else on the screen. On small screens this is problematic since many of the positioned elements will be placed outside the limited viewing area. Therefore positioning is turned off:</p>
|
||
|
|
|
||
|
|
<pre>* {
|
||
|
|
position: static ! important;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Finally, the floating of elements is turned off since the screen is not wide enough to show elements next to each other:</p>
|
||
|
|
|
||
|
|
<pre>* {
|
||
|
|
float: none ! important;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<h3 id="h-346">Element removal</h3>
|
||
|
|
|
||
|
|
<p>Some elements are not suitable for display on small screens. There are three main types of elements that are removed by FLACS: small images, advertisements, and elements using certain <a href="#plug-in">plug-ins</a>.</p>
|
||
|
|
|
||
|
|
<p>Small images that only serve ornamental or stylistic roles can be selected based on their size:</p>
|
||
|
|
|
||
|
|
<pre>img[width="1"], img[height="1"] {
|
||
|
|
display: none ! important;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The example above removes images with a declared width or height of one pixel. Images that have not declared their size through attributes will not be selected.</p>
|
||
|
|
|
||
|
|
<p>Advertisements are problematic on small screens since they take up valuable screen space and bandwidth. Therefore, FLACS tries to remove advertisements from the document presentation. There is no way to know which elements contain advertisements in HTML. However, certain conventions have been established by advertisers and these conventions can be used to select and remove advertisements. For example, a typical size for advertisements is 468 by 600 pixels. FLACS removes images of this size through a simple rule:</p>
|
||
|
|
|
||
|
|
<pre>img[width="468"], img[height="600"] {
|
||
|
|
display: none ! important;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Also, the <code class="element">iframe</code> element is most often used for advertisements and can therefore be removed:</p>
|
||
|
|
|
||
|
|
<pre>iframe {
|
||
|
|
display : none ! important;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Finally, FLACS removes <code class="element">embed</code> elements which point to a certain type of content:</p>
|
||
|
|
|
||
|
|
<pre>embed[type*="shockwave"] {
|
||
|
|
display : none ! important;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The selector in use in the above example is proposed for CSS3 <a href="#WD-CSS3-selectors">[WD-CSS3-selectors]</a>.</p>
|
||
|
|
|
||
|
|
<h3 id="h-347">Element resizing</h3>
|
||
|
|
|
||
|
|
<p>To avoid horizontal scrolling, elements that are wider than the available screen size must be scaled. CSS2 has a property to describe the maximum width of elements:</p>
|
||
|
|
|
||
|
|
<pre>* {
|
||
|
|
max-width: 176px ! important;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The above statement sets the maximum width of all elements to 176 pixels. Images wider than 176 pixels will then be scaled down to 176 pixels while smaller images will remain unchanged.</p>
|
||
|
|
|
||
|
|
<h2 id="h-348">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>The strategy for reformatting content for small screens described in this chapter uses two aspects of CSS. First, cascading is used to enforce a browser style sheet over author and user style sheets. Second, CSS properties such as <code class="property">display</code>, <code class="property">position</code>, <code class="property">float</code> and <code class="property">max-width</code> are used to describe rendering in small-screen mode. The result is a browser that can display most web pages on a small screen.</p>
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-clink" title="Cascading links">
|
||
|
|
<h1 class="chapter" id="h-349">Cascading links</h1>
|
||
|
|
|
||
|
|
<p>The previous chapter described how CSS can be used to describe a specific visual presentation of documents. This chapter will describe a non-stylistic use of CSS.</p>
|
||
|
|
|
||
|
|
<p>The purpose of style sheets is to describe the presentation of documents. Style sheet languages do this by associating stylistic properties and values with elements in the document. However, there is nothing style-specific in the syntax and value propagation mechanisms of style sheet languages, and style sheets can equally well be used to associate other types of properties and values with elements. As such, style sheet languages can be considered a generic mechanism for associating property/value pairs with elements. Cascading links, or CLINK for short, uses CSS as a mechanism for describing links in documents.</p>
|
||
|
|
|
||
|
|
<h2 id="h-349b">Background</h2>
|
||
|
|
|
||
|
|
<p>One type of information which is crucial on the web is links. In HTML, links are found in certain attributes (e.g., the <code class="attribute">href</code> attribute on the <code class="element">a</code> element) which browser must know. Generic XML has no such attributes, and the question of where to put, and how to find, hyperlinks arises. XLink <a href="#XLink_2001">[XLink 2001]</a> was developed to solve this problem. XLink defines a set of new attributes which represent links of different kinds. Here is a simple XLink example:</p>
|
||
|
|
|
||
|
|
<pre><my:crossReference xlink:href="students.xml">
|
||
|
|
Current List of Students
|
||
|
|
</my:crossReference>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, the <code class="attribute">xlink:href</code> turns the element into a hyperlink. XLink defines a set of attributes that must be used in order to establish the links.</p>
|
||
|
|
|
||
|
|
<p>The W3C HTML Working Group resisted switching over to XLink. The main argument against using XLink was that all documents had to be changed. Instead, it was argued, a solution that <em>describes</em> links rather than <em>being links</em> would be beneficial <a href="#Pemberton_2000">[Pemberton 2000]</a>:</p>
|
||
|
|
|
||
|
|
<blockquote>Another important semantic of a web page, perhaps the most important after presentation, is linking. What is needed is a sort of 'Linking Sheets for the Web': a way to tell generic XML application which attributes represent a link, and how to interpret them.</blockquote>
|
||
|
|
|
||
|
|
<p>HLink <a href="#WD-hlink">[WD-hlink]</a> was later developed to address the needs of XHTML.</p>
|
||
|
|
|
||
|
|
<p>Two of the style sheet language proposals discussed in Chapter 4 discuss how links can be described in <q>sheets</q>. First, <a href="#ssfp">SSFP</a> proposes the <code class="property">click</code> property to indicate where to find URLs in a document. Two ways of describing the behavior of HTML's <code class="attribute">href</code> attribute on the <code class="element">A</code> element are suggested in the proposal:</p>
|
||
|
|
|
||
|
|
<pre>(style a (click (follow (attval 'href))))
|
||
|
|
(style a (click 'follow-URL 'HREF))
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Second, <a href="#ssp">SSP</a> proposes a way for style sheets to identify anchors and targets in a document:</p>
|
||
|
|
|
||
|
|
<pre>*A.anchor: !HREF
|
||
|
|
*A.target: !NAME
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>CLink follows in the same pattern as SSFP and SSP; it provides a way for style sheets to describe links in a document.</p>
|
||
|
|
|
||
|
|
<h2 id="h-349c">The CLink proposal</h2>
|
||
|
|
|
||
|
|
<p>CLink was first proposed in May 2000 <a href="#CLink_2000a">[CLink 2000a]</a>, with an updated proposal November that <a href="#CLink_2000b">[CLink 2000b]</a>. The proposal was not announced publically, at that time, but discussed within W3C forums. Opera Software <a href="#Opera">[Opera]</a> has added experimental support for CLink, and the examples in this chapter use the syntax supported by Opera.</p>
|
||
|
|
|
||
|
|
<p>CLink has two basic functions. First, an element can be marked as a source anchor so that the browser can make it a clickable hyperlink. Second, elements can be marked as <a href="#replaced_element" class="term">replaced</a> so that the content of the element is replaced by an image, for example, when the document is presented to a user.</p>
|
||
|
|
|
||
|
|
<h3 id="h-350">Making hyperlinks</h3>
|
||
|
|
|
||
|
|
<p>CLink uses two properties to mark a hyperlink. The <code class="property">-o-link-source</code> property identifies the URL of the anchor, while the <code class="property">-o-link</code> property turns an element into a source anchor. (The <code>-o</code> prefix of the CLink properties marks the properties as experimental.) Typically, both properties are used on the same elements:</p>
|
||
|
|
|
||
|
|
<pre>A {
|
||
|
|
-o-link-source: attr(HREF);
|
||
|
|
-o-link: current;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the example above, the first declaration states that the <code class="attribute">HREF</code> attribute of the <code class="element">A</code> element contains the URL of the anchor. The effect of the declaration is that, whenever an <code class="element">A</code> element is encountered, the URL is copied into a special variable kept by the browser. The second declaration states that the <code class="element">A</code> element is to become a source anchor and that the <em>current</em> value of the special variable will be the URL of the anchor.</p>
|
||
|
|
|
||
|
|
<p>The two-step approach to defining hyperlinks may seem unnecessarily complicated. In the case of HTML's <code class="element">A</code> element (which is what the above example describes), a single-step approach would have achieved the goal. However, in some languages the URL of the anchor is not defined on the same element as the source anchor so the simplest solution will not always work. Consider this example from WML <a href="#WML">[WML]</a>:</p>
|
||
|
|
|
||
|
|
<pre><anchor>follow me
|
||
|
|
<go href="destination"/>
|
||
|
|
</anchor>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The markup above should have the same effect as this HTML markup:</p>
|
||
|
|
|
||
|
|
<pre><a href="destination">follow me</a>
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>WML's <code class="element">anchor</code> element poses a challenge since the URL of the anchor is not found in an attribute of the element itself, but rather in an attribute of a child element (namely <code class="element">go</code>). Clink can describe this behavior with:</p>
|
||
|
|
|
||
|
|
<pre>go { -o-link-source: attr(href) }
|
||
|
|
anchor { -o-link: next }
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>The first rule states that the <code class="attribute">href</code> attribute of the <code class="element">go</code> element contains the URL of the anchor. The second rule turns the <code class="element">anchor</code> element into a source anchor, and also states that the URL of the anchor will be found in the <em>next</em> assignment of the link variable (<code class="value">next</code> and <code class="value">current</code> are the only values on the <code class="property">-o-link</code> property).</p>
|
||
|
|
|
||
|
|
<h3 id="h-351">Replaced elements</h3>
|
||
|
|
|
||
|
|
<p>In HTML, images and other non-textual content are stored outside the document. For example, the <code class="element">IMG</code> element is part of the document structure, but the element only holds a link to the image data. When the document is presented to the user, the image data are automatically fetched and the <code class="element">IMG</code> element is replaced by the decoded image. As such, the <code class="element">IMG</code> element is an example of a <a href="#replaced_element" class="term">replaced element</a>. To achieve the same functionality in documents written in arbitrary XML, there must be a way to declare elements as replaced. In Clink, the <code class="property">-o-replace</code> property fulfills this role. Consider the following:</p>
|
||
|
|
|
||
|
|
<pre>picture {
|
||
|
|
-o-replace: attr(source)
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>In the above example, the fictional <code class="element">picture</code> element is set to be replaced and the replaced content will be fetched from a URL found on the <code class="attribute">source</code> attribute.</p>
|
||
|
|
|
||
|
|
<h2 id="h-353">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>Clink is an example of a non-stylistic use of CSS. Instead of stylistic properties, Clink distributes properties that describe linking information onto elements. Thus, Clink highlights the fact that out of six required components of a style sheet language (syntax, selectors, properties, values and units, value propagation mechanism, and formatting model), only one (the formatting model) necessarily has anything to do with style.</p>
|
||
|
|
|
||
|
|
<p>A range of other non-stylistic uses of style sheets can be imagined, and only a few of these have been explored.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-future" title="Future research">
|
||
|
|
<h1 class="chapter" id="h-354">Future research</h1>
|
||
|
|
|
||
|
|
<p>Style sheets form an interesting area of research. In addition to intellectual challenges, which most research domains can offer, this author thinks there are two reasons why the study of style sheets is attractive. First, as Marden and Munson write, style sheets have been <q>terribly underresearched</q> in the past <a href="#Marden_1999">[Marden&Munson 1999]</a>. This makes it possible for young researchers to contribute without first spending years studying what others have done. Second, the web contains an increasing amount of information. In order to make this information human readable, style sheets are necessary. Therefore, in the foreseeable future, style sheets are likely to influence the presentation of a significant part of human information.</p>
|
||
|
|
|
||
|
|
<p>This section lists questions that, hopefully, future research will answer. Some of the questions are easier to answer than others. To avoid doing research on future research, there is no farther classifications of the questions.</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Is there an ideal level of abstraction for markup languages? Users want beautiful presentations, but also searchable documents. Some users have special needs and depend on device-independent markup languages to access information. Authors seem to have limited desire to add more semantics to their documents, but would surely like to see their content presented on a range of devices. Conflicting constraints like these indicate that there is no single ideal level of abstraction, but that document formats for the web need to cover a range of steps on the ladder of abstraction. How should this influence the design of future markup languages?
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>Can style sheets describe presentation in domains other than electronic documents? Just like markup languages can be used for more than markup (XML is a case in point), style sheet languages may also be for more than document presentation. For example, can style sheets describe architecture? Here is a simplistic example:
|
||
|
|
|
||
|
|
<pre>Norway Oslo Drammensvn 97 b {
|
||
|
|
floors: 3;
|
||
|
|
color: #FCA;
|
||
|
|
roof: mansard;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>What other non-stylistic uses are there for style sheets? How the CSS syntax and value propagation mechanism was used to distribute non-stylistic property values to elements was discussed in <a href="#ch-clink">Chapter 9</a>, and Daniel Glazman has developed a transformation language using a CSS-based syntax <a href="#Glazman_1997">[Glazman 1997]</a>. Most likely, there are other interesting uses of the same mechanisms. For example, one could easily think of using CSS to describe schema-like information about elements:
|
||
|
|
|
||
|
|
<pre>p {
|
||
|
|
nestable: no;
|
||
|
|
end-tag: optional;
|
||
|
|
legal-inside: body, div;
|
||
|
|
attributes: href, style, class;
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>How are style sheets used on the web today? The use of style sheets in word processing applications has been researched <a href="#Sorgaard_1996">[Sørgaard 1996]</a>, but the use of style sheets on the web has not been thoroughly investigated. What features of CSS are being used? Are style sheets only used to encode what HTML's <code class="element">FONT</code> element already represents in a document, or are sites using CSS to fully describe their design?
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>Can cascading be used to resolve other conflicts between users, programs and authors? For example, can cascading be used to determine GUI settings of an application? In many ways it is similar to document presentation; the author (programmer) would like to suggest default settings, but the user should be given the final word. Could CSS be used to express user preferences for applications?</li>
|
||
|
|
|
||
|
|
<li>Can glyph shapes be taken into consideration by style sheet languages? Typography in advertising and other artistic expressions often aligns glyphs based on their shapes. No known style sheet language has attempted to describe typography at this level of detail. How should it be done?</li>
|
||
|
|
|
||
|
|
<li>Can HTML/CSS be used as a storage format for office documents? Microsoft's suite of <em>Office</em> applications are typically used to author documents (including letters, contracts, and manuscripts), spread sheets, and projected presentations. HTML and CSS can probably express most documents. Also, by using the <code>projection</code> feature of CSS2, many projected presentations can be described. Tables in HTML can be used to express spread sheets, but are not able to encode relationships between cells. Can the missing functionality be added so that, for example, OpenOffice <a href="#OpenOffice">[OpenOffice]</a> can use HTML/CSS as the native storage format?</li>
|
||
|
|
|
||
|
|
<li>To what extent have browser vendors used style sheets in their marketing campaigns? How do the marketing efforts correlate with actual levels of support?</li>
|
||
|
|
|
||
|
|
<li>Can some of the problems described in <a href="#ch-problems">Chapter 7</a> be fixed?</li>
|
||
|
|
|
||
|
|
<li>XSL has not been thoroughly reviewed in this thesis. How does XSL compare with the languages and proposals discussed in this thesis?
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>Should future markup languages be designed around CSS? In the past, style sheet languages have trailed markup languages, and the former, therefore, had to be designed to work with markup languages. In the future, the situation may be turned around; markup languages may be designed so that their content can easily be presented through deployed style sheet languages. For example, Chavchanidze <a href="#Chavchanidze_2004">[Chavchanidze 2004]</a> has done some interesting work on how to represent mathematical notation in a CSS-friendly XML-based language.</li>
|
||
|
|
|
||
|
|
<li>In 1993, it was argued that HTML should be <q>frozen</q> and that a new markup language for the web should be developed <a href="#Dougherty_1993">[Dougherty 1993]</a>. What has the web gained and lost by evolving a backwards-compatible HTML rather than freezing it?
|
||
|
|
|
||
|
|
<p>The style sheet languages and proposals discussed in this thesis all follow a similar pattern: style sheets express rules that associate stylistic properties and values with structural elements in a document. Indeed, this is the proposed definition of a style sheet in electronic publishing. Are there other models that would serve the goals of content reuse and device independence better? For example, would a template-based approach where textual content is imported into tables be feasible? The tables and associated markup would be presentational, but the imported resources could be reused in other contexts as well.</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>Is it possible to use extension mechanisms offered by browsers to fix their support for style sheet languages? In particular, is it possible to <q>extend</q> Microsoft's Internet Explorer so that it renders CSS correctly?</li>
|
||
|
|
|
||
|
|
<li>Two of the languages reviewed (P94, PSL96) are explicitly based on constraints. Does it make sense to retrofit constraints into CSS? This approach was proposed by <a href="#Badros_1999">[Badros et al. 1999]</a>. To some extent it can be argued that CSS already is built on constraints, but can the language be improved further by making constraints more visible for designers?</li>
|
||
|
|
|
||
|
|
<li>Is it possible to use constraints to mathematically verify formatting models? This approach was proposed by <a href="#Michalowski_1998">[Michalowski 1998]</a>. For example, can one describe the CSS visual formatting model as a constraint-based system to discover inconsistencies and other errors of design?</li>
|
||
|
|
|
||
|
|
<li>Knowing what we know today, what would the ideal style sheet language look like?
|
||
|
|
</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h2 id="h-355">Summary and conclusions</h2>
|
||
|
|
|
||
|
|
<p>Style sheets, an interesting area of study, have much room left for future research. This chapter has posed some questions which may be of interest to researchers in the future.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="chapter" id="ch-conclusion" title="Conclusions">
|
||
|
|
<h1 class="chapter" id="h-356">Conclusions</h1>
|
||
|
|
|
||
|
|
<p>This chapter describes, in a compressed form, what I believe can be learnt from this thesis.</p>
|
||
|
|
|
||
|
|
<p>The hypothesis of this thesis is that the web calls for different style sheet languages than does traditional electronic publishing. I believe it has been shown that the hypothesis is true. The introduction outlined the web's unique characteristics as a publishing environment, and the these characteristics were formulated as requirements for a web style sheet language in <a href="#ch-webreq">Chapter 5 (Web requirements)</a>. None of the style sheet languages developed before the web fulfill – or are close to fulfilling – the web's requirements and, therefore, it seems reasonable to conclude that the hypothesis is correct.</p>
|
||
|
|
|
||
|
|
<p>One could argue that even though a different language is required, it was not necessary to develop a new language. A modified version of an existing language could have been sufficient. This approach was taken by DSSSL Lite as discussed in <a href="#ch-postweb">Chapter 4</a>. In retrospect, I think a modified version of FOSI could have been successfully adapted for use on the web, but it would not have significant advantages over CSS. On the contrary, CSS – by being designed specifically for the web while also learning from style sheets languages such as DSSSL – is able to address the requirements of the web.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<p>Further, the thesis describes five important contributions to the field of study: the dissemination of style sheet languages into six required components; the description of web requirements for style sheet languages; the comparative analysis of the different style sheet languages and proposals; the ladder of abstraction; and CSS itself.</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>In order to compare different style sheet languages, it is necessary to establish common criteria by which the languages will be judged. <a href="#ch-preweb">Chapter 3</a> describes a set of criteria for style sheet languages with six required components: syntax, selectors, properties, values and units, a value propagation mechanism, and a formatting model.</li>
|
||
|
|
|
||
|
|
<li>This thesis provides the first comprehensive comparative analysis of style sheet languages. Such languages developed before the web, and style sheet proposals developed for the web, have been evaluated for each of the six required components of a style sheet language. Also, all languages and proposals have been evaluated against a set of web requirements.</li>
|
||
|
|
|
||
|
|
<li>The web adds new requirements for style sheet languages. Among the requirements described in this thesis are the need to be stream-based, and to support screen-centric designs.</li><!-- errata: removed spurious "is"-->
|
||
|
|
|
||
|
|
<li>The ladder of abstraction is proposed as a method for evaluating electronic document formats. How high a certain document format is on the ladder will determine the complexity of formatting the document for presentation. Since the formatting of a document is specified by a style sheet, the abstraction level of target documents is crucial for the success of a style sheet language. Also, the ladder of abstraction is helpful when evaluating the accessibility of various document formats.
|
||
|
|
|
||
|
|
<p>When designing new document formats, therefore, one should always consider how documents written in the new format will be presented. Defining a new syntax for a document format is quite simple compared with the task of designing a presentation mechanism for the document format.</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>CSS has some unique and innovative features, including cascading, pseudo-elements and pseudo-classes, forward-compatible parsing, and media types. By now, CSS has established itself as one of the fundamental specifications on the web and most web sites are using it. As such, the efforts to create a style sheet language for the web have been successful. Also, CSS has partially fulfilled its ambition of maintaining HTML as a structured markup language and ensuring that documents can be styled by users. Alas, due to limited support for CSS in the dominant browser on the web, CSS cannot yet be used in full.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>In addition to the main contributions listed above, this author has – during the course of the work – come to believe the following to be true:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>In the past, structured documents have suffered from a lack of style sheet languages. While proponents of structured documents, SGML in particular, argued their case and further developed ways to create structured documents, little attention was paid to the presentation of documents.</li>
|
||
|
|
|
||
|
|
<li>HTML has the right level of abstraction for a general-purpose markup language: it is high enough on the ladder of abstraction to support presentation on a wide range of devices, and low enough for people to grasp easily the meaning of elements.</li>
|
||
|
|
|
||
|
|
<li><!--errata: replaced p with li -->Scribe, rather than SGML, probably would have been a better starting point for the development of HTML. Scribe offers the best of HTML (there is a default set of tags and conventions on how to present them), CSS (there is a default set of presentational conventions that can be modified), and XML (new elements can be created). Also, Scribe is much simpler than SGML. On the other hand, there might have been legal problems with using Scribe, and Scribe's presentation system might not have evolved into a style sheet language that fulfills the requirements of the web.</li>
|
||
|
|
|
||
|
|
<li>Most of the style sheet languages that were proposed for the web contained some innovative features. Some of these were later included in the development of CSS, but many were not. There are good reasons for not including all suggested features as the resulting specification will be too complex and may have conflicting functionality. However, some of the ideas proposed would have improved style sheets for the web and I believe it's unfortunate that CSS did not include them. In particular, the length units relative to the display (<code>pcd</code>, <code>nlh</code>, <code>p</code>) proposed by JEP would have been a valuable addition.</li>
|
||
|
|
|
||
|
|
<li>Transformation-based style sheet languages may be suitable in traditional publishing environments but they are not suitable on the web. This is primarily due to not being able to support progressive rendering.</li>
|
||
|
|
|
||
|
|
<li>Specifications can fail for a number of reasons. One of the specifications mentioned in this thesis, ODA, has three significant factors against it: complexity, it uses a binary encoding system, and the specification is not freely available. Rather, specifications should be simple, the language they describe should be easy to read and write, and the specification should <!-- errata: corrected spelling of "should" --> be freely available.</li>
|
||
|
|
|
||
|
|
<li>Having an archived mailing list open to the public is very important for the design of new specifications. Such a list will attract skilled people with new ideas, and it allows the authors and editors of a specification to express the thinking behind features. In the case of CSS, a community formed around the www-style mailing list. For a retrospective analysis, like this thesis, the mailing list archives provide valuable information.</li>
|
||
|
|
|
||
|
|
<li>Interoperability is one of the main goals for web specifications. Next to the specification itself, a comprehensive test suite is the most important tool for ensuring interoperability. In retrospect, the introduction of CSS on the web would have been faster and easier if a test suite had been developed concurrently with the specification.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="glossary" id="ch-terminology">
|
||
|
|
<h1 class="uuchapter" id="h-357">Glossary</h1>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a id="actual_value" name="actual_value">actual value</a></dt>
|
||
|
|
|
||
|
|
<dd>The property value which is actually used in the presentation of the document. The actual value may be different from the <a href="#specified_value" class="term">specified value</a> due to limitations in the output device (e.g., the lack of certain font sizes).</dd>
|
||
|
|
|
||
|
|
<dt><a id="anchor" name="anchor">anchor</a></dt>
|
||
|
|
|
||
|
|
<dd>An end point of a <a href="#link" class="term">link</a>. There are two types of anchors: <a href="#source_anchor" class="term">source anchors</a> and <a href="#target_anchor" class="term">target anchors</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="application" name="application">application</a></dt>
|
||
|
|
|
||
|
|
<dd>A (somewhat complex) computer program that has a user interface.</dd>
|
||
|
|
|
||
|
|
<dt><a id="area" name="area">area</a></dt>
|
||
|
|
|
||
|
|
<dd>An area is to a <a href="#sequence_model" class="term">sequence model</a> what a <a href="#box" class="term">box</a> is in a <a href="#box_model" class="term">box model</a>. That is, an area is a rectangular container that encloses <a href="#content" class="term">content</a> and which is laid out in the <a href="#layout_area" class="term">layout area</a>. There are two main types of areas: <a href="#display_area" class="term">display areas</a> and <a href="#inline_area" class="term">inline areas</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="attribute" name="attribute">attribute</a></dt>
|
||
|
|
|
||
|
|
<dd>A name or name/value pair written inside a start <a href="#tag" class="term">tag</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="author" name="author">author</a></dt>
|
||
|
|
|
||
|
|
<dd>A person who writes documents and associated style sheets.</dd>
|
||
|
|
|
||
|
|
<dt><a id="author_style_sheet" name="author_style_sheet">author style sheet</a></dt>
|
||
|
|
|
||
|
|
<dd>A style sheet embedded into, or linked from, a document.</dd>
|
||
|
|
|
||
|
|
<dt><a id="band" name="band">band</a></dt>
|
||
|
|
|
||
|
|
<dd>A box in the CSS box model has three bands: padding, border and margin. The bands are surfaces which surround the boxes. Margin bands may have negative width, while padding and border bands must be zero or positive.</dd>
|
||
|
|
|
||
|
|
<dt><a id="binding" name="binding">binding</a></dt>
|
||
|
|
|
||
|
|
<dd>The process of combining a <a href="#structured_document" class="term">structured document</a> with a style sheet with the intention of <a href="#formatting" class="term">formatting</a> the document into a <a href="#final_form" class="term">final form</a> presentation.</dd>
|
||
|
|
|
||
|
|
<dt><a id="block-level_element" name="block-level_element">block-level element</a></dt>
|
||
|
|
|
||
|
|
<dd>An element which generates one or more <a href="#block_box" class="term">block boxes</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="block_box" name="block_box">block box</a></dt>
|
||
|
|
|
||
|
|
<dd>A box generated by a <a href="#block-level_element" class="term">block-level element</a>, which has a line break before and after itself.</dd>
|
||
|
|
|
||
|
|
<dt><a id="box" name="box">box</a></dt>
|
||
|
|
|
||
|
|
<dd>A rectangular container that encloses <a href="#content" class="term">content</a> and other boxes which is laid out in the <a href="#layout_area" class="term">layout area</a>. There are two main types of boxes: <a href="#block_box" class="term">block boxes</a> and <a href="#inline_box" class="term">inline boxes</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="box_model" name="box_model">box model</a></dt>
|
||
|
|
|
||
|
|
<dd>A visual formatting model where content is laid out in nested rectangular <a href="#box" class="term">boxes</a> that form a tree structure.</dd>
|
||
|
|
|
||
|
|
<dt><a id="browser" name="browser">browser</a></dt>
|
||
|
|
|
||
|
|
<dd>See <a href="#web_browser" class="term">web browser</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="browser_style_sheet" name="browser_style_sheet">browser style sheet</a></dt>
|
||
|
|
|
||
|
|
<dd>A style sheet that describes the default presentation of documents.</dd>
|
||
|
|
|
||
|
|
<dt><a id="cascading" name="cascading">cascading</a></dt>
|
||
|
|
|
||
|
|
<dd>The process of combining several style sheets and resolving conflicts between them.</dd>
|
||
|
|
|
||
|
|
<dt><a id="character" name="character">character</a></dt>
|
||
|
|
|
||
|
|
<dd>An entry in the Unicode Character Database [Unicode].</dd>
|
||
|
|
|
||
|
|
<dt><a id="client" name="client">client</a></dt>
|
||
|
|
|
||
|
|
<dd>An <a href="#application">application</a> that communicates with a server over a network.</dd>
|
||
|
|
|
||
|
|
<dt><a id="constraint" name="constraint">constraint</a></dt>
|
||
|
|
|
||
|
|
<dd>An expression of a restrictive geometrical relationship between elements.</dd>
|
||
|
|
|
||
|
|
<dt><a id="content" name="content">content</a></dt>
|
||
|
|
|
||
|
|
<dd>The parts of a <a href="#source_document" class="term">source document</a> which are not <a href="#markup" class="term">markup</a>. Also, the term refers to externally linked resources, for example, images and graphics.</dd>
|
||
|
|
|
||
|
|
<dt><a id="content_model" name="content_model">content model</a></dt>
|
||
|
|
|
||
|
|
<dd>The content model describes which constructs (e.g., elements and attributes) are allowed where in the structure of a document.</dd>
|
||
|
|
|
||
|
|
<dt><a id="contextual_selector" name="contextual_selector">contextual selector</a></dt>
|
||
|
|
|
||
|
|
<dd>A <a href="#selector" class="term">selector</a> whose search pattern depends on multiple elements, rather than a single one.</dd>
|
||
|
|
|
||
|
|
<dt><a id="continous_media" name="continous_media">continuous media type</a></dt>
|
||
|
|
|
||
|
|
<dd>A class of output devices which has a continuous, rather than a <a href="#paged_media" class="term">paged</a> presentation surface.</dd>
|
||
|
|
|
||
|
|
<dt><a id="containing_block" name="containing_block">containing block</a></dt>
|
||
|
|
|
||
|
|
<dd>A rectangular box generated by a block-level ancestor element to which a descendant box relates geometrically.</dd>
|
||
|
|
|
||
|
|
<dt><a id="declaration" name="declaration">declaration</a></dt>
|
||
|
|
|
||
|
|
<dd>A <a href="#property" class="term">property</a> and <a href="#value" class="term">value</a> pair.</dd>
|
||
|
|
|
||
|
|
<dt><a id="declarative" name="declarative">declarative language</a></dt>
|
||
|
|
|
||
|
|
<dd>A declarative language is a general term for languages which express relationships between variables, as opposed to imperative languages which specify explicit sequences of steps to be followed, in order to produce a result. Often, declarative languages are not <a href="#turing-complete" class="term">Turing-complete</a>, while imperative languages are. All style sheet languages described in this thesis are declarative.</dd>
|
||
|
|
|
||
|
|
<dt><a id="default_style_sheet" name="default_style_sheet">default style sheet</a></dt>
|
||
|
|
|
||
|
|
<dd>A style sheet which describes a default presentation of a <a href="#document_language" class="term">document language</a> (e.g., HTML) and which is embedded into a browser.</dd>
|
||
|
|
|
||
|
|
<dt><a id="designer" name="designer">designer</a></dt>
|
||
|
|
|
||
|
|
<dd>A person who writes style sheets.</dd>
|
||
|
|
|
||
|
|
<dt><a id="digital" name="digital">digital document</a></dt>
|
||
|
|
|
||
|
|
<dd>A document represented by digits on a medium which is computer readable (e.g., a hard disk or CD-ROM) but not human readable.</dd>
|
||
|
|
|
||
|
|
<dt><a id="display_area" name="display_area">display area</a></dt>
|
||
|
|
|
||
|
|
<dd>A rectangular <a href="#area" class="term">area</a> generated by a <a href="#block-level_element" class="term">block-level element</a> in a <a href="#sequence_model" class="term">sequence model</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="document" name="document">document</a></dt>
|
||
|
|
|
||
|
|
<dd>A collection of content, typically consisting of text, images and graphics. Traditionally, documents reach readers on printed paper, but <a href="#electronic_publishing" class="term">electronic publishing</a> is increasingly popular.</dd>
|
||
|
|
|
||
|
|
<dt><a id="document_format" name="document_format">document format</a></dt>
|
||
|
|
|
||
|
|
<dd>A language for storing and exchanging digital documents, for example, HTML.</dd>
|
||
|
|
|
||
|
|
<dt><a id="document_language" name="document_language">document language</a></dt>
|
||
|
|
|
||
|
|
<dd>The <a href="#document_format" class="term">document format</a> of the <a href="#source_document" class="term">source document</a>, for example HTML.</dd>
|
||
|
|
|
||
|
|
<dt><a id="draft" name="draft">draft</a></dt>
|
||
|
|
|
||
|
|
<dd>A <a href="#proposal" class="term">proposal</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="editor" name="editor">editor</a></dt>
|
||
|
|
|
||
|
|
<dd>An <a href="#application" class="term">application</a> which allows its users to compose and edit <a href="#document" class="term">documents</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="electronic_publishing" name="electronic_publishing">electronic publishing</a></dt>
|
||
|
|
|
||
|
|
<dd>A form of publishing where documents are transmitted in digital form from the author to the reader. The <a href="#web" class="term">web</a> is an example of electronic publishing.</dd>
|
||
|
|
|
||
|
|
<dt><a id="element" name="element">element</a></dt>
|
||
|
|
|
||
|
|
<dd>The primary syntactic construct of a <a href="#structured_document" class="term">structured document</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="element_type" name="element_type">element type</a></dt>
|
||
|
|
|
||
|
|
<dd>The name of an element (e.g., <code class="element">H1</code> and <code class="element">BLOCKQUTE</code> in HTML). The element type is referred to as the <em>Generic Identifier</em> in SGML.</dd>
|
||
|
|
|
||
|
|
<dt><a id="embedded_style_sheets" name="embedded_style_sheets">embedded style sheets</a></dt>
|
||
|
|
|
||
|
|
<dd>Style sheets which are placed inside a document, rather than linked to. In HTML, style sheets can be embedded in the <code class="element">STYLE</code> element and in the <code class="attribute">STYLE</code> attribute.</dd>
|
||
|
|
|
||
|
|
<dt><a id="environment_variable" name="environment_variable">environment variable</a></dt>
|
||
|
|
|
||
|
|
<dd>A parameter in the user's environment, for example, the width of the display or the time of day.</dd>
|
||
|
|
|
||
|
|
<dt><a id="fallback_value" name="fallback_value">fallback value</a></dt>
|
||
|
|
|
||
|
|
<dd>A <a href="#value" class="term">value</a> which is used if the intended value is unavailable, for example, while the style sheet is being downloaded.</dd>
|
||
|
|
|
||
|
|
<dt><a id="final_form" name="final_form">final form</a></dt>
|
||
|
|
|
||
|
|
<dd>A document is said to be in its <em>final form</em> when it no longer can be edited, and is ready for presentation to the user. A final form document can either be in a digital format (e.g., PDF) or printed on paper.</dd>
|
||
|
|
|
||
|
|
<dt><a id="flow_object" name="flow_object">flow object</a></dt>
|
||
|
|
|
||
|
|
<dd>DSSSL's term for <a href="#formatting_object" class="term">formatting object</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="font" name="font">font</a></dt>
|
||
|
|
|
||
|
|
<dd>A typeface which can be classified by several characteristics, including family, size, weight and slant.</dd>
|
||
|
|
|
||
|
|
<dt><a id="formatter" name="formatter">formatter</a></dt>
|
||
|
|
|
||
|
|
<dd>A computer program that formats a document.</dd>
|
||
|
|
|
||
|
|
<dt><a id="formatting" name="formatting">formatting</a></dt>
|
||
|
|
|
||
|
|
<dd>The process of converting a <a href="#structured_document" class="term">structured document</a> combined with a style sheet into a <a href="#final_form" class="term">final form</a> presentation.</dd>
|
||
|
|
|
||
|
|
<dt><a id="formatting_model" name="formatting_model">formatting model</a></dt>
|
||
|
|
|
||
|
|
<dd>A schematic description of all presentation-oriented features a style sheet language is capable of expressing.</dd>
|
||
|
|
|
||
|
|
<dt><a id="formatting_object" name="formatting_object">formatting object</a></dt>
|
||
|
|
|
||
|
|
<dd>An object which embodies certain content, along with information on how to present the content. An object which describes how a certain element is to be presented. The formatting object has no information about the logical role of the element; only about the presentation of the elements. The formatting object may be expressed in explicit markup (XSL-FO) or only exist within a formatter (CSS). If expressed in explicit markup, a formatting object is similar to a <a href="#presentational_element" class="term">presentational element</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="forward-compatible_parsing" name="forward-compatible_parsing">forward-compatible parsing</a></dt>
|
||
|
|
|
||
|
|
<dd>A grammar that is valid for all versions of a language: past, present and future. The purpose of the forward-compatible parsing in CSS is to allow future versions to include new functionality while ensuring that older implementations can parse the new style sheets.</dd>
|
||
|
|
|
||
|
|
<dt><a id="generated_content" name="generated_content">generated content</a></dt>
|
||
|
|
|
||
|
|
<dd>Content which is specified in the style sheet rather than in the <a href="#source_document" class="term">source document</a>. Examples of generated content include simple strings, quote marks, counters, cross-references, headers/footers, horizontal rules, and table of contents.</dd>
|
||
|
|
|
||
|
|
<dt><a id="generated_text" name="generated_text">generated text</a></dt>
|
||
|
|
|
||
|
|
<dd>Textual content which is specified in the style sheet rather than in the <a href="#source_document" class="term">source document</a>. Generated text is a form of <a href="#generated_content" class="term">generated content</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="generic_markup" name="generic_markup">generic markup</a></dt>
|
||
|
|
|
||
|
|
<dd>Markup where the vocabulary of tags and other symbols are unknown to the recipient. That is, the markup can only be processed at the syntax level and not at any higher levels of abstraction.</dd>
|
||
|
|
|
||
|
|
<dt><a id="glyph" name="glyph">glyph</a></dt>
|
||
|
|
|
||
|
|
<dd>A shape in a <a href="#font" class="term">font</a> that is used to represent one or more <a href="#character" class="term">characters</a> in the <a href="#layout_area" class="term">layout area</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="gui" name="gui">GUI</a></dt>
|
||
|
|
|
||
|
|
<dd>Graphical user interface.</dd>
|
||
|
|
|
||
|
|
<dt><a id="individual_property" name="individual_property">individual property</a></dt>
|
||
|
|
|
||
|
|
<dd>A property which is not a <a href="#shorthand_property" class="term">shorthand property</a>. That is, setting a value on an individual property does not assign values to properties other than the individual property.</dd>
|
||
|
|
|
||
|
|
<dt><a id="inheritance" name="inheritance">inheritance</a></dt>
|
||
|
|
|
||
|
|
<dd>A value propagation mechanism that transfers property values from a parent element to its child elements. The main benefit of inheritance is less verbose style sheets.</dd>
|
||
|
|
|
||
|
|
<dt><a id="initial_containing_block" name="initial_containing_block">initial containing block</a></dt>
|
||
|
|
|
||
|
|
<dd>A rectangular box, established by the formatter, which serves as the container for a document's presentation.</dd>
|
||
|
|
|
||
|
|
<dt><a id="inline_area" name="inline_area">inline area</a></dt>
|
||
|
|
|
||
|
|
<dd>A rectangular <a href="#area" class="term">area</a> generated by an <a href="#inline_element" class="term">inline element</a> in a <a href="#sequence_model" class="term">sequence model</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="inline_box" name="inline_box">inline box</a></dt>
|
||
|
|
|
||
|
|
<dd>A box generated by a <a href="#inline_element" class="term">inline element</a> which, in general, does not have a line break before and after itself.</dd>
|
||
|
|
|
||
|
|
<dt><a id="inline_element" name="inline_element">inline element</a></dt>
|
||
|
|
|
||
|
|
<dd>An element which generates one or more <a href="#inline_box" class="term">inline boxes</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="initial_value" name="initial_value">initial value</a></dt>
|
||
|
|
|
||
|
|
<dd>The value given to an element/property combination if no other value is set or inherited. Often called the <q>default</q> value.</dd>
|
||
|
|
|
||
|
|
<dt><a id="inside-out_formatting" name="inside-out_formatting">inside-out formatting</a></dt>
|
||
|
|
|
||
|
|
<dd>Formatting where the size of the box (or area) is determined by its content.</dd>
|
||
|
|
|
||
|
|
<dt><a id="instant_binding" name="instant_binding">instant binding</a></dt>
|
||
|
|
|
||
|
|
<dd>The concept of combining structured documents with style sheets in real time during the authoring process.</dd>
|
||
|
|
|
||
|
|
<dt><a id="ladder_of_abstraction" name="ladder_of_abstraction">ladder of abstraction</a></dt>
|
||
|
|
|
||
|
|
<dd>A measurement tool for digital documents. Documents that are high on the ladder of abstraction are semantically richer than documents that are low on the ladder of abstraction. Also, documents that are high on the ladder need more processing before reaching their <a href="#final_form" class="term">final form</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="late_binding" name="late_binding">late binding</a></dt>
|
||
|
|
|
||
|
|
<dd>The concept of combining structured documents with style sheets after the authoring has been completed. This way, authors do not have to worry about the presentation of the document during authoring.</dd>
|
||
|
|
|
||
|
|
<dt><a id="later_binding" name="later_binding">later binding</a></dt>
|
||
|
|
|
||
|
|
<dd>The concept of combining structured documents with style sheets on the user side rather than on the author side, thereby allowing user preferences to be taken into account.</dd>
|
||
|
|
|
||
|
|
<dt><a id="layout_area" name="layout_area">layout area</a></dt>
|
||
|
|
|
||
|
|
<dd>A two-dimensional surface onto which documents are rendered, for example, printed paper and computer screens.</dd>
|
||
|
|
|
||
|
|
<dt><a id="leading" name="leading">leading</a></dt>
|
||
|
|
|
||
|
|
<dd>Typographers used to add pieces of lead to increase the space between lines of typesetting. The term <em>leading</em> describes the space between lines. In CSS, the term refers to the difference between the values of <code class="property">font-size</code> and <code class="property">line-height</code>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="link" name="link">link</a></dt>
|
||
|
|
|
||
|
|
<dd>A connection from one web resource to another. A link has two ends, called <a href="#anchor" class="term">anchors</a>, and a direction.</dd>
|
||
|
|
|
||
|
|
<dt><a id="list-item_element" name="list-item_element">list-item element</a></dt>
|
||
|
|
|
||
|
|
<dd>A <a href="#block-level_element" class="term">block-level element</a> which generates a <a href="#list-item_marker" class="term">list-item marker</a> in addition to one or more block boxes.</dd>
|
||
|
|
|
||
|
|
<dt><a id="list-item_marker" name="list-item_marker">list-item marker</a></dt>
|
||
|
|
|
||
|
|
<dd>A symbol or image that marks a list item, for example, a <em>bullet</em> or a <em>circle</em>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="logical_element" name="logical_element">logical element</a></dt>
|
||
|
|
|
||
|
|
<dd>An element whose role, as opposed to presentation, is known. For example, the <code class="element">H1</code> element in HTML specifies that its content is a headline of level 1, but says nothing about the presentation of the content. A logical element is higher on the <a href="#ladder_of_abstraction" class="term">ladder of abstraction</a> than is a <a href="#presentational_element" class="term">presentational element</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="logical_markup" name="logical_markup">logical markup</a></dt>
|
||
|
|
|
||
|
|
<dd><a href="#markup" class="term">Markup</a> consisting primarily of <a href="#logical_element" class="term">logical elements</a>, rather than <a href="#presentational_element" class="term">presentational elements</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="logical_structure" name="logical_structure">logical structure</a></dt>
|
||
|
|
|
||
|
|
<dd>A document representation consisting primarily of <a href="#logical_element" class="term">logical elements</a>, rather than <a href="#formatting_object" class="term">formatting objects</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="markup" name="markup">markup</a></dt>
|
||
|
|
|
||
|
|
<dd>Tags and other symbols that, when embedded into <a href="#content" class="term">content</a>, form a <a href="#source_document" class="term">source document</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="markup_language" name="markup_language">markup language</a></dt>
|
||
|
|
|
||
|
|
<dd>A vocabulary of tags and other symbols that, when embedded into content, increases the level of abstraction and enables the processing of the content.</dd>
|
||
|
|
|
||
|
|
<dt><a id="media_type" name="media_type">media type</a></dt>
|
||
|
|
|
||
|
|
<dd>A class of output devices. CSS2 names nine media types (aural, braille, embossed, handheld, print, projection, screen, tty, tv) so that style sheets can be targeted for particular output devices.</dd>
|
||
|
|
|
||
|
|
<dt><a id="origin" name="origin">origin</a></dt>
|
||
|
|
|
||
|
|
<dd>The origin of a CSS style sheet is the author, the user, or the browser.</dd>
|
||
|
|
|
||
|
|
<dt><a id="out-of-order_rendering" name="out-of-order_rendering">out-of-order rendering</a></dt>
|
||
|
|
|
||
|
|
<dd>Presenting content in a different order from that specified in the <a href="#source_document" class="term">source document</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="output_device" name="output_device">output device</a></dt>
|
||
|
|
|
||
|
|
<dd>A physical unit capable of rendering documents visually or aurally.</dd>
|
||
|
|
|
||
|
|
<dt><a id="outside-in_formatting" name="outside-in_formatting">outside-in formatting</a></dt>
|
||
|
|
|
||
|
|
<dd>The size of the box (or area) is determined by its <a href="#containing_block" class="term">containing block</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="paged_media" name="paged_media">paged media</a></dt>
|
||
|
|
|
||
|
|
<dd>A class of output devices which divides the <a href="#layout_area" class="term">layout area</a> into discrete pages rather than being <a href="#continous_media" class="term">continuous</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="point" name="point">point</a></dt>
|
||
|
|
|
||
|
|
<dd>A unit of length equal to 1/72nd of an inch.</dd>
|
||
|
|
|
||
|
|
<dt><a id="pixel" name="pixel">pixel</a></dt>
|
||
|
|
|
||
|
|
<dd>A pixel is the smallest addressable unit on bitmapped computer displays and printers. Lengths and font sizes are often measured in terms of pixels, and style sheet languages often offer pixels as unit of measurement. Since the density of pixels varies widely from one output device to another, CSS defines the pixel unit relative to a <a href="#reference_pixel" class="term">reference pixel</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="plug-in" name="plug-in">plug-in</a></dt>
|
||
|
|
|
||
|
|
<dd>A program which extends the functionality of a browser.</dd>
|
||
|
|
|
||
|
|
<dt><a id="presentational_element" name="presentational_element">presentational element</a></dt>
|
||
|
|
|
||
|
|
<dd>An element whose presentation, as opposed to role, is known. For example, the <code class="element">B</code> element in HTML specifies that its content should be presented bold-faced, but says nothing about the role of the content. A presentational element is lower on the <a href="#ladder_of_abstraction" class="term">ladder of abstraction</a> than is a <a href="#logical_element" class="term">logical element</a>. A presentational element is at the same level of abstraction as a <a href="#formatting_object" class="term">formatting object</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="presentational_structure" name="presentational_structure">presentational structure</a></dt>
|
||
|
|
|
||
|
|
<dd>A document representation consisting of <a href="#formatting_object" class="term">formatting objects</a> rather than <a href="#logical_element" class="term">logical elements</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="procedural_markup" name="procedural_markup">procedural markup</a></dt>
|
||
|
|
|
||
|
|
<dd>Markup that denote imperative instructions to the <a href="#formatter" class="term">formatter</a> (for example, a instruction to start on a new page).</dd>
|
||
|
|
|
||
|
|
<dt><a id="processing_instruction" name="processing_instruction">processing instruction</a></dt>
|
||
|
|
|
||
|
|
<dd>A syntactic construct in SGML and XML.</dd>
|
||
|
|
|
||
|
|
<dt><a id="progressive_rendering" name="progressive_rendering">progressive rendering</a></dt>
|
||
|
|
|
||
|
|
<dd>Browsers that support progressive rendering are able to display documents incrementally as they are downloaded from the web.
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="proposal" name="proposal">proposal</a></dt>
|
||
|
|
|
||
|
|
<dd>An early, immature version of a <a href="#specification" class="term">specification</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="pseudo-class" name="pseudo-class">pseudo-class</a></dt>
|
||
|
|
|
||
|
|
<dd>A classification of elements much like the <code class="attribute">class</code> attribute in HTML, except that the classification happens automatically without any attribute present in the markup.</dd>
|
||
|
|
|
||
|
|
<dt><a id="property" name="property">property</a></dt>
|
||
|
|
|
||
|
|
<dd>A characteristic of an element which, when attached to a particular element and given a value, may influence the rendering the element.</dd>
|
||
|
|
|
||
|
|
<dt><a id="pseudo-element" name="pseudo-element">pseudo-element</a></dt>
|
||
|
|
|
||
|
|
<dd>Pseudo-elements mark sections of the document beyond those specified in the document itself. CSS has four pseudo-elements: two that are determined by formatting (<code class="selector">first-letter</code> and <code class="selector">first-line</code>) and two that support generated content (<code class="selector">before</code> and <code class="selector">after</code>).</dd>
|
||
|
|
|
||
|
|
<dt><a id="reader" name="reader">reader</a></dt>
|
||
|
|
|
||
|
|
<dd>See <a href="#user" class="term">user</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="reference_pixel" name="reference_pixel">reference pixel</a></dt>
|
||
|
|
|
||
|
|
<dd>In order for the <a href="#pixel" class="term">pixel</a> unit to be usable across a range of output devices, CSS describes how pixel values should be scaled if the pixel density is very different from that of a typical computer display. It is recommended that the <em>reference pixel</em> be the visual angle of one pixel on an output device with a pixel density of 90dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is, therefore, about 0.0227 degrees.</dd>
|
||
|
|
|
||
|
|
<dt><a id="replaced_element" name="replaced_element">replaced element</a></dt>
|
||
|
|
|
||
|
|
<dd>An element which is automatically replaced with content other than its own (e.g., an image) when the element is presented to a <a href="#user" class="term">user</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="root_element" name="root_element">root element</a></dt>
|
||
|
|
|
||
|
|
<dd>In a tree-structured document, the root element is the oldest ancestor of all other elements and the only element which has no parent.</dd>
|
||
|
|
|
||
|
|
<dt><a id="rule" name="rule">rule</a></dt>
|
||
|
|
|
||
|
|
<dd>A statement that consists of a selector and a declaration.</dd>
|
||
|
|
|
||
|
|
<dt><a id="selector" name="selector">selector</a></dt>
|
||
|
|
|
||
|
|
<dd>A search pattern that identifies to what elements the corresponding <a href="#declaration" class="term">declaration</a> applies.</dd>
|
||
|
|
|
||
|
|
<dt><a id="semantic_markup" name="semantic_markup">semantic markup</a></dt>
|
||
|
|
|
||
|
|
<dd>See <a href="#logical_markup" class="term">logical markup</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="sequence_model" name="sequence_model">sequence model</a></dt>
|
||
|
|
|
||
|
|
<dd>A visual formatting model in which content is laid out in a sequence of <a href="#area" class="term">areas</a> inside a <a href="#layout_area" class="term">layout area</a> (as opposed to the <a href="#box_model" class="term">box model</a>).</dd>
|
||
|
|
|
||
|
|
<dt><a id="shorthand_property" name="shorthand_property">shorthand property</a></dt>
|
||
|
|
|
||
|
|
<dd>Shorthand properties offer a way of setting the value of several related <a href="#individual_property" class="term">individual properties</a> into one simple declaration. For example, in CSS, the <code class="property">font</code> property is a shorthand property for setting all font-related properties (and <code class="property">line-height</code>) at once.</dd>
|
||
|
|
|
||
|
|
<dt><a id="small-screen_mode" name="small-screen_mode">small-screen mode</a></dt>
|
||
|
|
|
||
|
|
<dd>A browser that reformats documents for a small screen is said to be in <em>small-screen mode</em>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="source_anchor" name="source_anchor">source anchor</a></dt>
|
||
|
|
|
||
|
|
<dd>The starting point of a <a href="#link" class="term">link</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="source_document" name="source_document">source document</a></dt>
|
||
|
|
|
||
|
|
<dd>A structured document which, when combined with one or more style sheets in a <a href="#formatter" class="term">formatter</a>, produces a <a href="#final_form" class="term">final form</a> presentation.</dd>
|
||
|
|
|
||
|
|
<dt><a id="specification" name="specification">specification</a></dt>
|
||
|
|
|
||
|
|
<dd>A technical document that describes an aspect of communication between computers, for example a <a href="#document_format" class="term">document format</a>, <a href="#style_sheet_language" class="term">style sheet language</a>, or a transfer protocol. Before specifications reach a certain level of maturity, they are referred to as <q>proposals</q> or <q>drafts</q>. W3C's <em>Recommendations</em>, ISO's <em>Standards</em> and IETF's <em>RFCs</em> are examples of specifications.</dd>
|
||
|
|
|
||
|
|
<dt><a id="specificity" name="specificity">specificity</a></dt>
|
||
|
|
|
||
|
|
<dd>A measurement of how explicit is a <a href="#specificity" class="term">selector</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="specified_value" name="specified_value">specified value</a></dt>
|
||
|
|
|
||
|
|
<dd>The property value that is specified in the style sheet (as opposed to the <a href="#actual_value" class="term">actual value</a>).</dd>
|
||
|
|
|
||
|
|
<dt><a id="stream-based" name="stream-based">stream-based</a></dt>
|
||
|
|
|
||
|
|
<dd>A style sheet language that can support <a href="#progressive_rendering" class="term">progressive rendering</a> of documents is said to be stream-based.</dd>
|
||
|
|
|
||
|
|
<dt><a id="structured_document" name="structured_document">structured document</a></dt>
|
||
|
|
|
||
|
|
<dd>A digital document consisting of hierarchical elements containing text and other content. The elements primarily represent the logical roles of the content rather than the presentation of the content.</dd>
|
||
|
|
|
||
|
|
<dt><a id="structured_document_system" name="structured_document_system">structured document system</a></dt>
|
||
|
|
|
||
|
|
<dd>A system for electronic publishing that recognizes the difference between the <a href="#logical_structure" class="term">logical structure</a> and the <a href="#presentational_structure" class="term">presentational structure</a> of a document. Authors are typically encouraged to edit the logical structure, which is later transformed into a presentational structure. A structured document system consists of a <a href="#document_format" class="term">document format</a> and optional implementations. Examples of structured document systems are: LaTex, ODA, SGML, and HTML.</dd>
|
||
|
|
|
||
|
|
<dt><a id="style_sheet" name="style_sheet">style sheet</a></dt>
|
||
|
|
|
||
|
|
<dd style="page-break-inside: auto">In the context of electronic publishing, including this thesis, the following definition of a style sheet is offered:
|
||
|
|
|
||
|
|
<blockquote>A set of rules that associate stylistic properties and values with structural elements in a document, thereby expressing how to present the document. Style sheets generally do not contain content; are linkable from documents; and are reusable.</blockquote>
|
||
|
|
|
||
|
|
<p>Since style sheets are the topic of this thesis, some other definitions are also offered. They are, in chronological order:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>A definition of how the term is used in paper-based publishing is found in <a href="#Bruggemann-Klein_1992">[Brüggemann-Klein 1992]</a>:
|
||
|
|
|
||
|
|
<blockquote>A running account of rules about diction and language usage adopted for a particular manuscript</blockquote>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>From <a href="#English_1994a">[English 1994a]</a>:
|
||
|
|
|
||
|
|
<blockquote>A stylesheet is a collection of style specifications prepared by the document author.</blockquote>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>CSS1 <a href="#CSS1_1996">[CSS1 1996]</a> defined the term to mean:
|
||
|
|
|
||
|
|
<blockquote>a collection of rules</blockquote>
|
||
|
|
|
||
|
|
<p>where the term <q>rule</q> is defined as:</p>
|
||
|
|
|
||
|
|
<blockquote>a declaration (e.g. 'font-family: helvetica') and its selector (e.g. 'H1')</blockquote>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><!--errata: replaced p with li-->Another definition can be found in <a href="#Prescod_1997a">[Prescod 1997a]</a>:
|
||
|
|
|
||
|
|
<blockquote>... a series of statements that map structural elements (from the source document) into formatting objects.</blockquote>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>CSS2 <a href="#CSS2_1998">[CSS2 1998]</a> contained another definition of the term:
|
||
|
|
|
||
|
|
<blockquote>A set of statements that specify presentation of a document.</blockquote>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>From <a href="#Munson_1999">[Munson 1999]</a>:
|
||
|
|
|
||
|
|
<blockquote style="page-break-before: avoid">A style sheet is a specification of how a document should look.</blockquote>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="style_sheet_language" name="style_sheet_language">style sheet language</a></dt>
|
||
|
|
|
||
|
|
<dd>A language that has a syntax, selectors, properties, values and units, value propagation, and a formatting model. Style sheet languages are used to express <a href="#style_sheet" class="term">style sheets</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="surf" name="surf">surf</a></dt>
|
||
|
|
|
||
|
|
<dd>To browse <a href="#web" class="term">web</a> <a href="#document">documents</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="tag" name="tag">tag</a></dt>
|
||
|
|
|
||
|
|
<dd>A syntactic construct that marks the start and end of elements in HTML and other markup languages.</dd>
|
||
|
|
|
||
|
|
<dt><a id="target_anchor" name="target_anchor">target anchor</a></dt>
|
||
|
|
|
||
|
|
<dd>The destination of a <a href="#link" class="term">link</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="tbssl" name="tbssl">transformation-based style sheet language</a></dt>
|
||
|
|
|
||
|
|
<dd>A style sheet language that is also a <a href="#transformation_language">transformation language</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="transformation_language" name="transformation_language">transformation language</a></dt>
|
||
|
|
|
||
|
|
<dd>A language that expresses how to convert a document from one form to another. Some style sheet languages consider formatting to be a transformation.</dd>
|
||
|
|
|
||
|
|
<dt><a id="tree_structure" name="tree_structure">tree structure</a></dt>
|
||
|
|
|
||
|
|
<dd>Elements in a tree structure always have only one parent element (except the <a href="#root_element" class="term">root element</a>, which has none), but can have zero or more child elements.</dd>
|
||
|
|
|
||
|
|
<dt><a id="turing-complete" name="turing-complete">Turing-complete</a></dt>
|
||
|
|
|
||
|
|
<dd>A Turing-complete system is one which has computational power equivalent to a universal Turing machine. The term <em>Turing-complete</em> is often used in a lax sense for programming languages that can implement any well-defined algorithm, as opposed languages that are not as powerful. Most style sheet languages are not Turing-complete, but some – including DSSSL and XSL – are.</dd>
|
||
|
|
|
||
|
|
<dt><a id="unit" name="unit">unit</a></dt>
|
||
|
|
|
||
|
|
<dd>A precisely specified quantity in terms of which values can be stated. Examples of units in style sheets are <a href="#point" class="term">points</a> and <a href="#pixel" class="term">pixels</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="URL" name="URL">URL</a></dt>
|
||
|
|
|
||
|
|
<dd>A <a href="#web" class="term">web</a> address.</dd>
|
||
|
|
|
||
|
|
<dt><a id="URI" name="URI">URI</a></dt>
|
||
|
|
|
||
|
|
<dd>See <a href="#URL" class="term">URL</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="user" name="user">user</a></dt>
|
||
|
|
|
||
|
|
<dd>A human being who uses a web browser.</dd>
|
||
|
|
|
||
|
|
<dt><a id="user_agent" name="user_agent">user agent</a></dt>
|
||
|
|
|
||
|
|
<dd>A <a href="#web_browser" class="term">web browser</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="user_style_sheet" name="user_style_sheet">user style sheet</a></dt>
|
||
|
|
|
||
|
|
<dd>A style sheet supplied by the user. The user style sheet encodes user preferences.</dd>
|
||
|
|
|
||
|
|
<dt><a id="value" name="value">value</a></dt>
|
||
|
|
|
||
|
|
<dd>Each legal <a href="#element" class="term">element</a>/<a href="#property" class="term">property</a> combination has a value. The value can be a string, a keyword, a number, or a number with a unit identifier. Also, values can be lists or expressions involving several of the aforementioned determinants.</dd>
|
||
|
|
|
||
|
|
<dt><a id="value_propagation" name="value_propagation">value propagation</a></dt>
|
||
|
|
|
||
|
|
<dd>Automatic assignment of values which are not described in a style sheet. Example of value propagation mechanisms are <a href="#inheritance" class="term">inheritance</a>, <a href="#initial_value" class="term">initial values</a> and <a href="#cascading" class="term">cascading</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="viewport" name="viewport">viewport</a></dt>
|
||
|
|
|
||
|
|
<dd>A window, or other viewing area on the screen, which exposes part of the <a href="#layout_area" class="term">layout area</a>.
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="web" name="web">web</a></dt>
|
||
|
|
|
||
|
|
<dd>See <a href="#world_wide_web" class="term">World Wide Web</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="web_browser" name="web_browser">web browser</a></dt>
|
||
|
|
|
||
|
|
<dd>A computer program which fetches resources (for example text, graphics, and style sheets) from the web, decodes and assembles the resources, and presents the resulting content to a human user.
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="web_device" name="web_device">web device</a></dt>
|
||
|
|
|
||
|
|
<dd>An electronic device which has a <a href="#web_browser" class="term">web browser</a> and network access to the web.</dd>
|
||
|
|
|
||
|
|
<dt><a id="web_page" name="web_page">web page</a></dt>
|
||
|
|
|
||
|
|
<dd>A <a href="#document" class="term">document</a> which is available on the <a href="#web" class="term">web</a>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="winning_declaration" name="winning_declaration">winning declaration</a></dt>
|
||
|
|
|
||
|
|
<dd>If there are several conflicting declarations that apply to a given element/property combination, the <a href="#cascading" class="term">cascading</a> process will determine one <em>winning declaration</em> among the set of declarations that apply. For example, a declaration in an <a href="#author_style_sheet" class="term">author style sheet</a> will typically win over a declaration in a <a href="browser_style_sheet" class="term">browser style sheet</a>.</dd>
|
||
|
|
|
||
|
|
|
||
|
|
<dt><a id="word_processor" name="word_processor">word processor</a></dt>
|
||
|
|
|
||
|
|
<dd>A computer program used for authoring and editing documents.</dd>
|
||
|
|
|
||
|
|
<dt><a id="world_wide_web" name="world_wide_web">World Wide Web</a></dt>
|
||
|
|
|
||
|
|
<dd>A system of connected servers that uses HTTP to transfer documents and other information on request to browsers. The documents are typically written in HTML and include links to other documents.
|
||
|
|
</dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="references" id="ch-references">
|
||
|
|
<h1 class="uuchapter" id="h-358">References</h1>
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><a id="Adie_1993" name="Adie_1993">[Adie 1993]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Adie, C.</span>; <span class="title">Networking Multimedia Applications</span>; Message posted to www-talk Thu, 3 Jun 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0433.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0433.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0433.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Adler_2002" name="Adler_2002">[Adler 2002]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Adler, S.</span>; <span class="title">Re: xsl-fo first anniversary</span>; Message posted to www-xsl-fo@w3.org 21 Oct 2002; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-xsl-fo/2002Oct/0076.html">http://lists.w3.org/​Archives/​Public/​www-xsl-fo/​2002Oct/0076.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-xsl-fo/2002Oct/0076.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Adobe_1993" name="Adobe_1993">[Adobe 1993]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Portable Document Format</span>; Reference Manual, Adobe Systems, Addison-Wesley, 1993</dd>
|
||
|
|
|
||
|
|
<dt><a id="Adobe_2001" name="Adobe_2001">[Adobe 2001]</a></dt>
|
||
|
|
|
||
|
|
<dd>PDF Reference, Third Edition, Version 1.4, Addison-Wesley, 2001</dd>
|
||
|
|
|
||
|
|
<dt><a id="Amaya" name="Amaya">[Amaya]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Welcome to Amaya</span>; W3C web page, 2004; Available from <a class="url" href="http://www.w3.org/Amaya/">http://www.w3.org/Amaya/</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Amaya/index.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Andre_1989" name="Andre_1989">[André, et al. 1989]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">André, J., Furuta, R., and Quint, V. (editors)</span>; <span class="title">Structured Documents</span>; The Cambridge series on electronic publishing, Cambridge University Press, 1989</dd>
|
||
|
|
|
||
|
|
<dt><a id="Andreessen_1993a" name="Andreessen_1993a">[Andreessen 1993a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Andreessen, M.</span>; <span class="title">NCSA Mosaic for X 0.10 available</span>; Message posted to comp.infosystems.gopher, comp.infosystems.wais, comp.infosystems, alt.hypertext and comp.windows.x 15 Mar 1993; Available from <a class="url" href="http://groups.google.com/groups?selm=MARCA.93Mar14225600%40wintermute.ncsa.uiuc.edu&output=gplain">http://groups.google.com/​groups?selm=​MARCA.93Mar14225600%40​wintermute.ncsa.uiuc.edu&​output=gplain</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/groups.google.com/wintermute.txt">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Andreessen_1993b" name="Andreessen_1993b">[Andreessen 1993b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Andreessen, M.</span>; <span class="title">Stylesheet Language</span>; Message posted to www-talk 22 Oct 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q4/0266.html">http://www.webhistory.org/​www.lists/​www-talk.1993q4/0266.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q4/0266.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Andreessen_1994a" name="Andreessen_1994a">[Andreessen 1994a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Andreessen, M.</span>; <span class="title">Indented <MENU>s</span>; Message posted to www-talk 17 Feb 1994; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1994q1/0648.html">http://www.webhistory.org/​www.lists/​www-talk.1994q1/0648.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1994q1/0648.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Andreessen_1994b" name="Andreessen_1994b">[Andreessen 1994b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Andreessen, M.</span>; <span class="title">Mosaic Netscape is out the door...</span>; Message posted to www-talk 13 Oct 1994; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1994q4/0187.html">http://www.webhistory.org/​www.lists/​www-talk.1994q4/0187.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1994q4/0187.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Appelt_1991" name="Appelt_1991">[Appelt 1991]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Appelt, W.</span>; <span class="title">Document architecture in open systems: The ODA standard</span>; Springer-Verlag, 1991</dd>
|
||
|
|
|
||
|
|
<dt><a id="Badros_1999" name="Badros_1999">[Badros et al. 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Badros, G. J., Borning, A., Marriott, K. and Stuckey, P.</span>; <span class="title">Constraint Cascading Style Sheets for the Web</span>; 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</dd>
|
||
|
|
|
||
|
|
<dt><a id="Behlendorf_1994" name="Behlendorf_1994">[Behlendorf 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Behlendorf, B.</span>; <span class="title">Re: Cascading HTML style sheets – a proposal</span>; Message posted to www-talk 13 Oct 1994; Available from <a class="url" href="http://www.w3.org/Style/History/www.eit.com/www.lists/www-talk.1994q4/0186.html">http://www.w3.org/​Style/​History/​www.eit.com/​www.lists/​www-talk.1994q4/0186.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/History/www.eit.com/www.lists/www-talk.1994q4/0186.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1991a" name="Berners-Lee_1991a">[Berners-Lee 1991a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">HTML Tags</span>; Available from <a class="url" href="http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html">http://www.w3.org/​History/​19921103-hypertext/​hypertext/​WWW/​MarkUp/Tags.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1991b" name="Berners-Lee_1991b">[Berners-Lee 1991b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">Re: status. Re: X11 BROWSER for WWW</span>; Message posted to www-talk 29 Oct 1991; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-talk/1991SepOct/0003.html">http://lists.w3.org/​Archives/​Public/​www-talk/​1991SepOct/0003.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-talk/1991SepOct/0003.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1992a" name="Berners-Lee_1992a">[Berners-Lee 1992a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">MIME, SGML, UDIs, HTML and W3</span>; Message posted to www-talk 11 Jun 1992; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-talk/1992MayJun/0038.html">http://lists.w3.org/​Archives/​Public/​www-talk/​1992MayJun/0038.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-talk/1992MayJun/0038.html">local copy</a>)</span>.
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1992b" name="Berners-Lee_1992b">[Berners-Lee 1992b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">Re: HTML DTD</span>; Message posted to www-talk 26 Jun 1992; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-talk/1992MayJun/0063.html">http://lists.w3.org/​Archives/​Public/​www-talk/​1992MayJun/0063.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-talk/1992MayJun/0063.html">local copy</a>)</span>.
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1992c" name="Berners-Lee_1992c">[Berners-Lee 1992c]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">Re: HTML DTD and related problems (rather long)</span>; Message posted to www-talk 15 Jul 1992; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-talk/1992JulAug/0017.html">http://lists.w3.org/​Archives/​Public/​www-talk/​1992JulAug/0017.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-talk/1992JulAug/0017.html">local copy</a>)</span>.
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1992d" name="Berners-Lee_1992d">[Berners-Lee 1992d]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">Design Constraints</span>; Document last changed 13 Nov 1992; Available from <a class="url" href="http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/HTMLConstraints.html">http://www.w3.org/​History/​19921103-hypertext/​hypertext/​WWW/​MarkUp/HTMLConstraints.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/HTMLConstraints.html">local copy</a>)</span>.
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1993a" name="Berners-Lee_1993a">[Berners-Lee 1993a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">HTML, HMML, and HyperTeX</span>; Message posted to www-talk 21 Apr 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0129.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0129.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0129.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1993b" name="Berners-Lee_1993b">[Berners-Lee 1993b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">Re: RE dtd2.html</span>; Message posted to www-talk 27 May 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0396.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0396.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0396.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1993c" name="Berners-Lee_1993c">[Berners-Lee 1993c]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">Re: browsing vs validation, or, why not to make software robust</span>; Message posted to www-talk 20 Aug 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q3/0745.html">http://www.webhistory.org/​www.lists/​www-talk.1993q3/0745.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q3/0745.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1994" name="Berners-Lee_1994">[Berners-Lee 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">HTML *** Important ** LIST CHANGE</span>; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1994q2/0581.html">http://www.webhistory.org/​www.lists/​www-talk.1994q2/0581.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1994q2/0581.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1996" name="Berners-Lee_1996">[Berners-Lee 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">The Web Maestro: An Interview with Tim Berners-Lee</span>; inteview written by Brody, H.; published in Technology Review 99, no. 5: 32-40, July 1996</dd>
|
||
|
|
|
||
|
|
<dt><a id="Berners-Lee_1999" name="Berners-Lee_1999">[Berners-Lee 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T.</span>; <span class="title">Weaving the Web</span>; Harper, San Francisco, 1999</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bingham_2000" name="Bingham_2000">[Bingham 2000]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bingham, H.</span>; <span class="title">CALS Table Model History</span>; Original public version 1.3 2000-06-30; Available from <a class="url" href="http://users.rcn.com/hwbingham/tables/calstbhs.htm">http://users.rcn.com/​hwbingham/​tables/calstbhs.htm</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/users.rcn.com/hwbingham/tables/calstbhs.htm">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Borenstein_1994" name="Borenstein_1994">[Borenstein 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Borenstein, N.</span>; <span class="title">The text/enriched MIME Content-type</span>; <a href="http://rfc.net/rfc1563.html">RFC1563</a>, January 1994</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bos_1994" name="Bos_1994">[Bos 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bos, B.</span>; <span class="title">Re: Cascading HTML style sheets – a proposal</span>; Message posted to www-talk 11 Oct 1994; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1994q4/0158.html">http://www.webhistory.org/​www.lists/​www-talk.1994q4/0158.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1994q4/0158.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bos_1995" name="Bos_1995">[Bos 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bos, B.</span>; <span class="title">Stream-based Style sheet Proposal</span>; Web page last updated 31 March 1995; Available from <a class="url" href="http://odur.let.rug.nl/~bert/stylesheets.html">http://odur.let.rug.nl/​~bert/stylesheets.html</a>;<!--errata: added ;--> Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/odur.let.rug.nl/~bert/stylesheets.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bos_1998" name="Bos_1998">[Bos 1998]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bos, B.</span>; <span class="title">OPINIONS WANTED: regexps in CSS? (Re: Suggestion for Attribute Selectors)</span>; Message posted to www-style 10 Mar 1998; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-style/1998Mar/0051.html">http://lists.w3.org/​Archives/​Public/​www-style/​1998Mar/0051.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-style/1998Mar/0051.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bosak_1995" name="Bosak_1995">[Bosak 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bosak, J.</span>; <span class="title">Toward a specification of DSSSL Core</span>; Message posted 9 Oct 1995 to dsssl-lite; Available from <a class="url" href="http://xml.coverpages.org/dssslCore1.txt">http://xml.coverpages.org/​dssslCore1.txt</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/xml.coverpages.org/dssslCore1.txt">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bosak_1996a" name="Bosak_1996a">[Bosak 1996a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bosak, J.</span>; <span class="title">SGML: DSSSL style sheet for HTML 3.2 print output</span>; Message posted 21 Jul 1996; Available from <a class="url" href="http://xml.coverpages.org/dsssl-o-html32.html">http://xml.coverpages.org/​dsssl-o-html32.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/xml.coverpages.org/dsssl-o-html32.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bosak_1996b" name="Bosak_1996b">[Bosak 1996b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bosak, J.</span>; <span class="title">Greetings from the chair</span>; Message posted to w3c-sgml-wg@w3.org 28 Aug 1996; Available from <a class="url" href="http://lists.w3.org/Archives/Public/w3c-sgml-wg/msg00004.html">http://lists.w3.org/​Archives/​Public/​w3c-sgml-wg/msg00004.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/w3c-sgml-wg/msg00004.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bosak_1997" name="Bosak_1997">[Bosak 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bosak, J.</span>; <span class="title">RE: Positioning HTML Elements with Cascading Style Sheets</span>; Message posted to www-style@w3.org Feb 03 1997; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-style/1997Feb/0033.html">http://lists.w3.org/​Archives/​Public/​www-style/​1997Feb/0033.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-style/1997Feb/0033.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bruggemann-Klein_1992" name="Bruggemann-Klein_1992">[Brüggemann-Klein&Wood 1992]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Brüggemann-Klein, A., Wood, D.</span>; <span class="title">Electronic Style Sheets</span>; Interner Bericht 45, Institut für Informatik, Universitat Freiburg, 1992</dd>
|
||
|
|
|
||
|
|
<dt><a id="Bray_2002" name="Bray_2002">[Bray 2002]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bray, T.</span>; <span class="title">XML-SW, a thought experiment</span>; Message posted to www-tag@w3.org 6 Feb 2002; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-tag/2002Feb/0031.html">http://lists.w3.org/​Archives/​Public/​www-tag/​2002Feb/0031.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-tag/2002Feb/0031.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Burnard_1993" name="Burnard_1993">[Burnard 1993]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Burnard, L.</span>; <span class="title">FOSI/sgml stylesheets</span>; Message posted to www-talk 27 Oct 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q4/0301.html">http://www.webhistory.org/​www.lists/​www-talk.1993q4/0301.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q4/0301.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Cailliau_1997" name="Cailliau_1997">[Cailliau 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Cailliau, R.</span>; Foreword of <span class="title">Cascading Style Sheets</span> by <span class="author">Lie, H. W., and Bos, B.</span>; Addison-Wesley, 1997,</dd>
|
||
|
|
|
||
|
|
<dt><a id="Chicago_1993" name="Chicago_1993">[Chicago 1993]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">The Chicago Manual of Style</span>; The University of Chicago Press, Fourteenth Edition, 1993</dd>
|
||
|
|
|
||
|
|
<dt><a id="Chavchanidze_2003" name="Chavchanidze_2003">[Chavchanidze 2004]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Chavchanidze, G.</span>; <span class="title">Formatting Mathematical Articles with Cascading Style Sheets</span>; Revised edition published 10 Oct 2004; Available from <a class="url" href="http://geocities.com/csssite/math.xml">http://geocities.com/​csssite/math.xml</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/geocities.com/csssite/math.xml">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Clark_1994" name="Clark_1994">[Clark 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Clark, J.</span>; <span class="title">DSSSL Lite</span>; Draft specification dated November 24, 1994; Originally available from http://www.falch.no/​~pepper/DSSSL-Lite/<span class="local-copy"> (<a href="archive/dsssl-lite.pdf">local copy of scanned printout</a>)</span></dd>
|
||
|
|
|
||
|
|
<dt><a id="Clark_1998" name="Clark_1998">[Clark 1998]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Clark, J.</span>; <span class="title">Jade - James' DSSSL Engine</span>; Web page last modified 13 Oct 1998; Available from <a class="url" href="http://www.jclark.com/jade/">http://www.jclark.com/jade/</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.jclark.com/jade/index.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="CLink_2000a" name="CLink_2000a">[CLink 2000a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Lie, H. W.</span>; <span class="title">CLink</span>; Available from <a class="url" href="http://people.opera.com/howcome/2000/clink/2000-05-05.html">http://people.opera.com/​howcome/​2000/​clink/2000-05-05.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/people.opera.com/howcome/2000/clink/2000-05-05.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="CLink_2000b" name="CLink_2000b">[CLink 2000b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Lie, H. W.</span>; <span class="title">CLink</span>; Available from <a class="url" href="http://people.opera.com/howcome/2000/css3/clink-nov-6.html">http://people.opera.com/​howcome/​2000/​css3/clink-nov-6.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/people.opera.com/howcome/2000/css3/clink-nov-6.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Connolly_1992" name="Connolly_1992">[Connolly 1992]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Dan Connolly</span>; <span class="title">MIME as a hypertext architecture</span>; Message posted to www-talk 6 Jun 92; Available from: <a class="url" href="http://lists.w3.org/Archives/Public/www-talk/1992MayJun/0020.html">http://lists.w3.org/​Archives/​Public/​www-talk/​1992MayJun/0020.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-talk/1992MayJun/0020.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Connolly_1994a" name="Connolly_1994a">[Connolly 1994a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Connolly, D.</span>; <span class="title">Some Background on SGML for the World-Wide Web</span>; Essay available from <a href="http://www.w3.org/MarkUp/html-spec/html-essay.html">http://www.w3.org/​MarkUp/​html-spec/html-essay.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/MarkUp/html-spec/html-essay.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Connolly_1994b" name="Connolly_1994b">[Connolly 1994b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Connolly, D.</span>; <span class="title">Toward Closure on HTML</span>; Message posted to www-talk 4 Apr 1994; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1994q2/0020.html">http://www.webhistory.org/​www.lists/​www-talk.1994q2/0020.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1994q2/0020.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Connolly_1996" name="Connolly_1996">[Connolly 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Connolly, D.</span>; <span class="title">Generic SGML Activity Launched</span>; W3C Newsletter, Volume 2, No. 7, 5 Jun 1996</dd>
|
||
|
|
|
||
|
|
<dt><a id="Connolly_1997" name="Connolly_1997">[Connolly 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Connolly, D.</span>; <span class="title">XML Enables Custom Markup Schemes</span>; W3C Newsletter, Volume 3, No. 6, 21 Mar 1997</dd>
|
||
|
|
|
||
|
|
<dt><a id="Connolly_2000" name="Connolly_2000">[Connolly 2000]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Connolly, D.</span>; <span class="title">Re: XHTML Invalidity / WML2 / New XHTML 1.1 Attribute</span>; Message posted to www-html@w3.org 12 Aug 2000; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-html/2000Aug/0052.html">http://lists.w3.org/​Archives/​Public/​www-html/2000Aug/0052.html</a>;<!--errata: added ;--> Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-html/2000Aug/0052.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="CSS_draft1_1995" name="CSS_draft1_1995">[CSS draft1 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Cascading Style Sheets: a draft specification</span>; Draft specification published 31 May 1995; Available from <a class="url" href="http://www.w3.org/Style/CSS/draft1.html">http://www.w3.org/​Style/​CSS/draft1.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/CSS/draft1.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="CSS_draft2_1995" name="CSS_draft2_1995">[CSS draft2 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Cascading Style Sheets: a draft specification</span>; Draft specification published 3 Jul 1995; Available from <a class="url" href="http://www.w3.org/Style/CSS/draft2.html">http://www.w3.org/​Style/​CSS/draft2.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/CSS/draft2.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="CSS_draft3_1995" name="CSS_draft3_1995">[CSS draft3 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Cascading Style Sheets: a draft specification</span>; Draft specification published 10 Aug 1995; Available from <a class="url" href="http://www.w3.org/Style/CSS/draft3.html">http://www.w3.org/​Style/​CSS/draft3.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/CSS/draft3.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="CSS_draft4_1995" name="CSS_draft4_1995">[CSS draft4 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Cascading Style Sheets: a draft specification</span>; Draft specification published 6 Oct 1995; Available from <a class="url" href="http://www.w3.org/Style/CSS/draft4.html">http://www.w3.org/​Style/​CSS/draft4.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/CSS/draft4.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="CSS_draft5_1995" name="CSS_draft5_1995">[CSS draft5 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Cascading Style Sheets: fifth draft specification</span>; Draft specification published 1 Nov 1995; Available from <a class="url" href="http://www.w3.org/Style/CSS/draft5.html">http://www.w3.org/​Style/​CSS/draft5.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/CSS/draft5.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="CSS_draft6_1995" name="CSS_draft6_1995">[CSS draft6 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Cascading Style Sheets, level 1</span>; W3C Working Draft published 17 Nov 1995; Available from <a class="url" href="http://www.w3.org/Style/CSS/draft6.html">http://www.w3.org/​Style/​CSS/draft6.html</a>;<!--errata: added ;--> Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/CSS/draft6.html">local copy</a>)</span>.
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="CSS1_1996" name="CSS1_1996">[CSS1 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Cascading Style Sheets, level 1</span>; <span class="author">Lie, H. W. and Bos, B.</span>; W3C Recommendation 17 Dec 1996; Available from <a class="url" href="http://www.w3.org/TR/REC-CSS1-961217">http://www.w3.org/​TR/​REC-CSS1-961217</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="CSS2_1998" name="CSS2_1998">[CSS2 1998]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Cascading Style Sheets, level 2</span>; <span class="author">Bos, B., Lie, H. W., Lilley, C. and Jacobs, I. (editors)</span>; W3C Recommendation 12 May 1998; Available from <a class="url" href="http://www.w3.org/TR/1998/REC-CSS2-19980512">http://www.w3.org/​TR/​1998/REC-CSS2-19980512</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="Davis_1994" name="Davis_1994">[Davis 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Jim Davis</span>; <span class="subject">Re: Toward Closure on HTML</span>; Message posted to www-talk 5 Apr 1994; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1994q2/0050.html">http://www.webhistory.org/​www.lists/​www-talk.1994q2/0050.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1994q2/0050.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="DOM1_1998" name="DOM1_1998">[DOM1 1998]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Document Object Model (DOM) Level 1 Specification</span>; <span class="author">Apparao, V., Byrne, S., Champion, M., Isaacs, S., Jacobs, I., Le Hors, A., Nicol, G., Robie, J., Sutor, R., Wilson, C. and Wood, L.</span>; W3C Recommendation 1 Oct 1998; Available from <a class="url" href="http://www.w3.org/TR/REC-DOM-Level-1/">http://www.w3.org/​TR/REC-DOM-Level-1/</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="Dougherty_1993" name="Dougherty_1993">[Dougherty 1993]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Re: Re HMML?</span>; <span class="author">Dougherty, D.</span>; Message posted to www-talk 25 May 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0388.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0388.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1992q2/0388.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="DSSSL_1996" name="DSSSL_1996">[DSSSL 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Document Style Semantics and Specification Language (DSSSL)</span>; ISO/IEC 10179:1996; The DSSSL specification is available in compressed form from <a class="url" href="http://metalab.unc.edu/pub/sun-info/standards/dsssl/draft/">http://metalab.unc.edu/​pub/​sun-info/​standards/​dsssl/draft/</a>, and in HTML from <a class="url" href="http://www.cs.berkeley.edu/~wilensky/CS294/dsssl/html/">http://www.cs.berkeley.edu/​~wilensky/​CS294/dsssl/html/</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="dssslist" name="dssslist">[dssslist]</a></dt>
|
||
|
|
|
||
|
|
<dd>The dssslist mailing list was startd in March 1997 as a forum for DSSSL users. The archives for the dssslist mailing list is available from <a class="url" href="http://lists.mulberrytech.com/dssslist/archives/">http://lists.mulberrytech.com/​dssslist/archives/</a>; Accessed 25 Oct 2004.</dd>
|
||
|
|
|
||
|
|
<dt><a id="DuCharme_2001" name="DuCharme_2001">[DuCharme 2001]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">DuCharme, B.</span>; <span class="title">Getting Loopy</span>; xml.com, 1 Aug 2001; Available from <a class="url" href="http://www.xml.com/pub/a/2001/08/01/gettingloopy.html?page=2">http://www.xml.com/pub/​a/​2001/​08/01/gettingloopy.html?page=2</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.xml.com/pub/a/2001/08/01/gettingloopy.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="EBT_1997" name="EBT_1997">[EBT 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">EBT ANNOUNCES PLANS TO SUPPORT IMPORTANT NEW PUBLISHING STANDARD: DSSSL</span>; Press release from Electronic Book Technologies Inc, Providence, RI, USA; Available from <a class="url" href="http://xml.coverpages.org/ebtDSSSL.html">http://xml.coverpages.org/​ebtDSSSL.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/xml.coverpages.org/ebtDSSSL.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="EP" name="EP">[Electronic Publishing]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Electronic Publishing—Origination, Dissemination and Design</span>; John Wiley & Sons, ISSN 0894-3982; A cumulative contents page is available from <a class="url" href="http://cajun.cs.nott.ac.uk/compsci/epo/papers/epoddtoc.html">http://cajun.cs.nott.ac.uk/​compsci/​epo/​papers/epoddtoc.html</a>; Accessed 25 Oct 2004</dd>
|
||
|
|
|
||
|
|
<dt><a id="English_1994a" name="English_1994a">[English 1994a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">English, J.</span>; <span class="title">Style Sheets for HTML</span>; 18 Nov 1994; An electronic version is available from <a class="url" href="http://www.w3.org/Style/History/jenglish.ps">http://www.w3.org/​Style/​History/jenglish.ps</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/History/jenglish.ps">local copy</a>, <a href="archive/www.w3.org/Style/History/jenglish.pdf">local copy in PDF format</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="English_1994b" name="English_1994b">[English 1994b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">English, J.</span>; <span class="title">Style Sheets</span>; Message posted to www-html 18 Nov 1994; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-html/1994Nov/0064.html">http://lists.w3.org/​Archives/​Public/​www-html/​1994Nov/0064.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-html/1994Nov/0064.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="English_2002" name="English_2002">[English 2002]</a></dt>
|
||
|
|
|
||
|
|
<dd>Personal email correnspondance with Joe English, 2002</dd>
|
||
|
|
|
||
|
|
<dt><a id="FOSI_1997" name="FOSI_1997">[FOSI 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">MARKUP REQUIREMENTS AND GENERIC STYLE SPECIFICATION FOR EXCHANGE OF TEXT AND ITS PRESENTATION</span>; MIL-PRF-28001C, 2 May 1997; Available from <a class="url" href="http://www.dt.navy.mil/tot-shi-sys/tec-inf-sys/cal-std/doc/28001C.pdf">http://www.dt.navy.mil/​tot-shi-sys/​tec-inf-sys/​cal-std/​doc/28001C.pdf</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.dt.navy.mil/tot-shi-sys/tec-inf-sys/cal-std/doc/28001C.pdf">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="FrameMaker" name="FrameMaker">[FrameMaker]</a></dt>
|
||
|
|
|
||
|
|
<dd>A brief history of the FrameMaker desktop publishing application is available from <a class="url" href="http://en.wikipedia.org/wiki/FrameMaker/">http://en.wikipedia.org/​wiki/FrameMaker/</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/en.wikipedia.org/wiki/FrameMaker.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Furuta_1982" name="Furuta_1982">[Furuta, et al. 1982]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Furuta, R., Scofield, J. and Shaw, A</span>; <span class="title">Document Formatting Systems: Survey, Concepts, and Issues</span>; Computing Surveys, 14, 3, 417472. (September 1982) ISSN:0360-0300</dd>
|
||
|
|
|
||
|
|
<dt><a id="Furuta_1992" name="Furuta_1992">[Furuta 1992]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Furuta, R</span>; <span class="title">Important papers in the history of document preparation systems: basic sources</span>; Electronic Publishing—Origination, Dissemination, and Design; 5 (1), 19-44, 1992; Available from <a class="url" href="http://cajun.cs.nott.ac.uk/compsci/epo/papers/volume5/issue1/ep057rf.pdf">http://cajun.cs.nott.ac.uk/​compsci/​epo/​papers/​volume5/​issue1/ep057rf.pdf</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/cajun.cs.nott.ac.uk/compsci/epo/papers/volume5/issue1/ep057rf.pdf">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Germán_1997" name="Germán_1997">[Germán 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Germán, D. M.</span>; <span class="title">An Introduction to DSSSL</span>; 1997; Available from <a class="url" href="http://csgrs6k1.uwaterloo.ca/~dmg/dsssl/tutorial/tutorial.html">http://csgrs6k1.uwaterloo.ca/​~dmg/​dsssl/​tutorial/tutorial.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/csgrs6k1.uwaterloo.ca/~dmg/dsssl/tutorial/tutorial.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="GIF_1990" name="GIF_1990">[GIF 1990]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">GRAPHICS INTERCHANGE FORMAT(sm)</span>; Version 89a, CompuServe Incorporated, Columbus, Ohio, 1990; Available from <a class="url" href="http://www.w3.org/Graphics/GIF/spec-gif89a.txt">http://www.w3.org/​Graphics/​GIF/spec-gif89a.txt</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Graphics/GIF/spec-gif89a.txt">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Glazman_1997" name="Glazman_1997">[Glazman 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Glazman, D.</span>; <span class="title">Simple Tree Transformation Sheets 2</span>; W3C Note 17 Oct 1997; Available from <a class="url" href="http://www.w3.org/TR/NOTE-stts2-971017">http://www.w3.org/​TR/​NOTE-stts2-971017</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/TR/NOTE-stts2-971017.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Glazman_2002" name="Glazman_2002">[Glazman 2002]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Glazman, D.</span>; <span class="title">Small Screen Rendering</span>; Blog entry 21 Oct 21 2002; Available from <a class="url" href="http://webperso.easyconnect.fr/danielglazman/weblog/newarchive/2002_10_20_glazblogarc.html#s83291371">http://webperso.easyconnect.fr/​danielglazman/​weblog/​newarchive/​2002_10_20_glazblogarc.html#s83291371</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.glazman.org/weblog/newarchive/2002_10_20_glazblogarc.html#s83291371">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Goldfarb_1990" name="Goldfarb_1990">[Goldfarb 1991]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Goldfarb, C. F.</span>; <span class="title">The SGML Handbook</span>; Oxford University Press, 1991</dd>
|
||
|
|
|
||
|
|
<dt><a id="Goldfarb_1997" name="Goldfarb_1997">[Goldfarb et al.1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Goldfarb, C. F., Pepper, S. and Ensign, C.</span>; <span class="title">SGML Buyer's Guide</span>; Prentice Hall, 1997</dd>
|
||
|
|
|
||
|
|
<dt><a id="Graham_1992" name="Graham_1992">[Graham, et al. 1992]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Graham, S. L., Harrison, M. A. and Munson, E. V.</span>; <span class="title">The Proteus Presentation System</span>; University of California, Berkeley, California; The paper appeared in the Proceedings of the Fifth ACM SIGSOFT Symposium on Software Development Environments, Tyson's Corner, VA, December 911 1992;</dd>
|
||
|
|
|
||
|
|
<dt><a id="Gramlich_1996" name="Gramlich_1996">[Gramlich 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd>Email from <span class="author">Wayne Gramlich</span> to HTML ERB on April 12, 1996</dd>
|
||
|
|
|
||
|
|
<dt><a id="Grif_1993" name="Grif_1993">[Grif 1993]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Grif Languages</span>; Grif S.A., St Quentin en Yvelines, France, 1993</dd>
|
||
|
|
|
||
|
|
<dt><a id="Grosso_1993" name="Grosso_1993">[Grosso 1993]</a></dt>
|
||
|
|
|
||
|
|
<dd>Personal email correspondance with Paul Grosso, 1993</dd>
|
||
|
|
|
||
|
|
<dt><a id="Harvey_2000" name="Harvey_2000">[Harvey 2000]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Betty Harvey</span>; <span class="title">Re: AW: ebXML - core components glossary of terms and acronyms</span>; Message posted to ebxml-core on 23 Jun 2000; Available from <a class="url" href="http://lists.ebxml.org/archives/ebxml-core/200006/msg00038.html">http://lists.ebxml.org/archives/​ebxml-core/​200006/msg00038.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.ebxml.org/archives/ebxml-core/200006/msg00038.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Harvey_2002" name="Harvey_2002">[Harvey 2002]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">What SGML Can Teach Us About XML & the Web</span>; Betty Harvey interviewed by Tony Byrne, CMSWatch, 15 Jan 2002; Available from <a class="url" href="http://www.cmswatch.com/Features/PeopleWatch/FeaturedPeople/?feature_id=58">http://www.cmswatch.com/<br />
|
||
|
|
Features/PeopleWatch/FeaturedPeople/?feature_id=58</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.cmswatch.com/Features/PeopleWatch/FeaturedPeople/index.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Hayakawa_1940" name="Hayakawa_1940">[Hayakawa 1940]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Hayakawa, S. I.</span>; <span class="title">Language in Action</span>; Harcourt, Brace and Company; 1940; Later editions are named <em class="title">Language in thought and action</em>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Heaney_1993" name="Heaney_1993">[Heaney 1993]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Heaney, S.</span>; <span class="title">Re: Stylesheet Language</span>; Message posted to www-talk 26 Oct 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q4/0295.html">http://www.webhistory.org/​www.lists/​www-talk.1993q4/0295.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q4/0295.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="HTMLplus_1993" name="HTMLplus_1993">[HTML+ 1993]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">HTML+ (Hypertext markup format)</span>; 8 Nov 1993; Available from <a class="url" href="http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html">http://www.w3.org/​MarkUp/​HTMLPlus/htmlplus_1.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="HTML_3.2_1997" name="HTML_3.2_1997">[HTML 3.2 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">HTML 3.2 Reference Specification</span>; W3C Recommendation 14 Jan 1997; Available from <a class="url" href="http://www.w3.org/TR/REC-html32.html">http://www.w3.org/TR/REC-html32.html</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="HTML2_1995" name="HTML2_1995">[HTML2 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Berners-Lee, T. and Connolly, D.</span>; <span class="title">HTML 2.0</span>; <a href="http://rfc.net/rfc1563.html">RFC1866</a>, November 1995</dd>
|
||
|
|
|
||
|
|
<dt><a id="HTML4_1997" name="HTML4_1997">[HTML4 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">HTML 4.0 Specification</span>; <span class="author">Raggett, D., Le Hors, A. and Jacobs, I.</span>; W3C Recommendation 18 Dec 1997; Available from <a class="url" href="http://www.w3.org/TR/REC-html40-971218/">http://www.w3.org/​TR/REC-html40-971218/</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="HTTP_1999" name="HTTP_1999">[HTTP 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Hypertext Transfer Protocol – HTTP/1.1</span>; <span class="author">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and Berners-Lee, T.</span>; <a href="http://rfc.net/rfc2616.html">RFC2616</a>, June 1999</dd>
|
||
|
|
|
||
|
|
<dt><a id="Hutton_2002" name="Hutton_2002">[Hutton 2002]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Hutton, G. (editor)</span>; <span class="title">Frequently Asked Questions for comp.lang.functional</span>; Version of November 2002; Available from <a class="url" href="http://www.cs.nott.ac.uk/~gmh/faq.html">http://www.cs.nott.ac.uk/​~gmh/faq.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.cs.nott.ac.uk/~gmh/faq.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Interleaf" name="Interleaf">[Interleaf]</a></dt>
|
||
|
|
|
||
|
|
<dd>A brief history of the Interleaf desktop publishing application is available from <a class="url" href="http://en.wikipedia.org/wiki/Interleaf">http://en.wikipedia.org/​wiki/Interleaf/</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/en.wikipedia.org/wiki/Interleaf.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Kennedy_1997" name="Kennedy_1997">[Kennedy 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Kennedy, D.</span>; <span class="title">DSSSL; An Introduction</span>; (A related version of the article in was published in <TAG>, February 1997.) Available from <a class="url" href="http://xml.coverpages.org/kennDSSSLInt.html">http://xml.coverpages.org/​kennDSSSLInt.html</a>;<!--errata: replaced . with ;--> Accessed 26 Oct 2004<span class="local-copy"> (<a href="archive/xml.coverpages.org/kennDSSSLInt.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Kidwell_1997" name="Kidwell_1997">[Kidwell&Richman 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Kidwell, R. S. and Richman, J. G.</span>; <span class="title">Final DSSSL Survey and Assessment Report for the DOD CALS IDE PROJECT</span>; ManTech Advanced Technology Systems, March 1997; Available from <a class="url" href="http://www.dcnicn.com/lamp/cals_ide/task03/html/dssslsar/cals_a009/recon02.htm">http://www.dcnicn.com/​lamp/​cals_ide/​task03/​html/​dssslsar/cals_a009/recon02.htm</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.dcnicn.com/lamp/cals_ide/task03/html/dssslsar/cals_a009/recon02.htm">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Lamport_1986" name="Lamport_1986">[Lamport 1986]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Lamport, L.</span>; <span class="title">LaTeX: A document preparation system</span>; Addison-Wesley, Reading, Mass, 1986</dd>
|
||
|
|
|
||
|
|
<dt><a id="Lamport_2003" name="Lamport_2003">[Lamport 2003]</a></dt>
|
||
|
|
|
||
|
|
<dd>Personal email correspondance with Leslie Lamport, 2003</dd>
|
||
|
|
|
||
|
|
<dt><a id="Kernighan_1978" name="Kernighan_1978">[Kernighan&Richie 1978]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Kernighan, B. W., Ritchie, D. M.</span>; <span class="title">The C Programming Language</span>; Prentice-Hall, Englewood Cliffs, NJ, 1978</dd>
|
||
|
|
|
||
|
|
<dt><a id="Khare_1998" name="Khare_1998">[Khare&Rifkin 1998]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Khare, R., Rifkin, A.</span>; <span class="title">The origin of (document) species</span>; Proceedings of the seventh international conference on World Wide Web, Brisbane, Australia, 1998
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="Knuth_1981" name="Knuth_1981">[Knuth&Plass 1981]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Knuth, D. E., Plass, M. F.</span>; <span class="title">Breaking Paragraphs into Lines</span>; Software Practice and Experience, 11:1119–1184, 1981</dd>
|
||
|
|
|
||
|
|
<dt><a id="Knuth_1984" name="Knuth_1984">[Knuth 1984]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Knuth, D. E.</span>; <span class="title">The TeXbook</span>; Addison-Wesley, 1984</dd>
|
||
|
|
|
||
|
|
<dt><a id="Lie_1994" name="Lie_1994">[Lie 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Lie, H. W.</span>; <span class="title">Cascading HTML Style Sheets</span>; Proposal published 10 Oct 1994; Available from: <a class="url" href="http://www.w3.org/People/howcome/p/cascade.html">http://www.w3.org/​People/​howcome/​p/cascade.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/People/howcome/p/cascade.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Lie_1996" name="Lie_1996">[Lie 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Lie, H. W.</span>; <span class="title">CSS1 status</span>; Message posted to www-style@w3.org 25 Jan 1996; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-style/1996Jan/0039.html">http://lists.w3.org/​Archives/​Public/​www-style/1996Jan/0039.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-style/1996Jan/0039.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Lie_1999" name="Lie_1999">[Lie&Saarela 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Lie, H. W. and Saarela, J.</span>; <span class="title">Multipurpose Web Publishing using HTML, XML and CSS</span>; Communications of the ACM, October 1999</dd>
|
||
|
|
|
||
|
|
<dt><a id="Lorimer_1996" name="Lorimer_1996">[Lorimer 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Lorimer, P.</span>; <span class="title">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</span>; Ph.D. Thesis, University of Birmingham, December 1996
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="Magliery_1994" name="Magliery_1994">[Magliery 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Magliery, T.</span>; <span class="title">DSSSL-Lite Announcement</span>; Message posted to www-talk 1 Dec 1994, and to comp.text.sgml, comp.infosystems.www.users, comp.infosystems.www.misc, comp.infosystems.www.providers 2 Dec 1994; Available from <a class="url" href="http://xml.coverpages.org/dsssl-lite-ann.html">http://xml.coverpages.org/​dsssl-lite-ann.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/xml.coverpages.org/dsssl-lite-ann.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Marden_1997" name="Marden_1997">[Marden&Munson 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Marden, P. M. and Munson, E. V.</span>; <span class="title">Multiple presentations of WWW documents using style sheets</span>; Proceedings of the 1997 workshop on New paradigms in information visualization and manipulation, Las Vegas, Nevada, United States, pp. 75-78, 1997</dd>
|
||
|
|
|
||
|
|
<dt><a id="Marden_1998" name="Marden_1998">[Marden&Munson 1998]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Marden, P. M. and Munson, E. V.</span>; <span class="title">PSL: An alternate approach to style sheet languages for the world wide web</span>; Journal of Universal Computer Science, 4(10), 1998</dd>
|
||
|
|
|
||
|
|
<dt><a id="Marden_1999" name="Marden_1999">[Marden&Munson 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Marden, P. M. and Munson, E. V.</span>; <span class="title">Today's Style Sheet Standards: The Great Vision Blinded</span>; Computer, November 1999</dd>
|
||
|
|
|
||
|
|
<dt><a id="Mason_2001" name="Mason_2001">[Mason 2001]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Mason, J. D.</span>; <span class="author">History (was: Re: Montreal meeting recommendations)</span>; Message sent to sc34wg3@isotopicmaps.org 18 Sep 2001; Available from <a class="url" href="http://www.isotopicmaps.org/pipermail/sc34wg3/2001-September/000047.html">http://www.isotopicmaps.org/​pipermail/​sc34wg3/​2001-September/000047.html</a>; Accessed 26 Oct 2004<span class="local-copy"> (<a href="archive/www.isotopicmaps.org/pipermail/sc34wg3/2001-September/000047.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="MathML_1998" name="MathML_1998">[MathML 1998]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Mathematical Markup Language (MathML) 1.0 Specification</span>; <span class="author">Ion, P., Miner, R. (editors)</span>; W3C Recommendation 7 Apr 1998; Available from <a class="url" href="http://www.w3.org/TR/1998/REC-MathML-19980407/">http://www.w3.org/​TR/​1998/REC-MathML-19980407/</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="Michalowski_1999" name="Michalowski_1999">[Michalowski 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Michalowski, B.</span>; <span class="title">A Constraint-Based Specification for Box Layout in CSS2</span>; UW Tech Report UW-CSE-98-06-03, Department of Computer Science and Engineering, University of Washington, Seattle, June 1998</dd>
|
||
|
|
|
||
|
|
<dt><a id="Milowski_1997" name="Milowski_1997">[Milowski 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Alexander Milowski</span>; <span class="title">Re: Heresy? Re: DSSSL WWW Enhancements</span>; Message posted to dssslist 18 May 1997; Available from <a class="url" href="http://www.biglist.com/lists/dssslist/archives/199705/msg00038.html">http://www.biglist.com/​lists/​dssslist/​archives/​199705/msg00038.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.biglist.com/lists/dssslist/archives/199705/msg00038.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Mosaic" name="Mosaic">[Mosaic]</a></dt>
|
||
|
|
|
||
|
|
<dd>A brief history of the Mosaic browser is available from <a class="url" href="http://en.wikipedia.org/wiki/Mosaic_web_browser/">http://en.wikipedia.org/​wiki/​Mosaic_web_browser</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/en.wikipedia.org/wiki/Mosaic_web_browser.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="MS-Word" name="MS-Word">[MS-Word]</a></dt>
|
||
|
|
|
||
|
|
<dd>A brief history of the Microsoft Word text processor is available from <a class="url" href="http://en.wikipedia.org/wiki/Microsoft_Word/">http://en.wikipedia.org/​wiki/Microsoft_Word</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/en.wikipedia.org/wiki/Microsoft_Word.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Munson_1994" name="Munson_1994">[Munson 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Munson, E. V.</span>; <span class="title">Proteus: An Adaptable Presentation System for a Software Development and Multimedia Document Environment</span>; PhD dissertation, University of California, Berkeley, December 1994</dd>
|
||
|
|
|
||
|
|
<dt><a id="Munson_1996" name="Munson_1996">[Munson 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Munson, E. V.</span>; <span class="title">A new presentation language for structured documents</span>; Electronic Publishing, Vol. 8 (2&3), pp. 125138 (June & September 1995), Paper received 16 Apr 1996, revised 28 June 1996</dd>
|
||
|
|
|
||
|
|
<dt><a id="Munson_1999" name="Munson_1999">[Munson&Pfeiffer 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Munson, E. V., Pfeiffer, M.</span>; <span class="title">A Representation of Media for Multimedia Authoring and Browsing Systems</span>; Proceedings of the AAAI 98 Workshop on Representations for Multi-Modal Human-Computer Interaction, Madison, WI, USA, July 1998</dd>
|
||
|
|
|
||
|
|
<dt><a id="Munson_2003" name="Munson_2003">[Munson 2003]</a></dt>
|
||
|
|
|
||
|
|
<dd>Personal email correspondance with Ethan Muson, 2003</dd>
|
||
|
|
|
||
|
|
<dt><a id="Naggum_1994" name="Naggum_1994">[Naggum 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Naggum, E</span>; <span class="title">Erik Naggum's review of DSSSL (DIS)</span>; Message posted to comp.text.sgml 5 Dec 1994 under the title <span class="title">DSSSL</span>; Available from <a class="url" href="http://xml.coverpages.org/dsssl-note-erik.html">http://xml.coverpages.org/​dsssl-note-erik.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/xml.coverpages.org/dsssl-note-erik.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Nicol_1995" name="Nicol_1995">[Nicol 1995]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Gavin Nicol</span>; <span class="title">Re: A New Era of Afforable Tools</span>; Message posted to comp.text.sgml 10 Jun 1995; Available from <a class="url" href="http://groups.google.com/groups?selm=GTN.95Jun10022744%40ebt-inc&output=gplain">http://groups.google.com/​groups?​selm=GTN.95Jun10022744%40ebt-inc&output=gplain</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/groups.google.com/ebt-inc.txt">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Nielsen_1994" name="Nielsen_1994">[Nielsen&Lie 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Nielsen, H. F. and Lie, H. W.</span>; <span class="title">Towards a Uniform Library of Common Code</span>; Proceedings of Second International WWW Conference '94, Chicago, 1994;
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="Nielsen_1996" name="Nielsen_1996">[Nielsen 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Jakob Nielsen</span>; <span class="title">Why Frames Suck (Most of the Time)</span>; December, 1996; Available from <a class="url" href="http://www.useit.com/alertbox/9612.html">http://www.useit.com/​alertbox/9612.html</a>; Accessed 25 Oct 2004</dd>
|
||
|
|
|
||
|
|
<dt><a id="NOTE-XSL_1997" name="NOTE-XSL_1997">[NOTE-XSL 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">A Proposal for XSL</span>; <span class="author">Adler, S., Berglund, A., Clark, J., Cseri, I., Grosso, P., Marsh, J., Nicol, G., Paoli, J., Schach, D., Thompson, H. S. and Wilson, C.</span>; Available from <a class="url" href="http://www.w3.org/TR/NOTE-XSL-970910">http://www.w3.org/​TR/NOTE-XSL-970910</a>; Accessed 26 Oct 2004<span class="local-copy"> (<a href="www.w3.org/TR/NOTE-XSL-970910.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="ODA" name="ODA">[ODA]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Office Document Architecture (ODA) and Interchange Format</span>; A family of specifications published as drafts from around 1988, and issued as ISO/IEC standards 1994-1998.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Opera" name="Opera">[Opera]</a></dt>
|
||
|
|
|
||
|
|
<dd>A brief description of the Opera browser is available from <a class="url" href="http://en.wikipedia.org/wiki/Opera_browser">http://en.wikipedia.org/​wiki/Opera_browser</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/en.wikipedia.org/wiki/Opera_browser.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="OpenOffice" name="OpenOffice">[OpenOffice]</a></dt>
|
||
|
|
|
||
|
|
<dd>A brief description of the OpenOffice.org office applications suite is available from <a class="url" href="http://en.wikipedia.org/wiki/Openoffice">http://en.wikipedia.org/​wiki/Openoffice</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/en.wikipedia.org/wiki/Openoffice.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="OSI" name="OSI">[OSI]</a></dt>
|
||
|
|
|
||
|
|
<dd>A bried description of the Open Systems Interconnection Reference Model (<q>OSI Model</q> or <q>OSI Reference Model</q> for short) can be found from <a class="url" href="http://en.wikipedia.org/wiki/OSI_model">http://en.wikipedia.org/​wiki/OSI_model</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/en.wikipedia.org/wiki/OSI_model.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Pemberton_2000" name="Pemberton_2000">[Pemberton 2000]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">HTML WG Last Call Comments, part 1 of 2</span>; Message posted to www-xml-linking-comments 13 Mar 2000; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0073.html">http://lists.w3.org/​Archives/​Public/​www-xml-linking-comments/​2000JanMar/0073.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0073.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="PNG_1996" name="PNG_1996">[PNG 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">PNG (Portable Network Graphics) Specification Version 1.0</span>; W3C Recommendation 1 Oct 1996; Available from <a class="url" href="http://www.w3.org/TR/REC-png">http://www.w3.org/TR/REC-png</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="Prescod_1997a" name="Prescod_1997a">[Prescod 1997a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Prescod, P.</span>; <span class="title">Introduction to DSSSL</span>; July, 1997; Available from <a class="url" href="http://www.prescod.net/dsssl/">http://www.prescod.net/dsssl/</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.prescod.net/dsssl/index.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Prescod_1997b" name="Prescod_1997b">[Prescod 1997b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Prescod, P.</span>; <span class="title">Heresy? Re: DSSSL WWW Enhancements</span>; Message posted to dssslist 18 May 1997; Available from <a class="url" href="http://www.biglist.com/lists/dssslist/archives/199705/msg00035.html">http://www.biglist.com/​lists/​dssslist/​archives/​199705/msg00035.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.biglist.com/lists/dssslist/archives/199705/msg00035.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Quint_1994" name="Quint_1994">[Quint 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Quint, V.</span>; <span class="title">The Languages of Grif</span>; Translated by Ethan Munson, GIPSI S.A., GRIF S.A., Version of April 18, 1994</dd>
|
||
|
|
|
||
|
|
<dt><a id="Radestock_2004" name="Radestock_2004">[Radestock 2004]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Radestock, M.</span>; <span class="title">Scheme Frequently Asked Questions</span>; Version 1.8, 17 Oct 2004; Available from <a class="url" href="http://www.schemers.org/Documents/FAQ/#N40081C">http://www.schemers.org/​Documents/FAQ/#N40081C</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.schemers.org/Documents/FAQ/index.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1993a" name="Raggett_1993a">[Raggett 1993a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">Standardizing new HTML features</span>; Message posted to www-talk 27 Apr 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0166.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0166.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0166.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1993b" name="Raggett_1993b">[Raggett 1993b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">Re: Standardizing new HTML features</span>; Message posted to www-talk 28 Apr 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0186.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0186.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0186.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1993c" name="Raggett_1993c">[Raggett 1993c]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">Re: Mail addresses as URLs</span>; Message posted to www-talk 13 May 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0313.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0313.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0313.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1993d" name="Raggett_1993d">[Raggett 1993d]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">Re: HTML+ and printed books</span>; Message posted to www-talk 19 May 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0349.html">http://www.webhistory.org/www.lists/​www-talk.1993q2/0349.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0349.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1993e" name="Raggett_1993e">[Raggett 1993e]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">Re HMML?</span>; Message posted to www-talk 25 May 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0385.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0385.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0385.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1993f" name="Raggett_1993f">[Raggett 1993f]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">Re: RE dtd2.html</span>; Message posted to www-talk 27 May 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0393.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0393.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0393.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1993g" name="Raggett_1993g">[Raggett 1993g]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">Re: Style sheets for HTML</span>; Message posted to www-talk 11 Jun 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0448.html">http://www.webhistory.org/www.lists/​www-talk.1993q2/0448.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0448.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1995a" name="Raggett_1995a">[Raggett 1995a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">A Review of the HTML+ Document Format</span>; Web page last changed 1 Feb 1995; Available from <a class="url" href="http://www.w3.org/MarkUp/HTMLPlus/htmlplus_paper/htmlplus.html">http://www.w3.org/MarkUp/HTMLPlus/​htmlplus_paper/htmlplus.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/MarkUp/HTMLPlus/htmlplus_paper/htmlplus.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1995b" name="Raggett_1995b">[Raggett 1995b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="title">Document Type Definition for the HyperText Markup Language (HTML DTD)</span>; Published 24 Mar 1995; Available from <a class="url" href="http://www.w3.org/MarkUp/html3/html3.dtd">http://www.w3.org/​MarkUp/​html3/html3.dtd</a>;<!--errata: added ;--> Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/MarkUp/html3/html3.dtd.txt">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raggett_1995c" name="Raggett_1995c">[Raggett 1995c]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D.</span>; <span class="name">HTML Tables</span>; Internet draft, 7 Jul 1995; Available from <a class="url" href="http://www.w3.org/MarkUp/html3-tables/tables.txt">http://www.w3.org/​MarkUp/​html3-tables/tables.txt</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/MarkUp/html3-tables/tables.txt">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raisch_1993a" name="Raisch_1993a">[Raisch 1993a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raisch, R.</span>; <span class="title">Request for Comments: STYLESHEETS</span>; Message posted to www-talk 10 Jun 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q2/0445.html">http://www.webhistory.org/​www.lists/​www-talk.1993q2/0445.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q2/0445.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raisch_1993b" name="Raisch_1993b">[Raisch 1993b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raisch, R.</span>; <span class="title">Re: Stylesheet Language</span>; Message posted to www-talk 23 Oct 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q4/0269.html">http://www.webhistory.org/​www.lists/​www-talk.1993q4/0269.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q4/0269.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Raman_1996" name="Raman_1996">[Raman 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raman, T. V.</span>; <span class="title">Style Sheets For Producing Spoken Renderings</span>; Available from <a class="url" href="http://www.w3.org/Style/CSS/Speech/speech.html">http://www.w3.org/​Style/​CSS/​Speech/speech.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/CSS/Speech/speech.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Reid_1979" name="Reid_1979">[Reid&Walker 1979]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Reid, B. K. and Walker, J. H.</span>; <span class="title">Scribe Introductory User's Manual</span>; Second Edition, third printing, UniLogic Ltd, Pittsburgh, PA, July 1979;</dd>
|
||
|
|
|
||
|
|
<dt><a id="Reid_1980" name="Reid_1980">[Reid 1980]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Reid, B. K.</span>; <span class="title">Scribe: A Document Specification Language and its Compiler</span>; Phd dissertation, Department of Computer Science, Carnegie-Mellon University, Pittsburgh, PA, October, 1980</dd>
|
||
|
|
|
||
|
|
<dt><a id="Reid_1989" name="Reid_1989">[Reid 1989]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Reid, B. K.</span>; <span class="title">Electronic Mail of Structured Documents</span>; in André, J., Furuta, R., Quint, V. (editors) <span class="title">Structured Documents</span>, Cambridge University Press, 1989</dd>
|
||
|
|
|
||
|
|
<dt><a id="Rosenberg_1991" name="Rosenberg_1991">[Rosenberg et al. 1991]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Rosenberg, J., Sherman, M., Marks, A. and Akkerjuis, J.</span>; <span class="title">Multi-Media Document Translation: Oda and the Express Project</span> Springer-Verlag, 1991</dd>
|
||
|
|
|
||
|
|
<dt><a id="Sandahl_1999" name="Sandahl_1999">[Sandahl 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Sandahl, T. I.</span>; <span class="title">From Paper to Digital Documents: Challenging and Improving the SGML Approach</span>; Dr. Scient Thesis, University of Oslo, January 1999</dd>
|
||
|
|
|
||
|
|
<dt><a id="SGML_1986" name="SGML_1986">[SGML 1986]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Standard Generalized Markup Language (SGML)</span>; ISO 8879:1986</dd>
|
||
|
|
|
||
|
|
<dt><a id="SGMLUG_1990" name="SGMLUG_1990">[SGMLUG 1990]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">A Brief History of the Development of SGML</span>; SGML Users' Group, 11 Jun 1990; Available from <a class="url" href="http://www.sgmlsource.com/history/sgmlhist.htm">http://www.sgmlsource.com/​history/sgmlhist.htm</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.sgmlsource.com/history/sgmlhist.htm">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Sherman_1991" name="Sherman_1991">[Sherman 1991]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Guest Editorial</span>; <span class="author">Sherman, M.</span>; ComputerNetworks and ISDN Systems; 21 (1991) pp. 145-147, North Holland Available from <a class="url" href="http://reports-archive.adm.cs.cmu.edu/anon/itc/CMU-ITC-102.pdf">http://reports-archive.adm.cs.cmu.edu/​anon/​itc/CMU-ITC-102.pdf</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/reports-archive.adm.cs.cmu.edu/anon/itc/CMU-ITC-102.pdf">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Sorgaard_1996" name="Sorgaard_1996">[Sørgaard 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Sørgaard, P. and Sandahl, T. I.</span>; <span class="title">Problems with Styles in Word Processing: A Weak Foundation for Electronic Publishing with SGML</span>; Published in the Proceedings of the 30th HICSS, Wailea, Hawaii, January 7-10, 1997</dd>
|
||
|
|
|
||
|
|
<dt><a id="Sperberg-McQueen_1994a" name="Sperberg-McQueen_1994a">[Sperberg-McQueen 1994a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Sperberg-McQueen, C.M.</span>; <span class="name">Sketch of Simple Formatting Primitives</span>; Original version published 13 Sep 1994, updated 4 Jul 1995; Available from <a class="url" href="http://tigger.cc.uic.edu/~cmsmcq/style-primitives.html">http://tigger.cc.uic.edu/​~cmsmcq/style-primitives.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/tigger.cc.uic.edu/~cmsmcq/style-primitives.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Sperberg-McQueen_1994b" name="Sperberg-McQueen_1994b">[Sperberg-McQueen 1994b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Re: HTML style sheets</span>; <span class="author">Sperberg-McQueen, C.M.</span>; Message posted to www-html 4 Nov 94; Available from <a class="url" href="http://lists.w3.org/Archives/Public/www-html/1994Nov/0023.html">http://lists.w3.org/​Archives/​Public/​www-html/​1994Nov/0023.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/lists.w3.org/Archives/Public/www-html/1994Nov/0023.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Suck_1996" name="Suck_1996">[Suck 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Xanadu Redux, Part I: The World Wide Web Consortium could learn a few things from Xanadu</span>; Available from <a class="url" href="http://www.suck.com/daily/96/02/16/daily.html">http://www.suck.com/​daily/​96/02/16/daily.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.suck.com/daily/96/02/16/daily.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Thot_2001" name="Thot_2001">[Thot 2001]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">About Thot</span>; Last changed 16 Dec 2001; Available from <a class="url" href="http://www.inrialpes.fr/opera/Thot/AboutThot.html">http://www.inrialpes.fr/​opera/​Thot/AboutThot.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/opera.inrialpes.fr/Thot/AboutThot.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="USPS_1994" name="USPS_1994">[USPS 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd>U.S. Postal Service Purchasing Protest Decision <span class="title">P.S. Protest No. 94-15, Interleaf Inc.</span>; Written by William J. Jones, Senior Counsel, Contract Protests and Policies; 4 Aug 1994; Available from <a class="url" href="http://www.usps.com/lawdept/protestdecisions/1994/9415.htm">http://www.usps.com/​lawdept/​protestdecisions/1994/9415.htm</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.usps.com/lawdept/protestdecisions/1994/9415.htm">local copy</a>)</span>.
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="WASP_2004" name="WASP_2004">[WASP 2004]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">The Web Standards Project</span>; <span class="title">Cascading Style Sheets</span>; Available from <a class="url" href="http://www.webstandards.org/learn/resources/css/">http://www.webstandards.org/​learn/​resources/css/</a>; Accessed 26 Oct 2004<span class="local-copy"> (<a href="archive/www.webstandards.org/learn/resources/css/index.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Watson_1991" name="Watson_1991">[Watson&Davis 1991]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Watson, B. C. and Davis, R.</span>; <span class="title">ODA and SGML: An Assessment of Co-Existence Possibilities</span>; Computer Standards & Interfaces 11 (1990/91) 169-176, Elsevier Science Publishers, 1991</dd>
|
||
|
|
|
||
|
|
<dt><a id="WD-CSS3-selectors" name="WD-CSS3-selectors">[WD-CSS3-selectors 2001]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Glazman, D., Çelik, T. and Hickson, I.</span>; <span class="title">Selectors</span>; W3C Candidate Recommendation, 13 Nov 2001; Available from <a class="url" href="http://www.w3.org/TR/2001/CR-css3-selectors-20011113">http://www.w3.org/​TR/​2001/CR-css3-selectors-20011113</a>; Accessed 25 Oct 2004.</dd>
|
||
|
|
|
||
|
|
<dt><a id="WD-hlink" name="WD-hlink">[WD-hlink]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="name">Pemberton, S. and Ishikawa, M.</span>; <span class="title">HLink – Link recognition for the XHTML Family</span>; W3C Working Draft, 13 Sep 2002; Available from <a class="url" href="http://www.w3.org/TR/2002/WD-hlink-20020913/">http://www.w3.org/​TR/​2002/WD-hlink-20020913/</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="WD-positioning_1997" name="WD-positioning_1997">[WD-positioning 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Stevahn, R. (editor)</span>; <span class="title">Positioning HTML Elements with Cascading Style Sheets</span>; W3C Working Draft 31 Jan 1997; Available from <a class="url" href="http://www.w3.org/TR/WD-positioning-970131">http://www.w3.org/​TR/​WD-positioning-970131</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/TR/WD-positioning-970131.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="WD-style_1997" name="WD-style_1997">[WD-style 1997]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Raggett, D., Bos, B. and Lie H. W.</span>; <span class="title">HTML and Style Sheets</span>; W3C Working Draft 24 Mar 1997; Available from <a class="url" href="http://www.w3.org/TR/WD-style-970324">http://www.w3.org/​TR/​WD-style-970324</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/TR/WD-style-970324.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="WD-XML_1996" name="WD-XML_1996">[WD-XML 1996]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bray, T. and Sperberg-McQueen, C. M.</span>; <span class="title">Extensible Markup Language (XML)</span>; W3C Working Draft 14 Nov 1996; Available from <a class="url" href="http://www.w3.org/pub/WWW/TR/WD-xml-961114.html">http://www.w3.org/​pub/​WWW/​TR/WD-xml-961114.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/TR/WD-xml-961114.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Wei_1992" name="Wei_1992">[Wei 1992]</a></dt>
|
||
|
|
|
||
|
|
<dd>The Viola browser is documented in the <span class="title">Viola Browser Archive</span>; Available from <a class="url" href="http://www.viola.org">http://www.viola.org</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.viola.org/index.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Wei_1993a" name="Wei_1993a">[Wei 1993a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Wei, P. Y.</span>; <span class="title">Stylesheet Language</span>; Message posted to www-talk 22 Oct 1993; Available, in two parts, from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q4/0264.html">http://www.webhistory.org/​www.lists/​www-talk.1993q4/0264.html</a> and <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q4/0265.html">http://www.webhistory.org/​www.lists/​www-talk.1993q4/0265.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q4/0264.html">local copy</a>)(<a href="archive/www.webhistory.org/www.lists/www-talk.1993q4/0265.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Wei_1993b" name="Wei_1993b">[Wei 1993b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Wei, P. Y.</span>; <span class="title">Re: Stylesheet Language</span>; Message posted to www-talk 23 Oct 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q4/0276.html">http://www.webhistory.org/​www.lists/​www-talk.1993q4/0276.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q4/0276.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Wei_1993c" name="Wei_1993c">[Wei 1993c]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Wei, P. Y.</span>; <span class="table">FOSI</span>; Message posted to www-talk 26 Oct 1993; Available from <a class="url" href="http://www.webhistory.org/www.lists/www-talk.1993q4/0297.html">http://www.webhistory.org/www.lists/​www-talk.1993q4/0297.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.webhistory.org/www.lists/www-talk.1993q4/0297.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Wei_1993d" name="Wei_1993d">[Wei 1993d]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Wei, P. Y.</span>; <span class="title">Stylesheet</span>; Available from <a class="url" href="http://www.xcf.berkeley.edu/~wei/viola/book/chp14.html">http://www.xcf.berkeley.edu/​~wei/​viola/​book/chp14.html</a>; Accessed 26 Oct 2004<span class="local-copy"> (<a href="www.xcf.berkeley.edu/~wei/viola/book/chp14.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Wei_1994" name="Wei_1994">[Wei 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Wei, P. Y.</span>; <span class="title">Re: Cascading HTML style sheets – a proposal</span>; Message posted to www-talk 24 Oct 1994; Available from <a class="url" href="http://www.w3.org/Style/History/www.eit.com/www.lists/www-talk.1994q4/0387.html">http://www.w3.org/​Style/​History/​www.eit.com/​www.lists/​www-talk.1994q4/​0387.html</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/www.w3.org/Style/History/www.eit.com/www.lists/www-talk.1994q4/0387.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Weitzman_1994" name="Weitzman_1994">[Weitzman&Wittenberg 1994]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Weitzman, L. and Wittenberg, K.</span>; <span class="title">Automatic presentation of multimedia documents using relational grammars</span>; Proceedings of ACM Multimedia '94, pp. 443-451, ACM Press, October 1994</dd>
|
||
|
|
|
||
|
|
<dt><a id="Wilson_2003a" name="Wilson_2003a">[Wilson 2003a]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Wilson, B.</span>; <span class="title">Browser Timelines</span>; Available from <a class="url" href="http://www.blooberry.com/indexdot/history/browsers.htm">http://www.blooberry.com/​indexdot/​history/browsers.htm</a>; Accessed 26 Oct 2004<span class="local-copy"> (<a href="archive/www.blooberry.com/indexdot/history/browsers.htm">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Wilson_2003b" name="Wilson_2003b">[Wilson 2003b]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Wilson, B.</span>; <span class="title">CSS Support History</span>; Available from <a class="url" href="http://www.blooberry.com/indexdot/css/supportkey/syntax.htm">http://www.blooberry.com/​indexdot/​css/​supportkey/syntax.htm</a>; Accessed 26 Oct 2004<span class="local-copy"> (<a href="archive/www.blooberry.com/indexdot/css/supportkey/syntax.htm">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="WML" name="WML">[WML]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Wireless Markup Language Specification</span>; Version 1.2, Wireless Application Protocol Forum, 4 Nov 1999</dd>
|
||
|
|
|
||
|
|
<dt><a id="www-talk" name="www-talk">[www-talk]</a></dt>
|
||
|
|
|
||
|
|
<dd>The www-talk mailing list was started in October 1991 and hosted much of the electronic discussions about the technical development of the web. The mailing list is archived by W3C (<a class="url" href="http://lists.w3.org/Archives/Public/www-talk/">http://lists.w3.org/​Archives/​Public/www-talk/</a>), and the World Wide Web History Project (<a class="url" href="http://www.webhistory.org">http://www.webhistory.org</a>).
|
||
|
|
</dd>
|
||
|
|
|
||
|
|
<dt><a id="W3C_2003" name="W3C_2003">[W3C 2003]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">Some early ideas for HTML</span>; Available from <a class="url" href="http://www.w3.org/MarkUp/historical">http://www.w3.org/​MarkUp/historical</a>. Last modified on 9 Jan 2003. Accessed 13 Mar 2005<span class="local-copy"> (<a href="archive/www.w3.org/MarkUp/historical.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="W3C_2004" name="W3C_2004">[W3C 2004]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="title">W3C CSS1 Test Suite – Version History</span>; Available from <a class="url" href="http://www.w3.org/Style/CSS/Test/CSS1/current/vhistory">http://www.w3.org/​Style/​CSS/​Test/​CSS1/​current/vhistory</a>. Last modified 25 Oct 2004. Accessed 13 Mar 2005<span class="local-copy"> (<a href="archive/www.w3.org/Style/CSS/Test/CSS1/vhistory.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Xerox_Star" name="Xerox_Star">[Xerox Star]</a></dt>
|
||
|
|
|
||
|
|
<dd>A brief description of the Xerox Star computer workstation can be found from <a class="url" href="http://en.wikipedia.org/wiki/Xerox_Star/">http://en.wikipedia.org/​wiki/Xerox_Star/</a>;<!--errata: added ;--> Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/en.wikipedia.org/wiki/Xerox_Star.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="XLink_2001" name="XLink_2001">[XLink 2001]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">DeRose, S., Maler, E. and Orchard, D.</span>; <span class="title">XML Linking Language (XLink) Version 1.0</span>; W3C Recommendation 27 June 2001; Available from <a class="url" href="http://www.w3.org/TR/2001/REC-xlink-20010627/">http://www.w3.org/​TR/​2001/​REC-xlink-20010627/</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="XML_1998" name="XML_1998">[XML 1998]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bray, T., Paoli, J., Sperberg-McQueen, C. M.</span>; <span class="title">Extensible Markup Language (XML) 1.0</span>; Available from <a class="url" href="http://www.w3.org/TR/1998/REC-xml-19980210">http://www.w3.org/​TR/​1998/​REC-xml-19980210</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="XML-names_1999" name="XML-names_1999">[XML-names 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Bray, T., Hollander, D. and Layman, A.</span>; <span class="name">Namespaces in XML</span>; W3C Recommendation 14 Jan 1999; Available from <a class="url" href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">http://www.w3.org/​TR/​1999/REC-xml-names-19990114</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="XML-stylesheet_1999" name="XML-stylesheet_1999">[XML-stylesheet 1999]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Clark, J. (editor)</span>; <span class="name">Associating Style Sheets with XML documents, Version 1.0</span>; W3C Recommendation 29 Jun 1999; Available from <a class="url" href="http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/">http://www.w3.org/​1999/​06/REC-xml-stylesheet-19990629/</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="XSL_2001" name="XSL_2001">[XSL 2001]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Adler, S., Berglund, A., Caruso, J., Deach, S., Graham, T., Grosso, P., Gutentag, E., Milowski, A., Parnell, S., Richman, J. and Zilles, S.</span>; <span class="title">Extensible Stylesheet Language (XSL) Version 1.0</span>; W3C Recommendation 15 October 2001; Available from <a class="url" href="http://www.w3.org/TR/2001/REC-xsl-20011015/">http://www.w3.org/​TR/​2001/REC-xsl-20011015/</a></dd>
|
||
|
|
|
||
|
|
<dt><a id="X11" name="X11">[X11]</a></dt>
|
||
|
|
|
||
|
|
<dd>X11 (a.k.a. the <q>X Window System</q> or <q>X</q>) is a windowing system for bitmap displays. A brief description of X11 is available from <a class="url" href="http://en.wikipedia.org/wiki/X11/">http://en.wikipedia.org/wiki/X11</a>; Accessed 25 Oct 2004<span class="local-copy"> (<a href="archive/en.wikipedia.org/wiki/X11.html">local copy</a>)</span>.</dd>
|
||
|
|
|
||
|
|
<dt><a id="Zeldman_2003" name="Zeldman_2003">[Zeldman 2003]</a></dt>
|
||
|
|
|
||
|
|
<dd><span class="author">Zeldman, J.</span>; <span class="title">Designing with Web Standards</span>; New Riders, May 2003
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="colophon" id="colophon">
|
||
|
|
<h1 class="uuchapter" id="h-359">Colophon</h1>
|
||
|
|
|
||
|
|
<p>Writing a thesis about style sheets sets certain expectations; the resulting document should use proper markup and actively use style sheets. And it should be presentable. This section describes briefly how these goals were achieved for this thesis.</p>
|
||
|
|
|
||
|
|
<p>Almost every document I have produced over the last decade (except email) has been written in HyperText Markup Language (HTML) and styled in CSS. A thesis, however, is significantly more complex than is a letter or a home page. First, a thesis is, generally, much longer than most other documents. Second, a thesis should, ideally, retain more semantics than do most other documents. Third, the presentation of a thesis – especially on paper – is a challenge to CSS.</p>
|
||
|
|
|
||
|
|
<p>The length of a thesis is mostly an issue in the authoring process. Basically, there are two ways of handling the length issue: either the document is split into several manageable parts (e.g., chapters), or the whole document is kept in one file. The right choice will depend on the capacity of the <em>editor</em>, its search and overview capabilities, and the personal preferences of the author. GNU-Emacs, which is my editor of choice, can edit huge files and has good search capabilities within a file. I chose, therefore, to edit the thesis as one HTML file.</p>
|
||
|
|
|
||
|
|
<p>HTML was developed in a scientific environment and, generally, is well suited to retain the semantics of a thesis. For example, internal and external references can be marked up as hyperlinks, and code examples can be marked with the <code class="element">CODE</code> element. I have chosen to use the <code class="element">CODE</code> element when marking up inline HTML code. This, however, is not able to discern between different types of HTML code. It cannot distinguish, for example, between HTML elements and HTML attributes. To retain this distinction, I have introduced several class names which are given as values on the <code class="attribute">CLASS</code> attribute. For example, the markup of the previous sentence is:</p>
|
||
|
|
|
||
|
|
<pre>To retain this distinction, I have introduced several class names
|
||
|
|
which are given as values on the <code class="attribute">CLASS</code>
|
||
|
|
attribute.
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>Similarly, other elements have also been subclassed.</p>
|
||
|
|
|
||
|
|
<p>Needless to say, the presentation of this thesis must be specified in CSS. Any other solution would, I presume, automatically disqualify the dissertation from further review. Thankfully, CSS is at a stage where specifying the presentation of a thesis is possible. The associated style sheet describes the presentation of this thesis on five different media types: screen, projection, print, aural and handheld. Admittedly, few people will ever read the document on a handheld or aural device, but the extra work of specifying the presentation for such <a href="#output_device" class="term">output devices</a> is minimal.</p>
|
||
|
|
|
||
|
|
<p>The media type that requires most work is print. The University of Oslo, like most other institutions, demands that doctoral dissertations are submitted on printed paper.<span class="fn">The requirement does not use the word <q>paper</q>, but prescribes that the thesis shall be submitted <q>bound or stapled</q> in five copies.</span> The easiest way to comply with this requirement is to print the HTML document from a browser. Alas, browsers – including the ones for which I have partial responsibility – are rarely able to print web documents in ways that makes for pleasant reading. In order to generate a decent-looking printed document, it is necessary to use a dedicated formatter. I have chosen to use the <em>Prince</em> formatter which supports the print-specific features of CSS2 as well as some features proposed for CSS3. Headers and footers, footnotes and page numbers in the table of contents have been specified in CSS.</p>
|
||
|
|
|
||
|
|
<p>The PDF version of this document is typeset in 10pt/15pt Bergamo. Code examples are typeset in 9pt/13pt Bitstream Vera Sans Mono.</p>
|
||
|
|
|
||
|
|
<p>The resulting document is one that I am proud to submit.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|
||
|
|
|