Open Bug 3658 (frame-longdesc) Opened 23 years ago Updated 3 years ago
UAAG: frame/iframe longdesc attribute not used [frame]
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.
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.
Chris owns the frameset code so reassigning...
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.
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)
Redistributing to M8...
Didn't make M8
Status: ASSIGNED → RESOLVED
Closed: 22 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
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
Assignee: alexsavulov → frame
QA Contact: vladimire → amar
->Page Info I guess
Assignee: frame → db48x
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
*** 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]
The previous URL http://slip/projects/marvin/html/frameset_longdesc.html is now "Not Found 404" Replacing with http://www.w3.org/WAI/UA/TS/html401/cp0203/0203-FRAME-LONGDESC-TEST.html
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.
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.