-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default appender: Hide the dashed indicator until ancestor is selected. #53761
Conversation
Size Change: +20 B (0%) Total Size: 1.51 MB
ℹ️ View Unchanged
|
The dotted outlines break the wysiwyg – particularly in site view – so I am in favor of this change and would even consider extending it to empty groups. It works well in the Site Editor because you see the outlines of empty columns on hover. In the post editor you have to click around to find the empty block which feels a bit 'mystery meat': Should we expose outlines when hovering empty containers in the post editor? |
My reason for not extending it to that is that those move towards placeholder territory, not actually taking up space on the frontend, so true wysiwyg there would mean a zero height.
I think maybe, yes, though perhaps even further it would be nice to find a hover-outline design and style that would be identical between both, while still keeping in mind both design and writing flows as valid and useful. Related, #44774 and #44775, both rather outdated but containing tangential explorations. |
Unless you add a height or min-height. It's perhaps unconventional but there's nothing to stop you using empty containers as spacers. Fine to start with columns though :)
Agreed, though I'd say adding a hover-outline to empty containers (just individual columns initially) is fairly low risk, and achieves parity in that context? If it's not trivial then probably fine to do separately. |
I can take a look, sure, was mostly doing the mental math of whether this would be a local bit of code complexity that would eventually become vestigial if we revisit this. |
I took a stab, and got this far:
That almost shows a hover outline on the appender. And then I stopped myself as this is already duplicating some of the hover styles from elsewhere, and is very edge-case CSS, because. This is the appender, which diverges from the block in a few ways, notably around it being an actual If inspiration strikes and you have an idea for how to address the hover outline without too much complexity, feel free to push to the branch. |
Agreed, if there's no easy way to target the hover state of the block then we should leave it out. I suppose we'd need to add an I still think it'd be nice to have some visual feedback to indicate when an empty space is not actually an empty space, but it's probably fine to handle it separately. |
Let's try this, it's a small change and we can revisit it. |
What?
Currently when using the Columns block for certain layouts, an empty column will show a dashed outline indicator, as shown in this GIF:
The dashed outline indicator comes from the appender block, and serves both to indicate an empty container, and to serve as a clickable area to select the block itself, because when the block gets selected it becomes an inserter.
But for column based layouts, occasionally you want a column to be empty, to stay that way to simply space out a layout. That breaks with WYSIWYG.
This PR changes it so that the appender in 2 level nesting cases (i.e. columns), the appender is invisible until an ancestor has been selected first. In other words, if you have an intentionally empty column, the dashed indicator won't show up for the empty column until the columns block itself has been selected, as shown in this GIF:
The group, row, and stack empty states remain the same as before:
Testing Instructions
Insert a columns block with content in one column, and no content in the other. Deselect it, and observe that the empty column should visually appear empty, with no dashed line indicators until you select the columns block.