@DTorsani-WMF I think the revised approach is good. Let's not unnecessarily add scope to this right now, the focus is on getting things to work for dark mode. We should track what you've described as 'Phase 2' in T333681.

Agreed, I think we need an updated version of T362861

Thanks for chiming in. I've updated this patch with this revised approach, to use Codex tokens but match [as closely as possible] the existing colors for both backgrounds/borders and text individually. I will work on getting someone on DST to review this patch and get it merged in in preparation for the next Codex release.

Additionally, T366280 is a new task for future exploration of improving diffs/bytes altogether.

Change #1031609 merged by jenkins-bot:

[design/codex@main] tokens: Update `content-added` and `content-removed` token values

https://gerrit.wikimedia.org/r/1031609

Change #1041776 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] Update Codex from v1.6.1 to v1.7.0

https://gerrit.wikimedia.org/r/1041776

Change #1041776 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.6.1 to v1.7.0

https://gerrit.wikimedia.org/r/1041776

Confirmed!

To add a bit more explanation, the original colors are not colors available in Codex. So to assign these as tokens, we need to use the closest existing color while considering how the two new colors compare to one another.

The color for added text changes from the dark green to green700.
The color for removed text changes from the dark red to red700.
These are relatively subtle changes.

The color for diff added background changes from the light blue to a slightly darker blue, blue300.
The color for diff removed background changes from the light yellow to a slightly darker but also brighter yellow, yellow500.
Although the closest colors to the originals for this application would be the 100 values of each color, this would make these even lighter, further decreasing the contrast and there the accessibility. Instead we move the opposite direction to a darker value. As seen in the Codex option tokens color file, the next value from yellow100 is yellow500. Although the blue spectrum has a blue250 value, in order to be more visually balanced with the diff removed background color of yellow500, we use blue300 instead to address the goal mentioned above:

we need to use the closest existing color while considering how the two new colors compare to one another.

A broader expansion of the color palette is being worked on in T360494 which will provide more values and colors to choose from when we can address a potential revision to how we handle diffs in general as a part of T333681.

Change #1041814 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@master] Use upstream codex variables for diffs and red links

https://gerrit.wikimedia.org/r/1041814

Change #1031504 merged by jenkins-bot:

[mediawiki/core@master] Use Codex design tokens in diff.less

https://gerrit.wikimedia.org/r/1031504

Change #1031511 merged by jenkins-bot:

[mediawiki/core@master] Use standard Codex colors on changelist diffs

https://gerrit.wikimedia.org/r/1031511

Change #1041814 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Use upstream codex variables for diffs and red links

https://gerrit.wikimedia.org/r/1041814

I want to suggest using pure black / --color-emphasized for changed text in ‘day theme’ because currently, the new ‘added’ colour feels pretty much hard to read with the grayish colour used for text by default. Maybe it is just my impression, but I think when this gets deployed, you will hear many similar opinions, especially since this change will take communities by surprise.

The color choice for light mode makes no sense to me. Desaturated blue (almost gray) versus saturated yellow. I mean, colors shouldn't be completely random, decided solely by the existing palette and numbers; there should be at least some concern for aethetics, even if we agree the colors don't necessarily have to be meaningful. The "added content" background is just repulsive to me as background for text, even if it passes WCAG 2.1.

even if it passes WCAG 2.1

