Re: CSS vs. DSSSL-O
I think I had mailer problems. So this is a re-transmission.
At 5:23 PM 11/23/96, firstname.lastname@example.org wrote:
>At 09:51 PM 11/22/96 -0800, Tim Bray wrote:
>Perhaps we could attack through Java. It sounds bizarre, but right now Java
>is so heavily hyped that Java-anything is considered good. Ergo Netscape has
>actually not half bad. I am envisioning something we could call "Java
>stylesheets". It would be a DSSSL-like transformation that works on the
>source object and builds a screen display. The style sheet would be
>delivered as Java byte codes. The byte codes would have to have access to a
>much more powerful display layout API than they do now (fonts, layout,
>etc...much like DSSSL flow objects).
An interesting aspect of this is that XML is actually a much nicer way to
pass parameters to applets: markup can be pre-compiled into an attributed
tree, that can (optionally) be verified for structure, and then fed as
input to the applet. So whatever XML styles are, they should have a way to
specify that an element should have its parse-tree passed to an embedded
application (applet). Since we have a well-defined notion of what
information the parser must pass to an application, we can do a Java
language binding, and a Scheme/DSSSL language binding as well... (In the
case of Scheme-in-Java these might be identical).
> a) Scheme has a stigma (though I *really* like it, I can imagine Marc
> b) DSSSL will have a scheme-stigma.
> c) DSSSL without scheme is, in my opinion, underpowered, just as CSS is
> d) Java bytecodes put everyone on fairly level ground.
> e) Java interpreters are already widely deployed and getting more and more
> e) maybe once the document UI is controlled in Java there are some
>interesting interactive things we can do (expandable table of contents, for
>Once Java-style sheets are implemented, CSS, DSSSL-O and full DSSSL could
>all be built on top of them, either by compilation *to* Java byte codes, or
>by interpretation *by* Java bytecodes.
The only problem I see with this is that there are good reasons to have
declarative style sheets rather than only xecutable style sheets. There is
also a real performance and/or deployment hit for distributing formatters
over the web. Either we get large downloads (which Netscape caching
strategies do not help with), or we have to somehow get the formatters onto
people's disks. Also, I think the politics of defining an API that goes
that far down into a browser's guts will be pretty difficult.
We definitely need to do whatever we can to make XML and CSS work
together. I think the fundamental idea of CSS (cascading) is so misguided
and retarded as to be comical, but that doesn't change the facts that it is
being implemented by the two gorillas -- so we better be able to work
within that framework, as well as within a smarter one. I don't think we
can afford to be wrong if people choosse to patch CSS rather than discard
it once the limitations become clear. In fact, given the history of HTML, I
would expect that CSS will be hard to kill.
><META-COMMENT>Perhaps it is too early in our understanding of online style
>sheets to choose *any* standardized style sheet syntax. Look at the
>complexity of DSSSL-Print. It is only after *centuries* of typographic
>development that we knew what the right flow objects and characteristics to
Probably so, but we have to try anyway, I think. And at least the basic
structures of typography are not as divergent from print as the video and
multimedia stuff... I think we can be useful, even if we are not 100%
I am not a number. I am an undefined character.
David Durand email@example.com \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________