Closed
Bug 22624
Opened 25 years ago
Closed 25 years ago
Input type = image buttons
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
VERIFIED
INVALID
People
(Reporter: st8, Assigned: rods)
Details
Attachments
(1 file)
268 bytes,
text/html
|
Details |
My version of Netscape, when I hover over an INPUT type="image" button, the little yellow appearing box, that should display the contents of the ALT field, displays the image name instead!!!
Comment 2•25 years ago
|
||
If I understood you correctly, you're describing a bug present in Netscape Navigator 4. This bug report forum handles bugs about Mozilla, Netscapes Next Generation browser engine.
Updated•25 years ago
|
Assignee: karnaze → rods
Comment 3•25 years ago
|
||
Reassigning to Rod.
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
QA Contact: ckritzer → elig
Resolution: --- → INVALID
Comment 4•25 years ago
|
||
Actually, what is displayed is not the image name, but the value of the NAME attribute for IMG. Note that while Communicator does display the value of NAME in preference to the value of ALT in hover-tooltips, the HTML 4 spec says that NAME is to be used as an identifier for scripting, and ID should really be used instead: see under "name" in http://www.w3.org/TR/html401/struct/objects.html#h-13.2 There is really a design decision here: in what order should NAME, LONGDESC, and ALT be drawn upon to provide tooltip content, and should a TITLE attribute, if present, be used, ever? (TITLE is an IE-ism, IIRC, and also displaces ALT) Currently, Mozilla is not displaying the contents of any IMG attribute in tooltips while hovering over images, so this can't be a Mozilla bug. Tested with: 1999-12-25-08-M13 nightly binary on Windows NT 4.0sp3 1999-12-25-08-M13 nightly binary on Redhat Linux 6.1 (gnome+enlight) Communicator 4.7 on Windows NT 4.0sp3 Marking INVALID. Changing component from "HTML Form Controls" to "UE/UI" in case the order in which IMG attributes are used to provide tooltip content has not been specified yet.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 5•25 years ago
|
||
Agreed with Sean: * verified as invalid on basis of bug not being reported against Mozilla * there's another bug (reported by Ian Hickson) which covers the expected behavior for this scenario in depth. Either way, we will be following the relevant HTML 4 specification 100% by the time Seamonkey ships.
You need to log in
before you can comment on or make changes to this bug.
Description
•