Closed Bug 3658 (frame-longdesc) Opened 25 years ago Closed 2 years ago

UAAG: frame/iframe longdesc attribute not used [frame]

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: glynn, Unassigned)

References

()

Details

(Keywords: access, html4, testcase, Whiteboard: [HTML4-16.2.2][HTML4-16.5])

Attachments

(3 files)

March 11 Seamonkey builds, Mac 8.5/G3, Linux 5.2,  optimized, viewer
March 10 win98  optimized, viewer

1.  Launch Seamonkey and load test case page:
slip/projects/marvin/html/frameset_longdesc.html
2.  These frames include longdesc attributes; it is unclear even per HTML 4.0
spec what the user should see when this attribute is used.

•  What should the user experience here when the longdesc attribute is used?
Need clarification on this from engineering to determine A) if this is indeed a
functional failure B) to refine test case.
Assignee: rickg → kipp
Component: Parser → Layout
Beth -- HOW we handle attributes is not a parser problem. It's core layout.
Passing these on to Kipp.
I filed these all in one lump..hence why all were marked parser..will mark layout
for this variety in future.
Assignee: kipp → karnaze
Status: ASSIGNED → NEW
Chris owns the frameset code so reassigning...
Assignee: karnaze → pollmann
Eric is working on frameset related DOM changes which will include longdesc, so
I'm reassigning this to him to make sure that getting and setting this attribute
works.

However, what the viewport display does with this is not clear to me and maybe
Troy has some insight, since it is related to what the viewport will need to do
with the title attribute.
Status: NEW → ASSIGNED
This is treated as the longdesc attribute on an img tag, which is to say it
isn't yet.

The attribute is stored in the content model correctly (as can be seen by
dumping the content model.  However, when the DOM methods are used to access it,
an empty string is returned.

After the document is loaded, the longdesc attribute can be set and retrieved
through the DOM, but has no effect on either the content model or the display of
the document.

(This behaviour was observed at http://blueviper/frames/test.html)
Target Milestone: M6
Redistributing to M8...
Didn't make M8
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → REMIND
Summary: frame/iframe longdesc attribute implementation unclear → frame/iframe longdesc attribute not used
This doesn't seem like a dogfood, beta, or final ship requirement to me, but
more like an accessability enhancement.  We are already storing the attribute in
the content model, I think that should be enough for a while.

Perhaps we should leave this up to the creator of an enhanced browser that
embeds gecko to get then use the longdesc file as needed.  Closing the bug open
as remind.

If anyone things this should be addressed now or before ship, please reopen and
suggest how we should handle the longdesc attribute.
Reopening and moving to Future...
Severity: major → normal
Status: RESOLVED → REOPENED
OS: Windows 98 → All
Resolution: REMIND → ---
Target Milestone: M11 → Future
Keywords: access
Keywords: html4
not my area, reassigning to vladimire
QA Contact: janc → vladimire
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov
Status: REOPENED → NEW
Summary: frame/iframe longdesc attribute not used → frame/iframe longdesc attribute not used [frame]
The longdesc attribute is now supported with a img element. That procedure
should similarly work with iframe/frame elements. Right clicking on a iframe or
frame should display a popup menu that includes a View Frame info item.
Selecting this menu item should open a dialog that includes the specified
longdesc uri.
removing myself from the cc list
Whiteboard: [HTML4-16.2.2][HTML4-16.5]
Component: Layout → Layout: HTML Frames
Keywords: qawanted
->
Assignee: alexsavulov → frame
QA Contact: vladimire → amar
->Page Info I guess
Assignee: frame → db48x
Depends on: 47534
Attached file Testcase
Keywords: testcase
Reporter, please try a newer build.  This bug is getting quite old and will be
marked invalid if some action does not occur shortly.

-R
Alias: frame-longdesc
*** Bug 321623 has been marked as a duplicate of this bug. ***
Summary: frame/iframe longdesc attribute not used [frame] → UAAG: frame/iframe longdesc attribute not used [frame]
Blocks: uaag
QA Contact: amar → layout.html-frames
Shouldn't this be WONTFIX now that HTML5 obsoletes longdesc?
Since this is a 4 digit bug, I don't know that it matters whether HTML5 obsoletes longdesc here. But, note that for iframe HTML5 also obsoletes: frameborder, marginheight, marginwidth, and scrolling. I think if we don't have, or remove processing for those, then we should close this bug.
That's not quite right; it still requires that they be implemented by browsers (with the exception of "scrolling", no idea what that needs to do).
Removing QAwanted from this bug since it didn't come with any specific request and it was added 11 years ago. Please re-add if you need anything specific from QA.
Keywords: qawanted
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: db48x → nobody
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 10 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)
Status: NEW → RESOLVED
Closed: 25 years ago2 years ago
Flags: needinfo?(emilio)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: