I'm using the HTML 4.01 strict DTD.

I have a few questions about the longdesc attribute when used
with the IMG element.

I understand that longdesc takes a uri for a value.

1) What kind of resource is appropriate for the uri to point to?
A plain text file? An HTML document?

1) a. If an HTML document, would that be one document per
description, or could it be a name anchor in a page with many
descriptions?

1) b. If several document types are possible, is there a way to
indicate the content type(s) of longdescs used in a page.

2) If the uri is relative, is it relative to the image or to the
page on which IMG occurs? I guess the latter, but want to be
sure.

3) Are there any user-agents in current release that actually
treat longdesc in an appropriate manner, including cases in
which IMG is in A?

4) Should longdesc be omitted or be empty for purely decorative
images or images adequately described with alt?

--
Lars Eighner eighner@io.com http://www.larseighner.com/
I don't see posts from or threads started from googlegroups.
War hath no fury like a noncombatant.
- Charles Edward Montague

Lars Eighner wrote:
[color=blue]
> I'm using the HTML 4.01 strict DTD.[/color]

The longdesc attribute belongs to all HTML 4.01 DTDs. This does not make
it supported, or useful.
[color=blue]
> I have a few questions about the longdesc attribute when used
> with the IMG element.[/color]

The short answer is "Don't".
The medium-length answer is "Don't; use an explicit normal link instead."
The long answer is at http://www.cs.tut.fi/~jkorpela/html/alt.html#longdesc

The technical details of longdesc are rather unimportant, but due to my
continued failures in resisting the temptation to get involved in
discussing irrelevant technicalities (a.k.a. "nitpicking"), here I go
again...
[color=blue]
> I understand that longdesc takes a uri for a value.[/color]

Yes, and "uri" is formalese for "URL" in practice, until URNs will be
implemented in a useful way.
[color=blue]
> 1) What kind of resource is appropriate for the uri to point to?
> A plain text file? An HTML document?[/color]

Either, or some other format, such as PDF document, or an image, though
many of the formats would surely be absurd in this context.
[color=blue]
> 1) a. If an HTML document, would that be one document per
> description, or could it be a name anchor in a page with many
> descriptions?[/color]

It could be a "name anchor", i.e. the URL can contain a fragment (e.g.,
longdesc="explanations.html#foobar"). The general idea in the HTML specs
has always been to allow fragments wherever URLs are allowed, although
formally they made authoritative references to RFCs that defined "URL"
differently. That's all water under bridge now: the Internet-standard on
generic URI format defines a fragment part of a URI.
[color=blue]
> 1) b. If several document types are possible, is there a way to
> indicate the content type(s) of longdescs used in a page.[/color]

The browser is expected to recognize the media type from the HTTP
headers sent by the server for the URL requested. There's nothing you
can say about this in the <img> element.

Some HTML constructs contain a type="..." attribute for suggesting a
media type for a linked resource, but a) this hasn't been implemented,
b) it was not meant to replace the HTTP mechanism but to augment it with
an "advance hint", c) it's not defined for an <img> element (and it
wouldn't be logical to do so, since it would be much more natural to
have a type="..." attribute specify the media type of the image).
[color=blue]
> 2) If the uri is relative, is it relative to the image or to the
> page on which IMG occurs? I guess the latter, but want to be
> sure.[/color]

The latter, as all URLs in URL-type attributes.
[color=blue]
> 3) Are there any user-agents in current release that actually
> treat longdesc in an appropriate manner, including cases in
> which IMG is in A?[/color]

None that I know of.
[color=blue]
> 4) Should longdesc be omitted or be empty for purely decorative
> images or images adequately described with alt?[/color]

The specification rather clearly implies that, since the longdesc
attribute is described as giving additional information when the alt
attribute does not give enough info.

In reality, it should be omitted always, except perhaps in an
environment where HTML documents are processed by a program that makes
some meaningful use of the attributes. (I can't imagine useful
applications right now, but they might well exist.)

"Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:
[color=blue]
>Some HTML constructs contain a type="..." attribute for suggesting a
>media type for a linked resource, but a) this hasn't been implemented,[/color]

That depends on how you define "a linked resource", it's widely
supported on the link and object element to name two, and recent Geckos
have some form of support for it on the anchor element.

--
Spartanicus

