CSS inset and outset are ugly

NEW
Assigned to

Status

()

Core
Layout
P3
enhancement
17 years ago
6 years ago

People

(Reporter: Jerry Baker, Assigned: Jerry Baker)

Tracking

(4 keywords)

Trunk
Future
css1, helpwanted, polish, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [CSS1-5.5.17])

Attachments

(7 attachments)

(Assignee)

Description

17 years ago
Open attachment in IE5 and Mozilla. Compare Mozilla's absolutely ugly rendering 
compared to IE5.
(Assignee)

Comment 1

17 years ago
Created attachment 13693 [details]
So much nicer in IE.
(Assignee)

Comment 2

17 years ago
Created attachment 13694 [details]
For you folks on *nix - a screen capture
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
(Assignee)

Comment 4

17 years ago
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.
(Assignee)

Comment 5

17 years ago
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.
(Assignee)

Comment 6

17 years ago
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 :-)
(Assignee)

Comment 8

17 years ago
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
(Assignee)

Comment 10

17 years ago
Note: RFC posted to www-style@w3.org w/regards to this. It can be viewed at 
http://lists.w3.org/Archives/Public/www-style/2000Aug/0140.html
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.
(Assignee)

Comment 12

17 years ago
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

17 years ago
Created attachment 13731 [details]
IE's rendering - a thing of beauty

Comment 14

17 years ago
Created attachment 13732 [details]
Mozilla's rendering - ugly

Comment 15

17 years ago
Created attachment 13733 [details]
HTML source

Comment 16

17 years ago
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.

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.
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 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
DOH! I am an idiot. Sorry about that. REOPENING. :-/
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 20

17 years ago
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 :-)

Updated

17 years ago
Keywords: mozilla1.2

Comment 21

17 years ago
adding myself to cc

Comment 22

17 years ago
Created attachment 23931 [details]
Borders rendered by IE,NS4.6, Mozilla Strict, Mozilla Combatible

Comment 23

17 years ago
Created attachment 23932 [details]
html file i used for the screenshots

Comment 24

17 years ago
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...

Comment 26

17 years ago
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

17 years ago
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)
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

16 years ago
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

16 years ago
after talking with hixie on irc changing status and os
Status: REOPENED → NEW
OS: Windows 2000 → All
(Assignee)

Comment 31

16 years ago
Mass removing self from CC list.
(Assignee)

Comment 32

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

Comment 33

15 years ago
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]

Updated

15 years ago
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
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.
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...

Updated

9 years ago
Duplicate of this bug: 431182

Comment 37

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

https://bugzilla.mozilla.org/attachment.cgi?id=319249
QA Contact: ian → layout

Updated

6 years ago
Blocks: 225314
You need to log in before you can comment on or make changes to this bug.