image caption in xhtml

What is the best way to attach a caption to an image in xhtml?

I can attach a caption to a table by a "<caption>" tag
but I would like to do sth similar to an image.
How to do it in a natural way?


-tt.

Tomek Toczyski <guf (AT) kajak (DOT) org.pl> wrote:

What is the best way to attach a caption to an image in xhtml?

First, forget XHTML, for now at least.

I can attach a caption to a table by a "<caption>" tag
but I would like to do sth similar to an image.
How to do it in a natural way?

There is no natural way, since no HTML markup was designed for the purpose.
You could, for example, just put the caption into a <div> element after the
<img> element and use CSS to style it. For this and other options, see
http://www.cs.tut.fi/~jkorpela/www/captions.html

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Tomek Toczyski <guf (AT) kajak (DOT) org.pl> wrote:

What is the best way to attach a caption to an image in xhtml?

I'd recommend dropping the worse than useless XHTML silliness and use
HTML 4.01 Strict.

I can attach a caption to a table by a "<caption>" tag
but I would like to do sth similar to an image.
How to do it in a natural way?

Short answer: <p><img ... alt="Suitable alt content"><br>Caption</p>

Long answer:

There are 3 situations where image & caption markup matters: Search
Engine indexing, visual non CSS rendering and aural rendering.

From a SE perspective: if you search for images with the Google Image
Search service you'll notice that it finds images based on surrounding
textual content. It's commonly thought that Google ignores alt content
unless the image is linked, having looked at the images produced by a
Google Images Search I have concluded that this isn't correct. As with
other SE indexing methods, both how SEs treat alt content and how SEs
links surrounding textual content to an image is unknown and subject to
speculation based on empirical results. Unless you have a good reason to
prioritize SE indexing, I'd take the high road and ignore SE image &
caption indexing quirks and choose markup based on other factors.

Both from a visual rendering perspective in a non CSS situation and from
a theoretical aural rendering perspective wrapping the image and caption
in a paragraph element (as shown in the short answer above) is
appropriate. In a visual non CSS rendering situation the image and
caption can be expected to render adjacent whilst the combo will be
separate from other content. In aural rendering the image & caption
combo should be rendered with a leading and trailing pause.

From a practical aural rendering perspective:
Of the aural renderers that I'm familiar with only Opera renders image &
caption combos marked up as a paragraph with a leading and trailing
pause. Of the AT aural renderers my configuration* of IBM Homepage
Reader (3.04) renders it with no discernable pauses, Jaws (6) prefixes
the rendering of the alt content with "image", Jaws also renders with no
discernable leading or trailing pause. But due to it's "image" prefix
the result appears fairly logical.

* Whether or not alt content is rendered at all can be configured both
in HPR and Jaws.

--
Spartanicus

Spartanicus:

I'd recommend dropping the worse than useless XHTML silliness and use
HTML 4.01 Strict.

Why? What are the advantages of HTML4.01 over XHTML?

I like XHTML because it is more elegant and I think it will be more
reusable in the future.


------

Thank you and Yucca for your answers.

-tt.

Tomek Toczyski <guf (AT) kajak (DOT) org.pl> wrote:

I'd recommend dropping the worse than useless XHTML silliness and use
HTML 4.01 Strict.

Why? What are the advantages of HTML4.01 over XHTML?

I like XHTML because it is more elegant and I think it will be more
reusable in the future.

http://www.spartanicus.utvinternet.ie/no-xhtml.htm

--
Spartanicus

Once upon a time *Spartanicus* wrote:

Tomek Toczyski <guf (AT) kajak (DOT) org.pl> wrote:

I'd recommend dropping the worse than useless XHTML silliness and use
HTML 4.01 Strict.

Why? What are the advantages of HTML4.01 over XHTML?

I like XHTML because it is more elegant and I think it will be more
reusable in the future.

http://www.spartanicus.utvinternet.ie/no-xhtml.htm

I agree there is no benefit using XHTML over HTML 4.01 Strict. Making
"serious work" (e.g. sites for clients or your own business site) HTML
Strict is what should be used.

But I have a "site for fun" (testing and sutch) on the free space I
have on my ISP's server. There I have coded XHTML 1.1 "just for fun"
and to see how the pages acts, validates a.s.o. as text/html. And the
server is serving the pages as ISO-8859-1. From what I see there, I
have a couple of questions regarding what you say in the page above.

Serving XHTML Strict 1.0 as text/html
This is at best pointless, UAs will treat it as tag soup. You'll
kick IE and some versions of Opera into quirks mode if you add the
xml declaration on top of your documents as W3C recommends, omit the
xml declaration and the document can only use the default character
encodings UTF-8 or UTF-16.

I don't call valid code as "tag soap", not even in this "environment".
For me tag soup is not valid and depricated code only.

When I omitted the xml declaration from my XHTML pages nothing
happends (as I can see) to the content, despite the fact that the
pages is not served with UTF-8 or UTF-16 encodings.

Serving XHTML 1.1 as text/html
This violates W3C guidelines, the exemption that XHTML that follows
Appendix C guidelines may be served as text/html only applies to
XHTML 1.0.

I know W3C says XHTML 1.1 *should* be served as application/xhtml+xml.
But I don't recall where it says it *must* be served as sutch. If it's
a "must", then why do the W3C validator say the pages are valid XHTML
1.1. even when served as text/html?

Remeber now, I'm not in favor for XHTML for "serious" websites.
I am just curious and have playing around with it, for fun and
"research" purpose to learn a bit about it. So I would be grateful for
some comment regarding the quoted parts.

BTW, I have no access to the ISP's server, so I can't change the
encoding or configure it to serve "proper" XHTML. I belive most
website owners is in the same situation, if they don't have their own
server. So They can't configure the host's server to serve XHTML as
sutch (at least those I know of), only as text/html and then it's no
point using XHTML at all

--
/Arne

Tech Support: Are you sure you used the right password?
Customer: Yes, I'm sure. I saw my colleague do it.
Tech Support: Can you tell me what the password was?
Customer: Five stars.

On Sun, 20 Nov 2005, Arne wrote, quoting Spartanicus:

But I have a "site for fun" (testing and sutch) on the free space I
have on my ISP's server. There I have coded XHTML 1.1 "just for fun"
and to see how the pages acts, validates a.s.o. as text/html.

What you do "for fun" is your own business, but serving XHTML/1.1 as
text/html doesn't follow the W3C recommendation. Further discussion
below.

Serving XHTML Strict 1.0 as text/html
This is at best pointless, UAs will treat it as tag soup. You'll
kick IE and some versions of Opera into quirks mode if you add the
xml declaration on top of your documents as W3C recommends, omit the
xml declaration and the document can only use the default character
encodings UTF-8 or UTF-16.

I don't call valid code as "tag soap", not even in this
"environment".

It's a correct factual statement: UAs *will* treat it as tag soup.

For me tag soup is not valid and depricated code only.

The UAs don't /care/ what you think! They just do what they do.

When I omitted the xml declaration from my XHTML pages nothing
happends (as I can see) to the content, despite the fact that the
pages is not served with UTF-8 or UTF-16 encodings.

Did you read the relevant guidelines? When the encoding is defined by
the HTTP header, it's defined. That's it.
http://www.w3.org/International/O-charset.html
http://www.w3.org/International/tuto...rial-char-enc/

I know W3C says XHTML 1.1 *should* be served as application/xhtml+xml.

RFC2119

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

You haven't presented the "full implications" yet.

Remeber now, I'm not in favor for XHTML for "serious" websites.
I am just curious and have playing around with it, for fun and
"research" purpose to learn a bit about it.

BTW, I have no access to the ISP's server,

So how do you get your web pages onto it???

so I can't change the encoding or configure it to serve "proper"
XHTML.

I guess you haven't even tried, yet.

I belive most website owners is in the same situation,

