W3C home > Mailing lists > Public > www-style@w3.org > December 2005

Re: Printing a Book with CSS

From: Mark Schenk <css@markschenk.com>
Date: Thu, 01 Dec 2005 15:43:57 +0100
To: Håkon Wium Lie <howcome@opera.com>
Cc: www-style@w3.org
Message-ID: <op.s030jjlz31wfpa@imladris.kvz.local>

On Thu, 01 Dec 2005 13:54:27 +0100, Håkon Wium Lie <howcome@opera.com>  

> I believe in separating transformations from styling. However, there
> are some small interesting things happening in the interface between
> the two. Take cross-references as an example: it's not possible to
> find what to transform them into (i.e. the page number) without
> formatting the document. So, I think it is appropriate for a
> style-centric language like CSS to do this. Another example is the
> "text-transform" property. Borderline, but convenient.

You make a very good point here: in paged media some formatting has to  
take place before some of the content is known (e.g. page numbers). That  
indeed keeps these kind of things (just) within the bounds of a styling  
language. It is still borderline, and imho the line should be drawn  

For instance the use of 'target-content' is even closer to that border. It  
could be useful for making the TOC, by retrieving the corresponding value  
of the Chapter Header. However, that information does not actually require  
formatting to be performed first, so would better be performed by the  
authoring tool, or a script (a DOM script for creating a TOC is trivial)  
before formatting. It is a balance between purism and convenience. I tend  
to go for the convenience.

One final note: things might get quite complicated when using these kind  
of cross-references, as the rendering/formatting engine will need to make  
several 'passes' before the layout is fixed. Precisely the reason why in  
LaTeX you have to build the document two or three times to make sure all  
the references are correct. That is up to the designer of the user-agent  

> As noted in the article, not all features used are desribed in a WD.
> The 'target-content' function has been around for a long time and it
> deserves a description in a more recent WD.

Yes, and I also found a description (though not specification) of the  
property on the Prince site. I'm not sure, but would this property also  
return the content of generated content? I mean, if you have the following:

<ul class="toc">
<li><a href="#chptr"></a></li>

<h1 id="chptr">Chapter header here</h1>

with CSS styling

h1:before {content: '. ' counter(chapter); count-increment: chapter; }
ul.toc a::after { target-content leader('.')  
target-counter(attr(href),page); }

would that give:

1. Chapter header here............1

or would it be:

Chapter header here............1

because target-content does not include the generated content of H1?

Hrm, I think I've answered my question by asking it: it would be much  
easier, by simply rephrasing the CSS to do the following:

ul.toc a::before { content: target-counter(attr(href),chapter) '. ';
ul.toc a::after { leader('.') target-counter(attr(href),page); }

to obtain

1. Chapter header here............1

Still, in general the question remains: would target-content also return  
the text content of any generated content?

> In Prince, it's based on the width. I think this is correct, but it
> should be clearly specified as such.

That makes sense.

> Agreed. The basic idea is to lay out the content without the leaders,
> find the empty space on each line and divide it up between the
> speficified leaders. This way, leaders should not change the shrink
> wrap algorighm in any way.


Mark Schenk
Received on Thursday, 1 December 2005 14:41:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:22 UTC