Steps to reproduce: 1. Go to https://jsfiddle.net/v79uznt7/1/ 2. Open JS console 3. Put cursor in the editable body 4. Use the touch bar to set the color of the text Observe that e.data is sent as "rgb(x, y, z)" This is inconsistent with the spec for Input Events (https://w3c.github.io/input-events/) which states that `If the inputType is "formatBackColor" or "formatFontColor" the value of data is to be the hex digit value of the proposed color.` While the formatForeColor event is not specified in the Input Events spec, it would be nice to be consistent on how this data is represented across all events. Secondly, why is formatForeColor being used and not formatFontColor?
<rdar://problem/30424022>
Hey Dominic! Indeed, the way WebKit currently serializes colors is definitely not consistent with the spec (https://w3c.github.io/input-events/index.html). However, I'm not sure there's a compelling reason that this should be in #RRGGBB format, as opposed to the color format used for computed style, which would be able to capture a broader range of colors (e.g. transparent colors, and even colors in an extended color space). I proposed this spec tweak to Johannes in https://github.com/w3c/input-events/issues/67, and it looks like he's okay with changing the spec to limit colors to RGB and RGBA for now, which would be consistent with our current behavior. The rich text controls on the touch bar don't provide a way to specify deep colors at the moment, so I think all choosable colors should fall into RGB or RGBA. Does this sound reasonable to you?
Sounds good to me!
An update: Johannes tweaked the input events spec so that the `data` attribute now allows for an rgb function in https://github.com/w3c/input-events/commit/95b1b4802a1967ef14b9aff1a0fa005c7857015d. I think we can now close this bug as Invalid. (Also, I've renamed formatForeColor => formatFontColor earlier, in a separate patch).
Mass move bugs into the DOM component.