There is an outstanding ask in WHATWG to enable the color input to support alpha channels, among other things.@domenic outlines the following options in order to enable this:

• is already a mess. We could add more to the mess (e.g. a new type="" value, or a format="" that applies only to type="color", or valueWithAlpha/valueAsWideGamut getters, or...). Or we could start over with a new input type (e.g. like switch attempted). Although it'd be nice to avoid extending the mess, it sure is convenient and expedient.
• Reusing also has a better backward-compatibility story. For example if we did then in browsers that don't implement the user would get a text box, which might be better than nothing. Or, if we reused and added some of the additions mentioned above, we could have sites which accept alpha-less colors in older browsers and alpha-ful colors in new ones.

Further down the thread there is general agreement that the path forward will be a new tag that offers this capability due to backwards compatibility that changing <input type="color"> will cause. As Domenic later states:

I would prefer a new tag, though one completely unrelated to HTMLInputElement. (You can't have that as a base class without inheriting all of its complexity.)

There is still a demand for this functionality as I was just asked by someone on our SLDS team about this capability missing in the native controls. We should begin the work of doing the research for the color control in order to define this new HTML element.

Notes:

• Color has overlap of functionality with the <select> in that it has a <popup>, so certain discussions and resolutions we'll want to ensure are consistent
• Thorough research into the various color wells will need to be done
• Future proofing that control for extensibility, as @svgeesus noted in the other thread "do we only have 1 chance at this". The overall design of the IDL for color value selection and storage should be worked with closely with the CSSWG and color editors.