Closed Bug 147017 Opened 21 years ago Closed 18 years ago

Support rgba and hsla colors in CSS


(Core Graveyard :: GFX, enhancement)

Not set


(Not tracked)



(Reporter: erik, Assigned: roc)


(Blocks 1 open bug)


(Keywords: css3)


(1 file, 1 obsolete file)

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.

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?
Keywords: css3
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
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.
Depends on: 160550
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
To me it seems sort of backwards that hsla() is implemented while the extension
of the more commonly understood (at least among web developers) rgb() to rgba()
is not.

Since this seems to be somewhat dead in the water right now, how about if we do
a temporary stopgap measure of mapping rgba() to hsla()?  It wouldn't be
permanent, but it would get it working until a better implementation could be
done.  I don't know how complicated it would be in the coding, and it would be
pretty kludgy as I think hsla() when rendered is converted back into rgb, but it
would work for now.  If this happened, we'd also need to remove -moz-rgba (which
currently ignores the alpha channel) from source.

Here's a bit of Javascript that should do the conversion of RGBA to HSLA. 
Porting it to C++ should be relatively trivial, I think.  Feel free to do
whatever with this to make rgba() work.  (I don't know enough C++ or have enough
knowledge of the tree to try making a stab, and trust me, you wouldn't want me
to make one. ;-) )

// assumes red, green, blue are percentages
// alpha channel passed on "as is"
function rgba_to_hsla (red, green, blue, alpha) {

   var maximum, minimum, lum, sat, hue;
   var rgbArray, hslaArray;

   rgbArray = new Array (red, green, blue);
   rgbArray = rgbArray.sort();  // from lowest pct. to highest

   minimum = rgbArray[0];
   maximum = rgbArray[2];

   lum = (minimum + maximum)/2;

   if (minimum = maximum) {
      sat = 0;
      hue = 0;
   else {
      if (lum < 0.5) {
         sat = (maximum - minimum) / (maximum + minimum);
      else {
         sat = (maximum - minimum) / (2 - maximum - minimum);

   switch (maximum) {
      case red:
         hue = (green - blue) / (maximum - minimum);
      case green:
         hue = 2 + (blue - red) / (maximum - minimum);
      case blue:
         hue = 4 + (red -green) / (maximum - minimum);

   hslaArray = new Array (hue, sat, lum, alpha);
   return hslaArray;
(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
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.


	<tr Bgcolor="rgb(200,200,200)" WIDTH=100%>
		<td HEIGHT=50 WIDTH=50></td>

	<TR Bgcolor="rgb(200,200,200)" WIDTH=100%>
		<TD HEIGHT=50 WIDTH=50></TD>
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.
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 :)
Attachment #211352 - Attachment is obsolete: true
Attachment #211355 - Flags: review?(dbaron)
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) → superreview+
Checked in
Closed: 18 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.