Open Bug 50699 Opened 20 years ago Updated 2 years ago

CSS inset and outset are ugly


(Core :: Layout, enhancement, P3)






(Reporter: mozilla, Assigned: mozilla)



(4 keywords, Whiteboard: [CSS1-5.5.17])


(7 files)

Open attachment in IE5 and Mozilla. Compare Mozilla's absolutely ugly rendering 
compared to IE5.
Attached file So much nicer in IE.
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.
Assignee: clayton → jerrybaker
Severity: normal → enhancement
Keywords: css1, helpwanted, polish
QA Contact: petersen → py8ieh=bugzilla
Target Milestone: --- → Future
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.
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.
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.
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 :-)
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?
eek. That's a mistake. I'll get that fixed.
Whiteboard: WG
Note: RFC posted to w/regards to this. It can be viewed at
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.
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?
Attached file HTML source
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.
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.
Summary: [RFE]CSS inset and outset are ugly → [RFE] CSS inset and outset are ugly
Whiteboard: WG

*** This bug has been marked as a duplicate of 41924 ***
Closed: 20 years ago
Resolution: --- → DUPLICATE
DOH! I am an idiot. Sorry about that. REOPENING. :-/
Resolution: DUPLICATE → ---
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 :-)
Keywords: mozilla1.2
adding myself to cc
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...
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...
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 ?

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)
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.
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 ?

after talking with hixie on irc changing status and os
OS: Windows 2000 → All
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Reonfirmed using FizzillaCFM/2002070913. Attachment 7 [details] still looks the same as in
the screenshot in attachment 6 [details]. Setting Platform=All.
Keywords: testcase
Hardware: PC → All
Whiteboard: [CSS1-5.5.17]
Summary: [RFE] CSS inset and outset are ugly → CSS inset and outset are ugly
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.
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...
Duplicate of this bug: 431182
Bug 431182 has a nice reference picture to compare current browsers.
QA Contact: ian → layout
Blocks: 225314
Depends on: 1382896
You need to log in before you can comment on or make changes to this bug.