Re: [calsify] non-CSS-named colors for events

[Ken Murchison <[e-mail]>]

On 6/9/22 12:27 PM, Ricardo Signes wrote:
> Hello!
>
> tl;dr:  I think the rarely-used COLOR should have a facility for RGB 
> colors, not just named colors.
>
> RFC 7986 <https://datatracker.ietf.org/doc/html/rfc7986> provides the 
> COLOR property 
> <https://datatracker.ietf.org/doc/html/rfc7986#section-5.9> for 
> specifying color on a per-event basis.  It defines the value as a 
> string that must be a named CSS3 color.
>
> Calendar users, unsurprisingly, very often push for more control, and 
> want a full selection of RGB colors.  This is permitted in jsCalendar, 
> where the color 
> <https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar/#section-4.2.11> event 
> property can be a named color /or/ an RGB hex value.  At present, 
> there is no means to map a non-CSS-named color from jsCalendar back to 
> iCalendar.
>
> Erratum 5449 <https://www.rfc-editor.org/errata/eid5449> was filed, 
> suggesting that RFC 7986's COLOR property should have allowed for 
> "rgb(r,g,b)" formatted hex colors.  This erratum was not accepted.
>
> We (Fastmail) plan to support RGB color for events using JMAP for 
> Calendars and jsCalendar, and so need to map these values back to 
> iCalendar.  I am not familiar with any existing clients that use the 
> COLOR property, but would be happy to be pointed at some, and at how 
> they may handle this problem.  In the meantime, here are options we 
> have been thinking about:
>
>  1. act like the erratum was accepted and use "rgb(r,g,b)"; maybe
>     somebody else has done the same, but parsing that, especially
>     given the structural commas, is not appealing
>  2. just put #RRGGBB into COLOR as needed; any human would understand
>     what is happening and could adjust accordingly; file a proposed
>     update;  nice and simple, directly maps to jsCalendar
>  3. like the above, but add an attribute to the property:
>     |COLOR;VALUE=HEX:FF0000|
>  4. store weird colors in some experimental property; this is
>     unappealing, as it seems like a bit of a dead end
>  5. store weird colors in CATEGORIES, which Fantastical does, but is
>     otherwise as unappealing as using an experimental property
>

I'd vote for #2 or #3 with a preference for #3, as it is more explicit 
as to the type of the value and doesn't require any "magic" text 
prefix.  Of course, VALUE=HEX would have to be defined (I'd be willing 
to write a draft).


-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC