Re: Concerns about HTML+ complexity
fox@pt0204.pto.ford.com (Ken Fox)
Errors-To: listmaster@www0.cern.ch
Date: Fri, 17 Jun 1994 23:04:22 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406172058.AA04908@pt0204.pto.ford.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: fox@pt0204.pto.ford.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: fox@pt0204.pto.ford.com (Ken Fox)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Concerns about HTML+ complexity
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text
Content-Type: text
X-Mailer: ELM [version 2.4 PL23]
X-Mailer: ELM [version 2.4 PL23]
Brian Behlendorf writes:
> As food for thought, let me throw this in: if I could tell the art people
> here that they could Quark Xpress files seamlessly into HTML files (sans
> hyperlinking of course)
Why shouldn't they have hyperlinking capabilities? Just overlay shaped
regions on top of the image. Or, create an associated hyperlink file that
the rendering agent for Quark Xpress would use like this:
Web Browser: Hyperlink at (x1, y1)?
Rendering Agent: (looking in hyperlink file) No.
Web Browser: Hyperlink at (x2, y2)?
Rendering Agent: (looking in hyperlink file) Yes, the URL is foo://bar/
The Web browser might ask the question to the rendering agent whenever a
user poked the image with a mouse. Other commands like "search this" and
"print this" also need to be defined so that external data is not second
class.
This is why we need a standard interface to rendering agents! I expect the
addition of hypertext markup to non-markable documents to be very common.
There should probably be a standard way of wrapping data with hyperlink
information.
> ... because everyone out there has a free plug-in
> provided by Quark that does the rendering into every Web browser (and if
> people don't have it they can get it from our site anyways), they'd do
> backflips.
Could be one provided by Quark. Could be a competing implementation. They
would all work in everybody's browser. The resulting applet market would
really take off.
> Build a strong, portable, efficient API, and encourage ALL vendors to
> build plug-ins to the API for their products.
It doesn't have to be an API. It could "merely" be a protocol specification
or something equivalent.
> Then HTML++... won't have
> to try and become a page description language, it can stay light and easy
> to use as the lingua franca.
This is *exactly* the kind of usage for HTML I had in mind with my original
posting. HTML becomes "simply" the glue that holds documents together in
space and time. The spatial organization comes about through the
interaction of geometry managers with rendering agents. The time
organization is achieved through the linking and navigational structure.
- Ken
--
Ken Fox, fox@pt0204.pto.ford.com, (313)59-44794
-------------------------------------------------------------------------
Ford Motor Company, Powertrain | "Is this some sort of trick question
CAD/CAM/CAE Process Integration | or what?" -- Calvin
AP Environment Section |