50699 - CSS inset and outset are ugly

Status: NEW

(Core :: Layout, enhancement, P3)

Description

[Jerry Baker]

Open attachment in IE5 and Mozilla. Compare Mozilla's absolutely ugly rendering 
compared to IE5.

Comment 1

[Jerry Baker]

Attachment: So much nicer in IE.

Comment 2

[Jerry Baker]

Attachment: For you folks on *nix - a screen capture

Comment 3

[Hixie (not reading bugmail)]

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]

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 
             "buttonhighlight".
          3. Outermost border-right and border-bottom are the color of
             "threeddarkshadow".
          4. Innermost border-right and border-bottom are the color of
             "buttonshadow".
     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 
             "threeddarkshadow".
          3. Outermost border-right and border-bottom are the color of
             "buttonhighlight".
          4. Innermost border-right and border-bottom are the color of
             "threedlightshadow".

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]

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]

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)]

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]

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)]

eek. That's a mistake. I'll get that fixed.

Comment 10

[Jerry Baker]

Note: RFC posted to [e-mail] w/regards to this. It can be viewed at 
http://lists.w3.org/Archives/Public/www-style/2000Aug/0140.html

Comment 11

[Hixie (not reading bugmail)]

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]

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]

Attachment: IE's rendering - a thing of beauty

Comment 14

[Matthew Brealey]

Attachment: Mozilla's rendering - ugly

Comment 15

[Matthew Brealey]

Attachment: HTML source

Comment 16

[Matthew Brealey]

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)]

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.

http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html 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)]

*** This bug has been marked as a duplicate of 41924 ***

Comment 19

[Hixie (not reading bugmail)]

DOH! I am an idiot. Sorry about that. REOPENING. :-/

Comment 20

[Jerry Baker]

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]

adding myself to cc

Comment 22

[Martin Horwath]

Attachment: Borders rendered by IE,NS4.6, Mozilla Strict, Mozilla Combatible

Comment 23

[Martin Horwath]

Attachment: html file i used for the screenshots

Comment 24

[Martin Horwath]

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)]

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]

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 ?

hmm...

Comment 27

[Martin Horwath]

one other thing

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

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)]

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]

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]

after talking with hixie on irc changing status and os

Comment 31

[Jerry Baker]

Mass removing self from CC list.

Comment 32

[Jerry Baker]

Now I feel sumb because I have to add back. Sorry for the spam.

Comment 33

[Greg K.]

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 [:bzbarsky]]

Jerry, are you actually working on this?

The code Mozilla currently uses for determining colors is
nsCSSRendering::MakeBevelColor
(http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSRendering.cpp#304)
which calls either NS_Get3DColors or NS_GetSpecial3DColors (both in
http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSColorUtils.cpp).

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 [:bzbarsky]]

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 37

[j.j.]

Bug 431182 has a nice reference picture to compare current browsers.

https://bugzilla.mozilla.org/attachment.cgi?id=319249

Comment 38

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.