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

[Dilyan Palauzov <[e-mail]>]

Hello,

I think erratum 5449 does not make progress, because it introduces a  
backward incompatible change…

> 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:

… which change does not break any known client (CUA).  Or since nobody  
has implemented the property, there is lack of interest on the erratum.

DAVx⁵ (Android) and Evolution (Gnome) do support per event colour.  I  
think in Evolution the users can select any colour, which is then  
casted internally to the closest CSS3-value (as Cyrus IMAP does).

>  2. just put #RRGGBB into COLOR as needed;

In favour.  When I wrote that erratum there were some discussions on  
this list and in that discussions there might be in the archives  
arguments against this form.  I do not remember.  At the end I chose  
for simplicity to include a single way for presenting RGB.


While at RFC7986, it introduces the LANGUAGE parameter and permits  
specifying multiple DESCRIPTION properties, each with a different  
language.  This definition of DESCRIPTION in RFC7986 updates  
https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.1.5, and the  
latter states, that DESCRIPTION can be present only once in VEVENT and  
VTODO and multiple times in VJOURNAL.

Is there any software, which utilizes DESCRIPTION in more than one language?

Greetings
   Дилян

----- Message from Ricardo Signes <[e-mail]> ---------
    Date: Thu, 09 Jun 2022 12:27:55 -0400
    From: Ricardo Signes <[e-mail]>
Subject: [calsify] non-CSS-named colors for events
      To: [e-mail]


> 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
> --
> rjbs


----- End message from Ricardo Signes <[e-mail]> -----