Dropbuttons in table cells are potentially unusable if it includes options with long text length.

Experiencing this with the graphql module's server list. The items aren't even that long.

#5 Please review the patch

Well... it applies cleanly and it does keep the dropbutton open.

The next poblem this shows up is that the dropbutton open handle moves to the right, away from the cursor, which is less than desireable. I'm not sure whether that's something that should be solved here or as a follow-up.

Just a thought - views has a 'responsive' mechanism with values low, medium and high that determine how much a column changes size in situations like this. How does that work? Is that something that can be implemented by this theme on operations columns?

Yeah I'm following that one too.

Do we know what the core team's preference is? Are you on any of the core teams? (Sorry if I'm supposed to know that)

I agree consolidating effort would be a good thing.

Thanks for that excellently clear explanation :)

Agree on all points.

For this issue: I call it functionally reviewed, and I would mark this RTBC but I'm not 100% up on the preferences of the Claro theme when it comes to CSS inclusion. I think that level of code review needs someone who has worked on the theme to take a look.

Ok.... found an issue with this approach in views:

Can be make this change more targeted to only dropbuttons inside tables? Given that's the place they're broken, then it won't effect the views ui.

This patch makes the change only applicable to dropbuttons inside a td.

Applied patch #5 working fine after patch the issue fixed
Thanks for the patch for reference sharing

Definitely needs a bit more work, I'll review the breakpoint tomorrow as I've been using my patch and am still seeing it popup in tables in some occasions. Going to work on this tomorrow.

Screenshot attached from views showing the fix.

IMHO the previous solutions are too complicated.

In this patch (which is what we do in Olivero), we use visibility: hidden to hide the hidden <li> elements instead of display: none.

While both rules remove the elements from the browser's accessibility tree, the difference is that visibility: hidden will reserve space for the elements, while display: none will not (it will effectively remove the elements from the DOM).

I guess there's the trade-off that the main button is now sized according to the widest item in the tray, which wasn't the case before. I think this would be fine as a trade-off for addressing this bug until we have implemented split button. What do others think?

+1 for clean simple solutions!

I have manually tested this in an environment that experienced this issue in multiple places and it is working nicely, thanks @mherchel.

As for code review I see nothing out place. I've checked and it seems there's no change in functionality for screen readers so there's no regression there.

I'd say #18 passes community review.

I'm really sorry, but this brokes the design by leaving this huge space between the button word and the toggle. I understand the reasoning behind the technical solution, but the visual result goes too far for what it solves.

IMHO the patch from #13 also solves the problem without that huge visual impact by default, since the difference is just shown when it's hovered.

But added to the feedback on #15, I've also spotted something thaton a design perspective isn't quite right: the button goes to the right of the screen.

It can give the impression that it's partially hidden, so the right design solution would be to leave a few pixels to make it clear it's the intended behavior. Doing some tests seems like a possible way to fix it would be to add a max-width to .dropbutton--extrasmall, something like width: calc(100% - 0.5rem);. Then the .dropbutton-togglewould need to be moved too and the shadow from .dropbutton-widgetwould need to be adjusted too:

but this breaks the design by leaving this huge space between the button word and the toggle. I

This only happens if there is an extreme amount of text in any of the dropdowns. I personally don't know of any core or contrib configurations that would cause this to happen. Nevertheless, it is possible!

Attached is a patch very similar to #18, but with a max-width set to 200px (animated gif below).

IMHO This is a really good compromise that resolves 99.9% of the use cases. Anything outside of that is still usable.

If you think this approach is a dead end, let me know.

Uploading correct animated gif

Ugh. I also accidentally uploaded a D10 patch for Olivero. Please ignore that! :D

I do like the clean solution in #22, the max width seems a suitable work around.

Noting that this applied to all dropbuttons instead of just ones in table cells where the issue was present. I've checked the views layout (screenshot attached) and a few other pages, and see no issue with the results of this change... Especially given this issue is a temporary fix until splitbutton arrives.

Though it would be a simple enough change to make it targeted to tables again.

Aside from that, the patch applies, before/after screenshots attached, code is good, no new issues introduced. Going to mark this RTBC.

ugh, failing at screenshots today!

This only happens if there is an extreme amount of text

It does happen any time the content in the hidden area is bigger than the button text. :)

See an example:

As background, this is the design specification:

I can understand this is solving a UX problem but it's breaking the design on the resting/closed state. I think UX is more important than design here, and also I expect this is going to be solved in the future by #1899236: Add new Splitbutton render element to eventually replace Dropbutton. So I'll +1 this while my designer self goes to cry to a corner.

Committed 92e3e65 and pushed to 9.4.x. Thanks!

Committed 65c863b and pushed to 10.0.x too. Thanks!