Pretty simple idea for a nice(?) tweak:
It is typical UI behaviour to grey out disabled elements.
What about adding this to Drupal menu edit screens?
Current UI
Proposed UI
In a small menu like this it's relatively easy to spot the disabled items, but in a big menu with longer text entries and especially with also entries, the default (disabled) marking of disabled entries does not stand out very well anymore.
For the screenshot above i used
tr.menu-disabled>td:first-child {
filter: grayscale(100%) opacity(0.3);
}
Maybe the dragging-arrow would need to be left untouched
and surely the exact greying-out effect is TBD,
but before getting a thumbs-up/down i did not want to do anything more.
| Comment | File | Size | Author |
|---|---|---|---|
| #24 | interdiff_13-24.txt | 2.28 KB | komalk |
| #24 | improve_listing_of_disabled_menu-3105810-24.patch | 3.77 KB | komalk |
| #24 | before-patch.png | 361.33 KB | komalk |
| #24 | after-patch.png | 356.97 KB | komalk |
| #21 | After_2.png | 112 KB | priyanka.sahni |
Comments
Comment #2
sirtetComment #3
sirtetOne argument against the idea could be:
The above claim
omits that typically also interaction is disabled with these greyed out elements.
But here, interaction is still possible (and also wanted).
Not being able to rearrange entries or follow links would be a loss of functionality.
So i still think the benefits of better visual clues justify to go against the convention of disabling interaction with greyed out elements.
Comment #4
sirtetI think leaving the handle dark is a step back compared to greying it out:
Comment #5
ckrinaThanks for the suggestion, it looks like a really good idea to be implemented on several places!
- Have you checked if there's any existing pattern for that in Seven we can adapt?
- Also, have checked if it passes the minimum contrast?
Comment #6
sirtetThanks.
Yes, it also thought it might be interesting for other places.
No, i wanted to do no further research until i got some more Feedback from the makers of claro.
Waiting for more Input...
Comment #7
ckrinaComment #8
ruthleopold commentedHaving the text that light is not accessible, but we can modify that with the disabled color that is defined in the Drupal Design System, as well as make the text weight thin instead of regular. Without both, the disabled text does not look distinct from the normal text.
Figma: https://www.figma.com/file/NpZUAp8BEkMJvm5gKBCDBB/Claro?node-id=17227%3A...
Comment #10
indrajithkb commentedHi @ruthleopold from your design it's showing color:#727780 (which we need to add as new variable)
we have the color variable for disable (--input--disabled-color: rgba(84, 85, 96, 0.6);) so which color can be used here ?
i have just check with this --input--disabled-color: rgba(84, 85, 96, 0.6); Please review the screenshot and confirm whether is ok or not.
Comment #11
ckrina@indrajith-kb let's use the current
disabled-colorvariable for now. This color will be updated soon together with the rest of greys in another issue, but for now let's keep it as the one we've been using so far.Comment #12
indrajithkb commentedComment #13
indrajithkb commentedHi @ckrina thanks for the confirmation to use the color. I have added the patch please review.
Steps to reproduce:
- Go to Home > Administration > Structure > Menus
-Edit menu (here i used edit tools menu)
Attaching screenshots for refer:
Brfore:
After:
Comment #14
indrajithkb commentedComment #15
KondratievaS commentedTested patch from #14 and result is OK
Comment #16
KondratievaS commentedComment #17
ckrina+1 to RTBC
Comment #18
lauriiiThe text doesn't comply with the color contrast requirements. According to https://webaim.org/articles/contrast/#incidental, inactive elements don't have to comply with the color contrast requirements. I'm a bit skeptical that this would fall into that category of the elements. Tagging for accessibility review to get input on that.
Comment #19
priyanka.sahni commentedComment #20
priyanka.sahni commentedVerified and tested by applying the patch #13.Attaching the accessibility reports as well as per my understanding.
Before Patch -
After Patch -
Comment #21
priyanka.sahni commentedComment #22
priyanka.sahni commentedComment #23
bnjmnmLauri's concern in #18 was warranted. This needs to be a color that meets AA contrast requirements. The item being styled is definitely not incidental, and needs to have sufficient contrast. We can safely consider it not-incidental because 1) It is a link that is still clickable 2) It epresents a disabled menu item, but it's still possibl to configure that menu item, to do things such as enabling it.
This may be addressed in #3154539: Implement new Gray scale on Claro, but a text color should not have an rgba value. This removes the ability to easily check for contrast problems as the final text color is dependent on its background color. This probably also explains why the contrast problems were not identified in the automated checks in #20. I suspect they need to compare hex values.
Comment #24
komalk commentedReview the patch.
Fixed the contrast error also attached the screenshot for the reference.
Comment #25
bnjmnmThere's an entire issue devoted to the use of grays and their variables in Claro, I think #24 would potentially conflict with that. This should be postponed until that issue lands.
Comment #32
quietone commentedThe Claro theme was approved for removal in #3576460: [policy, no patch] Deprecate and remove Claro.
The deprecation work is in #3576668: [meta] Tasks to deprecate Claro and the removal work in #3584638: [meta] Tasks to remove the Claro theme.
Comment #33
smustgrave commentedClaro has moved to contrib
Wonder if this is something menu_ui should handle?