Re: DSSSL WWW Enhancements

Subject: Re: DSSSL WWW Enhancements
From: James Clark <jjc@xxxxxxxxxx>
Date: Thu, 29 May 1997 13:16:03 +0700
Thank you for your helpful comments.

At 22:14 28/05/97 +0200, Hakon Lie wrote:

> - the proposed background image characteristics are said to be
>inherited. This is not the case in CSS1 -- why should they inherit?

In DSSSL the general policy is that characteristics are inherited unless
there is some compelling reason why they should not be, since there are some
conveniences that are available only if the characteristic is inherited
(declare-initial-value, use in style objects).

> - the document suggests a "side-flow-multiple" to control if floating
>areas can be placed next to each other horizontally. Can't you just
>use the proposed "side-float-clear" for this?

I was thinking of putting side-float-clear on just the running text, but if
you allow it on the floating objects as well, then I think you're right.
Was this what you had in mind?

Suppose I have a document with two float:left images in a single line.  If
I've understood the CSS model correctly, a formatter can place these images
side by side (with the second image to the right of the first image).  This
might not be what I want, because it may leave to narrow a space for the
running text.  Instead I might prefer second image to be placed below the
first.  To do this, I would use clear:right on the first image.  Is that how
it works in CSS?

> - the document briefly mentions that the functionality of the CSS
>positioning draft should be replicated in DSSSL. The ideal solution
>would be if one could find a way to reuse formatting properties
>directly without having to rephrase specs.

I certainly have no desire to reinvent things unnecessarily: I would much
rather spend my time writing code than specs.  However I can see at least
one good reason why a solution that's right for CSS may not be right for
DSSSL and vice-versa.  In CSS formatting properties are attached directly
for source elements whereas in DSSSL they are attached to flow objects which
are need not map one-to-one onto elements (and usually don't).  The fact
that in DSSSL there can be a one-to-may map between the source elements and
the objects that formatting properties attach to opens up many possibilities
for modelling formatting behaviour that aren't available in CSS. For
example, in DSSSL a boxed paragraph is modelled by a paragraph flow object
inside a box flow object, but this approach isn't available in CSS.  It
doesn't make sense to constrain DSSSL to use only solutions that would work
for CSS.

If CSS could be extended to so that it can associate with a single source
element multiple objects each with their own properties, then I think it
would be much easier to share properties between CSS and DSSSL.  It would
also make CSS enormously more powerful. For example, if you want to handle
generated text in CSS, one way to do it is with before and after properties
on an element.  But this is very limited.  You can allow the before and
after generated text to have different properties with before and after
pseudo-elements (ie you can allow yourself three objects for each source
element). But what if you want to generate a horizontal rule before a
paragraph, or an image, or a rule and an image and some text?  The only way
I can see to avoid arbitrary limitations with generated text is to allow a
complex hierarchical structure of objects each with their own properties to
be associated with a single source element.

>2) CSS1 features that can still be tricky to convert
>
> - the matching rules for the font properties in CSS1 are very
>specific. E.g., the order in which things are matched is specified.
>Unless DSSSL is extended in the same direction, converted style sheets
>may not end up using the same font. 

I wouldn't want to require all DSSSL implementations to use a particular
font matching algorithm.  DSSSL needs to be able to work with existing
formatters as well as with native DSSSL formatters.

I think the way to handle this that would be most in keeping with DSSSL's
current approach would be to add a font-mapping-method (or maybe
font-matching-method) characteristic whose value would be a public
identifier of the policy/algorithm to be used for font matching.  Then XS
could define a value for this which specified CSS1 compatible rules.

> - font-weight takes a different set of values than does the
>corresponding characteristic in DSSSL. We need to define a mapping
>table of some kind

We have nine weights just like CSS does. Bold is the 7th weight in DSSSL
just as it is in CSS.  But the default weight in DSSSL is the 5th weight
(medium), but the default weight in CSS is normal which is the 4th weight
(which is semi-light in DSSSL).

By my reading of the CSS spec, it would seem like the right thing to do is
to map each of the nine values in DSSSL onto the corresponding nine values
in CSS.

> - 'ex' units seems to be missing in DSSSL.

Right.  I forgot about that.  Handling this is DSSSL would require a
(font-x-height) procedure that returns the x height of the font specified
for the flow object that the (font-x-height) procedure is being to use
specify a characteristic for.

How would this work for non-Latin fonts?  Other scripts have similar, but
not identical concepts.  For example, Thai typesetting sometimes works in
terms of the height of the character bo baimai (Unicode 0E1A).

DSSSL also lacks pixels.  This could be handled with a (pixel-size) procedure.

> - relative and percentage values. There seems to be no easy
>conversion of relative keyword values (e.g. 'bolder' on 'font-weight')
>or percentage values (e.g. 'width: 30%' which sets the width of an
>element to be 30% of the width of the parent element)

In general relative and percentage values convert into an expression using
(inherited-c) or using (display-size).  For example,

  font-size: 150%

would convert to

  font-size: (* (inherited-font-size) 1.2)

I haven't looked in detail at all the percentage values in CSS.  Are there
cases other than:

- a percentage of the value of some property of the element or a parent element

- a percentage of the width of the parent element

?

Bolder and ligher are different because their exact effect depends on the
available weights.  I'll have to think about what the best way to handle
that is in DSSSL.

>Also, it should be noted that a CSS1->DSSSL conversion can only take
>place after cascading.

DSSSL does have a concept of cascading (inspired by CSS).  A DSSSL
style-sheet can be composed of an ordered sequence of parts (which can be in
the same or different resources) with rules in one part overriding rules in
subsequent parts.  However it's less fancy than CSS's cascading mechanism
(no !important for example).  Also the fact that in CSS you can specify each
property independently in a separate rule whereas in DSSSL you can't makes
cascading rather different (and more useful) in CSS.  So in general I
suspect that you are right that the cascading must be done before
conversion, but I think in some cases in may be possible to do it before the
cascade.  It wouldn't be easy though.

James



 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread