Bug 1996 (longdesc)

Support LONGDESC for IMG

RESOLVED WONTFIX

Status

SeaMonkey
UI Design
P4
enhancement
RESOLVED WONTFIX
19 years ago
3 years ago

People

(Reporter: Hixie (not reading bugmail), Unassigned)

Tracking

(Depends on: 1 bug, 4 keywords)

Trunk
access, helpwanted, html4, testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bae:20011119][parity-opera], URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

19 years ago
(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

Updated

19 years ago
Assignee: kipp → troy

Comment 1

19 years ago
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.

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 2

19 years ago
We do, you can access it through the DOM. See GetLongDesc() and SetLongDesc() in
nsIDOMHTMLImageElement or the W3C DOM spec
(Reporter)

Updated

19 years ago
(Reporter)

Comment 3

19 years ago
Page moved. Updating uri.

Updated

19 years ago
Status: RESOLVED → REOPENED

Updated

19 years ago
Status: REOPENED → ASSIGNED

Updated

19 years ago
Resolution: WORKSFORME → ---

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → REMIND

Comment 4

19 years ago
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

Updated

19 years ago
QA Contact: 1698

Comment 5

19 years ago
QA Assigning to self.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 6

19 years ago
Verifying 'REMIND'.
(Reporter)

Updated

18 years ago
Status: VERIFIED → REOPENED
(Reporter)

Comment 7

18 years ago
Since bug 1995 is now under consideration, and it is very similar, I am
reopening this bug.
(Reporter)

Updated

18 years ago
Severity: minor → enhancement
Resolution: REMIND → ---
(Reporter)

Comment 8

18 years ago
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.

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → REMIND

Comment 9

18 years ago
This still isn't going to get implemented for version 1.0 so I'm marking it back
as REMIND

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 10

18 years ago
Rubberstamping as verified/REMIND.
(Reporter)

Updated

18 years ago
Blocks: 7954
(Reporter)

Updated

18 years ago
Blocks: 16501
(Reporter)

Comment 11

17 years ago
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. :-)
Status: VERIFIED → REOPENED
Component: Layout → User Interface: Design Feedback
Keywords: helpwanted
OS: Windows 95 → All
Hardware: PC → All
Resolution: REMIND → ---
(Reporter)

Comment 12

17 years ago
Reassigning...
Assignee: troy → nobody
Status: REOPENED → NEW
Target Milestone: --- → Future

Updated

17 years ago
Depends on: 42066

Comment 13

17 years ago
Added a depend on Bug 42066.  GetLongDesc() only returns a relative URI right 
now, and it needs to return an absolute URI.
Keywords: access
(Reporter)

Comment 14

17 years ago
Taking QA per managerial policy.
QA Contact: elig → py8ieh=bugzilla

Comment 15

17 years ago
Changing dependency on bug 42066 to bug 47534, since this takes over the
problem of longdesc (among others) returning a relative URL.
Depends on: 47534
No longer depends on: 42066

Updated

17 years ago
Keywords: html4

Comment 16

17 years ago
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.

Updated

17 years ago
Blocks: 1995
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?
Created attachment 20507 [details] [diff] [review]
patch to add longdesc & cite support
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.

Updated

17 years ago
Keywords: patch
This patch has been sitting here a while.  Should "review" be added?
Keywords: mozilla1.1
Actually, I think it's been obsoleted by the patch for bug 1995, which seems to
have stalled in review.
(Reporter)

Comment 22

17 years ago
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...
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.
(Reporter)

Comment 24

17 years ago
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

17 years ago
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...
QA Contact: ian → zach
Them longdesc metainfo is now avalible through the "properties" window from
bug 1995, so feel free to mark as fixed
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

17 years ago
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

17 years ago
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

17 years ago
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.
Assignee: nobody → mpt
Component: User Interface: Design Feedback → HTML Element
Keywords: patch
Summary: IMG longdesc support missing. → Support LONGDESC for IMG and FRAME
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

17 years ago
Check out bug 74121, which is about cleaning up the Properties window to be more
UI friendly and logical...
(Reporter)

Updated

17 years ago
Whiteboard: [Hixie-P4]

Updated

16 years ago
Blocks: 41368

Comment 33

16 years ago
Bug 3658 is for frame/iframe longdesc support
Summary: Support LONGDESC for IMG and FRAME → Support LONGDESC for IMG

Comment 34

16 years ago
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).
Assignee: mpt → karnaze
Component: HTML Element → Layout
QA Contact: zach → petersen

Comment 35

16 years ago
not a table bug, over to attinasi
Assignee: karnaze → attinasi

Comment 36

16 years ago
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
Status: NEW → RESOLVED
Last Resolved: 18 years ago16 years ago
Keywords: testcase
Resolution: --- → FIXED
Whiteboard: [Hixie-P4] → [bae:20011119][Hixie-P4]

Comment 37

16 years ago
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

16 years ago
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
Status: RESOLVED → VERIFIED

Comment 39

15 years ago
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?
I agree; the link to the longdesc URI should be functional. Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 41

15 years ago
And this is related to "layout" _HOW_ exactly?  ;)
Assignee: attinasi → blaker
Status: REOPENED → NEW
Component: Layout → XP Apps: GUI Features
QA Contact: petersen → paw

Comment 42

14 years ago
this looks like something I could fix someday so adding CC

Comment 43

14 years ago
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.
Attachment #20507 - Attachment is obsolete: true

Comment 44

14 years ago
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
Attachment #123948 - Flags: superreview?(caillon)
Attachment #123948 - Flags: review?(bugmail)
Attachment #123948 - Flags: approval1.4?
Comment on attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

Sorry.	I'm not a superreviewer.  Try jag.
Attachment #123948 - Flags: superreview?(caillon) → superreview?(jaggernaut)

Comment 46

14 years ago
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

14 years ago
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.
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?
(Reporter)

Comment 49

14 years ago
Shouldn't you be able to right click the link and choose "Copy"?

Comment 50

14 years ago
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 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
Attachment #123948 - Flags: review?(bugmail) → review+

Comment 52

14 years ago
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

14 years ago
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

14 years ago
Comment on attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

unsetting approval request until this has reviews.
Attachment #123948 - Flags: approval1.4?

Comment 55

14 years ago
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

14 years ago
(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

14 years ago
*** Bug 197025 has been marked as a duplicate of this bug. ***

Comment 58

14 years ago
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.
Attachment #123948 - Flags: superreview?(jaggernaut) → superreview-

Comment 59

14 years ago
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

14 years ago
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.
Assignee: firefox → guifeatures
Target Milestone: Future → ---

Updated

13 years ago
Keywords: mozilla1.1
QA Contact: pawyskoczka → ian
Product: Core → Mozilla Application Suite

Comment 61

13 years ago
(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.
Depends on: 258960

Comment 62

13 years ago
(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.)

Updated

13 years ago
Assignee: guifeatures → aaronleventhal

Comment 63

13 years ago
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

13 years ago
(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

13 years ago
(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

12 years ago
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

12 years ago
*** Bug 321622 has been marked as a duplicate of this bug. ***

Updated

10 years ago
Alias: longdesc

Comment 68

9 years ago
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

9 years ago
It looks like this bug was filed against the Mozilla Application Suite (SeaMonkey). Bug 216086 was for Firefox.

Comment 70

9 years ago
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

9 years ago
(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

9 years ago
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

9 years ago
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

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design

Updated

9 years ago
Component: UI Design → DOM: Core & HTML
Product: SeaMonkey → Core
QA Contact: ian → general

Updated

9 years ago
Component: DOM: Core & HTML → UI Design
Product: Core → SeaMonkey
QA Contact: general → ui-design
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody

Updated

8 years ago
Flags: wanted1.9.2?

Updated

8 years ago
Flags: wanted1.9.2?
Shouldn't this be WONTFIX now that HTML5 obsoletes longdesc?

Comment 76

7 years ago
Why?  Shouldn't SeaMonkey still support HTML 4?
(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

7 years ago
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

7 years ago
> 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

5 years ago
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
Status: NEW → RESOLVED
Last Resolved: 16 years ago5 years ago
Resolution: --- → WONTFIX

Comment 81

5 years ago
(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?
(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

5 years ago
(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

5 years ago
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

5 years ago
(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

5 years ago
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

5 years ago
(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

5 years ago
Phillip's reason for closure was incorrect. Putting parity-opera on the whiteboard.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [bae:20011119][Hixie-P4] → [bae:20011119][Hixie-P4][parity-opera]

Comment 89

5 years ago
> 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

5 years ago
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

5 years ago
(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

5 years ago
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

4 years ago
(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

4 years ago
> 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
(Reporter)

Comment 95

4 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago4 years ago
Resolution: --- → WONTFIX
Whiteboard: [bae:20011119][Hixie-P4][parity-opera] → [bae:20011119][parity-opera]

Comment 96

4 years ago
(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

4 years ago
(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

4 years ago
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?
You need to log in before you can comment on or make changes to this bug.