I just run into #8205 for the nth time and my fix is always the same, make ListItemSecondaryAction staticly positioned, make the list item container a flexbox and undo the additional padding.
<ListItem
style={{paddingRight: 16}}
ContainerProps={{
style: {display: 'flex', alignItems: 'center'},
}}
>
...
<ListItemSecondaryAction
style={{position: 'static', transform: 'none'}}
>
...
</ListItemSecondaryAction>
</ListItem>
It would be nice if this was not necessary and instead the default behavior.
The ListItemSecondaryAction is absolutely positioned, causing the problem that it does not grow to take the space needed for its content.
N/A
I think this is described with enough context above.
Is there a reason ListItemSecondaryAction is absolutely positioned?
@Pajn Yes, it's because HTML5 specification prohibits the nesting of <button> elements.
I'm probably missing some use case, but this doesn't cause nesting of <button> elements.
ListItemSecondaryAction lies next to the ListItem-root, both having <li> as parent.
Event when adding the button property to the list item does not seem to cause a difference, however as ListItem-root no longer extends the full width the hover effect (and click area) is also no longer the full width as it does not stretch below the ListItemSecondaryAction
Not nested:

Button example, not using the full width:

I can't say if not extending the full width when using button is an improvement or a problem. It looks a bit weird but also, having two buttons on top of each other is also weird. The use case ListItem with button + secondary actions feels strange all together. But still, it's a breaking change I guess.
I'm probably missing some use case, but this doesn't cause nesting of
@Pajn You are right, I have jumped to the conclusion too quickly. I think that it's important to have a ripple covering the whole surface area. In order to have that, we need to nest the secondary action in the list or to absolutely position the action. If we go with the nesting path, it's important to be careful with the resulting DOM structure, some combinations are invalid. Benchmarking MCW and vuetify it seems we are the only one doing that. I have nothing against exploring the flex layout position path. It's definitely a breaking change, we would have to wait for v4.0.0, coming in the next few months. Feel free to experiment, I think that it will be a success if:
I tried this long ago and we merged https://github.com/mui-org/material-ui/pull/5911 but reverted due to the ripple issue.
I did try to revisit this, I still have the branch https://github.com/alienfast/material-ui/tree/list-item-flex-revisited - I tried with a ripple bounding element but I did not have success.
I just bumped into this again - am using a ListItem without button but with secondary actions, and want the content to grow but not overflow the actions. I'll do something custom for now but I definitely think revisiting this is worthwhile.
I'm closing for #13597 that explores how to improve the ListItemSecondaryAction position.
Most helpful comment
I tried this long ago and we merged https://github.com/mui-org/material-ui/pull/5911 but reverted due to the ripple issue.
I did try to revisit this, I still have the branch https://github.com/alienfast/material-ui/tree/list-item-flex-revisited - I tried with a ripple bounding element but I did not have success.
I just bumped into this again - am using a ListItem without
buttonbut with secondary actions, and want the content to grow but not overflow the actions. I'll do something custom for now but I definitely think revisiting this is worthwhile.