input type="color" does not support transparent or opacity

[TheWebTech]

While there is reason to allow "transparent" or opacity to be optional on a color input there is no way to add it.

Perhaps an additional attribute opaque="false" or opacity="true"/ opacity could be used to progressively enhance these inputs.

<input type="color" opacity>

Sorry if I'm not following proper protocol for making a suggestion, first time making a suggestion here.

[edent]

Hello! Thank you for raising this issue. I'm going to ask you some questions so we make sure that we've understood you.

At the moment, colour* is defined as only being an RGB hex string. Ref:

• 2.4.6. Colors
• 4.10.5.1.14. Color state (type="color")
• Probably a few other places.

You want to be able to use RGBA. That is, redefine the colour spec so that it can optionally include alpha / transparency / opacity information.

Have I understood that correctly?

Your proposed solution is to add a boolean tag on to the <input type="color"> element. Is that right?

I could see this being more generic. For example

• <input type="color" opacity>
• <input type="color" rgba>
• <input type="color" cmyk>
• <input type="color" hsla>
• etc

The best place to discuss this is probably https://www.w3.org/community/wicg/ - but let's see if anyone wants to comment here.

* I'm British. I'll fight for that "u" to be included!

[TheWebTech]

@edent You understand perfectly correctly.

Your mentioning of the other formats raises a very good point.
They are all equally valuable but I don't think boolean would fit the situation well now that I recognize all the other possible options that make sense.

Your examples actually make me think we need something more like
<input type="color" colorformat="rgba">

and the valid colorformat values would be:

• rgba
• rgb(if you're going to include one doesn't make sense to not include the other)
• cmyk
• hsla
• hex[default if none specified]
• hexa(for 8 digit hex with alpha)

For RGBA, HSLA, HEXA browsers would show an alternate UI that adds an opacity/alpha control.
For the non alpha/opacity formats the current UI would suffice.

The way I see it all of these would end up changing the output - because you may/may not need the alpha channel.

The problem with boolean:
<input type="color" opacity rgba cmyk hsla>
Suddenly the above is possible.

Web Browsers would need to determine how to handle situations where multiple formats are used, and as far as the actual value of the input who knows what the output would actually be if multiple are specified.

And thank you for the advice on the community site - didn't know about it.

PS. We can make a polyfill for input type="colour". hah

[prlbr]

The CSS color module level 4 (working draft) defines a hexadecimal notation for RGBA values:
https://www.w3.org/TR/css-color-4/#hex-notation
And there’s already support by major browser engines for it:
https://caniuse.com/#feat=css-rrggbbaa
This is not the same as <input type='color'>, but it shows a precedent as well as interest in extending the RGB hex notation to RGBA in the web world. I think that it may not be too hard to make the same extension in HTML’s <input type='color'>.

Re: other color models – is there a need for that in the web world that justifies a different color picker build into the web browser? Are there such alternative color pickers build using JavaScript already that get use? Maybe that’s something the WICG would have input on.

[TheWebTech]

@prlbr just to clarify, my note above where I specified "hexa" as a color format value, I was referring to the notation you are talking about. Sorry, didn't know if there was a common term for it yet.

Regarding necessitating a different color picker. There are times where a developer would want to allow a user to pick a color but not allow transparency. This would not necessarily require a fully new color-picker just an update to the existing one that if the color format supports alpha/opacity, there would be some sort of opacity range, as well as "transparent" button(ex: color:transparent; is valid).

Example without allowing transparency:
An ecommerce store that lets you embroider text onto t-shirts. In this situation transparent or an opacity level is impossible. Therefore the input shouldn't allow it.

Example With Transparency:
A service like squarespace or an online design tool, the medium supports transparency and opacity therefore both a "transparent" and value with an opacity would be ideal.

Example scenario where other color format would be valuable.
Printing companies favor CMYK as that's what printers use. A website that allows a user to create print materials such as brochures, cards, business cards, etc. would be able to use this instead of having to convert rgb colors to CMYK.

While yes conversion IS possible through javascript - that argument is kind of lost on the fact the <input type="color"> field was also previously done with javascript and text inputs.

This change would help simplify the development process for apps like this.

Priority wise I think being able to toggle on the ability to set an opacity or set to transparent, on a color input is the most important part. Color format itself is more a developer problem and less user facing.

Regarding javascript libraries to solve the existing problem
These color pickers support alpha:
https://bgrins.github.io/spectrum/ - supports color formats, also includes text name of color
https://github.com/BraadMartin/components/tree/master/customizer/alpha-color-picker
https://github.com/PitPik/colorPicker - also supports CMYK

[cynthia]

One issue I see with this request is that not all OS color picker controls (natively provided) necessarily have support for alpha channels (e.g. Legacy Windows API, GTK come to mind) - what would be the expected behavior there? I'm not sure if it would be helpful if browser vendors have to each implement a custom color picker to work around this limitation.

[cmawhorter]

so first of all -- i'll give the brits grey > gray, but i'll fight another war before i use colour ;]

i was kinda surprised that input[type=color] didn't support this. after thinking about it though, it kinda makes sense since transparency doesn't -- strictly speaking -- have anything to do with color.

that said, my vote is for choosing a winner (rrggbbaa) and allowing alpha through a flag, or maybe even the value itself <input value="#FFFFFF00"> results in allowing alpha. <== on chrome that currently displays black just like value="#FFF"

[TheWebTech]

@cmawhorter appreciate you continuing the conversation on this and the humor about british English.

I think implementation wise rrggbbaa would be fine as the default. I think color formats as an attribute would be cool down the road but getting the basic functionality is really more important

[mojimi]

Seeing as the color input is mostly used to modify an element's color/background-color, being able to define opacity is very relevant and necessary, what happens in most cases is that an extra slider is needed for opacity.

The actual issue here I think is the implementation, on Windows, the color swatch used is the legacy ChooseColor box which does not support opacity, but funnily enough, Microsoft Edge does not use the legacy box, instead it has a very nice custom javascript color picker, it has no opacity of course because the specification doesn't say so.

Edge color picker :

[TheWebTech]

Im honestly not even sure that's going to stay the same now that edge is moving to chromium. Likely theyre going to mimic what chromium has.

[barkermn01]

I would like to say I have just needed this now looking for a Javascript alternative.

I would support the edge way as @mojimi said. It should not be using Windows API or GTK it should be using a built into the browser the same as almost all other modern input types, such as the Number, Date Picker or Range to list a few.

There is absolutely no reason to use use the OS default for this there have been DOM and browser JS implementation for years before this was added to the Spec, perhaps should also have an issue raised with chromium over the matter because the only other one that uses the standard OS stuff is file selection (AKA <input type="file">) I think and JS removes the need for that with File drag and drop and paste listener event,

UPDATE:
I found something that is almost perfect for this https://bgrins.github.io/spectrum/ perhaps it requires an option for paletteE.G palette="RGB(0,0,255), RGB(0,255,0), RGB(255,0,0), RGBA(204,204,204,0.5)" or palette for default and missing to disable the pallet but that's my thoughts on it

But otherwise, I think that this would be perfect for browsers to use as an example of how browsers should do this. the worst part which I forgot about until I found this is they have the damn thing implemented in the dev tool's why did they not implement it into the main system???

[siusin]

Thanks all.

We're closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.

If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.

If you have questions about this, please open an issue on the W3C HTML WG repository or send an email to public-html@w3.org.

[barkermn01]

@siusin This should not just be closed it needs porting sufficiently, this was under incubation and has some great idea's inside it and an agreement that this needed dealing with.

[siusin]

@barkermn01 Understand. We plan to make this repo archived so that all the historical discussion will be kept. For future discussion, could you please open a new issue on the WHATWG repository or start a conversation in the Web Incubator CG ?