Cleanup tag display with long lists of tags

[zackkrida]

Problem

Some images, particularly from platforms like Flickr, have many many tags. The display of these tags is distracting, particularly on mobile:

An example: https://openverse.org/image/7e138814-e774-45fb-91ee-7b728c174616?q=Titmouse

Description

Truncate the tags list to a fixed number of rows. We can do this hackily in CSS with height or some other method. Use additional styling to indicate the list is expansible.

Alternatives

Additional context

[openverse-bot]

Subscribe to Label Action

cc @WordPress/gutenberg-design, @WordPress/openverse

This issue or pull request has been labeled: "🖼️ aspect: design"

Thus the following users have been cc'd because of the following labels:

• WordPress/gutenberg-design: 🖼️ aspect: design
• WordPress/openverse: 🖼️ aspect: design

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[fcoveram]

Great finding. Thanks for the ticket ✨

Here is an idea that can be implemented in line with #410, and that can be found in #2113's design file

---

Since XS breakpoint has the smaller area, I envision three visible rows of tags. In XL and 2XL could be the same, but I wonder how that dynamic behavior can be applied consistently across all breakpoints.

What do you think @obulat and @dhruvkb?

[AetherUnbound]

This is great! As I look at those screenshots you shared, it can be a little tough initially to tell that the "Show all tags" element is something that can be interacted with. Is that consistent with the way similar elements are displayed in the rest of our app? Is there a way to make it seem a bit more like a button/interactive element? Please disregard if this fits other paradigms I'm unaware of 😄

[zackkrida]

It looks very nice! Development-wise anything we do for this issue might be deceptively challenging. We'll have to make sure it's accessible and crucially decide what type of component we think this is. Perhaps an "accordian" is the closest-related pattern.

[fcoveram]

it can be a little tough initially to tell that the "Show all tags" element is something that can be interacted with. Is that consistent with the way similar elements are displayed in the rest of our app? Is there a way to make it seem a bit more like a button/interactive element?

The button size is consistent with other buttons toggling similar actions. I tried a different style that might work well on small breakpoints, but it becomes too wide on md and beyond. Here is an example

First release

As writing this comment, I think we can go with full-width for xs / sm and width auto for md and beyond.

[krysal]

I like more the version of just bold text plus the caret. The button calls more interaction but it doesn't seem so necessary for this case.

[fcoveram]

I asked for feedback on the accessibility channel and received the following response from nickthegeek:

This is a good design pattern as long as it’s implemented accessibly. Here are a few things to remember:

• Use a button for the toggle
• Use aria-controls and aria-expanded on the toggle
• Use aria-hidden on the hidden section
• I’d personally use the aria-hidden to show/hide. ie [aria-hidden="true"] { display: none; }. It’s not an a11y requirement but I find devs get the toggles right when they visibly see then doing their thing
• When the content is hidden use either display or visibility to hide the content. These do not animate on transition but you can use visibility then opacity, height, etc which do animate. The reason display and visibility are important is if a user is using a keyboard to navigate they could still access all of the tags but not see them.

[fcoveram]

I think we can go with the first idea for this release and see how people interact with it.

The mockups are in #410's designs in the "Use cases" section.