[css-color] Should specify that `opacity` is serialized as a number for the specified values

[weinig]

The opacity property has a quirk implemented in at least Safari, Firefox and Chrome and tested in css/css-color/parsing/opacity-valid.html, that when the specified value is a percentage, it should be serialized as a normalized number.

This should be formalized in the opacity section of CSS Color.

[cdoublev]

It seems that resolving <percentage> to <number> almost always applies at parse time. See #9395.

[svgeesus]

Does that happen by analogy with 15.1. Serializing alpha values?

Do we need a new section Serializing <opacity> values ? Or just add it to Transparency: the opacity property

@weinig by normalized do you mean just percent converted to number, or also clamped? Spec currently says:

Opacity values outside the range [0,1] are not invalid, and are preserved in specified values, but are clamped to the range [0, 1] in computed values.

which implies unclamped specified values.

[svgeesus]

I just added

This applies to the ''opacity'' property.

The specified given opacity value is serialized
as a <<number>>, not a <<percentage>>.

This <<number>> value is expressed in base ten,
with the "." character as decimal separator.
The leading zero must not be omitted.
Trailing zeroes must be omitted.

Opacity values outside the range [0,1]
are preserved, without clamping, in the serialized specified value.

The precision with which opacity values are retained,
and thus the number of decimal places in the serialized value,
is not defined in this specification,
but must at least be sufficient
to round-trip integer percentage values.
Thus, the serialized value must contain
at least two decimal places
(unless trailing zeroes have been removed).
Values must be
<a href="https://drafts.csswg.org/css-values-4/#combine-integers">rounded
towards +∞</a>, not truncated.

[svgeesus]

@weinig does that resolve the issue?

[weinig]

@svgeesus I don't think this part is needed:

This <<number>> value is expressed in base ten,
with the "." character as decimal separator.
The leading zero must not be omitted.
Trailing zeroes must be omitted

Since that should just be standard number serialization.

I think we still have an issue with how calc() works. The current WPT tests have a pretty weird assumption that calc() values with percentages get transformed into calc() values with numbers:

test_valid_value("opacity", "clamp(50%, 0%, 70%)", "calc(0.5)");
test_valid_value("opacity", "clamp(50%, 80%, 70%)", "calc(0.7)");
test_valid_value("opacity", "clamp(50%, 60%, 70%)", "calc(0.6)");
test_valid_value("opacity", "min(50%, 0%)", "calc(0)");
test_valid_value("opacity", "min(0%, 50%)", "calc(0)");
test_valid_value("opacity", "max(50%, 0%)", "calc(0.5)");
test_valid_value("opacity", "max(0%, 50%)", "calc(0.5)");
test_valid_value("opacity", "min(-40%, 50%)", "calc(-0.4)");

Only Firefox has this behavior, and I think it's pretty weird. We don't do any transforms inside a calc() like this for any other properties. Given WebKit and Chrome don't match Firefox here, and instead preserve percentages inside calc() for specified value (but do, of course, resolve them for computed styles).

I would prefer we specify the WebKit/Chrome behavior which I might right out as something like:

If the specified value for an opacity value matches a literal <percentage-token> (i.e. does not use calc()) it should be serialized as the equivalent <number> (0% to 0, 100% to 1) value. Otherwise, the specified value for an opacity value should serialize using standard serialization for the grammar.

If we adopt this, we would change the tests.

[svgeesus]

@svgeesus I don't think this part is needed:

We already say the same thing in Serializing <color> values: https://drafts.csswg.org/css-color-4/#serializing-color-values) so I added it for opacity, too.

The current WPT tests have a pretty weird assumption that calc() values with percentages get transformed into calc() values with numbers:

Probably because the spec says

The specified given opacity value is serialized as a <number>, not a <percentage>.

So I guess the disconnect is whether to resolve the percentages in specified values, or only in computed values. And whether that happens before or after calc() processing. I can see the value in retaining <percentage> inside calc.

For color components, we also serialize to <number>:

The component values are serialized in base 10, as <number>.

The text you propose seems clear. @emilio is there a reason for the Firefox behavior, and if no strong reason, can it be changed for interop?

[svgeesus]

@ericwilligers you wrote those tests, originally for CSS Color 3, and @emilio you added the calc percentage ones:

Be explicit about comparing percentages in calc().
The root cause here is that percentages when mixed with lengths don't
compare / simplify, because the basis might be negative (bug 1709018),
so PartialOrd returns None for them.

When parsing a plain percentage / resolving to a percentage however, we
do want them to resolve. The regressing bug broke that because min > max
etc would effectively return false.

[svgeesus]

Agenda+ to try to move this forward

[svgeesus]

@emilio there is an outstanding question about the Firefox behavior regarding transforms in calc() and whether that aligns with the spec or not. Could you take a look?

[emilio]

Seems fine to adapt to the WebKit / Blink behavior here, don't have a strong opinion one way or the other and it is right that usually these simplifications don't happen at parse time.