Closed Bug 24224 Opened 25 years ago Closed 23 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED INVALID
Milestone:
Future

People

(Reporter: rods, Assigned: attinasi)

References

Details

Attachments

(2 files)

Simple test, note how the top border is white just like the background
549 bytes, text/html
Details
Oops, here is a test were the bg color of the page defaults
516 bytes, text/html
Details 
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.
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...).
Blocks: 1021
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
Status: NEW → ASSIGNED
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
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M20
Moving waaay off into the future.
Target Milestone: M20 → Future
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
as

  <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
*** Bug 108351 has been marked as a duplicate of this bug. ***
Closing as INVALID: see Additional Comments From Braden 2000-06-27 22:29 with
which I am in complete agreement.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: