[css-ui] Resolved value of caret-color should be the used value

[mrego]

As discussed on issue w3c/csswg-drafts#781, I'm updating the tests
so that caret-color behaves similar to the rest of color properties.

---

This change is 

[syncbot]

Automatic validation checks of commit a96e1b4 passed.

[syncbot]

Automatic validation checks of commit 5b3a864 passed.

[frivoal]

The change look good to me assuming we resolve on w3c/csswg-drafts#566 that for colors the resolved value is the used value. I think we will, but we haven't yet. I'll merge as soon as we do.

[syncbot]

Automatic validation checks of commit b96acae passed.

[frivoal]

The change assumes we resolve on w3c/csswg-drafts#566 that for colors the resolved value is the used value. The WG just did so, so it looks all good.

[frivoal]

@gsnedders (CC @plinss @astearns @atanassov) I want to merge this pull request, but "the system" is getting in the way:

1. What's up with this failling / stalling travis CI checks? Are they doing anything valuable? Cause all I see them do is fail on perfectly reasonable pull requests and get in the way.
2. Why does github keep on insisting that branches are too old, and that I need to merge master into it? This is a clean merge, and the vast majority of the things in that repo are independent from eachother, so the risk of having issues due to an old branching point are minimal. I wouldn't necessarily mind doing the update anyway, except that it triggers a lengthy and often (randomly?) failing travis run.

I am sure that I am missing something, but this is a nuisance. So either the failure is caused by a real problem that needs to be address, in which case we need to make it much clearer what that problem is so that I know what I need to do, or it is not, and we need to get these annoyances out of the way.

[syncbot]

Automatic validation checks of commit 984848a passed.

[mrego]

1. What's up with this failling / stalling travis CI checks? Are they doing anything valuable? Cause all I see them do is fail on perfectly reasonable pull requests and get in the way.

I've fixed this in #1164.

2. Why does github keep on insisting that branches are too old, and that I need to merge master into it? This is a clean merge, and the vast majority of the things in that repo are independent from eachother, so the risk of having issues due to an old branching point are minimal. I wouldn't necessarily mind doing the update anyway, except that it triggers a lengthy and often (randomly?) failing travis run.

I'm not completely sure that I'm right but trying to reply with my guesses. 😄
I guess that if master was broken when you start the PR, even if it's fixed later, you'll still get that Travis CI doesn't pass. That's why GitHub offers you the chance to Update branch and get the last commits from master.
I just did it and now Travis CI is happy.

[frivoal]

I just did it and now Travis CI is happy.

Thanks. I had updated the branch to get the latest from master, but I had not fixed master first.

However it is that broken commits are getting into master, we should stop that. Or we should fix travis to only block on new errors introduced in the pull request, not those already present in master.