Computed style doesn't do the 'a' part of rgba/hsla colors. With cairo, we apparently added support for rgba/hsla colors, but the computed style implementation wasn't updated accordingly...

If nothing else, this will cause dataloss issues in editor/midas.

I don't care a whole lot about these DOM interfaces (nsIDOMRGBColor), so I just did the smallest thing I could to get things working somewhat sanely. It might have been nicer to have a separate (non-inheriting) interface since rgba colors really aren't rgb colors, and separate objects so that the existing objects wouldn't pick up an alpha property, but I don't think it's worth the extra codesize. We should probably even be thinking about code removal here...

Note that this patch also implements http://www.w3.org/TR/2003/CR-css3-color-20030514/#transparent , since I wanted that to be the computed value in the alpha==0 cases.

Comment on attachment 252567 [details] [diff] [review] patch Looks good! The interfaces are the ones in DOM CSS. And yes, I agree that they're not great.

This should have a mochitest. It would be easy to write.

Checked in to trunk, with visual reftests for rgba and transparent, but no mochitest. (I think I'd have an easier time writing it in reftest with document.write, but I suppose I should figure out how to copy an existing test at some point...)

The CSSValue and related interfaces have long been dropped from DOM Level 2 Style fwiw...

That's fine, but there's existing code relying on them, so it's not like we'll be removing them anytime soon. We can just worry less about adding stuff to them.

This is still broken for me on trunk: <h3>Hello!</h3> <script> h3 = document.getElementsByTagName("h3")[0]; h3.style.color = "rgba(50, 50, 200, 0.7)"; document.write(h3.style.color); </script> --> rgb(50, 50, 200)

That's not computed style. Different code; separate bug.

Ok, filed bug 372770 on that.