Re: From CSS to DSSSL

At 8:29 PM -0400 4/16/97, Paul Prescod wrote:

> Let be clear: most SGML users would NOT advocate an <initialpara> tag in
> an SGML DTD!

I think the case for such was in fact a case for "<intro>" or something

> DSSSL has been deployed to generate HTML (in Jade -- I have built a
> whole website this way), and Jade will generate HTML+CSS as soon as CSS
> is supported in a standard way by major browsers.

I am very interested to see how this works.

> It is important to
> remember though, that shipping dumbed-down documents over the web is
> second best.

In the most general case, sure. But in particular situations (currently
predominant), shipping "smart" documents is not such a nifty idea, as when
a large part of the intended readership might not be equipped to enjoy the
smarts, or even to access the documents at all, much less to re-use the
data as such. For operations of any significant scale, however, I will be
interested in XML+DSSSL as document design and management tools, if not
initially as final publication formats.

> > Should we really be dealing in pixels anymore?
> Don't we want styles to be portable across displays?

I understand the downside very well. Points and picas, however, are grossly
misinterpreted across platforms for display at least, so they're not useful
here. If a UA's pixel density were very far from the 90 dpi reference, or
the reader's eyesight were poor, however, I would expect the UA stylesheet
to override my specification. This is one meaning of cascading, no? In the
meantime, a particular rasterization for type is more important than a
nominal size in determining its character, legibility, etc. Consider the
case where word-images must maintain a consistent visual relation to
(bitmap) images. As soon as UAs and hardware will allow for bicubic
interpolation on variable-size images to keep in synch with variable-size
type, I'll stop wanting to specify pixels.

> > Percentages or rendering area (width and height)?
> I believe that those would have to be added. I can't find anything that
> would indicate that they are available in DSSSL-Print or DSSSL-Lite.
> That extension for online is about to begin. It is part of the XML
> effort.

This is essential for preserving typographical grids in areas of varying
aspect. (By grids I mean divisions of the canvas into harmonic units, like
3x4, not graph paper). CSS is weak in this area, but without percentage
units (on the horizontal) it wouldn't go anywhere at all.

> I'm not sure if there is a CSS analogue to cascading! I haven't yet seen
> this idea put in practice, with the many obvious kinks (oops! black on
> black!) worked out. Once we understand this, it could probably be
> incorporated into DSSSL, but right now it looks to me like a nice idea
> that wasn't practical. The stylesheet author MUST provide a list of
> reasonable alternatives: either as options or as separate style sheets.

The "@media" selector proposed in the CSS Printing Extensions WD could be
generalized to accommodate multiple stylesheets on a single document based
on rendering environment variables, including reader needs/preferences. So,
for example, you could go from one- to two-column layout as the rendering
area (say the browser window) went from portrait to landscape aspect, all
without a lick of scripting or other non-declarative stuff. (if only css
could accommodate multi-column layout....)

> > or to multiple choices for, say, fonts?
> That is done through definitions at the beginning of the specification.
> On the dssslist, we have started work on a DTD that will allow WYSIWYG
> editors (or browsers) to load DSSSL style sheets and provide the most
> salient choices to the user: "This stylesheet allows the font to be
> changed to one of these options, the margins to be scaled from 0 to 2
> inches and offers three different colour schemes."

As a matter of taste, I'd class this with "click here for the shockwave
version"  at the index page. Draws too much attention to the machinery.
Cascading aspires to transparency, at least.

> I feel that this is a
> much more workable solution than ad hoc combinations of user stylesheets
> and author stylesheets that were not designed to work together.

I share your suspicions about the practicality of cascading, but I'm still
optimistic. A really good implementation and a large body of test cases
will deliver a convincing answer, I think. We don't have either yet.

> I am planning on creating flow
> objects for 3D display as part of a project I am doing.

keWl. blinking 3D? :^)

Todd Fahrner

Follow-Ups: References: