-
Notifications
You must be signed in to change notification settings - Fork 544
input type="color" does not support transparent or opacity #1422
Comments
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:
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 I could see this being more generic. For example
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! |
@edent You understand perfectly correctly. Your mentioning of the other formats raises a very good point. Your examples actually make me think we need something more like and the valid colorformat values would be:
For RGBA, HSLA, HEXA browsers would show an alternate UI that adds an opacity/alpha control. 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: 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 |
The CSS color module level 4 (working draft) defines a hexadecimal notation for RGBA values: 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. |
@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: Example With Transparency: Example scenario where other color format would be valuable. While yes conversion IS possible through javascript - that argument is kind of lost on the fact the 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 |
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. |
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 |
@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 |
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 : |
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. |
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 UPDATE: 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??? |
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. |
@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. |
@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 ? |
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.
The text was updated successfully, but these errors were encountered: