Closed Bug 85354 Opened 23 years ago Closed 23 years ago

gannett.com - anchor hover background colors are only rendered on the bottom 13 pixels of transparent GIFs

Categories

(Tech Evangelism Graveyard :: English US, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: samg0d, Assigned: bc)

References

()

Details

Attachments

(6 files)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010131 Netscape6/6.01 BuildID: 2001050518 Sample URLs: http://jobs.gannett.com/service/ala/local/FindJob/?srv=FindJob&act=ShowOptions http://jobs.gannett.com/service/mad/local/FindJob/?srv=FindJob&act=ShowOptions http://jobs.gannett.com/service/tbb/local/FindJob/?srv=FindJob&act=ShowOptions http://jobs.gannett.com/service/rdc/local/FindJob/?srv=FindJob&act=ShowOptions http://jobs.gannett.com/service/tcs/local/FindJob/?srv=FindJob&act=ShowOptions http://jobs.gannett.com/service/poc/local/FindJob/?srv=FindJob&act=ShowOptions (Run a job search for more examples if you're bored.) The icons in the upper-right corner of the page are 2-color transparent GIFs-- white and transparent. Their apparent colors are determined from their TD's background-color, which changes on :hover. In IE, the entire background of the icon changes color on rollover. In Mozilla, only the bottom 13 pixels of the images change color. The icons are actually the same image files accross all the above URLs, different only in linked CSS files. Reproducible: Always Steps to Reproduce: Move your mouse onto the icons in the upper-right corner of the provided URLs. Actual Results: The icons change color only on the bottom 13 rows of pixels. However, the bug is even more obvious in the included CSS/HTML code because it occurs before the mouse is over the icon as well. The background color appears only on the lower 13 rows of pixels of the image. Expected Results: The background color behind the full transparent area of the image should render, and change on hover, according to the CSS rule. Not just the bottom 13 rows of pixels. Images with no transparant pixels in the bottom 13 rows don't appear to change on hover. Furthermore, if the only visible color in the 2-color GIF matches the page's background color, then everything above the 13th row of pixels from the bottom is invisible. <style type="text/css"> .Icons A { background-color: #999999; } .Icons A:hover { background-color: #CC0000; } </style> <table> <td class="Icons"><A HREF="blaa"><IMG SRC="http://jobs.gannett.com/img/icons/print.gif" WIDTH="30" HEIGHT="36" BORDER="0" ALT=""></A></td> </table>
Status: UNCONFIRMED → NEW
Ever confirmed: true
See also bug 67966, a related problem involving the focus outline.
This is a dup of or depends on bug 5693 (see third testcase attached in that bug attachment 8284 [details])
Err scratch my previous comment. This bug affects even non-hovering css. I'll attach a testcase.
Attached image gif for testcase (deleted) —
Attached file testcase (deleted) —
Few questions: 1) It would seem that <img> is not inheriting <a> background-color (css) attribute. is it suppost to? 2) Or is the size of <a> incorrect? Is <a> suppost to size to contain <img> ? 3) does this work in any build of NS4? (Doesn't seem to work with NS4.71 win32) 4) does this used to work in the past in Moz? 5) this seems to work only in IE, can someone try in opera? 6) the background color seems to overlap the border drawn around the <img>. Is it suppost to be drawn in the <img> at all?
After thinking abit more and reading bug 5693 more carefully I've come up with some answers to my own questions: 2) the size of <a> is correct 3) no, since background-color is not implemented in NS4 6) It is not suppost to draw over the border. (another bug?) I'm still not sure about question 1) and 5) Note that in question 1) I meant image inheriting background-color (and maybe other css attributes) all the time, regardless whether there is :hover, :active or neither.
sorry for the spam, forgot to add self to cc
It's not only the background colour which has a problem here. Try this html: <html> <body> <a href="http://bugzilla.mozilla.org" style="border-width:thick; border-style:double"> <img src="http://bugzilla.mozilla.org/ant.jpg"> </a> </body> </html>
Attached file testcase (deleted) —
After hours of investigation, I found that Mozilla is actually displaying per css spec. Was rather busy the last few days, sorry for not getting back to this bug sooner. 1) See Ian Hickson's comment in bug 38883 for a quick solution. 2) The css spec has 2 type of boxes involved in inline elements. They are called inline boxes and line boxes. 3) Each inline element has an inline box ( see http://www.w3.org/TR/REC-CSS2/visuren.html#q7 ), sometimes anonymous inline boxes are also created ( but that has nothing to do with this bug ). 4) Each line has a line box (see http://www.w3.org/TR/REC-CSS2/visuren.html#inline-formatting ). The line box will adjust to fit all the inline boxes in it. 5) So what does that have to do with anything? Well, since the <a> element is an inline element, it has a inline box. The <img> element is also an inine element has a inline box. 6) The <a> element being a non-replaced inline element gets its height from the font height (see http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata#x41 ). 7) The <img> element is a replaced inline element in this case (see http://www.w3.org/TR/REC-CSS2/conform.html#replaced-element ) and therefore gets its height (obviously) from the image (see http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata#x16 ). 8) when you add any styles like border and background to an inline element it is applied to the "inline box", not the "line box". 9) in this bug the <img> is displayed on top of the <a>, which is expected, but due to the standard compliant behavior mentioned in 6) and 7), <a> doesn't have the height of <img> I'll post an example that demonstrates my point and some examples that works per css spec.
Attached image transparent gif (deleted) —
Attached file example (deleted) —
changing component: sorry! I forgot to change it before making all the comments above. Want to get a css expert to take a look. Should this go to evangelism later? Should there be a technote on this, I've found quite a number of bugs on this.
Component: Compositor → Style System
Sending to evangelism, should to inform webmaster. Reporter: wanna help with that?
Component: Style System → Evangelism
Reassigning to evangelism
Assignee: kmcclusk → bclary
QA Contact: petersen → zach
Priority: -- → P2
Summary: anchor hover background colors are only rendered on the bottom 13 pixels of transparent GIFs → gannett.com - anchor hover background colors are only rendered on the bottom 13 pixels of transparent GIFs
Status: NEW → ASSIGNED
Bob: could you explain what that bug is about? I don't have access to it.
Essentially layout problems. I get reports on sites both internally in bugscape and here in bugzilla. I am just trying to consolidate them so I can manage the two databases better. Unfortunately bugzilla does not support duplicates between multiple databases.
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
follow up with these sites by 0.9.5
Target Milestone: --- → mozilla0.9.5
-> 0.9.6, need to follow up on these asap
Target Milestone: mozilla0.9.5 → mozilla0.9.6
fixed, seems to have changed layout. reopen if you still find a site with this
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified 2002022703/WinXP
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: