Re: No IMG in FIG

Mike Batchelor (
Fri, 4 Aug 1995 08:54:57 -0400 (EDT)

From: Mike Batchelor <>
Message-Id: <>
Subject: Re: No IMG in FIG
Date: Fri, 4 Aug 1995 08:54:57 -0400 (EDT)
In-Reply-To: <> from "Michael Johnson" at Aug 4, 95 07:40:47 am

Michael Johnson once wrote...
> Ping wrote:
> >The rest of my message concerning <FIG> content proposes that the content
> >of FIG be treated as HTML to be rendered as a figure when SRC is not
> >specified.  This is aimed at increasing orthogonality.
> >
> >How do you feel about this?
> I'm not quite sure what you mean by "rendered as a figure". The intent of FIG
> content now is that it should be rendered in place of the SRC when the latter
> is unavailable. I guess it would not hurt to expand this notion to allow the
> SRC to be omitted entirely so that the content is always rendered.
> When you say "rendered as a figure" though what exactly do you mean? I have
> been thinking about the idea of paying attention to the width attribute when
> I render the content of a FIG, falling back on normal processing if WIDTH is
> not specified. I would then flow text around the formatted content. Is this
> the sort of behavior that you mean?

That's what I would like to see.  A <fig> with a SRC represents
some item that is not part of the text flow, but should be set aside,
perhaps enclosed within a box, and have the surrounding text flow around
it.  I don't see why this should change if the <fig> doesn't have a SRC. 
The <fig> then contains textual data that is separate from the surrounding
text flow.  And that textual data could certainly contain <img>.  Here's
an example of how this would be useful:

<fig align=right width=40en height=10en>
<caption>We have two versions for you!</caption>
<li><img src="html2.gif">Select this for <a href="index.html">HTML v2</a>.
<li><img src="html3.gif">Select this for <a href="index.html3">HTML v3</a>.
<h1>Welcome to XYZ Inc.'s Web site</h1>
We are pleased to offer, blah blah blah blah
Contact us at
<address> blah blah blah</address>

(and so on).

This would then have the short list with caption aligned to the right
margin, and the following <h1> and paragraph would flow around it.

I suppose the same effect could be achieved using a borderless table with
headings, but sometimes, a table isn't appropriate, but a figure is.

> Someone who wants to write simple pages doesn't have to use the extra new tags.
> But people who want to write documents that can be searched by a sophisticated
> search engine need the power of these tags.
> Some have proposed using the CLASS attribute of EM to replace those tags. My
> opinion is that this is an abuse of the CLASS attribute. I infer from the
> IETF draft and comments in the DTD that CLASS exists purely to allow elements
> to be subclassed for the purposes of presentation. I do not think that Dave
> intended CLASS to be used to dynamically define new semantic markup, nor do I
> think it would be a good idea to use it for this.

Oh but that's *exactly* what class is for!  It extends HTML in the same
sort of way that classes extend C++.  Why shouldn't HTML authors be able
to declare new classes, too?  Style sheets are merely one application of
the class attribute.  There are potentially hundreds more.  Imagine a
robot that combs the web for new class attributes, and uses them to build
a thesaurus of classes that is referenced by other indexing robots, to
improve the quality of the indexing.  The possibilities are endless.

   %%%%%% %%%%%% %%%%%%