Re: Standardizing new HTML featuresBill Janssen <email@example.com>
Date: Tue, 27 Apr 1993 17:17:55 PDT
Sender: Bill Janssen <firstname.lastname@example.org>
From: Bill Janssen <email@example.com>
To: Bill Janssen <firstname.lastname@example.org>,
email@example.com (Marc Andreessen)
Subject: Re: Standardizing new HTML features
Cc: Dave_Raggett <firstname.lastname@example.org>, email@example.com,
Excerpts from ext.WorldWideWeb: 27-Apr-93 Re: Standardizing new HTML ..
Marc Andreessen@ncsa.uiu (1750)
> Plus, this is hypertext -- most times, generic inclusions shouldn't be
> per se necessary, or even necessarily useful compared to a hyperlink.
Perhaps so, perhaps not. There's a difference between a multimedia
document and a hyperlinked document, as your experiments with embedded
images richly show.
> Also, I'm not certain that any multimedia data other than images needs
> to be specifiable as inlined/included. Things like audio and MPEG can
> simply be pointed at from an anchor (as Mosaic does) and forked to
> external viewers or processed internally, whichever the browser
Come now, so can images. So why special-case them in XMosaic? Because
your users are looking for multi-media, not just hypermedia. Similarly,
HTML should allow embedded animations (very useful in documentation of
gestural interfaces, for one thing) or graphs or even other text. I'm
basing my expectation of the power and utility of this mechanism on my
experience with Andrew and Slate, both of which have this feature.
Typically what is shown for embedded sound, for instance, is a small
(tiny) control panel which allows control over the speed and amount of
the sound inset that is actually played, along with a label.
The other thing is, if you can specify the data for one of these
embedded things directly in the HTML document, you can then avoid some
of the complexity/connectivity problems you mention. That's what I
meant by "in-line data", as opposed to "in-line" presentation, which
both included and external data would, presumably, have.