rgba color output: to clamp or not to clamp?

[seven-phases-max]

Example:

z {
    @a: rgba(255, 255, 255, 100%);
    @b: rgba(255, 255, 255, 25%);

    1: (@a + @a);
    2: (@b + @b);

    // or simply:
    3: rgb(510, 510, 510);
    4: rgba(510, 510, 510, 50%);
}

Result:

z {
  1: #ffffff;
  2: rgba(510, 510, 510, 0.5);
  3: #ffffff;
  4: rgba(510, 510, 510, 0.5);
}

I.e. the non-transparent output of the same color is clipped and the transparent one isn't. Strictly speaking rgba(510, 510, 510, 0.5) is still a valid CSS value according to http://www.w3.org/TR/css3-color/#numerical (a browser should recognise it and perfrom clipping on its own). But are we actually fine with hex and rgba having different color output? (This is easy to fix, but should we?)

Beside math ops, those out-of-range color values may rise as a result of some color functions. (Currently I'm working on blending functions with proper transparency handling, see #1675, and came across this inconsistency).

[lukeapage]

I think we should clamp. If browsers don't clamp, its a annoying bug to have.in less.

if for some reason browsers start allowing more than 256 color components we need to make bigger more general changes and handle that so I don't think clamping will ever hurt us.