Last Comment Bug 1996 - (longdesc) Support LONGDESC for IMG
(longdesc)
: Support LONGDESC for IMG
Status: RESOLVED WONTFIX
[bae:20011119][parity-opera]
: access, helpwanted, html4, testcase
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: All All
: P4 enhancement with 19 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.hixie.ch/tests/evil/mixed/...
: 197025 321622 (view as bug list)
Depends on: context-menu-cursor 47534
Blocks: html4.01 metadata 16501 robin's
  Show dependency treegraph
 
Reported: 1998-12-19 13:06 PST by Hixie (not reading bugmail)
Modified: 2014-04-26 03:21 PDT (History)
45 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch to add longdesc & cite support (24.22 KB, patch)
2000-12-11 17:57 PST, Christopher Hoess (gone)
no flags Details | Diff | Review
test case to use for verification (557 bytes, text/html)
2001-11-19 18:13 PST, rubydoo123
no flags Details
fixing regression from 101910 to make links clickable again (2.12 KB, patch)
2003-05-21 19:00 PDT, Brant Gurganus
jonas: review+
jag-mozilla: superreview-
Details | Diff | Review
this one uses a button instead (3.48 KB, patch)
2003-05-22 13:18 PDT, Brant Gurganus
no flags Details | Diff | Review

Description Hixie (not reading bugmail) 1998-12-19 13:06:54 PST
(Should this be assigned to Content Model? Parser? Rendering? Viewer App?)

The longdesc attribute of the IMG element contains a link to a file
describing the image in detail, for those times where the image
cannot be downloaded.

The browser should supply some way of accessing this information.

See also bug #1995
Comment 1 kipp 1999-01-06 18:20:59 PST
While application behavior is outside the scope of the layout engine, it would
be good to figure out what we should do with ALT/TITLE/LONGDESC and then forward
that information to the appropriate app developers or change our default
behavior for the image frame class.
Comment 2 troy 1999-01-06 19:17:59 PST
We do, you can access it through the DOM. See GetLongDesc() and SetLongDesc() in
nsIDOMHTMLImageElement or the W3C DOM spec
Comment 3 Hixie (not reading bugmail) 1999-01-23 15:09:59 PST
Page moved. Updating uri.
Comment 4 troy 1999-01-29 17:41:59 PST
Re-opened the bug, because it was pointed out to me that just providing DOM
access to the LONGDESC wasn't all that useful.

Marking it REMIND, because it's not something we're planning on doing for
version 1.0
Comment 5 Eli Goldberg 1999-02-24 16:16:59 PST
QA Assigning to self.
Comment 6 Eli Goldberg 1999-03-15 12:25:59 PST
Verifying 'REMIND'.
Comment 7 Hixie (not reading bugmail) 1999-06-21 20:13:59 PDT
Since bug 1995 is now under consideration, and it is very similar, I am
reopening this bug.
Comment 8 Hixie (not reading bugmail) 1999-06-21 20:14:59 PDT
Troy, you may wish to reassign this bug to german/don/shuang in UE, as this
will probably require a spec before it can be implemented.
Comment 9 troy 1999-06-22 07:50:59 PDT
This still isn't going to get implemented for version 1.0 so I'm marking it back
as REMIND
Comment 10 Eli Goldberg 1999-06-28 11:06:59 PDT
Rubberstamping as verified/REMIND.
Comment 11 Hixie (not reading bugmail) 2000-05-20 14:50:54 PDT
Troy no longer with us, so reassigning.

Since Troy says that DOM access is indeed provided, and that all that is missing
is the XUL interface to this, marking "helpneeded" and reassigning to nobody.
Setting milestone to Future.

If anyone wants to do this, it should be relatively easy: Add a menu item to the
popup menu for images. Disable it by default. When the menu is popped up, check
(using "GetLongDesc()") if the image has a LongDesc URI, and if it does, enable
the menu item. If the menu item is selected, then fetch the URI for the image
using "GetLongDesc()" again, and navigate to that page.

For extra credit, make the status line text for that menu item contain the URI
of the pointed to by the "longdesc" attribute. :-)
Comment 12 Hixie (not reading bugmail) 2000-05-20 14:51:41 PDT
Reassigning...
Comment 13 Tim Hill 2000-06-09 13:33:16 PDT
Added a depend on Bug 42066.  GetLongDesc() only returns a relative URI right 
now, and it needs to return an absolute URI.
Comment 14 Hixie (not reading bugmail) 2000-10-01 16:57:55 PDT
Taking QA per managerial policy.
Comment 15 Nicholas Cull 2000-10-01 18:50:44 PDT
Changing dependency on bug 42066 to bug 47534, since this takes over the
problem of longdesc (among others) returning a relative URL.
Comment 16 Robin Lionheart 2000-11-19 12:21:09 PST
In addition to longdesc on images, it would also be nice if the Frame context
menu provided access to the longdesc on the current frame.