Lars Eighner wrote:[color=blue]
> I have a few questions about the longdesc attribute when used
> with the IMG element.[/color]

Longdesc is broken - don't use it, build something better instead, even
if this involves additional explicit coding work for you.

It's broken in many ways, most of them made worse by having a "longdesc
page" with lots of fragments within it and pointing many longdesc links
to each fragment. Much of this brokenness is caused by Google etc.
being confused by this large page jump between portions of what is
really the same resource. It's particularly bad if the "annotation"
portion of these resources are then lumped together by being placed on
one page and only separated by fragments. This is reasonably clear for
a simple user-click navigation that ignores the location context, but
it will confuse any search engine spider immensely.

A reasonable use of longdesc is to point them at identifiers just below
the image on the same page, at the location of some further
description. This does at least keep image and annotatin together in
the same resource and it's also consistent with longdesc behaviour for
any agent that does support it.

A particularly vile practice is using longdesc to point to a 3rd party
vocabulary (such as an image gallery of landscapes that references each
one out to the Getty Thesaurus of Geographical Names). This is
confusing annotation (description of one specific thing) with a
vocabulary (a collection of terms shared by many objects).

Lars Eighner wrote:[color=blue]
> I'm using the HTML 4.01 strict DTD.
>
> I have a few questions about the longdesc attribute when used
> with the IMG element.
>
> I understand that longdesc takes a uri for a value.
>
> 1) What kind of resource is appropriate for the uri to point to?
> A plain text file? An HTML document?[/color]

Yes and yes.
[color=blue]
> 1) a. If an HTML document, would that be one document per
> description, or could it be a name anchor in a page with many
> descriptions?
>[/color]
Yes and yes. And it could be an anchor within the same page as the IMG.
[color=blue]
> 1) b. If several document types are possible, is there a way to
> indicate the content type(s) of longdescs used in a page.[/color]

No.
[color=blue]
> 2) If the uri is relative, is it relative to the image or to the
> page on which IMG occurs? I guess the latter, but want to be
> sure.[/color]

Indeed. The client is parsing the page, not the image.
[color=blue]
> 3) Are there any user-agents in current release that actually
> treat longdesc in an appropriate manner, including cases in
> which IMG is in A?[/color]

Interesting that that only makes question #3. I believe there are,
but couldn't cite detail without taking time to check.
[color=blue]
> 4) Should longdesc be omitted or be empty for purely decorative
> images or images adequately described with alt?
>[/color]
Yes. It's only meaningful where the img can be adequately described in
text, the description is genuinely useful, but the description would
be inappropriate inline. Thus an appropriate longdesc might easily
start with words like "The graph shows ..."

Hmmm, I see Andy wrote:

A reasonable use of longdesc is to point them at identifiers just below
the image on the same page, at the location of some further
description.

As it happens, that's the only way I've used them myself in real life.

--
Nick Kew

On Mon, 22 Aug 2005, Nick Kew wrote:
[color=blue]
> Lars Eighner wrote:[color=green]
> > I'm using the HTML 4.01 strict DTD.
> >
> > I have a few questions about the longdesc attribute when used
> > with the IMG element.
> >
> > I understand that longdesc takes a uri for a value.
> >
> > 1) What kind of resource is appropriate for the uri to point to?
> > A plain text file? An HTML document?[/color]
>
> Yes and yes.[/color]

Excuse me for using this response partially for administrivia, but I've
seen a number of symptoms which suggest that my usual news server is
broken today: I posted a response to Lars earlier today, but I don't see
it on this server nor on Google Gropes, so I suspect that it hasn't
escaped from the server. Whether it ever will, I don't know.

Please humour me if I repeat myself a bit. I agreed with the above (but
the HTML page shouldn't contain images!), but I added this:

I think it's fair to say that the designers of HTML4 intended the old, and
inadequately specified, <img> to be obsoleted by their <object> markup,
where the possibilities for fallback would have been much better
specified. As such, they put only a limited amount of effort into
thinking-through all the accessibility features of <img>. But the
<object> then got so confused with proprietary crud and plugins, and with
muddled implementations in browsers, that document authors weren't
prepared to trust it, and preferred to stay with the more conservative
<img> - for all its inadequacies.
[color=blue][color=green]
> > 1) b. If several document types are possible, is there a way to
> > indicate the content type(s) of longdescs used in a page.[/color]
>
> No.[/color]

