Re: Style Sheets for HTML

Brian Behlendorf <>
Date: Mon, 30 May 1994 10:23:16 +0200
Message-id: <>
Precedence: bulk
From: Brian Behlendorf <>
To: Multiple recipients of list <>
Subject: Re: Style Sheets for HTML
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
On Sun, 29 May 1994, Gavin Nicol wrote:
(Quoting Phillip Hallam-Baker)
> >Keeping it simple while still allowing powerful expression is the
> >objective. It is not our aim to produce a spec that is simple through
> >not being functional. We want to be both functional and simple. 
>   A nobel idea. I am sure that you will do a fine job on HTML+.
> However, I don't feel that any DTD will ever satisfy the needs of
> everyone. I feel that HTTP needs to be extended to allow for
> negotiation on DTD's, stylesheets, pay-per-use, encryption, and other
> things in order for commercial publishers to be really successful. 

Well, yes, things do need to be added to the transaction layer, but
that shouldn't affect too much how the document language should be 
constructed.  Pay-per-use (hooray for David Chaum's great keynote
address at WWW'94!) and encryption belong at the HTTP layer (along 
with server-side and client-side programs), while stylesheets are an
issue above HTML.  Define a strong document language, and the stylesheets
will be created with ease.  As for arbitrary DTDs... aren't they really
different document types, and thus should have unique MIME types anyways?
Additionally, the level of programming browsers would need to properly
display arbitrary DTD's would be huge, and these browsers are big enough

> For
> example: Say Encyclopedia Britannica was online. How could they charge
> people for using it? 

Actually, they are setting up an online service (  I
think the model they are using is to sell the service to institutions
(universities, etc) and use access control restricted to
*, for example.  However, if any server in that domain
has open proxying supported (as the CERN server does - does NCSA's?)
then *anyone* can get that information, as the proxy service is open
to anyone (or is it configurable?).  I see this as analogous to the
easily-forgeable sendmail problem awhile back, which was solved via
the enlightened self-interest of the sendmail authors to enable
complete tracing, so that unauthenticated mail could never be fully
anonymous.  Hopefully a similar solution will become available for
proxy servers - the best solution I can think of is to simply pass
along the name of the originating host, or perhaps even the complete
path.  If this is currently in the HTTP spec let me know.