Re: Mosaic Corp. HTML extensions (NCSA Tables?)

Murray Maloney (murray@sco.COM)
Fri, 21 Oct 1994 15:10:51 -0400 (EDT)

Marc Andreessen writes:
> I realize the extensions in 0.9 have stirred up some attention,
> but they're really not that significant relative to a lot of the
> capabilities that our customers and potential customers are beating
> down our doors for. We do need to figure out in relatively short
> order how specs for these new features get cut-n-dried and implemented,
> because the market is moving too fast to stand still and debate for
> a long time, and if we don't move quickly, I guarantee each and every
> person on this list that there are much bigger companies than MCom
> that will be doing so, and then we're *all* irrelevant.
> I would more than welcome comments on how people on this list think
> we can all move forward together quickly to address the intense
> market demand for enhanced functionality -- particularly for
> functionality related to advanced control over layout and
> appearance, which is of urgent concern to an amazingly broad
> spectrum of the potential customer base, as has been the case
> for over a year and a half.
> Marc

Yes, thank you for asking this question. I wish that I
had seen this before I left for Chicago rather than
after getting back, but....

Someone recently said that compromise leaves one with
the worst of two alternatives. I hope that is not accurate,
because I am about to suggest that we all need to compromise.
However, I am hoping that we can develop a language architecture
that accomodates more than one formatting model.

At the conference this week, I heard a lot of polarizing statements.
Some say that hard-coded style info is the way to answer the needs
of WWW users, others complain that "that isn't SGML". Some of the
SGML proponents suggest that external stylesheets are the way to go,
while others complain about the probable speed penalties and
the processing burden implied. Some publishers insist that
they must have full control over presentation, while users and
technology respond that local conditions and preferences must rule.

First of all, there is nothing in ISO 8879 that says that
formatting information must never be encoded within any
document that purports to be SGML. That is an opinion,
held by a large number of people who have years of experience
in publishing, information management, text processing, etc.
None of us should discard this opinion out of hand, and some
could stand to learn the philosophy behind it. However, it is
not valid to claim that <B> is invalid SGML or that <STRONG>
is somehow more valid.

There is absolutely no reason why style information
cannot travel in the document and/or a style-sheet both.
In cases where publishers and readers are willing to incur
the penalty associated with external style sheets, why would
anyone want to deprive them of their God-given right to do so.
Ya, I know. Neither camp thinks that publishers or users
would really want to do things the way that the other camp
suggests if they really understood. Well, speaking as someone
who fully appreciates the point of view being expressed on
both sides -- I do understand and I want the freedom to choose.

Speaking as a publishing systems architect, as a publisher,
a writer, and as a user of the WWW, I can assure you that the
imperatives of both publishers and users to control format are
legitimate. However, I don't think that the publishers rights
take precedence over those of the user. Therefore there must
be a means for publisher preferences and author preferences to
be communicated with a document (within or as a style sheet),
but the user must have a convenient means of overriding.

All of these things are possible. Surely it would be in
all of our best interests to establish a set of design
principles that would allow us to move forward while
accomodating alternate points of view within our philosophy.
As Marc points out, if we don't then there is a risk that
an unnamed organization will simply beat us at our own game.


Murray C. Maloney Internet:
Technical Publications Writer/Architect Uucp: ...uunet!sco!murray
SCO Canada, Inc. My Phone: (416) 960-4031
130 Bloor Street West, 10th Floor Fax: (416) 922-2704
Toronto, Ontario, Canada M5S 1N5 SCO Phone: (416) 922-1937
Sponsor member of Davenport Group (
Member of IETF HTML Working Group (