[css-color-4] Resolving and serializing the opacity property

[svgeesus]

As @lilles originally noted in passing

we have existing interop on the opacity property not being clamped for declared values.

The part is now clear that this only applies to the alpha component of <color> values, but now we need a separate section defining that there is no opacity clamping, and how this is resolved and serialized.

[cdoublev]

I think clamping should not be defined in 4.2. Representing Transparency: the <alpha-value> syntax:

4.2. Representing Transparency: the <alpha-value> syntax

<alpha-value> = <number> | <percentage>

[...]

Values outside the range [0,1] are not invalid, but are clamped to that range at parsed-value time.

It is a sub-section of 4. Representing Colors: the <color> type (which means clamping only applies in this context) but the problem is that all references of <alpha-value> links to the above production rule.

[svgeesus]

I think the way to resolve that is not to not link to a single <alpha-value> production but instead:

<alpha-value> = <alpha-component> | <opacity-value>

The clamping of each one can then be independently specified. WDYT?

[cdoublev]

I would keep a single definition (ideally placed below opacity definition table) with the production rule and without clamping, and I would add a context specific definition (via dfn-for) below color definition table.

I do not like splitting productions just to apply clamping separately, whereas these productions match the same input. Worse, I also do not like splitting <rg-ending-shape> and <ending-shape> just because sides is also valid in ray() but not in radial-gradient(). Or even worse, I think <alpha-value> is useless and it should be <'opacity'>.

Therefore I think it would be more appropriate to ask Tab Atkins.

[svgeesus]

I am concerned by this assertion in t32-opacity-clamping-0.0-b.xht by @dbaron (which all browsers pass):

<meta name="assert" content="Opacity values less than 0.0 are clamped to 0.0" />

and similarly in t32-opacity-clamping-1.0-b.xht which again all browsers pass:

<meta name="assert" content="Opacity values greater than 1.0 are clamped to 1.0" />

So specified values are not clamped (see [codepen](https://codepen.io/lilles/pen/YzjQEzj by @lilles) but computed values (which is what @dbaron was testing) are.

Right?

[cdoublev]

With 711296f and d995b34, opacity is now defined with <opacity-value> instead of <alpha-value>. Below are some suggestions and remaining problems.

---

In 3.3. Transparency: the opacity property (CSS Color 4), this sentence seems a bit confusing to me:

Opacity in CSS is typically represented using the <opacity-value> syntax, for example in the opacity property or as the alpha component in a color function, using the <alpha-value> syntax.

This seems clearer: Opacity in CSS is typically represented using <x> syntax, [example for <x>], or using the <y> syntax, [example for <y>].

But other specs should only use <opacity-value> (which is missing a production rule, unlike <alpha-value>) and this section is about the opacity property, so it could be simplified to Opacity in CSS is typically represented using the <opacity-value> syntax.

However, other specs currently use <'opacity'>:

• fill-opacity (SVG 2, Fill Stroke)
• flood-opacity (Filter Effects)
• shape-image-threshold (CSS Shapes)
• stop-opacity (SVG 2)
• stroke-opacity (SVG 2, Fill Stroke, SVG Strokes)

So it might be simpler to define opacity with <number> | <percentage> and a prose that requires clamping at computed value time, and optionally <alpha-value> with <'opacity'> and a prose that requires clamping at parse time.

---

In 15.1 Serializing alpha values (CSS Color 4), the emphasized parts below seem redundant:

This applies to any <color> value which can take an optional alpha value. It does not apply to the opacity property.

If, after clamping to the range [0.0, 1.0] the alpha is exactly 1, it is omitted from the serialization; an implicit value of 1 (fully opaque) is the default.

Besides, one may wonder whether 1.0 as input (tokenized to 1) can be omitted, because it is not exactly 1 and the specs do not clearly define when a component value can be omitted when serializing a specified value, at the moment (see #5642 (comment))

[cdoublev]

In 15.1 Serializing alpha values (CSS Color 4), the emphasized parts below seem redundant:

[...] If, after clamping to the range [0.0, 1.0] the alpha is exactly 1 [...]

Actually I would remove it from 4.2. Representing Transparency in Colors: the <alpha-value> syntax:

Unless otherwise specified, an <alpha-value> component of a color defaults to 100% when omitted. Values outside the range [0,1] are not invalid, but are clamped to that range at parsed-value time.

I agree with #7677 (comment), you just need the specified value to be clamped. Implementers may choose to do it at parse time or "just in time" when serializing the specified value.

[svgeesus]

I agree with #7677 (comment), you just need the specified value to be clamped. Implementers may choose to do it at parse time or "just in time" when serializing the specified value.

The various specs use "parsed value time" frequently. Determining whether this has actually been done at parse time or when serializing the specified value is not, afaict, observable.

[svgeesus]

Besides, one may wonder whether 1.0 as input (tokenized to 1) can be omitted, because it is not exactly 1 and the specs do not clearly define when a component value can be omitted when serializing a specified value, at the moment (see #5642 (comment))

Oh, you mean because that implies a float comparison (if the value is stored as a float)? Maybe we could say "if the serialized value would be '1' or something like that?

[cdoublev]

At the current state of #5642, I would just write [0,1] instead of [0.0,1.0] to define the range, and remove exactly.

But "remove x if it serializes as the default value" is probably the simplest implementation and makes sense to me. It implies that calc(1) cannot be omitted, but some browsers currently remove math functions representing default values in some places.

[svgeesus]

At the current state of #5642, I would just write [0,1] instead of [0.0,1.0] to define the range, and remove exactly.

Done with 9d07962

[cdoublev]

As I already noted above, <opacity-value> is missing a production rule: <opacity-value> = <number> | <percentage> (<alpha-value> already has one) but imo <opacity-value> can just be removed and opacity can be defined with <number> | <percentage>: other specs must use <'opacity'> to represent an opacity value, as they already do.

But of course you may have reasons not to follow these suggestions.

[svgeesus]

other specs must use <'opacity'> to represent an opacity value, as they already do.

The issue I see with that, is that it is linking to a property definition (the opacity property), not to a value type.

I also see some other specs allow only <number while others accept <number> | <percentage>.

I agree that a production rule needs to be added.

[cdoublev]

I understand your concern about using <'opacity'> in other property value definitions. Productions of property value ranges embed the semantics of the property and are more often used in shorthand value definitions, or in properties that are semantically related: background-blend-mode with <'mix-blend-mode'>, block-size with <'width'>, etc.

I cannot find any property that only allows <number> to express an opacity or transparency value.

[svgeesus]

I cannot find any property that only allows <number> to express an opacity or transparency value.

shape-image-threshold says

<number>
Sets the threshold used for extracting a shape from an image.

[cdoublev]

I filled #9884 about <percentage> for shape-image-threshold.

edit: see #4102, maybe <number> should just be replaced with <'opacity'> (or <opacity-value>)?

[svgeesus]

Yes, I think <opacity-value> is correct there

[cdoublev]

Based on the property names (*-opacity vs -threshold) it makes sense, ok. 👍