Last Comment Bug 50699 - CSS inset and outset are ugly
: CSS inset and outset are ugly
Status: NEW
: css1, helpwanted, polish, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P3 enhancement with 7 votes (vote)
: Future
Assigned To: Jerry Baker
: Jet Villegas (:jet)
: 431182 (view as bug list)
Depends on:
Blocks: 225314
  Show dependency treegraph
Reported: 2000-08-29 12:53 PDT by Jerry Baker
Modified: 2011-08-24 10:30 PDT (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

So much nicer in IE. (577 bytes, text/html)
2000-08-29 12:54 PDT, Jerry Baker
no flags Details
For you folks on *nix - a screen capture (1.19 KB, image/png)
2000-08-29 12:59 PDT, Jerry Baker
no flags Details
IE's rendering - a thing of beauty (5.13 KB, image/png)
2000-08-30 07:53 PDT, Matthew Brealey
no flags Details
Mozilla's rendering - ugly (5.44 KB, image/png)
2000-08-30 07:53 PDT, Matthew Brealey
no flags Details
HTML source (157 bytes, text/html)
2000-08-30 07:54 PDT, Matthew Brealey
no flags Details
Borders rendered by IE,NS4.6, Mozilla Strict, Mozilla Combatible (24.87 KB, image/png)
2001-01-31 05:12 PST, Martin Horwath
no flags Details
html file i used for the screenshots (910 bytes, text/html)
2001-01-31 05:17 PST, Martin Horwath
no flags Details

Description Jerry Baker 2000-08-29 12:53:38 PDT
Open attachment in IE5 and Mozilla. Compare Mozilla's absolutely ugly rendering 
compared to IE5.
Comment 1 Jerry Baker 2000-08-29 12:54:13 PDT
Created attachment 13693 [details]
So much nicer in IE.
Comment 2 Jerry Baker 2000-08-29 12:59:07 PDT
Created attachment 13694 [details]
For you folks on *nix - a screen capture
Comment 3 Hixie (not reading bugmail) 2000-08-29 14:57:23 PDT
Jerry: Could you work out a better algorithm for us that we could implement?
At the moment we are taking the simple strategy of using slightly darker and
slightly brighter colours for the two sides, but if you could find an algorithm
that draws nicer bevels I'm sure we could use it.
Comment 4 Jerry Baker 2000-08-29 16:11:20 PDT
It's not exactly a mathematical algorithm, but it is an algorithm:

1. Take the border size and halve it - [border size] / 2
2. Construct two borders, each one the width of the result of step 1.
3. Color them as follows
     a. For outset
          1. Outermost border-left and border-top are the same color
             as the background-color of the element being bordered.
          2. Innermost border-left and border-top are the color of 
          3. Outermost border-right and border-bottom are the color of
          4. Innermost border-right and border-bottom are the color of
     b. For inset
          1. Outermost border-left and border-top are the same color
             as "buttonshadow".
          2. Innermost border-left and border-top are the color of 
          3. Outermost border-right and border-bottom are the color of
          4. Innermost border-right and border-bottom are the color of

I was noticing that these colors could have some interesting results on buttons 
colored black, for instance, but it keeps with the user's OS and how it does 3D 
objects. That is to say that this is how an "inset" or "outset" object would 
look if created by the user's OS natively.
Comment 5 Jerry Baker 2000-08-29 16:13:02 PDT
I forgot to add that "inset", "outset", "ridge", and "groove" necessarily cannot 
be less than two pixels, so they should always be drawn as at least two pixels.
Comment 6 Jerry Baker 2000-08-29 16:17:05 PDT
Jeez. Also:

When [border size] / 2 = a fraction, give the outer borders the remainder. For 
example a border width of 3 would make 2px outermost border and 1px innermost.
Comment 7 Hixie (not reading bugmail) 2000-08-29 17:16:51 PDT
That algorithm does not match what the CSS spec requires us to do with respect
to colouring, as far as I can tell. Also, if we have border-width: 1px, then
we are not allowed to make it 2px wide. And finally, a 1px inset/outset border
is perfectly feasible.

More in e-mail :-)
Comment 8 Jerry Baker 2000-08-29 17:28:33 PDT
That depends on whether the statement "The color of borders drawn for values of 
'groove', 'ridge', 'inset', and 'outset' depends on the element's color 
property" is an informative statement or declarative one. How do we tell?

I can't imagine that the W3C meant to contradict themselves. The whole point of 
integration with the users OS UI is to allow things to appear in a Web page the 
same as they do on the OS. Why would the W3C then go right ahead and make that 
impossible right in the same section that they are trying to accomplish this?
Comment 9 Hixie (not reading bugmail) 2000-08-29 17:45:58 PDT
eek. That's a mistake. I'll get that fixed.
Comment 10 Jerry Baker 2000-08-29 18:22:00 PDT
Note: RFC posted to w/regards to this. It can be viewed at
Comment 11 Hixie (not reading bugmail) 2000-08-30 01:46:02 PDT
Jerry: When I said "I'll get that fixed"... I brought up the same issue in the
internal W3C working group mailing list about 30 minutes before you e-mailed
the public list. :-)

I sent further comments to the list.
Comment 12 Jerry Baker 2000-08-30 07:13:48 PDT
So does that mean if an errata is produced for the spec that if someone is 
willing to implement this change that it will not violate the spec anymore?
Comment 13 Matthew Brealey 2000-08-30 07:53:09 PDT
Created attachment 13731 [details]
IE's rendering - a thing of beauty
Comment 14 Matthew Brealey 2000-08-30 07:53:37 PDT
Created attachment 13732 [details]
Mozilla's rendering - ugly
Comment 15 Matthew Brealey 2000-08-30 07:54:05 PDT
Created attachment 13733 [details]
HTML source
Comment 16 Matthew Brealey 2000-08-30 08:01:21 PDT
Colour is #ff0000. Mozilla does #8d0000 and #ffb2b2. IE does #be0000 and 
#7f0000. Opera does the same. As you can see, IE's is attractive whereas 
Mozilla's is horrible.
Comment 17 Hixie (not reading bugmail) 2000-08-30 10:55:00 PDT
Thanks, Matthew, that really helps us determine a good algorithm. </sarcasm>
Oh, and BTW, this bug is talking about 'inset' and 'outset' -- where the
difference is a lot more important. (In the case of 'ridge' as in the 3rd to
5th attachments, Mozilla is arguably doing a better job, since it is trying
to give the impression that the border is bright red - #F00 - rather than 
maroon - #700 - like Internet Explorer. I do agree that for darker values,
Mozilla is doing a poorer job at selecting colours, though.)

Jerry: The spec has been errata'ed. now says:
#   8.5.3 Border style
#   Change the sentence "The color of borders drawn for values 
#   of 'groove', 'ridge', 'inset', and 'outset' depends on the 
#   element's 'color' property" to 
#      The color of borders drawn for values of 'groove', 'ridge', 'inset', 
#      and 'outset' should be based on the element's 'border-color' property, 
#      but UAs may choose their own algorithm to calculate the actual colors 
#      used. For instance, if the 'border-color' has the value 'silver', then a 
#      UA could use a gradient of colors from white to dark gray to indicate a 
#      sloping border.

Jerry: Thanks for your help in finding this error and in trying to fix Mozilla.
One idea for finding a better algorithm would be looking at thick borders, like 
the 5th attachement does for 'ridge'. That shows us that IE is just using two 
colours, and that it picks less washed-out colours than Mozilla. I spoke to 
the people behind Konqueror a couple of weeks ago, and they said that they were
using four colours in a gradient to achieve the effect.
Comment 18 Hixie (not reading bugmail) 2000-08-30 11:13:14 PDT

*** This bug has been marked as a duplicate of 41924 ***
Comment 19 Hixie (not reading bugmail) 2000-08-30 11:14:26 PDT
DOH! I am an idiot. Sorry about that. REOPENING. :-/
Comment 20 Jerry Baker 2000-08-30 12:04:36 PDT
The funny thing is that NN4 does it the same way as IE5 in Matthew's attached 
test case. Can someone cut and paste that code from the NN4 tree :-)
Comment 21 Martin Horwath 2001-01-23 14:27:18 PST
adding myself to cc
Comment 22 Martin Horwath 2001-01-31 05:12:52 PST
Created attachment 23931 [details]
Borders rendered by IE,NS4.6, Mozilla Strict, Mozilla Combatible
Comment 23 Martin Horwath 2001-01-31 05:17:39 PST
Created attachment 23932 [details]
html file i used for the screenshots
Comment 24 Martin Horwath 2001-01-31 05:20:11 PST
ie uses for the calculation the definied color value in the css (in this case 
R: 255 G: 255 B:255 which is also the fouth color)

value inset :
ie uses 4 colors for the display
the darkest color in this example is 
1. R: 255 / 4, G: 255 / 4, B: 255 / 4, == R: 63.75 , G: 63.75 , B: 63.75 (ie 
uses in this case follwing values to display the color-> R: 63, G:63, B: 63)

