Subject: [calsify] Proposed Errata №5449 for RFC 7986: COLOR property with arbitrary RGB values

From: Дилян Палаузов <[email-masked]>
Date: Wed, 10 Oct 2018 09:16:58 +0000

Hello,

what shall happen, so that https://www.rfc-editor.org/errata/eid5449
makes progress?

Regards
  Дилян

On Thu, 2018-06-28 at 22:04 +0000, Дилян Палаузов wrote:
> Hello,
> 
> I would like to suggest the following Errata and welcome any comments
> within a month.
> 
> My reading is that COLOR now cannot have the value RGB(61,211,68)
> 
> Please correct me, if I am wrong.
> 
> RFC 7986 (new Properties for iCalendar)  Section 5.9. COLOR Property
> says:
> https://tools.ietf.org/html/rfc7986#section-5.9
> 
> Type: Technical
> Section: 5.9 COLOR Property
> 
> Origianl text:
> 
> Description:   ...The value is a case-insensitive color name taken from
> the CSS3 set of names, defined in Section 4.3 of [W3C.REC-css3-color-
> 20110607].
> 
> Example:  The following is an example of this property:
>    COLOR:turquoise
> 
> Corrected text:
> 
> Description:   ...The value is either a case-insensitive color name
> taken from the CSS3 set of names, defined in Section 4.3 of [W3C.REC-
> css3-color-20110607], or an RGB() functional  notation with absolute
> values specified in Section 4.2.1 of the same document
> 
> Examples:  The following are examples of this property:
>    COLOR:turquoise
>    COLOR:rgb(61\,211\,68)
> 
> Notes for the errata:
> 
> draft-daboo-icalendar-extensions-07 removed the possibily to have RGB
> colours for COLOR.
> 
> CSS3 included color names, that browsers at that time suppored,
> originating from X11's rgb.txt.  The color names and values were
> randomly chosen.  The minimal distance between the colors isn't
> consistent.  One motivation for creating a color name were hardware
> capabilities - an argument which isn't valid for 20 years now.  There
> is no reason to limit the number of possible values for COLOR.  A user
> interface for choosing a named color has either to offer the user the
> possibility to choose from a pre-filled list of colors, which could
> clutter the interface, or let the user choose any RGB color and narrow
> it later to the closest color with CSS3 name.  This narrowing isn't
> trivial and performing it seems like having an RFC running in itself.
> 
> Notes for this message, outside the errata:
> 
> Gnome Evolution recently added support for the COLOR property and
> uploaded iCalendar files by it now have:
> COLOR:rgb(61\,211\,68)
> 
> https://www.w3.org/TR/2011/REC-css3-color-20110607/ lets also other
> forms:
> #f00
> #ff0000
> rgb(100%, 0%, 0%)
> 
> I have no propbem to let or exclude any of the forms above.  The main
> challenge is neither to have the user chose from a final list of
> colours, nor to let her choose any colour but narrow the selected
> colour afterwards to something.  Letting more than one form of the
> mentioned above would be overengineering for the mentined challanage.
> 
> https://github.com/w3c/csswg-drafts/issues/2813 states the colours are
> chosen randomly, and http://christopher.org/history-web-color-names/
> proves this thesis.
> 
> Randomly choosen colour values (having names coming from rgb.txt) are
> not suitable to achieve any aim.
> 
> I haven't worked with colour terms until today, so feel free to
> rephrase the rgb-functional sentence.
> 
> Regards
>   Дилян
> 
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify