Completion kind Color for color keywords and hex 4 / hex 8

[romainmenke]

This builds upon and is directly related to : #315

My initial intention was to verify those changes but I quickly ran into issues.

Having a match for rgb in completionItem.documentation doesn't actually mean that the value is a color. This becomes more apparent when considering new color functions like lab which can easily be part of a larger word or can be used in a sentence.

A documentation string can also contain multiple values :

--border: 1px solid rgb(255 0 0);

I started writing regexp's to match actual color functions, but this exploded in complexity and would only cover the most simplistic of cases. I don't think it is ideal to have parser functions and regexp matchers for all the color functions.

---

However I do think it is valuable to add support for color keywords transparent and currentColor and to extend hex support to hex 4 and hex 8.

I also moved some regexp constructors outside of functions.

[aeschli]

That's a huge regex. We can just do a lookup in the colors object instead

[romainmenke]

This should be checked ascii case insensitive.
https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-invalid-named-color.html#L32

// Not a real upper case `K`
'blacK' === 'black'
// false
'blacK'.toLowerCase() === 'black'
// true -> incorrect
/black/i.test('blacK')
// false

vs.

// Real upper case `K`
'blacK' === 'black'
// false
'blacK'.toLowerCase() === 'black'
// true
/black/i.test('blacK')
// true

But maybe it's fine to be a little bit less strict here?

[aeschli]

Interesting, I didn't know that toLowerCase does that. We use it over the place to do case insensitive comparisons.
I suggest to ignore that for now.

[aeschli]

Does this make #315 obsolte?

[romainmenke]

I think so.

imho the remaining functionality from that PR is not possible with the current available API's'. It requires a way to assign a color attribute through a different field than completionItem.documentation.