*They* haven't even tried yet, either. I get tired of this line of
discussion. These are server features that you *need* for doing
anything non-trivial. Either find them or, if they really are blocked
by your server provider, and you are serious, then move. Or do your
experiments on your own web server, installed locally. We're not going
to stop pointing out that you need them, any time that you repeat that
you haven't got them.

Arne <invalid (AT) domain (DOT) invalid> wrote:

Serving XHTML Strict 1.0 as text/html
This is at best pointless, UAs will treat it as tag soup. You'll
kick IE and some versions of Opera into quirks mode if you add the
xml declaration on top of your documents as W3C recommends, omit the
xml declaration and the document can only use the default character
encodings UTF-8 or UTF-16.

I don't call valid code as "tag soap", not even in this "environment".
For me tag soup is not valid and depricated code only.

To many language errors in what you wrote for me to be able to parse it,
sorry.

Tag soup refers to HTML, all sorts, valid, non valid, correct,
incorrect. The parser required to parse HTML is often referred to as a
tag soup parser.

When I omitted the xml declaration from my XHTML pages nothing
happends (as I can see) to the content, despite the fact that the
pages is not served with UTF-8 or UTF-16 encodings.

If you provide an url, others who know about character encoding issues
may be willing to comment on any practical consequences of what you are
doing.

Serving XHTML 1.1 as text/html
This violates W3C guidelines, the exemption that XHTML that follows
Appendix C guidelines may be served as text/html only applies to
XHTML 1.0.

I know W3C says XHTML 1.1 *should* be served as application/xhtml+xml.
But I don't recall where it says it *must* be served as sutch.

I didn't claim that there was, it's a violation of a w3c guideline.
Furthermore the exemption laid out in the notorious Appendix C that
XHTML may be served as text/html is attached to and applies to XHTML 1.0
only.

If it's
a "must", then why do the W3C validator say the pages are valid XHTML
1.1. even when served as text/html?

A validator only checks if a document complies with the applicable DTD.
Before you can claim spec compliance you must comply with other spec
requirements that cannot be expressed in a DTD, these other requirements
are listed in the spec's prose. There are markup checkers that check for
DTD compliance *and* for other requirements. Certain checkers may throw
an error on XHTML 1.1 served as text/html (Page Valet does in "fussy"
mode IIRC).

Remeber now, I'm not in favor for XHTML for "serious" websites.

Under discussion is "best practice", this applies to all web sites. I
have no idea what you mean by a "serious" web site.

BTW, I have no access to the ISP's server, so I can't change the
encoding or configure it to serve "proper" XHTML.

