If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED DUPLICATE of bug 93156

Status

()

Core
CSS Parsing and Computation
P3
normal
VERIFIED DUPLICATE of bug 93156
17 years ago
14 years ago

People

(Reporter: ekrock's old account (dead), Assigned: Pierre Saslawsky)

Tracking

({crash})

Trunk
Future
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: WONTFIX maybe possibly?)

(Reporter)

Description

17 years ago
[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.
(Reporter)

Comment 1

17 years ago
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.
Keywords: crash, ns601
Target Milestone: --- → Future
(Assignee)

Updated

17 years ago
Blocks: 58501
(Assignee)

Comment 2

17 years ago
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?
Status: NEW → ASSIGNED
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?
Keywords: ns601
(Reporter)

Comment 5

17 years ago
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

17 years ago
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...
QA Contact: chrisd → ian
(I'm still erring on the side of WONTFIX, the crashes were minor, no...?)
Whiteboard: WONTFIX maybe possibly?

Comment 9

17 years ago
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! ;-)

Comment 11

17 years ago
Moving to m0.9.3.
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.9.3
(Assignee)

Comment 12

16 years ago
We'll change the name to 'opacity' when the spec becomes a recommendation.
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Summary: change -moz-opacity name to -moz-opacity1 or something similar for next release → [WG]change -moz-opacity name to -moz-opacity1 or something similar for next release
Target Milestone: mozilla0.9.3 → Future
...only if our implementation matches that of the recommendation, which it
currently doesn't.
(Assignee)

Comment 14

16 years ago
dbaron: please be more specific.

reassigned to Compositor like the other opacity bugs.
Assignee: pierre → kmcclusk
Status: ASSIGNED → NEW
Component: Style System → Compositor
QA Contact: ian → petersen
'-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.
(Assignee)

Comment 16

16 years ago
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.
Assignee: kmcclusk → pierre
Component: Compositor → Style System
Depends on: 54631
QA Contact: petersen → ian
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 17

16 years ago
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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.