[Opening tracking bug to track this issue for timeframe of future significant releases such as Mozilla 1.0 and the first major N6 point release.] It's been observed that the -moz-opacity CSS extension triggers some crash bugs in N6 RTM (bug 54631, bug 57223), and that these won't be fixed for N6 RTM, and that the -moz-opacity property won't be removed for N6 RTM (bug 57307). The presence of known crashers in N6 RTM for -moz-opacity will deter the use of that CSS extension property name for as long as N6 RTM has significant market share, even after the specific crashers are fixed in post-N6 RTM point releases. There's no point in promoting a CSS extension property name that content providers will be unwilling to adopt due to the risk of crashers. The only logical solution to this situation is to officially deprecate the -moz-opacity property as unsupported in N6 RTM and change the name to something else (like -moz-opacity1) for Mozilla 1.0 and the first post-N6 RTM major point release. I don't care what we change the name to (suggestions welcome), but we should change the property name so that content providers can adopt the new property name in their content without risking crashes of N6 RTM. Marking ns601.

Marking ns601 and Future. Also marking crash (in terms of severity and practical impact on the content developer, although strictly speaking this doesn't actually eliminate a specific crasher from the codebase itself) because fixing this bug will enable content providers to use our opacity functionality in Mozilla 1.0 and future N6 releases without the fear of triggering crashes in N6 RTM.

Why not, but a long-term solution would be to have "opacity" officially recognized as a property. Has any effort been done for that in the WG? Ian, David, do you know?

Pierre: ChrisL wants 'opacity'; however as he currently describes it it is rather different to ours. (He describes it as the alpha-value of the 'color' property; and would therefore have equivalents for the border-X-color, background-color, outline-color, and other colour properties. Mail the list if you want it on the Agenda for the F2F.)

I don't like calling it "-moz-opacity1"; that name is awful. Don't we have any better ideas? I'm tempted to suggest WONTFIX; how serious are the crashes?

I don't like that name either. All: feel free to suggest something better. -moz-opacity-new? Ian: As you've argued yourself so eloquently so many times in the past ;-> , the point is that as long as there's a browser in the market with significant market share that crashes on property foo, no one will be willing to use property name foo anywhere. Since -moz-opacity is known to trigger crashes in N6.0, we've effectively killed the name -moz-opacity. If we hope to get rapid adoption of a working opacity implementation in a future N6 release, we need to change the name so that people can take advantage of it on N6+ without crashing on N6.0.

Eric, Is there a way to wait WG works related with opacity before this naming decision? If we are going to promote the property in the future releases after first Mozilla 1.0 and N6, I believe this promoting phase will take more effect if the opacity feature (name and behavior) is compliant with WG. Maybe we can find out if WG is working on this issue and how long will take to have an "opacity" attribute as an official CSS property. Well, if name is going to be changed my suggestion -moz-alpha. Since alpha:0 is the same of opacity:0

Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...

(I'm still erring on the side of WONTFIX, the crashes were minor, no...?)

The W3C have now, as of the working draft published 5 March 2001, included an opacity property in CSS3. See http://www.w3.org/TR/css3-color#transparency . Does this mean we can stop calling it "-moz-opacity" and start calling it "opacity" again?

No, because it is still a working draft. We have to wait until the spec reaches CR stage before dropping our vendor prefixes -- the W3C might well change their mind at the last minute... it's happened before! ;-)

Moving to m0.9.3.

We'll change the name to 'opacity' when the spec becomes a recommendation.

...only if our implementation matches that of the recommendation, which it currently doesn't.

dbaron: please be more specific. reassigned to Compositor like the other opacity bugs.

'-moz-opacity' is inherited and applies only to any painting done for the element (at least it did the last time I checked) 'opacity' is not inherited and should apply to the entire subtree drawn by the element The former is totally wrong and only works reasonably in certain simple cases.

I suggest we fix '-moz-opacity', then implement 'opacity' when it becomes a recommendation and still keep '-moz-opacity'. I'm taking the bug back, marking it dependent on bug 54631.

I looked into the way we use '-moz-opacity' and it doesn't seem that we are already taking advantage of the difference between the two definitions. So, unlike what I wrote on [2001-07-17 16:31], the way to go would be to fix '-moz- opacity' when we can, and rename it to 'opacity' as soon as the spec becomes a recommendation. I opened bug 93156: "[rfe] Implement 'opacity' according to the spec" *** This bug has been marked as a duplicate of 93156 ***

verified.