58517 - [WG]change -moz-opacity name to -moz-opacity1 or something similar for next release

Status: VERIFIED DUPLICATE of bug 93156

(Core :: CSS Parsing and Computation, defect, P3)

Description

[ekrock's old account (dead)]

[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.

Comment 1

[ekrock's old account (dead)]

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.

Comment 2

[Pierre Saslawsky]

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?

Comment 3

[Hixie (not reading bugmail)]

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.)

Comment 4

[Hixie (not reading bugmail)]

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?

Comment 5

[ekrock's old account (dead)]

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.

Comment 6

[/\/\arcio Galli]

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

Comment 7

[Hixie (not reading bugmail)]

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...

Comment 8

[Hixie (not reading bugmail)]

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

Comment 9

[Brett Donald]

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?

Comment 10

[Hixie (not reading bugmail)]

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! ;-)

Comment 11

[karnaze (gone)]

Moving to m0.9.3.

Comment 12

[Pierre Saslawsky]

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

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 14

[Pierre Saslawsky]

dbaron: please be more specific.

reassigned to Compositor like the other opacity bugs.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

'-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.

Comment 16

[Pierre Saslawsky]

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.

Comment 17

[Pierre Saslawsky]

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 ***

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

verified.