Better hex to rgba conversation

[panych]

Feature request: better hex to rgba conversation.
Task: compact way to convert HEX color with transparency to rgba

Now there are two ways to do that:

@base-color: #3399cc;

// now we need this color in 20% transparency, it will be rgba(51, 153, 204, 0.2)
// solution #1
body {
    color: rgba(red(@base-color), green(@base-color), blue(@base-color), 0.2);
    // color: rgba(51, 153, 204, 0.2);
}

// solution #2
span {
    color: fade(@base-color, 20%);
     // color: rgba(51, 153, 204, 0.2);
}

I think that fade function is not very appropriate here and we can create new function for this task or update rgba. Example:

@base-color: #3399cc;

html {
    color: hex2rgba(@base-color, 0.2);
    // color: rgba(51, 153, 204, 0.2);
}
// or this way
body {
    color: rgba(@base-color, 0.2);
    // color: rgba(51, 153, 204, 0.2);
}

[seven-phases-max]

Could you please elaborate on why exactly you think that fade function is not very appropriate here?
Is it only because of 20% vs. 0.2? If so the answer is just: fade(@base-color, (100% * 0.2));

[lukeapage]

You can pass 0.2 to the fade function...

[seven-phases-max]

@lukeapage

You can pass 0.2 to the fade function...

We can but the result is rgba(51, 153, 204, 0.002);. I also was under impression that these functions do distinguish percentage and unitless values, but they don't, it's always percentage regardless of %.

[panych]

@seven-phases-max

Is it only because of 20% vs. 0.2? If so the answer is just: fade(@base-color, (100% * 0.2));

I don't think that fade function is appropriate name for function which should convert hex to rgba.

For my opinion, rgba function should "make" rgba color. So I suggest to make arguments for this function more flexible. I think examples will be helpful:

body {
    rgba(51, 153, 204)       // rgba(51, 153, 204, 1)
    rgba(51, 153, 204, 0.2)  // rgba(51, 153, 204, 0.2)
    rgba(51, 153, 204, 20%)  // rgba(51, 153, 204, 0.2)
    rgba(#3399cc)            // rgba(51, 153, 204, 1)
    rgba(#3399cc, 0.2)       // rgba(51, 153, 204, 0.2)
    rgba(#3399cc, 20%)       // rgba(51, 153, 204, 0.2)    
}

[lukeapage]

I'm not sure if thats a bug or not, I thought you could pass 0.2 or 20% into fade.

I think the thinking behind fade was that we have functions to allow you to modify each component, e.g. red, green, blue and I assume we went for fade instead of alpha to not interfere with filter: alpha(opacity = (@opacity * 100)); so it is kind of consistent.. we are editing the fade aka the alpha of a color.. we are not converting from hex to rgba or rgb.. it just so happens that at the moment less can only output colours with opacity using rgba.. For instance, there is a legacy microsoft format to allow you to specify alpha as a 8 character hex value. There is transparent which is a color corresponding to rgba(0, 0, 0, 0)..

so I don't think fade is inconsistent if you think of it in the right way.

In terms of your rgba examples, allowing missing off the alpha component seems a little dangerous.. I see that as someone who intended to add an alpha component and then forgot - so I think it might be useful showing an error.

Allowing 20% as the last argument to rgba seems okay, as does rgba(#3399cc, 0.2) but we have to ask ourselves how much benefit this gives users versus the complexity it adds to the language..

In addition.. you seem to not like fade because you are considering that you are converting a hex value to an rgba value.. and yet at the moment rgba(51, 153, 204, 1) becomes #3399cc.. and why shouldn't it if we are compressing the output?

[Synchro]

I agree with @lukeapage, I think fade is appropriate. rgba as a function name sounds like something that would simply define a colour, not something to adjust the transparency of an existing one. I do think the 0.2/20% thing is a bug though.

[Synchro]

I think most of @panych's examples are all reasonable ways of defining an rgba colour, but I foresee problems with having it replace fade. For example, what should this do?

@c: rgba(51, 153, 204, 0.2);
@d: rgba(@c, 0.2);

should that result in no change to transparency or a change to 0.04? There is no ambiguity when using fade in that situation.

[panych]

I would suggest to live fade function as it is, ie use percentages (0-100) as opacity value.

In terms of your rgba examples, allowing missing off the alpha component seems a little dangerous.

Agree

Allowing 20% as the last argument to rgba seems okay, as does rgba(#3399cc, 0.2) but we have to ask ourselves how much benefit this gives users versus the complexity it adds to the language..

I still thinks that rgba function can be more flexible, and allow us to path hex color as first argument. But use only native for rgba values from 0 to 1. It's really helpful, because most of the time we use hex and remember about rgba only when need alpha channel. I use this feature in Sass most of the time.

@rgb: rgb(255, 200, 200); // #ffc8c8

// it throws an error now, but it will be nice if makes an 'rgba(255, 200, 200, 0.5)'
@rgba: rgba(@rgb, 0.5); // 

So at the end the list of accepted values:

body {
    rgba(51, 153, 204)       // error
    rgba(51, 153, 204, 0.2)  // rgba(51, 153, 204, 0.2)
    rgba(51, 153, 204, 20%)  // error
    rgba(#3399cc)            // error
    rgba(#3399cc, 0.2)       // rgba(51, 153, 204, 0.2)
    rgba(#3399cc, 20%)       // error    
}

About alpha-hex: it's looks like there is no hex alpha format now: http://www.w3.org/TR/css3-color

[seven-phases-max]

About alpha-hex: it's looks like there is no hex alpha format now:

Not now but sometimes they come back: http://dev.w3.org/csswg/css-color/#hex-notation

rgba(51, 153, 204, 20%) // error

It will also most likely become valid CSS syntax.

[Synchro]

8-digit hex has been around before in IE, except that it was #AARRGGBB, just to be different...

[stevenvachon]

I like hexa() better than both fade() and hex2rgba(). What do you guys think?

[Synchro]

I don't think hexa is a very good name because fade accepts a colour in any format, not just RGB hex, and I don't think it would ever occur to me to search for hexa - I'd be more likely to look for 'transparent' which leads straight to fade on lescss.org.
Is hexa used in some other context? I've never seen it before. Adding synonyms is a pretty bad idea if we're trying to keep things tidy as there are way too many combinations. Fade is nicely generic, descriptive and doesn't tie itself to any particular format or colour space. hexa or rgba as synonyms for fade would allow you to do seemingly nonsensical things like:

color: hexa(rgb(0.5, 0.5, 0.5), 50%);
color: rgba(hsv(90, 100%, 50%), 50%);

Following that logic we'd end up with hexain and hexaout etc... We do have separate operations for rgb, hsv etc, but hex is not a colour space - it's a representation of RGB.

Aside from the percentage thing, I don't think any of these names have sufficient merit.

[seven-phases-max]

Aside from the percentage thing, I don't think any of these names have sufficient merit.

+1

[stevenvachon]

I don't think it would ever occur to me to search for hexa

Everyone thinks differently, and fade() did not occur to me, though mostly because it wasn't grouped along with rgba(), hsla() and hsva(). Perhaps it's a documentation thing. I honestly don't know why hexa() was not added to the CSS specification considering the other two, regardless if hex is RGB-based.

Anyway, I was never suggesting that we should get rid of fade(), though. It is—as you have said—generally more usable.

[lukeapage]

I'm a bit lost here on this. Is this waiting implementation or have people given up and generally think it is no longer needed?

[Synchro]

I think fade() does the job requested, and there's no need to change it, so should close.

[matthew-dean]

Interestingly, I came across this, when I was seeing if there was a solution to issue #2379. (Of course, that requires converting a decimal alpha unit to hex, which we don't currently have.) _EDIT: Oops, I forgot about argb()!_

On this, I think the original issuer was confused because it seemed that fade was for converting hex to rgba. It is but only as a necessity; we just have to convert from hex to either rgba or hsla to represent the new color generated by fade(). So it doesn't really have anything to do with hex conversion. Fade() is for setting the alpha channel of a color. So, as it stands, agreed this issue seems closable.

[seven-phases-max]

So let's finally close it. There's no issue here (fade is not going to be renamed, and those percentage vs. generic float value things mentioned above are a subject to be improved/fixed elsewhere).