It would be really nice if rgba values could be used anywhere where CSS expects a color value. RGBA values are part of CSS3 color module and I hope to see them soon in Mozilla. http://www.w3.org/TR/2002/WD-css3-color-20020418/ This would give Moz a serious edge over competing browsers...
css3-colors is still at working draft status. If we implement this before the spec reaches CR stage, it should be as moz-rgba().
roc: How hard would this be at the rendering level?
It depends. nsColor already supports RGBA in principle. The right way to do this is to add rgba() to the style system and then make GFX drawing do the right thing with RGBA nsColors. On some platforms that might be easy. It's not easy on Windows or GTK though. We'll have to composite by hand. If dbaron wants to do the style system support for this, I'll sign up for a GTK implementation.
Actually I have a plan for GFX reorg which would make RGBA work on all platforms. "Someone" could go ahead and add -moz-rgba to the style system right away. GFX work to handling non-opaque nsColors can happen in parallel.
Hmm, I could roll -moz-rgba (and -moz-hsla) into my -moz-hsl patch, I guess. ETA 3 weeks, probably, unless we really want it sooner. See bug 160550
Yeah, roll it in. That would be great.
bz landed the style system end. Over to roc. :-)
Assignee: dbaron → roc+moz
Component: Style System → GFX
As Jason Davis noted in bug 160550 comment 28, the CSS3 Color Module is now a Candidate Recommendation. We are now encouraged to implement rgba and hsla color values!
(In reply to comment #9) > To me it seems sort of backwards that hsla() is implemented It's not. What gave you the idea that it is? -moz-hsla does exactly what -moz-rgba does -- creates an nsColor with the right alpha info, which the rendering engine then proceeds to ignore.
(In reply to comment #10) > It's not. What gave you the idea that it is? -moz-hsla does exactly what > -moz-rgba does -- creates an nsColor with the right alpha info, which the > rendering engine then proceeds to ignore. Mostly that bug 160550 is marked FIXED, when if the alpha channel is ignored it really shouldn't be FIXED. Instead it should really depend on this one, which is where I assume (per comments 29 and 30 on that bug) alpha support should be added.
Summary: Support rgba colors in CSS → Support rgba and hsla colors in CSS
That bug _is_ fixed. Which you should realize, since you clearly read both the bug and comment 10. The syntax is implemented _in_the_style_system_ (which is what bug 160550 was filed on). This bug is on making the renderer make use of that style information.
Any update on getting RGB() or RGBA() working yet?
Excuse me? rgb() works fine. Updates on rgba()/hsla() will be in this bug if any happen.
Actually, if you use this code, you will see that in Firefox the boxes are black. 200 200 200 should be Grey. It displays with the correct color in Internet Explorer. <html> <body> <form> <table> <tr Bgcolor="rgb(200,200,200)" WIDTH=100%> <td HEIGHT=50 WIDTH=50></td> </tr> <TR Bgcolor="rgb(200,200,200)" WIDTH=100%> <TD HEIGHT=50 WIDTH=50></TD> </tr> </table> </form> </body> </html>
The bgcolor attribute of "table" doesn't use the CSS color syntax. It uses the HTML color syntax, so only supports #XXXXXX colors and named colors. In any case, that's completely unrelated to this bug, which is clearly about rgb_a_ and hsl_a_. Note that "a" part.
I can totally fix this.
Attachment #211352 - Flags: review?
Attachment #211352 - Flags: review? → review?(dbaron)
Comment on attachment 211352 [details] [diff] [review] enable rgba/hsla CSS colors No, please make a macro for RENDERER_SUPPORTS_ALPHA_COLORS (PR_TRUE ifdef MOZ_CAIRO_GFX, otherwise PR_FALSE), and use it both: 1) about 8 lines above what you changed, initializing mHandleAlphaColors 2) in ParseColorString Or, alternatively, make ParseColorString do a proper save/restore, and ifdef the initialization a few lines above what you changed. I'm trusting you when you say cairo supports this -- there will probably a bunch of bugs that need to be fixed before we ship a release with this, though. (Anywhere we double-paint at the least. We should check straight borders, dashed-dotted borders, table border-collapse borders, and probably some other things (text, text-shadow, text-decoration, background-color, etc.).) Could you make sure they're filed? Does Hixie have tests for this?
Attachment #211352 - Flags: review?(dbaron) → review-
Doh, forgot about the ParseColorString bit. As for cairo supporting this.. the only promise is that cairo supports operations with colors with full 8-bit alpha. What we do with that is up to nsCSSRendering :) There are definitely going to be bugs with things like rgba() borders -- for example, border: 15px solid rgba(0,0,255,0.5); shows creases at the border edges. This is our own fault due to how we render borders though, and will be fixed once we redo the border drawing code to use real paths (instead of lines and rectangles). We're in no danger of shipping a cairo-gfx official build any time soon, though :)
Comment on attachment 211355 [details] [diff] [review] enable rgba/hsla CSS colors #2 OK, but please do get bugs filed on things like that so we don't forget about them and accidentally ship them in a release. It's sooner than you think.
Attachment #211355 - Flags: review?(dbaron) → review+
Attachment #211355 - Flags: superreview?(roc)
Attachment #211355 - Flags: superreview?(roc) → superreview+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.