[feat] interactive states for <rh-tag>

[marionnegp]

Description

Docs for the linked <rh-tag> show states for linked tags, but they have to be implemented.

We also need to consider instances where <rh-tag> acts as a button, and we may need to show a different affordance for interactivity. (For example, a tag in My Red Hat can trigger a popover.) PatternFly's tag demos currently show clickable tags and linked tags that use the same states.

Additional updates:

• When tag is used as a button, a space bar should be able to trigger it. Currently it's trigger by the enter key only.

Suggested solution

• Implement states for linked tags
• Design clickable tag states
• Make demos for linked tags and clickable tags (Currently linked tags are only shown in the color context demo.)
• Fix keyboard interactivity if it's used as a button

Screenshots

No response

Example API

Additional context

No response

[markcaron]

Since we currently have linkable <rh-tag> elements, I'm thinking it wouldn't be a stretch to provide the option for clickable through a similar approach.

Linkable:

<rh-tag href="#">

Clickable:

<rh-tag action="{namedAction}">

Where {namedAction} could be a string like popovertarget="popoverID"

And, in the template, we'd just embed a <button popovertarget="popoverID"> instead of <a href="#">.

Or maybe click="" makes more sense?

The attributes would be an either-or situation, as you couldn't have both at the same time. One would take precedence.

[coreyvickery]

@markcaron @marionnegp What do you think of these state explorations for link vs. button?

[marionnegp]

@coreyvickery, tag as a button looks good to me!

Does tag as a link need a hover state? The typical hover state for underlined inline links would be for the underline to move down a couple pixels, but I don't think that works as well here.

[adamjohnson]

<button>'s can have a disabled state. Would be nice to include design specs for disabled as well.

Keep in mind WCAG states that disabled elements do not need to meet color contrast guidelines (see incidental).

[coreyvickery]

@marionnegp @adamjohnson For the link variant, I got rid of the underline on default, but it could appear on hover and active states. Do you think that would be enough to distinguish?

[marionnegp]

@coreyvickery, we were considering using a regular tag next to a link tag in My Red Hat, and having no underline makes it tough to know that one's clickable. (Ignore the old underline style.) I do like how you've simplified the default state for a tag as a link vs. a button though. Might bring this to the designers on My Red Hat to see what they think.

[coreyvickery]

@marionnegp @adamjohnson Another exploration using tags placed next to each other.

[marionnegp]

@coreyvickery, would it be weird for a link tag's default state to have the underline and then its hover state would remove it? Another possible direction is making the underline solid instead of dashed on hover.

The text color change is pretty imperceptible between the -70 and -80 colors in the filled tags, so I don't think that should be the primary hover effect.

[coreyvickery]

@marionnegp I'm happy with that if you are. Can we move forward with the below styles and interactions? About your second point, yes, color alone is not an accessibility best practice.

[marionnegp]

@coreyvickery, I'm good with it if you are.

[coreyvickery]

@adamjohnson Are you able to work on this? If so, I'll provide the changes.

[coreyvickery]

Update 3/13: Changes to docs that reflect the above are done.

[coreyvickery]

Another update 3/13: This might need to get moved to Diglett because we have other high priority docs that need to get done first.