Open Bug 50699 Opened 20 years ago Updated 2 years ago
CSS inset and outset are ugly
577 bytes, text/html
1.19 KB, image/png
5.13 KB, image/png
5.44 KB, image/png
157 bytes, text/html
24.87 KB, image/png
910 bytes, text/html
Open attachment in IE5 and Mozilla. Compare Mozilla's absolutely ugly rendering compared to IE5.
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.
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.
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.
Note: RFC posted to firstname.lastname@example.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.
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?
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
*** This bug has been marked as a duplicate of 41924 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
DOH! I am an idiot. Sorry about that. REOPENING. :-/
Status: RESOLVED → REOPENED
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 :-)
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 ? hmm...
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.
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
Status: REOPENED → NEW
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.
Hardware: PC → All
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...
Bug 431182 has a nice reference picture to compare current browsers. https://bugzilla.mozilla.org/attachment.cgi?id=319249
You need to log in before you can comment on or make changes to this bug.