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)
Tracking
()
RESOLVED
INVALID
Future
People
(Reporter: rods, Assigned: attinasi)
References
Details
Attachments
(2 files)
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.
|
Assignee | |
Comment 1•25 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...).
|
Reporter | |
Comment 2•25 years ago
|
||
|
|
Reporter | |
Comment 3•25 years ago
|
||
|
|
Assignee | |
Comment 4•25 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
|
||
Updated•25 years ago
|
Status: NEW → ASSIGNED
|
|
||
Comment 5•25 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
Status: ASSIGNED → NEW
|
|
Assignee | |
Updated•25 years ago
|
Status: NEW → ASSIGNED
|
|
Assignee | |
Updated•25 years ago
|
Target Milestone: M20
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.
|
||
Comment 8•25 years ago
|
||
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.
|
|
||
Comment 9•24 years ago
|
||
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
|
|
Assignee | |
Comment 10•23 years ago
|
||
*** Bug 108351 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Comment 11•23 years ago
|
||
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.
Description
•