W3C home > Mailing lists > Public > www-style@w3.org > April 1997

From CSS to DSSSL

From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
Date: Wed, 16 Apr 1997 20:29:09 -0400
Message-ID: <33556ED4.79C11D16@calum.csclub.uwaterloo.ca>
To: Todd Fahrner <todd@verso.com>
CC: www-style@w3.org
Why don't you and other interested parties join the DSSSList? It is
fairly low volume -- it won't fill up your mailbox:

http://www.mulberrytech.com/dsssl/dssslist/

Todd Fahrner wrote:
> Extra added bonus (void where prohibited): you can use
> <initialpara>stuff</initialpara> RIGHT NOW. CSS browsers (IE & NS) will let
> you style it as you wish, sorta (beta). Downlevel browsers (NS & IE) will
> render it inline. This is not an endorsement of this approach, but it does
> have implications for ease-of-transition to XML.

Let be clear: most SGML users would NOT advocate an <initialpara> tag in
an SGML DTD! That would be completely redundant. An initial paragraph is
structurally distinct already! Why tag it? SGML users tend to frown on
redundant information because it gets out of sync.
 
> But seriously, given that CSS is clearly the next wave of client-side
> style, couldn't DSSSL be deployed effectively on servers, or at "publish"
> time, to generate HTML+CSS? 

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. It is important to
remember though, that shipping dumbed-down documents over the web is
second best.

> If this is the case, then the highest priority
> for CSS is not to fill it out with problem-solving ability, but to make it
> a suitably rich vocabulary for DSSSL-generated formatting. Or vice-versa:
> make sure DSSSL is capable of specifying the full range of formatting that
> CSS can.

> Jon's examples of DSSSL include references to picas and points. Does DSSSL
> know about pixels? About ex? 

DSSSL allows you to define units. Usually the relationship between units
is specified at the time you write stylesheets, but we could also define
pixels as a base unit. Should we really be dealing in pixels anymore?
Don't we want styles to be portable across displays?

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

> How does it compare with CSS-P in terms of granularity of control?

Control of positioning? You have more control over positioning.

> Is there a DSSSL analogue to cascading, 

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.

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

See also:

http://www.mulberrytech.com/dsssl/dssslist/archive/0029.html
http://www.mulberrytech.com/dsssl/dssslist/archive/0030.html

> Finally, can the dynamic formatting behaviors of CSS+scripting
> languages (like alpha-channel manipulation) be modelled and generated in
> DSSSL? 

In the set of existing DSSSL flow objects? No. In some new extended
DSSSL flow objects, yes. Flow objects are the basic building blocks of
DSSSL output. They can be changed to meet changing needs without
changing the heart of DSSSL itself. I am planning on creating flow
objects for 3D display as part of a project I am doing.

> How about rotated text? 

Yes -- currently only at 90 degrees.

> Fit to curve?

Not yet. That would require a new flow object, just as it would in CSS.
The thing stopping it from being in either would be that vendors would
probably balk. Fit to curve is probably non-trivial to implement on many
platforms, even WYSIWYG ones, where the API doesn't help out.
 
> In short, is there a transition path from CSS to DSSSL, or is all lost
> already? :^)

I'm not sure how these questions address that, but yes, there is a
transition path from CSS to DSSSL. CSS goes into 4.0 level browsers, for
use primarily with HTML ,and DSSSL goes into 5.0 level browsers for use
primarily with XML. At one point I thought that there needed to be some
relationship between CSS and DSSSL in order to have a migration path
from one to the other, but now I ask: "why?" Use CSS when it is
convenient (small,simple documents). Use DSSSL when it is convenient
(large, complex, structurally marked up documents).

 Paul Prescod
Received on Wednesday, 16 April 1997 20:23:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:49 GMT