Along the same lines, it would also be desirable if the context menu made the
cite attribute on BLOCKQUOTE/Q/INS/DEL navigable. See bug 37209.
Comment 17 Christopher Hoess (gone) 2000-12-09 10:17:49 PST
I've got a patch for this adding IMG longdesc support to the context menu.
However, I've heard that cluttering up the context menu with this (since I plan
to add support for FRAME longdesc and the cite attribute as well) may not be the
best idea, and I should put it in the sidebar.  Anyone care to comment on where
this metadata should go?
Comment 18 Christopher Hoess (gone) 2000-12-11 17:57:27 PST
Created attachment 20507 [details] [diff] [review]
patch to add longdesc & cite support
Comment 19 Christopher Hoess (gone) 2000-12-11 17:59:15 PST
The patch adds "View Image Long Description" and "View [element] Citation" to
the context menu as appropriate.  The second function isn't very robust yet, though.
Comment 20 Matthew Tuck [:CodeMachine] 2001-02-05 22:53:41 PST
This patch has been sitting here a while.  Should "review" be added?
Comment 21 Christopher Hoess (gone) 2001-02-06 07:42:11 PST
Actually, I think it's been obsoleted by the patch for bug 1995, which seems to
have stalled in review.
Comment 22 Hixie (not reading bugmail) 2001-02-16 03:20:19 PST
This is *not* obsoleted by bug 1995; this bug is for a context menu option and
not all the additional stuff like panels and so on.

Blake: could you have a look at the patch and do something with it? Cheers...
Comment 23 Christopher Hoess (gone) 2001-02-16 08:31:54 PST
The reason I made my comment was that the current context-menu UI spec just
lists a single item "Imtage Properties" which should presumably cover all the
metadata, and mpt's comments in bug 26939 suggest he's looking to keep bloat out
of the context menus.  Feel free to mine the patch for whatever changes you
like, though.
Comment 24 Hixie (not reading bugmail) 2001-02-16 11:07:34 PST
This bug isn't so much about metadata as one click access to links to more
information. "longdesc" is a URI -- a context menu option is a considerably 
quicker way of getting to this information that a "middle man" window. (Not
that the metadata window is a bad idea, I think it's great, it's just not
a replacement for _this_ bug.) Similary with "cite".

Your patch looks great to _me_, but I'm not an expert at all in this code, so
I'll defer to Blake.
Comment 25 Zach Lipton [:zach] 2001-02-27 19:20:41 PST
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
Comment 26 Jonas Sicking (:sicking) PTO Until July 5th 2001-04-02 04:52:28 PDT
Them longdesc metainfo is now avalible through the "properties" window from
bug 1995, so feel free to mark as fixed
Comment 27 Christopher Hoess (gone) 2001-04-02 12:55:50 PDT
Can we not close this just yet?  The trouble with the current setup is that one 
has to enter the properties window from the context menu to click the longdesc 
link.  Not many people will realize that it's there, which will discourage its 
use by authors.  Ideally, I think that the longdesc should be somewhere in the 
context menu (as in my patch above), but mpt has been pretty assertive about 
not wanting more items in the context menu.  Can someone with more UI 
experience suggest a good, quickly accessible place to put longdesc?
Comment 28 timeless 2001-04-02 13:11:13 PDT
i have a design idea that would result in a powerful tooltip replacement for 
the properties dialog, it would easily handle most of the problems relating to 
contextual objects, however i don't have the time to work on it right now.  (oh 
and it won't fit in the margins of this comment either, !exist a^n+b^n=c^n 
forall positive integers a,b,c, where n>2)
Comment 29 Karl Ove Hufthammer 2001-04-02 13:46:08 PDT
The W3C TUAAG <URL: http://www.w3.org/TR/UAAG10-TECHS/#long-descriptions > says:

Allow the user to configure how the user agent renders a long description 
(e.g., "longdesc" in HTML 4 [HTML4]). Some possibilities include: 

* Render the long description in a separate view. 
* Render the long description in place of the associated element. 
* Do not render the long description, but allow the user to query whether an 
element has an associated long description (e.g., with a context-sensitive 
menu) and provide access to it. 
* Use an icon (with a text equivalent) to indicate the presence of a long 
description. 
* Use an audio cue to indicate the presence of a long description when the user 
navigates to the element. 
Comment 30 Matthew Paul Thomas 2001-04-04 10:16:57 PDT
The W3C TUAAG also says that it is a collection of suggestions, rather than a 
collection of requirements. I am of the opinion that providing preferences for 
configuring the display of longdesc would harm usability (`help, I don't 
understand all these prefs!') more than it would improve accessibility. Given 
that longdesc is (I assume) hardly used, it's just not important enough to have 
prefs for.

However, we do have a problem in that where a `longdesc' is present, its 
existence is hardly noticable. You have to go into a context menu item (which 
is identical whether or not the item has longdesc), then look in the resulting 
window, and finally click a link in order to open the longdesc page (which 
blows away the original page).

I suggest three things to solve this problem.

1.  When an image has a longdesc, by default it should be given the cursor
    which indicates the existence of a context menu (that is: img[longdesc]
    {cursor: context-menu}). In this case, the cursor indicates that
    information provided by the author is available for the item. This should
    also apply to frames, but only when frames are turned off (i.e. the cursor
    applies to the Lynx-like link to the frame, not to the frame itself).
    Potential problem: this may give Mac users the impression that their
    Control key is stuck. Perhaps we should use {cursor: help} instead?

2.  The `Properties' item should be renamed to `Image Info', `Frame Info', or
    `Page Info' as appropriate, with the `Page Info' and Page Properties
    windows being merged (bug 74729.) When an item has a longdesc, the item
    should instead be labelled `Image Info and Description' or `Frame Info and
    Description'. (Unlike the cursor, this would apply to a frame even when
    frames were turned on.)

