#Usability

I fixed the issue where the checkboxes for "Reversed" and "First and last only" were not being saved.

Moshe was right in 2007, this can be implemented in contrib. Doing it in core would mean having to handle it in all listings, views etc. generically.

Based on #22 I removed the collapsible behavior entirely.

In support of what has already been said...

I hover on Commerce and the menu items open. I then hover on Products and the menu items don't open. I have to click on Products.

I finally click on Products and I am not able to get to the products page. Instead the child items now open.

For me to get to the products page, I will first have to go to Scheduled Products and then to Products.

The same way you can't go from Structure to Feed types. You first have to get to Add feed type and then make your way back to Feed types.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

And a reroll for Drupal version 10.4.4!

We commonly use an improved version of the https://www.drupal.org/project/improved_multi_select → for our Entity Reference fields:

Added features (on top of those of Improved Multiselect):
- Edit buttons in the list.
- Add button at top right to add new items.
- Ajax refresh button to update the list.

At 📌 Drupal Usability Meeting 2025-03-04 Active , we agreed to use this open-ended issue to continue the discussion of the admin UI.

We need to be aware of the changes driven by Experience Builder (XB). I think the most recent demo available is @lauriii's presentation at Florida Drupal Camp: https://www.fldrupal.camp/session/experience-builder-transforming-drupal.... The YouTube link is https://www.youtube.com/watch?v=vBiPqXLfJjk

Some of the next steps after that are to get the results of user testing and to come up with proposals to be used in further testing. I think it will help to focus the discussion if we consider a single task that a beginning user is expected to accomplish. (Or consider a few tasks, one at a time.)

Today, we had a broad discussion of the admin UI instead of discussing a particular issue. I am adding #3325034 as a related issue, since that seems like the best place to continue the discussion.

benjifisher → credited aaronmchale → .

benjifisher → credited ckrina → .

benjifisher → credited emma horrell → .

benjifisher → credited rkoller → .

benjifisher → credited simohell → .

benjifisher → credited worldlinemine → .

Fix the date.

It is missing a "-" character at this place :

Hello,

The latest patch #23 seems to break CSS aggregation for me.

My 2nd point was that in your previous commit bd6e4af7 after hovering over the div it is getting blue color as i thought you were trying to make the hover same as the other dropdowns like e.g. Security Advisory Coverage, Maintenance Status etc. I was saying if we follow this we need to change the color of the text from white to black when it get blue bg color while hovering.

Alternatively we may pick the design as i mentioned in my 3rd point it may look good as in light mode also Filter by category is not identical with other select dropdowns.

As you make the changes in the MR now. I think it is looking good. Let's wait for feedback from others.

I'm experiencing the same issue in Firefox (136.0 on Mac) after moving to the 4.0.6 version

The breadcrumb is covered by 🐛 Mobile friendly breadcrumb (Lighthouse) Needs work .

The Lighthouse accessibility audit in Chrome DevTools covers this (WCAG SC 2.5.8).

The automated Axe tests will cover this, but we would need to explicitly enable (or really, enable WCAG 2.2 AA). The test for 🐛 Mobile friendly breadcrumb (Lighthouse) Needs work can serve as a starting point.

I'm not clear on why this is tagged as a beta blocker.

Beta is where the PHP API and update path begin, but this has nothing to do with either of those. The frontend code is completely internal and we can change it however we like, whenever we like, so I'm tentatively untagging this as a beta blocker...but certainly a worthwhile feature!

appears everyone that attended got credited. Lets get them their credit!

Added some questions/comments.

I think it makes sense to move the css rules to gin.css.I think i didn’t completely get how points 2 and 3 makes it similar to other dropdown.If you think it makes sense then you can push the changes accordingly.

This was a tiny bit tricky b/c we need PostCSS to not mess up the form that is required to provide the empty alt text. Should be OK now. Needs browser testing, but Can I Use shows 91%: https://caniuse.com/?search=content%20alt%20text

We need to apply this here for items which does not have icons.
Should be enough imo.

https://dev.to/whitep4nth3r/hide-text-in-css-pseudo-elements-from-screen...

To expand on #199.

If we added an OnlyShowTranslatedMenuLinksInterface then SystemMenuBlock could implement that, or pass a value object which does so.

And then another contrib module that provides an alternative to SystemMenublock could implement that interface or pass a value object that does so. With the current implementation in the MR, that contrib module would also need to to duplicate LanguageMenuLinkTreeManipulator and check its own class in there so the manipulators are not re-usable even when the logic is identical.

And then I still don't understand the reasoning for always passing a context, except to allow contrib manipulators to potentially target any specific core menu class that does this - but doing so with just the class to go on and no other generic contextual information seems very unwieldy.

Hi @utkarsh_33, While reviewing this issue, I had a few observations.

1. It seems that dark mode-related changes would be more appropriately placed in the gin.css file rather than pb.css, as all other Gin-
specific styling is handled there. Would you agree with this approach?

2. If we want it to look similar with the other select dropdowns we need to change the colour of text to black like other select dropdowns
when it gets focus or hover.

3. But i noticed in light mode this dropdown is not similar with other select dropdowns so we may consider it and can obtain the background color for before and after hover like this also.

I used this code for the changes

.gin--dark-mode .pb-filter__multi-dropdown__items--visible {
  background-color: var(--gin-bg-layer);
}
.gin--dark-mode .pb-filter__multi-dropdown__items--visible div:hover,
.gin--dark-mode .pb-filter__multi-dropdown__items--visible div:focus {
  background-color: var(--gin-bg-layer2);
}

I read the MR through, and I didn't understand why the new $context argument was required instead of defaulting to an empty array or some other default.

The callers are all passing $this which seems very arbitrary and only relevant if you wanted to target the specific calling class with a manipulator, which seems like it would probably be extremely rare - and something an individual core issue could be opened if someone wants to target one.

The only implementation of ::applies() in core is checking for SystemMenuBlock, but the reason it's checking is to not show untranslated menu links, so why not a context like DO_NOT_SHOW_UNSTRANSLATED_MENU_LINKS in that case? And then every other caller in core would not be passing that context, but contrib menu implementations like alternative menu renderings possibly could.

wim leers → credited gábor hojtsy → .

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

It needs a round of manual testing and also i'm not sure about the css rule for hovering over the div.Already added the questions for the same.

#8: that particular error seems a duplicate of 🐛 No visible error message when trying to save with missing image Active . See this issue's summary: this is about generally actually displaying validation errors.

Will re-post your comment there and credit you 👍

The background and text color of Filter by category items is different from other filters eg Security advisory coverage.
Also suggested some css change.

Marking NR.

This is how the dropdown looks:-

Opened ✨ AVIF conversion with WEBP fallback Active