Programmable or declarative stylesheets?

Subject: Programmable or declarative stylesheets?
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 19 May 1997 08:57:28 -0400
James Clark wrote:
> This is an interesting point.  One solution might be for browsers to provide
> a configurable timeout for processing each node (I seem to remember
> PostScript printers have something like this).  Don't browser vendors
> already have basicallly the same problem with HTML scripting?

Yes. But I think that they have to "solve" it separately for each

I'm generally leary of schemes that send source code over the Internet.
It always feels messy in several ways. Many of these reasons are vague
and based more on my experience and observations than on any theoretical
difference between programmable and declarative languages:

The probability of an implementation bug in a full programming language
seem much higher to me. It is harder to reason about the interaction of
features when they can be more arbitrarily combined.

Even though the languages are theoretically side effect free, like
DSSSL, or secure, like Java, a bug in the implementation code can make
them much more dangerous than handlers for non-executable data types. I
mean even if you know about a bug in someone's HTML handling it is very
hard to exploit that bug to DO something interesting. But if you can
find a way to break the security on DSSSL or Java handling then you have
a complete programming language at your disposal to try and exploit it.

Implementations of declarative languages can be more optimized than
implementations of full programming languages because the language
implementor decides on how a particular feature is coded rather than the
stylesheet "programmer".

Bugs in fully programmable stylesheets are much more likely and are
harder to recover from (though Jade is quite good at it!).

Non-programmable stylesheet languages seem a little more "backwards
compatible" in this sense: If you view a document that was created with
XML and CSS (for instance) *without* CSS, or without some of the
features the author used, the document structure is basically the same,
but the style is missing. You can apply the style "mentally" or using
another simple stylesheet language (e.g. one optimized for braille). But
when the document's display depends on arbitrary transformations, the
path from document source to reasonable display could be quite large.
This is not a problem in a typical SGML environment where all of the
software is controlled and works together, but on the Web I think that
the document sent across the net should be trivially displayable.

There is a tendency for systems with a built-in programming language to
leave out functions because they can be implemented as part of the
stylesheet language. For instance HTML doesn't have any kind of
reasonable footnote or popup note element. But that feature can now be
implemented in "JavaScript". So now the impetus for the declarative
function is reduced. DSSSL is admirable in the wealth of functions it
provides despite the fact that they can be created from procedure
combinations, but being forced into a declarative box has a way of
focussing thought which I believe to be healthy.

I am willing to admit, though, that some things cannot be done in a
strictly declarative style. I support the use of Java, for instance, for
interactive widgets that could not be otherwise created. Can stylesheets
fall on the declarative side of the fence if transformations are done on
the server?

 Paul Prescod

 DSSSList info and archive:

Current Thread