Not so far as I can see. In principle, a client agent could negotiate
the content type which it's willing to "Accept:" in response to a
longdesc, but I've never noticed any kind of user option in a browser
to tailor such an Accept: to the user's wishes.

Rather obviously, you could point your longdesc to some kind of "shim"
page which presented a menu of alternatives (plain text, HTML,
whatever), but that's a rather clumsy idea - I doubt that it would be
particularly welcomed by a user who needed a longdesc.
[color=blue][color=green]
> > 2) If the uri is relative, is it relative to the image or to the
> > page on which IMG occurs? I guess the latter, but want to be
> > sure.[/color]
>
> Indeed. The client is parsing the page, not the image.[/color]

HTML4 section 6.4 says that relative URIs are resolved relative to a base
URI, and refers to 12.4. 12.4.1 sets out the rules for determining the
base URI. I see nothing there which could indicate that the image itself
might serve as base URI! In the absence of a <base> in the <head> (first
list item), nor any HTTP protocol specification of a base URI (second list
item, though don't ask me what that would look like exactly in practice,
see RFC2616), then the third list item indicates that the HTML document
itself is the base URI for resolving relative URIs, doesn't it? So I
think that's the answer to the question.
[color=blue][color=green]
> > 4) Should longdesc be omitted or be empty for purely decorative
> > images or images adequately described with alt?
> >[/color]
> Yes.[/color]

Omitted: yes. Empty: I don't think so (?). If an empty URI meant
anything, it would be a relative link back to the current page, which
isn't in the least helpful. (Although in different circumstances, a
longdesc="#anchor" could be entirely acceptable and useful).

But even if longdesc was widely and usefully implemented, I feel that it
has distinct shortcomings.

best

In <1124711004.021789.115800@f14g2000cwb.googlegroups .com>, on
08/22/2005
at 04:43 AM, dingbat@codesmiths.com said:
[color=blue]
>Longdesc is broken[/color]

You have failed to document that claim. What you documented is that
google is broken, which is hardly a startling revelation.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

Lars Eighner wrote :[color=blue]
> I'm using the HTML 4.01 strict DTD.
>
> I have a few questions about the longdesc attribute when used
> with the IMG element.
>
> I understand that longdesc takes a uri for a value.
>
> 1) What kind of resource is appropriate for the uri to point to?
> A plain text file? An HTML document?
>
> 1) a. If an HTML document, would that be one document per
> description, or could it be a name anchor in a page with many
> descriptions?
>
> 1) b. If several document types are possible, is there a way to
> indicate the content type(s) of longdescs used in a page.
>
> 2) If the uri is relative, is it relative to the image or to the
> page on which IMG occurs? I guess the latter, but want to be
> sure.
>
> 3) Are there any user-agents in current release that actually
> treat longdesc in an appropriate manner, including cases in
> which IMG is in A?[/color]

There are now several browsers which can render the longdesc attribute.

Firefox has the Longdesc 0.21 extension which adds 'View Image Longdesc'
to the image context menu.
https://addons.mozilla.org/extension...Windows&id=273

Icab supports longdesc attribute and offers a link in the contextmenu.
There are a few other browsers.

Longdesc Linker for Internet Explorer 6 adds a 'Long Description' item
to the context menu that IE uses for images:
http://www.hackcraft.net/longdesclink/default.asp

I've personally asked IE 7 dev. team to support longdesc for the IE 7
final release.
[color=blue]
> 4) Should longdesc be omitted or be empty for purely decorative
> images or images adequately described with alt?[/color]

It should be omitted for purely decorative images.
It should be omitted for images adequately described with alt.
These issues are covered by WCAG.

Gérard
--
remove blah to email me

Shmuel (Seymour J.) Metz wrote:
[color=blue][color=green]
> >Longdesc is broken[/color]
>
> You have failed to document that claim.[/color]

I documented it some time in 2003, in one of my published papers on
annotation work, probably co-authored with Libby Miller and Paul
Shabajee.

Lars Eighner:
[color=blue][color=green]
>> 4) Should longdesc be omitted or be empty for purely decorative
>> images or images adequately described with alt?[/color][/color]

Gérard Talbot:
[color=blue]
> It should be omitted for purely decorative images.
> It should be omitted for images adequately described with alt.[/color]

And for images adequately described by the adjacent text.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.