Re: IMG and FIG? -Reply

R J Partington writes:
> 
> 
> Presumably this would be like IMG handling now though ie it's not
> downloaded automatically if you don't want it - similar to turning
> image loading off. 

One would hope. Next-generation dynamic browsers like HotJava should be
far more configurable than the Mosaic/Netscape bloated monolithic legacy
programs. :) But anyway, yeah, hopefully there'd be optional EMBED
loading.

> What if the browser can't, and you don't have helper apps that can,
> but you do have access to a machine that can? As above, if it's handled
> like IMG (say [EMBEDDED mpg] for lynx), then that's ok by me.
> 
> If it's going to be another reason for lynx users to be restricted, then
> I'm dead against it.

I suggested support for EMBED and Fote added primitive EMBED support
which works pretty much like IMG support. It's in the latest 2.4-FM
builds, from about two days ago.

> > > 4) still images have been with us since the dawn
> > > of history, so it only makes sense to have a 
> > > specialized tag for them with a rich set of 
> > > corresponding attributes.
> > 
> > Those attributes should be moved to some sort of style mechanism, in any
> > case.
> 
> Huh? You mean treat still images as a special case of an embedded thing?
> Or as a special case of a moving image?

Actually, what I meant was that things like VSPACE, HSPACE, WIDTH, etc
should be moved to style sheets. Most of the presentational stuff which
has been layered onto HTML in a very hacked manner is never
adequate. Moving into style sheets allows the presentation to be
abstracted from the structure, allowing finer control over each.

But yeah, still images should be special cases of embedded things.

> > It's kinda sad, since most of the docs would be more readable much more
> > quickly in HTML. But Acrobat is a far superior format to HTML for many
> > things. *shrug*
> 
> Except if you're
> a) using Linux
> b) using an Amiga
> c) using an Acorn Archimedes
> 
> And guess what? I use all three. Can I view PDF files? Nope. So, in what
> sense are they `far superior' than HTML _for me_ if I can't even view them?

I agree, if you want to get information across, use HTML. I use Lynx for
about 90% of my web stuff, and Netscape for the rest; I have a borrowed
286 at home and a 14.4k modem. But Acrobat still whoops HTML in terms of
a presentational display. For advertizing and some technical documents,
this is much better than bastardizing HTML. 

With your Amiga, you can view PostScript files. With my borrowed 286, I
can't. But a PS file is still hands down the winner for page description
languages, and there are tons of documents for which anything but a PS
version would be somewhat silly; or at the very least, impractical to
produce.

Anywho, this is leading away from the point.

> > I agree that using the wrong medium for a message is wrong. But I don't
> > think EMBED will encourage it at all. Conversely, since EMBED relies on
> > media types and not Netscape-like plugins, and media handlers tend to be
> > more portable than full apps or plugins, EMBED could make life a lot
> > cleaner.
> 
> If you have a `supported' system. Kinda makes a mockery of the _World-Wide_
> bit of the WWW.

Re-read what I said. "media types and not Netscape-like plugins". You've
got an Amiga; the Amiga Mosaic has been doing inline MPEGs for a year or
so, if I remember correctly. With EMBED, if someone can write a handler
for media types, and it can be ported to your platform, you're set.

I guess I should make that clearer. I think EMBED will foster more use
of open and widely used media types (MPEG, Quicktime, etc) rather than
proprietary types (Shockwave video, say). Most platforms have support
for most common media types.

>  <EMBED SRC="graph001.gif" CLASS="FIGURE">
>  
> In which case, why not make <FIG> a special class of <EMBED> (like
> <BANNER> is of <DIV>)?

One of the current themes on the WG is "small is better". If FIG is
gonna be a special case of EMBED, just use EMBED and add the required
functionality. I suspect BANNER might not make it to the eventual
HTML3-final for similar reasons.

> FIG has a decent MAP though. 

I agree that it's superior to the MAP proposal. Unfortunately, it looks
like that doesn't matter to the browser manufacturers. :( 

>And how is lynx supposed to handle a
> table-based overlay mechanism when it doesn't fully handle tables?

Erm... how can Lynx handle graphical overlays anyway? Lynx handles
tables, parser wise; it is just that the display engine can't render
them properly at the moment, and it's gonna be a hell of a lot of work
on the part of volunteers like Foteos to get it done.

Joshua
--
                ___.----~~~----.___  | MIME: jsbell@acs.ucalgary.ca
 ,--------.-.,-'-------------------` | WWW:  http://www.ucalgary.ca/~jsbell/
 `--------"-'-.,---`~~~-----~~~'
  '---'-._____/

Received on Saturday, 16 December 1995 18:40:07 UTC