Ensure component links account for base link styles

Issue Description

All links now include the following styles:

a {
  background-color: transparent; /* Remove the gray background on active links in IE 10. */
  color: var(--terra-link-color, #0065a3);
  outline: none;
  text-decoration: underline;
}

a:visited {
  color: var(--terra-link-visted-color, #0065a3);
}

a:hover {
  color: var(--terra-link-hover-color, #004c76);
}

a:focus {
  background-color: var(--terra-link-focus-background-color, transparent);
  border-radius: var(--terra-link-focus-border-radius, 0.2142rem);
  box-shadow: var(--terra-link-focus-box-shadow, 0 0 1px 3px rgba(76, 178, 233, 0.5), 0 0 7px 4px rgba(76, 178, 233, 0.35));
  color: var(--terra-link-focus-color, #004c76);
}

a:active {
  color: var(--terra-link-active-color, #004c76);
}

With this, we need to look at places where we use anchors in our components, and ensure the link pseudo classes of those different components account for this new set of base styles. This issue is an example of a component where the base styles of a:visited conflicts with our intended styles. To fix that issue, we need to update styles for button when it renders as an anchor to account for the base a:visited styles.

Issue Type

• New Feature
• Enhancement
• Bug
• Other

Expected Behavior

Component with anchors render correctly with new base link styles

Current Behavior

Components with anchors render incorrectly in the link pseudo classes with the new base link styles

Steps to Reproduce

1. Create a terra button component with an href
2. Visit the link
3. Go back to original page to see new text color

Environment

• Component Version: Not completely sure, but I believe its the Terra-Base (version 2.11.0)
• Browser Name and Version: Chrome Version 63.0.3239.132 & Firefox 58.0.1 (64-bit)
• Operating System and version (desktop or mobile): macOS Sierra Version 10.12.6 (desktop)

[bjankord]

We’ll plan to move forward with option 2 and revert the changes to terra base and release a bugfix release: terra-base@2.11.1 with the global link styles removed. With option 2, the cost is lower for teams to mitigate the trade-offs compared to the other options identified.

[bjankord]

The OCS UX team has provided direction that they want hyperlinks to have a consistent look across applications. Below are a few different options to achieve that. More options probably exists that we haven’t thought of.

1. Set global styles on all anchors. Any place where UX want links to be different, like bread-crumb navigation links, general navigation links, etc, we’d need CSS to customize the look of those links.
2. Create an anchor component and direct people to use that whenever they need a link which looks like the OCS defined hyperlink.
3. Create a class that can be added into the DOM which scopes the “global” styles applied to anchors.

Each of these have trade-offs.

With the first option, the global styles target HTML links, links generated from react-router’s link component, links in generated content, (think content from the CCD stuff in portal) meeting UX’s intent of consistent hyperlinks across applications. The trade-off with this approach is by having those global styles, it will also style links which UX doesn’t want to look like the default hyperlink. To mitigate this trade-off, customized CSS would need to be added to get those links( bread-crumb links, general navigation links, etc) to look different than the default hyperlink.

With the second option, the trade-off comes from teams not using the anchor react component simply by not knowing it exists and or not knowing that they should be using it. That leads to some links in the app being regular HTML anchors and some being the terra anchor component or all of the links in an app being HTML links. That causes inconsistencies with the look of hyperlinks as some will be styled to match the OCS design for hyperlinks and others will be left without the style. Another trade-off with this approach is we wouldn’t be able to style links in generated HTML content with the component. To mitigate these trade-offs, we’d need to raise awareness of using this component, keep an eye on it in code reviews, and look into maybe a specialized class for generated HTML content.

With the third option, the trade-off is somewhat similar to the first. Any time we had links in the DOM nested under an element using the class to “globally” style links which UX wanted to look differently, we’d need to add customized CSS to override the styles. Though the custom styles would need to match the specificity of .global-link-styles a {...} to apply correctly. The mitigation of this approach is also similar to the first options mitigation approach.

I’m open to looking at the options. And as mentioned above, more options probably exists that we haven’t thought of. If we think the 2nd option of creating a component works better, I’m fine talking through that.