Proposal: the data attribute of an event of inputType "formatFontColor" should be in RGB/RGBA format

[whsieh]

Currently, the spec (at https://w3c.github.io/input-events/) states that the data attribute of an input event of type "formatFontColor" is "the simple color value...of the proposed color". According to the linked spec (https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#colours), "A simple color consists of three 8-bit numbers in the range 0..255, representing the red, green, and blue components of the color respectively, in the sRGB color space."

It seems like this would preclude the possibility of setting transparent colors, or colors in an extended color space. Would it be reasonable to tweak the spec so that the data attribute would take on value that match CSS text when using, say, getComputedStyle(element).color?

[whsieh]

• @rniwa @johanneswilm @choniong

[johanneswilm]

This is absolutely possible. Safari is the only browser with such a color menu. The term "simple color" came out of the TAG review:

While we understand that this comes from a underlying infrastructural issue (HTML) - colors are just mentioned as "hex digit value", which could be a bit more specific. I believe the concept you are looking for is simple color (defined in HTML), but this has the downside of not having alpha channel support.
https://html.spec.whatwg.org/multipage/infrastructure.html#colours [1]

For JS editors to be able to deal with this event effectively, it would be a good idea to not give colors in many different formats. @whsieh would it be OK if we limited the colors to RGB and RGBA [2]?

[1] w3ctag/design-reviews#160 (comment)

[2] https://www.w3.org/TR/css3-color/#rgba-color

[whsieh]

I see! If JavaScript compatibility is the big concern here, I think limiting to rgb() and rgba() is a reasonable compromise for the time being.

Hopefully, this doesn't lock us into only being able to specify rgb/rgba in the future though? While there's currently no UI affordance in Safari to specify deep colors for text/backgrounds, it doesn't seem unreasonable to add such options.

[johanneswilm]

No, future specs could expand on the list of allowed values, so this will not create a lock-in.

The values may have to be read by JavaScript, so allowing any type of color values would mean that the JS color parser would have to be much more complex than if we only allow RGBA/RGB.

A parser could be as simple as this if only rgb/rgba was allowed:

data.replace(/[^0-9,.]/g,'').split(',').map(str => parseFloat(str))

So the current proposal is to exchange the term "simple colors" with "RGB/RGBA colors" (linking to the CSS color spec instead of the infrastructure document).

[whsieh]

Got it — changing the "simple colors" requirement to "RGB/RGBA colors" sounds good to me. Thanks for the explanation!

[johanneswilm]

approved by today's editing taskforce call

[johanneswilm]

fixed in 95b1b48

[johanneswilm]

level 1 fix in 88bb8ac