Re: DTP with XHTML+CSS

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

Only a clairvoyance module can address that issue.  You cannot 
progressively render things that require lookahead, at least not
without a fixup!

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

But note that even the CSS3 box model section explicitly says
that progressive rendering is a desirable aim and imposes constraints
on floats to achieve that.  Also, as already noted, breaking progressive
rendering is bad for the user, because the document will be progressively
downloaded.

> Fine tuning is not the best solution IMHO. 
> In any case page sizes can be fixed with CSS too.

We are not talking about page sizes but the individual boxes on,
possibly multiple pages.  In any case, CSS cannot fix sizes because
the user can override.

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

A good example is the print media thread.  Printers lose pixels at
the edge of the sheet because technical reasons they cannot print
exactly at the edge, but there is sometimes a requirement that there
be no unprinted border.  Moreover, looking at the conformance 
requirements in the CSS 2.1 draft announced today:

    1. It must support one or more of the CSS 2.1 [33]media types.
 
So technical limitations can mean that it doesn't support braille or
doesn't support visual styles.

       Values may be approximated when required by the user agent.

So technical limitations can mean that it doesn't represent values
exactly.  Also, and this has its own set of rules, the lack of a font
specified by the user doesn't make a CSS implementation invalid, nor does
having a version of the font face without a particular glyph (e.g. a US
out of the box XP installation will not be able to display in "MS Song"
(because it is not supplied with XP, and one must explicitly enable East
Asian support for any Chinese fonts to be available), nor will a Linux
system (it would be a breach of the copyright licence)).

And even more explicitly:

   The inability of a user agent to implement part of this specification
   due to the limitations of a particular device (e.g., a user agent
   cannot render colors on a monochrome monitor or page) does not imply
   non-conformance.

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

For the primary target market it is a very strong advantage and 
a selling point, however accessibility legislation, and just possibly
small devices have meant that the latest PDF versions have the information
needed to reflow the text and the latest readers can reflow even without
that.

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

This is how standards die.  They start tight and focused (replacing some
old complex standard).  Then they lose their focus and attempt to do
everything, so become complex and awkward, until replaced by the next
generation of tight and focused standards.  It's much better to use the
right tool for the right job.  CSS was designed for simple style sheet
production, not as a fully blown DTP system.

Received on Tuesday, 14 June 2005 21:48:34 UTC