border disappears when buttonhighlight and the default page color are the same




19 years ago
17 years ago


(Reporter: rods, Assigned: attinasi)


Windows NT

Firefox Tracking Flags

(Not tracked)



(2 attachments)



19 years ago
CSS provides several keywords for setting the colors for the border. In some
cases this causes the border to disappear when standard settings are used.

Comment 1

19 years ago
The problem is when the buttonhighlight (or buttonshadow) color and the window
color are the same. In this case the control does not appear to be inset or
outset as it should because the buttonhighlight blends into the page color.

In IE (and Windows) the control painting used to do inset and outset utilize two
shades of highlight and shadow, thus even if the page is the same color as the
highlight (or shadow) there is still the visual appearance of an inset/outset
due to the secondary shadow or highlight color.

A possible solution is to implement another metric in nsLookAndFeel where the
number of widget 3D border colors can be specified. For Windows this would be 2
to more closely simulate the look for native Windows widgets.

Another possible solution is to offset the buttonhighlight or buttonshadow
border color if they match the color of the page. This is a hack that will cause
bugs when somebody wants the borders to be the same color as the page (why would
somebody want that? I don't know...).

Comment 2

19 years ago
Created attachment 4315 [details]
Simple test, note how the top border is white just like the background

Comment 3

19 years ago
Created attachment 4316 [details]
Oops, here is a test were the bg color of the page defaults


19 years ago
Blocks: 1021

Comment 4

19 years ago
This is a border-painting issue so we'll let the border-painting expert have a 
stab at it...

An additional note: maybe the simplest solution is just to use two colors for 
border-sides that have the buttonshadow and buttonhighlight color set (assuming 
they are at least 2px in thickness). The second color could be 20% lighter or 
darker than the specified color, or it could just be white or black depending on 
the actual color of the buttonhighlight or buttonshadow.
Assignee: attinasi → dcone


19 years ago

Comment 5

19 years ago
By the time the border drawing code gets called, the colors are resolved, and a 
solid border is being draw.  Style needs to inform the border drawing code that 
a button color is needed.. and then we can do the special code to draw with two 
slightly different colors.
Assignee: dcone → attinasi


19 years ago


19 years ago
Target Milestone: M20

Comment 6

19 years ago
Moving waaay off into the future.
Target Milestone: M20 → Future

Comment 7

19 years ago
I'd like to propose that this be resolved INVALID.

I really don't think this is a bug. There are all sorts of places in CSS where
adjacent colors can potentially collide--this case is not unique. I don't think
it's a case of UA error, either--it's the page/stylesheet author's fault, just

  <body bgcolor="#ffffff" text="#ffffff">

is the page author's fault.

I don't think automatically multicolored borders are the answer. I don't like
them in IE; and I think if a particular color for a border is requested, that
(and only that) is the color it should be drawn with.
I would tend to agree, except that the idea about using another metric in 
nsLookAndFeel where the number of widget 3D border colors can be specified 
sounds like a good one, especially since that was probably the intent of the
UI-specific border keywords.

So for "groove" "inset" and so on we would not do anything special, but for
the UI border keywords we would make the border match the UI.
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian

Comment 10

17 years ago
*** Bug 108351 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
Closing as INVALID: see Additional Comments From Braden 2000-06-27 22:29 with
which I am in complete agreement.
Last Resolved: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.