3.  The longdesc document should be shown in a box inside the Info window,
    rather than in a browser window. Since we will be the first major browser
    to support longdesc, we can dictate a convention that a longdesc document
    works best if it is a small one. There should be an `Open in Browser'
    button under the box, to allow the longdesc page to be opened in an
    ordinary browser window for saving, printing, better viewing, or whatever;
    in addition, any links followed from the longdesc page should open in a
    browser window rather than opening in the box.

This proposal does not address how longdesc should be handled in a future 
speech interface to Mozilla; but since that will require a completely new set 
of HTML compliance speccing, it can be left for another time.

Please discuss this proposal in the thread `Bug 1996: Support LONGDESC for IMG 
and FRAME' in the m.ui group and the mozilla-accessibility mailing list.
Comment 31 Christopher Hoess (gone) 2001-04-04 20:13:24 PDT
I think that with the new description for this, bug 3658 can be marked a
duplicate of this bug (it covers frame/iframe support specifically).
Comment 32 Håkan Waara 2001-04-11 07:04:47 PDT
Check out bug 74121, which is about cleaning up the Properties window to be more
UI friendly and logical...
Comment 33 Aaron Leventhal 2001-07-18 16:50:17 PDT
Bug 3658 is for frame/iframe longdesc support
Comment 34 Matthew Paul Thomas 2001-07-22 00:41:48 PDT
Ok, I lost this bug. Sorry about that. My previous specification applies, with 
the exception that the word `Properties' is used instead of `Info'.

--> Layout (since HTML Elements is deprecated).
Comment 35 anthonyd 2001-10-26 14:19:33 PDT
not a table bug, over to attinasi
Comment 36 rubydoo123 2001-11-19 18:10:19 PST
Since the contents of the image properties dialog, accessed from the context 
menu, displays the image location and it is a valid link to the longdesc, I am 
marking this bug as resolved/fixed.

Attaching a testcase for tracking purposes
Comment 37 rubydoo123 2001-11-19 18:13:28 PST
Created attachment 58476 [details]
test case to use for verification

To verify:
1. open testcase in browser window
2. On windows, mouse-over the netscape logo, right mouse click and select
properties.
3. The URI displayed next to the Description label is the content of the
longdesc attribute, select the URI

Result: the DevEdge page should be rendered
Comment 38 Chris Petersen 2001-11-20 11:50:50 PST
Marking verified in the Nov 20th build. The URI for longdesc is displayed in
Image Properties dialog and is functional. However, we still haven't implemented
support for LONGDESC with iframe/frames elements.
http://bugzilla.mozilla.org/show_bug.cgi?id=3658
Comment 39 Jonathan Wakely 2003-01-07 09:54:42 PST
Using Mozilla 1.2.1 I can find no direct way to access the longdesc URI of an IMG.
Page Info->Media shows the longdesc, but it's shown as a relative URI (if given
as a relative URI) and isn't an active link.
The Properties dialog shows the URI but again, it isn't a link (trying the test
case given in comment 37, I can't select the URL)
This means I have to highlight and copy the URI, and paste it to the Location
bar to access it. Has this changed since this bug was marked fixed? Should I
open it as a new bug?
Comment 40 Christopher Hoess (gone) 2003-03-12 12:12:06 PST
I agree; the link to the longdesc URI should be functional. Reopening.
Comment 41 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-03-18 12:53:36 PST
And this is related to "layout" _HOW_ exactly?  ;)
Comment 42 Brant Gurganus 2003-05-18 14:21:48 PDT
this looks like something I could fix someday so adding CC
Comment 43 Brant Gurganus 2003-05-21 19:00:30 PDT
Created attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

In a fix for bug 101910, the onclick and class attributes were not transferred
to the new elements.  Because of this, the links no longer looked like links
and did not function as links.	I have fixed this by adding
  class="text-link" onclick="openLink(this);"
to the appropriate XUL elements.

I have tested this locally and it works with no noticed regressions.
Comment 44 Brant Gurganus 2003-05-21 19:05:19 PDT
Comment on attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

requesting review by sicking (original author) and superreview from caillon
since he's around right now
Comment 45 Christopher Aillon (sabbatical, not receiving bugmail) 2003-05-21 19:10:39 PDT
Comment on attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

Sorry.	I'm not a superreviewer.  Try jag.
Comment 46 Brant Gurganus 2003-05-21 19:11:40 PDT
Comment on attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

changing superreiver request, caillon's not superreviewer
Comment 47 Brant Gurganus 2003-05-21 20:30:40 PDT
received a message from Neil Marshall who wrote the patch causing the regression.

He said it was intentional so that the links could be copied.  They can't be
copied with the linkification.  So, we have a decision to make: Do we want to be
able to copy the URLs or to click them?  It seems the two are mutually
exclusive.  Since the labels cannot be copied and most other dialogs can't be
copied, I opt for the linkification, but other feedback is obviously necessary
before this were actually checked in.
Comment 48 Christopher Hoess (gone) 2003-05-21 21:58:17 PDT
It seems to me that linkifying would make more sense; after all, you're supposed
to be able to browse these URLs, and that's more convenient than copy-and-paste
to URL bar. Is inability to copy linked text a bug?
Comment 49 Hixie (not reading bugmail) 2003-05-22 05:46:08 PDT
Shouldn't you be able to right click the link and choose "Copy"?
Comment 50 Brant Gurganus 2003-05-22 08:02:16 PDT
In a subsequent e-mail from Neil, he suggested adding a button to follow the
link.  I think that would just be moving the onclick action to the button and
then the text can still be copied.  But then, that would be a workaround for
what might be considered a bug, which might be discouraged.  Any other ideas?
Comment 51 Jonas Sicking (:sicking) PTO Until July 5th 2003-05-22 08:15:47 PDT
Comment on attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

r=sicking for this patch. However make sure that you get somebody from UI to
superreview this, I'm not sure who qualifies for that these days.

Also note that this bug has previously been considered something different then
the metadata window (see comment 22), so you might not want to close this bug
after applying this patch
Comment 52 Brant Gurganus 2003-05-22 13:18:32 PDT
Created attachment 123993 [details] [diff] [review]
this one uses a button instead

This patch uses a button instead for the onclick event.  However, the URL text
is sometimes truncated.  Ideas?
Comment 53 Neil Marshall 2003-05-22 13:27:07 PDT
Are you sure it's truncated and not just off the edge of the textbox?  They were
put into textboxes so that the entire url is visible and it doesn't change the
size of the dialog box.  Windows does the same thing in it's properties dialog
boxes.
Comment 54 Asa Dotzler [:asa] 2003-05-22 13:55:44 PDT
Comment on attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

unsetting approval request until this has reviews.
Comment 55 Brant Gurganus 2003-05-23 09:30:51 PDT
Neil: it is just off the edge of the dialog boxes.  If I highlight the URL, it
will scroll so that it can completely be seen.  So, do we want this buttoned
version instead?
Comment 56 Neil Marshall 2003-05-25 09:05:13 PDT
(Sorry for taking so long to check the patch out)

hm, the problem with it is that it looks ugly because the buttons so big and
it's throwing off the layout.  (Not to mention the blue text creating weird
underlines in the right click menu under modern)

What if the go and copy were both accessable in the right click menu?
Then it wouldn't matter if the link was clickable or not (it could be either
depending on what people want).

Does anyone else have any ideas?
Comment 57 Bill Mason 2003-06-19 11:19:21 PDT
*** Bug 197025 has been marked as a duplicate of this bug. ***
Comment 58 jag (Peter Annema) 2003-07-08 04:22:52 PDT
Comment on attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

This "text-link" class causes the text in the context menu to become
underlined.

I think I would prefer this approach (once fixed) though over adding a separate
button. For now users could Select All, Copy to get the text of the url,
perhaps in the future we could add a "Copy Link" item to make it easier.
Comment 59 Brant Gurganus 2003-07-08 19:40:14 PDT
I confirmed the issue mentioned by jag and think it could be fixed by adding a
style rule like [class="text-link"] xul:popup { text-decoration: none; color:
black } or something along those lines.  Would that work.  As for Neil's issue
with not being able to copy it, is it possible to make a child element of the
input box that is like a span.  We could then have <address> where the '<' and
'>' are not linkified.  That way the URL could be copied if need be.
Comment 60 Blake Ross 2004-04-03 15:20:50 PST
Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). 
If you want this fixed for Firefox, change the Product and Component accordingly
and reassign back to me.
Comment 61 Gérard Talbot 2004-12-20 16:42:04 PST
(In reply to comment #30)
> However, we do have a problem in that where a `longdesc' is present, its 
> existence is hardly noticable. (...) When an image has a longdesc, by default
it > should be given the cursor which indicates the existence of a context menu
(that > is: img[longdesc] {cursor: context-menu}).

Marking this bug dependent on bug 258960.
Comment 62 Matthew Paul Thomas 2004-12-25 16:22:38 PST
(For what it's worth, which probably isn't much since I can't imagine this 
ever appearing in Firefox: I now think it's not worth the menu-and-cursor 
clutter for a *graphical* browser to provide an obvious interface to 
longdesc=. That attribute was well-intentioned but is destined to hardly 
ever be used; alt= is much more practical for accessibility purposes.)
Comment 63 Gérard Talbot 2005-02-16 10:59:38 PST
For fans of this bug, there is since Feb. 13th a Firefox extension, Longdesc
0.21, which makes an image longdesc link attribute accessible via context menu.
You can try it:
https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox&version=1.0+&os=nt&id=273

Comment 64 Aaron Leventhal 2005-02-16 11:04:07 PST
(In reply to comment #63)
> ... Firefox extension, Longdesc 0.21, which makes an image longdesc link 
> attribute accessible via context menu.
It would be nice to see this merged with the Firefox accessibility extension
being build by Jon Gunderson's team at UICU 

Comment 65 jongund 2005-03-22 09:07:13 PST
(In reply to comment #64)
> (In reply to comment #63)
> > ... Firefox extension, Longdesc 0.21, which makes an image longdesc link 
> > attribute accessible via context menu.
> It would be nice to see this merged with the Firefox accessibility extension
> being build by Jon Gunderson's team at UICU 
> 
> 

It is already a part of the Firefox Accessibility Extension up the list of
images option.  There is a button to open long descriptions.

Jon
Comment 66 Gérard Talbot 2005-08-27 15:22:42 PDT
The extension
longdesc-0.21-fx+mz.xpi
also works perfectly for Seamonkey 1.0a and 1.1a. So, once/thanks to this
extension registered and associated to a profile, this bugfile is FIXED for
practical reasons as far as I'm concerned. 
Comment 67 Gérard Talbot 2005-12-27 22:34:51 PST
*** Bug 321622 has been marked as a duplicate of this bug. ***
Comment 68 Marjolein Katsma 2008-04-19 04:57:31 PDT
In spite of possible extensions that support longdesc, it really is the task of the *browser* to provide access to this information. (IMO the browser isn't complete when it doesn't actually support HTML completely.)

Firefox already has excellent data in its images properties, which includes the longdesc *URL*. It would be great if that URL were made into a clickable *link*. I suspect it would also be easy to do.

BTW, neither the Firefox Accessibility Extension () nor the longdesc extension (longdesc_0.5.xpi) - both mentioned in this thread - are currently usable with Firefox 3b5. This demonstrates precisely the problem with extensions that "repair" an omission in the browser itself; they may not get updated for a major new browser version, thus leaving the browser "unrepaired" again.
Comment 69 Minh Nguyễn 2008-04-19 11:47:54 PDT
It looks like this bug was filed against the Mozilla Application Suite (SeaMonkey). Bug 216086 was for Firefox.
Comment 70 Gérard Talbot 2008-04-19 11:54:35 PDT
Marjolein,

I completely agree with every points you made and your point of view. 

Regarding "URL were made into a clickable *link*", this was the case before, in earlier releases. 
Ex. given: NS 7.0 (rv:1.0.1 Gecko/20020823) has the URL linkified.
but with NS 7.2 (rv:1.7.2 Gecko/20040804), the link of the longdesc URI is plain text, not blue, linkified, clickable.

One issue which may stop or refrain Mozilla (and other browsers) from fully implementing longdesc (that is: in the browser, not as an add-on and with linkification) or investing further dev. time and energy is that it may no longer be needed, required for HTML5. Some browser manufacturers may/will think: why implement longdesc if it won't be required in HTML5 anyway? Why work on implementing (or completing the implementation of) an attribute which won't be needed anyway later?
http://www.whatwg.org/specs/web-apps/current-work/#the-img
"There has been some suggestion that the longdesc attribute from HTML4, or some other mechanism that is more powerful than alt="", should be included. This has not yet been considered."
Comment 71 Marjolein Katsma 2008-04-19 14:12:57 PDT
(In reply to comment #70)
> Regarding "URL were made into a clickable *link*", this was the case before, in
> earlier releases. 
> Ex. given: NS 7.0 (rv:1.0.1 Gecko/20020823) has the URL linkified.
> but with NS 7.2 (rv:1.7.2 Gecko/20040804), the link of the longdesc URI is
> plain text, not blue, linkified, clickable.

Thanks for pointing that out; I've had a few versions of NS for testing but have never been a real user, so I didn't know that.

> One issue which may stop or refrain Mozilla (and other browsers) from fully
> implementing longdesc (that is: in the browser, not as an add-on and with
> linkification) or investing further dev. time and energy is that it may no
> longer be needed, required for HTML5. Some browser manufacturers may/will
> think: why implement longdesc if it won't be required in HTML5 anyway? Why
> work on implementing (or completing the implementation of) an attribute which
> won't be needed anyway later?

Well, developing a standard is not the same thing as developing a browser - even if some of the same people may be doing both.

I actually read a long discussion on longdesc and HTML5 today. It is true longdesc may not be the ideal solution to a real problem, but given that the problem is real, HTML5 should, one way or another, provide "a" solution, ideal or not, and make clear (as HTML4 did) that there is a problem to be solved. Merely discarding longdesc because it's not ideal is not helpful at this stage.

But it may be years before HTML will reach recommendation stage. Surely Firefox 3 will not take that long.

There is no way the browser maker (as opposed to the standards WG member) can even consider to only implement what /may/ be in an future standard. The browser needs to support what is out there, now. Not just in the HTML4 / XHTML standards, but in real use in real documents out there. When HTML5 becomes a standard, it won't magically make those real, existing documents disappear.

So the browser needs to support not just what /may/ be coming, but first and foremost what is out there already and compliant with the *current* standard. (The browser supports even things that were in previous standards, after all, precisely because there are still documents that use those features.) It [support for longdesc] will be needed, as it always was needed. It's about time, I think.

> http://www.whatwg.org/specs/web-apps/current-work/#the-img
> "There has been some suggestion that the longdesc attribute from HTML4, or
> some other mechanism that is more powerful than alt="", should be included.
> This has not yet been considered."

It should be, but that's another discussion. :) 
Comment 72 Gérard Talbot 2008-04-20 15:53:56 PDT
Back around 2001-2002, it was decided to make the longdesc URL accessible, fetchable in the properties window to avoid cluttering the right-click-contextmenu: see comments #17, #23 in this bug.
Firefox 2.x does that. Firefox 3 does that (as far as I know). Seamonkey 2.0a1 rv:1.9pre does that.

Linkification of the longdesc URL is another issue: problem, it seems, is how to copy linkified text.

The extension
longdesc-0.21-fx+mz.xpi
works for Seamonkey 1.x but not Seamonkey 2.x
Comment 73 Gérard Talbot 2008-05-01 13:31:32 PDT
WCAG 2.0 Candidate Recommendation (April 30th 2008)
Techniques for WCAG 2.0
H45: Using longdesc
http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H45.html
Comment 74 David Bolter [:davidb] 2009-06-16 11:18:20 PDT
Mass un-assigning bugs assigned to Aaron.
Comment 75 Henri Sivonen (:hsivonen) 2010-11-16 06:33:17 PST
Shouldn't this be WONTFIX now that HTML5 obsoletes longdesc?
Comment 76 Tristan Miller 2010-11-16 06:51:19 PST
Why?  Shouldn't SeaMonkey still support HTML 4?
Comment 77 Henri Sivonen (:hsivonen) 2010-12-10 01:53:07 PST
(In reply to comment #76)
> Why?  Shouldn't SeaMonkey still support HTML 4?

There's really no point in *adding* support for obsolete features. HTML 4 as a whole is obsolete as an implementation target.
Comment 78 Lucas 2010-12-21 01:29:26 PST
Henri, while I agree there is little demand or justification, comment #71 already makes a valid argument why support should be added in principle. Being "obsolete as an implementation target" is irrelevant to the fact that HTML 4 documents exist, and can still legitimately be created, because the browser should support valid uses of valid attributes if it claims to be compatible with any prior standards. 

Nevertheless, I recognize this bug is simply an example of ignoring problems until they go away. It's part of human nature.
Comment 79 Jonathan Wakely 2010-12-21 06:48:30 PST
> I recognize this bug is simply an example of ignoring problems
> until they go away.

That certainly seems to be the bugzilla.mozilla.org approach, for every bug I can remember submitting or being CC'd on
Comment 80 Philip Chee 2012-06-03 11:27:52 PDT
http://www.w3schools.com/tags/att_img_longdesc.asp
The longdesc attribute is not supported by any of the major browsers.

WONTFIX parity-ie parity-fx parity-chrome parity-opera parity-safari
Comment 81 Robin Lionheart 2012-06-03 17:41:04 PDT
(In reply to Philip Chee from comment #80)
> The longdesc attribute is not supported by any of the major browsers.
> 
> WONTFIX parity-ie parity-fx parity-chrome parity-opera parity-safari

Parity? What's wrong with making Mozilla's standards support better than IE, Chrome, Opera, and Safari?
Comment 82 Henri Sivonen (:hsivonen) 2012-06-04 01:31:41 PDT
(In reply to Robin Lionheart from comment #81)
> (In reply to Philip Chee from comment #80)
> > The longdesc attribute is not supported by any of the major browsers.
> > 
> > WONTFIX parity-ie parity-fx parity-chrome parity-opera parity-safari
> 
> Parity? What's wrong with making Mozilla's standards support better than IE,
> Chrome, Opera, and Safari?

Longdesc is flawed as a feature of an obsolete standard (HTML4). See permathreads on http://lists.w3.org/Archives/Public/public-html/ over the last few years.
Comment 83 Laura Carlson 2012-06-04 09:16:55 PDT
(In reply to Robin Lionheart from comment #81)
> (In reply to Philip Chee from comment #80)
> > The longdesc attribute is not supported by any of the major browsers.
> > 
> > WONTFIX parity-ie parity-fx parity-chrome parity-opera parity-safari
> 
> Parity? What's wrong with making Mozilla's standards support better than IE,
> Chrome, Opera, and Safari?

For longdesc implementation information please visit:
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation

Opera indeed added native support for longdesc in 2009.
http://www.opera.com/docs/changelogs/mac/1010b1/#ui
iCab has had native support for longdesc long before then.

ISSUE-30: longdesc is an open issue in HTML5.
http://www.w3.org/html/wg/tracker/issues/30

People are using longdesc.
Comment 84 Carlos Alén Silva 2012-06-05 01:46:19 PDT
Usual Mozilla behavior: let a spec-related bug rot for 14 years, then claim that web developers don't use the feature, that the spec is flawed/not useful/not clear/no one else is using it. The irony is that web developers don't use the feature because browsers don't implement it. And browsers don't implement the feature because they say that web developers aren't using it. And let's not forget to dismiss any non-developer comments on the bug report as not helpful and in violation of Bugzilla's etiquette.

We've seen this behavior before. We'll probably keep seeing it.

Mozilla devs —in general— lack self-criticism.
Comment 85 Laura Carlson 2012-06-05 04:37:19 PDT
(In reply to Carlos Alén Silva from comment #84)
> Usual Mozilla behavior: let a spec-related bug rot for 14 years, then claim
> that web developers don't use the feature, that the spec is flawed/not
> useful/not clear/no one else is using it. The irony is that web developers
> don't use the feature because browsers don't implement it. And browsers
> don't implement the feature because they say that web developers aren't
> using it.

During the past year alone, numerous organizations such as the A11y Bugs Project, Aboriginal Affairs and Northern Development Canada, Axel Schäfer, SPD Abgeordneter im Deutschen Bundestag für Bochum, CSS Squirrel, Canadian Department of Justice, Canadian Space Agency, Correctional Service Canada, Department of Transportation (Taiwan), Courts Administration Service (Canada), Daegu Metropolitan Office of Education (South Korea), Office of the Superintendent of Financial Institutions Canada, Elections Canada, Environment Canada, Hipocampo, HTML Accessibility Task Force, HTML5 Multimedia, Kyungpook (South Korea), Marine National Park (Taiwan), Michigan State University, National Center on Birth Defects and Developmental Disabilities, Object Description, Ohlone College, University (South Korea), Oracle, Oriental Hospital of Daejeon University (South Korea), Panel on Responsible Conduct of Research (Canada), Parcs Canada, Parks Canada, Paris Web, Parliament of Canada , Public Safety Canada, Public Works and Government Services Canada, Rebuilding The Web, Social Security Online, Secrétariat du Conseil du Trésor du Canada, Les rapports sur les plans et les priorités, Special Education Support Center (South Korea), Statistics Canada, Statistique Canada, Substance Abuse & Mental Health Services Administration, Treasury Board of Canada Secretariat, Texas State Library, U.S. Department of Health & Human Services, and the University of Minnesota have used it in reports and publications.

Notably two sister sites Statistics Canada and Statistique Canada began consistently using longdesc in "The Daily" publication. "The Daily" produces statistics on a business-day basis that help Canadians better understand their country, its population, resources, economy, society and culture.

On July 29, 2011 Suzanne Taylor and Ed McCoyd, Esq., of the Association of American Publishers attested:

"We are using longdesc increasingly in our products."
Comment 86 Gérard Talbot 2012-07-16 16:05:41 PDT
I am disappointed by the WONTFIX resolution of this bug report.


Longdesc 0.8 add-on extension for Firefox by Patrick H. Lauke
https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesc/


longdesk 0.2 add-on extension for Firefox by Anthony
https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesk/

------------

IE8 supports longdesc natively, without any extension.

"
The target of the longDesc attribute is now displayed as the tooltip, if present; otherwise, the title is displayed.
"
http://msdn.microsoft.com/en-us/library/ie/ms534132%28v=vs.85%29.aspx

----------

As mentioned in comment #70, NS 7.0 and NS 7.2 supported the longdesc attribute.


Gérard
Comment 87 Laura Carlson 2012-11-08 10:08:21 PST
(In reply to Gérard Talbot from comment #86)
> I am disappointed by the WONTFIX resolution of this bug report.
> 
> 
> Longdesc 0.8 add-on extension for Firefox by Patrick H. Lauke
> https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesc/
> 
> 
> longdesk 0.2 add-on extension for Firefox by Anthony
> https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesk/
> 
> ------------
> 
> IE8 supports longdesc natively, without any extension.
> 
> "
> The target of the longDesc attribute is now displayed as the tooltip, if
> present; otherwise, the title is displayed.
> "
> http://msdn.microsoft.com/en-us/library/ie/ms534132%28v=vs.85%29.aspx
> 
> ----------
> 
> As mentioned in comment #70, NS 7.0 and NS 7.2 supported the longdesc
> attribute.
> 
> 
> Gérard


NVDA will now "announce the existance of the long description, and you can press NVDA+d to open it. Works in Gecko (Firefox) and MSHTML (Internet Explorer)."
http://www.nvda-project.org/ticket/809#comment:7
Comment 88 Robin Lionheart 2012-11-08 16:29:07 PST
Phillip's reason for closure was incorrect. Putting parity-opera on the whiteboard.
Comment 89 Philip Chee 2012-11-08 20:57:37 PST
> Works in Gecko (Firefox)
SeaMonkey is Gecko too. Do you have an example of a webpage with long descriptions that work in Firefox but not in SeaMonkey?
Comment 90 Laura Carlson 2012-11-09 12:31:07 PST
HTML5 Image Description Extension

Abstract: "This specification defines a longdesc attribute to extended descriptions to images in HTML5-based content."

https://dvcs.w3.org/hg/html-proposals/raw-file/b63325998cc1/longdesc1/longdesc.html
Comment 91 Laura Carlson 2012-11-09 12:33:32 PST
(In reply to Philip Chee from comment #89)
> SeaMonkey is Gecko too. 

Yes.

> Do you have an example of a webpage with long
> descriptions that work in Firefox but not in SeaMonkey?

No.
Comment 92 Laura Carlson 2013-01-10 12:08:05 PST
Chris Kennish just released a new chrome plugin providing image highlighting and right-click access to longdesc.  It is available at:
https://chrome.google.com/webstore/detail/longdesc/haohljalgapbacpkfefnmhiadanhejmb
Comment 93 Laura Carlson 2013-03-25 07:56:30 PDT
(In reply to Henri Sivonen (:hsivonen) from comment #75)
> Shouldn't this be WONTFIX now that HTML5 obsoletes longdesc?

longdesc is a valid HTML5 attribute.

HTML Image Description Extension Draft Published 
http://www.w3.org/News/2013.html#entry-9756

The W3C validator http://validator.w3.org was updated last week to support the longdesc attribute as specified in http://www.w3.org/TR/html-longdesc/

Innovative browser vendors provide ways that make longdesc discoverable:
http://www.d.umn.edu/~lcarlson/research/ld-ua.html

Please fix this bug. Thank you.
Comment 94 Gérard Talbot 2013-03-25 08:39:09 PDT
> longdesc is a valid HTML5 attribute.

"
User agents should make the link available to all users through the regular user interface.

User agents should expose the link to relevant APIs, especially accessibility-oriented APIs.

User agents should enable users to discover when images in a page contain a long description.
"

3. The longdesc attribute
http://www.w3.org/TR/2013/WD-html-longdesc-20130312/#longdesc
Comment 95 Hixie (not reading bugmail) 2013-03-25 13:00:20 PDT
longdesc="" is obsolete, it was removed from HTML for very good reasons. That there are people in the W3C who think otherwise is not news, but it doesn't make it part of HTML again.

As the one who originally reported this bug, I'm marking it WONTFIX.
Comment 96 steve faulkner 2013-03-26 03:19:51 PDT
(In reply to Hixie (not reading bugmail) from comment #95)
> longdesc="" is obsolete, it was removed from HTML for very good reasons.
> That there are people in the W3C who think otherwise is not news, but it
> doesn't make it part of HTML again.
> 
> As the one who originally reported this bug, I'm marking it WONTFIX.

Like it or not Ian while longdesc is obsolete in the whatwg spec it is no longer obsolete in HTML , while I personally agree that there are good reasons for it being obsolete as currently implemented in browsers, others do not and there has recently been new implementations of it, in NVDA (for example). I consider that one of the main failings of longdesc is that it has only been implemented in the accessibility layer, if it is the case that browser vendors can be pursuaded to implement a UI for it that exposes the feature to any user then I suggest it would improve it. Mozilla acc engineers have recently indicated they are willing to discuss the idea. For anyone intersted in pursuing this, i suggest a talk to dave bolter etal and open in new bug.
Comment 97 Laura Carlson 2013-03-26 04:49:44 PDT
(In reply to steve faulkner from comment #96)
> (In reply to Hixie (not reading bugmail) from comment #95)
> > longdesc="" is obsolete, it was removed from HTML for very good reasons.
> > That there are people in the W3C who think otherwise is not news, but it
> > doesn't make it part of HTML again.
> > 
> > As the one who originally reported this bug, I'm marking it WONTFIX.
> 
> Like it or not Ian while longdesc is obsolete in the whatwg spec it is no
> longer obsolete in HTML , while I personally agree that there are good
> reasons for it being obsolete as currently implemented in browsers, others
> do not and there has recently been new implementations of it, in NVDA (for
> example). I consider that one of the main failings of longdesc is that it
> has only been implemented in the accessibility layer, if it is the case that
> browser vendors can be pursuaded to implement a UI for it that exposes the
> feature to any user then I suggest it would improve it. Mozilla acc
> engineers have recently indicated they are willing to discuss the idea. For
> anyone intersted in pursuing this, i suggest a talk to dave bolter etal and
> open in new bug.

Thanks Steve. I opened a new bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=854848
Comment 98 Léonie Watson 2013-03-26 05:04:54 PDT
Perhaps it's time to take a step back and look at the point of all this?

The smart and talented people who write the specs (W3C or WhatWG) make choices about what does (or doesn't) go into those specifications. The thing is that those choices often directly impact the lives of people, most of whom don't know what HTML is, may not even understand what a browser is, let alone care. In this case the choice is simple: Do we give people a way to enjoy complex images, even when they can't access the original image itself?

We've argued about longdesc for a long time, and I really don't think anyone really wants to go through all that again. It isn't a perfect solution, but it's the best damn thing we've got at the moment. So can we put some of the great ideas in this bug to good use, and solve a problem that makes a big difference to a lot of people who use this browser?

Note You need to log in before you can comment on or make changes to this bug.