Re: Is DSSSL Hard?

On Apr 23,  9:39pm, Paul Prescod wrote:

> > 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
>
> I'm certainly not a graphics expert,

I am, with a speciality in color theory

> but I know experts who feel very
> passionately that RBG is broken,

device RGB, which is what you selected in DSSL, yes. Calibrated RGB
spaces, particularly when values outside the 0-100% range can be
specified as in CSS, no.

My intent was to encourage you to show how DSSSL would implement support
for the same color space that CSS uses. Is that possible?


> > 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 -
>
> Not at all! Things that are a good idea (and not intrinsically complex)
> should be easy in DSSSL: and usually are. I don't think that the cascade
> falls into this category (anymore).
>
> > and thus the reader
> > is unable to influence the presentation with their own stylesheet;
>
> Not true. The stylesheet is data. It can be embedded in another
> stylesheet where the user's construction rules take precedence.

Sorry if I am being dense. How? Can you give an example?


> > Thus DSSSL avoids having to specify
> > how to resolve conflicts by limiting itself to situations that do
> > not generate any.
>
> Exactly! Usually the avoidance of confusing conflicts is called
> "simplicity."

Also "lack of completeness". I note that you added the term 'confusing' in
there. My point was, is it true that DSSL is capable of defining an
inheritance cascade or not and if so, how?


> > Fine - can you inherit from a different stylesheet? How can document
> > readers inherit from a stylesheet they haven't seen yet?
>
> Why do you want to do that?

To be able to read the document, if I have poor eyesight, or am blind, or
can't distinguish red from green.

> How can you know what you want to override
> before you've seen it?

The type size, for example. Perhaps you forget that the relative units
in CSS let, for example, a well-constructed stylesheet base all sizes
on the body text size. The reader can then make all the text bigger,
or smaller, with a simple one-line stylesheet.


> > And if DSSSL
> > cannot do this, how can readers exchange stytlsheets with each other
>
> I don't see the connection. Panorama users exchange stylesheets with
> each other all of the time.

Perhaps but hardly relevant since Panorama does not use DSSSL. My point
was that if DSSL cannot handle reader stylesheets, then users have to fall
back on browser-specific preference files and suchlike which are not
portable, as I said:

> > - 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.
>
> Not at all true.

If not true, show how the reader stylesheets can be implemented. If they
cannot, we are back to preference files as argued above.

> The first problem is that it isn't clear how CSS helps nor DSSSL hurts.
> How do I globally override all colour changes on all classes using CSS?
> The same way I would in DSSSL, or without any style language at all: I
> ask the UA to map colours to greyscales

How - using stylesheets or magic non-portable files, X resources, etc?


> So I don't see CSS helping much. DSSSL can help through mechanism 2
> above. It can make it very easy to build parameterized stylesheets. It
> can also allow you to override construction rules. Finally, you always
> have the option of using your own style sheet.

But without a cascade this has to implement the whole thing and will give a
generic presentation.


> CSS tried to tackle these issues, but I have no evidence that the
> cascade solution works, and I don't even see how it would work
> theoretically,

Hmm.. 'I don't understand it so it won't work?' I take it you mean
something else.

> so I prefer the series of mechanisms that are tried and
> true: well known DTDs, strict validation, public identifiers,

I have seen no evidence that FPIs have helped solve a grewat deal on the
Web.


> > Ah, you forget the cascade. Blind and print-disabled *readers* will
> > apply them, in the first instance.
>
> What does that have to do with the cascade?

In the part you deleted was your question asking what authors would bother to
implement ACSS stylesheets and the part you quote above was the answer.
If you don't see what reader stylesheets have to do with the cascade then
you need to read the relevant part of the CSS1 spec again.



> What is the value to a blind person

I note you omit the 'print disabled' part and it is they who will benefit
form the cascade the most. I agree that for people who want aural-only
presentation in the case where the author stylesheets are visual-only the
cascade comes down to throwing out the author stylseheet.

>[about ACSS]
> > > 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'm not sure what's involved. I suspect that the SGML community would
> want to be more involved than just handing it off to me! We can begin to
> throw around ideas, however.

OK, but perhaps in a thread more appropriately labelled.

> > 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?
>
> There is nothing about DSSSL that presumes batch processing.

Yes, that is why I said it should at some point be possibe to use it
interactively.

> Issues of
> batch processing vs. interactive are also distinct from print vs.
> online.

Yes. You seem to have misunderstood what I wrote; we are in agreement
here so far.

> I want a DSSSL wordprocessor for print documents that gives me
> an interactive WYSIWYG view

WYSIWYG implies that 'see' is a substitute for 'get (when printed)'.
I am talking more of WYSI.



> Anyhow, ISO DSSSL supports online. It is not specialized for the web,
> however. And there was certainly not as much work put into the online
> flow objects as there were into print.

Yes, that was my understanding also which is why I said above "I know
that DSSSL was originally a print-oriented technology"

> > 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 DSSSL spec does not specify. It is a language for attaching visual
> semantics to documents and not for specifying user agent behaviour.

Hmm. You are saying that DSSL is uaable to handle the case of a browser
window resize? It has no dynamic properties at all? I suspect that is
not the case.

> [about handling a conflict with a style rule that says 'bolder' when
  the parent element is already as bold as it can be]

> > As opposed to doing what?
>
> AS opposed to calling it a mistake in the meta-stylesheet.

That is a fundamental difference of approach on the Web as opposed to
the academic-oriented document processing research community. One is best
pleased with a very black font (graceful degradation) the other is best
pleased by an error message and a refusal to display the document because
a conflict could not be handled.

> Of course I'm
> not saying that Netscape should pop up an error message,

instead it should do what?

> but a validator should trigger an error message.

Of course.




-- 
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 Wednesday, 23 April 1997 22:20:25 UTC