Dan Connolly wrote:
> I just had a discussion with Dave Raggett about this... <FIG> is
> meant to compliment, not replace, <IMG>. There's a lot of history
> behind the current spec. Some of it is technical, but some of it
> is political stuff that I won't go into.
This is somewhat unfortunate. But i can accept that <img> and <fig>
have different purposes, sure.
Mike Meyer wrote:
> IMG is meant for "inline" graphics, in the sense that they go in the
> line of text.
[...]
> FIG is meant for graphics that are not part of a text block (which is
> why they aren't allowed in a <P>), but stand alone. Since there are no
> documents to break by doing it right, it can be done right. This means
> you get captions, client-side image maps, and such goodies as well.
Dan Connolly wrote:
> Suffice it to say that HTML 3.0, like many other markup languages,
> includes two idioms for graphics: the <img> element for phrase-level
> stuff, like little funny characters or inline icons (or inline
> math formulas or ...) and <fig> for "displayed formulas" or graphic
> callouts or ... .
Understood. But this doesn't mean that functionality should be
*removed* from FIG. It just seems very strange to me that this extra
limitation exist, purely as a limitation that to me yields no observable
advantage. I'm very optimistic about FIG "being done right" -- which
makes me especially wary when i hear that functionality is being
designed away that we might otherwise have at no loss at all.
Clearly <p><fig...></fig> can achieve separation of a figure if this
is desired. Moreover by separating the <p> it becomes slightly easier
to see breaks in a train of thought.
Correct me if this is irrational, but my impression of the purpose of
<fig> is to provide an alternate-media representation in order to enhance
the communication of a concept -- which might be associated with text
describing or referring to that concept, or which might be completely
independent of text. It seems the former is much more likely, though
both of these uses are still distinctly different from the "inline" idea.
I'd imagine that the actual positioning of a <fig> element is not the
key piece of information, so that browsers could be considered
conformant whether they render a <fig> before, after, or wrapped by the
paragraph within which it appears. I could even see a browser replacing
figures with references, then attaching a list of figures after the text.
But this does not mean we should remove the ability of an author to
*suggest* where a <fig> can appear.
With a slight alteration -- say, the addition of the ID attribute, you
might have
<p>The bond angle between the two oxygen-hydrogen
bonds in water is slightly larger than that
between two carbon-hydrogen bonds in methane
(<fig src="molecules.jpg" id="1" align="right">
figure 1 shows models of CO2 and H2O molecules
</fig>). This is due to the two extra pairs of
free electrons around the oxygen atom, which
take up more space than the bound pairs.</p>
which might appear rendered as
The bond angle between the two oxygen-hydrogen
bonds in water is slightly larger than that
between two carbon-hydrogen bonds in methane
(see figure 1). .---------------------------.
This is due to | |
the two extra | |
pairs of free | |
electrons around | |
the oxygen atom, `----------------figure 1---'
which take up more space than the bound pairs.
Or the alternate text "figure 1 shows models of CO2 and H2O molecules"
could appear in the parentheses as a link to download the image.
My point is that it often makes more sense for a figure to relate to
the text (not the same as being incorporated into the text like an IMG)
than to stand on its own.
Ping (Ka-Ping Yee): 2B Computer Engineering, University of Waterloo, Canada
[email protected] | 62A Churchill St, Waterloo N2L 2X2, 519 886-3947
CWSF 89, 90, 92; LIYSF 90, 91; Shad Valley 92; DOE 93; IMO 91, 93; ACMIPC 94
:: Skuld :: Tendou Akane :: Belldandy :: Ayukawa Madoka :: Hayakawa Moemi ::
New! <http://csclub.uwaterloo.ca/u/kryee/> Yeah, i finally made a home page.