(Well it doesn't actually)

I agree with the above, these colors (at least in light mode) are way too intense and saturated., distracting from the actual content itself.

Is it possible to override this change using CSS?

@1AmNobody24 from enwiki thread: (https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Heads-up:_Diff_colour)

.diff-deletedline {

border-color: #ffe49c;

}
.diff-addedline {

border-color: #a3d3ff;

}
.diff-deletedline .diffchange,
.mw-diff-inline-deleted del, .mw-diff-inline-changed del, .mw-diff-inline-moved del {

background: #ffebad;

}
.diff-addedline .diffchange,
.mw-diff-inline-added ins, .mw-diff-inline-changed ins, .mw-diff-inline-moved ins {

background: #a3d3ff;

}

Though if these are problematic, it would be best addressed at the root

I would recommending adding the following code to https://en.wikipedia.org/wiki/Special:MyPage/vector-2022.css to restore the old colors (it's cleaner and less prone to breakage than the one suggested by @Xaosflux)

:root {
  --color-content-added:  #006400;
  --color-content-removed: #8b0000;
  --background-color-content-removed: #ffe49c;
  --background-color-content-added: #a3d3ff;
}

If using a skin other than Vector 2022 for desktop site in addition to the above also add:

.diff-deletedline {
  border-color: #ffe49c;
}
.diff-addedline {
  border-color: #a3d3ff;
}
.diff-deletedline .diffchange,
.mw-diff-inline-deleted del, .mw-diff-inline-changed del, .mw-diff-inline-moved del {
  background: #ffe49c;
}
.diff-addedline .diffchange,
.mw-diff-inline-added ins, .mw-diff-inline-changed ins, .mw-diff-inline-moved ins {
  background: #a3d3ff;
}

I agree with JWBTH. The new color has 20% less contrast on the subtitle text. They don't provide adequate contrast.

I don't understand why "background-color-content-added" and "background-color-content-removed" can't use different shades of the same colors as "color-content-added" and "color-content-removed" (i.e. green and red), just as "background-color-success-subtle" and "background-color-error-subtle" use lighter shades of the same colors as "color-success" and "color-error".

https://doc.wikimedia.org/codex/latest/design-tokens/color.html#background-colors

In T361717#9882777, @DTorsani-WMF wrote:

Although the blue spectrum has a blue250 value, in order to be more visually balanced with the diff removed background color of yellow500, we use blue300 instead to address the goal mentioned above:

Actually:

• the yellow500 (#fc3) has a relative luminance of 0.6468, which gives a 1:1.5 contrast ratio against the white background and 1:10.7 agaist the foreground;
• the blue300 (#afb6e9) has a relative luminance of 0.4845, which gives a 1:1.96 contrast ratio against the white background and 1:8.21 against the foreground.

They are not visually balanced. This blue is harder to read from than yellow. And while the primary aim of diff is too read from and not to look at, it makes a difference. Yes, the contrast ratios are still above WCAG threshold but it's a drop in readability and not an increase.

However, the mentioned blue250 (#c2d1f0) has a relative luminance of 0.6336, which gives a 1:1.53 contrast ratio against the white background and 1:10.5 against the foreground (very similar to yellow500). This is what can be balanced to match yellow500 without having loss of accessibility at the same time.

I agree however that these new colors seem "too bold" for me (and not only me, I've heard similar voices from the community).

They are not visually balanced. This blue is harder to read from than yellow. And while the primary aim of diff is to read from and not to look at it makes a difference.

Yup.
And it's much worse on m.wikipedia.org where the diff text is not bold.

In T361717#9914956, @Msz2001 wrote:

However, the mentioned blue250 (#c2d1f0) has a relative luminance of 0.6336, which gives a 1:1.53 contrast ratio against the white background and 1:10.5 against the foreground (very similar to yellow500). This is what can be balanced to match yellow500 without having loss of accessibility at the same time.

blue250 is better in terms of contrast, but it is even lighter than blue300 in terms of HSL which gives you two colors that have nothing in common: neither hue, nor saturation, nor lightness. Saturated, medium-light yellow against desaturated, light blue. It's basically a warning color against a neutral color which is how they are going to be perceived, whether we want the colors to convey that meaning or not:

I'm not saying this is necessarily wrong (deleted content needs attention, while added content is supposed to be normal = neutral?), but that's a whole new semantics, and there needs to be a design decision made for switching to it. Or maybe a better idea would be to expand the palette T360494.

In T361717#9914856, @Nardog wrote:

I don't understand why "background-color-content-added" and "background-color-content-removed" can't use different shades of the same colors as "color-content-added" and "color-content-removed" (i.e. green and red), just as "background-color-success-subtle" and "background-color-error-subtle" use lighter shades of the same colors as "color-success" and "color-error".

I think the general argument against red and green is that the color blind can't tell them apart.

Wikidata (Wikibase) diffs often contain links, which became barely readable with this change. Using default link color (used by Vector 2022, Minerva and Timeless), the contrast ratio on the added side is about 60% of the AA-level 1:4.5. (Vector 2010 is slightly less bad, but the added side – with a contrast ratio of 1:4.34 – still isn’t WCAG AA-compliant).

One accessibility aspect that hasn't been discussed much is accessibility to those with mild cognitive impairment. If you avoid both red and green in diff colours, you create a barrier for these editors. A better strategy is to stick close to the red-green, for instance orange-teal. Or pinkish red vs blue.

Intuitive colours should also be a help for new editors. I still have to make a conscious effort to read the diffs, slowing down my editing.

Thank you everyone, both in this task and elsewhere, who have provided feedback on the recent diff color changes. Your feedback is incredibly valuable and helpful. As we were attempting to enable color modes and add in new tokens to represent diff colors, we missed some really important things that you all have pointed out, so thank you for your help here. For now, we are going to change these color tokens to use the previous colors for diffs. This update will be included in the Codex release next week, on July 9.

Additionally, we are going to begin work on T360494 to expand the color palette which will enable us to reconsider diff styling more holistically as a part of T333681, where we can revisit what colors we use altogether, including red and green as an option to explore, with a goal of unifying diff colors everywhere. This should set an expectation that the colors will change again. We would greatly appreciate your input on those tasks.