-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Site Editor: Hide appender in non-empty documents #36827
Comments
I believe that @shaunandrews and @jasmussen might want to take a look at this issue. |
Agreed all around. Also better matches the reality of the partial when rendered in the template and front-end. |
Generally agreed, but I think it's important for us to think of a clear and intuitive heuristic for when it shows and when it doesn't, one that ideally works across every instance of the editor. I'm not sure "non-empty" is enough. I know @youknowriad is busy as always, but he recently tinkered with this behavior a bit: what are your thoughts Riad? |
Well right now, when you focus the template part, the inserter shouldn't be visible (per the last changes), so the issue is less present. the inserter is still visible when nothing is selected but maybe that's an acceptable tradeoff for now (we also need to think about post editor, it's the same behavior) |
If that behavior is a good one for everyone and a must have for 5.9, we should backport #36656 in that case. |
This is actually the behaviour I think we need to change here. It is much less problematic in the post editor, and even the template editor to some extent, because the bottom of the document is not visually defined except by the browser window itself. But in template part focus mode it makes it difficult to interpret whether the whitespace at the bottom of the document is added by the inserter, or some padding / margin values on the blocks in the document. Especially as when you do select a block, the inserter disappears but the space it occupies remains. |
@jasmussen this makes me wonder why this appender is not "absolute positioned" like the ones in container blocks? That would solve the issue I believe. |
Abs positioning would probably help here, yes. I think the challenge there is that it's actually yet another appender that's different, but still the same, as the others, because technically it is abs positioned. It's just abs positioned inside an empty paragraph that you're meant to be able to click to start typing. If that empty paragraph wasn't there, the appender wouldn't be either. I've referred to this particular appender as the "Trailing appender" (paragraph and plus in a box), and past conversations suggested it could be removed entirely in favor of selecting the last block and pressing Enter, as you would in most other editors. It's just unclear whether that would be intuitive in a site editing context. One thought is to enable replace that trailing appender with allowing the sibling inserter to function after the last block. 🤔 |
That seems perfectly reasonable to me. |
We don't need a trailing inserter for these views. The main inserter in the header should already accomplish that. |
I'm going to leave this marked as a bug to be fixed during the 5.9 beta period as that large white area at the bottom of the canvas is not correct behaviour. |
I took a quick look at this and hiding the appender for templates parts doesn't fix the white gap at the bottom. The white gap comes from the Group block having a https://github.com/WordPress/twentytwentytwo/blob/trunk/parts/header-small-dark.html I don't think we should hide this since it's a part of the template part's content? Perhaps we could change the background of the isolated template part editor to a checkered pattern so that it better indicates that "nothing" is there? (Excuse the rough mockup.) |
Hey @noisysocks good catch, I can confirm that bottom margin comes from the theme (TwentyTwentyTwo): My instinct would be to accept that this is showing (I wouldn't show the checkered background, the margin is presumably there to actually push content down and let the white part show), so I personally think it's fine. I'll let @jameskoster chime in as well. |
Agreed, we should allow the margin to affect the canvas dimensions. The background is a little tricky. Effectively it is transparent since the template part itself has no background color. But of course the template part is never accessed independently on the frontend, so that transparent area will always be "filled" by the background of the parent template. All that said, can we use the "Background" color from global styles as a default? And if that is not set, use the transparent texture as a fallback. |
I just checked with TT1 as my install of Twenty Twenty Two is not working correctly. Focused Header area. It looks like the appender is just hanging in the air so to speak. I wonder why I see it there. As I see no hanging appenders in the template I was just in before editing the header in focused mode. Deselecting the layout an appender should not be seen. As it should just show a pure layout. |
Regardless of any margins added by the theme, I still think it makes sense to remove the appender. If we ignore the margins, the appender still adds unintentional whitespace: -- I do actually like the idea of the "transparent" background. If we treat it like a spacer block, with a drag handle, I think it could be fairly nice. With that in mind, I do think some of these margins/paddings belong on the Header Template Part within a Template. |
Sorry, I wasn't suggesting it for the entire canvas — just as a way to denote the margin that exists outside of the canvas; I think the canvas should default to the GS background color, with white as a fallback. |
Gotcha, yeah that could work well. For the drag handle, would that just increase the margin value? I wonder how that would work if there are multiple margins. I also worry a little that folks might mis-interpret that as setting an overall height value. |
I may be the only one not a total fan of the photoshop transprency texture. I don't think it really adds any value since there will always be a background around content. |
To me it sounds like this is becoming more complex than it need to. The appender automatically adds space. I highlighted the Spacer area above it through List view. Removing the appender we can also remove the default "Paragraph block" space. As it is really not a space that exist in the layout, but it is added in automatically associated with the appender. |
I agree.
Good point.
This seems simpler. In the interest of iterating, how about for now we just hide the appender and set the background colour to be the same as the one defined in global styles? |
Sounds good to me, we can always follow up. I suspect we might be over indexing on Twenty Twenty Two’s dark background and built in bottom margin. |
This is true, but I suppose the argument is that we don't always know what the background will be. Quick example... let's take this header: The light blue area is a Group with a bottom margin, and let's say the global Now let's say that you want a blue body background color just on your Page template. When you insert this Header template part, that white area from before will not be white, it will inherit the blue background color from the template like so: So the point is that the white background in isolated view may be accurate most of the time, but not all of the time. The transparent texture better indicates that the background color of the parent document will bleed through in to the template part. The other consideration here is patterns. When viewing a header pattern like the example above in the directory, there is no |
I opened the following issue in the repo for Twenty Twenty Two: |
The appender inserter that appears at the root level of the document degrades the site editing experience, particularly when focussing on a template part:
The white space in the screenshot above is caused by the appender inserter.
Since template composition is generally a less linear flow than authoring a post or a page, having an appender at the bottom of the document flow feels a little arbitrary. I don't think we would miss it if removed, and the result would be a more accurate representation of the document on the canvas:
The text was updated successfully, but these errors were encountered: