Module categories on Browse tab aren't clickable, don't perform a search

To fix this issue, I copied the code for the module categories' behavior from ModulePage.svelte into Categories.svelte. It seems to work the same on both pages, but it makes the code in ModulePage.svelte seem a bit repetitive. I've noticed that the markup for module categories is a bit different on the Browse tab vs a module's details page, but would it be a good idea to try to re-use Categories.svelte in ModulePage.svelte like some of the other components on the page? Given that the module details page is currently being worked on in issue #3322594 📌 Update project detail page layout & elements Needs work , I wasn't sure if I should make this point another issue, but I will if it's helpful.

Also, I noticed that in the CSS for the module details page, the entire `

` element holding individual module categories has `cursor: pointer;` applied, but on the Browse tab, I chose to change the cursor on hover for individual module categories so that it doesn't seem like non-interactive parts of the card are clickable. Please let me know which is preferable.

(I have rebased.) I don't know enough about svelte best practice to comment on the duplication of filterByCategory() - move something to util.js?

I've applied MR480 and also cleared the caches. Hovering over a category pill brings up the pointer, and adding the pointer rule to each list item instead of the wrapping unordered list seems like a reasonable call. only problem at the moment it doesnt happen anything on click, i've tried in safari and edge, while the click on the details page still works. but clicking a category pill on any card on the main page has no effect.

but there is also the question how the category selection behaves on click. if you have access control and accessibility selected in the filters category section on the main project browser page and you go to a details page and then click the category decoupled for that module you are forwarded back to the main page, access control and accessibility are unticked now while decoupled gets ticked.
but the question is what would be the expectation, returning to the example from the details page, if access control and accessibility are ticked and you now click for example the integrations category pill will now access control, accessibility, and integrations be ticked or will access control and accessibility be unticked and only integrations be the sole category being ticked? also the point that applies to the detail and the main page to the same degree, how to signify that you've clicked a category pill and how to revert to the previous category filter selection? yes you have the option to use the back button function in your browser but shouldn't there be at least some signage and/or an option to revert the selection on the page itself as well?

and two more aspects about the category pill design in general which are probably out of the scope for this issue. at the moment only the pointer changes on hover but shouldnt the styling be changed on hover and when active aka click, to create an affordance like for other interface components as well? the cursor alone could get missed.
and the background color for the category pills has one general problem, the background color (#E5E5E5) against the card background (#FFFFFF) has a color contrast of 1.3:1. In particular since the pills are clickable, interface components the user is able to interact with have to have a color contrast of at least 3:1 (WCAG 2.2 SC 1.4.11)

on the other hand you could also ask a controversial question and question what is the benefit of having the categories on each card? the user is able to control which module cards are shown in the results list by ones selection on the categories filter. problem is there is no switch between AND and OR for filter categories, so it is possible one card could contain only one out of three selected categories, or two or all. but the cognitive load is high to figuring out which categories are selected and which categories a card belong to. but as i said the card is matching the filter criteria and on the details page you have the category pills anyway so are those pills really necessary on a card? and on cards those pills are sort of harming the easy readability and scanability.

I think the basic click ability is kind of useful in this case (it felt like a good intuitive improvement) and could be enhanced in follow up issues, but I'm intrigued why you couldn't click... i'll review again.

This issue worked as expected on DrupalPod on Chrome.
We should open an issue up if it does not work in Edge and Safari but because this is an enhancement. I think supporting edge and safari would be could be a follow-up.
The feedback and accessibility concerns are valid and will be super useful as we make later enhancements but for now, I think this achieved the targeted outcome.

So i double checked and for me it's clickable in Safari.

kwiseman → changed the visibility of the branch 2.0.x to hidden.

It seems like the consensus in this thread in the Project Browser slack channel is to solve this problem (a module's category chips looking interactive but not being interactive on the Browse page) by removing the category chips altogether (only on the main Browse page). Prior to the Slack thread, the behavior of the category chips was also touched on in the Drupal UX meeting on 5/24/24. That discussion starts around 33:49 in the video.

I created a new branch for 2.0.x to solve this issue by removing the category chips.

Re-hashed this in the meeting today @kwiseman. I think the screenshot provided in this Slack thread is the new preferred way. Would you be able to do it this way?

https://drupal.slack.com/archives/C01UHB4QG12/p1719411859068539

kwiseman → changed the visibility of the branch 3446416-for-2x-module-categories-on to hidden.

kwiseman → closed merge request !524

kwiseman → changed the visibility of the branch 3446416-module-categories-on to hidden.

The 3446416-2x-no-click-categories branch makes the categories look like this screenshot from the slack thread:

But now I'm running into the problem that sometimes the module's descriptions are different heights which causes the categories to be misaligned, but doesn't look great:

Thanks for bearing with us while we floundered on decision-making, everyone! This is a step in a good direction.

Automatically closed - issue fixed for 2 weeks with no activity.