the second and the third values are calculated from the darkest color...
2. R: 63.75 * 2, G: 63.75 * 2, B: 63.75 * 2

and finaly the third color value
3. R: 63.75 * 3, G: 63.75 * 3, B: 63.75 * 3

i've checked this results several times with photoshop, so this should be 
correct... the calculation for outset is the same... only the colors are 
painted the other way round...
this algorithm is also the reason why internet explorer display everywhere 
black when the css color is black

for groove ie uses the darkest color and the defined color
for ridge ie uses the second and the third value...

i hope you find this information useful...
Comment 25 Hixie (not reading bugmail) 2001-01-31 15:27:11 PST
Thanks Martin, that is indeed useful.

Could you do the same thing with a colour border? Like an medium green colour?
When we fix this we're going to need a solution that works for black, white,
and every colour in between...
Comment 26 Martin Horwath 2001-01-31 16:07:18 PST
the ie calc works for nearly every color, e.g: #ff0000 or #008000. 
the problem: it does not work for dark colors...

i don't what the best solution should be, one idea i had was:
if the color value looks like this R:127 G:127: B:127 and none of the values is
larger than 127 the calculation should work the other way around:
that means that the darkest color would become the lightest one:
for inset :
lightes color R: 255 - (127/4) = 233 G: the same B: the same
and so on... 

another thing is how should the border be rendered if no color is definied, 
should the borders use the system colors ?

Comment 27 Martin Horwath 2001-01-31 16:11:49 PST
one other thing

>I forgot to add that "inset", "outset", "ridge", and "groove" necessarily 
>be less than two pixels, so they should always be drawn as at least two pixels.

i don't think it should always be two pixels.
there are two solutions for this problem...
1. only use the outer border (like ie does)
2. or use a calculated color between the two border colors... (i think this is 
a better way)
Comment 28 Hixie (not reading bugmail) 2001-01-31 16:47:51 PST
Per CSS there is always a colour defined, so we have no problem there.
Also, if the width is 1px, then the width will be 1px. Just because our display
resolution means we can't make it look 'ridge'd or 'groove'd with only one 
actual pixel of width is not a reason to ignore the width. Similarly, if the 
width is 0.01px then that turn out to be 0 real pixels, which means the border
is not shown at that resolution. Per CSS that's ok. It's the author's 
responsability to ensure that the border is wide enough to always have enough 
real pixels to display the ridge/groove even at low display resolutions.
Comment 29 Martin Horwath 2001-11-28 06:01:34 PST
its a long time ago since the last comment, so here we go... two things:

1. mozilla should render borders in both modes (combatible and standard) 
identically (there is no need for two different renderings)
2. when the algorithm gets implemented it can be used to style the standard 
HTML form controls like requested in bug 74058 or bug 67749 much easier.

so what do you think ?
should there be a dependency to those both bugs ?

Comment 30 Martin Horwath 2001-11-29 11:24:56 PST
after talking with hixie on irc changing status and os
Comment 31 Jerry Baker 2002-05-27 14:37:31 PDT
Mass removing self from CC list.
Comment 32 Jerry Baker 2002-05-27 15:03:32 PDT
Now I feel sumb because I have to add back. Sorry for the spam.
Comment 33 Greg K. 2002-07-11 19:59:10 PDT
Reonfirmed using FizzillaCFM/2002070913. Attachment 7 [details] still looks the same as in
the screenshot in attachment 6 [details]. Setting Platform=All.
Comment 34 Boris Zbarsky [:bz] (still a bit busy) 2003-04-13 09:57:50 PDT
Jerry, are you actually working on this?

The code Mozilla currently uses for determining colors is
which calls either NS_Get3DColors or NS_GetSpecial3DColors (both in

Changing those latter two functions would be the way to go if we just want to
change the colors that we compute to.

If we want to color each bevel in multiple colors, a lot more of hte
nsCSSRendering code will need rewriting.
Comment 35 Boris Zbarsky [:bz] (still a bit busy) 2003-04-13 10:00:02 PDT
One other note.  For "outset" borders, it is often desirable to set the border
color the same as the background color (makes things look like a button,
hopefully).  IE handles this case _much_ worse than Mozilla for dark colors. 
Haven't really tested light colors...
Comment 36 j.j. 2008-08-28 18:49:01 PDT
*** Bug 431182 has been marked as a duplicate of this bug. ***
Comment 37 j.j. 2009-01-22 18:14:40 PST
Bug 431182 has a nice reference picture to compare current browsers.

Note You need to log in before you can comment on or make changes to this bug.