List View: Reduce visual weight of locked nested blocks

[richtabor]

Noticed this in Fimga recently, where contents within a locked group would show a small circle, instead of another lock icon. It reduces visual weight of locked blocks within List View, making locked block contents less bulky and more scannable.

Perhaps worth exploring a bit.

Current

Proposed

[jasmussen]

To me this mainly makes sense if the list view employs the fuller behavior, where you can actually lock the inside blocks even when a parent is locked first, like Figma:

Even the dragging behavior is useful there, where those dots indicate the draggable-to-lock area.

But I'm missing a beat here, as I'm not seeing the nested locks in trunk:

[richtabor]

But I'm missing a beat here, as I'm not seeing the nested locks in trunk:

You have to toggle the control at the bottom; there's some cleaning up we can do on locking in general.

---

I actually wouldn't mind exploring more approaching locking as well. That would open the avenue for something more streamlined for locking/unlocking at the list view level.

We have "Lock all" (which does not lock everything technically) but only movement and removal on the current block. And then that "Apply to all" control, which allows those settings to permeate down into nested blocks.

I do wonder if the locking mechanism should apply to all nested blocks by default, then you could go in and unlock blocks instead of the other way around. And it is odd you can have "Apply all" toggled on a parent block, but then opt a nested block within out of locking (while the parent control still indicates everything is locked).

[jasmussen]

Ah of course, went a bit fast there. Thanks. And yes, I agree, lots of opportunities here to improve the list view and its features in general..

I do wonder if the locking mechanism should apply to all nested blocks by default, then you could go in and unlock blocks instead of the other way around. And it is odd you can have "Apply all" toggled on a parent block, but then opt a nested block within out of locking (while the parent control still indicates everything is locked).

I think I agree simply on the fact that I stumbled on this just now, that even though an ancestor can be locked, children inside are not. To reference Figma yet again, this is also the case here. The children can be locked, but they are also de-facto locked when an ancestor is locked. So it's probably more than a visual tweak if we wanted to apply this here.

But it does also seem valuable the block editor use case to allow the other, locking just the ancestor while keeping children unlocked, for example to make a particular edit operation safer. So it's not a direct comparison, and probably not that useful to compare too much. But that said, the default behavior could still be to apply to children. No strong opinion there.

I also feel like contentOnly locking is sorely underused for pattern building. As far as I know, that still requires code editing. It'd be nice to consider a locking modal + list view + contentOnly triad for a design sprint. What do you think?

[richtabor]

I also feel like contentOnly locking is sorely underused for pattern building. As far as I know, that still requires code editing. It'd be nice to consider a locking modal + list view + contentOnly triad for a design sprint. What do you think?

100%. There may be a way to leverage a popover instead of modal even. Perhaps a flyover/nested dropdown whenever toggled from the Block Options menu.

Or if you could click on lock icons (revealed similar to what's proposed for showing/hiding here) then that could work as well. Not sure we need locking so front-and-center though.

[mtias]

I'm curious if a parent is locked whether we may not want to expand it and keep the whole thing collapsed?

[richtabor]

We do allow for unlocking of nested blocks within a locked block, which makes me lean towards keeping them expandable.

[mtias]

Right, I was thinking more about cases where we might lock the whole block down (#51968) — it seems in those you shouldn't be able to expand.