E-mail List Archives
Re: Graphics and Captions
From: Kynn Bartlett
Date: Jan 21, 2006 10:30AM
- Next message: Karl Dawson: "This week's article: Content Language"
- Previous message: Jukka K. Korpela: "Re: Graphics and Captions"
- Next message in Thread: None
- Previous message in Thread: Jukka K. Korpela: "Re: Graphics and Captions"
- View all messages in this Thread
On 1/21/06, Jukka K. Korpela < <EMAIL REMOVED> > wrote:
> But you could use a simple table, putting an image inside a cell and the
> caption inside another, or even a single-cell table with the caption
> inside a <caption> element. This is a little trickery, but before
> rejecting it as using "tables for layout" (it actually isn't), consider
> the other options: they mean using _semantically empty_ (or perhaps even
> semantically wrong) markup, as opposite to table markup that is at least
> vaguely semantic: <table> markup indicates some relationships between
> data.
True. This is a perfectly sensible thing to do as well, and should be
considered added to the list of wacky alternatives I gave!
> A containing element is useful (and perhaps indispensable) for styling
> (and for compliance to a Strict DTD), but it implies nothing semantically,
> apart from creating a block. There's probably not much practical
> difference between using a <div> and using a <table> for an image and its
> caption, except that they require a bit different approaches in styling.
Agreed again. You at least should group them together, but it is no
substitute for having reasonable markup that identifies explicitly
when something is a caption. We don't have that, sadly. :(
> But using <p> for a caption is usually illogical - the caption does not
> usually constitute a _paragraph_ - and creates unnecessary (though small)
> problems in styling. A <p> element normally has default top and bottom
> margin, and may have some presentational idiosyncracies due to a user
> style sheet, and all of this is probably unwanted here. Using <div>
> would be preferable to _semantically wrong_ markup.
Well, it depends on the caption. :)
> The longdesc attribute is futile or worse. You spend time in setting it
> up, gaining virtually nothing, and you easily forget to make the long
> description _accessible_ in most browsing situations (that is, on all
> browsers not supporting longdesc, i.e. on almost all browsers).
Yeah, sadly, longdesc is one of those "gosh, isn't this a good idea"
half-broken concepts.
- Next message: Karl Dawson: "This week's article: Content Language"
- Previous message: Jukka K. Korpela: "Re: Graphics and Captions"
- Next message in Thread: None
- Previous message in Thread: Jukka K. Korpela: "Re: Graphics and Captions"
- View all messages in this Thread