Nor would you want to if you read and understood the provided resource
(for one IE doesn't support XHTML served as such).

I belive most
website owners is in the same situation, if they don't have their own
server.

Again you are using unclear language, what does "own their own server"
mean? Virtually every web hosting package allows user configuration for
the virtual servers, many of which commonly reside on the same physical
server. Web space provided with an ISP dial up or broadband package may
not, but they may be willing to do the configuration for you (mine was).

So They can't configure the host's server to serve XHTML as
sutch (at least those I know of), only as text/html and then it's no
point using XHTML at all

So why are you arguing in favor of doing so?

--
Spartanicus

Once upon a time *Spartanicus* wrote:

Arne <invalid (AT) domain (DOT) invalid> wrote:

Serving XHTML Strict 1.0 as text/html
This is at best pointless, UAs will treat it as tag soup. You'll
kick IE and some versions of Opera into quirks mode if you add the
xml declaration on top of your documents as W3C recommends, omit the
xml declaration and the document can only use the default character
encodings UTF-8 or UTF-16.

I don't call valid code as "tag soap", not even in this "environment".
For me tag soup is not valid and depricated code only.

To many language errors in what you wrote for me to be able to parse it,
sorry.

Sorry, I'll do my best but English is not my native language.
What part of the above do you not understand?

Tag soup refers to HTML, all sorts, valid, non valid, correct,
incorrect. The parser required to parse HTML is often referred to as a
tag soup parser.

Ok, I can buy that.

When I omitted the xml declaration from my XHTML pages nothing
happends (as I can see) to the content, despite the fact that the
pages is not served with UTF-8 or UTF-16 encodings.

If you provide an url, others who know about character encoding issues
may be willing to comment on any practical consequences of what you are
doing.

Since it's a page I only fuss with, it's not that important. I belive
what you said, but I also like to know why and what the practical
consequences are i general. That's what others ask me when I clame
something

Serving XHTML 1.1 as text/html
This violates W3C guidelines, the exemption that XHTML that follows
Appendix C guidelines may be served as text/html only applies to
XHTML 1.0.

I know W3C says XHTML 1.1 *should* be served as application/xhtml+xml.
But I don't recall where it says it *must* be served as sutch.

I didn't claim that there was, it's a violation of a w3c guideline.
Furthermore the exemption laid out in the notorious Appendix C that
XHTML may be served as text/html is attached to and applies to XHTML 1.0
only.

Ok, that I understand.

If it's
a "must", then why do the W3C validator say the pages are valid XHTML
1.1. even when served as text/html?

A validator only checks if a document complies with the applicable DTD.
Before you can claim spec compliance you must comply with other spec
requirements that cannot be expressed in a DTD, these other requirements
are listed in the spec's prose. There are markup checkers that check for
DTD compliance *and* for other requirements. Certain checkers may throw
an error on XHTML 1.1 served as text/html (Page Valet does in "fussy"
mode IIRC).

Did'nt know about the Page Valet, thank's! I find it and of course you
are right.

Checked a HTML Strict page with Page Valet also, and it validates.
Discovered that the W3C validator missed a line break tag with the
"end tag slash" for XHTML in it.

Remeber now, I'm not in favor for XHTML for "serious" websites.

Under discussion is "best practice", this applies to all web sites. I
have no idea what you mean by a "serious" web site.

Every site except my "for fun" page?

BTW, I have no access to the ISP's server, so I can't change the
encoding or configure it to serve "proper" XHTML.

Nor would you want to if you read and understood the provided resource
(for one IE doesn't support XHTML served as such).

Maybee I would want to, but for nothing else than what you have on
your demo page (demo.xhtml)

I belive most
website owners is in the same situation, if they don't have their own
server.

Again you are using unclear language, what does "own their own server"
mean? Virtually every web hosting package allows user configuration for
the virtual servers, many of which commonly reside on the same physical
server. Web space provided with an ISP dial up or broadband package may
not, but they may be willing to do the configuration for you (mine was).

Since I'm only dealing with hosts in Sweden, I don't know about
others. Same goes for ISP's. They clame the restrictions is for
security reasons.

So They can't configure the host's server to serve XHTML as
sutch (at least those I know of), only as text/html and then it's no
point using XHTML at all

So why are you arguing in favor of doing so?

I'm not arguing, only discussing the issuie. As I said, I'm not in
favor for XHTML, just curious about the subject and like to know more
from people who know more than I do.

--
/Arne

Tech Support: Are you sure you used the right password?
Customer: Yes, I'm sure. I saw my colleague do it.
Tech Support: Can you tell me what the password was?
Customer: Five stars.

Once upon a time *Alan J. Flavell* wrote:

On Sun, 20 Nov 2005, Arne wrote, quoting Spartanicus:

But I have a "site for fun" (testing and sutch) on the free space I
have on my ISP's server. There I have coded XHTML 1.1 "just for fun"
and to see how the pages acts, validates a.s.o. as text/html.

What you do "for fun" is your own business, but serving XHTML/1.1 as
text/html doesn't follow the W3C recommendation. Further discussion
below.

So, so, no need to sound so harsh
I get the messages. See my reply to Spartanicus.

--
/Arne

Tech Support: Are you sure you used the right password?
Customer: Yes, I'm sure. I saw my colleague do it.
Tech Support: Can you tell me what the password was?
Customer: Five stars.