Re: Is DSSSL Hard?

On Apr 22,  5:46pm, Paul Prescod wrote:

> I agree 100%. What I'm worried about is not syntax, but semantics. If
> CSS grows in ways that are incompatible with DSSSL, then implementors
> will have to implement two different models. Of course CSS will always
> be implementable as a subset of DSSSL: Turing proved that a long time
> ago.

One could also argue that CSS (or indeed DSSSL) will always be implementable
as a "subset of" C, Java, or your language du jour for the same reason.

I am reminded (again) of the person who buys a computer with the most
up-to-date browser, the most amazing desktop publishing system, the
most accurate and flexible CAD package. Upon unpacking it there is a
bunch of hardware, a bare OS, a hex editor and a listing of the CPU
op-codes. Theoretically, all the things described can be implemented
given a little time.

What I am getting at is that simply asserting that it is possible does
not help people judge how hard that possibility might be. Your examples
are a big help in this.


> The premise of the discussion is that we are applying the two
> stylesheet languages to a new DTD (e.g. something created with XML).

That is indeed your premise; as I said in an earlier message we do not
actually have that luxury in practice.


> > Defining a new unit in one line of code sounds easy, but how do you
> > convey how the new unit is to interpreted? I would think that has to
> > go into a specification somewhere?
>
> I was not arguing that DSSSL is more powerful because it is only one line
> to choose which color-space to use.

Good, because your style sheet defined device RGB whereas CSS uses a fully
defined, color managable definition of the color space, defined in terms of
an ICC profile (submitted by ISO TC 130 as ISO 15076 Graphic technology --
Prepress digital data exchange -- International colour profile format)

See also http://www.w3.org/pub/WWW/Graphics/Color/sRGB

> The display: attribute is basically necessary

(It is a property, not an attribute)

> for every element

yes, that property exists for all elements - whether a particular
stylesheet defines a value or not.

> (unless it is implied as in HTML),

in CSS this is called the initial value.

> > Technically it's not a mistake. Conflicts are intrinsic to CSS and we
> > have clear rules for how to resolve them. But, as with any language,
> > nonsense can be expressed in CSS...
>
> I would like to respond: "Conflicts are intrinsic to CSS" but you just
> said that -- and it's right in the spec.

Yes. It's not in the DSSSL spec because (correct me if I am wrong) DSSSL
has no cascading mechanism - I am sure you will say that one can be
programmed in DSSSL since it is Turing complete - and thus the reader
is unable to influence the presentation with their own stylesheet;
authors are unable to 'subclass' existing stylesheets by cascading
them with their own overrides. Thus DSSSL avoids having to specify
how to resolve conflicts by limiting itself to situations that do
not generate any.

> I don't think that it is a good
> thing. If you want to inherit from somewhere else in the stylesheet
> (as opposed to from your containing element), just say so explicitly:
>
> (element p (make paragraph
> 		use: default-p-style
> 		font-size: ... ))

Fine - can you inherit from a different stylesheet? How can document
readers inherit from a stylesheet they haven't seen yet? And if DSSSL
cannot do this, how can readers exchange stytlsheets with each other
- we are back to non-portable and often non-exposed proprietary 'user
preference' files, we are back to 'one size fits all eyes' presentation
and if you happen to be dyslexic or color-blind or have low vision,
there is nothing you as a reader can do.

CSS has chosen to tackle these issues, they are important issues, and
I hope DSSL can be adapted to tackle them too.

> > One of the extensions we are working on is ACSS: Aural Cascading Style
> > Sheets. This will enhance access to the Web for visually impaired
> > users -- only some of which are professional Web publishers...
>
> I wonder who will actually apply them? Only the professional web
> publishers or the most scrupulous of amateurs.

Ah, you forget the cascade. Blind and print-disabled *readers* will
apply them, in the first instance. If authors do apply them, of course,
then the result can be of higher quality.

> I support ACSS and hope that we can add whatever you come up
> with to DSSSL.

That is really good news and perhaps we could address that in a
separate thread.

> ACSS is not really about expanding CSS's domain into
> generic documents and complex HTML, but about more properly serving the
> simple HTML consistency.

Not sure what you mean by 'simple HTML' there.

> I think that that's great. I also expect it
> will be DSSSL compatible in the sense that extending DSSSL to suppor the
> same characteristics would be easy.

Is that a volunteer I hear in the audience?


> > I have some questions to your sample style sheets:
>
> >  > (define page-width 8.5in)	; these are just useful, not necessary
> >  > (define page-height 11in)
>
> > Could one define this in a manner that would work for both American
> > and A? sizes -- e.g. through client-side binding?

Even better, what happens when the reader resizes the browser window?
I know that DSSSL was originally a print-oriented technology but it
should at some point be possible to use it for interactive reading of
online documents rather than batch processing, shouldn't it?

> I wouldn't call it client-side binding, but there is a feature to
> allow that. It is called the (display-size) procedure and returns
> the space that the element being created has available to it. It
> would have been better for me to have used (display-size) throughout.
> To be honest, I didn't know about it when I wrote the stylesheet. This
> is DSSSL's biggest weakness: the spec is large and finding the feature
> you want is difficult. I don't think that this is the same as being
> difficult, however.

A subtle distinction, perhaps. But does this mean that when the reader
resizes the browser window, the display-size procedure will return a
different result? If so, does this trigger a reflow or are flow objects
created only once as the document is read?

> > The CSS style sheet you are replicating uses the 'bolder' value for
> > 'B' and 'STRONG', i.e. a relative value. Using DSSSL, I assume you
> > could query the font weight of the parent element and add 1 or
> > something?
>
> I don't think so. Font weights are not numbers.

OK, increment the enumeration then

> I could write a function
> to do so in 30 seconds, but the DSSSL spec doesn't do it itself. I find it
> a little disconcerting that CSS would just silently make something that I
> asked to be BOLDER to be actually no bolder if the maximum boldness was
> already specified.

As opposed to doing what?

> Well, I really don't believe that it is reasonable to expect that people
> will be able to override any property at all on visited links.

Does that mean that DSSSL is not sufficiently dynamic to allow any
changes to a document at all? I am aware that current implementations
are batch-driven and print-oriented but surely something as simple as
a link anchor turning from blue to purple on being visited can be
expressed in a DSSSL stylesheet?

> CSS allows
> it, but it seems like overkill to me. Should a stylesheet be able to turn
> a followed link into a list item? It seems that the (simpler) equivalent
> is:
>
> (make link
> 	color:
> 	visited-color:
> 	active-color:
> 	active-background-color:
> 	...)

Simple, declarative, matches CSS. Seems fine for the short term.
>
> On the other hand, if you really DO think that different links should
> be able to have completely arbitrary properties, then:
> [...]
> This is the same technique that you use for differentiating based on an
> attribute value:


Aha, this is looking more hopeful. Perhaps you have read the WD on
CSS positioning and seen tool-tip help, pop-up menus, collapsible
outlining, and dynamic contextual displays; these sorts of things
should be possible in DSSSL for Web use.


Paul, thanks for taking the time to contribute to this blow-by-blow
comparison thread which is, I think, extremely useful.


-- 
Chris Lilley, W3C                          [ http://www.w3.org/ ]
Graphics and Fonts Guy            The World Wide Web Consortium
http://www.w3.org/people/chris/              INRIA,  Projet W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 (0)4 93 65 79 87       06902 Sophia Antipolis Cedex, France

Received on Tuesday, 22 April 1997 20:33:05 UTC