549 bytes, text/html
516 bytes, text/html
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...).
Created attachment 4315 [details] Simple test, note how the top border is white just like the background
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
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
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
Last Resolved: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.