> There are at least two ways in which DTP and HTML+CSS differ:
> - a typical DTP package has access to the whole document, 

CSS3 (especially generated content module) is expected to address this
Try Prince 5 CSS formatter and you'll see that it can take data from 
some part of document and use for example to generate headers, footers,
cross references, table of contents etc.
> but web
>   standards are designed for incremental rendering;

Many parts of CSS are not 'suitable' for incremental rendering,
look at tables for example, or try to apply CSS3 selectors
:contains(), :last-child, :last-of-type etc incrementally.

> - a DTP package can be used in a closed loop environment, where the
>   designer sees the result, and can fine tune the fit of text to the
>   page,
Fine tuning is not the best solution IMHO. 
In any case page sizes can be fixed with CSS too.

> but the assumption under which CSS operates is that it only
>   hints at presentation - the browser may impose constraints for
>   technical reasons
'any failure for technical reason' = 'bug'.
User agent that claims to support CSS should follow specs.

>   and the user may impose constraints for reasons
>   including accessibility - that means designs must be created open
>   loop.
This is what I hate in PDF. User can't adjust layout to address his/her
needs better. I consider it as shortage of PDF rather then advantage.

Up to now CSS was not widely used in desktop publishing, 
but situation is changing and I am sure CSS3 will successfully
replace XSL FO and DSSSL. 
Consider for example Prince
it does the same thing what most of XSL formatters do, 
with only one difference being CSS based it is much more convenient and
easy to use.
Look at Open Reader project
it aims to replace current proprietary desktop publishing solutions
with XML + CSS. Open eBook Format also uses XHTML + CSS.

Received on Tuesday, 14 June 2005 11:03:42 UTC