Re: No IMG in FIG

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

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>
<ul>
<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>.
</ul>
</fig>
<h1>Welcome to XYZ Inc.'s Web site</h1>
We are pleased to offer, blah blah blah blah
<p>
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.

-- 
   %%%%%% [email protected] %%%%%% http://www.clark.net/pub/mikebat/ %%%%%%