[fill-stroke] [filter-effects] [css-color] percentage opacity

[ewilligers]

The opacity properties define their syntax using <alpha>.

In CSS Color 3, alpha only accepted number values.

In CSS Color 4, alpha accepts percentages in addition to numbers.

Blink/Edge/Firefox/Safari do not accept percentages for any of the opacity properties - test page.

Blink and Firefox do accept percentage alpha in rgba() color values.

Was the change to support percentages intended only for color functions, with opacity properties affected accidentally, or are browsers intending to support percentages in *-opacity?

Affected properties:

• opacity
• flood-opacity
• fill-opacity (also in SVG2)
• stroke-opacity (also in SVG2)
• stop-opacity (in SVG2)

[tabatkins]

It was intentional to cover both; it would be weird to have opacity in color functions accept a wider syntax than opacity in opacity.

[dirkschulze]

@tabatkins That makes sense. @ericwilligers's point is that even opacity does not support the wider syntax. So the properties are compatible already but simply do not support the full <alpha> value.

[ewilligers]

Thanks Tab.

A Blink patch to support % opacity is in code review. Comments from other browsers vendors would be appreciated before we send out the Intent to Implement and Ship. WPTs will be added.

[emilio]

Should specified opacity serialize as a number for backwards compat, or as a percentage?

They always serialize as numbers in colors, IIRC.

[ewilligers]

Should specified opacity serialize as a number for backwards compat, or as a percentage?

They always serialize as numbers in colors, IIRC.

Yes, Blink/Firefox serialize them as numbers in specified colors.

CSS OM specifies that alphavalue serializes as a number (with specific rounding rules).

Note 1. This is an argument against #3139, at least in the context of Color 4

Note 2. We should have consistency: <alphavalue> in CSSOM, <alpha-value> in CSS Color 4.

[ewilligers]

Adding to agenda to hear from other browsers before shipping.

[dirkschulze]

The SVG WG discussed replacing <alphavalue> with <number> before because of the lack of support of percentage. So far we still reference the syntax of the opacity property. @ewilligers The Blink patch you are talking about, would that address all *-opacity properties or just opacity itself?

[ewilligers]

All of them

[css-meeting-bot]

The CSS Working Group just discussed percentage opacity, and agreed to the following:

• RESOLVED: No change to spec

The full IRC log of that discussion

<dael> Topic: percentage opacity
<dael> github: https://github.com//issues/3342
<dael> ericwilligers: The argument is opacity can be % or number. opacity prop says same. Not browser impl that. We're proposing to impl but want to ping other browsers to make sure they're okay with it.
<dael> ericwilligers: to allow opacity to accept %
<dael> AmeliaBR: Has anyone looked and found reason not to? Or has no one prioritized?
<dael> myles: We're happy to adopt. % opacity is good in every context
<dael> Rossen_: Other opinions or objections to resolve in favor of %?
<dael> ericwilligers: Moz?
<dael> emilio: No strong opinion. Reasonable. As long as it doesn't cause a conflict
<dael> ericwilligers: Serializes as a number
<dael> AmeliaBR: We don't have anywhere we're using opacity and they're ambig. In color it's defined by positio in param list. In all others it's single value. No parsing concern
<dael> ericwilligers: Thanks everyone
<dael> AmeliaBR: It's resolve no change to spec.
<dael> Rossen_: Prop: No change to spec
<dael> RESOLVED: No change to spec

[AmeliaBR]

The tagging unfortunately makes it seem as if support for percentage opacity was rejected, but to be clear: the resolution was to keep percentage alpha/opacity values in the spec (the issue was asking if we should keep or revert).