Scalable figures with captions: supporting traditional typography

Robert J. O'Hara

For some time I've struggled with the problem of displaying simple
captioned figures on webpages in a way that is robust and scalable. I
tend to make "boring" (um, I mean "conservatively elegant") pages that
are text-heavy and that resemble academic publications. Despite the
origin of HTML in the world of scientific communication, the absence
of a FIGURE element to serve as a counterpart to the TABLE element is
surprising. This topic has been discussed in c.i.w.a.s before; if you
search the group for "figures and captions" you'll find some earlier
threads.

I had been working on a table-based approach, but for now have given
up on that because of inheritance inconsistencies across browsers. I
am now experimenting with a div-based approach which so far is working
well, at least for simple single-image figures. My experiments are
based on an earlier proposal for captioned figures by Bert Bos; I've
tried to extend his work by adding a few new features. My
demonstration page is here:

http://rjohara.net/server/css-figures-captions/

If you have an interest in captioned figures and/or traditional
typography take a look and see if you can identify any problems with
the page. An important feature of these figures is that they are
scalable: if the page author specifies that the figure should be 50%
of the width of the textblock, it should stay that way even when the
viewport dimensions change or the font size changes.

One weakness of the approach shown on this page is that it makes
considerable use of the max-width property, which is not supported on
the most common browsers today (IE5&6). The figures don't break under
these browsers, but if an author uses an image with small intrinsic
dimensions it may over-scale when the viewport is wide.

Bob O'Hara (http://rjohara.net)

Jul 20 '05 #1

Chris Beall

Robert J. O'Hara wrote:

If you have an interest in captioned figures and/or traditional
typography take a look and see if you can identify any problems with
the page.

Robert,

I looked at the page with IE 5.5 and NN 7.1 maximized on a 600 X 800 screen.

I recommend adding min-width to the images. On both browsers when I
narrowed the screen to cell-phone size, the smaller images went to 1
pixel and then vanished. The min-width should be expressed in ems and be
equal to the longest word in the caption/legend, to avoid text flopping
outside the figure border (which will also happen on a 'medium' sized
screen at very large text sizes).

This will limit, at the extremes, the extent to which you can retain
your 'optimum' proportion of text and image space across the page width,
but you've already accepted that limitation with regard to the maximum
useful size for an image, so the trauma should be minimal.

See http://pages.prodigy.net/chris_beall/sandbox/index.html. Each
navigation image has a caption (button). As the screen size is reduced,
the image will reduce UNTIL THE BUTTON SIZE IS REACHED, but no further.
(When that limit is reached, the 'figures' spill gradually from a
horizontal layout to a vertical one).

I did some experiments on image scaling and concluded that an image can
be scaled to 2X its 'natural' size without annoying pixellation. So I
recommend that you try to guess the size of the largest window any user
will employ and process the natural image to be about half that size.

Others will caution you that browsers, unlike image-specific tools like
PhotoShop, do not do a great job of scaling images, even to smaller than
'natural' sizes. You must be content to accept this if you use this
technique.

On NN 7.1 I tried changing the text size. The 4th image (fall leaves)
did not seem to scale with the text reduced to 50% or enlarged to 200%.

Chris Beall

Jul 20 '05 #2

Spartanicus

Crossposted and follow up set to ciwah, as this has nothing to do with
css.

rj*****@post.harvard.edu (Robert J. O'Hara) wrote:

Despite the
origin of HTML in the world of scientific communication, the absence
of a FIGURE element to serve as a counterpart to the TABLE element is
surprising.
What do captioned images have to do with tables?

Html does not need an element to associate an image and it's caption,
see below.
I had been working on a table-based approach, but for now have given
up on that because of inheritance inconsistencies across browsers.
An image and a caption do not constitute tabular data. The textual
replacement of the image and it's caption should form a single sentence.
Thus there is no need for an html element to group/associate the image
and it's caption, they are one.
I am now experimenting with a div-based approach which so far is working
well, at least for simple single-image figures.
I also consider div's the wrong type of markup. An image with it's
caption should be marked up as a paragraph, if the caption is beneath
the image then the image's alt content should be specified as a prefix
to the caption:

<p><img src="butterfly.jpg" alt="Picture of" title=""><br>A
butterfly</p>

Using a div instead of a paragraph makes it difficult for users to
associate the right image with the right caption when there are a number
of captioned images in sequence (e.g. image galleries).
http://rjohara.net/server/css-figures-captions/

If you have an interest in captioned figures and/or traditional
typography take a look and see if you can identify any problems with
the page. An important feature of these figures is that they are
scalable: if the page author specifies that the figure should be 50%
of the width of the textblock, it should stay that way even when the
viewport dimensions change or the font size changes.

There are a number of reasons why you should not specify anything other
than the intrinsic dimensions of an image in html:

A) Browsers do a poor job when scaling images.
B) One reason for specifying an image's dimension in the html is that
browsers should be able to layout a page before the images have finished
downloading, percentage scaling not only thwarts that, it adds to the
problem by requiring that the entire page including *all* it's
dependencies are downloaded. This is unacceptable.
C) Using oversized images to enable the "scaling" causes the download
times of the content to increase significantly, your demo page is a good
example of that, it loads far slower than it needs to.

--
Spartanicus

Jul 20 '05 #3

Robert J. O'Hara

Chris Beall <Ch*********@prodigy.net> wrote:

I recommend adding min-width to the images. On both browsers when I
narrowed the screen to cell-phone size, the smaller images went to 1
pixel and then vanished. The min-width should be expressed in ems and be
equal to the longest word in the caption/legend, to avoid text flopping
outside the figure border (which will also happen on a 'medium' sized
screen at very large text sizes).
A very good idea. I have no direct experience with hand-held browsers,
but on principle this would seem to be appropriate. It could also be
something made specifically to apply under a "handheld" media type (if
that is supported on the tiny browsers).
See http://pages.prodigy.net/chris_beall/sandbox/index.html. Each
navigation image has a caption (button). As the screen size is reduced,
the image will reduce UNTIL THE BUTTON SIZE IS REACHED, but no further.
A nice example.
On NN 7.1 I tried changing the text size. The 4th image (fall leaves)
did not seem to scale with the text reduced to 50% or enlarged to 200%.

Don't have NN7 and haven't been able to reproduce that one. I'll keep
checking. I did find an IE6 display bug: when the window is very wide
the full-width figure collides with the right column and is pushed
down. This appears to be some species of box model bug in IE6; it can
be worked around, but inelegantly. It is not relevent to the specific
scaling problem, however.

RJO

Jul 20 '05 #4

Chris Beall

Spartanicus wrote:

Crossposted and follow up set to ciwah, as this has nothing to do with
css.

Translation for the original poster, who seems not to have made the jump:

Spartanicus's response was also posted to
comp.infosystems.www.authoring.html, where there has been considerable
additional discussion of the HTML implications related to your original
post. You might want to take a look there.

Chris Beall

Jul 20 '05 #5

Robert J. O'Hara

Chris Beall wrote...

Spartanicus wrote:

> Crossposted and follow up set to ciwah, as this has nothing to do with
> css.

Translation for the original poster, who seems not to have made the jump:

Spartanicus's response...

I always try not to feed the trolls. :-)

If you search ciwas in Google groups for "figures and captions" you'll
find a thorough discussion from 2002 that covered many of the markup
aspects of the captioned figure question.

RJO

Jul 20 '05 #6