Change the color of visited links to purple

[adamwoodnz]

Changes the color of all links which are not buttons to a new purple color, added to the palette.

This has wide ranging effects and will need to be overridden in some cases. I've drafted a corresponding mu-plugins PR for some of these, but it will probably need to be more expansive, see screenshots below.

Closes #128 Related https://github.com/WordPress/wporg-mu-plugins/pull/595

Screenshots (with local nav and breadcrumb overrides applied)

Developer	Showcase	Forums

Main	Documentation

How to test the changes in this Pull Request:

1. Build the styles
2. Test with dependent child themes; HelpHub, DevHub, Showcase, Main, etc
3. Visit links and observe the style afterward

[StevenDufresne]

Does it make sense to style it differently using the background colors?

Examples has-blueberry-1-background-color a:visited {} has-charcoal-1-background-color a:visited {}

[jasmussen]

Perhaps a controversial take, but IMO we should not be showing visited states outside of the main body content. That is, anything in headers, footers, navigation sections, etc, those should be "evergreen links", insofar as they are meant to be navigational aids, fixtures, that never grow "visited". I'd love to start there, if we can, and it should solve the need outlined here. Notably the homepage stands out as something that should not have purple links here. We can revisit and add nuance if need be.

That said, here's a light version of the purple, for contexts that need it: #D7A7FF

[ryelle]

I think this could work, since we are fairly consistent with applying the entry-content class to page contents:

:where(.entry-content a:not(.wp-element-button)) {
    &:visited {
        color: var(--wp--preset--color--purple-1);
    }
}

Using :where also keeps the specificity low enough so that sections & blocks using custom link colors stay that color.

Looks good on forums:

And documentation:

[fcoveram]

The above looks great to me

[adamwoodnz]

I think this could work, since we are fairly consistent with applying the entry-content class to page contents

This is working nicely!

I've found places where we don't have the .entry-content class applied, eg. https://wordpress.org/documentation/category/installation/, but these are few and far between, and I think if that's our standard/best practice then this is acceptable.