Closed
Bug 1996
(longdesc)
Opened 26 years ago
Closed 12 years ago
Support LONGDESC for IMG
Categories
(SeaMonkey :: UI Design, enhancement, P4)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: ian, Unassigned)
References
()
Details
(4 keywords, Whiteboard: [bae:20011119][parity-opera])
Attachments
(3 files, 1 obsolete file)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
sicking
:
review+
jag+mozilla
:
superreview-
|
Details | Diff | Splinter Review |
(deleted),
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
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.
We do, you can access it through the DOM. See GetLongDesc() and SetLongDesc() in
nsIDOMHTMLImageElement or the W3C DOM spec
Reporter | ||
Updated•26 years ago
|
Reporter | ||
Comment 3•26 years ago
|
||
Page moved. Updating uri.
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
Updated•26 years ago
|
QA Contact: 1698
Comment 5•26 years ago
|
||
QA Assigning to self.
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 6•26 years ago
|
||
Verifying 'REMIND'.
Reporter | ||
Updated•26 years ago
|
Status: VERIFIED → REOPENED
Reporter | ||
Comment 7•26 years ago
|
||
Since bug 1995 is now under consideration, and it is very similar, I am
reopening this bug.
Reporter | ||
Updated•26 years ago
|
Severity: minor → enhancement
Resolution: REMIND → ---
Reporter | ||
Comment 8•26 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.
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → REMIND
This still isn't going to get implemented for version 1.0 so I'm marking it back
as REMIND
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 10•26 years ago
|
||
Rubberstamping as verified/REMIND.
Reporter | ||
Comment 11•25 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•25 years ago
|
||
Reassigning...
Assignee: troy → nobody
Status: REOPENED → NEW
Target Milestone: --- → Future
Comment 13•25 years ago
|
||
Added a depend on Bug 42066. GetLongDesc() only returns a relative URI right
now, and it needs to return an absolute URI.
Reporter | ||
Comment 14•24 years ago
|
||
Taking QA per managerial policy.
QA Contact: elig → py8ieh=bugzilla
Comment 15•24 years ago
|
||
Comment 16•24 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.
Comment 17•24 years ago
|
||
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•24 years ago
|
||
Comment 19•24 years ago
|
||
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•24 years ago
|
||
This patch has been sitting here a while. Should "review" be added?
Keywords: mozilla1.1
Comment 21•24 years ago
|
||
Actually, I think it's been obsoleted by the patch for bug 1995, which seems to
have stalled in review.
Reporter | ||
Comment 22•24 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...
Comment 23•24 years ago
|
||
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•24 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•24 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
Comment 27•24 years ago
|
||
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•24 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•24 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•24 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
Comment 31•24 years ago
|
||
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•24 years ago
|
||
Check out bug 74121, which is about cleaning up the Properties window to be more
UI friendly and logical...
Reporter | ||
Updated•24 years ago
|
Whiteboard: [Hixie-P4]
Comment 33•24 years ago
|
||
Bug 3658 is for frame/iframe longdesc support
Summary: Support LONGDESC for IMG and FRAME → Support LONGDESC for IMG
Comment 34•24 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 36•23 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
Closed: 26 years ago → 23 years ago
Keywords: testcase
Resolution: --- → FIXED
Whiteboard: [Hixie-P4] → [bae:20011119][Hixie-P4]
Comment 37•23 years ago
|
||
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•23 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•22 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?
Comment 40•22 years ago
|
||
I agree; the link to the longdesc URI should be functional. Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 41•22 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•22 years ago
|
||
this looks like something I could fix someday so adding CC
Comment 43•22 years ago
|
||
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•22 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 45•22 years ago
|
||
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•22 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•22 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.
Comment 48•22 years ago
|
||
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•22 years ago
|
||
Shouldn't you be able to right click the link and choose "Copy"?
Comment 50•22 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•22 years ago
|
||
This patch uses a button instead for the onclick event. However, the URL text
is sometimes truncated. Ideas?
Comment 53•22 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•22 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•22 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•22 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•22 years ago
|
||
*** Bug 197025 has been marked as a duplicate of this bug. ***
Comment 58•22 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•22 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•21 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•20 years ago
|
Keywords: mozilla1.1
QA Contact: pawyskoczka → ian
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 61•20 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: context-menu-cursor
Comment 62•20 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•20 years ago
|
Assignee: guifeatures → aaronleventhal
Comment 63•20 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•20 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•20 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•19 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•19 years ago
|
||
*** Bug 321622 has been marked as a duplicate of this bug. ***
Updated•17 years ago
|
Alias: longdesc
Comment 68•17 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•17 years ago
|
||
It looks like this bug was filed against the Mozilla Application Suite (SeaMonkey). Bug 216086 was for Firefox.
Comment 70•17 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•17 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•17 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•17 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•16 years ago
|
Component: UI Design → DOM: Core & HTML
Product: SeaMonkey → Core
QA Contact: ian → general
Updated•16 years ago
|
Component: DOM: Core & HTML → UI Design
Product: Core → SeaMonkey
QA Contact: general → ui-design
Comment 74•16 years ago
|
||
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Shouldn't this be WONTFIX now that HTML5 obsoletes longdesc?
Comment 76•14 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•14 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•14 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•13 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
Closed: 23 years ago → 13 years ago
Resolution: --- → WONTFIX
Comment 81•13 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•13 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•13 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•13 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•12 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•12 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•12 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•12 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•12 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•12 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•12 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•12 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•12 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•12 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
Closed: 13 years ago → 12 years ago
Resolution: --- → WONTFIX
Whiteboard: [bae:20011119][Hixie-P4][parity-opera] → [bae:20011119][parity-opera]
Comment 96•12 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•12 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•12 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.
Description
•