An alternative strategy

In thinking back over the various discussions about styles and
stylesheets that I have monitored from time to time over the last year
or so, it occurs to me that there is one possibility that doesn't seem
to have been given much consideration.

All the discussions that I can remember seem to assume that there is a
statistically normal distribution of users that peaks somewhere in the
middle between the extremes of wanting nothing but embedded format
controls on the one hand and wanting complete separation of format and
content on the other.  The debate seems to center on finding the
single solution that will suit the broadest segment of this bell
curve.

It's been my experience, however, that users tend to fall into two
fairly distinct groups.  One group consists of advertisers, artists,
and individual authors who produce highly variable, single-use
materials with sophisticated formatting requirements but little need
for repurposing or large-scale editorial coordination; these people
have consistently demanded embedded format controls and shown little
interest in the virtues of stylesheets -- quite understandably when
one considers that the main benefit of stylesheets comes when material
is reused in some context different from the one for which it was
originally designed.

The other group consists of large-scale content providers who need a
high level of process control and need to produce documents in a way
that allows them to be used for many different purposes over an
extended period of time.  Those among this group who realize that this
requirement cannot be met without separating format from content (not
all of them realize this yet, but they will eventually) have been
insisting on stylesheets that can at least potentially contain all the
formatting information somewhere outside of the document.

A small segment of the second group who have been early adopters of
online publishing and have had a chance to work through a couple of
generations of this technology know what the rest of this group will
eventually learn the hard way, which is that you can't achieve
complete reusability without completely extensible structured markup
and completely programmable presentation controls.  This is the
approach represented by generic SGML and DSSSL, and the fact that you
can't achieve this economically necessary goal any other way (in
particular, you can't achieve it using HTML and CSS) will eventually
force the large-scale content providers into adopting SGML and DSSSL
or reinventing them.  Right now there seem to be a significant number
of people bent on reinventing SGML and DSSSL, but being intelligent
folks they will realize in the end that this is a ridiculous waste of
time and come to demand generic SGML and DSSSL support from vendors
who at this point would rather not bother.

In sum, then, there are a large number of people producing relatively
small, one-shot publications, and a small number of people producing
large, multipurpose publications.  There are of course a significant
number of publishers who presently fall into neither of these two
camps, but the distribution of Web pages in general seems to me to be
decidedly bimodal.  What I am wondering is whether we might not be
better off with a two-pronged strategy that recognizes this.

We all know that what people are screaming for right now is something
that lets them use a standardized set of embedded style attributes
rather than a zoo of proprietary ad hoc tag extensions.  This is what
Microsoft and Netscape are both scrambling to provide, and from a
marketing standpoint, they are quite justified in doing so.  This is,
frankly, the part of the CSS proposal that people really care about
right now.

It would be a mistake, however, to think that embedded format controls
are something of interest only to small-scale content providers.  In
the short run (and this the piece that seems to be escaping everyone),
the other group that is going to want standardized embedded format
controls is the early-adopter large-scale content providers.  That's
right -- the folks who understand most clearly that you will need
generic SGML and DSSSL on the Web over the long run are the same
people who are solving the problem in the short run by generating HTML
from SGML or other document databases.  To these people, HTML is
merely the output format of the moment; it might as well be PostScript
or RTF as far as they're concerned, the one big difference being that
HTML without format controls is a lot weaker for serious publishing
than RTF or PostScript.  As soon as CSS becomes generally supported,
these publishers will happily begin generating HTML with embedded CSS
style attributes from their databases.  It's not the same as generic
SGML with DSSSL, but it's the optimum solution in the meantime, and
much more powerful in terms of long-term reuse than authoring in HTML
with CSS stylesheets.

Certainly there will be some people in the middle, handcrafting
stylesheets and dutifully putting them in their HEAD elements, but the
majority of small-scale publishers won't be using stylesheets for the
very good reason that they obtain no utility from them, and the
majority of really large-scale publishers won't be using stylesheets
because they can get the same effect with a lot less programming by
putting a simple default STYLE attribute on the BODY element and
sticking STYLE attributes directly in the generated output stream
wherever they're needed to override the default.  (Try writing a
database-to-HTML generator that creates stylesheets containing only
the pieces relevant to the fragment being downloaded.  With an
SGML-to-HTML system like DynaWeb, on the other hand, it's trivially
simple to generate inline style attributes on a per-element basis.
You're going to put in the whole stylesheet with every fragment, you
say?  Then what happens to all those bytes you were saving by not
embedding the style attributes in the output stream?  And how about
all those funny little exceptions that in the absence of
programmability in CSS you will be forced to handle with style
attributes anyway?)

I will stick my neck out here and predict that when Netscape and
Microsoft realize that everyone who really counts is getting by with
standardized embedded style attributes, they never will get around to
implementing CSS stylesheets, or will implement as little of the
standard as they can get away with -- leaving out the
context-sensitive selectors, for example.

So here's my thought.  Why not recognize the way that this is shaping
up and say that we will concentrate on HTML with standardized STYLE
attributes (per CSS) for the short term and plan as an industry on
generic SGML with DSSSL stylesheets for the long term?  Isn't this a
simpler, more efficient, and basically more believable strategy than
putting a lot of effort into the implemention of limited solutions
that relatively few people will use while stealing resources from the
implementation of admittedly more difficult solutions that will work
over the long run?

Just a thought.

Jon

Received on Tuesday, 30 April 1996 02:01:03 UTC