E-mail List Archives
Thread: Graphics and Captions
Number of posts in this thread: 17 (In chronological order)
From: Gill.Rawlings
Date: Fri, Jan 20 2006 9:45AM
Subject: Graphics and Captions
No previous message | Next message →
Hello,
I wonder if someone can help. We are trying to decide how to use captions
with graphics, and I found a thread on the forum from a while ago about
making sure that the caption was different to the ALT / TITLE to avoid
duplication. My question is this: is there specific html for displaying
captions (similar to <blockquote>)? The caption="" attribute is only for
use within the table element, I believe, and we're phasing out tables
unless they're for tabular data. So should I be defining a class in the
CSS or redefining an existing html tag? I would be grateful for advice, as
most stuff on the web is dealing specifically with 'captioning' video.
Thanks
Gill
From: Kynn Bartlett
Date: Fri, Jan 20 2006 1:15PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
On 1/20/06, = EMAIL ADDRESS REMOVED =
> My question is this: is there specific html for displaying
> captions (similar to <blockquote>)?
Not really, unfortunately.
> So should I be defining a class in the CSS or
> redefining an existing html tag?
For now -- lacking appropriate markup (HTML is too limited at present)
-- you should at least make sure they're grouped together within at
least one containing element, as this provides markup-level context:
<div class="imageandcaption">
<img src="foo.gif" alt="alt for foo">
<p class="caption">Caption for foo</p>
</div>
Now, there are a few alternatives you could use, but of course, none
of them are really "right."
If it's an image lacking a longdesc, and the caption itself is
sufficiently detailed (most captions are NOT) to be a longdesc:
<div class="imageandcaption">
<img src="foo.gif" alt="alt for foo" longdesc="#foocaption">
<p class="caption" id="foocaption">Caption for foo</p>
</div>
If browsers were magic, or if someone in the far future is as clever
as me, you can use <a> links:
<div class="imageandcaption">
<a id="fooimage" link="#foocaption" rel="caption">
<img src="foo.gif" alt="alt for foo">
</a>
<a id="foocaption" link="#fooimage" rev="caption" class="caption">
<p>Caption for Foo</p>
</a>
</div>
Of course, this has the nice effect of NOT WORKING IN ANY BROWSERS,
because I just made it up. So don't do this.
Even more snazzy is mixing in XLink and XPath into your XHTML. Again,
ha ha, doesn't work.
And although it's tempting, DON'T do this:
<div class="imageandcaption">
<img src="foo.gif" alt="Alt for foo" id="fooimage">
<label for="fooimage">
<p class="caption">Caption for Foo</p>
</label>
</div>
It's how HTML really should work, except it doesn't -- and this would
be an abuse of the <label> element, and it doesn't do anything for you
anyway. (<label> is only for form elements.)
So, your answer really is: Ignore everything I wrote here except my
first two paragraphs, where the answers were "(a) no, there's not any
appropriate markup, and (b) the best you can do is group them together
logically as sibling elements in a <div>."
Hope this helps some.
Oh, one last note: Do go ahead and use a class, as I've done above,
to STYLE your captions to look like whatever you want captions to look
like. Do NOT, however, assume that the use of an arbitrary class,
even one with a name like "caption" or "imageandcaption", is imparting
any sort of significant SEMANTIC or SYNTACTIC meaning when you use it.
It's not. The class attribute should be considered as presentational
markup and not used to convey anything beyond appearance.
--Kynn
From: Patrick H. Lauke
Date: Fri, Jan 20 2006 1:30PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
Kynn Bartlett wrote:
> If it's an image lacking a longdesc, and the caption itself is
> sufficiently detailed (most captions are NOT) to be a longdesc:
>
> <div class="imageandcaption">
> <img src="foo.gif" alt="alt for foo" longdesc="#foocaption">
> <p class="caption" id="foocaption">Caption for foo</p>
> </div>
To play a bit of devil's advocate, though: does that serve a real
purpose, in terms of how users would interact with the image? Or is it
just semantic pedantry?
--
Patrick H. Lauke
___________
re
From: Kynn Bartlett
Date: Fri, Jan 20 2006 2:00PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
On 1/20/06, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> To play a bit of devil's advocate, though: does that serve a real
> purpose, in terms of how users would interact with the image? Or is it
> just semantic pedantry?
Mostly semantic pedantry. As I said before, there's no viable HTML
elements for supporting captions for images, and other forms of
parallel/alternative/label/non-replacement text, so of course browsers
don't do anything useful for users.
However, there's some point in labeling an explicit longdesc
equivalent as such, even if it appears on the same page; it would
allow a user to theoretically be made aware that they're not missing
out on information. So there's a marginal value in using an anchored
longdesc.
For example, a few times I've posted a picture which is followed by a
short blurb describing the picture, such as you can get from Yahoo!
News on their images page.
I post the image first, and then a longdesc url like "#thisimagedesc"
to the text immediately following. It doesn't hurt much, and it also
makes it explicit that the text following /is/ descriptive, and also
doesn't leave it up in the air as to whether there's a longer
description out there. There's not, beyond what I just provided.
Here's an example, chosen at semi-random. It's a basketball picture:
http://news.yahoo.com/news?tmpl=story&u=/060120/483/azwl10101200456
"Stanford's Mitch Johnson (1) tries to shoot over Arizona's Marcus
Williams (3) and J.P. Prince during the first half of a college
basketball game in Tucson, Ariz., Thursday, Jan. 19, 2006. (AP Photo/
Wily Low)"
I'd deem, for most purposes (not necessarily all purposes) that the
caption is sufficient for a basic longdesc. Remember that alt text,
longdesc, captions, and other parallel/alternative content is very
much purpose-dependent and is based on what the goal of the image is
in the first place. But if I just wanted to put the picture up, say
on my LiveJournal, this would probably do for a longdesc. (Followed
by written text and commentary about why I chose it, naturally, which
isn't part of the longdesc.)
If I were going to comment on the apparent racial diversity of the
teams playing, on the colors of the uniforms, or on something visible
in the crowd behind, I'd need a more detailed longdesc. But I'd
probably also make it the caption, as captions are often times (but
not ALWAYS, don't get me wrong) functionally equivalent to "inline
longdescs."
--Kynn
From: Stephanie Leary
Date: Fri, Jan 20 2006 4:00PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
Patrick H. Lauke wrote:
> To play a bit of devil's advocate, though: does that serve a real
> purpose, in terms of how users would interact with the image? Or is it
> just semantic pedantry?
Mostly semantic, but I backed into doing it this way because the surrounding
div gives me more to work with when I start styling things.
--
Stephanie Leary
Texas A&M University System
Office of Communications
= EMAIL ADDRESS REMOVED =
From: Derek Featherstone
Date: Fri, Jan 20 2006 5:15PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
On 1/20/06, Kynn Bartlett wrote:
>Oh, one last note: Do go ahead and use a class, as I've done above,
>to STYLE your captions to look like whatever you want captions to look
>like. Do NOT, however, assume that the use of an arbitrary class,
>even one with a name like "caption" or "imageandcaption", is imparting
>any sort of significant SEMANTIC or SYNTACTIC meaning when you use it.
> It's not. The class attribute should be considered as presentational
>markup and not used to convey anything beyond appearance.
It is true that the most popular use for the class attribute happens to
be for style sheet hooks. However, there is *nothing* that says that is
all it can be used for.
"The class attribute... assigns one or more class names to an element;
the element may be said to belong to these classes. A class name may be
shared by several element instances. The class attribute has several
roles in HTML:
* As a style sheet selector (when an author wishes to assign style
information to a set of elements).
* For general purpose processing by user agents."
Source: <http://www.w3.org/TR/html4/struct/global.html#adef-class>
I'm not saying that we should assume that there is any semantic meaning
behind class names - currently there isn't a lot save for the work being
done with microformats. There is nothing saying that we can't establish
some and use the class attribute for things beyond presentational hooks.
And doing so might actually be a way to enhance the accessibility of the
web sites and applications we build.
I do agree that we need a richer set of elements than what is currently
available to us in HTML, but why wait?
Cheers,
Derek.
--
Derek Featherstone = EMAIL ADDRESS REMOVED =
tel: 613-599-9784 1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal: http://www.boxofchocolates.ca
From: Kynn Bartlett
Date: Fri, Jan 20 2006 6:00PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
On 1/20/06, Derek Featherstone < = EMAIL ADDRESS REMOVED = > wrote:
> It is true that the most popular use for the class attribute happens to
> be for style sheet hooks. However, there is *nothing* that says that is
> all it can be used for.
It's the primary use for it.
> "The class attribute... assigns one or more class names to an element;
> the element may be said to belong to these classes. A class name may be
> shared by several element instances. The class attribute has several
> roles in HTML:
>
> * As a style sheet selector (when an author wishes to assign style
> information to a set of elements).
> * For general purpose processing by user agents."
> Source: <http://www.w3.org/TR/html4/struct/global.html#adef-class>
There are no other "general purpose processing" functions defined.
> I'm not saying that we should assume that there is any semantic meaning
> behind class names - currently there isn't a lot save for the work being
> done with microformats. There is nothing saying that we can't establish
> some and use the class attribute for things beyond presentational hooks.
Except they're not established, and besides, doing so will simply mix
presentational markup with semantic markup, and we'll be back to the
original problem we had in the first place.
> And doing so might actually be a way to enhance the accessibility of the
> web sites and applications we build.
How? Any potential benefits of trying to convey content semantics via
class is dubious and doomed to failure, when the real solution is to
expand the actual semantic markup.
Sure, you could also use the style attribute for something other than
just presentation, but that's a bad idea for the same reason. Classes
are defined in the spec to be "presentational, PLUS MAYBE something
else."
We so totally don't want to go down that path toward "something else."
Wrong route entirely.
> I do agree that we need a richer set of elements than what is currently
> available to us in HTML, but why wait?
Because recent history teaches us that trying to misuse presentational
and/or semantic markup as each other only leads to headaches.
--Kynn
From: Patrick H. Lauke
Date: Fri, Jan 20 2006 7:30PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
Kynn Bartlett wrote:
>> * As a style sheet selector (when an author wishes to assign style
>> information to a set of elements).
>> * For general purpose processing by user agents."
>> Source: <http://www.w3.org/TR/html4/struct/global.html#adef-class>
>
> There are no other "general purpose processing" functions defined.
So they can be user agent, or even site specific.
>> I'm not saying that we should assume that there is any semantic meaning
>> behind class names - currently there isn't a lot save for the work being
>> done with microformats. There is nothing saying that we can't establish
>> some and use the class attribute for things beyond presentational hooks.
>
> Except they're not established, and besides, doing so will simply mix
> presentational markup with semantic markup, and we'll be back to the
> original problem we had in the first place.
No, it will not mix presentational markup with semantic markup because
class attributes are not presentational to begin with. Yes, as you noted
the primary use of class names is to later use them as selectors to
define presentation, but class names themselves are not presentational
(unless of course you use misguided class names like "bold" or "red")
>> And doing so might actually be a way to enhance the accessibility of the
>> web sites and applications we build.
>
> How? Any potential benefits of trying to convey content semantics via
> class is dubious and doomed to failure, when the real solution is to
> expand the actual semantic markup.
I would say that I can't see microformats directly benefitting
accessibility (as in a user agent making direct use of them)...but, when
combined with tools such as transformers which go through a page looking
specifically for microformat information and reformatting it
(server-side...or maybe even client side) to adapt to user preferences
they can be a good thing from both a usability and accessibility point
of view.
> Sure, you could also use the style attribute for something other than
> just presentation, but that's a bad idea for the same reason. Classes
> are defined in the spec to be "presentational, PLUS MAYBE something
> else."
And here we are now, working on examples for this "PLUS" that are viable
*today*, with current technology...not once we have our jetpacks and
enjoy XHTML2.0+
> We so totally don't want to go down that path toward "something else."
> Wrong route entirely.
I don't see it as a route into the far future...but it's a stopgap
solution until extensible markup is consistently supported even in IE
and there are no backwards compatibility worries anymore (IMHO, anyway).
> Because recent history teaches us that trying to misuse presentational
> and/or semantic markup as each other only leads to headaches.
But again, class names (and id) are not inherently presentational. Their
common application is to use them to apply presentation in a subsequent
step. They can quite happily carry meaning, though that meaning may not
be universally understood by all user agents (in which case no harm is
done, as it's still within spec) but only by specific server- or
client-side processing tools.
--
Patrick H. Lauke
___________
re
From: Kynn Bartlett
Date: Fri, Jan 20 2006 7:45PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
By the way, I think "microformats" based *on the class attribute* are
the stupidest thing to happen during the time I was away from web
standards.
Well, okay, maybe not THE stupidest.
But one of the stupider ones I've found so far.
Way for people who should know better to break the Web again, because
doing things the right way is too hard.
--Kynn
From: Kynn Bartlett
Date: Fri, Jan 20 2006 8:00PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
On 1/20/06, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> Kynn Bartlett wrote:
> > There are no other "general purpose processing" functions defined.
> So they can be user agent, or even site specific.
Which is an awful, horrible can of worms which isn't even really worth
considering. I mean, embedding semantics into classes on a user-agent
or site-specific basis? Why?
> No, it will not mix presentational markup with semantic markup because
> class attributes are not presentational to begin with. Yes, as you noted
> the primary use of class names is to later use them as selectors to
> define presentation, but class names themselves are not presentational
> (unless of course you use misguided class names like "bold" or "red")
The primary, and only valid use, of class is for creating selectors
for applying styles. This has nothing to do with class naming
practices and everything to do with what it's used for.
Class is acceptable presentational markup. It's the glue that allows
us to "separate presentation from content" in a consistent manner.
But that glue shouldn't be used to impart extra meaning beyond
presentation; doing so in an attempt to compensate for HTML's
deficiencies doesn't help any.
> I would say that I can't see microformats directly benefitting
> accessibility (as in a user agent making direct use of them)...but, when
> combined with tools such as transformers which go through a page looking
> specifically for microformat information and reformatting it
> (server-side...or maybe even client side) to adapt to user preferences
> they can be a good thing from both a usability and accessibility point
> of view.
But, again, that's trying to encode semantic meaning into class, which
is a bad idea. This can be accomplished through other means in some
cases, and in those cases where it can't, it's a bad idea to try to
force the issue.
> And here we are now, working on examples for this "PLUS" that are viable
> *today*, with current technology...not once we have our jetpacks and
> enjoy XHTML2.0+
In both cases you're talking about extending beyond the standard. I
would rather extend in a manner that makes sense, rather than just
trying to patch together something that will have to be torn down
again in the future as harmful.
> I don't see it as a route into the far future...but it's a stopgap
> solution until extensible markup is consistently supported even in IE
> and there are no backwards compatibility worries anymore (IMHO, anyway).
That's not going to happen any time soon, but I don't think the
solution is just to start coming up with clever tweaks that mix
together presentational cues (class) with structured content.
> But again, class names (and id) are not inherently presentational. Their
> common application is to use them to apply presentation in a subsequent
> step. They can quite happily carry meaning, though that meaning may not
> be universally understood by all user agents (in which case no harm is
> done, as it's still within spec) but only by specific server- or
> client-side processing tools.
ID is, of course, a different thing, which is why I'm not talking
about ID. I'm not entirely sure why you're trying to mix ID into this
discussion, except perhaps to obfuscate the point.
Class names can't and shouldn't carry meaning, no more than meaning
should be conveyed only by the color of text: Doing so is harmful to
accessibility and harmful to the development of a rich markup
language. "After all," someone might say. "Why do we need to be able
to identify a caption, if you can just do class="caption" and be done
with it?"
If your client-side or server-side processing tools are so
unsophisticated that they have to rely upon using the class attribute
instead of using proper markup, in this XML-friendly world, then you
need to develop better client-side and server-side processing tools.
--Kynn
From: Kynn Bartlett
Date: Fri, Jan 20 2006 8:15PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
On 1/20/06, Kynn Bartlett < = EMAIL ADDRESS REMOVED = > wrote:
> Well, okay, maybe not THE stupidest.
> But one of the stupider ones I've found so far.
I take it back already.
I've found something even more stupid.
The hijacking of the <abbr> element to provide not
abbreviation/acronym expansion, but instead machine-readable date
formats:
http://www.microformats.org/wiki/datetime-design-pattern
Here's an example of it in action, from:
http://www.microformats.org/wiki/abbr-design-pattern
BEFORE:
The party is at 10 o'clock on the 10th.
WITH STUPID MICROFORMAT IDEA:
The party is at
<abbr class="dtstart" title="20051010T10:10:10-0100">10 o'clock on the
10th</abbr>.
Gosh, I tell you, I'd really love, instead of hearing "10 o'clock on
the 10th" from a screenreader, to instead hear:
"twenty million fifty one thousand ten tee ten colon ten colon ten
dash oh one hundred." Or something like that. (Go on and argue that
screenreaders are required to translate title attribute values in
quasi-ISO 8601.)
Has anyone brought this up before? I've been away. But this kind of
stuff seems terribly harmful and quite worrysome. Embedding
machine-readable strings where human-readable accessibility
information is expected to reside? Wrong, just wrong.
--Kynn
From: Patrick H. Lauke
Date: Fri, Jan 20 2006 8:30PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
Kynn Bartlett wrote:
> Which is an awful, horrible can of worms which isn't even really worth
> considering. I mean, embedding semantics into classes on a user-agent
> or site-specific basis? Why?
To clarify: I'm not saying microformats are the best way of doing things
(versus, say, having links in the head of a document to some RDF or XML
file)...but I don't see them as the civilised web as we know it...
> The primary, and only valid use, of class is for creating selectors
> for applying styles.
Where did you get the "and only" from? Any spec that could corroborate this?
> Class is acceptable presentational markup. It's the glue that allows
> us to "separate presentation from content" in a consistent manner.
It's either the glue between markup and presentation, or it's
presentation in and of itself. The above is contradictory.
> In both cases you're talking about extending beyond the standard. I
> would rather extend in a manner that makes sense, rather than just
> trying to patch together something that will have to be torn down
> again in the future as harmful.
So a "sit and wait" approach rather than a "we accept it's only a
temporary solution".
> ID is, of course, a different thing, which is why I'm not talking
> about ID. I'm not entirely sure why you're trying to mix ID into this
> discussion, except perhaps to obfuscate the point.
I'm not attempting to obfuscate the issue, thank you very much. Could it
be that I mention them in the same breath because...oh....the spec does
as well?
7.5.2 Element identifiers: the id and class attributes
http://www.w3.org/TR/html4/struct/global.html#h-7.5.2
> "After all," someone might say. "Why do we need to be able
> to identify a caption, if you can just do class="caption" and be done
> with it?"
Because my idea of microformats would be to first use the most
appropriate method, within the boundaries of HTML, to achieve something
(getting back to the thread starter, wrapping the image and its caption
inside an element to denote that they somehow belong together in some
vague way), and then apply additional information that can be further
used by microformat-aware user agents / transformers / whatever (and
it's purely optional...we're not just relying on the software being able
to understand the microformat...if it doesn't, it's still getting our
best effort HTML).
> If your client-side or server-side processing tools are so
> unsophisticated that they have to rely upon using the class attribute
> instead of using proper markup, in this XML-friendly world, then you
> need to develop better client-side and server-side processing tools.
I personally favour XML as well. I think it's disconcerting though that
even Tim Bray makes a mention of microformats as a viable alternative
http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages
--
Patrick H. Lauke
___________
re
From: Patrick H. Lauke
Date: Fri, Jan 20 2006 8:45PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
Kynn Bartlett wrote:
> I've found something even more stupid.
Agree completely there.
> http://www.microformats.org/wiki/datetime-design-pattern
>
> Here's an example of it in action, from:
> http://www.microformats.org/wiki/abbr-design-pattern
The beauty of Wiki....edit away and enlighten the fools.
--
Patrick H. Lauke
___________
re
From: Patrick H. Lauke
Date: Fri, Jan 20 2006 9:00PM
Subject: Re: Graphics and Captions
← Previous message | Next message →
Patrick H. Lauke wrote:
> but I don't see them as the civilised web as we know it...
Hmmm...should have been "as the end of the civilised web as we know it..."
Obviously time for bed.
--
Patrick H. Lauke
___________
re
From: Jukka K. Korpela
Date: Sat, Jan 21 2006 1:45AM
Subject: Re: Graphics and Captions
← Previous message | Next message →
On Sat, 21 Jan 2006, Patrick H. Lauke wrote:
> The beauty of Wiki....edit away and enlighten the fools.
And see the fools edit it back, or worse.
It was quite OK to cite wikipedia for an example of what people might
actually do. Let's put a stop there.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Jukka K. Korpela
Date: Sat, Jan 21 2006 2:15AM
Subject: Re: Graphics and Captions
← Previous message | Next message →
On Fri, 20 Jan 2006, Kynn Bartlett wrote:
> On 1/20/06, = EMAIL ADDRESS REMOVED =
>> My question is this: is there specific html for displaying
>> captions (similar to <blockquote>)?
>
> Not really, unfortunately.
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.
> For now -- lacking appropriate markup (HTML is too limited at present)
> -- you should at least make sure they're grouped together within at
> least one containing element, as this provides markup-level context:
>
> <div class="imageandcaption">
> <img src="foo.gif" alt="alt for foo">
> <p class="caption">Caption for foo</p>
> </div>
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.
In practice, other considerations (such as ease of styling and the
rendering in the absence of styling) are more important, so <div> might be
just as good. But don't get lured into a mode of thinking where <table> is
bad just because you're not working with tabulated numbers.
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.
For accessibility, the roles of the caption and the alternate text (alt
attribute) are a difficult problem. The source of the problem is that the
caption will appear even when the image will not; this is one of the
shortcomings of the idea behind the alt attribute. This implies that if
you have a non-essential image (such as a photo in a news article, so that
the photo is just illustration and gives no new information), you should
use alt="" if there is no caption but something like alt="(photo)" if
there is a caption - otherwise the caption could create a mystery.
For some techniques, including a comparison of various markup methods, see
http://www.cs.tut.fi/~jkorpela/www/captions.html
> <img src="foo.gif" alt="alt for foo" longdesc="#foocaption">
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).
> Of course, this has the nice effect of NOT WORKING IN ANY BROWSERS,
> because I just made it up. So don't do this.
And don't even spend time in mentioning the longdesc attribute.
> So, your answer really is: Ignore everything I wrote here except my
> first two paragraphs, where the answers were "(a) no, there's not any
> appropriate markup, and (b) the best you can do is group them together
> logically as sibling elements in a <div>."
Nope. First, there is no really adequate markup, but you need to use some,
so you should consider what is least inadequate. Second, <div> is not
logical grouping; it is purely syntactic grouping (and presentational in
the sense that it implies line breaks).
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Kynn Bartlett
Date: Sat, Jan 21 2006 10:30AM
Subject: Re: Graphics and Captions
← Previous message | No next message
On 1/21/06, Jukka K. Korpela < = EMAIL ADDRESS 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.