I've been reading www-talk for about a year, read lots of archives, poured
over the docs at CERN and NCSA, and I still think that giving presentational
hints wouldn't violate the fundamentals of what TimBL and others had in
mind. And I'm not interested in verging away from SGML for this,
either. This doesn't have to be irresistable force (artistic
presentation) versus immovable object (structured, efficient text). HTML
won't give everything to both camps, but it can go pretty far. I'll be
posting a wish list here soon of things I'd like to see which haven't
been addressed by anything I've seen presented on HTML 3.0, all of which
can be hopefully done in SGML.
> >2) Acrobat/HyperPostscript/some-other-document-language-that-assumes-complete
> > -control-over-presentation
>
> At the risk of repeating myself, I have to say that I really don't think
> this is an either/or proposition. Look at the announcement Sun just made
> -- it is standardizing on SGML *and* Acrobat. Acrobat wasn't intended to
> be a UI language, either. It will go its own direction.
Well, exactly what I was saying, too, which is that the two of them
together will do just about everything I need to do with static
documents.
> >3) Browser plug-in modules to extend GUI functionality in a standard way,
> > and explicitly installed by the user (the "Acrobat" plug in, the
> > "AOL interface" plug-in, etc.) I don't subscribe to the notion that
> > the information provider should have automatic control over that
> > element.
>
> Clearly this needs to happen, but if they're just plug-ins with freedom to
> implement UIs any old way, then we might lose the Web's primary value
> (IMO), which is standard, cross-platform UI.
Hmm... I don't agree. The Web's primary value is indeed in a standard user
interface, and browser plug-ins would indeed by default change that user
interface. If designed well, they would change them in a uniform way - or
leave that change up to the browser to best implement, the same way HTML is
left up to the browser. Content providers might have need for different
options or capabilities to be built into the browser specifically for their
system, obviating the need for separate "Mosaic customized for l10n", "Mosaic
with fish search", "Mosaic supporting mailto: URLs". That's all I'm
talking about here. Some people might even sell plug-ins that talk a
proprietary protocol to their server for something - a modular browser is
really the only way that business model could float.
On the subject of plug-ins - any word from NCSA (or spyglass) as to the
status of XMosaic 2.5 and the forthcoming plug-in scheme?
Brian
p.s. - Mozilla ROCKS.