Incorrect summation colors?

[nicothin]

less:

p {
  color: rgba(255, 0, 0, 0.75) + rgba(0, 255, 0, 0.75);
}

css:

p {
  color: rgba(255, 255, 0, 0.9375);
}

Where did the value of 0.9375?
0.75 expected in the alpha channel.

[joev0000]

(1 - alpha1) * (1 - alpha2) = (1 - alphaSum)
(1 - 0.75) * (1 - 0.75) = (1 - 0.9375)
0.25 * 0.25 = 0.0625

I don't claim to know why less.js does it this way, (1/4 of 1/4 opaque is 1/16 opaque?), but that may be the math behind this.

[lukeapage]

Think how transparent it would be with 2 sheets of glass 0.75 opaque. Its
really difficult to decide how to model "adding" colours with opacity and
historically this was agreed on.

[seven-phases-max]

Yes, we decided to borrow alpha handling from simple-compositing model in this case but this was no more than just a quick fix for #1673 (see also #1676 for the discussion). This model is quite weird in this case, but the problem is that other (simple) opacity handling models would be even more faulty.

0.75 expected in the alpha channel.

Based on what rationale?
It's not a big deal to come up with some formula giving 0.75 in this case (it could be either arithmetic or geometric average, e.g. (a.alpha + b.alpha) / 2 or sqrt(a.alpha * b.alpha), or just some non-linear hammer (max(a.alpha, b.alpha)). But either one needs some rationale behind.
The tricky part here is that unlike blending-ops, the arithm ops in Less historically do not take opacity into account at all (before #1676 it was just (a.alpha + b.alpha)) which makes it quite difficult to fit into either physical model (especially when it comes to mul/div ops since those use integer arithmetic, and becomes even more tricky when one of two operand is a number instead of color).

---

Technically this arithmetic addition can be thought of as adding two sources of light (I guess it was me who suggested "2 sheets of glass" analogy there but that's was not quite correct: you don't get yellow glass by stacking red and green sheets, but you do get it by combining red and green lights). In that context the alpha channel would represent the light intensity, but then we need to introduce quite deep and breaking changes: consider adding weak red and strong green, e.g. rgba(255, 0, 0, 0.1) + rgba(0, 255, 0, 0.9); - obviously this actually can't result in the yellow (with whatever opacity) at all but historically the addition op in Less still produces rgba(255, 255, 0, whatever) in this case.

---

I was planning to come up with more "physically strict" transparency handling for arithm ops too (#1675) but after certain experiments I came to conclusion that this thing becomes just too complex to be included in the core (well, addition and subtraction of two colors are actually quite trivial, but multiplication and division plus non-color operands plus keeping at least partial backward compatibility make this thing grow too bloating). So at some point I thought it's just better to leave everything as is :) Especially because of the lack of use-cases (i.e. "yes, it's nice to have some very strict scientific color arithmetic but there's no point to burden the compiler if nobody uses that math" :) So @nicothin in that sense it would be interesting to hear more details about your use-case... (And btw., in this context I'd probably suggest to consider if one of blending functions could fit your use-case better).

[nicothin]

@lukeapage 2 sheets of glass? ok: http://jsbin.com/yubexi/1/edit (the first color should have no effect)
@seven-phases-max it's not a bug, it's a feature (: on all channels - simple addition, on alpha channel - cunning unexpected algorithm.

[tomek-he-him]

cunning unexpected algorithm

@nicothin this behaviour goes inline with that of Photoshop, Inkscape, Gimp and any other image editing program I know. Try overlapping two half-transparent rectangles over a transparent background and see what you get.