Closed Bug 1996 (longdesc) Opened 26 years ago Closed 11 years ago

Support LONGDESC for IMG

Categories

(SeaMonkey :: UI Design, enhancement, P4)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: ian, Unassigned)

References

(
URL
)

Details

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

Attachments

(3 files, 1 obsolete file)

test case to use for verification
557 bytes, text/html
Details
fixing regression from 101910 to make links clickable again
2.12 KB, patch
sicking
: review+
jag+mozilla
: superreview-
Details | Diff | Splinter Review
this one uses a button instead
3.48 KB, patch
Details | Diff | Splinter Review 
(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
Assignee: kipp → troy
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.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
We do, you can access it through the DOM. See GetLongDesc() and SetLongDesc() in
nsIDOMHTMLImageElement or the W3C DOM spec
Page moved. Updating uri.
Status: RESOLVED → REOPENED
Status: REOPENED → ASSIGNED
Resolution: WORKSFORME → ---
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → REMIND
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
QA Contact: 1698
QA Assigning to self.
Status: RESOLVED → VERIFIED
Verifying 'REMIND'.
Status: VERIFIED → REOPENED
Since bug 1995 is now under consideration, and it is very similar, I am
reopening this bug.
Severity: minor → enhancement
Resolution: REMIND → ---
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.
Status: REOPENED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → REMIND
This still isn't going to get implemented for version 1.0 so I'm marking it back
as REMIND
Status: RESOLVED → VERIFIED
Rubberstamping as verified/REMIND.
Blocks: html4.01
Blocks: 16501
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 → ---
Reassigning...
Assignee: troy → nobody
Status: REOPENED → NEW
Target Milestone: --- → Future
Depends on: 42066
Added a depend on Bug 42066.  GetLongDesc() only returns a relative URI right 
now, and it needs to return an absolute URI.
Keywords: access
Taking QA per managerial policy.
QA Contact: elig → py8ieh=bugzilla
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
Keywords: html4
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.
Blocks: metadata
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?
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.
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.
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.
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.
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?
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)
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. 

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).
Check out bug 74121, which is about cleaning up the Properties window to be more
UI friendly and logical...
Whiteboard: [Hixie-P4]
Blocks: robin's
Bug 3658 is for frame/iframe longdesc support
Summary: Support LONGDESC for IMG and FRAME → Support LONGDESC for IMG
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
not a table bug, over to attinasi
Assignee: karnaze → attinasi
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
Closed: 25 years ago → 23 years ago
Keywords: testcase
Resolution: --- → FIXED
Whiteboard: [Hixie-P4] → [bae:20011119][Hixie-P4]
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
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
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 → ---
And this is related to "layout" _HOW_ exactly?  ;)
Assignee: attinasi → blaker
Status: REOPENED → NEW
Component: Layout → XP Apps: GUI Features
QA Contact: petersen → paw
this looks like something I could fix someday so adding CC
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 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 on attachment 123948 [details] [diff] [review]
fixing regression from 101910 to make links clickable again

changing superreiver request, caillon's not superreviewer
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?
Shouldn't you be able to right click the link and choose "Copy"?
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+
This patch uses a button instead for the onclick event.  However, the URL text
is sometimes truncated.  Ideas?
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 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?
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?
(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?
*** Bug 197025 has been marked as a duplicate of this bug. ***
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-
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.
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 → ---
Product: Core → Mozilla Application Suite
(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: context-menu-cursor
(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.)
Assignee: guifeatures → aaronleventhal
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


(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 


(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
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. 
*** Bug 321622 has been marked as a duplicate of this bug. ***
Alias: longdesc
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.
It looks like this bug was filed against the Mozilla Application Suite (SeaMonkey). Bug 216086 was for Firefox.
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."
(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. :) 

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
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
Component: XP Apps: GUI Features → UI Design
Component: UI Design → DOM: Core & HTML
Product: SeaMonkey → Core
QA Contact: ian → general
Component: DOM: Core & HTML → UI Design
Product: Core → SeaMonkey
QA Contact: general → ui-design
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Flags: wanted1.9.2?
Flags: wanted1.9.2?
Shouldn't this be WONTFIX now that HTML5 obsoletes longdesc?
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.
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.
> 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
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
Closed: 23 years ago → 12 years ago
Resolution: --- → WONTFIX
(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.
(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.
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.
(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."
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
(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
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]
> 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?
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
(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.
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
(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.
> 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
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
Closed: 12 years ago → 11 years ago
Resolution: --- → WONTFIX
Whiteboard: [bae:20011119][Hixie-P4][parity-opera] → [bae:20011119][parity-opera]
(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.
(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
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.

Attachment

General

Creator:
Created:
Updated:
Size: